第1章：Memory 系统为什么需要审计——SOTA 数字背后的水分
同一个 LongMemEval-S 在不同论文里跑出 24% vs 82% 的元凶；retrieval / write strategy / judge 三层不可比性；Pareto 图揭示的 build-token 与 accuracy 弱相关；为什么「看 leaderboard 决策」在 Memory 赛道是高危行为
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
- 2. 不可比性的三层来源
- 3. Build Token 投入 vs Accuracy 弱相关
- 4. 一个具体的”水分”案例：oracle 路由
- 5. 审计的最小工作量：5 个问题
- 6. 本模块给你的工具箱
- ✅ 自我检验清单
- 📚 参考资料
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-behavior2 轴分类法 → 把 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 的事实标准