GraphRAG入門 — ベクトル検索との違いと本番での使い分け

通常のRAGは、質問に近いチャンクを見つけるのが得意です。「装置Aの停止条件は」「契約Xの解約条項は」のように、答えが少数の箇所に書かれている問いにはよく合います。一方、「この1年の障害に共通する組織的な原因は」「全報告書を通じた主要テーマは」という問いでは、近いチャンクを数件拾うだけでは全体像を作れません。

GraphRAGは、文書からエンティティと関係を抽出し、グラフのコミュニティを要約して検索に使います[1]。この記事の結論は、GraphRAGはベクトルRAGの置き換えではなく、関係探索と全体要約のための追加経路だということです。

通常RAGとGraphRAGは答える問いが違う

観点	通常のベクトルRAG	GraphRAG
索引の中心	テキストチャンクと埋め込み	エンティティ、関係、コミュニティ要約
得意な問い	局所的な事実、類似文書	複数文書の関係、全体テーマ、multi-hop
索引コスト	比較的低い	LLM抽出と要約で高い
更新	チャンク単位で容易	関係・コミュニティの再計算が必要
説明可能性	出典チャンク	経路と出典チャンクの両方
主な失敗	正解チャンクを検索できない	誤ったエンティティ統合・関係抽出

グラフDBを使えばGraphRAGになるわけではありません。テキスト中の同一人物・製品・組織を解決し、関係に根拠を結び付け、質問に応じた部分グラフや要約を取り出すところまでが検索設計です。

索引は5段階で作られる

Microsoft Researchの実装は、標準パイプラインでエンティティ、関係、主張を抽出し、コミュニティ検出と階層的な要約、埋め込みを作ります[2]。概念的には次の流れです。

1. 文書分割: 見出しや段落を保ち、根拠へ戻れるTextUnitを作る
2. 抽出: 人物、組織、製品、事象と、それらの関係・主張をLLMで抽出する
3. 正規化: 別名を統合し、同名異物を分離する
4. コミュニティ検出: 密につながるノード群を階層化する
5. 要約と埋め込み: 各コミュニティの報告と、検索に必要なベクトルを作る

最重要なのは3番です。「ABC」「ABC社」「株式会社ABC」を別ノードにすると関係が分断され、同姓同名をまとめると誤った経路ができます。正規化辞書、業務ID、型制約を使い、抽出精度と同一性解決を別々に評価します。

4つの検索方式を質問で切り替える

Microsoft GraphRAGは、Global、Local、DRIFT、Basicの検索方式を提供しています[2]。

Global Search

「全体の主要テーマ」「組織横断のリスク」のようなコーパス全体の問い向けです。関連するコミュニティ報告から部分回答を作り、map-reduce型で統合します。網羅性を得やすい反面、複数のLLM呼び出しで遅延と費用が増えます。

Local Search

「製品Aと障害Bはどう関係するか」のような、特定エンティティ中心の問い向けです。対象ノードから近傍、関係、関連TextUnitへ広げます。回答には最終的な原文根拠を必ず残します。

DRIFT Search

ローカル探索の起点にコミュニティ情報を加え、追加の問いへ展開します。局所的な対象から始めつつ、周辺の重要な文脈を拾いたい調査に向きます。

Basic Search

通常のtop-kベクトル検索です。GraphRAGの中でも、単純な事実質問はこの経路で十分です。高価な検索を常用せず、質問分類で経路を選ぶことが本番運用の鍵です。

def choose_search(question: str) -> str:
    global_markers = ("全体", "主要テーマ", "共通点", "傾向", "横断")
    relation_markers = ("関係", "影響", "つながり", "経路")
    if any(word in question for word in global_markers):
        return "global"
    if any(word in question for word in relation_markers):
        return "local"
    return "basic"

実運用ではルールか小さな分類器で始め、誤ルーティングを評価します。分類をLLMに任せる場合も、basicへ戻すフォールバックと予算上限を持たせます。

Microsoft GraphRAGを最小構成で試す

Python環境でパッケージを導入し、作業ディレクトリを初期化します。公式ガイドは、まず小さなデータと安価なモデルで索引費用を確認するよう勧めています[3]。

python -m venv .venv
source .venv/bin/activate
pip install graphrag

mkdir -p rag-project/input
graphrag init --root rag-project
# rag-project/input/ にUTF-8のテキストを置き、settings.yamlを設定する
graphrag index --root rag-project

索引後、問いの性質に応じて検索方式を変えます。

graphrag query --root rag-project \
  --method global \
  "全報告書に共通する停止原因は何か"

graphrag query --root rag-project \
  --method local \
  "設備Aと温度センサー異常の関係は何か"

設定形式はリリース間で変わり得るため、環境を固定し、索引生成物と設定のバージョンを一緒に管理します。原文を更新したら、ベクトル、グラフ、コミュニティ報告の鮮度を個別に観測します。

本番導入は「質問セット」で判断する

GraphRAGを入れる前に、実ユーザーの質問を最低50件集め、次の3群に分けます。

1. 1〜3チャンクで答えられる局所質問
2. 複数文書の関係をたどる質問
3. コーパス全体を要約する質問

2と3が少ないなら、まず通常RAGの検索改善へ投資した方が費用対効果は高くなります。GraphRAGを試す場合は、通常RAGと同じ質問で比較し、次を測ります。

• 検索: 必要なエンティティ、関係、根拠TextUnitが取得されたか
• 生成: 回答の主張が原文根拠へ戻れるか
• 網羅性: 正解観点の何割を含むか
• 運用: 索引費用、更新時間、p95検索遅延、1問当たり費用
• グラフ品質: 重複ノード率、誤統合率、根拠のないエッジ率

アクセス制御も忘れられません。ユーザーが読めない文書から作ったコミュニティ要約が検索されると、要約経由で情報が漏れます。部署、機密区分、テナントなどのメタデータを索引時に持たせ、検索前に絞ります。AWSもNeptune Analyticsを使うGraphRAGで、カテゴリ属性と等価・包含フィルターを中心に設計するよう案内しています[4]。

まとめ

• 通常RAGは局所的な事実、GraphRAGは関係探索と全体要約に強い
• GraphRAGの品質は、抽出だけでなくエンティティの同一性解決で決まる
• Global、Local、DRIFT、Basicを質問の性質と予算で使い分ける
• 最終回答はグラフ要約だけでなく原文TextUnitへ引用を戻す
• 導入判断は実質問を局所・関係・全体の3群に分けて行う
• 権限フィルターは原文、ノード、コミュニティ要約の全層に適用する

クラウド上の具体的な構成はAWS・Azure・Google CloudのRAG実装で比較します。まずは既存RAGの失敗質問から「関係をたどらないと答えられないもの」だけを抽出し、小さな検証コーパスで試すのが次の一手です。