MemOS vs Hindsight：当前是否值得重开对比评测

• HTML: https://decision.ht1072.top/2026-08-18-memos-vs-hindsight-current-reassessment.html
• Local HTML: [已移除本地路径]
• Generated: 2026-08-18T10:02:46+08:00

MemOS vs Hindsight：当前是否值得重开对比评测

结论

现在不建议重开同版本 MemOS 与 Hindsight 的全量 A/B；推荐 Hindsight 继续作为生产主链，MemOS 降为版本触发式 Watch。原因不是 MemOS 没价值，而是当前候选没有发生足以改变结论的版本变化，旧20题已经暴露核心缺口；同版本重跑只会重复成本，不能增加决策信息。

页面摘要区

• 核心结论：不重跑 MemOS 2.0.16；保留冻结题集与 runner，等明确版本/需求触发后再做20题 smoke。
• 关键依据：MemOS upstream main 与 npm 发布版本仍对应旧候选；旧 A/B 为 Hindsight 20/20、MemOS lightweight 14/20，full evolution 仍未解决时序更新。
• 落地方式：生产不迁移、不双写、不保留 MemOS 常驻 sidecar；优先在 Hindsight 内部继续找更低成本的中文/多语检索改进。
• 风险边界：AML 公榜是统一评测信号，不是本机替换证明；本轮 Hindsight reranker 试验不是新的 MemOS/Hindsight直比。

主论点：决策问题不是“谁榜单高”，而是“新试验还能否改变生产选择”

AML 的方法学价值是真实的：参评系统只负责 Add/Search，平台控制回答和评分，并用版本化 evaluation contract 约束可比性；但其公开仓库明确不包含 held-out 数据、gold、私有标注、participant outputs 或生产编排。因此，AML 能提供外部信号，却不能替代本机 Hermes 集成、中文时序质量、故障恢复和数据治理验收。AML 仓库 · AML 文档/榜单

当前真正需要判断的是：MemOS 自上轮以后有没有发生足以推翻 No-Go 的变化。2026-08-18 现场核验显示，MemOS upstream main 仍是 b41c8996a8dcb9df81998cced68d11457ce950c3，npm @memtensor/memos-local-plugin 仍为 2.0.16；正是旧试验的 base 与发布版本。试验分支还额外带有 masked API key restart 和 Hermes UTF-8 修复，所以当前 upstream 并不比已测候选更有利。MemOS 仓库 · npm package

已有证据如何解释

1. 旧20题已经给出稳定方向

MemOS full-evolution 诊断把多跳恢复到 4/4，但时序仍是 0/4，并引入额外摄入链、内部 LLM 调用、延迟和成本。这个结果说明 MemOS 的优势主要在轻量本地检索和演化架构，而当前短板正好落在生产长期记忆最敏感的 supersession/时序治理上。

2. Hindsight 的不足可以局部优化，不必先换平台

本轮在同一 Hindsight 0.9.1 clone、同一 PostgreSQL、同一冻结 bank 中，对 MiniLM 与多语 MMARCO reranker 做了单实例 A/B：

这组结果有两个含义：

1. Hindsight 当前中文/多跳质量确有内部优化空间，平台替换不是唯一解；
2. MMARCO 自身没有通过生产延迟门槛，因此不能切 live。它是“局部优化可行”的证据，不是生产候选。

Hindsight 本身采用 semantic、keyword、graph、temporal 多路召回，再做融合和 cross-encoder rerank；这种完整检索链解释了它相对本地 SQLite/FTS path 的延迟，也构成其多跳与时序能力来源。Hindsight 仓库

关键矛盾

矛盾一：MemOS 更轻更快，但生产要的是“最新事实正确”

MemOS lightweight 的毫秒级本地搜索很有吸引力，但时序更新失败会把旧值当现值。对生产长期记忆而言，错得快不比慢而正确更有价值。只有当其 temporal supersession 明确修复，轻量检索优势才值得重新计价。

矛盾二：Hindsight 质量更稳，但大 bank CPU rerank 已成为用户可见瓶颈

保留 Hindsight 不等于接受当前延迟。MiniLM 大 bank P95 约7.9秒，两路并发会涨到约15秒；这说明后续应继续找“质量增益/CPU成本”更平衡的多语 reranker、候选压缩或两阶段 rerank，而不是把“维持主链”误解为“不再优化”。

矛盾三：AML 提升了横向可比性，但公开分数仍缺少本机运维维度

AML 统一 Add/Search 和回答层，是比 vendor 自报榜单更可靠的方向；但生产决策还需要限流、失败回退、重启恢复、删除导出、数据外流、常驻资源和 Hermes bridge 稳定性。即使 MemOS 在某个 AML contract 上领先，也只能触发本机 smoke，不能直接触发迁移。

证据边界与反事实

• 当前榜单页面的动态表格无法由静态提取稳定恢复，因此不把此前观察到的具体分数当作今天的实时榜单事实。
• 本轮 reranker A/B 只比较 Hindsight 内部排序层；它不是新的 MemOS/Hindsight直比，不能把 18/20 或语义修正后的 20/20 与旧 MemOS分数混成同一排行榜。
• 如果 MemOS 已发布高于 2.0.16 且明确修复 temporal supersession 的版本，结论会改变为“重开20题 smoke”；但现场核验没有发现这个前提。
• 如果 Hindsight 内部优化始终无法同时满足中文质量和延迟门槛，MemOS 的轻量 sidecar 价值会重新上升；当前证据还没到这一步。

行动含义

现在

• 生产负责人：继续使用 Hindsight 0.9.1；不迁移、不双写、不改默认 provider。
• 评测负责人：保留 MemOS 固定候选、冻结20题、hidden oracle 和 runner；不扩到80–120题，不保留常驻 sidecar。
• 检索优化负责人：下一步只评估能在大 bank P95 ≤ MiniLM 1.5× 内提升中文精确事实/多跳的候选；并发、RSS和离线重启必须同时过门槛。

重开 MemOS 的触发器

满足任一条件才重开20题 smoke：

1. MemOS local plugin 发布高于 2.0.16 的固定版本，且 changelog/commit 明确修复 temporal supersession、Hermes bridge 稳定性或本轮密钥/Unicode问题；
2. AML 发布可核验的正式 result contract，能确认 MemOS/Hindsight 的精确版本、answer model、预算、成本、延迟和失败率；
3. 出现 Hindsight 当前架构无法覆盖、但 MemOS L1/L2/L3/Skill evolution 能直接解决的真实生产需求；
4. Hindsight 持续性质量或可靠性退化，且内部 reranker、候选预算与摄入治理无法达标。

触发后仍从冻结20题开始。只有 MemOS 总体领先至少 8pp、关键类别至少两类领先 10pp、不可答不变差、P95 不超过 1.5×，且重启/删除/溯源/资源泄漏门禁全部通过，才扩到80–120题。

验收与清理

• MMARCO 离线重启后，固定查询 top-10 与评测轮完全一致。
• 冻结 bank 保持 28 documents / 52 nodes / 740 links，零 pending/failed。
• 临时 clone API 18895 与 PostgreSQL 55437 已关闭。
• 生产 Hindsight 8889 当前为 0.9.1，health 返回 healthy、database connected。
• 本轮未改生产 reranker、provider、cron、bank 或 gateway。

证据路径

[已移除本地路径]
[已移除本地路径]
[已移除本地路径]
[已移除本地路径]
[已移除本地路径]