论文
记忆机制
Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
Mem0:面向生产环境的 agent 长期记忆层
Prateek Chhikara, Dev Khant, Saket Aryan, Taranjeet Singh, Deshraj Yadav · Mem0 AI · arXiv · 2025-04 · 被引 579
一句话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。机制与做法
抽取阶段:从消息对到候选记忆
每收到一对新消息(用户消息 + 助手回复),系统构造 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 卖的是质量-延迟权衡,不是绝对最高分。更新阶段: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 反而略降,作者自己也承认图结构在简单检索上是开销。
关键结果
- LOCOMO overall LLM-as-a-Judge:Mem0 66.88%、Mem0g 68.44%,高于 Zep 65.99%、最强 RAG 配置约 61%、LangMem 58.1%、OpenAI 记忆功能 52.9%、A-Mem 48.4%;但低于 full-context 的 72.90%。
- 标题性的 "26% relative improvement over OpenAI" 是相对 OpenAI ChatGPT 记忆功能(52.9)而言,不是相对最强基线。
- 延迟是最大卖点:Mem0 检索 p95 仅 0.20s、端到端 p95 1.44s,比 full-context 的 17.1s 低约 91%;Mem0g 为 2.59s。LangMem 检索 p95 高达 59.8s。
- 记忆存储开销:Mem0 平均每段对话约 7k tokens,Mem0g 约 14k,full-context 26k,而 Zep 的图记忆超过 600k(每个节点缓存全量摘要导致冗余)。
- 分项:Mem0 在 single-hop(J 67.13)和 multi-hop(J 51.15)最强;Mem0g 在 temporal(J 58.13, F1 51.55)最强;open-domain 上 Zep(76.60)略胜 Mem0g(75.71)——论文正文承认了这点,与摘要"在四类问题上全面超越"的说法不一致。
- 实验配置:GPT-4o-mini 做抽取/更新/回答,m=10 条近期消息,s=10 条相似记忆,图库用 Neo4j。
实证核查
有水分作为开源记忆层的工程价值是实打实的(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/
同类条目