LSREP：AI答对不等于记住

2026年9月15日，一项名为 LSREP 的长期记忆评测协议公开，试图纠正对话式 AI 评测中一个长期存在的问题：系统在最后答对一道题，并不代表它真的在整个使用过程中正确地记住了信息。

**LSREP 是一种通过按时间顺序重放对话、重建记忆状态，并在多个检查点反复提问来评估长期记忆的协议。**它不只看最终答案，而是追踪一条记忆从写入、强化、修订、老化到可能被遗忘的全过程。

这项工作的价值主要不在配套系统 ICE v2，而在于它提出了一套更接近真实使用方式的测试框架。更值得注意的是，作者没有把论文写成一篇为自家架构背书的宣传稿：ICE v2 在公开 LongMemEval 对比中明显输给了简单的纯向量 RAG，部分设计甚至没有真正运行起来。

截至2026年11月1日，论文报告的结果仍对应 GitHub 中冻结的 v2-paper-eval 标签，而不是已经继续迭代的主分支版本。把评测快照与当前代码分开，是理解这些数据的前提。(github.com)

长期记忆评测的问题，不只是题目太简单

**传统长期记忆评测通常是终点问答：先给系统一批历史对话，再问它几个问题。**这种方法能够测试检索和回答能力，却很难判断记忆系统在中间发生了什么。

例如，一位用户在第一次对话中说：

• 项目 Atlas 使用 SQLite；
• 两周后改用 PostgreSQL；
• 随后又要求保留最初选择的决策记录。

如果测试只在最后询问“Atlas 现在使用什么数据库”，模型回答 PostgreSQL 就能得分。但这个答案无法证明系统是否正确处理了三个不同问题：它有没有记住最初的 SQLite，有没有在决策更新后停止把 SQLite 当作当前事实，以及能不能在用户询问历史决策时重新找到 SQLite。

**长期记忆不是一个静态键值对，而是一组随时间变化的状态。**事实会被替换，偏好会逐渐形成，任务会完成或取消，同一个问题在不同时间点可能拥有不同的正确答案。

这也是 LSREP 与普通终点测试最关键的区别：它评估的是记忆状态如何演化，而不是数据库里是否碰巧存在一段相关文本。

LSREP怎么做“状态回放”

**状态回放是按照原始时间顺序重新输入对话，并在预先定义的检查点观察系统当前记忆状态。**每到一个检查点，评测框架只允许系统看到该时刻之前发生的内容，随后运行衰减、聚类、总结、知识更新等生命周期任务，再提出当前有资格出现的问题。

LSREP包含五个核心环节：

1. 顺序回放：对话必须按时间顺序进入系统，不能一次性把完整历史塞给模型。
2. 生命周期调度：在检查点之间运行衰减、强化、归档、反思或合并等机制。
3. 重复探针：同一个问题会在后续检查点再次出现，用于观察记忆质量如何变化。
4. 动态参考答案：新证据改变事实后，标准答案也必须更新，而不是从头到尾固定不变。
5. 机制忠实度审计：系统声称启用的图检索、程序性记忆或衰减机制，必须证明实际执行并影响了最终上下文。

**探针是用于检查特定记忆能力的测试问题。**一个探针可以关注当前事实、旧版本事实、跨会话信息，或者某项长期偏好；它还需要记录首次可回答的时间点，防止系统利用未来信息提前作答。

动态参考答案尤其重要。假设 T1 时刻 Atlas 使用 SQLite，T2 时刻改用 PostgreSQL，那么“现在使用什么数据库”的正确答案应在 T2 后更新为 PostgreSQL；但“最初选择了什么数据库”的答案仍应是 SQLite。普通静态问答数据集很容易把这两类问题混在一起。

LSREP还要求冻结代码版本、模型身份、参数、随机策略和时间设置。这样做看似繁琐，却能避免长期实验中最常见的问题：几百轮对话跑到一半，模型、提示词或检索配置已经悄悄变化，最后得到的数字无法解释。

这次实验到底测了多长

**LSREP此次实例化覆盖1,985轮对话、219个不同探针和1,211次“探针—检查点”观察。**整个过程包含52个检查点，总对话量约198万估算 token，数据来自同一位用户的四段长期真实工作记录。(github.com)

