← 返回资料站  /  Continuous Learning
论文 记忆机制

Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory

Mem0:面向生产环境的 agent 长期记忆层
一句话Mem0 公司(YC S24)的系统论文:用 LLM 从对话里抽取记忆条目、再用 tool call 决定 ADD/UPDATE/DELETE/NOOP 来维护记忆库;在 LOCOMO 上 overall J 分 66.88(图记忆版 68.44),p95 总延迟 1.44s、比 full-context 低 91%。工程影响力大(GitHub 64k+ 星),但 benchmark 结论被竞品 Zep 公开质疑,且当前开源版已放弃论文里的 UPDATE/DELETE 管线。

这是什么

LLM 的 context window 有限,多 session 对话里早先说过的信息("我是素食者")在新 session 里会被遗忘。Mem0 的做法不是把全部历史塞进 context,也不是对原始文本做 RAG,而是维护一个独立的记忆库:每轮对话后用 LLM 抽取出精炼的事实条目存起来,回答时只检索最相关的几条。这样平均每段对话的记忆只占约 7k tokens,而 full-context 要 26k。

论文提出两个变体:基础版 Mem0 把记忆存成自然语言条目 + 向量索引;Mem0g 在此之上加了图记忆,把实体存成节点、关系存成有向带标签的边(Neo4j),用于需要关系推理和时序推理的问题。评测用 LOCOMO 基准(多 session 长对话问答),对比 RAG 各种配置、full-context、A-Mem、LangMem、Zep、OpenAI 记忆功能等六类基线。

这篇论文的意义与其说是方法创新(抽取-更新记忆的思路此前已有),不如说它是目前最流行的开源 agent 记忆层的官方描述:mem0ai/mem0 仓库 64k+ 星、Apache-2.0、持续活跃(2026-08 仍在高频更新),是记忆系统工程化落地的现状基线。

Mem0 基础版管线。左边抽取阶段:新消息对 + 对话摘要 + 最近 m 条消息一起喂给 LLM,产出候选记忆;右边更新阶段:对每条候选检索 top-s 相似旧记忆,由 LLM 通过 tool call 在 ADD/UPDATE/DELETE/NOOP 四个操作中选择。注意这是论文(2025-04)的架构,开源 v3 已改为 ADD-only。
Mem0 基础版管线。左边抽取阶段:新消息对 + 对话摘要 + 最近 m 条消息一起喂给 LLM,产出候选记忆;右边更新阶段:对每条候选检索 top-s 相似旧记忆,由 LLM 通过 tool call 在 ADD/UPDATE/DELETE/NOOP 四个操作中选择。注意这是论文(2025-04)的架构,开源 v3 已改为 ADD-only。

机制与做法

抽取阶段:从消息对到候选记忆

每收到一对新消息(用户消息 + 助手回复),系统构造 prompt P = (对话摘要 S, 最近 m 条消息, 新消息对),让 LLM 抽取出若干条 salient facts 作为候选记忆。摘要 S 由一个异步模块定期刷新,提供全局语境;最近消息(实验中 m=10)提供摘要里没来得及合并的细节。实验全程用 GPT-4o-mini。

端到端延迟 vs LLM-as-a-Judge 分数(纵轴延迟为对数刻度)。柱子是 J 分:full-context 最高(72.9%)但 p95 延迟 17.1s;Mem0(66.9%)和 Mem0g(68.4%)分数略低但 p95 只有 1.44s/2.59s。这张图是全文论点的浓缩:Mem0 卖的是质量-延迟权衡,不是绝对最高分。
端到端延迟 vs LLM-as-a-Judge 分数(纵轴延迟为对数刻度)。柱子是 J 分:full-context 最高(72.9%)但 p95 延迟 17.1s;Mem0(66.9%)和 Mem0g(68.4%)分数略低但 p95 只有 1.44s/2.59s。这张图是全文论点的浓缩:Mem0 卖的是质量-延迟权衡,不是绝对最高分。

更新阶段:LLM 直接决定四种操作

对每条候选记忆,先从向量库检索 top s=10 条语义相似的已有记忆,然后把候选 + 相似记忆一起交给 LLM,通过 function calling 让它直接在四个操作里选:ADD(没有等价记忆时新建)、UPDATE(补充已有记忆)、DELETE(新信息与旧记忆矛盾时删除)、NOOP。不训练单独的分类器,完全依赖 LLM 的判断,这是整个设计的核心赌注——也是后来实践中被改掉的部分(见 reality)。

Mem0g:图记忆变体

两阶段抽取:entity extractor 先识别实体和类型,relationship generator 再生成 (源实体, 关系, 目标实体) 三元组,存入 Neo4j。新三元组入库前按 embedding 相似度(阈值 t)对齐已有节点,并有 LLM-based 冲突检测:与新信息矛盾的旧关系标记为 invalid 而非物理删除,以保留时序推理能力。检索是双路:实体锚定的子图扩展 + 整句 query embedding 对三元组文本编码的相似度匹配。结果上图记忆只在 temporal 类问题上明显占优(J 58.13 vs 基础版 55.51),single-hop/multi-hop 反而略降,作者自己也承认图结构在简单检索上是开销。

