智能体记忆上线前，应该怎样评估

一项记忆 benchmark 只能告诉你：某个冻结系统在某套运行器里回答了某个数据集。它不能告诉你，你的客服智能体是否记住了正确账户、是否尊重已经纠正的偏好、是否避开另一个租户的数据，也不能证明供应商超时后系统能安全恢复。

生产评估因此需要两层：用公共 benchmark 识别广泛失效类别，再用产品自身轨迹建立一套私有、版本化验收集。

先说结论

• 评估完整闭环：写入策略、持久状态、检索、上下文组装、答案、延迟和故障行为。
• 冻结代码、模型、提示词、存储适配器、数据切分和裁判规则。
• 只在开发集调参，为发布保留独立 holdout 集。
• 报告逐题输出、成对差异、不确定性和已知失败，而不是只报一个平均分。
• 把每个接近生产的失败变成长期回归案例。

从产品决策开始

“提高记忆准确率”不是验收标准。要写清楚记忆应该改善哪项决策，例如选择当前收货地址、保留用户的沟通限制、跨会话继续工作流、引用回答所依据的政策版本，或在没有可靠记忆时拒绝猜测。

每个案例都应包含来源轨迹、预期持久记录、检索查询、必须出现与禁止出现的证据、预期下游决策，以及这项决策为什么重要。

分层衡量完整闭环

层级	核心问题	示例指标
写入	系统是否保存了正确的持久信息？	必要事实召回率、禁止事实率、重复率
状态	纠正与有效期是否正确？	当前值准确率、as-of 准确率
检索	上下文是否包含回答所需证据？	上下文完整度、精确率、排名
答案	智能体是否依据证据作出正确决策？	任务 rubric 或精确答案
运营	闭环能否承受真实交付条件？	尾延迟、失败率、重试、索引可见时间
安全	是否暴露了禁止的作用域或来源？	跨租户泄漏与策略违规

先检查上下文完整度，再判断答案正确

答案可能因为错误原因而正确：模型本来就知道答案，评测问题泄漏了答案，或者无关检索内容碰巧诱导出目标短语。应检查组装后的上下文是否真正包含必要证据，同时排除了相互矛盾或未经授权的材料。

反过来，一条相关检索命中也不能保证正确答案。应用可能排列证据不当、遗漏时间标记，或把本应由确定性代码完成的决策交给模型。把检索层和答案层分开评分，才能知道应该修哪一层。

建立有代表性的轨迹集

先抽样真实分布，再有意识加入困难案例：

• 单会话事实与偏好；
• 跨会话继续；
• 随时间变化的事实；
• 迟到的纠正；
• 必须保持隔离的相似用户或项目；
• 正确行为是拒绝回答的请求；
• 无效写入、重试、删除与恢复；
• 需要引用的长来源；
• 应过期而不应成为持久记忆的工具结果。

在保留决策结构的前提下删除或脱敏敏感用户数据，并为每个案例提供稳定身份，使不同发布版本可以逐项比较。

把开发判断和发布判断分开

开发集用于检查失败、调整提示词、改变检索和调节阈值；holdout 集在候选版本冻结前保持不可见。边调参边反复查看发布集，会让它变成另一个开发集。

对于小改动，成对评估通常比两个独立平均值更有信息。用两个候选运行相同案例，记录哪些项目发生翻转，并检查收益是否集中在一种类型、同时让另一种类型退化。

冻结所有会移动的部件

• 源代码版本和依赖锁；
• 记忆模式与提取提示词；
• 回答、嵌入、重排与裁判模型；
• 温度与重试行为；
• 存储和向量适配器；
• 分块与 top-k 配置；
• 数据切分和来源预处理；
• 裁判 rubric 与规范化代码；
• 逐题原始输出和失败日志。

没有运行清单的 benchmark 结果只是一张截图；有清单和原始输出，它才是一项其他工程师可以质疑和复现的实验。

只能在各自运行器里解释 benchmark

LoCoMo、LongMemEval 和 BEAM 观察的是长期记忆不同方面。它们的分数不可互换，使用不同模型、提示词、检索上限或裁判协议的数字，也不应被放进同一张表假装赛跑。

FishMem 在 2026-08-24 冻结的评测组合中，对 FishMem 与 mem0 OSS 3.1.2 的每道题进行配对比较，并在每一组中使用相同且公开的配置。500 道 LongMemEval oracle 中，FishMem 为 88.2%，mem0 为 83.8%；配对差值为 +4.4 pt，95% 置信区间为 +1.0 至 +7.8。400 道 BEAM 100K 中，FishMem 为 46.7%，mem0 为 41.0%；差值为 +5.7 pt，95% 置信区间为 +1.8 至 +9.5。

LoCoMo 是败项，也完整保留在发布结果中。类别 1–5 共 1,986 道配对题里，FishMem 为 67.5%，mem0 为 71.1%；差值为 −3.7 pt，95% 置信区间为 −5.8 至 −1.5。LongMemEval oracle 不是 LongMemEval-S。中断后恢复的运行使本次成本和端到端总耗时不满足公开对比条件；FishMem 在两个胜项上也使用了明显更多的召回上下文。这些限制是结果本身，不是应该藏起来的脚注。

把运营指标一起加入

• 写入接受与完成延迟；
• p50、p95 与 p99 检索延迟；
• 每次查询和每个正确答案消耗的上下文 token；
• 供应商调用、重试、超时与终态失败；
• 规范提交到索引可见的时间；
• 重复与幂等冲突率；
• 重建和恢复时长；
• 作用域拒绝与泄漏测试。

谨慎使用模型裁判

LLM judge 对语义答案有用，但它也带来方差和偏差。保持 rubric 狭窄，保存裁判解释，尽可能隐藏系统身份，并人工抽查同意与分歧样本。ID、作用域、删除、事件状态等确定性契约，仍应优先使用精确检查。

不要把同一道题重试到裁判通过，再只报告最好结果。运行前定义重试策略，并保留所有失败。

让失败直接进入路线图

按被破坏的决策归类：漏写、作用域错误、旧事实、排序不佳、上下文不完整、答案推理或运营故障。修复最深层且反复出现的原因，加入回归案例，再重跑整组测试。只说分数提高、却解释不了哪些失败发生变化，很难建立信任，也难以维护。

发布检查清单

1. 冻结候选版本和评估清单。
2. 运行开发集，检查分类级退化。
3. 只为发布决策运行一次 holdout 集。
4. 验证持久状态和投影，不只看最终答案。
5. 运行重试、恢复、删除和跨命名空间用户旅程。
6. 发布或归档逐题输出与限制。
7. 定义生产观察期和回滚阈值。

延伸阅读

• FishMem benchmark 证据与限制
• FishMem benchmark 运行器
• Mem0：智能体记忆现状与开放问题
• Zep：智能体记忆测试与评估指南