1P by GN⁺ | ★ favorite | 댓글 1개
  • 장기 대화형 챗봇은 긴 컨텍스트 창이 있어도 과거 상호작용의 핵심을 응답에 안정적으로 반영하기 어렵고, 이 연구는 재귀적 요약 메모리로 일관성 문제를 줄이는 방법을 다룸
  • 핵심 절차는 짧은 대화에서 초기 메모리를 만든 뒤, 세션이 추가될 때마다 이전 메모리와 새 대화를 함께 요약해 최신 메모리로 갱신하는 방식임
  • 검색 기반 방식은 필요한 과거 발화를 정확히 찾는 검색기에 의존하고, 기존 메모리 기반 방식은 갱신되지 않은 오래된 정보가 응답 품질을 흔들 수 있음
  • Llama, ChatGLM, OpenAI GPT-3.5-Turbo 등 공개·비공개 LLM 실험에서 자동 평가와 인간 평가 모두 기존 접근보다 장기 대화 일관성이 높게 나타남
  • 이 방식은 긴 컨텍스트 창이나 검색 강화 LLM과도 함께 쓸 수 있어, 전체 대화 길이를 무작정 늘리지 않고 매우 긴 대화 맥락을 다루는 실용적 선택지가 될 수 있음

긴 컨텍스트만으로는 부족한 장기 대화 기억

  • GPT-4, ChatGPT 같은 LLM은 다양한 주제에서 동적이고 맥락에 맞는 대화를 수행할 수 있지만, 장기 대화에서는 과거 정보를 놓쳐 일관성 없는 응답을 만들 수 있음
  • 긴 컨텍스트 창은 전체 대화 이력을 입력으로 처리할 수 있게 해도, 과거 상호작용을 이해하고 핵심 정보를 응답에 통합하는 능력은 여전히 제한적임
  • 과거 대화 기억이 필요한 대표 사례는 개인 AI 동반자와 건강 보조 서비스임
    • 개인 AI 동반자는 관계 형성을 위해 이전 대화를 떠올릴 필요가 있음
    • 건강 보조 서비스는 진단 결과 제공을 위해 환자의 문의 기록 전체를 고려해야 함
  • Multi-Session Chat Dataset 예시에서는 약 20턴 뒤 사용자가 과거의 “작곡” 주제를 다시 언급했을 때, ChatGPT gpt-turbo-3.5-0301 버전이 자신을 “전통적인 의미의 직업이 없는 AI 언어 모델”로 답해 이전 페르소나와 불일치한 응답을 생성함

검색 기반·메모리 기반 접근의 한계

  • 장기 대화 능력을 강화하는 대표 접근은 검색 기반 방식메모리 기반 방식으로 나뉨
  • 검색 기반 방식은 과거 발화를 저장소에 보관하고, 현재 대화와 가장 관련 있는 이력을 검색기로 찾아 응답 생성에 활용함
    • 현재 대화에 필요한 의미를 완전하게 포착하는 이상적인 검색기를 얻기 어렵다는 한계가 있음
  • 메모리 기반 방식은 별도 학습 모델이나 강력한 LLM으로 과거 대화를 요약해 핵심 정보를 저장함
    • 반복 갱신 메커니즘이 부족하면, 보존된 오래된 정보가 응답 품질을 직접 해칠 수 있음
  • MemoChat은 화자의 주제별로 과거 대화 이력을 재구성하고, 생성 시 구조화된 메모리에서 검색하도록 LLM을 프롬프트함
  • MemoryBank는 각 대화 세션의 요약을 먼저 만든 뒤 이를 전역 요약으로 압축하는 메모리 메커니즘을 제안함
    • 저장된 메모리가 완전히 고정되면 진행 중인 대화와의 일관성을 보장하기 어려움

