SAG 知識庫評測：事件實體索引與查詢期動態超邊，是否值得取代現有 RAG 管線
A new SOTA for RAG — an original retrieval architecture and an open-source knowledge base for humans and agents.
秒懂
- 它是什麼？
- Zleap-AI 的 SAG 用 event-entity 索引與查詢期動態超邊，取代傳統稠密檢索與 GraphRAG 的雙軌架構，並附上一套 local-first 的單機知識庫應用。本文只根據 README、release notes 與 arXiv 摘要說明其機制、安裝路徑與適用邊界，不代為背書其 SOTA 宣稱。
- 適合誰用？
- 若你的團隊已有明確的單機或單使用者知識庫需求，且願意接受 SQLite 與 LanceDB 的本地儲存前提，SAG 值得先用 zleap-sag 在一個內部語料上跑完整條 ingestion 到 citation 的流程再決定；若你需要多租戶、跨團隊權限隔離，或已在 Neo4j 之類的圖資料庫上累積可用的實體關係資產，SAG 目前不是對應工具，因為 README 明言它是 local-first 且 single-user。動手前先確認三件事：PyPI 上 zleap-sag 的實際版本是否與 README 標示的 v1.8.6 一致、OCTX 匯出後的完整性驗證在你們的語料規模下是否可行、以及 Fast（vector）與 Precise（multi）兩種模式在你們的查詢型態上差多少。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
SAG 要解決的不是檢索品質，而是兩套系統並存的維護成本
多跳問答的常見做法是同時跑兩條路：一條做向量相似度檢索，一條做圖譜關係推理，再在檢索結果層合併。README 對這個做法的描述很直接，指出 GraphRAG 要付出 triple extraction、entity merging、relation normalization、global maintenance 的成本，且增量更新困難。SAG 的定位不是把兩者融合，README 用「an original retrieval architecture that replaces both」來說明，並強調不需要維護兩套 RAG 系統或合併兩條檢索路徑。
目標讀者有兩類。一類是正在評估是否導入 GraphRAG 的資料工程團隊，關心的是離線建圖的維運負擔。另一類是想把自家文件接給 agent 使用的開發者，README 把這部分包成一個完整應用，從上傳文件到 agent 帶引用的回答都在同一個介面內。第二類讀者要注意，這個應用在 README 裡被描述為 deliberately local-first and single-user，這個前提會決定它能不能進你們的環境。
事件與實體的分工：chunk 不拆成三元組，超邊在查詢時才生成
README 用三行文字概括資料模型：chunk 對應一個語意完整的事件，chunk 同時對應多個索引實體，事件與實體之間構成一個潛在超邊。這三者的角色分工是整個架構的關鍵。
Event 承載 chunk 的完整語意，README 明確說它「is not fragmented into independent triples」，這是與 GraphRAG 最根本的差別。Entity 只是輕量索引與擴展點，不是語意的替代品。Query-time dynamic hyperedge 則是在 SQL 把共享實體的 events 連接起來時，於本地即時產生，SAG 不預先建構、也不全域維護這些超邊。
這個設計的推論是：圖結構不是持久化資產，而是每次查詢的副產物。好處是省下離線建圖與增量更新的維護工作，代價是每次查詢都要付出 join 的計算。能不能接受這個交換，取決於你們的查詢頻率與語料規模，README 沒有給出這方面的數字。
輸出邊界也值得一提。README 說 original evidence 是輸出邊界，被選中的 events 一律映射回來源 chunk 以供生成與引用。對需要可追溯性的場景，這比只回傳一段生成文字實用。
離線索引四步與線上檢索：資料實際流向哪裡
README 把離線索引拆成四步。先把文件解析成語意連貫的 chunks，再從每個 chunk 平行抽出一個 event 與多個 entities，接著把 chunks、events、entities 及 event-entity 關聯寫入關聯式儲存，最後把三者的表徵寫入向量與全文索引。
這裡有個容易被忽略的細節：event 是單數，entities 是複數。也就是說一個 chunk 只產生一個事件，但會產生多個索引實體。這個比例關係直接影響超邊的連接密度，實體越多，跨 chunk 的連接機會越大，同時也越容易引入雜訊。README 沒有說明實體抽取的粒度控制方式。
線上檢索一節在提供的素材中被截斷，只留下「Online retrieval」這個標題。後續的檢索步驟、排序方式與 top-k 設定無法從現有材料確認，我不會替它補上。可以確定的是 README 把檢索分成 Fast（vector）與 Precise（multi）兩種模式，並支援全域或限定來源範圍的檢索。
安裝與啟動：zleap-sag、Node 20 與 MCP 連接指令
執行環境的需求在 README 的 badge 中寫得很清楚：Python 3.11+、Node 20+。Python 套件名稱為 zleap-sag，對應的 PyPI 頁面是 pypi.org/project/zleap-sag。桌面版則透過 GitHub Releases 發布，README 的 badge 指向 releases/latest。
命令列客戶端是 @zleap-ai/sag-cli，文件在 docs/sag-cli.en.md。README 給的連接範例是 `sag agent connect codex | claude-code`，它會把 SAG Knowledge MCP 掛進 Codex 或 Claude Code，README 強調不需要手動複製 JWT，也不用編輯設定檔。
儲存層的預設選擇是 SQLite 加 LanceDB，README 說不需要外部資料庫，並保留通往 PostgreSQL/pgvector 的路徑。整合面則包含自架的 REST/OpenAPI、OpenAI 相容的 chat 端點、MCP，以及 zleap-sag 這個 Python 套件。
要注意 README 沒有在提供的段落裡給出 pip install 的完整指令，也沒有列出主要的設定鍵名稱。實際安裝前請以 PyPI 頁面與 docs 目錄下的文件為準，不要憑這篇敘述推測參數。
local-first 與 single-user 是硬邊界，不是預設值
README 對產品定位的用詞沒有模糊空間：deliberately local-first and single-user。這表示它預設的部署情境是一台機器、一個使用者。
如果你的需求是多租戶、跨團隊的權限隔離，或需要把知識庫當成共享服務暴露給多個內部系統，這個前提會直接擋住你。README 提到有通往 PostgreSQL/pgvector 的路徑，但沒有說明這條路徑是否已經處理並發寫入、權限模型或資料隔離。在沒有進一步文件的情況下，我不會假設它已經解決。
另一個要注意的是版本斷層。2026 年 7 月 14 日的 changelog 寫明新版建構在 zleap-sag 套件上並重新設計了 UI，舊版被歸檔在 v1 分支且不再維護。任何在網路上找到的舊版教學、設定範例或部署腳本，都可能對應到已停止維護的架構。
還有一個操作層面的風險：changelog 顯示 8 月底到 9 月初有數個密集的 patch 版本（v1.8.4、v1.8.5、v1.8.6）。這種節奏通常意味著介面或行為仍在快速調整，鎖定特定版本並記錄你們實際使用的版本號，比跟著 latest 走更安全。
與 GraphRAG 的差異在於圖是查詢產物，而非持久化資產
拿 GraphRAG 當對照，差別不在檢索精度，而在圖的生命週期。GraphRAG 的圖是離線建構的持久化資產，需要 triple extraction、entity merging、relation normalization 與全域維護，好處是關係結構可以累積、可以人工檢視、可以跨查詢重用。SAG 把超邊推到查詢期生成，省下維護成本，代價是關係結構不沉澱，每次都要重算。
這個差異會影響兩件事。第一，如果你的團隊已經在 Neo4j 之類的圖資料庫上累積了整理過的實體關係，那是有價值的資產，SAG 不會沿用它。第二，如果查詢延遲是硬需求，查詢期 join 的成本會直接反映在回應時間上，而離線建圖的成本則攤提在背景。
README 也提到 SAG 支援 OCTX 來源的匯入與匯出，含完整性驗證、衝突處理、失敗復原，以及跨實例遷移時的相容向量重用。這對需要在多台機器間搬移知識庫的人是實際功能，但它處理的是遷移，不是多使用者共享。
至於 README 引用的 HotpotQA、2WikiMultiHopQA、MuSiQue 三個 benchmark 上的最佳表現宣稱，那是作者在 arXiv 論文（2606.15971）中的實驗結果，並附有獨立的 SAG-Benchmark 倉庫供重現。我沒有執行過這些實驗，無法驗證，讀者若要採用這個結論，應該自己跑一次 benchmark。
授權、升級成本與採用前該驗的三件事
授權是 MIT，README 的 badge 與 LICENSE 檔案一致。MIT 允許修改與再散布，實務上要注意的是你們自行修改後的程式碼如何與上游同步，以及內部再散布時是否保留授權聲明。這不是法律意見，實際條款請看 LICENSE 全文。
升級成本方面，素材支持兩個判斷。一是舊版已歸檔在 v1 分支不再維護，跨過 2026 年 7 月 14 日這條線的升級不是 patch 而是架構替換。二是套件與桌面版是分開發布的，PyPI 上的 zleap-sag 版本與 GitHub Releases 的桌面版本號需要分別確認，README 的 badge 把 SAG 版本標為 v1.8.6，但這是否等於 PyPI 上的最新版，素材沒有明說。
採用前先驗三件事。第一，確認 PyPI 上 zleap-sag 的實際版本與你們要用的功能是否對得上。第二，用你們自己的語料跑一次完整流程，從 ingestion、Fast 與 Precise 兩種檢索模式，一路到 agent 回答的引用是否能回到原始 chunk。第三，若你們打算跨機器搬移知識庫，先在小規模資料上測 OCTX 的匯出與匯入，確認完整性驗證與衝突處理在你們的資料型態下行為符合預期。這三項都必須用你們的資料回答。
編輯結論
若你的團隊已有明確的單機或單使用者知識庫需求，且願意接受 SQLite 與 LanceDB 的本地儲存前提，SAG 值得先用 zleap-sag 在一個內部語料上跑完整條 ingestion 到 citation 的流程再決定；若你需要多租戶、跨團隊權限隔離，或已在 Neo4j 之類的圖資料庫上累積可用的實體關係資產，SAG 目前不是對應工具，因為 README 明言它是 local-first 且 single-user。動手前先確認三件事：PyPI 上 zleap-sag 的實際版本是否與 README 標示的 v1.8.6 一致、OCTX 匯出後的完整性驗證在你們的語料規模下是否可行、以及 Fast（vector）與 Precise（multi）兩種模式在你們的查詢型態上差多少。這三項都要用你們自己的資料驗證，README 給不出答案。
社群筆記