# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：mem0 (@mem0ai) · 平台：X (Twitter) · 日期：2026-04-18

> 原始來源：https://x.com/mem0ai/status/2044823522560901120

## 中文摘要

# 我們是如何打造高 token 效率的記憶演算法

全新的 @mem0ai 記憶演算法在 LoCoMo、LongMemEval 和 BEAM 測試中達到了極具競爭力的準確度，且每個查詢使用的 token 數不到 7,000 個（約減少了 3–4 倍的 token 使用量），而大多數系統的運作量都在 25,000 個以上。
完全開源。
以下為你解析其運作原理 ↓

---

大多數 AI Agent 的記憶系統透過最大化 context window 的大小來檢索資訊。這在基準測試中行得通，但在生產環境中卻不然，因為每個 token 都會增加成本。所謂的 token 效率，是指在每個查詢使用較少 context 的情況下，依然能達到高準確度。

我們全新的記憶演算法在 LoCoMo、LongMemEval 和 BEAM 基準測試中，在每次檢索呼叫使用不到 7,000 個 token 的情況下，實現了極具競爭力的準確度。作為對比，這些基準測試中的全 context 方法通常每個查詢會消耗 25,000 個以上的 token。

這項新演算法即日起可在 Mem0 平台及開源 SDK 上使用。

---

Mem0 新演算法摘要（2026 年 4 月）

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776479844472-iaHGAGxtWbwAA6pN7png.png)

---

## 打造實用的 Agent 記憶

要做好記憶，意味著必須同時解決三個問題：提取（extraction）、檢索（retrieval）和推理（reasoning）。大多數系統只優化了檢索，這就是為什麼它們的效能會停滯不前。該領域主流的架構框架（儲存、嵌入、檢索）並未涵蓋記憶系統在面對數百萬次真實互動時必須處理的工作。本次發布的架構決策深受以下兩個案例影響：

試想一位使用者連續兩個月每週五都訂同一家泰式餐廳。檢索系統儲存了八筆「週五訂了泰式炒河粉」的紀錄，並且能精確告訴你 3 月 8 日發生了什麼事。但如果你問它該為這位使用者預訂哪裡的晚餐，它卻束手無策。一個好的記憶系統應該在幾週前就該發現這個人熱愛泰式料理，並且有固定的週五晚餐去處。

或者試想一位使用者的個人資料顯示他住在紐約。六個月後，新資料顯示他搬到了舊金山。大多數記憶系統將變更視為替換：舊的事實被覆蓋。但知道使用者從紐約搬到舊金山，比單純知道他目前的城市更有價值。一個真正理解 context 的系統應該保留這兩個事實，理解其中存在過渡，並知道提到「你以前的社區」時是指紐約，而「你目前的位置」則是指舊金山。

這次發布將 Mem0 推向了一個統一的記憶系統，讓提取、檢索和推理協同工作，而不是作為獨立的階段。

## 我們的做法：階層式記憶

檢索會同時對所有層級進行評分並融合結果。像「Alice 對遠端工作有什麼看法？」這樣的問題，依賴於實體匹配；「我上週開了哪些會議？」則取決於時間理解；「使用者對這個專案的態度有何轉變？」則需要跨越許多零散記憶的高階推理。

本次發布在現有的句子層級檢索之上，加入了實體層級匹配。我們計畫接下來加入行為模式匹配。

提取和檢索是非同步執行的，因此 Agent 不會消耗額外的運算資源來管理自己的 context。

# 有什麼改變

## 1. 單次傳遞、僅新增（ADD-only）的提取

舊演算法透過兩次 LLM 傳遞來提取記憶。第一次從輸入中識別候選事實，第二次使用 ADD、UPDATE 和 DELETE 操作將這些事實與現有記憶進行協調。那個協調步驟很慢，也是 context 被破壞的地方。覆蓋操作有時會抹除原始事實中的關鍵資訊；刪除操作有時會移除未來可能相關的資訊。

通常，記憶系統將變更視為替換。當新事物發生時，舊的事實被覆蓋，導致資訊丟失。僅新增（ADD-only）的提取保留了狀態變更的完整歷史紀錄，因此系統可以推理事物是如何演變的，而不僅僅是它們最終的狀態。

新演算法將提取過程簡化為僅執行一次 LLM 呼叫，且只進行新增操作。每個提取出的事實都成為獨立的紀錄。當資訊發生變更時，新的事實會與舊的事實並存，兩者皆被保留。這將提取延遲大約減少了一半，並產生了更好的記憶，因為模型將運算能力花在理解輸入上，而不是與現有狀態進行差異比對。

## 2. Agent 產生的事實現在被視為一等公民

Mem0 現在將 Agent 產生的事實視為一等公民。以前，當 Agent 說出類似「我已為你預訂了 3 月 3 日的航班」之類的話時，舊系統通常會完全忽略它，只專注於使用者明確陳述的內容。

新演算法會儲存 Agent 產生的事實（例如確認行動或提供建議），並給予同等權重，填補了記憶覆蓋範圍中的一個重大缺口。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776479844488-iaHGAHK7BaAAEdckkpng.png)

## 3. 實體連結（Entity linking）

現在，每項記憶都會被分析其中的實體，包括專有名詞、引號內的文字和複合名詞短語。這些實體會被嵌入並儲存在一個獨立的查詢層中，連結關於同一個人、地點或概念的記憶。在查詢時，從查詢中識別出的實體會與該層進行匹配，相關的記憶會獲得排名加權。

## 4. 多訊號檢索

