PageRankはチェーンが長くなるほどスコアが減衰する。これはGraphRAGやHippoRAGが採用するオフライングラフ構築＋PageRankスコアリングの本質的な制約であり、多段推論を必要とするクエリでは正答率が落ちる直接的な原因になりえます。SAG（Structured Agentic Graph）はこの問題に対し、グローバルグラフの事前構築自体を不要にするアーキテクチャで応答しています。
データモデルの設計判断：トリプルではなくイベント
SAGの中核にあるのは「チャンク → イベント＋エンティティ」という3要素のデータモデルです。1つのドキュメントチャンクからLLMが1つのイベント（意味的要約）と複数のエンティティを抽出し、それらをリレーショナルデータベースの外部キーで関連付けます。
ナレッジグラフの設計でよく使われるトリプル（主語・述語・目的語）との比較が参考記事のアブレーション実験で示されています。MuSiQeベンチマークにおいて、イベント（ハイパーエッジ）アプローチのRecall@5は80.0%、トリプルアプローチは77.1%でした。差分は約3ポイントですが、これは設計哲学の違いを反映しています。トリプルは関係を細かく分解するため、完全な文脈を復元するには複数ホップが必要になります。イベントアプローチは1チャンクの意味をそのまま保持し、エンティティはグラフ横断のインデックス役に徹します。
エンティティのタイプは時刻・場所・人物・組織・グループ・トピック・作品・製品・アクション・指標・ラベルの11種類に限定されています。エンティティ自体には単独の意味を持たせず、「異なるイベントを接続する展開点」として機能させる設計です。これはHyperGraphRAGが明示的にハイパーグラフを構築するのと概念的に等価ですが、SAGは専用グラフエンジンを導入せずPostgreSQLの外部キー制約で同等の効果を得ています。
クエリタイムのSQL展開とトレードオフ
SAGのクエリ処理は3ステップで進みます。まずベクトル類似検索でシードイベントを取得し、次にSQLのJOIN操作でそこからエンティティ経由の隣接イベントを展開、最後にベクトルスコアとグラフ距離を組み合わせた二経路で最終選択を行います。
アーキテクチャ上のポイントはオフラインとオンラインの役割分担にあります。オフラインフェーズではMarkdownやTXTのチャンクからLLMがイベントとエンティティを並列抽出し、PostgreSQLとpgvectorに同期書き込みします。グローバルなグラフ構造は事前に計算しません。クエリタイムにJOINで展開するため、チェーンが何段になっても減衰しません。これはPageRankが持つ「距離に比例したスコア減衰」という性質を構造的に回避しています。
ただし、このアプローチにはトレードオフが存在します。JOIN展開はクエリごとにデータベースアクセスが発生するため、エンティティ数やイベント数が増えるとクエリレイテンシに影響します。GraphRAGのオフライン事前計算はクエリタイムの計算を削減する代わりにインデックス更新コストを前払いする設計であり、ドキュメント更新頻度やクエリパターンによってどちらが有利かは変わります。更新頻度が高いナレッジベースでは、グローバルグラフの再構築コストが重くなるため、SAGのクエリタイム展開モデルが有利に働く場面があります。
バックエンド構成はTypeScript＋PostgreSQL＋pgvector＋Reactのフルスタックで、pgvectorがベクトル検索とリレーショナルなJOIN展開を同一データベース内で処理します。専用ベクトルデータベースと専用グラフDBを組み合わせる構成と比べると、インフラの複雑度を抑えながらグラフ横断検索を実現できます。
エージェント統合とMCPサーバー設計
SAGの「Agentic」は命名だけでなく、設計に直接反映されています。各SAGプロジェクトにはMCP（Model Context Protocol）サーバーが組み込まれており、エージェントから呼び出し可能なツールエンドポイントとして公開できます。
これはナレッジベースを単一のモノリシックなRAGパイプラインに閉じ込めず、エージェントオーケストレーション層からツールとして選択的に呼び出す設計パターンです。プロジェクト単位でMCPサーバーが分離されることで、ドメインや権限境界に沿ったアクセス制御が構造的に実現しやすくなります。
GitHubスターは1,900件超、フォーク数は87件以上（2025年7月時点）で、arXivのペーパー番号は2606.15971です。ライセンスはMITで、ベンチマークリポジトリもZleap-AI/SAG-Benchmarkとして公開されています。
SQLベースのグラフ展開はトレーサビリティという非機能要件でも優位性があります。JOINのパスは決定的（deterministicで）であり、どのエンティティを経由してどのイベントに到達したかをクエリログから再現できます。PageRankのスコアベース展開はその過程が確率的で説明が難しい場合がありますが、SQLの実行計画は記録・再現が直接できます。監査可能性やデバッグ容易性を非機能要件に含める設計では、この差は無視できません。
設計の本質は「グラフ構造をリレーショナルデータベースの既存セマンティクスに落とし込む」点にあります。グラフDBやベクトルDBを追加導入せずにPostgreSQLとpgvectorで完結させることは、オペレーション面での技術的負債を抑制する判断でもあります。