Agent 記憶的瓶頸，可能不在查詢速度
最近看到一篇 arXiv 論文 Graph Memory for LLM Agents: At What Cost?，它提醒我一件很容易被 benchmark 遮住的事：做 agent memory 或 RAG，真正昂貴的部分往往不是模型問一次要幾毫秒，而是讓資料變成可查詢狀態之前，已經付出了多少成本。
這篇研究用約 102 萬個 nodes、534 萬筆 node 和 edge rows 的生醫型 property graph，設計 20 種 query workload，比較 Corvic AI、LoraDB、Ladybug、DuckPGQ、Memgraph、Neo4j、HugeGraph 和 FalkorDB。結果沒有一個系統全面最快。Ladybug 在窄範圍的鄰居查詢表現較好，Corvic 在大範圍 scan 和 join 較快，DuckPGQ 則受到 query plan 成本拖累。這其實比「誰是第一名」更有用，因為 agent 的 memory workload 本來就不是單一查詢。
更關鍵的是 bulk ingest 速度，從每秒 5.0k rows 到 4.3M rows，差了三個數量級。研究估計，當每次資料更新後的查詢次數少於約 10^5 次時，匯入成本會主導總持有成本。白話說，如果你的知識庫每天都更新，但 agent 只查幾百次，那麼選一個單次 query 快 20% 的引擎，可能遠不如選一個能快速完成更新、索引和可用性切換的方案。
這對 RAG 設計有三個實際含意。第一，先量測資料更新頻率、每次更新的資料量，以及更新後會被重用多少次，再談資料庫選型。第二，把 ingest、embedding、索引建立、驗證和切換時間放進 latency budget，不要只看 retrieval latency。第三，分開評估短路徑查詢和全域探索。前者像找某個病人的鄰近概念，後者像跨多層關係找出潛在關聯，兩者適合的 query plan 可能完全不同。
嚴格來說，這篇論文不是在宣布哪個 graph database 勝出，而是在修正我們看 benchmark 的方式。一次查詢的冠軍，不等於長期運作的 TCO 冠軍。對 agent memory 而言，記憶不是存進去就結束，而是每次更新都要重新支付可查詢化的成本。若忽略這點，最後優化的可能只是 demo，而不是系統。
作者：陳思維