MemCompile은 장기 기억 검색과 근거 편집을 분리한다

무엇인가

이 논문은 장기 대화 기억에서 답에 필요한 근거가 여러 턴과 세션에 흩어져 있고 이후 상호작용으로 수정될 수 있다는 문제를 다룬다. 기존 시스템은 구조화 메모리와 적응형 검색을 쓰더라도 검색되거나 확장된 단위를 리더에 직접 넘기는 경우가 많아, 메모리 주소 지정과 근거 제시가 결합되고 최종 문맥이 중복되거나 불완전해진다. 저자들은 이를 쿼리 조건부 근거 편집으로 정식화하고, 제한된 근거 예산을 어떤 원본 대화 소스에 줄지와 그 소스의 근거를 리더에게 어떻게 표현할지를 분리해야 한다고 주장한다. 원자적 클레임은 검색은 쉽지만 인과관계나 같은 소스의 형제 사실을 빠뜨릴 수 있고, 원문 턴은 세부를 보존하지만 인사말 같은 잡음을 다시 넣으며, 계층 노드는 탐색 단위로는 유효해도 답 생성에 필요한 세밀도와 맞지 않는다. 소스 수준 경계가 없으면 여러 클레임이나 검색 채널이 같은 원본에 예산을 반복 배정하는 문제도 생긴다.

어떻게 동작하나

MemCompile은 Address Plane과 Evidence Plane으로 나뉜다. 각 원본 대화 턴은 발화자, 세션, 상호작용 시간, 원문 내용, 안정적 식별자를 가진 불변 SourcePacket이 된다. Address Plane은 LLM으로 각 SourcePacket에서 독립적 사실 클레임을 추출하되 직전 턴을 사용해 지역 지시어를 해소하고, 클레임 텍스트, 턴 식별자, 발화자, 세션, 시간, 인물·키워드 집합, 사건 시간·상호작용 시간, 토큰 수, SourcePacket 외래키를 담은 설명자를 만든다. 이 설명자들은 토큰 용량과 항목 용량 제약을 가진 Cell에 배치되며, 배치 점수는 메타데이터 지역성, 키워드·인물·시간 일관성, 극성 불일치, 용량·엔트로피 압력을 조합한다. 새 Cell 생성은 0.65+n_i/B_C의 확장 압력을 후보로 갖는다. 쿼리 시에는 열린 Cell과의 중복을 벌점으로 주는 한계 이득 g(c|O_t,q)=u(c,q)[1-λ_R J(M_c,M_O_t)]-κ_open으로 Cell을 탐욕적으로 열고, λ_R=0.45와 열기 비용, 최대 6개 Cell 제한 같은 중단 조건을 적용한다.

무엇과 다른가

주소 후보는 다채널로 모인다. BM25가 전체 원자 설명자를 정렬해 상위 96개 어휘 후보를 제공하고 상위 8개는 Cell 라우팅 시드로도 쓰인다. 열린 Cell의 클레임과 BM25 결과를 합친 뒤 각 후보를 클레임 용어, 키워드, 인물, 시간 일치, BM25 점수의 가중합 r_i로 재정렬한다. 병렬로 전체 패킷에 대한 밀집 의미 검색을 수행해 K_D=40개의 패킷 제안을 얻는다. 핵심은 Source-Normalization Boundary로, 모든 클레임을 그 SourcePacket 외래키로 해소해 같은 패킷의 후보를 하나로 접는다. 패킷 점수는 그 패킷으로 해소된 클레임 중 최대 r_i가 된다. 이 다대일 전환이 검색 키의 다중성과 근거의 양을 분리하므로, 한 턴에 여러 성공적 주소가 생겨도 예산 항목은 하나가 된다.

어떻게 쓰나

Evidence Plane은 정규화된 패킷 후보를 제한된 일관 문맥으로 바꾼다. 닫힌 풀 listwise 스케줄러가 쿼리와 정규화 풀을 받아 K0=10개의 상보적 SourcePacket을 고르고, 각 후보는 불투명 라벨, 대화 식별자, 발화자, 기록 날짜, 원문 내용으로 렌더링된다. 스케줄러는 직접 답을 담은 패킷을 우선하되 관계형·시간형·비교형·목록형 질문을 위한 상보 패킷을 유지하도록 지시받고, 반환된 라벨은 닫힌 풀과 검증된다. 이어서 기준 앵커 집합 A0와 밀집 검색 풀 D_q의 합집합 W_q에 listwise 리랭커를 적용하고, 상위 K_R=5 위치를 살펴 이전에 선택되지 않은 패킷을 최대 K_Δ=2개만 추가한다. 최종 패킷 시퀀스의 각 패킷에 대해 그 패킷에서 유래한 보존 클레임 전체를 시간순 번들로 묶고 패킷 타임스탬프와 함께 스케줄 순서대로 연결해 리더 문맥을 만든다. 이 편집은 원문 재구성이 아니라 보존된 설명자 집합에 대해 완전하다.

