MemOS vs Hindsight：AML 触发的隔离 Sidecar 评估与延迟归因

• HTML: https://decision.ht1072.top/2026-08-17-memos-vs-hindsight-aml-sidecar-trial-decision.html
• Local HTML: [已移除本地路径]
• Generated: 2026-08-17T14:29:07+08:00

MemOS vs Hindsight：AML 触发的隔离 Sidecar 评估与延迟归因

结论

结论摘要

本轮评估不支持 MemOS 替换 Hindsight，也不支持继续扩大到 80–120 题。Hindsight 继续作为生产长期记忆主链；MemOS 候选保留为一次性、可删除的隔离评估资产。2026-08-18 复核后，建议进一步收紧为：现在不重跑同版本 MemOS，只做版本触发式 Watch。

m5 的 20 题共同回答层结果：Hindsight 20/20，MemOS 默认 lightweight 形态 14/20。MemOS 的主要缺口是多跳与时序更新；full-evolution 诊断轮把多跳补到 4/4，但时序仍为 0/4，同时增加了明显的摄入延迟和内部 LLM 成本。

一、评估边界与候选冻结

• Hindsight：原始 A/B 时本机生产为 0.9.0；当前现场已验证为 0.9.1。原始评测写入的是临时 bank，不是生产 hermes bank。
• MemOS：@memtensor/memos-local-plugin 2.0.16-beta.1 源码候选，base b41c8996a8dcb9df81998cced68d11457ce950c3，带本地固定补丁：
• masked API key restart 修复；
• Hermes adapter UTF-8 输出修复；
• 对应测试补丁。
• MemOS runtime 使用独立路径，未接入 default profile、gateway、Feishu、cron 或生产 Hindsight。
• 评估语料为虚构、脱敏数据；没有复制生产 Feishu、凭证或现有 Hindsight 事实。

二、m3：MemOS 隔离数据面验收

通过真实 bridge 和 SQLite 数据面验证：

• session open → turn start → turn end 写入成功；
• local embedding Xenova/all-MiniLM-L6-v2 成功，384 维；
• 精确标识符 MEMOS_UTF8_OK_20260817 可检索；
• bridge 关闭后进程退出；
• bridge 重启后原数据仍可检索；
• 中文 wire 输出没有退化为 \\uXXXX；
• runtime、DB、日志和状态文件均在 [已移除本地路径]；
• [已移除本地路径] 未被改动；
• smoke runtime 删除后路径不存在。

一次早期 smoke 失败是 runner 自身变量名笔误 SENTIN/SENTINEL，不是 MemOS 失败；另一次空召回是 runner 将 tier2 错设为 0，修正后精确检索通过。这两次被保留为评估方法学记录，不计入候选质量分。

证据：

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

三、m4：冻结题集与统一契约

20 题分布：

两侧固定：

• 相同 source events、时间戳和摄入顺序；
• 相同 query；
• top_k=10；
• 返回 evidence 字符预算 6000；
• 同一个 answer model、prompt、温度和最大输出；
• 候选不可见 private oracle 与评分规则；
• 记录原始 evidence、search latency、ingest latency、restart 和 cleanup；
• Hindsight 使用临时 bank + case tag；MemOS 使用 case namespace。

产物：

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

题集 hash：

public/manifest.json  6ff608f11d231c5a8f349197113662ea669c0f963567e7793e45c63482651539
hidden/cases.json     4005692c4b5c005914fb8179a8387b6397f084271e4197444a003671457a0ea8
private-oracles/gold  676b76e3f80c237ecb662ab4916dbb51b627cebe20e84166b11e5adfeee3a606

四、m5：20 题结果

共同回答模型为当前 gpt-5.6-sol，provider 为 custom:axon，回答时两侧 evidence 匿名化并在同一次调用中回答。

这里的流程题按“概念覆盖”判分，避免把“先做配置备份”和“配置备份”当作实质差异；多跳题按最终答案判分，不要求模型复述全部证据节点。

检索层 raw 指标如下：

Hindsight 临时 bank 在每个 case 使用同步 retain；因此 ingest latency 不是普通“写入 SQLite/HTTP”的延迟，而是包含 Hindsight 的同步记忆处理链。

证据：

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

临时 Hindsight bank 清理成功，删除记录显示 deleted_count=134；MemOS runtime 也已删除。

五、full-evolution 诊断轮

为了避免把 MemOS 默认 lightweightMemory=true 误当作完整能力，额外运行了时序+多跳 8 题诊断：

run: [已移除本地路径]
config: lightweightMemory=false
llm: host bridge → 当前 Hermes 模型路由

结果：

这轮说明 MemOS full evolution 可以改善多跳，但没有解决时序更新；turn.end 的摄入阶段会触发摘要、embedding 及演化链，内部 LLM 成本和延迟应单独统计，不能只看 search latency。

六、Hindsight 为什么比 MemOS search 慢一个数量级

