Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — ベクトルRAGの復習と、どこで行き詰まるか
バニラRAGが答えられない2種類の質問
GraphRAGとは何か — グラフ索引を作る
ローカル検索 vs グローバル検索
具体例 — インシデントのコーパス
正直なトレードオフ — 安くはない
で、あなたは使うべきか
おわりに
参考資料

はじめに — ベクトルRAGの復習と、どこで行き詰まるか

RAG(検索拡張生成)の標準レシピは、すでにプロダクションRAGパターンで整理しました。要約するとこうです — 文書をチャンクに切り、埋め込んでベクトルDBに入れ、質問と意味が最も近い上位k件のチャンクを取り出してプロンプトに貼る。ハイブリッド検索とリランキングまで載せれば、「この文書のどこにXが書いてあるか」といった質問はたいていこれで十分に解けます。

ところが、このパイプラインには構造的な死角があります。ベクトル検索は結局「質問と意味が近い断片」を探す作業であり、答えがどれか一つの断片の中にまるごと収まっているときに最もよく働きます。問題は、答えが複数の断片に散らばっているとき、あるいはそもそもどの断片にも明示されていないときです。

バニラRAGが答えられない2種類の質問

第一に、マルチホップの質問。 「最大級の障害に関わったチームが所有する他のサービスのうち、Postgresに依存しているものは?」この答えは、いくつもの連結をたどって初めて出てきます — 障害 → チーム → サービス → 依存関係。どのチャンクもこの連鎖全体を含んではいません。上位k件をどれだけうまく選んでも、別々の文書に散った環をつなぎ合わせる作業は検索ではなく推論です。

第二に、グローバルな「センスメイキング」質問。 「私たちのポストモーテム全体を貫く反復的なテーマは何か?」 GraphRAGの論文が挙げる正確な例がこれです — "What are the main themes in the dataset?"。これは検索問題ではなく要約問題です。論文の言葉ではクエリ中心要約(query-focused summarization)であり、答えは特定のチャンクではなくコーパス全体に広がっています。上位k件を取った瞬間にもう負けています — k件は全体ではないからです。かといって「全部コンテキストに入れる」は100万トークンのコーパスでは不可能で、収まってもlost-in-the-middleで崩れます。

GraphRAGとは何か — グラフ索引を作る

MicrosoftのGraphRAG(Edgeら、arXiv:2404.16130)は、この2つの死角を正面から狙います。中心となる発想は「検索する前に、LLMでコーパスから知識グラフを前もって抽出しておこう」です。論文の表現では、LLMが2段階でグラフ索引を作る — まずエンティティ知識グラフを導き、次に密接に関連するエンティティ群ごとにコミュニティ要約を事前生成する。

索引パイプラインはこう流れます。

チャンキング。 コーパスをTextUnitと呼ぶ分析単位に切る。(ここまでは通常のRAGと同じです。)
抽出。 各TextUnitからLLMがエンティティ、関係、そして重要な主張(claim)を抜き出す。たとえば「決済サービス —(所有)→ アリスのチーム」「決済サービス —(依存)→ Postgres」といったトリプルが積み上がります。
グラフ構築。 抽出したエンティティをノードに、関係をエッジにつないで、コーパス全体を一つの知識グラフにする。
コミュニティ検出。 Leidenアルゴリズムでグラフを階層的にクラスタリングする。密につながったノードが一つのコミュニティにまとまり、コミュニティはさらに上位のコミュニティへと階層をなします。(LeidenはLouvainを改良し「よくつながったコミュニティ」を保証するコミュニティ検出アルゴリズムです — Traagら、2019。)
コミュニティ要約。 各コミュニティについて、下から上へ(bottom-up)LLMが要約を生成する。「このコミュニティは決済インフラとその障害履歴に関するもの」といった要約が階層ごとに作られます。

ここでの重要な転換は、コーパスを理解するという高価な作業を、クエリ時ではなく索引時に前もって済ませておくことです。理解のコストを前払いするわけです。

ローカル検索 vs グローバル検索

こうして作った2つの構造(グラフ + コミュニティ要約)を、質問の種類によって使い分けます。

グローバル検索(Global Search) は先のセンスメイキング質問向けです。仕組みはマップリデュースです — マップ段階で各コミュニティ要約が質問への部分回答を一つずつ作り(それぞれ有用性スコア付きで)、リデュース段階でそれらの部分回答をまとめて最終回答に統合します。論文の文をそのまま移せば、各コミュニティ要約で部分応答を作ったのち、すべての部分応答を再び要約して最終応答を作る、ということです。コーパス全体を見渡す必要がある質問に対して、生のチャンクではなく事前生成した要約を見渡します。

ローカル検索(Local Search) は特定のエンティティに関する質問向けです。質問からエンティティを見つけ、グラフ上でその近傍へ扇状に広がり(fan-out)、つながった関係・テキスト断片・コミュニティ要約を集めてコンテキストを作ります。マルチホップの質問はここで解けます — グラフを歩けば散った環がつながるからです。(これにコミュニティの文脈まで加えたDRIFT検索という変種もあります。)

一言でいえば、グローバルは「森」を、ローカルは「木とその隣人」を見ます。

具体例 — インシデントのコーパス

過去1年分の障害ポストモーテムを数百件、索引したとしましょう。

