26% 的真相：Mem0 論文、Benchmark 戰爭，和 Graph Memory 的承諾與現實

「26% accuracy boost.」

這個數字出現在 Mem0 的融資 pitch deck、TechCrunch 報導、AWS 合作公告、GitHub README。它支撐了一家公司的 $24M Series A、41K GitHub stars、和 AWS Strands SDK 獨家合作夥伴的地位。

但 26% 到底是怎麼算出來的？跟誰比的？在什麼條件下測的？

這篇文章要把這個數字拆到底。

兩階段 Pipeline：簡潔的設計

先看 Mem0 最核心的東西——記憶的「寫入」機制。

在 上一篇 我用一句話帶過了 Mem0 的 extraction pipeline。這次我們拆開來看每一步。

Stage 1：Extraction（提取候選記憶）

每次對話後，Mem0 不是把整段對話丟給 LLM 去「摘要」，而是精心組裝三個 context 來源，再讓 LLM 從中提取值得記住的事實：

Rolling Summary 是在背景非同步更新的——不會阻塞推理。這是個不錯的工程決策：summary 不需要即時精確，稍微落後幾個 turn 也沒關係。

Stage 2：Update（決定怎麼更新記憶庫）

提取出候選事實後，每個事實會跟 vector DB 中最相似的 top-s 條記憶做比對。然後 LLM 透過 tool call 決定四種操作之一：

整個 pipeline 長這樣：

對話結束
  ↓
[Extraction LLM] ← Latest Exchange + Rolling Summary + Recent Window
  ↓ 候選事實
[Vector Search] ← 每個事實 vs 記憶庫 top-s
  ↓ 候選事實 + 相似記憶
[Update LLM] → Tool Call: ADD / UPDATE / DELETE / NOOP
  ↓
Vector DB（+ 可選 Graph DB）

Sr/Staff 視角：為什麼用 LLM 做 operation classification？

這個問題值得停下來想一下。四個操作（ADD/UPDATE/DELETE/NOOP）看起來很適合用 rule-based 系統——比方說設一個 cosine similarity 閾值，超過 0.95 就 NOOP，0.7-0.95 就 UPDATE，低於 0.7 就 ADD。

但 Mem0 選擇了 LLM。 為什麼？

因為 UPDATE 和 DELETE 需要語義理解。「使用者搬到 SF」跟「使用者住在紐約」的 cosine similarity 可能很高（都是關於居住地），但語義關係是矛盾，不是互補——應該 DELETE 而不是 UPDATE。rule-based 系統很難區分「互補」和「矛盾」。

Trade-off 是什麼？ 每次對話的 ingestion 需要兩次 LLM call。50 輪對話 = 100 次 LLM call，光是記憶管理就會產生可觀的成本。這也是為什麼後面的成本分析很重要。

LOCOMO Benchmark 拆解：那個 26% 到底怎麼算的

Mem0 引以為傲的 26% 來自 LOCOMO（Long-term COnversational MeMOry）benchmark。先看這個 benchmark 在測什麼。

Benchmark 設計：

• 10 段長對話，每段約 600 個 dialogue turns、26,000 tokens
• 每段對話附帶約 200 個測試問題，含標準答案
• 4 種問題類型：single-hop（單跳）、multi-hop（多跳）、temporal（時間推理）、open-domain（開放式）
• 評分方式：LLM-as-a-Judge（J score）——用 LLM 對比答案與標準答案打分

關鍵結果：

那個 26% 是這樣算的：

Mem0 Base 的 66.9% vs OpenAI Memory 的 52.9%。

(66.9 - 52.9) / 52.9 ≈ 26.5% 相對改善。

不是絕對值差 26 個百分點。是相對改善率。

這在學術論文裡不算作弊——用相對改善是常見做法。但在行銷材料裡就容易讓人產生「準確度高了 26%」的錯覺。

更尷尬的事

Full Context 拿到了 ~73%，比 Mem0 的 66.9% 還高。

什麼是 Full Context？就是不用任何 memory 系統，把整段 26K tokens 的對話歷史全部塞進 context window。暴力解法，沒有任何巧思。

但它贏了。

這不是說 Mem0 沒用——Full Context 的 p95 延遲是 17.12 秒，token 成本是 ~26K/次。Mem0 是 1.44 秒延遲、~1.8K tokens。效率優勢巨大，但準確度不如「全塞」。

這引出一個核心問題：LOCOMO 的 26K tokens 在現代 LLM 的 context window 內可以直接處理。 GPT-4 Turbo 128K、Claude 200K、Gemini 2M——26K tokens 根本不算長。這個 benchmark 真的在測「記憶」能力嗎？還是在測「在 26K tokens 裡找答案」的能力？

各題型拆解

值得注意：Mem0ᵍ 在 single-hop 上反而比 base Mem0 差。 論文自己也承認這一點——加了 graph 之後，簡單查詢反而被 graph traversal 的 noise 干擾了。