| 数据集 | 主要场景 | 对话轮数 | 观察次数 | 检查点 | 主要压力 | |---|---:|---:|---:|---:|---| | A | 创意写作 | 290 | 173 | 10 | 人物与情节连续性 | | B | 长篇世界观构建 | 1,119 | 638 | 20 | 超长距离检索、实体演化 | | C | 技术规划 | 325 | 154 | 10 | 单轮信息极密集、超长文本 | | D | 学术与个人规划 | 251 | 246 | 12 | 决策更新、个人偏好 | | 合计 | — | 1,985 | 1,211 | 52 | — |

**这组数据的纵向密度比样本数量更有价值。**219个探针被反复测试，意味着研究者可以画出某条记忆的质量曲线，而不是只得到一次性的正确或错误标签。

但这组数据也有明显边界：所有私人对话都来自作者本人，原始语料和探针没有公开。它能够说明协议在一个复杂个人历史上的可行性，却不能证明结果能推广到不同语言、职业、文化和使用习惯的人群。

ICE v2不是模型，而是一层记忆中间件

**ICE v2 是部署在聊天客户端与语言模型之间的本地优先记忆中间件。**它本身不生成答案，而是负责判断当前请求需要什么记忆、从多个存储中检索信息、融合结果，并在 token 预算内组装提示上下文。

ICE v2使用的记忆结构比普通向量数据库复杂得多：

| 记忆组件 | 保存内容 | 主要检索方式 | |---|---|---| | 情节记忆 | 原始对话、摘要、衰减分数、访问次数 | BM25与向量检索 | | Codex图谱 | 实体、属性、关系及有效时间 | 图遍历与枚举回退 | | 程序性记忆 | 用户反复表现出的行为模式 | 意图门控后的向量检索 | | 文档记忆 | 外部导入的文档分块 | 向量检索 | | 持久记忆槽 | 人设、偏好、项目背景、待办事项 | 每次请求直接加入上下文 | | 上下文聚类 | 按主题组织的对话片段 | 缩小情节记忆搜索范围 |

检索结果通过 RRF，也就是倒数排名融合进行组合。RRF不直接比较不同检索器的原始分数，而是根据每条结果在各个列表中的排名计算融合分数，这能缓解 BM25 分数与向量相似度不在同一尺度的问题。

ICE v2还使用动态 token 预算限制进入提示词的记忆量。这个设计在极端高密度数据集上发挥了作用：不设预算的向量基线会把30个超长片段全部塞进上下文，最终大量请求失败；ICE则会主动裁剪候选内容。

复杂系统没有赢过简单基线

**在三个普通密度数据集上，ICE v2与纯向量 RAG的平均质量几乎没有差异。**ICE的平均得分为4.26，向量基线为4.25；使用未四舍五入数据后，配对差值只有+0.002，按探针轨迹聚类计算的95%置信区间为-0.148到+0.158。

这不是“表现相当”的严格证明，而是没有检测到稳定差异。置信区间同时覆盖正负值，无法排除ICE略好、略差或者没有区别。

| 普通密度结果 | ICE v2 | 纯向量 RAG | 判断 | |---|---:|---:|---| | 平均得分 | 4.26 | 4.25 | 无显著优势 | | 平均检索片段 | 20.4 | 30.0 | ICE少32.0% | | 估算提示token | 22,411 | 21,025 | ICE多6.6% | | 锦标赛第一名比例 | 30.6% | 21.2% | 不是直接胜率 | | 幻觉率 | 19.6% | 20.5% | 差距很小 |

**ICE减少了片段数量，却没有减少总提示token。**原因是它除了检索片段，还加入最近对话窗口、持久记忆槽和更复杂的指令结构，因此“检索更精简”不能直接等同于“成本更低”。(github.com)

高密度数据集C给出了完全不同的结果。ICE v2平均得分为4.33，纯向量基线只有1.23；后者有94.2%的观察被记为最低分1分。这个结果证明了有界上下文在极端长片段下的重要性，但不能证明知识图谱、衰减或路由机制分别有效，因为测试比较的是整个系统与一个不设token上限的基线。

到LongMemEval，ICE输得更直接

**在匹配设置的LongMemEval测试中，ICE v2明显输给了纯向量 RAG。**证据已筛选的Oracle阶段，ICE准确率为50.8%，向量 RAG为72.8%；加入完整历史和干扰内容的Full-S阶段，ICE为43.0%，向量 RAG为69.5%。(github.com)