質問A (ローカル / マルチホップ): 「決済サービス障害に関わったチームが所有する他のサービスは?」
  ベクトルRAG:       決済サービスのチャンクをいくつか返す -> チーム -> 他サービスの連結は取りこぼす
  GraphRAG(ローカル): 決済サービスのノード -(関与)-> チームのノード -(所有)-> サービスのノード
                     グラフを数ホップ歩いて答えを組み立てる

質問B (グローバル / センスメイキング): 「昨年のポストモーテム全体の反復テーマは?」
  ベクトルRAG:        上位k件のポストモーテムだけ返す -> 「全体のテーマ」は原理的に出ない
  GraphRAG(グローバル): コミュニティ要約をマップリデュース
                      コミュニティ1: DBフェイルオーバー / コミュニティ2: デプロイのロールバック / コミュニティ3: 認証切れ
                      -> 「反復テーマ3つ」にリデュース

質問C (単純なローカル照会): 「ERR_2043 の意味は?」
  ベクトルRAG:       該当するチャンクを一つ返す -> 十分(GraphRAGは過剰)

質問Cが重要です。すべての質問がグラフを必要とするわけではありません — 実務の質問の大半はいまだにCに近いのです。

正直なトレードオフ — 安くはない

さて、正直になる番です。GraphRAGはタダではありません。

索引コスト。 抽出段階はコーパスのすべてのチャンクにLLMを回します(取りこぼしたエンティティを拾うため、GraphRAGは複数回のgleaningパスを回します)。そしてコミュニティ要約段階は、階層のすべてのコミュニティごとにまたLLMを回します。つまり索引コストはコーパスの規模に比例して膨らみ、その大半がLLM呼び出しです。Microsoftが公開した資料は具体的な金額を示していないので、ここで数字を作り出すことはしませんが、「文書を埋め込むだけ」のベクトルRAGの索引とは桁が違う作業だという点は明らかです。

レイテンシと更新。 索引はバッチ処理であり、大きなコーパスでは分〜時間単位かかります。より痛いのは更新です — 文書が変わるたびにグラフと要約を作り直す必要があり(増分索引はありますが複雑さを増します)、そのためリアルタイムに変わり続けるコーパスとは相性が悪いのです。

クエリコスト。 グローバル検索そのものも安くありません — マップリデュースが多数のコミュニティ要約にまたがってLLMを何度も呼ぶからです。ローカル検索はずっと安上がりです。

抽出品質への依存。 グラフは抽出が抜き出した分だけの良さしかありません。エンティティを雑に抜けば雑なグラフになり、だからドメインごとに抽出プロンプトを調整する必要があります。何をエンティティとみなすか、どの関係が意味を持つかは、結局ドメインモデリングの問題です — この話はドメイン知識をオントロジーとしてモデリングすると知識グラフを実際に構築するで別途扱います。

で、あなたは使うべきか

判断基準はこう整理できます。

使ってコストに見合う場合

質問がグローバル・テーマ型である — 「全体のテーマ」「全般的な傾向」「XとYがコーパス全体でどう絡むか」。
複数の文書をまたぐマルチホップ推論が必要である。
コーパスが比較的安定しており、索引コストを償却できるほど頻繁に・長く問い合わせられる。

過剰な場合

質問の大半がローカル照会である — 「Xはどこに書いてあるか」「このエラーの意味は」。
コーパスが絶えず変わり続ける。
予算やレイテンシの余裕が乏しく、ハイブリッド検索 + リランキングがすでに評価基準を満たしている。

現実のプロダクションは、たいてい二者択一にせず混ぜます。ローカル照会は安価なベクトル・ハイブリッド検索で処理し、本当のセンスメイキング質問にだけグラフを使います。GraphRAG自体がローカル検索モードを備えている事実が、すでにこのハイブリッド性を物語っています — グラフ対ベクトルの二分法ではなく、質問の種類に合う道具を選ぶスペクトラムなのです。実際の実装ツール — microsoft/graphragライブラリからNeo4j、LlamaIndexのグラフインデックスまで — の比較はGraph RAGを動かす道具たちで別途扱います。

そしてプロダクションRAGパターンの原則はここでもそのままです — ベンチマークではなく、あなたのクエリで評価してください。論文が報告した改善(グローバルなセンスメイキング質問における回答のcomprehensivenessとdiversityの向上)は、LLM審査(LLM-as-judge)で採点された著者報告の数値であり、100万トークン級のデータセットが対象です。あなたのコーパス・あなたの質問で同じ利得が出るかは、小さな評価セットで自分で確かめるべき問題です。

おわりに

まとめるとこうです。ベクトルRAGは答えが一つのチャンクに収まる質問に強く、マルチホップとグローバルなセンスメイキングで構造的に行き詰まります。GraphRAGはその2つの死角を狙い、理解という高価な作業を索引時へ移します — LLMで知識グラフを抽出し、Leidenでコミュニティを見つけ、コミュニティ要約を前もって作り、グローバルな質問は要約のマップリデュースで、ローカルな質問はエンティティ中心のグラフ探索で答えます。

その代わり、索引がLLM予算を大きく食い、更新が面倒です。だからGraphRAGは「より良いRAG」ではなく「別の質問を解くRAG」です。バニラ・ハイブリッドで始め、グローバルなセンスメイキングが実際の失敗地点だと分かったとき — そのときにグラフを取り出してください。道具ではなく、質問が先です。