Benchmark 戰爭：Zep 反擊

學術 benchmark 通常是安靜的數字比較。但 Mem0 的論文捅了馬蜂窩——它把 Zep 列為對照組之一，而且 Zep 的分數不太好看。

Zep 不幹了。

Zep 的指控

Zep 創辦人發了一篇 blog，標題是 “Lies, Damn Lies, & Statistics: Is Mem0 Really SOTA in Agent Memory?”——引用 Mark Twain 的名言，火藥味十足。

核心指控：

1. 錯誤實作 Zep：Mem0 的論文在跑 Zep 對照組時，把本該 concurrent 的搜尋跑成了 sequential，人為拉高了延遲
2. 分數偏低：Zep 自己跑同一個 benchmark 拿到 75.14%，遠高於 Mem0 論文報告的 65.99%
3. System Prompt 不一致：Mem0 論文修改了 system prompt 和 retrieval template，偏離了其他 baseline 使用的標準設定

Zep 的結論：如果正確實作，Zep 不僅贏 Mem0，還贏 Full Context。

Mem0 的反擊

Mem0 共同創辦人 Deshraj Yadav 在 GitHub Issue #5 上回擊，標題同樣不客氣：“Revisiting Zep’s 84% LoCoMo Claim: Corrected Evaluation & 58.44% Accuracy”。

核心發現： Zep 在計算 J score 時，把 adversarial category（對抗性問題）也算進去了。LOCOMO benchmark 的標準做法是只計算 Category 1-4（single-hop、multi-hop、temporal、open-domain），排除 adversarial。

修正後的數字：

從 75.14% 到 58.44%——差距來自於是否包含 adversarial category。

我的判斷

兩邊都有問題。

• Zep 包含 adversarial category 是方法論錯誤。 這一點是明確的。
• 但 Mem0 的 Zep 實作是否正確，外人很難驗證。 Sequential vs concurrent search 確實會影響效能表現。
• 更根本的問題是 benchmark 本身。 LOCOMO 的 26K tokens 在 2026 年的 context window 標準下根本不算「長期記憶」。Full Context 暴力全塞就能拿 ~73%，這說明 benchmark 的區分度不夠。

真正的 takeaway：不要看 benchmark 數字選工具。 兩家公司互相指控對方作弊，最終只證明了一件事——benchmark 只對 benchmark 有效。你的場景跟 LOCOMO 不一樣，你的對話長度、問題類型、延遲要求都不一樣。

Mem0ᵍ：Graph Memory 的承諾與現實

這是我最想拆開的部分。上一篇文章中，Graph-based 流派的核心主張是：記憶不是一堆孤立的事實，而是有結構的知識網路。 Mem0ᵍ 就是這個主張的具體實作。

架構

Mem0ᵍ 在 base pipeline 之上加了一層 Knowledge Graph：

1. Entity Extraction：用 LLM 從對話中提取實體（人名、地點、概念）
2. Relationship Generation：另一個 LLM 評估實體對之間的關係，標上 label（lives_in、prefers、works_at）
3. Storage：Entity 存為 Node，Relation 存為 Edge，寫入 Graph DB（Neo4j、Memgraph、Neptune 等）
4. Conflict Resolution：當新資訊與舊關係矛盾時，舊事實被標記為失效而非刪除——保留時間軸

Retrieval 是 dual path：

• Entity-centric：先分析 query 涉及哪些 entity，從 graph 中拉出相關 node 及其鄰居
• Semantic triplet：同時用 vector search 找相似的三元組

兩條路徑的結果合併，提供給 LLM 生成回答。

尷尬的數據

理論很美。但數據呢？

Mem0ᵍ 只比 base Mem0 好了大約 2%。（68.4% vs 66.9%）

更尷尬的是逐項分析：

Multi-hop 更差，這一點讓人難以接受。 Knowledge Graph 存在的意義就是把跨實體的關係串起來，讓「A 認識 B，B 在 C 公司工作，C 公司在 D 城市」這種多跳問題能被回答。結果 Mem0ᵍ 在這上面反而退步了。

論文自己的原話：「graph memory yields marginal performance drop on single-hop queries」。但論文沒有深入解釋為什麼 multi-hop 也沒有顯著改善。

延伸思考

還記得上一篇提到的一個發現嗎？Letta 的研究中，Agent 用基本 filesystem 操作（74.0%）打敗了用 Mem0 graph memory 的 Agent（68.5%）。

兩個獨立的研究結果都指向同一個結論：Graph Memory 的 ROI 遠低於預期。 加了 Graph DB、Graph Extraction、Graph Traversal——一堆額外的複雜度和延遲——最後只換來 ~2% 的改善，甚至在某些場景下退步。

