← 文件教學

效能基準

Graphify 作為記憶層與程式碼智慧層的測量結果
來源：BENCHMARKS.md · 最後更新 2026-07-05

重點摘要

Graphify 在開放 harness 上與其他系統在同一模型、同一預算、同一裁判下比較：

所有系統共用同一個模型（Kimi K2.6）、相同預算，裁判與第二個獨立裁判盲驗的一致性 90.6%（Cohen's kappa 0.81）。

一眼表

套件資料集 (n)指標graphify場上對手
MemoryLOCOMO (300)QA accuracy45.3%supermemory 49.7%（11× ingest 成本）· bm25 31.3% · mem0 27.3%
MemoryLOCOMO (300)recall@100.497bm25 0.362 · mem0 0.048
MemoryLongMemEval-S (50)QA accuracy76%dense RAG 76% · hybrid 74% · mem0 70%
CostLOCOMO ingestUSD~$1.40supermemory $15.67 · mem0 $3.48
Costgraph buildLLM credits$0多數系統按 token 計費

怎麼測的：同一個 harness

Graphify 用自己的 harness，把其他系統（mem0、supermemory）當 adapter 塞進同一條流水線，所以大家看到的是同一個模型、同一 token 預算、同一個裁判：

ingest  ->  index  ->  search  ->  answer  ->  grade
(build)     (store)    (retrieve)  (Kimi K2.6) (key-fact coverage)

裁判怎麼評

答案由 Kimi K2.6 對照「一組正確答案必須包含的原子關鍵事實」評分：

coverage = (covered + 0.5 * partial) / total

每個評分都引述答案原文，所以可稽核而非一個不透明的分數。裁判本身先經盲驗（90.6% 一致、kappa 0.81）——多數發表的記憶基準完全不公開裁判驗證。

公平規則

記憶結果：LOCOMO（n=300）

依 recall@10 排序：

系統QA accuracyrecall@10Ingest 成本
graphify (graph-expand)45.3%0.497~$1.40
hybrid RRF43.3%0.493$0（共享索引）
graphify (SurrealDB engine)43.3%0.485$0
dense RAG41.3%0.439$0
BM2531.3%0.362$0
supermemory49.7%0.149*$15.67
mem027.3%0.048$3.48

* supermemory 的 recall 被 embedder 綁住：它用自己的 768-d 純英文 embedder，而非共用的 BGE-m3。QA accuracy 軸（共用 Kimi 讀者 + 裁判）才是乾淨的比較。

怎麼讀這張表：supermemory 原始 QA 高幾十分，但 ingest 成本約 11 倍、recall 差約 3 倍。Graphify 是測過系統中 LOCOMO 檢索 recall 最好的、共用 embedder 上 QA 最好的，成本約 supermemory 的十分之一——檢索正確記憶的次數約是 mem0 的 10 倍、答案準確度高 18 分。只做 seed 的消融（不圖擴充）仍有 42.7% / $1.40，所以最便宜設定就保有大部分準確度。

記憶結果：LongMemEval-S（n=50）

系統QA accuracyrecall@10
graphify (graph-expand)76%0.844
dense RAG76%0.848
graphify (SurrealDB engine)74%0.833
hybrid RRF74%0.822
BM2570%0.710
mem070%0.344

Graphify 與 dense RAG 並列最佳 QA（76%）；dense RAG 在 recall 上小勝（0.848 vs 0.844）。兩者都遠勝 mem0（recall 0.344）。

程式碼智慧：ERPNext

在約 1M 行的 ERPNext 上，給固定程式代理一個 graphify 工具，把評分問題集（n=6）的關鍵事實覆蓋率從 70.8%（grep+read 基線）拉到 82.0%，每次查詢約 140K token。Graphify 在準確度上勝過掃原始檔，並避開「把整個 repo 塞進每回合」的 context-stuffing 反模式（那要花約 20 倍 token、覆蓋率反而更低）。

時間子套件：15 年 ERPNext

689 個每週 AST checkpoints（2011–2026），確定性建圖、零 LLM：

CheckpointNodesEdgesFiles
2011-06-083,0692,9001,032
2026-06-2422,62048,7103,758

15 年間節點成長約 7 倍、邊成長約 17 倍。程式庫越大，純詞彙檢索找到的答案越少，而圖與語意檢索跟著規模成長，AST 抽取本身保持穩定。

成本與 token 經濟

重現

設 MOONSHOT_API_KEY，資料集抓到 harness 文件中說明的本機布局，每次跑遵守 --max-spend 並寫 spend ledger：

# 記憶（LOCOMO）——呼叫 SurrealDB engine 那一行（43.3%）；graph-expand 頭條（45.3%）是同一 harness 的獨立 adapter
python memory/runner.py --phase 3 --split locomo --n 300 \
  --adapters graphify_v1_surreal --cn natural --workers 6 --max-spend 15

