第1章：Memory 系统为什么需要审计——SOTA 数字背后的水分

LongMemEval-S 是 2024 年 ICLR 接收的 long-term memory benchmark，500 题、6 能力类、~115K token 干扰。一篇 2026 年的 Memory 论文宣称”在 LongMemEval-S 上达到 82% acc，比 zero-build baseline 提升 38 pp”。同年另一篇论文在同一个 benchmark 上的最佳成绩只有 54%，再一篇只有 24%。它们用了同一个数据集、同一个评测脚本，结果差 30 个百分点。这不是模型差异，这是评测口径、retrieval pipeline 强度、judge 实现、是否使用 oracle 路由叠加出来的不可比性。本章把这层水拆开给你看，让你下次再读 Memory 论文时，第一反应不是”哇 SOTA”，而是”等一下，它的 baseline 是怎么算的”。

1. 一张图看穿不可比性：LongMemEval-S 跨论文 Pareto

把 9 篇 2024-2026 年公开报告 LongMemEval-S 数字的 Memory 系统，横轴画 build phase 消耗 token（每 conversation），纵轴画 accuracy：

acc (%)
  ^
  |                                ⭐ Memori (~82%, 0.6M build tokens)
80|                          ⭐ EMem
  |
70|                    ⭐ LightMem
  |              ⭐ MemoryOS
60|        ⭐ Mem0          ⭐ A-Mem (~62%, 1.26M)
  |
50|  ⭐ zero-build retrieval (~54%, 0 build tokens)
  |
40|
  |
  +------------------------------------------------> build tokens
   1K       10K      100K     1M      10M

🍎 直觉：横跨 162× 的 build-phase token 投入，对应的 accuracy 拟合曲线只抬升约 3.6 pp——一个对数拟合就能告诉你，单纯把 build phase 做”更聪明”边际收益极小。

但这张图最关键的信息不是”Memory 没用”——而是：

🌟 关键观察：同一个 LongMemEval-S 上，跑 zero-build retrieval（hybrid + bge-large）的强基线已经能上 50%+。一些”号称 SOTA”的系统给出的不是”绝对 acc”上的进步，而是”相对它们自己挑选的弱 baseline”的进步。读者需要的是 paired comparison against a strong common baseline，不是绝对数字。

2. 不可比性的三层来源

把”为什么同一 benchmark 跑出 30 pp 差距”拆成三层：

2.1 Retrieval Pipeline 强度差异

论文	embedder	稀疏检索	reranker	top-K	备注
论文 A	`all-MiniLM-L6-v2`	❌	❌	5	报告 24%
论文 B	`bge-large-en-v1.5`	BM25 + RRF	bge-reranker-base	10	报告 54%
论文 C	OpenAI `text-embedding-3-large`	BM25 + RRF	rerank API	12	报告 82%

仅仅 retrieval 这一层就能解释 ~30 pp 的差距——这与 Yuan et al. 2026 的 “retrieval 解释 ~20 pp、write strategy 仅 ~3-8 pp” 的结论一致。

2.2 Judge 实现差异

LongMemEval-S 官方提供了每个 ability 类别的 judge prompt，但许多论文：

用自己的”语义相似”judge（GPT-4 二判 yes/no）
用 BLEU / ROUGE / token-F1 替代官方 judge
用同一个 LLM 既生成又判答（self-bias）

⭕ 审计提示：第一时间打开论文的代码仓 eval.py，确认它调用的是不是官方 judge。如果没有公开 eval 代码，论文的绝对数字几乎不可信。

2.3 是否使用 Oracle 路由

LongMemEval-S 每条 QA 标了 question_type（multi-session / temporal-reasoning / single-session-* / knowledge-update）。部分论文把这个标签直接喂给 memory 系统，让 memory 知道”这是一个时间推理题，去时间索引里找”。这是 oracle access。

如果作者没声明、读者没看代码，oracle 路由可以悄无声息地多偷 5-15 pp。

3. Build Token 投入 vs Accuracy 弱相关

把 9 个公开系统拟合：

acc(%) ≈ 50.2 + 1.3 × log10(build_tokens / 1K)

意味着：

build tokens / conversation	拟合 acc
1K（最小投入）	~50.2%
10K	~51.5%
100K	~52.8%
1M	~54.1%
1.6M（A-Mem）	~54.4%

🧠 核心洞察：把 build phase 从 1K 加到 1.6M（1600 倍投入）只换来 ~4 pp 拟合上的提升。Memory 这条赛道的边际收益正在快速衰减——这本身就是审计 / 负结果方法论应当出现的强信号。

更重要的是：上面这条拟合线是跨论文的，因此混杂了不同的 retrieval 强度、不同的 judge、不同的 oracle 路由水平。控制掉这些混杂之后，build phase 的边际收益可能更接近 0——这是模块第 4 章预注册配对评测要解决的问题。

4. 一个具体的”水分”案例：oracle 路由

来看一段真实的代码（出自一篇 2026 公开 Memory 系统）：

# 摘自某 2026 Memory 系统的 query 入口
def query(self, question, question_type=None):  # ← 注意这个参数
    if question_type == "temporal-reasoning":
        chunks = self.temporal_index.retrieve(question, k=5)
    elif question_type == "multi-session":
        chunks = self.cross_session_summary.retrieve(question, k=3)
    else:
        chunks = self.default_retriever.retrieve(question, k=10)
    return self.llm.answer(chunks, question)

