•
MemPalace 記憶宮殿架構：逐字儲存、AAAK 壓縮方言、與 LongMemEval 96.6% 的工程哲學
18 分鐘閱讀 •
今天要講的是一個記憶系統專案，它的核心主張很特別
「原始文字加上好的向量索引，效果勝過讓 LLM 先理解再儲存」
聽起來太粗暴了，但 benchmark 數字支持這個說法
MemPalace v3.0.0 在 2026 年 4 月 6 日發佈，是一個完全本地執行的 AI agent 記憶系統，依賴 Python 3.9+ 和 ChromaDB，不需要任何外部 API key。它在 LongMemEval 上達到 96.6% R@5 的零 LLM 最高分，在 ConvoMem 上以 92.9% 超過 Mem0 的 30-45% 兩倍以上。MIT 授權，程式碼完全公開。
多數記憶系統的設計邏輯是「先理解再儲存」。MemMA 用 probe QA 生成和語意合併來建構記憶，MLMF 把對話壓縮成三層認知結構，Oblivion 用 Recognizer 從對話中提取結構化事實。這些系統都在儲存端做了資訊轉換，每一次轉換都有遺失細節的風險。MemPalace 走了相反的方向，把原始對話逐字存入 Drawer（抽屜），然後在 Closet（衣櫃）層產生壓縮摘要，但原文永遠保留。
這篇文章是我對 MemPalace 的架構分析，以及它和近期其他記憶系統的比較。
宮殿隱喻的工程實現
MemPalace 用建築空間來組織記憶。每一層隱喻對應一個具體的資料結構，而這種結構化分類在 benchmark 測試中帶來了可量化的檢索改善。
最頂層的分區是 Wing（翼），每個人或專案獲得獨立的 Wing，相當於為不同的對話對象建立完全隔離的記憶空間。Specialist agent（審閱者、架構師、運維人員）也各自獲得獨立 Wing。Wing 內分為五種 Hall（廳），對應五種記憶類型，分別是 facts、events、discoveries、preferences、advice。Hall 內再分為 Room（房間），每個 Room 是特定主題的容器。
Room 內部有兩層儲存。Closet（衣櫃） 存放以 AAAK 壓縮方言寫成的摘要，Drawer（抽屜） 存放逐字原文。檢索流程是先在 Closet 層做向量搜尋定位相關 Room，再從對應的 Drawer 取出原始文字。這種兩階段檢索兼顧了搜尋速度和回傳精確度。
最後是 Tunnel（隧道），跨 Wing 的連接。當不同人或專案之間存在關聯時，Tunnel 允許記憶跨越隔離邊界。這是多數記憶系統缺乏的設計。MemMA 的記憶空間對每個任務是扁平的，Oblivion 的叢集結構也沒有跨人物的連接機制。
這個宮殿隱喻乍看像是裝飾性的命名
但消融實驗的數字很有說服力
移除 Wing 和 Room 過濾後，檢索準確率從 94.8% 降到 60.9%
結構化分類貢獻了 +34% 的絕對提升
四層記憶堆疊與 Token 預算管理
MemPalace 用四層堆疊來管理 context window 的 token 分配。
L0（身份層） 約 50 token，是 agent 的核心身份描述，每次對話都載入。L1（關鍵事實層） 約 120 個 AAAK token，同樣每次對話都載入。這 120 個壓縮 token 展開後約等於 1000 個英文 token 的資訊量。L2（房間召回層） 按需載入，當對話觸及特定主題時，從對應 Room 的 Closet 檢索摘要。L3（深度搜尋層） 也是按需的，觸發完整的向量搜尋和 Drawer 原文檢索。
L0 + L1 始終佔用約 170 token，這個基礎 token 成本極低。相比之下，Oblivion 的 L₁ 程序記憶需要在每輪對話中參與 Decayer 計算，MLMF 的三層融合需要在每次查詢時計算 softmax 加權。MemPalace 的做法是把「永遠需要的資訊」壓縮到極致，讓大部分 context window 留給當前對話。
AAAK 壓縮方言
AAAK 是 MemPalace 中最獨特的元件，一種專為 AI agent 設計的無損速記語言，程式碼在 dialect.py 中實現（1050 行 Python）。
它的三個設計原則分別是 30 倍壓縮率、零資訊損失、LLM 原生可讀。1000 token 的英文內容壓縮到約 120 token，任何能讀文字的 LLM 都能理解 AAAK 格式，不需要特殊解碼器。
30 倍壓縮還零損失 🤯
這有點難以想像欸
AAAK 去除的是自然語言的冗餘，冠詞、連接詞、禮貌用語
保留的是純粹的語意結構和事實
概念上比較像是速記術而不是壓縮演算法
任何 LLM 都已經「理解」省略語法，所以展開的時候不需要訓練
AAAK 的存在讓 Closet 層的摘要更接近結構化的壓縮編碼，和傳統自然語言摘要有本質上的不同。「摘要」和「原文」之間的關係更接近「索引」和「全文」。這個設計解決了 agent 記憶系統中的一個實際瓶頸，也就是 context window 的 token 限制。在需要載入大量記憶的場景下（例如同時處理多個 Wing 的交叉查詢），壓縮率的累積效果很顯著。
SQLite 時序知識圖譜
knowledge_graph.py（384 行 Python）實現了一個基於 SQLite 的時序實體關係圖。核心結構是實體表加上三元組表（主體, 關係, 客體），每個三元組帶有 valid_from 和 valid_to 時間戳。
時間有效性視窗是這個知識圖譜和多數靜態知識圖譜的差異。Zep 使用的 Neo4j 儲存靜態關係，MemPalace 的三元組帶有時間範圍，可以回答「在 2025 年 3 月的時候 Bob 住在哪裡」這類時序查詢。系統還支援矛盾偵測，當新事實與既有三元組衝突時會標記矛盾，並做動態計算（例如年齡、任職年數）。
整個知識圖譜跑在 SQLite 上，成本是零。Zep 的 Neo4j 每月至少 $25，對個人開發者或小型專案來說，這個成本差異有實際意義。
Auto-Save 機制
MemPalace 為 Claude Code 提供了兩種自動存檔 hook。Save Hook 每 15 條訊息觸發一次自動存檔。PreCompact Hook 在 context window 壓縮之前觸發，把即將被壓縮掉的脈絡先存入 Palace。
PreCompact Hook 的設計有實際價值。Claude Code 在 context window 接近上限時會自動壓縮歷史脈絡，這個過程會丟失細節。MemPalace 在壓縮發生前攔截，把完整脈絡搬進 Drawer，相當於在記憶體被回收前做一次快照。
這種設計和 Oblivion 的 Write Path 有結構上的相似。Oblivion 的 Recognizer 也在每輪結束時做記憶更新，差異在於 MemPalace 保存的是逐字原文，Oblivion 保存的是 LLM 提取的結構化事實。
Benchmark 結果與誠實揭露
MemPalace 在 BENCHMARKS.md 中提供了非常詳細的測試過程紀錄（724 行），坦誠程度在記憶系統專案中罕見。
LongMemEval
原始分數 96.6% R@5，500 題中答對 483 題，零 API、零 LLM rerank，是已發表的零 LLM 最高分。加入 Haiku rerank 後達到 100%（500/500），是第一個完美分數。作者建議的誠實持出分數是 98.4% R@5（450 題未見過的問題，hybrid v2，無 rerank）。
作為對照，Oblivion 在 LongMemEval 上報告 90.60%（S 設定），但 Oblivion 的 Read Path 依賴 LLM-as-a-judge 做不確定性估計。MemPalace 的原始分數純粹來自向量搜尋和結構化過濾。
從 96.6% 到 100% 的演進
作者紀錄了五個 hybrid 版本的逐步演進。v1 加入 keyword overlap，97.8%。v2 加入 temporal boost，98.4%。v3 加入偏好提取（16 個 regex 模式），99.4%。v4 針對 3 個失敗問題做修正，100%。
作者坦承 v4 的 3 個修正是 teaching to the test。他們檢視了具體失敗的問題後做了針對性修正，因此建議 98.4% 作為誠實發表數字。這種透明度在記憶系統的 benchmark 報告中極為少見，多數論文只報告最終最佳結果。
ConvoMem 和 LoCoMo
ConvoMem 得分 92.9%，超過 Mem0 的 30-45% 兩倍以上。LoCoMo 原始 60.3%，hybrid v5 提升到 88.9%，Sonnet rerank 後達到 100%。
但作者在 LoCoMo 上揭露了一個結構性限制，top-k=50 超過了 session 數，結構上保證了高召回率。這讓 100% 的數字打了折扣。在 session 數更多的真實場景中，這個結果可能不可重現。
還有一個很有趣的觀察
作者指出 hybrid 方法和 palace 方法分別在 99.4% 處收斂
兩種完全不同的技術路徑達到了相同的分數
這可能意味著剩餘的 0.6% 需要根本不同的方法
與其他記憶系統的設計哲學對比
逐字保存 vs 衰減控制
MemPalace 和 Oblivion 代表記憶系統設計的兩個端點。MemPalace 的立場是「不要丟任何東西」，Oblivion 的立場是「不被存取的記憶應該衰減」。Oblivion 以 Ebbinghaus 遺忘曲線為數學基礎，用保留分數 R_t(c) = exp(-n/S) 控制記憶的可及性。MemPalace 沒有衰減機制，所有原文永久保存。
從 LongMemEval 的數字看，MemPalace 的逐字策略在檢索準確率上佔優（96.6% vs 90.60%）。但 Oblivion 在長期互動的 token 經濟性上可能更好，它報告在 120K 設定下達到 73% 的 token 成本減少。在 context window 寸土寸金的場景下，token 經濟性和檢索準確率之間的取捨是真實的。
結構化儲存 vs 融合式檢索
MLMF 的三層架構（working/episodic/semantic）在儲存端做壓縮，檢索端用 adaptive retrieval gating 做融合。MemPalace 的四層（L0-L3）管理的是 token 預算，真正的結構化組織由 Wing/Hall/Room 完成。
MLMF 有 retention regularization，透過 L_ret = Σ||G_t - G_{t-1}||² 懲罰語意記憶的劇烈漂移。MemPalace 的知識圖譜用時間有效性視窗來記錄變化，但不懲罰變化本身。前者是防禦性的設計（不讓記憶變太多），後者是記錄性的設計（讓記憶變化可追溯）。
隔離式 agent vs 協作式 agent
MemMA 的四角色 planner-worker 架構（Meta-Thinker/Memory Manager/Query Reasoner/Answer Agent）讓多個 agent 協作建構和修復記憶。MemPalace 的 specialist agent 各自擁有獨立 Wing，是隔離而非協作的設計。
MemMA 報告 LoCoMo ACC 81.58。MemPalace 在 LoCoMo 上原始 60.3%，hybrid 模式下 88.9%。MemPalace 在 hybrid 模式下超過 MemMA，但原始模式下低於 MemMA，暗示 MemPalace 的優勢依賴 hybrid 檢索策略。
跨系統同構的可靠性設計模式
比較多個記憶系統後，幾種提升可靠性的共通設計模式浮現。
第一種是結構化過濾先於向量搜尋。MemPalace 的 Wing/Hall/Room 過濾帶來 +34% 提升，Oblivion 的叢集節點閘控也先縮小搜尋範圍再做向量比對。「先分類再搜尋」在所有有報告數字的系統中都是正面貢獻。
第二種是時序感知。MemPalace 的知識圖譜 valid_from/valid_to、Oblivion 的 Ebbinghaus 衰減曲線、MLMF 的情節記憶衰減參數 α，三者在不同層面處理同一個問題。時序資訊的加入在所有系統中都帶來可測量的改善。
第三種是多層冗餘。MemPalace 保留原文加壓縮摘要加知識圖譜三重表示。MLMF 和 Oblivion 也各自保留三層記憶。多層冗餘讓系統在任一層失效時仍有備份資訊源。
局限與開放問題
逐字儲存的磁碟和索引成本隨對話量線性增長。對於超長互動場景（例如 Oblivion 測試的 120K 設定），MemPalace 的儲存成本可能成為瓶頸。
AAAK 方言是一個 1050 行的自訂元件，壓縮品質取決於方言設計的覆蓋度。如果輸入文字包含 AAAK 未預見的語意結構，壓縮效果可能退化。這是自訂壓縮語言相對於標準化方法的固有風險。
所有記憶永久保存意味著系統缺乏原生的「遺忘」機制。在需要刪除特定對話的場景下（例如 GDPR 被遺忘權），MemPalace 沒有提供明確的處理流程。
ChromaDB 是唯一的向量後端。相比 MemMA 宣稱的跨三種儲存後端 plug-and-play，MemPalace 的可移植性較低。
MemPalace 的結果讓我確認了一件事
在記憶系統的設計中，工程執行的品質和理論框架至少同等重要
98.4% 的 held-out 分數不需要 Ebbinghaus 曲線、保留正則化、PDE 場方程式
它需要的是好的向量索引、結構化過濾、和逐字保存原文
不過「什麼都不忘」的哲學讓我想了很久
在 LongMemEval 這類測試中，完美記憶必然佔優，因為測試本身就是在問「你還記得嗎」
但在真實的長期互動中，「記得太多」也可能是問題
使用者可能希望 AI 忘記某些對話，過多的歷史脈絡可能干擾當前判斷
「記住一切」和「適時遺忘」之間的最佳平衡點，還沒有哪個 benchmark 能測量