# 程式碼跨工具（ERPNext）
python crosstool/run.py --repo erpnext --max-spend <budget>
提醒：這些是上游自測的數字（self-reported benchmark），公開的 harness 與裁判引述讓它可稽核、可重現，但引用時記得標明出處與前提（同一模型、同一預算）。本站翻譯自 BENCHMARKS.md。

教學解說

這份基準測試的核心價值在於「公平比較」：所有系統用同一個模型（Kimi K2.6）、同一 token 預算、同一個裁判。這在記憶系統基準中很少見——多數發表的基準不公開裁判驗證。

關鍵數字：Graphify 在 LOCOMO 上的 recall@10 = 0.497，是 mem0 的約 10 倍。QA accuracy 45.3% 比 supermemory 低 4.4 分，但 ingest 成本只要它的約 1/11。這反映了「圖檢索 vs 向量檢索」的權衡：圖結構提供了更好的關係理解，但需要更多的預處理。

程式碼智慧方面，Graphify 在 ERPNext（約 1M 行）上把關鍵事實覆蓋率從 70.8% 拉到 82.0%，證明了「用圖取代 grep」的實際價值。

Worked Example：重現 LOCOMO 基準

  1. 設定環境：設定 MOONSHOT_API_KEY 環境變數。
  2. 抓取資料集：按照 BENCHMARKS.md 說明的佈局，下載 LOCOMO 資料集到本機。
  3. 執行基準：執行 python memory/runner.py --phase 3 --split locomo --n 300 --adapters graphify_v1_surreal --cn natural --workers 6 --max-spend 15。
  4. 檢查 spend ledger：查看每次跑的 token 消耗與成本記錄。
  5. 比較結果：對照文中表格的 recall@10 與 QA accuracy 數字。
提醒：這是上游自測的數字（self-reported benchmark）。引用時記得標明出處與前提（同一模型、同一預算）。

常見錯誤與診斷

錯誤訊息原因解決方式
MOONSHOT_API_KEY not set未設定 API key執行 export MOONSHOT_API_KEY=your_key
max-spend exceeded超過預算上限提高 --max-spend 參數或減少測試數量 --n
adapter not found: graphify_v1_surrealSurrealDB 未安裝或未啟動安裝 SurrealDB 並啟動，或改用其他 adapter
裁判一致性低於 90%裁判模型或 prompt 有問題檢查 Kimi K2.6 連線，確認裁判 prompt 未被修改

練習與驗收清單

① 進階真實情境 Worked Example：用 graphify 當自家文件的記憶層並量化成效

這次不是重現上游基準，而是為你自己的語料設計一次基準：你的團隊有一個 800 份 markdown + 60 個 Python 模組的內部知識庫，你被問「換成 graphify 當記憶層值不值得」。

  1. 建圖：graphify extract corpus/——markdown 走 Pass 3（花 token），Python 走 AST（免費）；記下 spend ledger 與 nodes/edges/社群數。
  2. 定義評分集：請領域專家挑 50 個「查詢 + 必須涵蓋的原子事實」當 ground truth（模仿 LOCOMO 的 key-fact coverage 精神）。
  3. 建基線：用相同語料跑 BM25（graphify benchmark 或本地 script），得到「無圖」的 recall 對照。
  4. 測圖檢索：用 graphify query（graph-expand）對同一組 50 題取 recall@10，再用固定的 reader 模型答題。
  5. 量成本：對照 ingest 的 USD（graphify extract 的 token 統計）與搜尋的 token 用量，畫出「準確度/成本」座標。
為什麼選這條路徑：基準的價值在「在你的語料上」——LOCOMO 的 0.497 是他人語料的數字，你的分佈（中英混雜、有程式碼有文件）可能完全不同。自建 harness 的好處是：共享 reader 與裁判、寫 spend ledger、連 gemini 的召回都只跟你的語料有關。這正是「self-reported 數字只能當起點」的意義。

② 深入原理擴充：graph-expand 與 SurrealDB engine 的差異、以及「公平」怎麼被破壞

表裡出現兩個 graphify 引擎：graph-expand（預設，檢索時沿圖展開候選）與 SurrealDB engine（把圖倒進資料庫查）。兩者共用同一張 AST 圖、同一 embedder，差別在檢索策略——graph-expand 用圖結構把 seed 節點沿邊展開補召回，SurrealDB 版則靠資料庫索引做近鄰。LOCOMO 上 graph-expand 略勝（0.497 vs 0.485）。公平的脆弱點則藏在「共用 embedder」這條規則：supermemory 用自家 768-d 純英文 embedder，recall 被綁死（0.149）；一旦有人偷偷換成對語料更好的 embedder，數字就不可比。所以讀基準要先問「哪一層共用」——模型、embedder、裁判、預算，四層共用才叫公平。

大家以為建圖正確、但其實有誤的案例：表頭的「建圖零 LLM 成本 $0」常被解讀成「整個流程零成本」。實際上只有 AST 建圖是零 LLM；如果你的語料含文件/論文/圖片（Pass 3），那些檔案仍要花 token。LOCOMO 的 $1.40 是「記憶 ingest」成本，其中就含語意抽取的文件部分。引用「$0 建圖」時務必標注語料類型——純程式碼才成立。

