요약
Memorilla는 문서 모음 전체를 메모리 토큰 16개로 압축해 LLM 입력에 바로 넣습니다.
유레 레스코베츠 등 스탠퍼드 연구진이 낸 논문입니다. 가중치를 고정한 LLM은 메모리 시스템이 컨텍스트 창에 넣어 준 정보만 쓸 수 있습니다. 연구진은 지난 대화나 긴 문서를 텍스트 대신 압축된 임베딩(텍스트를 숫자 벡터로 바꾼 것)으로 건네는 방법을 제안했습니다.
왜 중요한가
- 상위 문서 몇 개만 골라 넣는 RAG(검색 증강 생성)와 달리 전체 문서를 읽어, 질문과 약하게 이어진 사실도 연결할 수 있습니다.
- 긴 기록을 통째로 넣지 않고도 성능이 비슷하거나 나아서, 토큰 비용과 응답 지연을 함께 줄일 길을 보여 줍니다.
핵심 내용
- 고정된 인코더가 문서를 한 번만 임베딩해 두고, 학습된 메모리 슬롯 16개가 질문에 맞춰 저장소 전체를 읽습니다.
- Qwen3-8B 기준 8개 벤치마크 가운데 5개에서 Mem0, MemoRAG 같은 기존 방식보다 높은 점수를 냈습니다.
- FactKG에서는 문서 토큰을 108배 적게 쓰고도 정확도 84.33%로 전체 문맥 방식(80.43%)을 앞섰습니다.
- 문서 512개 기준 응답 시간은 0.74초로, 전체 문맥 방식(19.9초)보다 약 27배 짧았습니다.
- 정확한 이름처럼 원문 그대로의 세부 정보는 놓칠 수 있고, 모델마다 메모리 모듈을 따로 학습해야 합니다.
HN 반응
- 일부 이용자는 원문 대신 압축된 의미를 주입하는 방식이라 개념에 강하고 정확한 인용에 약한 결과가 자연스럽다고 봤습니다.
- 최신 모델은 전문 검색 질의만 잘 짜도 충분하다는 반론에, 음성 비서처럼 지연이 중요한 곳에서는 쓸모가 크다는 반박이 나왔습니다.
제가 제대로 이해했다면, 이건 기본적으로 RAG를 특화된 임베딩으로 만든 겁니다. 그 중간에 모델이 하나 끼어서 에이전트의 질의를 받아 응답을 돌려주는데, 이 응답이 실제 텍스트를 건너뛰고 메인 모델의 입력 토큰 스트림에 곧바로 주입되는 형태고요. 게다가 주입 형식은 토큰 효율이 엄청나게 높습니다. 인용할 수 있는 텍스트가 아니라 일종의 느낌(vibe)을 주입하는 셈이죠. "개념에는 강하고 인용문이나 정확한 텍스트 검색에는 약하다"는 그쪽 결과도 직관적으로 이 구조와 맞아떨어지는 것 같습니다.
저도 어제 이것과 관련된 연구를 찾아보던 참이에요. 이미지, 텍스트, 소리를 다루는 멀티모달 모델이 있는데, 왜 텍스트와 그래프를 다루는 멀티모달 모델은 없을까요? 외부 도구 없이도 컨텍스트 안에 텍스트보다 효율적인 형식으로 기억을 저장할 수 있을 텐데요.
동의합니다
RAG와 다른 점이 하나 더 있는 것 같습니다. 문서 벡터를 재순위화(reranking)해서 상위 5개 정도만 가져가는 대신, 이 논문은 모든 문서를 (관련도로 가중해서) 고정된 개수의 "메모리 토큰"에 섞어 넣습니다.
이 방식이 제가 RAG에서 겪던 문제, 즉 하나의 사실이 한 덩어리의 텍스트 안에 모여 있지 않은 경우를 피하는 데 도움이 되는 것 같습니다.
그게 정말 문제인가요? 벡터 유사도로 관련 있는 덩어리들을 찾아내야 하는 거잖아요.
하지만 RAG의 하드 컷오프를 통과한 문서들 안에서만 그렇죠. 관련된 스탠퍼드 사이트 https://memory.stanford.edu/ 에 이 부분 설명이 있어요("How MEMORILLA differs from RAG"를 보세요).
정확도와 토큰 사이의 절충안을 제시하는 것 같습니다. 토큰을 그만큼 많이 쓰지 않아도 꽤 괜찮은 정확도가 나오지만, 최고 수준은 아니라는 거죠. 다만 많은 상황에서 사람들은 토큰보다 정확도를 훨씬 더 신경 쓴다고 생각합니다.
프런티어 모델이 운전대를 잡으면 의미 기반(semantic)이 어휘 기반(lexical)과 거의 같아지는 걸 느끼고 있습니다. 대규모 문서 집합을 다룰 때는 여전히 전문 검색 엔진(full text search)이 가장 설득력 있는 방법이고요.
마리오 64 롬 덤프를 리버스 엔지니어링해서 제 토스터 오븐에서 돌아가게 만들 수 있는 생성 모델이 있는데, 의미 기반이니 임베딩이니 하는 고민은 솔직히 이해하기 어렵습니다. 이런 모델은 Lucene을 비롯한 FTS 쿼리 문자열을 알아서 잘 짜기 때문에, 순수하게 어휘 기반인 시스템 위에서도 사실상 의미 검색을 얻게 됩니다.
논문에 나온 것 같은 시스템은 음성 기반의 빡빡한 대화 루프를 다룰 때 더 흥미로워집니다. 지연 시간에 민감한 작업이 아니고 말씀하신 검색을 하네스가 대신 실행해 주면 되는 상황이라면, 이런 최적화나 메모리 구조를 탐구할 가치는 거의 없습니다(임베딩을 쓸 이유도 거의 없고요). 하지만 어제 나눈 이야기를 모델에게 물었을 때, 모델이 추론하고, 도구를 호출하고, 결과를 읽고, 다시 추론하는 걸 기다리고 싶지는 않습니다. "확인해 볼게요"라는 말도 금방 질립니다. 논문에서는 검색 시간이 19초에서 0.79초로 줄어 27배 빨라졌다고 했는데, 음성 기반 개인 비서에는 아주 가능성이 큰 결과입니다.
속도 향상에는 또 다른 요소가 있습니다. 바로 의미 압축입니다. 가져온 토큰에 비해 임베딩 벡터 하나에 더 많은 내용을 담을 수 있다는 거죠.
에이전트의 도구 검색에 대한 말씀은 맞습니다. 다만 두 가지가 함께 숨어 있다는 점을 말씀드리고 싶었습니다.
맞는 말씀입니다. 다만 우리에게는 에이전트식 토큰 주입(말씀하신 프롬프팅), 임베딩 주입(memorilla), 그리고 지속 학습(continual learning)이 있다는 점도 생각해 보세요.
첫 번째는 모델이 추론하는 내용 정보를 갱신하고, 마지막은 모델이 어떻게 추론하는지를 갱신합니다.
이 둘은 아주 다릅니다.
제가 이해하기로 memorilla는 그 중간에 있습니다. 토큰이 아니라 복잡성을 그대로 지닌 임베딩 벡터를 주입하고요. (의미) 압축 효과가 상당한데, 제 생각에는 이 점이 아주 흥미롭습니다.
의미 임베딩은 전체 그림의 일부일 뿐이라고 생각해요. 하이브리드 시스템이 분명히 필요하지만, 텍스트 기반 접근만으로는 정말 형편없어요. 제 에이전트들은 세션이 바뀔 때마다 같은 실수를 되풀이하거든요. 우선 세션이라는 개념부터 없애야 해요.
기억을 하나의 모달리티로 본다니 정말 멋진 발상이네요!