GraphRAG：ローカルからグローバルなクエリ指向の要約へ

マイクロソフトのGraphRAG論文は2024年4月に発表され、ナレッジグラフがRAGをその最も明白な失敗モード、すなわち特定の箇所を検索するのではなくコーパス全体を合成する必要がある質問から救い出せるかどうかを検討する際の標準的なリファレンスとなりました。私が今これを読んでいるのは、以前のFinAuditingに関する記録でLLMが複数ドキュメントにわたるXBRL構造に苦戦していることが明らかになったためです。GraphRAGのコミュニティ要約アプローチは、まさにそのようなグローバルな推論問題に対する最も有力な既存の回答です。

論文について

マイクロソフトのDarren Edgeらによる論文「From Local to Global: A Graph RAG Approach to Query-Focused Summarization」（arXiv:2404.16130）は、著者が「グローバルな意味把握（global sensemaking）の質問」と呼ぶもの、例えば「このデータセットの主なテーマは何か？」といった、単一の箇所に答えが含まれないために標準的なベクトルRAGでは回答できないクエリに答えるための、LLM駆動の2段階パイプラインを提案しています。

このアプローチは2つのフェーズで進行します。インデックス作成時には、LLMがすべてのテキストチャンクからエンティティ、関係性、主張を抽出し、それらを重み付きエンティティグラフに組み立てます。その後、Leidenコミュニティ検出を実行してグラフを関連するクラスターの階層に分割し、各レベルの各コミュニティに対して自然言語の要約を生成します。クエリ実行時には、各コミュニティの要約が独立して部分的な回答を生成し（mapステップ）、これらの部分的な回答が有用性スコアによってランク付けされ、コンテキストウィンドウの制限まで組み立てられ（reduceステップ）、最終的な合成回答となります。

主なアイデア

• Leiden階層コミュニティ検出により、コーパスを4つの粗さレベル（C0〜C3）に構造化します。これにより、ユーザーはトークンコストと引き換えに応答の深さを調整できます。ルートレベルの要約では、ソーステキストを直接処理する場合と比較してトークンを97%削減できました。
• 2つのテストコーパス（ポッドキャストの書き起こし 約100万トークン、8,564エンティティ、20,691エッジと、ニュース記事 約170万トークン、15,754エンティティ、19,520エッジ）において、GraphRAGはLLMを評価者としたペア比較で、ベクトルRAGに対し包括性（comprehensiveness）で72〜83%、多様性（diversity）で62〜82%の勝率を達成しました。
• Map-reduce設計により、クエリ実行時のロングコンテキストLLM呼び出しを回避します。コミュニティ要約は事前計算されているため、検索は生のドキュメントを再処理するのではなく、要約を取得するだけになります。
• 論文では、4つのGraphRAG階層レベル、テキスト要約（TS）、セマンティック検索（SS）の6つの条件をベンチマークしています。グローバルなGraphRAGの条件は、意味把握の質問において一貫してSSを上回りますが、SSは特定のルックアップクエリにおいてより優れたパフォーマンスを発揮します。
• 主張抽出の実験では、グローバル条件では1回答あたり平均31〜34の主張が抽出されたのに対し、ベクトルRAGでは25〜26でした。これは、LLM評価者のスコアリングの好みとは無関係に、より広いトピックをカバーしていることを示唆しています。
• このパイプラインはドメイン固有のスキーマやオントロジーを必要としません。エンティティ抽出、関係性のラベル付け、コミュニティの要約はすべてプロンプトによる推論のみから得られます。

有効な点とそうでない点

コアとなるアーキテクチャの洞察は正しいものです。コサイン類似度を用いたRAGは、全体を代表する単一のチャンクが存在しないため、コーパスレベルの質問に答えることができません。GraphRAGの事前計算されたコミュニティ要約は原理に基づいた回避策であり、Leidenベースの階層構造は、コスト許容度に応じて大まかなグローバル要約からきめ細かなクラスター要約までナビゲートできる真の設計上の選択肢です。

