Mitigating Provenance-Role Collapse in Long-Term Agents via Typed Memory Representation

Who Should Read

MemGPT, Mem0 같은 장기 메모리 에이전트를 구축 중인 개발자. 특히 멀티턴 대화에서 오래된 사실과 최신 사실이 섞이거나, 같은 엔티티를 여러 개로 중복 카운팅하는 문제를 겪고 있다면.

Core Mechanics

• 기존 메모리 시스템은 대화 이력을 평문 텍스트로 저장해서, 어디서 온 정보인지(provenance)와 그 정보의 역할(role)이 뒤섞이는 'Provenance-Role Collapse' 문제가 생긴다. 예: Joanna가 쓴 시나리오 개수를 물었을 때, 각 시점의 언급을 별개 개체로 오인해 중복 카운팅.
• MEMIR는 메모리를 7종류의 '원자(atom)'로 분류해 저장한다: 페이지(P), 스팬(S), 핸들(H), 타임(T), 피벗(V), 클레임(A), 검색뷰(R). 이 중 실제 사실로 사용할 수 있는 건 오직 클레임(A) 원자뿐.
• BM25(희소 검색)와 BGE-M3(밀집 검색)를 동시에 돌려 이질적인 검색 결과를 클레임 중심의 'candidate bundle'로 합쳐준다. RRF(Reciprocal Rank Fusion)로 랭킹 신호를 통합.
• Cross-encoder(bge-reranker-v2-m3)로 bundle을 재랭킹한 뒤, LLM 셀렉터가 최종 답변에 쓸 bundle을 direct/support 역할로 구분해 선택한다.
• 증거가 불충분하면 '불충분한 증거' 응답을 반환하도록 강제해서 근거 없는 생성(hallucination)을 줄인다.
• 복잡한 멀티홉 추론의 최종 품질은 MEMIR 구조보다 backbone 모델 능력에 여전히 의존한다. MEMIR는 메모리 접근/조직화를 개선하는 것이지, 추론 자체를 대체하지는 않는다.

Evidence

• LoCoMo 벤치마크에서 GPT-4.1-mini 기준 Single-hop F1 59.60으로 2위 SimpleMem(57.70) 대비 +1.9p, Temporal Judge 84.60으로 2위 SimpleMem(80.70) 대비 +3.9p 달성.
• LoCoMo GPT-4.1 기준 Single-hop F1 62.20으로 2위 SimpleMem(55.80) 대비 +6.4p, Temporal Judge 86.30으로 최고 성능 달성.
• BEAM-100K(100K 토큰 히스토리) 벤치마크에서 평균 Judge 48.26으로 2위 SimpleMem(40.68) 대비 +7.58p. 특히 Contradiction Resolution(CR) 32.30으로 2위 SimpleMem(20.60) 대비 +11.7p.
• Ablation 실험에서 클레임 원자 제거 시 모든 카테고리 성능 하락, Type-Constrained Projection 제거 시 특히 Temporal/Multi-hop 성능이 크게 감소해 각 컴포넌트가 독립적으로 기여함을 확인.

How to Apply

• 장기 대화 에이전트에서 메모리를 저장할 때, raw 텍스트 덩어리 대신 '클레임(사실 단위)'과 '증거 스팬(원문 근거)'을 분리해서 저장하라. 클레임만 사실로 쓸 수 있고, 스팬은 클레임의 근거로만 사용하면 출처 혼용 문제가 줄어든다.
• 검색 결과를 그대로 LLM에 넘기는 대신, 검색된 스팬/핸들/피벗을 해당 클레임으로 '투영(projection)'한 뒤 bundle로 묶어서 넘겨라. 동일한 사실을 여러 검색 경로에서 중복으로 가져오는 문제를 줄이고, 오래된 사실 vs 최신 사실 충돌을 명시적으로 다룰 수 있다.
• 증거가 부족할 때 LLM이 억지로 답을 만들어내는 걸 막으려면, fact interface에 충분한 evidence가 없으면 'insufficient evidence'를 반환하도록 시스템 프롬프트에 명시하라. MEMIR의 Provenance-Scoped Utilization 단계를 단순화한 형태로 지금 바로 적용 가능.

Code Example

# MEMIR의 Claim Writing 프롬프트 핵심 구조 (간소화 버전)
# 실제 논문 Appendix B.3 기반

CLAIM_WRITER_PROMPT = """
당신은 대화 페이지에서 장기 메모리용 클레임(Claim)을 추출합니다.

## 규칙
- 클레임은 나중에 단독으로 검색되어도 이해 가능한 '사실 문장'이어야 합니다.
- 클레임은 반드시 원문 스팬 ID를 근거로 가져야 합니다 (support_span_ids).
- "said", "asked", "shared" 같은 발화 행위 자체를 클레임으로 쓰지 마세요. 기저 사실을 쓰세요.
- 페이지당 최대 {max_claims}개.

## 입력
페이지 텍스트:
{page_text}

스팬 목록 (id: 텍스트):
{spans}

## 출력 형식 (JSON만 반환)
{{
  "units": [
    {{
      "unit_text": "Joanna는 2023년에 첫 번째 시나리오를 완성했다.",
      "support_span_ids": ["span_003", "span_004"]
    }}
  ]
}}
"""

# Provenance-Scoped Utilization: 증거 부족 시 hallucination 방지
ANSWER_GENERATION_PROMPT = """
아래 fact interface를 기반으로 질문에 답하세요.
증거가 질문을 답하기에 불충분하면 "insufficient evidence"라고만 답하세요.
절대 fact interface에 없는 내용을 만들어내지 마세요.

질문: {query}

Fact Interface:
{fact_interface}

답변:
"""

Terminology

Related Papers

• Retrying vs Resampling in AI Control

  Claude Code처럼 의심 행동을 막고 재시도하는 방식이 오히려 공격자에게 힌트를 줘서 더 위험할 수 있다는 연구.

• Push Your Agent: Measuring and Enforcing Quantitative Goal Persistence in Long-Horizon LLM Agents

  LLM 에이전트가 '100개 찾아줘'를 실제로 100개 찾을 때까지 멈추지 않게 만드는 방법과 벤치마크.

• CoSPlay: Cooperative Self-Play at Test-Time with Self-Generated Code and Unit Test

  Ground Truth 없이도 코드와 Unit Test가 서로 평가하며 함께 품질을 높이는 추론 시간 최적화 프레임워크

• Multi-Stream LLMs: new paper on parallelizing/separating prompts, thinking, I/O

  현재 LLM이 입력·사고·출력을 순차적으로만 처리하는 구조적 한계를 지적하고, 각 역할을 별도의 병렬 스트림으로 분리해 동시에 처리할 수 있는 Multi-Stream 방식을 제안한 논문이다. 에이전트의 효율성·보안·모니터링 가능성을 모두 개선할 수 있다는 점에서 주목받고 있다.

• HarnessAPI: A Skill-First Framework for Unified Streaming APIs and MCP Tools

  FastAPI HTTP 엔드포인트와 MCP 도구를 하나의 폴더에서 자동으로 동시에 만들어주는 Python 프레임워크

• Launch HN: Runtime (YC P26) – Sandboxed coding agents for everyone on a team

  엔지니어링팀뿐 아니라 마케팅, 영업, 지원팀까지 누구나 샌드박스 환경에서 coding agent를 안전하게 쓸 수 있게 해주는 인프라 플랫폼으로, YC P26 배치 스타트업이 런치했다.

Related Resources

• https://github.com/langchain-ai/langmem