腾讯Hy Memory实测：写入模型决定记忆成败

腾讯本周开源了 Hy Memory 2.0——一个 Apache-2.0 许可的框架、一个 30B 记忆模型，以及 MemHub（可在多个 AI 工具间共享同一份记忆的应用）。作为同赛道开源项目 Aura 的作者，我关心它在两个最实际的失败场景上表现如何：

1. 事实已更新，却仍回答旧版本；
2. 忘记"谁说过什么"，尤其是助手自己说过的话。

利益披露： 我是 Aura 的作者，一个开源记忆库并配有 Windows 应用。所有测试配置和通过线在运行前就已确定，不利结果同样如实报告。

测试方法

我使用了公开基准 LongMemEval。每道题附带约 50 段对话的用户聊天历史，答案藏在其中。我选取了六类问题中的三类，每类 20 题：

类型	考察内容
知识更新	事实后来改变了，记忆是否给出新版本？
助手说过	答案只存在于助手说过的话中
用户说过	答案在用户的话中（对照组）

两套系统获得完全相同的历史和问题。两者都用同一个模型读取检索到的记忆并作答（Gemini 3.8 Flash），同一模型按 LongMemEval 官方评判提示词打分。

• Hy Memory 2.0.1，默认 pro 模式。Hy 用 LLM 将每段对话转化为事实，并与旧事实调和。腾讯自有的 30B 模型没有可用的 API，框架支持任何 OpenAI 兼容模型（其 README 使用 DeepSeek^广告）。因此我跑了两次：分别用 Gemini 3.8 Flash 和 Claude Opus 5.5 作为写入模型。Opus 是公平的替代——腾讯的模型卡将其与 Claude Opus 5 对比，平均分几乎相同（55.5 对 54.6）。
• Aura 1.62.0 保留每一轮对话的原貌，附带日期和说话人，检索最相关的 10 条。写入时不使用 LLM；嵌入在本地运行。

LongMemEval 是评估长期记忆系统的公开基准，其设计核心在于：为单个用户构造横跨多轮会话的聊天历史（此处约 50 段对话），再把需要跨会话才能回答的问题附在其后。问题被划分为若干能力维度，例如知识更新、时间推理、多会话推理、助手记忆与用户记忆等，考察系统能否从冗长历史中定位并整合信息。评判通常由另一个 LLM 依据官方提示词对系统答案与标准答案进行语义比对，而非字符串匹配。由于历史长度、问题类型和评判方式都公开固定，LongMemEval 常被用于横向比较不同记忆方案的准确率，但也意味着结果受历史构造方式和评判模型选择的影响。

写入模型（写入时 LLM） 指记忆系统在保存阶段调用的模型，与回答问题时使用的阅读模型相互独立。以本文为例，Hy 在写入时用 LLM 把每段对话转化为结构化事实，写入模型越强，事实提取与新旧调和的质量越高；Aura 则不在写入阶段调用 LLM，仅保留原始对话。这一区分之所以关键，是因为写入发生在历史积累阶段，成本随用户数据量线性增长，而阅读只发生在提问时。评估记忆系统时，若只报告最终准确率而不说明写入模型强度与调用次数，就难以判断这套方案在真实规模下的成本是否可接受。

结果一：廉价写入模型下，Hy 仅答对 43%

问题类型	Aura	Hy（Gemini Flash 写入）
知识更新	90%	55%
助手说过	100%	0%
用户说过（对照）	95%	75%
全部 60 题	95%	43%

Hy 的 34 次失败中有 32 次是"我没有那个信息"。

我预想到的第一个反驳是：Hy 的 10 条事实比 Aura 的 10 轮对话短（约 2,000 对 5,000 字符），也许只是读到的内容更少。我用更大的限制重新搜索 Hy 的存储，不重写任何东西。当文本量与 Aura 相当时，得分 45%；检索 40 条记忆（约 7,900 字符）时，仍只有 45%。信息是在对话转化为事实时丢失的，而非检索阶段。

结果二：Claude Opus 写入时，Hy 追平了事实更新

用 Opus 作为写入模型每题约花 5 美元，因此每类只跑了 10 题。

知识更新，同样 10 题：

	正确数
Aura（写入时不调用 LLM）	9 / 10
Hy，Gemini Flash 写入	6 / 10
Hy，Claude Opus 5.5 写入	9 / 10