這不是說 Knowledge Graph 沒用。Zep 的 Graphiti 在 temporal reasoning 上確實有優勢，因為它從一開始就為時間軸設計（bi-temporal model）。問題是 Mem0ᵍ 的 graph 是「後加的」——base pipeline 本來就夠用了，graph 是 bolt-on 而非 built-in。

從論文到生產

學術數據看完了，回到工程師最關心的問題：真的要用 Mem0 的話，怎麼部署？踩什麼坑？花多少錢？

兩種部署模式

Self-hosted 的架構是三個 Docker container：FastAPI（API server）+ PostgreSQL/pgvector（vector store）+ Neo4j（graph store，可選）。

安全坑：一定要注意

Self-hosted 預設配置有兩個問題：

1. 無認證：API server 出廠不帶任何 auth
2. CORS: allow_origins=["*"]：任何 origin 都能呼叫

這不是 Mem0 獨有的問題——很多開源專案都預設「方便開發」。但如果你直接上 production 而沒加 reverse proxy + auth，你的記憶庫就是對全世界開放的。

AWS Strands 整合

Mem0 是 AWS Strands Agents SDK 的官方記憶供應商。整合很簡單：

from strands import Agent
from strands.models import BedrockModel
from mem0 import MemoryClient

# 初始化 Mem0
memory = MemoryClient(api_key="m0-xxx")

# 建立 Agent
model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0")
agent = Agent(model=model)

# 對話後儲存記憶
response = agent("I prefer dark mode and use Kotlin")
memory.add(response, user_id="user-123")

# 下次對話前載入記憶
memories = memory.search("user preferences", user_id="user-123")

如果你已經在 AWS 生態系（Bedrock、Lambda、Fargate），Mem0 幾乎是阻力最小的記憶方案。

成本模型

這是很多人忽略的部分。Mem0 的記憶管理不是免費的：

每次對話 = 1 次 Extraction LLM call + 1 次 Update LLM call = 2 次 LLM call

50 輪對話 = 100 次 LLM call（純記憶管理，不含對話本身）

加上 vector search、graph operations（如果用 Mem0ᵍ）、embedding 生成——記憶管理的成本可能佔到你 Agent 總成本的 20-30%。

對比 Observational Memory（Mastra）的「壓縮 + prompt cache」方案，Mem0 的 per-conversation 成本顯著更高。但 Mem0 的跨 session 能力是 Mastra 沒有的——不同場景，不同 trade-off。

v2.4.0 新功能（2026-03）

immutable memories 是個有意思的功能——某些核心事實（使用者身份、合規要求）你不希望被 LLM 意外刪除或修改。

結語：我的選型建議

研究完 Mem0 的論文、benchmark 爭議、和 production 現實之後，我的結論：

Mem0 的真正價值不是 Graph Memory——那個 ROI 太低。真正的價值是 base pipeline 的簡潔性。

兩階段 pipeline（Extraction → Update）是一個優雅的設計。它把「記住什麼」這個問題拆成了明確的步驟，每一步都可以 debug、可以替換 LLM、可以調參數。比起 Letta 的 Agent 自主管理（黑盒）或 Mastra 的壓縮（有損），Mem0 的 pipeline 是最容易理解和掌控的。

具體建議：

最重要的 takeaway：

不要看 benchmark 數字選工具。

26% 是 Mem0 vs OpenAI Memory 在 LOCOMO 上的相對改善，用 LLM-as-a-Judge 評分。Zep 說自己才是最高分，Mem0 說 Zep 算錯了。兩邊互指對方作弊。Full Context 暴力全塞反而比兩家都高。

看你的場景。 你的對話多長？需不需要跨 session？延遲容忍度多少？預算多少？回答了這些問題，答案自然浮現。

完美的 memory 系統不存在。但「先上線，再迭代」是工程師最好的策略——比在 benchmark 數字上糾結有用得多。

參考資料

1. Mem0: Memory Layer for AI Agents (arXiv:2504.19413) — Mem0 核心論文，26% accuracy boost 數據來源
2. Zep: Is Mem0 Really SOTA in Agent Memory? — Zep 對 Mem0 benchmark 的質疑
3. Revisiting Zep’s 84% LoCoMo Claim (GitHub Issue #5) — Mem0 對 Zep 的反擊
4. AWS + Mem0 Strands Partnership — AWS 官方合作公告
5. Mem0 Raises $24M Series A (TechCrunch) — 融資報導
6. Mem0 Official Docs — 技術文件
7. Zep: A Temporal Knowledge Graph Architecture (arXiv:2501.13956) — Zep/Graphiti 論文
8. Letta: Benchmarking AI Agent Memory — Filesystem 打敗 Graph Memory 的研究

這是「AI Agent 架構實戰」系列文章。上一篇：2026 AI Agent Memory Wars：三大流派的技術對決。下一篇敬請期待。