檢索堆疊會同時執行三種評分傳遞：語意相似度、關鍵字匹配和實體匹配，並融合這些結果。不同的查詢依賴不同的訊號，而組合後的評分優於單一訊號的評分。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776479844496-iaHGAHTLcaQAA1uqJjpg.jpg)

## 5. 關鍵字標準化

像「我參加了哪些會議？」這樣的查詢，過去無法匹配到包含「參加會議（attending a meeting）」的記憶，因為關鍵字搜尋將動詞變位視為不同的 token。動詞形式標準化解決了這個問題。這是一個小小的改動，但影響顯著。

# 結果

所有結果皆為新舊演算法在單次傳遞檢索設定下的對比：一次檢索呼叫、一個答案、沒有 Agent 循環。由於評分者不一致，分數帶有 ±1 分的信賴區間。

分數反映了 Mem0 的託管平台表現，其中包含開源 SDK 中未提供的專有優化。開源使用者應預期會有方向性相似的提升，但數值不會完全相同。完整的評估框架是開源的，因此任何人都可以獨立重現這些數據。

如何解讀這些數據

在大規模環境下評估記憶系統，歸結為三個參數：

- 準確度（基準測試測量的內容），

- 成本（每個查詢的 context token 數），以及

- 效能（延遲）。

優化其中一項很容易，但在大規模環境下平衡這三者才是真正的難題。

目前的一些基準測試，特別是像 LoCoMo 和 LongMemEval 這樣較小的測試，可以透過激進的檢索策略、更大的 context window 或前沿模型來實質提升。這並不一定意味著底層記憶系統變得更好。我們的目標是在反映記憶系統在生產環境中實際運作的限制下進行測試：有限的 context window 和實際的 token 預算。

BEAM 是這裡最相關的基準測試。它在 100 萬和 1,000 萬 token 的規模下運作，無法僅透過擴大 context window 來解決。1,000 萬規模下的結果反映了記憶系統在生產環境 context 容量下的真實水準。

## LoCoMo

LoCoMo 測試跨對話階段的單跳、多跳、開放領域和時間記憶回憶。

所有結果皆為新舊演算法對比

Mem0 新演算法在 LoCoMo 上的結果（2026 年 4 月）：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776479844491-iaHGAHsnOa4AAZTO6png.png)

平均 token 數：6,950

兩個最大的提升在於時間查詢（+29.6）和多跳推理（+23.1）。對於開發者而言，這意味著新演算法能更可靠地處理諸如「使用者第一次提到 X 是什麼時候？」或「是什麼導致了使用者目前的決定？」這類問題。這兩個類別直接測試了僅新增（ADD-only）架構和實體連結層。

## LongMemEval

LongMemEval 評估跨單一階段和多階段 context 的記憶，包括知識更新和時間推理。

Mem0 新演算法在 LongMemEval 上的結果（2026 年 4 月）：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776479844482-iaHGAIHEVbAAEuhpOpng.png)

平均 token 數：6,787

最大的提升在於單一階段助手（+53.6）、時間推理（+42.1）和知識更新（+16.7）。助手記憶回憶的跳躍意味著新系統能可靠地記住你的 Agent 說過的話。這是開發者通常認為「應該會自動運作」直到實際測試後才發現問題的地方。舊演算法對 Agent 產生的事實存在盲點，而新演算法則沒有。

單一階段助手獲得 100.0 分反映了一個較小的評估集，其中針對性的修復解決了該類別的問題。

## BEAM

BEAM 在 100 萬和 1,000 萬 token 的規模下，針對十個任務類別評估記憶系統，包括偏好遵循、時間推理和矛盾解決。它是唯一在生產環境 AI Agent 實際遇到的 context 容量下運作的公開基準測試。

Mem0 新演算法在 BEAM 上的結果（2026 年 4 月）：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1776479844526-iaHGAIPPkbMAAJOcBpng.png)

平均 token 數（100 萬）：6,719
平均 token 數（1,000 萬）：6,914

在 100 萬規模下的效能明顯強於 1,000 萬規模。在 1,000 萬規模下，檢索變得更加困難，因為相似的內容會在視窗中多次出現，記憶系統並不總能在其他相近的匹配項中找出最準確的記憶。

觀察類別細分，該系統在兩個規模下的偏好遵循、指令遵循和知識更新方面都表現良好。這些任務受益於僅新增（ADD-only）架構，能乾淨地保留長期的狀態。在 1,000 萬規模下表現較弱的類別是時間推理、事件排序和多階段推理。這些在整個領域中仍是待解的問題。事實層級和實體層級的匹配對它們來說還不夠。它們需要更高階的表示法來描述事件如何隨時間相互關聯，這也是我們持續研究的重點。

## 下一步

目前系統的主要限制在於，事實層級和實體層級的檢索對於最困難的長距離記憶任務仍然不足。最弱的領域仍然是大規模下的時間推理、事件排序和多階段推理。接下來的工作方向是：

- 更豐富的時間表示法

- 更好的跨階段事件結構建模

- 更具表達力的檢索融合

- 與 Agent 工作流程更緊密的整合

本次發布在實際的 token 預算下提升了提取效率和檢索品質。剩餘的工作在於如何表示資訊隨時間的變化，並在大規模環境下可靠地利用該結構。如果你對這類系統問題感興趣，歡迎加入我們。

GitHub | 評估儲存庫 | 研究 | 文件

---

mem0 是一個智慧型開源記憶層，專為 LLM 和 AI Agent 設計，旨在跨階段提供長期、個人化且具備 context 感知的互動。

- 在此獲取免費 API Key：app.mem0.ai

- 或從我們的開源 GitHub 儲存庫自行託管 mem0

## 標籤

開源專案, Agent, Benchmark, Mem0