전제와 한계

실험은 LoCoMo와 LongMemEval-S에서 진행됐다. LoCoMo는 10개 대화, 대화당 약 600턴과 평균 16K 토큰이고, LongMemEval-S는 500개 질문이 각각 약 115K 토큰 역사에 묻혀 있다. 비교 대상은 MemoryBank, A-Mem, Mem0, MemoryOS, LightMem, AnchorMem, xMemory, SimpleMem, AtomMem 등이며, 지표는 토큰 수준 F1, BLEU-1, Judge 정확도와 구축·검색·생성 토큰 비용이다. 생성 구성요소는 gpt-4o-mini temperature 0, 최대 2048 토큰, 밀집 검색은 text-embedding-3-small, Judge는 gpt-5-nano를 사용했다. LoCoMo에서 MemCompile은 단일 홉·다중 홉·시간 질문 모두 1위이며 전체 F1/BLEU/Judge 55.94/48.65/80.52를 기록했다. 가장 강한 베이스라인 대비 다중 홉 Judge는 8.69%p, 시간 질문 Judge는 7.79%p 높다. Mem0 대비 Judge는 14.35점 높으면서 토큰은 51.7% 적고(26.72M 대 55.30M), AtomMem 대비로는 토큰을 8.8%만 더 쓰면서(26.72M 대 24.55M) 전체 Judge가 10.01점 높다. LongMemEval-S에서는 Mem0 대비 시간 추론 Judge가 24.1%p, 단일 세션 어시스턴트 Judge가 50%p 향상됐다.

분석은 병목을 분리한다. 고정 후보 예산에서 Bounded Cell 배치는 단일 홉 재현율을 5.13%p, 다중 홉을 3.42%p, 시간을 1.71%p, 오픈 도메인을 2.78%p 올렸다. Cell 라우팅 후보를 제거하고 하위 스케줄러와 편집 파이프라인을 고정하면 최종 재현율 81.54%로 3.96%p 떨어지고 F1 52.31, BLEU-1 45.14, Judge 77.53%가 됐다. Top-20 순위는 20개 히트를 갖지만 평균 14.60개의 서로 다른 소스만 포함했고, 같은 소스 히트가 명목 예산의 27.02%를 차지하며 질문의 97.27%에 영향을 줬다. 일반 텍스트 중복 제거는 거의 개선이 없었지만 SourcePacket 정규화는 Gold Recall을 3.35%p 올렸다. 상보 스케줄링은 서로 다른 소스 수를 9.988로 유지하고 DBR을 0으로 두면서 Gold Recall을 51.91%에서 80.84%로 28.93%p 올렸다. 같은 SourcePacket을 고정한 리더 표현 실험에서는 단일 대표 클레임이 Judge 57.01%, 원문 SourcePacket이 75.32%, 전체 클레임 번들이 80.52%로, 근거 표현 자체가 별도 설계 문제임을 보였다.

절제 실험에서 A0-A3는 앵커 구성과 프런티어 확장의 효과를 분리했고, 약한 결정론적 앵커일수록 확장이 더 크게 보상하며 상보 패킷 스케줄링은 더 강한 초기 근거 집합을 만들어 확장 의존을 줄였다. A4와 A5는 BM25가 단독 경로로 더 강하지만 Cell 유래 후보를 더하면 비중복 근거가 생겨 전체 파이프라인이 좋아짐을 보였다. A6는 구조화된 쿼리 의도가 소스 커버리지보다 근거 우선순위화에 주로 기여함을, A7은 밀집 코사인 Top-10 SourcePacket을 바로 클레임 번들로 제시하는 것이 컴파일 파이프라인에 못 미침을 시사한다. 개발자 관점에서는 대화형 RAG나 에이전트 메모리에서 검색 히트를 그대로 프롬프트에 넣지 말고 원본 소스 ID로 정규화해 예산 중복을 막고, 소스 선택과 리더용 근거 편집을 분리해 평가해야 한다는 실무적 함의가 있다. 특히 소스 재현율과 답변 품질을 별도로 측정하면 검색 실패와 근거 제시 실패를 구분할 수 있다. 저자들이 밝힌 한계는 평가가 두 대화형 메모리 벤치마크와 독점 LLM에 한정된다는 점, 더 넓은 도메인과 오픈 모델 재현이 향후 과제라는 점, 전체 토큰 소비를 더 최적화할 여지가 있다는 점이다.