北京
“我决定不掩饰这一点，也不辩解，而是告诉你们这一切为什么会发生，以及这种准确性的代价是什么。然后让你决定你更愿意接受哪一边，因为对很多人来说，答案并不是那个显而易见的。”
这是一位研究人员在对比两种记忆架构时给出的开场白。一边是 Mem0，它会在每次写入记忆时调用大语言模型，存储蒸馏后的结果；另一边是 RE‑call，从不调用任何大模型，只保存原始的对话轮次。两者在同一个基准上的分差，正是那条“单行决策”撕开的裂缝。
一道单行决策，解释所有得失
把架构差异浓缩成一句话：Mem0 写入记忆时会调用一个 LLM，然后把精炼后的结果存下来；RE‑call 则从不触发任何大模型，只保存用户的原始轮次。就是这“一句话”决定了后续的一切——性能的赢面、丢失的部分、账单的高低，以及数据的流向。
在 BEAM 基准 100 万 token 的测试桶里，Mem0 在研究者最关心的类别上拿到了更好的分数。表现最清楚的，是名为“时间推理”的类别。RE‑call 在这里只得到 0.408，而 Mem0 的得分是 0.567。两者的差距不止于数字本身，更在于出错的方式。
一样的“日期差”问题，完全不同的出错模式
“时间推理”的 7 道严重丢分题中，只有一道是因为检索为空，其余 5 道全都给出了确信的错误答案。它们全是同一类问题：“A 事件和 B 事件之间隔了几天？”每次出错的根源都是模型用错了日期的实例——把修订日期、随口提到的日期和原始截止日期混在一起。
Mem0 之所以能做对，是因为它的记忆里只有精炼后的一行：“Sprint 1 截止日期：2024 年 2 月 15 日”。而 RE‑call 里的同一个日期散落在多个场景中：它被设定的那一刻、被修改的那一刻、被人不经意提起的那一刻。没有任何检索端的低成本改动能复现这种“蒸馏出来的干净”。项目文档已经把它列为已知局限，而非待解决的任务。
新近的未必是对的，最简单的修复也失效了
尝试过那条最直接的补丁：优先使用最新出现的日期实例。但这条路走不通。有些正确的日期恰恰是更老的那个——最初的截止日，而不是后来的修订版。这直接把所有依赖“最新即正确”的启发式规则堵死，也成了整个项目中第三条反对“最新即赢”的独立证据。
也就是说，在这一类别上，采用 LLM 在写入阶段做蒸馏，本身就是更优的架构。这不是某种可以事后弥补的检索侧缺陷。
重新排序能拉一把，但未必是全部答案
需要补充一个重要的测量条件：前述 0.408 的分数是在关闭重新排序的情况下测得的。项目使用的 BEAM 框架支持 --reranker 参数，但那次运行没有启用。而重新排序恰好是整个项目中检索提升最大的手段——在 LOCOMO 数据集上把 hit@5 从 0.671 拉到 0.777，连先前预测无法触及的多跳类地板都跟着提升了。这意味着 0.408 只是默认设置下的成绩，并非最优配置。
但研究者也补充说，重新排序不太可能把整件事扭过来。因为诊断结果不属于排序失效。在 7 道严重丢分的题中，多数是“答错了”而不是“没找到”。问题的病根并不在排序阶段，而在记忆本身的结构上。
上一次他预测某个类别不会从重新排序中获益时，结论被现实推翻了。所以这一次他选择不下判断：“如果我现在去猜重排序会怎么改变这一项，那就是拿上次犯过的错再犯一遍，只不过这次挂在数字更大了。”
为什么你仍然会想要一个“输掉”的东西
把两张亮出来的账单放在一起：Mem0 赢了时间推理，但每一段记忆都要调用一次大模型；RE‑call 在这里输了，但它的写入端是零开销的，而且所有数据都停留在原始对话轮次中。一个用准确度换成本和控制权，一个用局部精度换完整的原始记录。哪一边更划算，取决于你的问题域、你的预算和你对“记忆应该长什么样”的理解。
这篇论文做的不是宣布某个架构胜出，而是拉出一张完整的得失清单。在 LLM 蒸馏确实更优的窄口上，它承认边界；在检索增强仍有空间的宽面上，它保留测量空白。对于所有在“要精度还是要控制”之间徘徊的系统设计者来说，清单本身比一个简单的赢家更有分量。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