재귀적으로 갱신되는 메모리 생성

  • 제안 방식은 LLM 자체가 요약을 만들고 과거 맥락을 계속 갱신·검토해 화자의 실시간 정보를 저장하도록 하는 단순한 플러그인 방식임
  • 절차는 세 단계로 구성됨
    • 생성형 LLM이 짧은 대화 맥락을 입력받아 초기 요약을 생성함
    • 이후 이전 메모리와 후속 대화를 결합해 새 요약 또는 메모리를 계속 갱신함
    • 챗봇은 최신 메모리를 주요 참조로 사용해 현재 대화에 응답함
  • 생성된 요약은 전체 대화보다 훨씬 짧기 때문에, 최대 입력 길이를 비싸게 늘리지 않고도 여러 세션에 걸친 매우 긴 맥락을 다룰 수 있음
  • 장기 대화는 여러 세션으로 구성된 Multi-Session Dialogue로 정의됨
    • 과거 세션 집합 S = {S1, S2, ..., SN}과 현재 세션의 대화 맥락 Ct, 정답 응답 rt를 사용함
    • 목표는 과거 세션과 현재 맥락을 바탕으로 관련 있고 일관성 높은 응답을 생성하는 것임
  • 메모리 Mi는 i번째 세션이 끝난 시점에서 사용할 수 있는 메모리이며, 전체 과정은 각 메모리가 현재 세션과 이전 메모리에만 의존하는 순차적 과정으로 정의됨

메모리 반복과 응답 생성

  • 제안 방식은 임의의 LLM에 두 작업을 맡김
    • 메모리 반복: 장기 대화 흐름에 따라 핵심 정보를 재귀적으로 요약함
    • 메모리 기반 응답 생성: 최신 메모리와 현재 대화를 결합해 적절하고 일관된 응답을 생성함
  • 메모리 반복은 챗봇이 사용할 일관되고 최신 상태의 요약을 얻는 과정임
  • 일부 기존 연구는 요약에 replace, append, delete 같은 “하드 연산”을 적용해 메모리를 갱신함
    • 이런 방식은 연산 라벨이 붙은 고품질 대화에 의존하고, 요약의 의미적 일관성을 방해하며, 장기간 관리에도 적합하지 않음
  • 제안 방식은 대화 맥락과 이전 메모리를 함께 넣어 LLM이 메모리 또는 요약을 재귀적으로 생성하게 함
    • 이전 요약을 활용하면 모델이 현재 대화 맥락을 더 잘 소화하고 고품질 메모리를 만들 수 있음
  • 예시에서는 첫 번째 세션 후 초기 메모리가 만들어지고, 두 번째 세션 후 이전 메모리에 “봇이 최근 24시간 운영하는 새 헬스장에 가입했다”는 새 성격 정보가 통합됨

실험 결과와 적용 가능성

  • 실험은 Llama, ChatGLM, OpenAI GPT-3.5-Turbo 등 최신 공개·비공개 LLM으로 구현됨
  • 장기 대화 성능은 자동 평가와 인간 평가 모두에서 기존의 인기 접근보다 높게 나타남
  • 명시적 메모리를 장기 대화에 사용하는 효과와, 제안 방식으로 생성한 메모리가 LLM이 소화하기 더 쉽다는 점을 검증함
  • 인컨텍스트 학습(ICL)을 결합하면 응답 품질을 더 높일 수 있음
    • 여러 개의 (대화, 메모리, 정답 응답) 형식 샘플을 LLM에 제시함
    • LLM이 생성된 메모리를 더 유연하게 활용할 수 있게 함
  • text-davinci-003에서는 BLEU 점수가 약 +3% 개선
  • 제안 방식은 GPT-3.5-Turbo-16k, LongLoRA-8k 같은 긴 컨텍스트 창 LLM과 LLM-BM25, LLM-DPR 같은 검색 강화 LLM을 보완함
  • 공개 코드는 qingyue2014/Rsum에 제공됨

댓글과 토론

