記憶系統的失效是靜默的：它不拋錯、不掉延遲、不觸發警報，只讓回答變差一點。因此沒有量測的記憶系統在實務上等於沒有品質——你會在使用者抱怨三個月之後才發現召回率一直在下降。這一篇處理兩件事：公開 benchmark 能告訴你什麼（以及明確不能告訴你什麼），以及一套可以在自己專案裡建起來的最小量測。
三個主要 benchmark
LoCoMo（Long-term Conversation Memory）——評估跨多輪 session 的對話回想與推理。它包含 10 段對話，每段 19–32 個 session（每段對話約 9K token），產生 1,986 組問答，分成五類：single-hop（取回單一事實）、multi-hop（跨 session 綜合）、temporal（事件何時發生）、open-ended（需要較長的脈絡回答）、adversarial（正確地拒答無法回答的問題）。
這五類的分類本身很有用，即使不跑這個 benchmark：它們是一份現成的記憶能力檢查清單。多數自建的評測只測 single-hop，因此完全看不見 temporal 與 adversarial 的失效——而後兩者在生產環境的殺傷力更大（拿舊事實當新的、對不知道的事情編造答案）。
LongMemEval——在標準化的長上下文設定下評估使用者—助理互動的長期記憶，借用 needle-in-a-haystack 的範式，每題搭配約 115K token 的互動歷史。它測的主要是「在大量無關內容中找到相關資訊」的能力，比 LoCoMo 更偏向檢索而非記憶治理。
BEAM——第三個被廣泛引用的記憶 benchmark，與前兩者一起構成 2026 年「嚴格意義上的記憶 benchmark」這一組。
Benchmark 的極限：一個必須知道的落差
2026 年公開的結果中，領先方案在 LoCoMo 上約 92.5、LongMemEval 上約 94.4（約每次查詢 6,900 token）。這些數字看起來像是問題已經解決了，而它們不是。
同一批討論裡有一個更重要的觀察：在 LoCoMo 上接近滿分的模型，在 MemoryArena 這類需要「主動使用記憶做決策」的評測上掉到 40–60%。 這個落差被明確描述為「被動回想」與「主動、與決策相關的記憶使用」之間的差距。
這個落差對選型與自建評測有三個直接影響：
不要用 benchmark 分數選框架。 分數高低反映的是在「被問到時能否取回」這個任務上的表現，而多數產品需要的是「在不被問到的時候，agent 有沒有自己想起該遵守的約定」。後者是完全不同的能力，而且沒有標準 benchmark。
adversarial 類別的分數比總分更有資訊。 一個在 adversarial 上表現差的系統，會在生產環境中對不知道的事情自信作答——這比漏召回嚴重得多。
token 數必須與分數一起看。 「92.5 分／6,900 token」與「92.5 分／30,000 token」是差距巨大的兩件事，而多數比較只報前一個數字。這正是 「最小的高訊號 token 集合」 應該被當成品質定義的理由。
自建評測：最小可用的四層
公開 benchmark 用來理解問題，自建評測用來管理自己的系統。這四層依實作成本排序，而且應該按順序建起來。
第一層：組裝軌跡（assemble trace）——當天就能做
每一輪推理記錄「實際注入了哪些記憶、共多少 token」。這就是 schema 草案 裡的 assemble_traces 表。
它本身不是評測，但它是所有後續評測的資料前提。沒有它，「這次回答不好是因為沒召回到，還是召回到了但模型沒用」這個問題無法回答——而這是 debug 記憶問題時最常需要問的第一個問題。
第二層：決策紀錄（decision log）——當天就能做
每一次寫入記錄操作與理由（memory_decisions 表）。用途有兩個：抽樣人工審核寫入品質，以及在「agent 記住了錯的事」時回溯是哪一次寫入、基於什麼理由。
這兩層的共同特徵是它們不需要標註資料、不需要黃金答案，只需要記錄。 這是投報率最高的量測投資，而它在多數實作裡缺席。
第三層：召回黃金集（recall golden set）——一到兩天
建一組 30–100 筆「這個查詢應該召回這條記憶」的配對，跑成回歸測試。做法：從真實流量中挑出記憶相關的查詢，人工標註應該被召回的記憶 ID。
量測兩個數字：命中率（應召回的有沒有出現在結果裡）與精確率（召回的有多少是相關的）。前者的下降代表檢索退化，後者的下降代表庫在膨脹稀釋。 兩者要分開看，因為處方相反——命中率低要改檢索，精確率低要改寫入與歸檔。
這一層應該在 CI 裡跑。 記憶檢索的退化通常來自看似無關的改動（換 embedding 模型、改 chunk 大小、調 top-k），沒有回歸測試會完全發現不了。
第四層：任務層評測（task-level eval）——持續投入
最終標準：在需要用到記憶的端到端任務上，成功率與 token 消耗。 建一組情境（「使用者兩週前說過偏好 X，現在問相關問題」），跑完整流程，判定成功與否。
這一層必須包含 LoCoMo 的五個類別，特別是 temporal 與 adversarial：
- 事實改變後，系統用的是新值嗎？（temporal）
- 對於記憶裡沒有的事情，系統會說不知道嗎？（adversarial）
同時要量測負面情境——這是自建評測最容易漏掉的部分：注入一條錯誤記憶，系統會不會照著做？（記憶投毒的迴歸測試，見 實作陷阱）
可觀測性：四條必須存在的曲線
評測回答「現在好不好」，可觀測性回答「有沒有在變差」。記憶系統的退化是漸進的，因此趨勢比單點數值重要。
記憶條目數（按 scope 與 kind 分組）——成長曲線。線性成長通常正常，超線性成長表示去重或 NOOP 判斷失效。
平均召回 token 數——直接對應成本與 context 壓力。它上升而任務成功率不變，就是純虧損。
召回命中率（來自黃金集的定期執行）——檢索品質的趨勢。
寫入操作分佈（ADD／UPDATE／DELETE／NOOP 的比例）——這條曲線的診斷價值最高也最被忽略。NOOP 比例過低（例如低於 30%）幾乎確定表示庫在膨脹，因為真實對話中大量內容是重複提及；NOOP 過高則可能表示抽取或門檻過嚴，重要資訊沒被記下。這個比例是記憶系統健康度的單一最佳指標。
四條之外，值得加一個未被召回的記憶佔比：存了但從來沒被用過的記憶比例。它高得離譜（例如 80% 以上）時，代表寫入門檻太寬鬆——那些記憶只是在付儲存與稀釋的成本。這正是 recall_count 這個欄位存在的理由。
一個實務上的順序建議
不要一開始就建第四層。 順序應該是：
第一週：加上 assemble trace 與 decision log。只是記錄，沒有評測，但它讓後面所有事情變得可能。 第二週：從流量裡撈出 50 個記憶相關的查詢，人工標註，做成召回黃金集，放進 CI。 第一個月：把四條曲線放上 dashboard，特別是操作分佈。 之後：按實際遇到的失效模式，逐步補任務層評測。每一次生產環境的記憶問題，都應該變成一個新的評測案例——這比預先設計一套完整評測有效得多。