一句話
Zleap-AI 提出 SAG（SQL-Retrieval Augmented Generation），將文字拆成「事件 + 實體」存 SQL，查詢時用 JOIN 動態建局部超邊，取代稠密向量搜尋和靜態知識圖譜。三基準 9 項 Recall 指標中 8 項最佳，MuSiQue Recall@5 達 80%，已部署數億筆生產環境。
關鍵數據
| 項目 | 數據 |
|---|
| 基準測試 | HotpotQA / 2WikiMultiHop / MuSiQue |
| Recall@K（共 9 項） | 8/9 最佳 |
| MuSiQue Recall@5 | 80.0% |
| 生產規模 | 數億筆資料，線上檢索秒級 |
機制拆解
- 事件化存儲：每段文字拆成一個語意完整事件 + 多個索引實體。不做全域圖，每筆資料在 SQL 中獨立存在。
- 查詢時動態 JOIN：收到查詢 → 從問題抽實體 → SQL JOIN 找共享實體的事件 → 形成局部超邊。只為這次查詢存在，不持久化。
- 標準 DB 基礎設施：用普通 SQLite/PostgreSQL。不需向量庫、不需圖資料庫。天然支援增量寫入、並行處理、水平擴展。
- 不做全域圖的哲學：省去圖重建、碎片化、維護成本，查詢時才決定關聯——這是 SAG 最核心的設計原則。
落地應用：對 Hermes Agent 的啟發
- SQLite 路線正確：Hermes 的 fact_store 已是 SQLite+FTS5，SAG 驗證了不需要 Neo4j 或向量資料庫。架構方向一致。
- 缺失實體層：fact_store 目前是扁平結構（事實 ID + 文字 + 信任分數），沒有實體標籤。要 SAG 化只需加 entity_tags 欄位。
- 現在不急著改：83 條事實的規模下，FTS5 全文搜尋已經夠用。等長到 500+ 條、多實體交叉查詢變頻繁時再進化——成本一樣（加欄位 + 寫入時抽實體），但效益有感。
- 論文最有價值的不是 SQL JOIN：而是「不做全域圖，查詢時才動態關聯」的設計哲學——這驗證了 Hermes 記憶架構的基礎決策是對的。