先纠正表述：本轮测得是约 285/310ms 对 3.4/7.7ms，属于约 40–90 倍差异，确实是数量级差距，但不是严格“指数级”。它主要来自两边的系统形态与调用契约不同，而不是单纯数据库性能差。

1. Hindsight 的 /memories/recall 是服务端 agentic retrieval

m5 调用：

POST /v1/default/banks/{bank}/memories/recall
budget=low
max_tokens=1024
max_results=10
include_entities=false
include_chunks=true
tags_match=all_strict

这个 API 不是裸向量查询。它在服务端需要做 bank 作用域检查、query 处理、多路召回、rerank，并组织最终 memory evidence。Hindsight 的设计还包含 semantic、keyword、entity/graph、temporal 等记忆能力；即使低 budget，也要经过统一 recall 编排和 HTTP/JSON 序列化。

2. Hindsight 的结果需要经过 PostgreSQL/服务端边界

本机 Hindsight 生产服务是独立 API/data plane，m5 每题都走 loopback HTTP，再进入 Hindsight API、数据库连接池、检索与结果组装。MemOS 则是同一 Python 进程拉起的本地 Node bridge，使用进程内 stdio JSON-RPC 和本地 SQLite；它避开了 TCP、HTTP middleware、JSON request/response 和独立服务调度。

这会造成固定基线差异：

• Hindsight：Python runner → loopback HTTP → Hindsight API → Postgres/检索 → JSON → runner；
• MemOS：Python runner → Node child stdio JSON-RPC → SQLite/vector scan → JSON → runner。

3. Hindsight 的单题召回包含更多治理与证据语义

Hindsight 返回的不只是一个向量命中，还会组装 memory text、时间、实体、chunk/evidence 等结构。m5 明确要求 include_chunks=true，并使用 tags 做 case isolation；这些是公平隔离所需的证据字段，但也增加了服务端处理和返回成本。

4. 本轮 MemOS 走的是轻量本地 Tier 2

MemOS m5 配置为：

lightweightMemory=true
llmFilterEnabled=false
embedding=local MiniLM 384d
search=local SQLite/vector + FTS/pattern path

在该模式下，turn-start/tool-driven retrieval 被路由到 Tier 2 trace，搜索主要是本地向量/FTS/模式检索，不调用回答 LLM。full-evolution 只改变摄入与演化链，并没有让 search 变慢，说明 MemOS search 的低延迟主要来自本地进程内路径，而不是“完整自进化搜索”已经被证明同样低延迟。

5. Hindsight 低分位也受每题独立 bank/tag 隔离影响

为避免题目之间互相污染，m5 每个 case 都写入带 tag 的临时 Hindsight bank 语料，并在 recall 时强制 tag filter。这个隔离方式提高了可解释性，但不是 Hindsight 生产常态下的单 bank 热缓存路径；它可能增加了 API 侧 filter 和查询计划开销。

不能从本轮直接推出的结论

• 不能说 Hindsight 的数据库一定比 SQLite 慢几十倍；本轮没有做同数据库、同索引、同返回字段的微基准。
• 不能说 Hindsight 生产真实交互延迟就是 285–310ms；本轮测的是临时小 bank、budget=low、max_tokens=1024 和 tags 隔离。后续 0.9.1 高保真回归确认，runner 当时发送的 max_results/include_entities/include_chunks 不属于 0.9.x RecallRequest，会被 API 忽略，因此不能把 include_chunks=true 当成延迟原因。生产大 bank 的主要成本来自多路候选合并与 cross-encoder rerank。
• 不能说 MemOS 的 3–8ms 是端到端用户可见延迟；它不包含回答模型、Python provider 生命周期、bridge 启动、embedding 冷启动、主机调度和长期运行资源管理。
• 不能把 Hindsight 的 search latency 与其 ingest latency 混为一谈；Hindsight 的 ingest 约 6.9s P50/16.9s P95，主要来自同步 retain 处理，不是 recall 本身。

七、如何做公平的延迟微基准

如果后续确实要比较性能，而不是现在扩大质量 A/B，应单独开 performance benchmark，不修改本轮质量结论：

1. 预先 ingest 完同一 corpus，search 阶段不再混入 retain；
2. 两侧都提供最薄的 search evidence 接口；
3. 去掉不必要的 include_chunks / entity 字段，或两侧都返回等价 evidence payload；
4. Hindsight 比较三档： - API recall； - 只取服务端最终 ranked facts 的 recall； - 若有内部低层接口，再测 database/rerank substrate；
5. MemOS 同样固定 raw hits、snippet 字符预算和 namespace/filter；
6. 冷启动、热缓存、单并发、并发 4/16 分开；
7. 每个条件至少 30 次，报告 P50/P95/P99、空结果率、CPU/RSS、返回字节数；
8. ingest、search、answer 三段分开计时，不用一个总耗时代替；
9. 若仍保留 tag/case isolation，必须把它作为条件变量报告，而不是隐藏在“公平配置”里。

八、最终决策与后续参考