Hacker News 의견들
  • “텍스트 공간”에 메모리를 쌓는 방식은 전부 꽤 해키하게 느껴짐
    모델의 의미를 온전히 보존하려면 계속 요약을 재생성하는 덧댄 절차보다 조밀한 임베딩 공간에 저장하는 편이 더 자연스러워 보임
    또한 모델은 메모리를 인식하고 활용하는 방식으로 훈련되어야 하며, 가능하면 처음부터 그런 설정에서 학습되는 게 좋다고 봄

    • 해키해 보이긴 하지만, 애초에 대화형 LLM이라는 개념 자체도 그렇다고 볼 수 있음
      결국 주어진 대화에 다음 단어를 하나 더 붙이라고 시키는 것이고, 어느 순간 종료 토큰을 내보내면 애플리케이션이 다시 사용자에게 제어권을 넘기는 구조임
      잠재 공간과 텍스트 공간은 생각보다 멀지 않다고 봄. LLM은 꽤 둔하지만 말하기에는 매우 능하고, 코드 작성도 그와 비슷해서 잘하지만 수학처럼 실제 추상적 사고가 필요한 영역에서는 무너짐
      이런 텍스트 공간 해킹은 실제로 잘 먹히는 편이고, “단계별로 생각하라” 같은 프롬프트가 흔해진 것도 그 때문임
      LoRA는 말한 방향에 더 가깝고, 아주 적은 데이터에 많은 이해를 압축하는 데 훌륭함. 다만 단일 대화를 위해 가중치를 조정하는 건 아직 현실적이지 않으니, 그 용도로는 텍스트 공간을 탐색하는 중임
    • 머릿속에서 이 방법을 쓴다고 생각해 보면 됨. 지금까지의 논의를 재귀적으로 요약하면 기억이 좋아질 수 있음
      머릿속에서 뭔가를 요약한다는 게 “해키”하게 느껴질 수 있지만, 실제 기억 작동 방식의 큰 부분이 그와 비슷하다고 봄
    • 흥미롭게도 계속 요약을 재생성하는 방식은 인간 뇌, 적어도 장기 기억이 작동한다고 여겨지는 방식과 크게 다르지 않음
      https://news.northwestern.edu/stories/2012/09/your-memory-is...
    • 오늘날 우리가 쓰는 컴퓨팅의 거의 모든 것도 충분히 추상화되고 오류 처리가 붙어서 해킹처럼 보이지 않을 뿐, 본질적으로는 해키한 구성물인 경우가 많음
    • 왜 조밀한 임베딩 공간이 완전한 의미 보존을 할 수 있다고 직관하는지 궁금함
      내가 이해한 임베딩은 본질적으로 손실 압축에 가까움. 텍스트 요약이라면 최소한 에이전트가 그 요약이 원래 정보를 정확히 대표하는지 검증할 수 있음
  • CodeRabbit에서는 PR 점진 리뷰와 코드 변경 맥락에서의 대화를 위해 이미 이런 방식을 쓰고 있음
    봇이 실제보다 훨씬 많은 맥락을 가진 것처럼 보이게 해 주며, 큰 PR(파일 100개 이상)까지 AI 코드 리뷰를 확장하는 데 쓰는 몇 가지 요령 중 하나임
    각 커밋마다 파일별 diff를 요약하고, 다시 요약들의 요약을 만들며, PR에 커밋이 추가될 때마다 점진적으로 갱신함. 이 요약들의 요약은 PR 댓글 안에 숨겨 저장되고, 각 파일을 리뷰하거나 사용자 질문에 답할 때 사용됨
    일부 코드는 오픈소스이고, 재귀 요약에 쓰는 관련 프롬프트는 여기 있음: https://github.com/coderabbitai/ai-pr-reviewer/blob/main/src...
    [0]: coderabbit.ai

    • 프롬프트 결과를 파싱할 때 문제가 생기는지 궁금함
      그렇다면 자유 텍스트 출력을 파싱하는 대신 function calling을 써 봤는지도 궁금함
  • “코드와 스크립트는 나중에 공개”라는 단계라면, 이제는 어떤 주장도 믿기 어려움
    사실일 수도 있고 헛소리일 수도 있지만, 실험을 낮은 비용으로 재현할 방법이 없으면 이런 논문은 저자들이 이력서에 넣으려고 쓴 것으로 봄
    LLM 분야에서 “코드는 나중에 공개”라는 논문들을 6개월 넘게 기다렸지만 실제 공개될 조짐이 없음. 심지어 일부 논문은 주차 도메인으로 이어지는 깨진 링크까지 넣을 정도로 뻔뻔함
    이제 커뮤니티가 이런 미공개 코드 관행을 제대로 인식해야 할 때임

    • 맞음. 이건 코드가 많이 필요 없는 아주 단순한 아이디어라서, 정리해서 공개하는 게 어렵지 않아야 함
      예전에 비슷한 아이디어를 API 대시보드에서 프롬프트만 직접 만져 보며 실험했는데 가능성은 있었지만 API 비용만큼 가치가 있어 보이진 않았음. 아마 벡터 임베딩 방식이 훨씬 나을 가능성이 큼
  • 개인적인 사례로, 회사에는 한 시간짜리, 때로는 하루 종일 진행되는 오프라인 패널인 “Briefings”가 수천 개 있음
    각 브리핑을 성공적으로 요약했고, 지저분한 전사본이 다섯 문단짜리 요약으로 잘 정리됐음
    더 관련 있는 부분은 각 브리핑을 주제와 하위 주제로 1:N 분류했다는 점임. 주제에는 수십 개 브리핑이, 하위 주제에는 십여 개 브리핑이 묶였고, 관련 요약들의 부분집합을 다시 요약해 폭넓게 테스트했는데 LLM으로 매우 좋은 결과가 나왔음
    처음에는 이게 될지 회의적이었지만 아주 잘 작동했음. 충분히 큰 컨텍스트 창이 있었다면 이렇게 하지 않았겠지만, 다행히 문제가 되지 않았음

    • 컨텍스트 창이 커도 이 기법은 유용함
      문제를 맵리듀스처럼 쪼개는 편이 32k짜리 거대한 컨텍스트 창에 전부 밀어 넣고 한 번에 풀게 하는 것보다 훨씬 잘 된다고 봄
  • 몇 달 전 오픈소스 모델로 재귀 요약 메모리를 만들어 봤는데, 순진하게 구현하면 특정 주제에 영원히 갇히는 일이 잦았음
    어떤 조각들이 모든 요약 라운드에서 살아남기 때문임

    • 맞음. 증폭을 상당히 완화하지 못하면, 알려진 자료에 대해 수동으로 청크 크기를 조절해도 맥락이 “죽어 가는 생각”을 붙잡고 있는 모습이 놀라울 정도로 알츠하이머와 닮아 있음
    • 그뿐 아니라 이 접근은 확장되지 않는다는 점을 증명할 수 있음
      어떤 텍스트 블록이든 더 작은 텍스트 블록으로 줄이면서 정보를 하나도 잃지 않는 건 불가능함
      그게 가능하다면 무한 압축이 가능하다는 뜻이고, 어떤 데이터셋도 1비트로 줄였다가 완벽히 복원할 수 있어야 함. 하지만 그럴 수 없음
      대화를 요약으로 압축하면 반드시 일부 정보가 사라짐. 아무리 튜닝하고 접고 영리한 방법을 써도 근본적으로 정보 손실은 발생함
      게다가 이 과정은 재귀적이라 어느 순간 요약들의 묶음을 다시 요약하게 되고, 그때도 어느 정도 정보가 사라짐
      그래서 사소한 경우에는 도움이 되겠지만, 재귀 요약을 프롬프트에 넣는 건 꽤 어리석고 실제로 유용한 일을 시키면 거의 확실히 제대로 작동하지 않을 것 같음. 재귀 요약을 많이 쓰지 않을 때는 잃는 정보가 적어서 작동하는 것처럼 보일 뿐이고, 실제로 써 보면 금방 한계가 드러날 가능성이 큼
    • “나쁜 환각 체험”이나 강박 패턴이 떠오름
      트라우마나 발달 과정만으로도 인간 정신이 얼마나 쉽게 궤도를 이탈하는지 생각하면, 인간 같은 AI라는 발상이 얼마나 희망 섞인 것인지 느껴짐
    • 관련 없어 보이는 것은 잊으라고, 즉 요약에서 건너뛰라고 지시하면 됨
  • 논문이 좀 실망스러움. 기법에 대한 세부는 사실상 거의 없고, 자기들이 쓴 방법론으로는 좋은 결과가 나온다는 표만 있음
    요즘 과학에서 흔한 일이라는 건 알지만, LLM을 다루는 개발자 입장에서는 논문 가치가 거의 없음. 물론 저자들의 학계 내 명성은 조금 올라가겠고, 그게 목적이었을 가능성이 높아 보임

    • 맨 마지막 페이지를 보면 프롬프트가 있음
    • “코드와 스크립트는 나중에 공개”라고도 되어 있음
      이런 식으로 논문 몇 편 같이 써 볼까 싶음. 몇 편쯤 써야 이력서 맨 위에 “ML researcher”라는 직함을 붙일 수 있을지 궁금함
    • 단순한 주제를 과학 논문 형식에 집어넣으면서 훨씬 더 복잡하게 만든 느낌임
      예시와 프롬프트에 훨씬 더 많은 시간을 썼어야 함
  • 몇 주 전에도 비슷하게 썼지만, 사람들이 요약 부분을 너무 단순화하고 있음: https://news.ycombinator.com/item?id=37117515
    장기 기억의 가치는 사용 사례마다 미묘하게 다름
    홈 어시스턴트를 만든다면 NER로 이름을 식별하고, 그 사람에게 메시지를 보낼 때 어떤 말투를 좋아하는지, 장소와 이동 방식을 이해해야 함
    고객지원 봇을 만든다면 긴 대화로 이어진 질의나 갑작스러운 장바구니 이탈로 이어진 질의를 식별해야 함
    일반적인 요약 수준만으로도 화려한 데모는 가능하지만, 지금 정말 유용한 제품을 만들려면 한 단계 더 나아가야 함

  • 여기서 뭐가 새로운지 잘 모르겠음
    LLM 기반 채팅 기록 메모리 요약은 이미 많은 LLM 프레임워크에서 구현된 잘 알려진 기법임. 논문처럼 매 메시지마다 요약하면 큰 성능 병목이 되고 채팅 루프에 상당한 지연을 추가함
    많은 구현은 고정 크기 버퍼를 쓰고, 버퍼 밖으로 밀려난 오래된 메모리 묶음을 점진적으로 요약함. 이상적으로는 이 작업도 채팅 루프 밖에서 처리함
    오픈소스 장기 메모리 저장소인 Zep의 작성자 중 한 명이고, 우리는 요약을 이런 방식으로 구현했음
    0: https://github.com/getzep/zep

  • 기사나 토론과는 약간 비껴간 이야기지만, 짧은 메모리는 실제 한계가 맞음
    다만 GPT-4 능력에 대한 대부분의 비판은 인간에게도 똑같이, 혹은 더 강하게 적용된다고 봄
    역 튜링 테스트 상황에서 살아 있는 누군가가 자신이 GPT-4라고 나를 설득할 수 있을 것 같지 않음. GPT-4의 빠르고 정돈된 답변만으로도 인간 능력을 압도함
    심지어 인간 팀이 각 질문에 60분씩 답할 수 있어도 흥미로운 질의에 대한 GPT-4의 응답을 따라가기 어려울 수 있음. 재미있는 대회가 될 것 같음

  • 논문의 구현은 사실상 메모리 텍스트를 프롬프트 일부로 덧붙이는 방식임
    왜 컨텍스트 창 토큰을 쓰지 않는 저장·검색 시스템을 쓰지 않는지 궁금함. 예를 들어 저장할 때, 즉 사용자 프롬프트가 들어올 때 데이터를 태그로 자동 분류하고, 검색할 때는 LLM이 응답 전에 추정한 태그로 필터링하는 쿼리를 날릴 수 있음
    하드코딩된 태그 이름이나 스타일 같은 초기 규칙 몇 개만 있어도 꽤 좋은 결과가 나올 것 같다는 직관이 듦