しかし、評価には深刻な問題があります。最近の独立した研究（arXiv:2506.06331）では、GraphRAGとその系譜で使用されているLLM評価者（LLM-as-judge）の手法を監査し、3つの体系的なバイアスを発見しました。位置バイアス（プロンプト内でどの回答が先に表示されるかだけで勝率が30%以上変化する）、長さバイアス（200トークンの回答において25トークンの差が勝率に50ポイントの変動をもたらす）、および試行バイアス（同一の評価が実行ごとに矛盾する結果を生む）です。これらを修正すると、主張されていたパフォーマンスの優位性は崩壊します。LightRAGが報告した対ナイーブRAG勝率66.7%は、修正後39.06%となりました。GraphRAG自身の72〜83%という包括性の数値も、ほぼ間違いなく同じ手法の影響を受けています。

インデックス作成コストも実質的な障害です。ある実務者の分析では、中規模のコーパスに対してGPT-4oを使用したインデックス作成コストが47.9ドルに達したと報告されています。マイクロソフト自身が後報としてリリースしたLazyGraphRAGバリアントでは、グラフ抽出をクエリ実行時まで遅延させることで、フルGraphRAGのコストを0.1%に削減しています。これは、元のインデックス作成予算が多くの実際の導入において非現実的であることを暗黙のうちに認めているものです。

2つの評価コーパスも限定的です。それぞれ合計100万〜170万トークンの2つの英語データセットのみです。著者らは、他のドメインや規模への汎用性は未知であると認めています。財務書類や元帳のエクスポートなどの構造化または半構造化データの場合、物語的なテキスト向けに最適化されたエンティティ抽出プロンプトでは、実務で最も重要となる表形式や階層的な関係を見逃す可能性があります。

財務AIにとってなぜ重要なのか

Beancountの元帳は、まさにグローバルな意味把握クエリが自然に発生するコーパスです。「過去3年間の最大の支出カテゴリは何か？」や「前年比20%以上成長したベンダーアカウントはどれか？」といった質問です。標準的なRAGは、単一のエントリに答えが含まれていないため、これらの質問に答えることができません。エージェントは数千のトランザクションを合成する必要があります。

GraphRAGのコミュニティ要約アプローチはこれに適合します。知識グラフのノードがアカウント、支払先、トランザクションカテゴリであり、エッジが共起関係や親アカウント関係である場合、コミュニティ要約は元帳に対する事前計算された集計ビューになります。また、この階層構造はBeancountのアカウントツリーがすでにデータを構造化している方法（資産、費用、収益が再帰的に分解される）を反映しており、Leidenスタイルの階層的クラスタリングと自然に適合します。

とはいえ、評価バイアスの発見は警告でもあります。論文に示された印象的な勝率は、厳密に制御されたテストの下では維持されない可能性があり、インデックス作成コストにより、これは見かけよりも重いエンジニアリングの賭けとなります。特にBeancountの場合、決定論的な分析においては、エクスポートされた元帳に対するSQL形式のクエリやpandasを用いた構造化集計の方が、LLM駆動のコミュニティ要約を上回る可能性があります。GraphRAGの価値が最も高まるのは、構造化クエリでは解決できない真の曖昧さが存在する、大規模なトランザクションメモやベンダー名の推論など、記述内容に重きを置いた質問でしょう。

次に読むべきもの

• LazyGraphRAG (Microsoft Research blog, 2024) — グラフ抽出を遅延させることでコストを削減したマイクロソフトのバリアント。法外なインデックス作成コストをかけずに、GraphRAGのアプローチを実際の元帳規模で展開できるかどうかに直接関連します。
• 「How Significant Are the Real Performance Gains? An Unbiased Evaluation Framework for GraphRAG」(arXiv:2506.06331) — 体系的なバイアス監査。要約手法のLLM評価者による評価値を鵜呑みにする前に必読の資料です。
• 「Towards Verifiably Safe Tool Use for LLM Agents」(arXiv:2601.08012, ICSE 2026) — 読書リストの次の項目。要約から書き戻しの安全性へと焦点を移します。これはBeancountエージェントにとってより差し迫った未解決の問題です。