这一局对我不利。使用强写入模型时，Hy 追踪变化事实的能力与 Aura 相当。它将旧值存为历史（"当前：25:50 … 历史：27:12"），这是正确的设计。两者都错过了同一道题：同一天出现了两个不同计数。

助手说过，8 题（Anthropic 额度在 10 题中的 2 题耗尽，已排除）：

	正确数
Aura	8 / 8
Hy，Gemini Flash 写入	0 / 8
Hy，Claude Opus 5.5 写入	4 / 8

Opus 在此帮助很大：它确实将助手的一些建议存为记忆（"助手建议…"），而 Flash 从未做到。但助手说过的内容仍有一半未能进入记忆。四次失败全部是"我没有那个信息"，即便检索了 40 条记忆。

同等准确率的成本对比

针对一个约 50 段对话的用户历史：

	写入时 LLM 调用次数	Token 数	写入耗时
Hy，Gemini Flash 写入	84	416K 输入，9K 输出	约 15 分钟
Hy，Claude Opus 5.5 写入	92	695K 输入，61K 输出（按标价约 5 美元）	约 11 分钟
Aura	0	0	36 秒

这才是真正的权衡所在。Hy 的质量是在写入时用 LLM 逐段阅读对话换来的。用廉价模型，在变化事实上的得分跌至 55–60%；用 Opus，可匹敌一个从不调用模型的记忆方案，代价是每用户历史约 5 美元。

根因：将对话重写为事实会丢失信息

Hy 将每段对话压缩为关于用户的陈述（"用户有兴趣学习和烹饪经典秘鲁菜"）。这使记忆小而整洁，但丢弃了写入模型认为不属于用户事实的一切：助手的推荐、看似次要的细节、有时是事实的更新版本。以下是用 Flash 运行时的例子：

• "我读完《夜莺》了吗？"Hy 说这本书因过于情绪化而被搁置；后来用户已读完。
• 之前 100 的目标被新的 150 目标覆盖，因此"我之前的目 标是什么？"无答案。
• "你推荐了哪种啤酒用于那个菜谱？"推荐来自助手，因此未被存储。

Aura 走相反路线：保留说过的原话，连同说话人和时间，把判断什么重要的决定留给回答问题的模型。这需要更多存储，也给了阅读器更多文本，但写入时无需猜测。

事实调和（fact reconciliation） 是 Hy 类系统的关键步骤：新对话被抽取为事实后，系统需判断它与已有事实是新增、重复还是替换关系。若新事实与旧事实冲突（如目标从 100 改为 150），正确做法是把旧值降级为历史、把新值标为当前，从而支持“现在是多少”与“之前是多少”两类问题。调和依赖写入模型的判断力，廉价模型容易直接覆盖旧值或忽略冲突，导致“事实已更新却仍答旧版本”；而若把冲突值都保留却不标注时效，检索时又可能召回错误版本。Aura 不做事先调和，而是把原话连同时间戳一并保留，让阅读模型在回答时自行判断哪个版本更新。

局限性

• 仅测试 LongMemEval 六类中的三类，选因是它们对应上述两个失败场景。未测试多会话推理、时间推理或偏好——在这些场景下，将对话摘要为事实可能反而有益。
• 样本量小。 主运行 60 题；Opus 运行 10 题和 8 题。每题对应 5–12 个百分点的波动。
• 并非腾讯自有模型。 其 30B 模型可能比 Flash 写得更好。Opus 是其模型卡提供的最接近对比。
• 仅测 pro 模式。 未测试 ultra（图模式）。
• 单一阅读与评判模型（Gemini 3.8 Flash），两套系统相同。
• 主运行中 Hy 有 1.3% 的对话未能存入（发送了模型拒绝的空文本），最多影响 1–2 题。

结论

如果你评估一个用 LLM 做摘要的记忆系统，请在自己的数据上检查两件事：它需要多强的写入模型才能表现良好，以及那个模型每用户成本是多少。还要问它是否保留了助手说过的话——因为"你上次推荐了什么？"是用户真会问的问题。

Aura 已开源（MIT）：github.com/teolex2020/aura-memory。Windows 应用在 Claude Code、Cursor、Codex、Gemini CLI 等工具间共享一份本地记忆：aurasdk.dev/desktop。