SAG を採用する前に読む: イベント・エンティティ索引とクエリ時ハイパーエッジの実際
A new SOTA for RAG — an original retrieval architecture and an open-source knowledge base for humans and agents.
ひと目でわかる
- これは何？
- Zleap-AI/SAG は、チャンクから1つのイベントと複数のエンティティを抽出し、検索時にSQL結合でハイパーエッジを組み立てるRAGアプリケーションです。ベンチマーク主張の裏側にあるデータモデルと、ローカル優先という設計の境界を整理します。
- 誰に向いている？
- SAG が向くのは、社内文書や個人の資料群を手元で検索可能にし、その同じ知識を Codex や Claude Code から MCP 経由で引かせたい単独利用者です。逆に、複数ユーザーが同時に書き込む共有ナレッジ基盤や、既存の PostgreSQL 運用に検索層を載せたいチームには、既定の SQLite と LanceDB という構成がそのままでは噛み合いません。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
SAG が置き換えようとしているのは「RAG と GraphRAG の併用」という選択
README は SAG を「traditional RAG と GraphRAG の融合ではない」と明言し、両者を置き換える独自の retrieval アーキテクチャだと位置づけています。ここで解かれようとしている問題は、精度そのものより構成の重複です。密ベクトル検索の系と、グラフ構築の系を並べて運用すると、検索経路が2本になり、どちらの結果を採用したかの説明責任も2箇所に分散します。SAG はこの分岐をデータモデル側で消しにかかっています。対象読者は README によれば個人と Agent で、プロダクトは「deliberately local-first and single-user」と明記されています。つまり企業の共有基盤ではなく、まず1人の手元で完結する知識ベースとして設計されている点を最初に押さえておく必要があります。
chunk からイベントを1つ、エンティティを複数。これが索引の最小単位
SAG のデータモデルは README にコードブロックで示されています。chunk は1つの「semantically complete event」になり、同時に複数の indexing entity を生みます。event と entities の組が1つの latent hyperedge を構成する、という関係です。重要なのは役割分担で、event はチャンクの意味全体を保持し、triple のように断片化されません。entity は索引と展開の起点に徹し、event の意味を置き換えません。GraphRAG がオフラインで triple 抽出、エンティティ統合、関係の正規化、グローバルなグラフ維持を払うのに対し、SAG はハイパーエッジを事前構築しません。現在のクエリに対して、共通エンティティを共有する event を SQL join で局所的に結び、その場でハイパーエッジを作ります。この「作らない」という判断が、後述する増分更新のコスト構造に直結します。
オフライン索引とオンライン検索で何が永続化されるか
README の How retrieval works は、オフライン索引を4段階で説明しています。文書を意味的にまとまった chunk に解析し、各 chunk から event 1つと複数の entity を並列に抽出し、chunk、event、entity、そして event-entity の関連をリレーショナルストレージへ永続化し、chunk、event、entity それぞれの表現をベクトルおよび全文検索の索引へ永続化する、という流れです。注目点は、リレーショナル側とベクトル側の両方に同じ対象が書かれることです。検索はこの2つを突き合わせて動きます。なお README の引用はここで途切れており、オンライン検索の手順そのものは提供された資料からは確認できません。検索モードとして Fast (vector) と Precise (multi) の2つが案内されていること、結果や引用から元の chunk へ戻れることが記載されている範囲です。
導入手順: pip と CLI、そして MCP の接続
配布形態は PyPI の zleap-sag パッケージで、README のバッジは Python 3.11 以上と Node 20 以上を要求しています。デスクトップ向けのリリースも GitHub Releases で配布されており、v1.8.6 が最新です。Agent 連携は公式 CLI の @zleap-ai/sag-cli が担い、README によれば sag agent connect codex | claude-code の1コマンドで SAG Knowledge MCP を Codex または Claude Code にマウントできます。JWT のコピー＆ペーストや設定ファイルの手編集が不要になった、というのがこの CLI の説明です。2026年8月30日の変更では @zleap-ai/dsh-sag が追加され、内蔵のローカル DeepSeek Harness コネクタ経由で DSH Agent から検索、ソース閲覧、ソースと文書の管理ができるとされています。統合面はセルフホストの REST/OpenAPI、OpenAI 互換チャット、MCP、そして zleap-sag Python パッケージの4つが列挙されています。
SQLite と LanceDB で始まるという制約をどう読むか
README は「starts with SQLite and LanceDB, requires no external database」と書き、PostgreSQL/pgvector などへの道は「clear path」として示すにとどめています。ここは賛否が分かれる設計判断です。外部データベース不要という性質は、個人が手元で動かす分には導入障壁を大きく下げます。一方で、複数人が同じ知識ベースへ同時に書き込み、文書のライフサイクルを運用で回すような使い方は、この既定構成の想定外です。README 自身が single-user と明記しているので、これは未完成ではなく意図的な境界と読めます。また v1 系は v1 ブランチにアーカイブされ、もはやメンテナンスされないと明記されています。v1 上で何かを組んでいた場合、v1.8 系への移行は事実上の必須作業になります。移行手段として、2026年8月13日の変更で OCTX の import/export が追加され、整合性検証、競合処理、失敗時の復旧、互換ベクトルの再利用が含まれると説明されています。
ベンチマーク主張と、この資料から確認できないこと
README は HotpotQA、2WikiMultiHopQA、MuSiQue の3つで SAG が retrieval と end-to-end QA の両方で最良の性能を達成し、RAG の新たな state of the art を確立したと述べています。対応する論文は arXiv:2606.15971 で、再現用のリポジトリとして SAG-Benchmark が示されています。ただし本稿はこのリポジトリをインストールも実行もしていないため、数値の妥当性や再現性を評価することはできません。ここでできるのは、主張の検証経路が用意されているという事実の確認までです。もう一点、README は「original retrieval architecture」という表現を使いますが、イベント抽出とエンティティ抽出を誰がどう実行するのか、抽出器の選択やプロンプト、失敗時の扱いについては提供された資料に記述がありません。索引品質が抽出品質に依存する以上、この部分の記述が薄いのは導入判断の際に引っかかる点です。
GraphRAG との違いは「事前構築するか、クエリ時に作るか」
比較対象として README が具体的に挙げているのは GraphRAG です。違いは抽象的な優劣ではなく、コストをいつ払うかにあります。GraphRAG は triple 抽出、エンティティ統合、関係の正規化、グローバルなグラフ維持をオフラインで行い、その分だけ構築時に計算と保守を要します。代わりに、グラフは事前に存在するのでクエリ時の結合コストは相対的に小さくなります。SAG は逆で、オフラインでは chunk、event、entity とその関連を書くだけにし、ハイパーエッジの構築をクエリ時の SQL join に先送りします。この設計は、文書を継続的に追加する使い方では再構築の範囲を小さくできる可能性がある一方、クエリのたびに結合が走るため、エンティティの分布が偏った大規模コーパスでは検索側の負荷が読みにくくなります。どちらが良いかは、更新頻度と検索頻度のどちらが高いかで決まります。
ライセンスと更新コスト
ライセンスは MIT です。MIT は商用利用、改変、再配布を許容する寛容なライセンスで、派生物のソース公開も要求しません。ただし本稿は法的助言を行うものではなく、同梱の依存パッケージやモデルの重み、同梱データのライセンスは別途確認が必要です。更新の頻度は提供された情報から読み取れます。v1.8.4 が2026年8月30日、v1.8.5 が9月2日、v1.8.6 が9月3日で、直近の push は9月9日です。この短期間にパッチ版が3つ出ているため、追従する側は更新のたびに動作確認を挟む前提でいたほうが安全です。特に v1 から v1.8 系への移行は、UI が全面的に作り直され、パッケージ名も zleap-sag に変わっているため、単なるバージョンアップではなく別アプリへの乗り換えとして扱うべきです。
編集部の結論
SAG が向くのは、社内文書や個人の資料群を手元で検索可能にし、その同じ知識を Codex や Claude Code から MCP 経由で引かせたい単独利用者です。逆に、複数ユーザーが同時に書き込む共有ナレッジ基盤や、既存の PostgreSQL 運用に検索層を載せたいチームには、既定の SQLite と LanceDB という構成がそのままでは噛み合いません。導入前に確認すべきは3点で、1つ目は docs/sag-cli.en.md に記載された sag agent connect codex | claude-code が自分の環境で通るか、2つ目は Fast (vector) と Precise (multi) のどちらが自分の文書群で実用的か、3つ目は v1 から移行する場合に OCTX の import/export で既存データを移せるかです。arXiv:2606.15971 の数値は SAG-Benchmark リポジトリ側で再現手順が公開されているので、主張を信じるかどうかは自分のデータで Precise モードを回してから決めれば足ります。
コミュニティノート