记忆系统排名为何经不起评分审查

一份 AI 记忆实验里，SQL 拿到 30/30，Graphiti 最初只有 12/30，重复跑又降到 7/30，看起来胜负已经分明。但作者检查保存记录和评分代码后发现：输入不对等，标准答案来自 SQL 自己，两套评分规则还在判断不同的东西。

这篇最有用的地方，是拆开了一个漂亮分数背后的条件。对正在给 AI 应用接记忆、检索和历史状态查询的程序员来说，它提供了一套检查方法：先确认分数到底测到了什么，再决定能不能据此选型。

30/30 为什么还不能证明 SQL 的记忆更好

这轮实验测试的是：一个值改变之后，系统能否回答变化前后的状态。

测试包含 15 个对象的 15 次变化。每次变化分别生成提前一小时、延后一小时的问题，共 30 题。其中 14 次变化来自同一字段类别，另一次来自另一类，覆盖范围相当窄。

Graphiti 收到的是两段文本记录：旧值所在记录的时间设为变化前一天，新值所在记录的时间设为变化发生时。SQL 则已经保存了带类型的历史行，而且评测使用的标准答案也由这套 SQL 历史库提供。

SQL 的 30/30，首先证明的是它与生成答案的同一套历史数据保持一致。

它并没有独立证明 SQL 更能处理一般性的记忆问题。Graphiti 还多做了一步：从文字里抽取对象、字段和值，再形成可查询的表示。把两个最终分数直接比较，会把抽取能力和历史查询能力混在一起。

实验发生在 2026 年 11 月 5 日晚间至 11 月 6 日 01:28 UTC。它是早先 DolphinBench 来源会话检索实验之后的另一轮测试，不属于 DolphinBench，也没有测试 Mem0 和 Anima。

搜索得 15 分、存储得 3 分，问题就出在存储吗

未必，因为两个分数不是同一把尺子量出来的。

搜索分支请求 20 条结果，按有效时间过滤，再检查结果中是否包含对象标识的一部分，以及预期值。它只使用对象标识的第一段。这样的子串匹配容易实现，却未必能准确区分对象。

另一个分支扫描全部已保存的图边，要求完整对象标识。它还增加了冲突惩罚：如果事实带有相同字段名前缀，却不包含预期值，就可能被扣分。但事实文字里只要出现字面单词 previous，又可能免除这项惩罚。

于是，「search: 15, stored graph: 3」不能直接说明信息在哪一步丢失。后一个评分器还在用额外规则检查事实的措辞。要定位检索和存储的问题，至少得先统一评分标准。

留存证据也不完整。搜索虽然请求了 20 条，每个保存条目却最多保留 4 条当前有效事实、6 条未过滤事实。别人可以重新加总已记录的通过与失败次数，却无法凭这些缩短的数组重建全部搜索判断。

这也解释了分数为什么容易被过度解读：Graphiti 首次搜索得到 12/30，同一路由标签重跑得到 7/30；后续搜索最高达到 24/30，单独扫描已存图的分支最高达到 27/30。最初「Graphiti 得到 6–12/30」的描述，必须附上配置和日期，不能当成固定能力结论。

这些改善也不能直接归因于更换模型。适配器和 schema 处理方式有变化，实验没有进行重复的受控对照，同一个 GLM 标签此前就出现过不同结果。记录中的名称只是本地提供方路由标签，背后模型身份没有得到独立验证。

此外，三个 Claude 标签路由和一个 GPT-OSS 路由因授权或提供方、schema 故障，没有处理这些文本记录。这些是缺失的测量，不能算作记忆能力零分。

这套配置能检查流程，却撑不起产品排名

所有运行文件都标记使用 hash-bow-256：把词散列到 256 维的嵌入器，并明确注明用于冒烟测试。重排序（reranking）也被禁用了。

这套设置适合检查数据能否写入、时间戳能否参与处理、集成链路能否跑通。但它没有使用面向检索质量的正常嵌入配置，再加上样本小、字段集中、输入不对等，不能支撑生产级记忆系统排名。

公开审计材料的用途同样有限。它提供路由标签、源文件哈希、带索引的通过与失败判定，以及文件修改时间；没有公开对象名称、值、事实级时间戳、提示词、图文本或凭据。因此，它支持核算已保存的判定数量，不支持独立重新判断答案在语义上是否正确。

另一个容易混淆的事实是产品发布。早先的检索实验之后，SGM PR #98 将 cross-encoder 重排序改为显式开启。该 PR 于 2026 年 11 月 6 日 00:37:59 UTC 合并，版本 0.3.7 约在 00:39 UTC 上传 PyPI。

这是此前证据推动的真实改动，但不能据此推断发布后又跑出了新的 DolphinBench 成绩。

我的判断

我认同作者把抽取、存储、检索和评分拆开检查。对结构明确、要求追溯历史值的业务，SQL 历史表是值得保留的基线；如果输入本来就是自由文本，抽取质量也是产品必须承担的成本。公平比较需要分别报告这些阶段，再补上完整流程的结果。

但这份材料最扎实的贡献是发现评测缺陷，而不是证明哪套记忆方案更强。它没有足够的受控对照数据，不能为「换模型改善效果」或「某种存储更可靠」背书。

报告由 Mycroft 和 Tony Dzi 署名，原文说明这是 AI 基于保存实验生成的分析，也没有独立提供方背书。读者应把它当作一次有边界的实验审计。

作者提出用公开、合成的变化历史数据重新测试，这个方向合理。不过那是下一次实验的设计，当前还没有对应结果。

能拿来做什么

• 给 Node AI 应用评估记忆组件时，先统一输入合同。如果一方接收结构化变更，另一方接收自然语言，就分别报告抽取结果和历史查询结果，再比较完整流程。
• 在评测脚本里单列可用性，区分授权失败、写入失败和答案错误；同时使用独立标准答案，让搜索结果与存储事实接受同一套评分规则。
• 保存评分器实际看到的全部检索条目，并记录评分器版本、嵌入配置、适配器和路由标签。只有通过次数，没有完整证据，后续很难定位回归。
• 为常见的「修改前是什么、修改后是什么」建立新用例，冻结配置后重复运行，再用未见问题验证。先完成这些步骤，再把分数用于选型或对外宣传。