今回の論文
今回取り上げるのは、Darren Edge らによる 2024 年の論文「From Local to Global: A Graph RAG Approach to Query-Focused Summarization」です。公開元は arXiv で、研究分野は RAG、情報検索、クエリ指向要約、ナレッジグラフ活用です。URL は https://arxiv.org/abs/2404.16130 です。
この論文を選んだ理由は、通常の RAG が強い「ピンポイント検索」と、弱い「文書群全体の傾向理解」をきれいに切り分けたうえで、その弱点を埋める実装パターンを提示しているからです。社内文書検索、調査支援、複数資料の横断要約、長い議事録やニュース束の分析などにそのまま応用しやすく、開発の発想にもつながりやすい技術です。
どんな技術か
GraphRAG は、文書をそのままベクトル検索するのではなく、まず文書からエンティティと関係を抽出してグラフ構造の索引を作り、そのグラフをコミュニティ単位で要約してから回答に使う RAG 手法です。
通常の RAG は、「ある事実がどこに書かれているか」を探すのは得意です。一方で、「この文書群で繰り返し出てくるテーマは何か」「全体としてどんな論点があるか」「複数のトピックがどうつながっているか」のような、コーパス全体を見渡す質問は苦手です。なぜなら、近いチャンクを数個取ってくるだけでは、全体像が context に入りきらないからです。
GraphRAG はここで、文書群をまず構造化します。誰と誰が関係しているか、どんな主張があるか、どの話題がどの話題と近いかをグラフにし、そのうえで似た話題どうしをコミュニティとしてまとめます。質問時には、各コミュニティの要約から部分回答を作り、それらを最後に統合して最終回答を作ります。
要するに GraphRAG は、「検索して答える」だけではなく、「コーパス全体を先に地図化してから答える」RAG です。
課題
この技術が解決しようとしているのは、通常の RAG が文書群全体の把握を必要とする質問に弱いという課題です。
何が難しいかというと、RAG の標準構成は基本的に局所検索だからです。質問をベクトル化し、意味的に近いチャンクを数件取って LLM に渡す方式では、質問に直接似ている断片は取れても、コーパス全体を横断して共通パターンを見つけるのは難しくなります。たとえば「この会社の障害レポート群に共通する根本原因は何か」「顧客インタビュー全体で頻出する不満は何か」といった質問では、上位数チャンクだけでは材料が足りません。
既存の方法にも限界があります。単純に context window を大きくして大量のチャンクを詰め込む方法は、コストが重くなりますし、長い入力の中で重要情報が埋もれる問題もあります。論文でも、長い文脈では情報が埋もれやすい点を問題設定に入れています。また、全文書を map-reduce 型で要約する方法は全体傾向を拾いやすい反面、毎回大量トークンを読むので重くなりやすいです。
なぜこの課題を解く必要があるかというと、実際の業務で欲しい質問は局所 factoid だけではないからです。経営会議の議事録、サポートチケット、研究ノート、監査ログ、ニュース束、社内 Wiki のようなデータでは、個別文書の一節よりも「全体の論点」や「複数資料をまたいだ関係」のほうが価値になることが多いです。
実際の AI システムでは、ここがプロダクト差にもなります。通常の FAQ ボットは作れても、複数資料から重要論点を洗い出す調査支援や、集合知を整理する分析系アプリは一段難しいです。GraphRAG はそのギャップに対する技術です。
用語解説
- RAG（Retrieval-Augmented Generation）
- 外部知識を検索して LLM の入力に足す仕組みです。この記事で重要なのは、一般的な RAG が局所的な関連チャンク検索に寄りやすく、GraphRAG はそこを補うために索引自体を構造化している点です。
- ナレッジグラフ
- エンティティをノード、関係をエッジとして表す知識表現です。GraphRAG では単なる可視化ではなく、文書群を話題コミュニティへ分割するための中間表現として使われます。
- クエリ指向要約（Query-Focused Summarization）
- 文書全体をただ短くするのではなく、質問にとって重要な観点に絞って要約する考え方です。GraphRAG は最終回答をこの形で作るため、検索と要約の中間ではなく、要約を前提にした RAG と理解すると読みやすいです。
- コミュニティ検出
- グラフの中で密につながったノード群を見つける処理です。GraphRAG では Leiden アルゴリズムを使い、関連の深い話題群ごとに要約を作れるようにしています。
- Map-Reduce 型要約
- 大きな入力を複数ブロックに分けて個別要約し、その結果を再統合する方式です。GraphRAG はコミュニティ要約ごとに部分回答を作り、最後にまとめるので、この流れが回答生成の中心になります。
技術の仕組み
GraphRAG の面白さは、検索時の工夫よりも、検索前にどんな索引を作るかに重心がある点です。論文のパイプラインは大きく分けると、索引構築と質問応答の 2 段階です。
基本アイデア
論文の核は、文書をベクトル埋め込みの集合としてだけ扱わず、LLM を使って「文書内に何がいて、何がどう関係しているか」を抽出し、グラフとして先に圧縮しておくことです。そのうえで、グラフをコミュニティ単位に分けて要約しておけば、質問時に全文書を読み直さなくても、テーマ単位で全体像にアクセスできます。
通常の RAG は局所検索に強い一方で、全体質問になると relevant chunk が分散しやすく、必要情報が拾いきれません。GraphRAG は「まず文書群の構造を作る」ことで、この分散を抑えようとしています。
1. 文書をチャンク化し、エンティティと関係を抽出する
最初の段階では、ソース文書をチャンクに分けます。チャンクが長すぎると 1 回の抽出で取りこぼしが増え、短すぎると LLM 呼び出し回数が増えます。論文では chunk size と抽出 recall のトレードオフを明示していて、長いチャンクではエンティティ参照の取りこぼしが増えることを示しています。
その各チャンクに対して LLM プロンプトを当て、エンティティ名、型、説明、さらにエンティティ間の関係を抽出します。加えて、必要なら claim のような補助属性も抽出できます。ここで重要なのは、GraphRAG のグラフが既存の厳密な知識グラフではなく、LLM 抽出による意味的な索引だという点です。つまり、多少抽象化された説明文も含む実用寄りのグラフです。
論文では、見落としを減らすために「gleanings」と呼ぶ複数回抽出も使っています。1 回目で取りこぼしたエンティティがないかを LLM に判定させ、足りなければ追加抽出させる方式です。これは、長めのチャンクを使って API 回数を抑えつつ、抽出品質を維持したい実装ではかなり参考になります。
2. 抽出結果を要約し、グラフを作る
抽出結果は、そのままだと同じエンティティの表記ゆれや、断片的な関係が大量に残ります。そこで GraphRAG は、同一エンティティや同一関係に対応する instance をまとめ、各ノードやエッジの説明文へ再要約します。
この段階で、文書の断片が「関係のある概念ネットワーク」に変わります。単に誰が出てきたかだけではなく、どの関係が重要か、どんな主張がついているかがグラフに乗るので、後段の要約がしやすくなります。
3. コミュニティ検出で話題の塊を作る
次に、できあがったグラフへコミュニティ検出をかけます。論文では Leiden アルゴリズムを使い、密につながったノード群を階層的に分割しています。ここが GraphRAG の本質で、検索対象を「チャンク」から「話題コミュニティ」へ変える処理です。
階層構造になっているのも重要です。粗いレベルでは大きなテーマが見え、細かいレベルでは具体的なサブトピックが見えます。たとえば社内ドキュメントなら、上位レベルでは「営業」「開発」「障害対応」のような大分類、下位レベルでは「特定顧客の要望」「特定障害の原因群」のような細分類に分かれるイメージです。
4. 各コミュニティを先に要約しておく
GraphRAG では、質問が来る前に各コミュニティのレポート風要約を作っておきます。葉レベルのコミュニティでは、ノード、エッジ、claim を優先順に詰めて要約し、上位レベルでは必要に応じて下位コミュニティの要約へ置き換えながら token 制限に収めます。
これは単なる前処理ではありません。ここで「生チャンクの山」が「意味の塊の要約」に変換されるので、質問時の計算量と文脈密度が大きく変わります。ベクトル検索 RAG は毎回チャンク断片を拾いますが、GraphRAG はコミュニティ要約を再利用できます。
5. 質問時はコミュニティごとに部分回答を作り、最後に統合する
質問が来たら、選んだコミュニティ階層の要約群をシャッフルしてチャンク化し、各チャンクから並列に部分回答を作ります。論文では、各部分回答に対して「その回答が質問にどれだけ役立つか」のスコアも LLM に付けさせ、スコア 0 のものは落としています。
その後、役立つと判断された部分回答だけを再度まとめ、最終回答を作ります。つまり、文書 -> グラフ -> コミュニティ要約 -> 部分回答 -> 全体回答 という 2 段階以上の圧縮を通しています。
この流れは実務上かなり重要です。通常の RAG が「関連箇所の抜粋」に寄るのに対し、GraphRAG は「話題ごとの観点整理」を経由するため、全体を聞く質問で強くなりやすいです。
実験と結果
論文では、GraphRAG が本当に全体質問に効くのかを、通常のナイーブ RAG や、グラフを使わず全文書を map-reduce 要約する方法と比較しています。評価対象は factoid QA ではなく、データセット全体の傾向や論点を問う sensemaking questions です。
何を検証したのか
主な検証は 3 つあります。1 つ目は、GraphRAG が通常の semantic search 型 RAG より、より包括的で多様な答えを返せるかです。2 つ目は、グラフを使わず全文書に対して map-reduce 要約する方法と比べても有利かどうかです。3 つ目は、コミュニティ階層のどのレベルを使うと、性能とコストのバランスがよいかです。
どんなデータセットや評価指標を使ったのか
データセットは、ポッドキャスト文字起こし群とニュース記事群の 2 種類です。論文では、これらに対して LLM で activity-centered なグローバル質問を生成し、125 問ずつ比較しています。
評価指標は通常の EM や F1 ではなく、LLM 評価による head-to-head 比較です。観点は主に Comprehensiveness、Diversity、Empowerment、Directness の 4 つで、GraphRAG の強みが出やすいのは前 2 つです。ここは重要で、GraphRAG は「最短で一点回答する技術」ではなく、「全体理解を支える回答品質」を上げる技術として評価されています。
どのような結果が出たのか
論文では、すべての GraphRAG 条件が、ナイーブ RAG を comprehensiveness と diversity で上回りました。Podcast transcripts では comprehensiveness の win rate が 72% から 83%、News articles では 72% から 80% でした。Diversity でも、Podcast transcripts で 75% から 82%、News articles で 62% から 71% の win rate が出ています。
また、グラフを使わずに source text をそのまま map-reduce 要約する方法と比べても、GraphRAG のコミュニティ要約は小さいながら一貫した改善を示しました。たとえば comprehensiveness の win rate は Podcast で中間レベル要約が 57%、News で低レベル要約が 64% でした。Diversity も Podcast の中間レベルで 57%、News の低レベルで 60% でした。
コスト面でも差があります。低レベルコミュニティ要約 C3 は、source text summarization より 26% から 33% 少ない context token で済み、ルートレベル要約 C0 では 97% 超の削減でした。つまり、GraphRAG は単に良い答えを出しただけでなく、全体要約系の別案より入力効率も良かったことになります。
結果から何が言えるのか
この結果から言えるのは、GraphRAG の価値は「検索精度を少し上げる」ことではなく、「質問の単位をチャンク検索からコーパス理解へ広げる」ことにあるという点です。特に、複数資料の横断整理や、テーマ把握、論点抽出のような用途では、近傍チャンク検索だけでは足りないことが多く、GraphRAG の設計がその弱点に刺さっています。
一方で、論文の評価指標は directness ではなく comprehensiveness と diversity を重視しています。したがって、短く一点回答したい FAQ では、常に GraphRAG が最適とは限りません。この読み分けは実務でも大事です。
何に使える？
GraphRAG は、単発の事実検索よりも、文書群全体の構造や論点を把握したい場面に向いています。
社内ナレッジ検索の上位版
社内 Wiki、議事録、仕様書、障害報告書、営業メモなどを束ねた検索では、「この不具合の原因は？」だけでなく、「この四半期の障害傾向は？」「顧客から繰り返し出ている要求は？」のような質問が出ます。GraphRAG はこうした全体質問に強く、複数文書の関係をまたいだ要約を返しやすいです。
調査支援やリサーチアシスタント
ニュースや論文束を読む用途では、「何が書いてあるか」以上に「どういう論点に分かれるか」が重要です。GraphRAG なら、コミュニティごとにサブテーマを要約してから全体回答を作るので、複数視点の整理や論点比較に向いています。特に競合調査や技術調査で役立ちやすいです。
顧客の声やログの分析
サポートチケット、問い合わせ履歴、VOC、障害ログの集合から、頻出原因や関連トピックを抽出する用途にも合います。通常の埋め込み検索だけだと、似た問い合わせを個別に返すだけで終わりがちですが、GraphRAG は関連する症状や原因群をコミュニティとしてまとめやすいです。
長文データのエージェント補助
AI エージェントが長大な社内データを扱う場合、毎回 raw document を引くより、先に構造化されたグラフ要約を持っていたほうが計画や検索が安定しやすくなります。たとえば調査エージェントが、まず上位コミュニティで全体像を見てから、必要に応じて下位コミュニティや原文へ掘る設計はかなり自然です。
開発や事業へのヒント
この論文から得られる実務的なヒントは、RAG の改善を retrieval モデルの入れ替えだけで考えないほうがよいということです。索引の作り方を変えると、扱える質問の種類そのものが変わります。
RAG の単位を「チャンク」から「テーマ」へ上げる
自分で AI アプリを作るなら、すべての質問を chunk retrieval だけでさばこうとしないほうがよいです。特に調査支援や社内分析では、回答に必要なのは断片ではなく論点の束です。GraphRAG の考え方を使えば、検索対象を話題コミュニティへ一段抽象化できます。
前処理にコストを払って、質問時の価値を上げる
GraphRAG は前処理が重いですが、そのぶん質問時の回答品質と再利用性が上がります。これは SaaS や社内ツールでも重要で、頻繁に参照されるデータセットなら、毎回全文から答えを組むより、先に索引を育てるほうが筋が良いです。更新頻度が低く、質問頻度が高いデータでは特に向いています。
部分導入でも十分価値がある
フルの GraphRAG をすぐ実装しなくても、考え方だけ取り入れることはできます。たとえば、文書群からエンティティと関係を抽出してタググラフを作る、上位トピックごとの事前要約を作る、全体質問だけ map-reduce ルートへ流す、といった段階導入です。小規模プロダクトでも始めやすい切り口です。
今後注目すべき方向性
今後は、GraphRAG のような構造化索引と、通常のベクトル検索、さらにエージェント的な探索をどう組み合わせるかが重要になりそうです。局所質問は普通の RAG、全体質問は GraphRAG、複雑な調査はエージェントで多段探索、というハイブリッド設計はかなり有望です。これは論文を少し超えた見方ですが、プロダクト設計上は自然な進化です。
限界
GraphRAG にもはっきりした限界があります。まず、索引構築コストが高いです。文書分割、エンティティ抽出、関係抽出、追加抽出、要素要約、コミュニティ検出、コミュニティ要約まで行うため、ナイーブ RAG より前処理はかなり重くなります。更新頻度が高いデータでは再構築コストが問題になりやすいです。
また、抽出品質が LLM に依存します。エンティティの取りこぼし、関係の誤抽出、表記ゆれの統合失敗があると、後段のコミュニティ構造そのものが歪みます。つまり、検索時の hallucination を減らす代わりに、索引時の抽象化誤差を抱える構造です。
実装難易度も低くありません。ベクトル DB を置くだけの RAG と違って、抽出パイプライン、グラフ管理、コミュニティ検出、階層要約、評価設計まで必要になります。小規模チームでは、まず全体質問だけ別ルートへ逃がすなど、段階導入のほうが現実的です。
さらに、すべての質問に向くわけではありません。特定の日付、特定の数値、特定の発言者の一言のような局所質問では、通常のベクトル検索や BM25 のほうが速くて素直です。GraphRAG は global question に強い一方で、fact lookup を全面的に置き換える技術ではありません。
最後に、論文の評価は comprehensiveness や diversity を重視した LLM 評価が中心です。実プロダクトでは、引用の正確さ、出典追跡、応答時間、更新コストなども別途検証する必要があります。
よくある質問
Q. GraphRAG は普通の RAG と何が違うのですか？
A. 普通の RAG は質問に近い文書チャンクを直接検索して回答します。GraphRAG はその前に、文書群からエンティティと関係のグラフを作り、話題コミュニティごとの要約を作っておきます。そのため、個別の事実よりも、全体傾向や複数トピックの関係を問う質問に強いです。
Q. どんなときに GraphRAG を使う価値がありますか？
A. 社内文書全体の傾向把握、顧客の声の横断分析、長い議事録群の論点整理、ニュースや論文束の比較などです。複数資料をまたいだ全体理解が必要で、単純な top-k 検索だけでは足りないときに価値が出ます。
Q. GraphRAG は通常のベクトル検索を置き換える技術ですか？
A. 完全な置き換えではありません。局所的な fact lookup や引用箇所の特定は通常の RAG のほうが扱いやすいことが多いです。実務では、局所質問は通常 RAG、全体質問は GraphRAG という併用が現実的です。
Q. 小規模なプロダクトでも導入できますか？
A. できますが、フル実装はやや重いです。まずはトピック抽出や上位要約だけを前処理で作る、全体質問だけ別パイプラインに流す、といった軽量版から始めるのが現実的です。論文の発想をそのまま縮小適用する形です。
Q. GraphRAG の弱点は何ですか？
A. 前処理コスト、抽出誤差、更新の重さ、実装複雑性です。特にデータ更新が激しい環境では、グラフ再構築や要約更新の運用設計が重要になります。
今日の学び
この論文は、通常の RAG がコーパス全体の傾向や論点を問う質問に弱いという課題を扱いました。そこに対して、文書からナレッジグラフを作り、コミュニティ要約を経由して部分回答を統合する GraphRAG を提案しました。
ここから得られるヒントは、RAG の性能は検索器だけでなく、索引の設計で大きく変わるということです。全体理解が必要なプロダクトでは、文書をそのまま埋め込むだけでなく、先に構造化しておく発想が重要になります。