Mem0：给 LLM Agent 装上「可扩展长期记忆」，延迟暴降 91%

本文来自 Mem0 AI 研究团队，作者包括 Prateek Chhikara、Dev Khant、Saket Aryan、Taranjeet Singh 和 Deshraj Yadav。

该团队提出了 Mem0——一个面向 LLM Agent 的可扩展长期记忆架构。核心思路是将对话中的关键信息动态提取、合并、检索，而不是像全上下文方案那样把整段对话历史一股脑塞给模型。在此基础上，研究者进一步提出 Mem0g^g，用图结构（知识图谱）建模实体间的复杂关系，在需要时间推理和多跳查询的场景下表现更强。

在 LOCOMO 基准上，Mem0 相比 OpenAI 的记忆方案取得 26% 的相对提升，p95 延迟降低 91%，token 成本节省 90% 以上。

论文链接：https://mem0.ai/research

LLM Agent 的记忆困境：上下文窗口撑不住

人类交流有个基本能力：记住之前说过的话。你在周一告诉朋友自己吃素，周五聚餐时他不会建议去牛排馆。但 LLM 做不到这一点——不是「做不好」，而是根本没法做。

问题的根源在固定上下文窗口。即便 GPT-4 支持 128K token、Claude 3.7 Sonnet 支持 200K、Gemini 号称 10M，这些数字听起来很大，但在真实场景中远远不够。原因有两个。

第一，长期交互的对话量天然会超出限制。一个用户跟 AI 助手持续对话几周，累积的信息量轻松超过任何窗口上限。第二，也是最关键的，真实对话不会围绕单一主题进行。用户可能上午聊饮食偏好（素食），下午花了三小时讨论编程问题，晚上又问晚饭吃什么。全上下文方案得把这些无关的编程讨论全部过一遍才能找到那条素食偏好——不仅低效，注意力机制在处理远距离 token 时性能也会退化。

那 RAG 呢？把对话分块检索，理论上能解决长对话问题。但 RAG 检索的是原始文本块，噪声大、粒度粗，检索到的往往是一大段包含关键信息的冗余文本，而不是精炼的事实。Mem0 想做的事情很直接：不存原始对话，只存关键事实。

Mem0 架构：提取、判断、更新三步走

Mem0 的处理流程可以概括为「增量式记忆管理」——每当一轮对话（一个 user message + 一个 assistant response）结束，系统就执行一次提取和更新。

提取阶段

收到新的消息对 (mt−1,mt)(m_{t-1}, m_t) 后，Mem0 会同时参考两类上下文信息来提取记忆：

  • 对话摘要 SS：一段异步维护的全局语义概要，概括到目前为止的对话主旨
  • 最近 mm 条历史消息 {mt−m,…,mt−2}\{m_{t-m}, \ldots, m_{t-2}\}：提供更细粒度的即时上下文

系统将这些信息拼成提示词，交给 LLM 提取出当前对话中的关键事实 Ω={ω1,ω2,…,ωn}\Omega = \{\omega_1, \omega_2, \ldots, \omega_n\}。

更新阶段

提取出候选事实后，Mem0 不会直接存入数据库。对每条候选事实 ωi\omega_i，系统先用向量相似度从数据库中检索出最相关的 ss 条已有记忆，然后把「候选事实 + 相似记忆」一起交给 LLM，由 LLM 自己判断该执行哪种操作：

  • ADD：全新信息，直接新增
  • UPDATE：补充已有记忆（比如用户之前说住在北京，现在提到搬到了上海）
  • DELETE：新信息与旧记忆矛盾，删除旧记忆
  • NOOP：无需任何操作

这种设计的好处在于——不需要额外的分类器，全靠 LLM 的推理能力做决策。实验中，系统配置为 m=10m=10（参考最近 10 条历史消息）、s=10s=10（检索 10 条相似记忆），所有 LLM 操作使用 GPT-4o-mini。

Mem0 系统架构：提取阶段和更新阶段的完整流程

Mem0g^g：用知识图谱捕捉复杂关系

Mem0 用自然语言存储记忆，对简单的事实检索效果很好。但有些问题需要跨多条记忆做关联推理——比如「Alice 之前在哪家公司工作时遇到了 Bob？」这类多跳问题，仅靠文本相似度检索往往力不从心。

Mem0g^g 在 Mem0 基础上引入了图记忆表示。具体来说，记忆被建模为有向标记图 G=(V,E,L)G = (V, E, L)：

  • 节点 VV 代表实体（人物、地点、事件等）
  • 边 EE 代表实体间的关系（lives_in、prefers、works_at 等）
  • 标签 LL 给节点分配语义类型