• Hindsight：继续生产主链，不迁移、不双写、不改默认 provider。
• MemOS：保留固定候选、题集、runner 和证据，暂不扩展 full A/B，不保留常驻 sidecar。
• 如果未来要继续，优先不是继续堆题，而是先做独立 latency microbenchmark，并明确比较的是 API、retrieval substrate 还是完整用户可见链路。
• MemOS 可能值得局部吸收的方法包括：显式 context budget、foreground deadline、分层检索的可观测性；不吸收其 runtime、第二技能真相源或默认自动演化链。

九、来源与证据索引

• AML 公开榜单与合同：https://agentmemories.ai/leaderboard/industry/textual、https://agentmemories.ai/docs、https://github.com/AML-memory/agent-memory-leaderboard
• 本机 Hindsight 当前版本：2026-08-18 现场 GET http://127.0.0.1:8889/version → 0.9.1
• 本机 Hindsight 生产基线：m5 前后均未写入生产 hermes bank；生产 stats 仍为约 11.7k nodes、992 documents、pending/failed 为 0。
• MemOS m3 smoke：[已移除本地路径]
• MemOS 删除验证：[已移除本地路径]
• m5 20 题：[已移除本地路径]
• full-evolution 8 题：[已移除本地路径]
• 运行协议与题集：[已移除本地路径]、hidden/cases.json、private-oracles/gold.json

十、2026-08-18 复核：现在是否值得重开 MemOS 对比

结论

不建议现在重开同版本 MemOS 与 Hindsight 的全量 A/B。现有证据已经足够支持 Hindsight 留在生产主链；再次运行同一 MemOS 候选只会重复已经确认的时序、多跳和运维成本结论，不会产生新的决策信息。

为什么不是“榜单更高就再试一次”

1. AML 的价值在于统一 Add/Search、统一回答与评分、固定 evaluation contract；它能降低跨系统比较偏差，但公榜分数只有在版本、合同、回答模型和预算一致时才可横比。公开仓库明确不发布 held-out 数据、gold、私有 annotations 或生产编排，因此它不能替代本机集成与运维验收。
2. 2026-08-18 现场核验，MemOS upstream main 仍是 b41c8996a8dcb9df81998cced68d11457ce950c3，npm @memtensor/memos-local-plugin 仍为 2.0.16；正是本轮候选的 base 与发布版本。试验分支还额外包含 masked API key restart 和 Hermes UTF-8 修复，因此没有“新版已经解决旧问题”的依据。
3. 已有统一20题结果是 Hindsight 20/20、MemOS lightweight 14/20；MemOS full-evolution 仅把多跳恢复到 4/4，时序仍为 0/4，同时增加摄入链、内部 LLM 调用、延迟和成本。
4. 本轮又验证了 Hindsight 内部仍有检索质量优化空间：换用多语 MMARCO reranker 后，共享 bank 的机械评分由 14/20 提升到 18/20；人工语义复核两个共同误判后是 16/20 → 20/20。这说明中文精确事实和多跳不足可以优先在现有 Hindsight 内部优化，不必先换整套记忆平台。
5. 但 MMARCO 本身也没有通过生产门槛：生产规模 clone 的 P95 从 MiniLM 7.90s 升到 13.67s（1.73×），两路并发单请求 P50 从 14.04s 升到 24.59s（1.75×），RSS 增约 31%。因此它只证明“质量问题可局部改善”，不构成生产切换建议。

本轮 Hindsight reranker 证据边界

• 同一 Hindsight 0.9.1 clone、同一 PostgreSQL、同一冻结 bank；两个 reranker 分别单实例运行，避免模型并驻污染。
• 冻结集：20题 × 3轮；大 bank：10条真实查询 × 3轮；另做3组两路并发。
• 两侧20题的 top-10 序列三轮均完全稳定。
• MMARCO 离线重启后，固定查询 top-10 与评测轮完全一致；冻结 bank 保持 28 documents / 52 nodes / 740 links，零 pending/failed。
• 原始机械评分保留不改；process-02 的“然后删除”与“再删除”、temporal-04 的“暂停状态结束”被词面规则误判，语义修正分仅作为诊断，不覆盖原始 artifact。
• 该 reranker 结果不是 MemOS 与 Hindsight 的新一轮直接 A/B，不能拿 18/20 或 20/20 与原始 MemOS 分数混成同一排行榜。

证据：

[已移除本地路径]
SHA256 292156b6ce1d9a8c3213adb0ac430e8988e45e10e46623a271c79cd74e727612

[已移除本地路径]
SHA256 7b709d367127fb44574250a2068881e90fbd14f0ab20107f5afabcba007c4f15

[已移除本地路径]
SHA256 888245e1a100414b24691a0ab6e03cbaeb918ddbddf248bf7abeb7f1245d5545

复测触发条件

只有满足以下任一项，才值得重开20题 smoke；未满足时不保留常驻 MemOS sidecar：

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 总体至少领先 Hindsight 8pp、关键类别至少两类领先 10pp、不可答不变差、P95 不超过 1.5×，且重启/删除/溯源/资源泄漏门禁全部通过，才扩到80–120题。