ベクトルRAGの限界とGraphRAGの効果：4つの研究が示す性能差

ベクトルRAGの限界

従来のRAG（検索拡張生成）では、文書を小さなチャンクに分割し、それぞれを埋め込みベクトルに変換してインデックスを作成する。クエリが来ると、類似度の高いチャンクを上位k件取得し、そのままモデルに渡して回答を生成する。この方式は「Q3の返金ポリシーは？」のような局所的な質問には強い。しかし「2年間のカスタマー不満の共通テーマ」のような、文書全体を横断する質問では、1つのチャンクに答えが入っていないため、うまく機能しない。

この構造的な欠陥として、記事は三つの点を挙げている。一つは、異なるチャンクにまたがる情報を関連付けることができない点。もう一つは、全体を俯瞰する質問に対して類似検索では表面的に似たチャンクしか返せない点。そして、チャンクの境界で文脈が切断され、複雑な推論に必要な関係性が失われる点である。Microsoft Researchもこの問題を認識しており、ベースラインのRAGは「点と点を結ぶのに苦労する」と指摘している。

GraphRAGの仕組み

GraphRAGは、質問が来る前のインデックス構築段階で、LLMを使ってテキストからエンティティ（実体）と関係性を抽出し、重み付き知識グラフを構築する。さらに、Leidenアルゴリズムによるコミュニティ検出を行い、関連するトピックの階層構造を作り、各コミュニティに自然言語の要約を事前作成する。これにより、質問時に孤立したチャンクではなく、構造化された文脈をモデルに提供できる。

クエリ時には、関連するコミュニティの要約を基に部分回答を生成し（マップ）、それらをランク付けして統合する（リデュース）という手順を踏む。最終的な回答は、いくつかの断片ではなく、グラフ構造に基づいて合成される。HippoRAGというバリアントは、グラフとPersonalized PageRankを使って関連する文章を見つけるが、アイデアは同じで、コサイン類似度だけでなく関係性に基づいて文脈を決定する点が特徴だ。

エビデンスが示す性能差

Microsoftが行った比較実験では、100万トークン規模のデータセットを使い、RAGとGraphRAGを全体を把握するタイプの質問で比較した。LLMを判定役として、網羅性、多様性、エンパワーメント（活用しやすさ）の3軸で評価したところ、GraphRAGはベクトルRAGに対して、網羅性で72〜83%、多様性で62〜82%の比較で勝った。また、最上位の要約はソーステキストを直接処理する場合と比べて最大97%少ないトークンで済んだ。

さらに、マルチホップQAの標準ベンチマーク（MuSiQue、HotpotQA、2WikiMultiHopQA）で、正解に関連する文章が上位5件に入るRecall@5を比較すると、素のRAGの73.4%に対して、グラフ誘導のRAGは87.8%に向上した。この+19.6ポイントという改善は、“チャンクの限界”をグラフが補っている証拠と言える。

適用判断と注意点

ただし、GraphRAGにはコストが伴う。インデックス構築でLLMを大量に使うため、処理時間と計算コストがベクトルRAGよりもはるかに高くなる。記事は「無料で手に入るわけではない」と述べており、常にGraphRAGを使うべきではないとしている。

具体的には、単一の事実に基づく質問や、チャンクに答えが含まれる場合は従来のRAGで十分だ。一方、全体を横断する分析や、複数の文書にわたる推論が必要な質問では、GraphRAGの効果が期待できる。どのタイプの質問が業務で多いかを把握し、コストと精度のトレードオフを考慮して選ぶことが重要だろう。