memtrust

促使我们构建这一工具的契机是 MemPalace。他们的 README 最初宣称 LongMemEval 达到 100%（使用 Haiku 重排序测得），但该数据无法通过其仓库自带的基准脚本复现，最终被撤下。另一个至今仍被引用的 96.6% 数据，主要得益于 ChromaDB 默认嵌入在 raw 模式下的强劲表现，而非 MemPalace 自身架构的功劳。此外，他们所声称的"无损"AAAK 压缩，在实际中将 96.6% 降至 84.2%，与"无损"的含义相差 12.4 个百分点。

这些情况在 MemPalace 用户自己提交的 [Issue #27]（4 月 7 日开启）中有完整记录。两个试图修正报告问题的 PR（#433 和 #729）于 4 月 12 日被关闭且未合并，其中 #729 在开启仅七分钟后便被关闭。我们认为是时候构建一款独立校验厂商宣称数据的工具，并在整个流程中使用完全一致的方法论。

我们之所以有足够信心发布这一基准，是因为在我们将工具指向任何第三方厂商之前，它先在我们自己的代码中捕捉到了一个虚构的 API。

我们早期版本的 MemPalaceAdapter 全部调用了 mempalace.Palace(storage_path=...) 类及其 .remember()、.recall()、.invalidate() 方法。但该类在实际安装的包中并不存在（运行 python3 -c "import mempalace; hasattr(mempalace, 'Palace')" 返回 False）。我们此前所有"通过"的测试，实际上都只是在运行一份手写的伪造实现。工具捕捉到了这一问题，我们随后已基于真实的 mempalace.mcp_server 函数重写了适配器。

目前仅有一个后端完成了完整运行：mem0_direct。它是 mem0ai 开源库的自托管版本，通过 memtrust 的适配器以进程内方式运行，后端采用本地 Qdrant + OpenAI，而非 Mem0 的托管 Platform API。

在较小样本下，我们发现了以下情况：

- 矛盾检测：7 个案例中有 7 个被静默覆盖（100% 静默覆盖率，0% 被标记为冲突）。

- 压缩保真度：跨 5 个案例，文本字面保真度均值为 31.6%。

- 提取质量：跨 15 个案例，12 条刻意构造的垃圾条目均被正确拒绝，但 3 条刻意构造的有效条目在检索时全部丢失。

让本次运行能够跑通的过程还暴露了 mem0ai 自身的一个 bug。其默认模型字符串（gpt-5-mini）未被 mem0 自身的推理模型识别逻辑所识别，因为该逻辑检查的是 gpt-5o-mini。任何设置了 OPENAI_API_KEY 的用户，在首次使用基于 LLM 的提取调用时都会直接收到 400 错误。我们的适配器目前已对此进行了规避。

Mem0、MemPalace、Zep 和 OpenViking 都是真实存在、有真实社区支持的实用项目。这并不是针对其中任何一方的攻击。我们只是想为各团队提供一个可验证的数据。Zep/Graphiti 与 OpenViking 尚未进行实时基准测试，但它们是我们的下一批目标。

如果您正在评估记忆系统，欢迎留言告诉我们您关注的候选后端以及最在意的指标（矛盾处理、压缩保真度、大规模检索等），我们将分享目前的发现。

如果您持有有效的凭证，并希望协助产出首个独立运行的 MemPalace 或 Zep 基准，请提交一个 Issue！