「GraphRAG は全体像の把握に強い」という説明は、いまや生成AIに聞けば数秒で返ってくる。
しかしその主張の出所は1本の論文であり、そこには「何を・どう測って・どこまで言えたか」が書いてある。
本稿は Microsoft Research の原論文[1]を一次情報として読み、
GraphRAG入門では触れなかった実験の数字と限界、
そして 2025 年以降の第三者評価[4][5]が付けた但し書きまでを整理する。
論文が最初に置く問題設定はこれだけである。通常の RAG（ベクトル検索で関連チャンクを引いて LLM に渡す）は、 「〇〇について書かれた箇所」を探す問いには強い。だがコーパス全体を見渡さないと答えが出ない問い—— 著者らの言葉では global sensemaking questions——には、そもそも「関連チャンク」が定義できない。
つまりこの論文の立ち位置は「RAG の改良」ではなく、RAG と QFS（クエリ指向要約）の接続である。 QFS は要約研究の古典的課題だが、コーパスが 100 万トークン級になると LLM のコンテキストに収まらない。 そこで「グラフを索引として使い、要約を前もって階層的に作っておく」というのが提案の骨子になる。
パイプラインは索引（indexing）と問い合わせ（query）に分かれる。索引時に LLM を何周も回すのが特徴で、これが後述のコストにつながる。
問いの作り方が重要で、人手で書いたのではなくLLM に「このデータを使いそうな人物像」を5つ作らせ、その人が抱く全体俯瞰の問いを生成させている。 「技術ジャーナリストが政策を理解するために聞くこと」のような、特定チャンクでは答えられない問いに寄せてある。 これは評価の再現性を担保する一方で、「実務で本当に聞かれる問い」かどうかは別問題である。
| 条件 | 内容 | Podcast のコンテキスト量 | News |
|---|---|---|---|
| C0 | 根レベルのコミュニティ要約（最少） | 26.6K（2.6%） | 39.8K（2.3%） |
| C1 | 上位レベル | 225.8K | 352.6K |
| C2 | 中位レベル | 565.7K | 980.9K |
| C3 | 葉レベル（最多） | 746.1K | 1,140.3K |
| TS | グラフなし。原文チャンクに直接 map-reduce | 1,014.6K（100%） | 1,707.7K |
| SS | naive RAG（ベクトル検索でチャンク取得） | 問いごとに上位チャンクのみ | |
「%」は TS を 100 としたときの比率。根の要約 C0 だけなら原文の 2〜3% のトークンで済む——ここが GraphRAG の経済性の根拠になる数字である。 逆に言えば、葉レベル C3 でも原文の 7 割前後は読むことになる。
正解ラベルのある QA ではないので、LLM を審判にした一対比較で測っている。4指標のうち直接性は「包括性・多様性と対立するはず」という妥当性確認のために入れた対照指標。
| 指標 | 問い | naive RAG（SS）に対する GraphRAG の勝率 |
|---|---|---|
| 包括性 comprehensiveness | 問いの側面をどれだけ網羅しているか | Podcast 72–83%、News 72–80%（p<.001） |
| 多様性 diversity | 視点・観点がどれだけ豊かか | Podcast 75–82%、News 62–71%（p<.01） |
| 力づけ empowerment | 読者が判断を下すのに役立つか | 混合（明確な差なし）。具体例・引用・出典の有無が効いた |
| 直接性 directness | 問いに具体的・明確に答えているか | naive RAG が全比較で最も直接的（想定通り） |
要するに「GraphRAG は広く・多角的に答える。naive RAG は狭く・端的に答える」。 どちらが良いかは問いの性質で決まる、というのが論文自身の結論の読み方である。 また、グラフを作らず原文に直接 map-reduce する TS も naive RAG には勝つが、C0〜C3 は TS より少ないトークンで同等以上を出している。
| 指摘 | 出典 | 中身 |
|---|---|---|
| 審判の位置バイアス | Han et al. 2025[4] | 一対比較で提示順を入れ替えると逆の判定が出るケースがある。原論文の勝率は割り引いて読む必要がある。 |
| QA では劣る | 同上 | 単一ホップ QA（NQ）は naive RAG が上（F1 64.8 vs 63.0）。Global Search は要約タスクでも細部が落ち ROUGE-2 で劣後（6.99 vs 10.08）。マルチホップ QA では GraphRAG 優位。 |
| 索引コスト | 同上 | 構築時間 RAG 135 秒 vs Community-GraphRAG 5,560 秒（約 41 倍）。 |
| Microsoft 自身の方針転換 | LazyGraphRAG 2024-11[3] | 索引コストをベクトル RAG 並み（フル GraphRAG の 0.1%）に落とし、Global 検索は同等品質で 700 倍以上安いと主張。「まず Full GraphRAG」は現在の Microsoft の推奨ではない。 |
| スキーマ設計は効く | Scaffidi et al. 2025[5] | 専門家設計の5クラススキーマは自動生成／無スキーマより約 10% 多くエンティティを抽出し、幻覚が最少。公式 Docs も prompt tuning を強く推奨。 |
論文の一番実務的な含意は、問いを global / local に仕分けてから道具を選ぶという順序である。 特許・技術文書のコーパスで考えると、次のように分かれる。
| 問いの型 | 例 | 向く手段 |
|---|---|---|
| global（俯瞰） | この技術領域で主要プレイヤーはどう分かれているか／どの課題群に出願が集中しているか／過去5年で撤退した主体はどこか | GraphRAG Global Search（コミュニティ要約）。ただし細部が落ちるので根拠は Local で取り直す |
| multi-hop（辿る） | この機序を採用する出願人の、他分野での出願は何か／この引用系譜の起点は何か | GraphRAG Local Search、または通常 RAG＋メタデータ結合 |
| local（特定） | この公報の請求項1の構成要件は何か／〇〇法の要件は何か | 通常 RAG（特許RAG）。GraphRAG を使う理由がない |
| 不在（白地） | 技術A×材料Cはなぜ誰もやっていないか | 母集団統計（共起・期待値との差）。GraphRAG は結果の説明役 |
もう一つはスキーマの先行設計である。論文のデフォルトのエンティティ型は organization / person / geo / event で、これは news や podcast 向け。 特許なら「技術要素・課題・効果・材料・出願人・引用」のように、誰が何の問いに答えるためのグラフかを先に決めてから抽出プロンプトを調整する。 Scaffidi et al. の結果はこの手間が報われることを示している。
最後にコスト。索引に LLM を3周回す設計なので、まず 1 テーマ・数百件で試すのが公式 Docs の推奨でもある。 Global Search が本当に要る問いが見つかってから、規模を広げればよい。