关键结果

实证核查

有水分作为开源记忆层的工程价值是实打实的(64k 星、生态广、持续维护),但论文的 benchmark 叙事有明显水分:对最强竞品的测量被对方公开质疑,摘要措辞超过正文结果,且当前开源版已经放弃了论文的核心更新机制。
摘要声称"在四类问题(single-hop、temporal、multi-hop、open-domain)上一致超越所有现有记忆系统"。
论文自己的结果节(source/sections/result.tex)写明 open-domain 上 Zep 的 J 分 76.60 高于 Mem0g 的 75.71 和 Mem0 的 72.93;overall J 上 full-context(72.90)也高于 Mem0g(68.44)。"26% 提升"的对比对象是 OpenAI 记忆功能(52.9),不是最强基线。
论文报告 Zep 在 LOCOMO 上 overall J 仅 65.99%(分项复现值 58.44%),显著弱于 Mem0。
Zep 发文《Lies, Damn Lies, Statistics: Is Mem0 Really SOTA in Agent Memory?》(blog.getzep.com)指控 Mem0 配置错误地评测了 Zep,称修正后 Zep 为 75.14%、反超 Mem0 约 10%,并批评 LOCOMO 本身是有缺陷的基准;Mem0 随后在 getzep/zep-papers issue #5 反驳 Zep 的复现。双方各执一词,第三方(如 Penfield Labs 的 benchmark 提案文章)将此事作为记忆系统评测不可信的典型案例。论文里的横向对比数字应当只作参考。
核心机制是抽取后由 LLM 决定 ADD/UPDATE/DELETE/NOOP,维护一致、无冗余的记忆库。
仓库 README(2026-04 "New Memory Algorithm")明确写着新算法是 single-pass ADD-only extraction——one LLM call, no UPDATE/DELETE, memories accumulate, nothing is overwritten,即论文引以为核心的更新管线已被官方放弃。第三方审查(mem0ai/mem0 issue #7002,基于 OSS 2.0.15 commit 50bdaae)进一步指出:update()/delete() 不在 add() 路径上,DEFAULT_UPDATE_MEMORY_PROMPT 只有测试代码可达,冲突处理实际无人负责。读论文时要意识到它描述的是 2025 年的旧架构。
README 宣称新算法 LoCoMo 92.5、LongMemEval 94.4。
README 自己标注这些分数来自 Mem0 托管平台(managed platform),包含开源 SDK 里没有的 proprietary optimizations,开源用户"不应期待相同数字";评测框架已开源在 mem0ai/memory-benchmarks,但托管平台的内部优化无法核查。另外仓库 issue 区可见大量向量后端的正确性 bug(如 #7130 supabase 相似度反序、#7123 dedup 硬编码 top-10 导致大库重复记忆),工程质量与"production-ready"的宣传之间有差距。

与我们方向的关系

对 continual-learning 方向,Mem0 代表"外置记忆 + LLM 管理读写"这条不改参数的路线的工程现状:抽取-合并-检索的记忆条目化,比对原始对话做 RAG 提升约 10 个点,同时把 token 成本压到 full-context 的 1/4 以下。值得借鉴的是它的成本-质量权衡框架(J 分 vs p95 延迟 vs 记忆 token 数三轴对比),这比只报准确率的评测诚实。

更有教益的其实是它的演化:论文精心设计的 UPDATE/DELETE 冲突消解在生产中被 ADD-only + 检索期消歧取代——说明"写入时维护一致性"在 LLM 判断不可靠时反而是负担,把复杂度移到检索端(多信号融合 + 时序感知排序)更稳。做记忆系统实验时,LOCOMO 数字的公信力有限(Mem0/Zep 之争),建议同时上 LongMemEval 等多个基准,并自查评测配置对基线是否公平。

阅读笔记

读法建议:方法部分只需读 proposed_work.tex(机制简单,一页图就够);结果表里 full-context 一行是理解全文定位的钥匙——Mem0 卖的不是最高分而是 91% 的延迟节省。用开源版时注意:论文 ≠ 当前代码,v3 的行为(ADD-only)以 docs.mem0.ai 的 migration guide 为准;自托管选向量后端前先搜 issue 区该后端的正确性 bug。

材料清单

TeX 源码
已存档:Raw/mem0/source/
代码仓库github.com/mem0ai/mem0
64355★ · 最近推送 2026-08-28
项目主页 / 报告mem0.ai
Zep 的反驳文章blog.getzep.com/lies-damn-lies-statistics-is-mem0-really-sota-in-agent-memory/
质疑 Mem0 对 Zep 的评测配置及 LOCOMO 基准本身;结合 Mem0 在 getzep/zep-papers issue #5 的回击一起看
官方评测框架github.com/mem0ai/memory-benchmarks
LoCoMo/LongMemEval/BEAM 的开源评测代码,可复现 README 数字的开源部分
第三方去重机制审查github.com/mem0ai/mem0/issues/7002
竞品 Mnemoverse 的作者对 Mem0 OSS 写入路径的逐行审读(利益冲突已声明),证实 UPDATE/DELETE 已不在 add() 路径上

同类条目