提取过程分两步：先用 LLM 从对话中抽取实体及其类型，再生成实体间的关系三元组 (vs,r,vd)(v_s, r, v_d)。更新时，系统会检测新旧关系之间的冲突，用 LLM 判断是否需要将旧关系标记为失效——注意是「标记失效」而非物理删除，这样可以支持时间推理（比如用户搬家后，旧的居住关系仍然可查，只是不再为当前有效）。

检索阶段采用双通道策略：一条路基于实体中心方法，从查询中识别关键实体后在图中扩展关联子图；另一路用语义三元组匹配，将整个查询编码为向量后与所有关系三元组做相似度比较。底层图数据库用的是 Neo4j。

Mem0^g 图记忆架构：实体提取和冲突解决流程

实验结果：全面碾压，延迟砍到脚踝

LOCOMO 基准：四类任务全面领先

研究者在 LOCOMO 数据集上做了系统评测。这个数据集包含 10 段扩展对话，每段约 600 轮对话、26000 token，配有约 200 道测试题，覆盖四类问题：单跳（Single-hop）、多跳（Multi-hop）、开放域（Open-domain）和时间推理（Temporal）。

对比了六类基线：LOCOMO 已有基准（LoCoMo、ReadAgent、MemoryBank、MemGPT、A-Mem）、开源方案（LangMem）、RAG（7 种 chunk size × 2 种 k 值）、全上下文、OpenAI 记忆功能、商业记忆平台 Zep。

方法单跳 J多跳 J开放域 J时间 J总分 J
OpenAI63.7942.9262.2921.7152.90
Zep61.7041.3576.6049.3165.99
LangMem62.2347.9271.1223.4358.10
A-Mem*39.7918.8554.0549.9148.38
Mem067.1351.1572.9355.5166.88
Mem0g^g65.7147.1975.7158.1368.44

几个有意思的发现：

Mem0 在单跳和多跳任务上全面领先，说明自然语言记忆对精确的事实检索已经足够强。Mem0g^g 在时间推理上拿了最高分（J=58.13），验证了图结构在捕捉时序关系上的优势——毕竟关系三元组天然带有「谁在什么时候做了什么」的结构信息。

开放域是唯一一个 Mem0 没拿第一的任务类型，Zep 以 76.60 的 J 分略胜 Mem0g^g 的 75.71。但差距不到 1 个百分点，考虑到 Zep 的 token 消耗是 Mem0g^g 的 40 多倍（后文会展开），这个微弱优势的性价比很低。

延迟和成本：不是好一点，是好一个量级

全上下文方案虽然总分最高（J=72.90），但代价惊人——p95 延迟 17.1 秒，每条查询要处理约 26000 token。在实际部署中，用户等 17 秒才能收到回复，这完全不可接受。

Mem0 的 p95 总延迟只有 1.44 秒，比全上下文方案低了 91%。token 消耗方面，Mem0 平均每段对话只占 7K token 的记忆空间，Mem0g^g 约 14K——而 Zep 的记忆图谱居然膨胀到 600K token 以上。原因在于 Zep 在每个节点都缓存了一份完整的摘要，边上也存事实，导致大量冗余。

更有趣的是，Zep 还有一个实际问题：新加入的记忆不能立即被检索到。研究者发现需要等待数小时后重新查询，结果才会明显改善——这意味着 Zep 的图构建涉及大量异步 LLM 调用和后台处理。相比之下，Mem0 的记忆构建即使在最差情况下也不到 1 分钟，新记忆立即可用。

延迟对比：Mem0 在搜索延迟和总延迟上都大幅领先

写在最后

总体来看，Mem0 的工作清晰地回答了一个问题：LLM Agent 的记忆不需要存所有东西，只需要存对的东西。通过增量提取和四操作更新机制，Mem0 用极低的存储成本和延迟实现了接近全上下文方案的回答质量。Mem0g^g 进一步证明了图记忆在时间推理等复杂任务上的价值——虽然带来了额外的延迟开销，但换来了最有价值的信息：实体间的关联结构。

一个值得关注的细节是，Mem0g^g 在多跳任务上并没有超过基础版 Mem0（J 分别为 47.19 vs 51.15）。研究者认为这可能是图结构在多步推理场景中引入了冗余或导航开销。未来如何优化图操作以降低延迟，以及如何将分层记忆架构与图表示结合，仍然是值得探索的方向。

论文链接：https://mem0.ai/research