③ 診斷式疑難排解表

症狀可能原因解決方案
自己語料上 recall 遠低於表上的 0.497語料分佈不同（多語言、文件比重高）或評分集太難先確認 embedder（BGE-m3）有裝且被用到；對照純 BM25 基線看相對增益而非絕對值
重跑基準數字對不上token 預算（--max-spend）不同、reader/裁判模型換了、資料集版本不同固定 MOONSHOT_API_KEY 對應的模型、固定 --n 與 seed、每次跑寫 spend ledger
supermemory/mem0 adapter 連不上adapter 需要 self-hosted 服務或額外 embedder 下載看 harness 文件裝好 adapter 前置；確認共用 BGE-m3 而非 adapter 自帶 embedder
裁判分數忽高忽低裁判 prompt 被改動或模型 provider 路由不一致跑盲驗（第二裁判一致性 > 90%）確認；固定裁判版本與温度
spend ledger 金額異常重試機制、快取沒生效或并行 worker 暴衝調低 --workers；確認 semantic cache 命中；檢查每 run 的 input/output token 分項

④ 進階挑戰題

  1. coverage 公式 (covered + 0.5 * partial) / total 的 0.5 是「部分涵蓋折半」。如果改成 0 或 1，哪些系統的排名會翻轉？這說明了「評分機制的微小參數會改寫基準結論」——你如何避免自己被誤導？
  2. harness 讓 mem0/supermemory「當 adapter 塞進同一條流水線」。要做到「真正的公平」，你認為哪一項最難保證：同模型、同 embedder、同預算、還是同裁判？為什麼？
  3. ERPNext 案例用「圖工具 + 固定代理」把關鍵事實覆蓋率從 70.8% 拉到 82.0%。請設計一個消融實驗，證明這 11.2 分的提升是「圖」造成的，而不是「工具多了個介面」造成的。

① 專案級端到端 Worked Example：為自家語料設計並執行一次完整基準

這次不是重現上游基準，而是從零設計基準：你有一個 300 份文件 + 100 個 Python 檔的內部知識庫，要回答「換成 graphify 當記憶層值不值得」。

  1. 建圖：graphify extract corpus/——記下 spend ledger（Pass 1 免費 + Pass 3 花 token）、nodes/edges/社群數。
  2. 設計評分集：請領域專家挑 50 個「查詢 + 必須涵蓋的原子事實」當 ground truth（模仿 LOCOMO 的 key-fact coverage 精神）。
  3. 建基線：用 BM25（graphify benchmark 或本地 script）跑同一組 50 題，得到「無圖」的 recall@10 對照。
  4. 測圖檢索：用 graphify query（graph-expand）對同一組 50 題取 recall@10，再用固定的 reader 模型答題。
  5. 量成本：對照 ingest 的 USD（graphify extract 的 token 統計）與搜尋的 token 用量，畫出「準確度/成本」座標。
  6. 產出報告：把結果寫成一份內部報告，附 spend ledger 和評分集，讓團隊能自行重現。
關鍵價值：基準的價值在「在你的語料上」——LOCOMO 的 0.497 是他人語料的數字，你的分佈（中英混雜、有程式碼有文件）可能完全不同。自建 harness 的好處是：共享 reader 與裁判、寫 spend ledger、連召回都只跟你的語料有關。

② 效能/品質/安全深度

面向考量實務建議
效能LOCOMO ingest $1.40 vs supermemory $15.67——11 倍差距來自「AST 建圖零 LLM」純程式碼語料的建圖成本確實為 $0；但混合語料的 Pass 3 仍要花 token——引用「$0 建圖」時務必標注語料類型
品質coverage 公式的 0.5（部分涵蓋折半）是任意參數——改成 0 或 1 可能翻轉排名讀基準時先問「評分機制的微小參數會不會改寫結論」；用自己的語料重現而非照抄上游數字
安全benchmark harness 的 spend ledger 應防篡改（預算超限要 fail）用 --max-spend 硬上限；每次跑寫 per-run spend ledger；不要手動改 ledger

③ 文件間比較對照表

面向本文（效能基準）相關文差異說明
Token 經濟LOCOMO $1.40 vs supermemory $15.67；建圖 $0運作原理運作原理頁講「52 檔省 71.5×」的內部基準；效能基準頁做跨系統比較
圖檢索graph-expand vs SurrealDB engine 的 recall 比較增量更新增量頁講圖的增量更新機制；效能基準頁講圖的查詢效能
程式碼智慧ERPNext 82.0% vs grep+read 70.8%實作案例實作案例頁展示單一專案的圖產出；效能基準頁量化「圖工具」的實際提升
裁判驗證90.6% 一致性、kappa 0.81架構總覽架構頁不涉及裁判機制；效能基準頁詳細講 coverage 公式與盲驗

④ 互動式檢核清單