| LongMemEval设置 | ICE v2 | 纯向量 RAG | ICE差值 | |---|---:|---:|---:| | Oracle | 50.8% | 72.8% | -22.0个百分点 | | Full-S | 43.0% | 69.5% | -26.5个百分点 | | Full-S多会话问题 | 21.5% | 74.4% | -52.9个百分点 | | Full-S时间推理 | 20.5% | 47.2% | -26.8个百分点 |

**ICE最大的短板是跨会话综合，而不是单纯害怕干扰内容。**它在Oracle阶段已经落后22个百分点，说明即使只提供包含答案的相关会话，系统仍然难以从多个独立会话中拼出完整证据。

ICE确实使用了更少上下文。Full-S阶段，它向回答模型提供的中位数是5个片段、2,222个输入token；向量基线则是30个片段、11,718个输入token。ICE少用了约81%的输入token，却损失26.5个百分点准确率。

这组数字只能说明质量与上下文成本之间存在取舍，不能说明ICE效率更高。要证明效率优势，至少需要在相同token预算下比较准确率，或者绘制不同预算下的质量—成本曲线；这次实验没有完成这样的预算扫描。

最有价值的结果，是查出哪些机制根本没工作

**机制忠实度审计是LSREP比常见排行榜更值得借鉴的部分。**一个复杂记忆系统包含十几个组件时，最终得分发生变化不代表每个组件都贡献了价值。

审计发现，ICE v2的程序性记忆检索存在类型绑定错误，查询触发 pgvector 运算符异常后返回空列表，因此贡献片段数量是0。文档检索共享同类问题，同时测试期间也没有导入文档；冷存储、批量摘要和历史时间线检索则没有被测试数据真正触发。

知识图谱虽然运行了，但只占有明确来源检索片段的3.3%，其实际质量收益没有得到确认。另有34.5%的来源记录无法归因到具体检索腿，这意味着系统甚至不能完全解释最终上下文来自哪里。

RRF融合是少数获得相对清晰证据的组件。单独加入BM25后，得分相对纯向量下降0.74分；随后加入RRF，得分恢复0.82分。不过这只能说明RRF修复了本次组合中未经融合的词法检索伤害，不能推导出RRF在所有检索系统里都会提升质量。

**这类审计阻止了一个常见错误：把“开关存在”当成“功能有效”。**如果一个模块因为数据库错误从未返回结果，那么消融实验中打开或关闭它都不会改变分数，接近零的差值并不代表它没有价值，而是说明实验根本没有测到它。

LSREP真正改变了什么

**LSREP把长期记忆评测从一张期末试卷，变成了持续记录的病历。**终点问答只能看到最后症状，状态回放则能看到系统何时写入错误、何时遗漏更新、何时因为衰减丢失信息，以及某个组件是否真的参与了回答。

对开发者来说，这套方法尤其适合三类系统：

• 会长期保存用户偏好、项目背景和个人历史的聊天助手；
• 会在多次任务之间积累状态的AI Agent；
• 同时使用向量库、知识图谱、摘要和规则记忆的复杂RAG系统。

LSREP目前仍不是一个可以直接取代LongMemEval的通用排行榜。它使用私人单用户历史，数据无法完整复现；探针和动态参考答案需要较高制作成本；重复观察之间并不独立，统计结果也不能直接代表不同用户群体。

但它指出的方向是对的：长期记忆系统不能只回答“最后还记得什么”，还要回答“什么时候记住的、后来是否更新、旧信息有没有被错误保留、遗忘是否符合设计，以及声称使用的机制到底运行没有”。

**ICE v2没有证明复杂记忆架构胜过简单向量检索，反而让LSREP的可信度更高。**一个评测协议如果只能产出对作者有利的结果，它更像演示脚本；LSREP主动暴露程序性检索故障、图谱收益不明和公开基准惨败，说明它至少开始具备审计工具应有的攻击性。

目前更合理的结论是：简单向量RAG仍是长期记忆系统必须击败的强基线，而不是一个可以被“图谱、多存储、衰减、路由”这些架构名词轻易淘汰的旧方案。复杂度只有在相同预算下带来稳定质量提升，或者在相同质量下显著降低成本，才值得进入生产系统。

参考来源

• LSREP论文的Hugging Face页面：包含论文摘要、发布日期和核心实验结果。
• ICE与LSREP官方GitHub仓库：包含冻结评测标签、协议实现、审计材料和当前项目状态。
• Reddit：LSREP研究介绍与讨论：作者对研究动机、实验规模与负面结果的简要说明。