如果 evaluation 脚本写：

for qa in benchmark:
    pred = system.query(qa["question"], question_type=qa["category"])  # ← oracle

那这就是 oracle question_type routing——论文里报告的 acc 是知道答案类型情况下的上限。读者如果不看代码，只读论文文字”the system adaptively routes to the appropriate retrieval channel”，根本看不出问题。

⭕ 诚实的写法（取自模块五 Agent-Memory 实证论文）：

“Artifact type is selected from the benchmark-provided question_type label, giving our trigger module oracle access. This favors our condition; we report it as upper-bound.”

🌟 这一段坦白本身就是论文质量的强信号：愿意暴露 oracle 设定 = 愿意承认结果的局限性 = 可信度 +1。

5. 审计的最小工作量：5 个问题

下次拿到一篇 Agent Memory 论文，先回答以下 5 个问题：

#	问题	在哪里找	红灯阈值
1	baseline 用的是 zero-build retrieval 还是被故意调弱的版本？	论文 §Experiments 或代码 `baseline.py`	baseline acc 比公认强 baseline 低 >5 pp = 红灯
2	retrieval pipeline 是 dense-only 还是 hybrid + rerank？	代码 `retriever.py` / 论文 method	dense-only + small embedder = 红灯
3	judge 用的是 benchmark 官方 prompt 吗？	代码 `eval.py` / `judge.py`	自定义 judge 且未做 calibration = 红灯
4	是否使用 question_type / answer_id 等 oracle 字段？	代码 `query()` / `route()`	使用且未声明 = 红灯
5	与 baseline 的 paired McNemar / TOST 报了吗？	论文 statistical analysis 段	只报 unpaired t-test 或不报 = 黄灯

3 个红灯以上：论文的 SOTA 数字基本不可信，跳过。

1-2 个红灯：值得读，但要把 paired 重做一遍。

0 红灯 + 5 报齐：罕见的合规论文，重点学。

6. 本模块给你的工具箱

后续 7 章会逐一交付：

第 2 章：write-trigger × read-behavior 2 轴分类法 → 把 11 系统按格子摆开
第 3 章：6 类 trigger primitive 的可证伪假设模板
第 4 章：预注册 + 配对评测三件套（TOST / McNemar / cluster bootstrap）+ cumulative-effect plot 防 optional stopping
第 5 章 ⭐：positive control 设计（gold-answer 注入 / extractive verbatim / oracle evidence），负结果论文的反证防线
第 6 章：跨 backbone 鲁棒性（Anthropic / OpenAI / DeepSeek / Qwen）的低成本实现
第 7 章：负结果论文的 5 种失败模式（mock-vs-prod gap / optional stopping / reversal / hidden oracle / cherry-pick）
第 8 章：端到端实战，复现一篇 4 LLM × 11 系统 atlas + C+oracle positive control 的负结果 Memory 论文

🌟 本章一句话总结：Agent Memory 赛道的”SOTA 数字”在严格审计下经常缩水 10-30 pp；学会用本模块的工具箱审计别人，也学会用同一套工具让自己写的论文扛得住别人审。

✅ 自我检验清单

不可比性来源：能说出 retrieval / judge / oracle 三层不可比的具体例子各一个
Pareto 图：能解释为什么 162× build token 投入只对应 ~4 pp 拟合 acc 提升
paired vs unpaired：能解释为什么”同一个 LongMemEval-S 上”应该用 paired 而不是 unpaired
oracle 路由：能在一段代码里识别出 question_type oracle 路由
5 个审计问题：能在 5 分钟内对一篇论文打出红灯计数
绝对 vs 相对：能解释”绝对 acc 30 pp 差距”和”配对 Δ = +0 pp” 同时成立的可能性
本模块定位：能说清本模块和模块五 Agent Memory 的差异

📚 参考资料

概念入门

模块五 Agent Memory 学习路线（前置） —— Agent Memory学习路线.md：先看 Memory 是什么
Pre-registration: A Discussion —— OSF / Center for Open Science：心理学 / 经济学领域的预注册流程，本模块第 4 章会迁移到 NLP

关键论文

LongMemEval（Wu et al., ICLR 2025）：arXiv 2410.10813 —— 单查询 long-term memory 评测的事实标准；本章 Pareto 图横坐标的来源
LoCoMo（Maharana et al., 2024）：arXiv 2402.17753 —— 多查询长对话 benchmark
Diagnosing Retrieval vs Utilization（Yuan et al., 2026）：arXiv 2603.02473 —— “retrieval 解释 ~20 pp、write strategy 解释 3-8 pp” 的关键先验
Memori（Anonymous, 2026）：arXiv 2603.19935 —— LoCoMo 上报告 81.95% F1 的代表性系统，本章 Pareto 图右上角

行业讨论

Anatomy of Agentic Memory（Anonymous, 2026）：arXiv 2602.19320 —— 与本模块互补的 empirical analysis 综述
MemOS（Li et al., 2025）：arXiv 2507.03724 —— 并行的 memory taxonomy 工作

框架文档（如适用）

bge-large-en-v1.5 模型卡 —— HuggingFace BAAI/bge-large-en-v1.5：本章”强 baseline”用的 embedder
rank_bm25 / scikit-learn TfidfVectorizer —— 稀疏检索的最小工程实现，配合 RRF 是 hybrid retrieval 的事实标准

搜索