9月17日、Towards Data Scienceが「When Does Graph RAG Actually Add Value? A Hands-On Experiment」と題した記事を公開した。この記事では、Graph RAGが通常のRAGと比べて実際にどのようなケースで優位性を発揮するかを、4種類のシステムを自前で構築・評価した実験を通じて明らかにしている。結論を先に言えば、Graph RAGが Plain RAGを明確に上回るのは「複数ドキュメントをまたぐ概念間の推論」という特定の問いに限られ、その他の用途では過剰投資になりやすい——これが個人のThinkPadで完結した実験から得られた現実だ。
RAG（Retrieval-Augmented Generation：検索拡張生成）にナレッジグラフを組み合わせた「Graph RAG」は、2024年にMicrosoft ResearchがGraphRAG論文を公開して以降、LangChainやLlamaIndexでの実装サポートも相次ぎ、アーキテクチャ解説やアナリストレポートで頻繁に登場するようになった。だが「本当に効果があるのか」を実際に手を動かして確かめた記事は少ない。本記事はその問いに正面から向き合い、4システムを比較した実践レポートだ。
実験の設計
使用したデータはAnthropicがAIセキュリティについて公開した2本の記事。このコーパスに対して、以下4つのシステムをすべて同一コンポーネントで構築し、同じ質問セットで評価した。
| システム | 概要 |
|---|---|
| A — Plain RAG | ドキュメントをチャンク分割してベクトル検索。最も一般的なRAG構成 |
| B — Graph Only | テキストではなくNeo4j（グラフデータベース）上のエンティティと関係のみを検索 |
| C — Graph RAG | ベクトル検索 + グラフ検索を組み合わせ |
| D — Full Context（Claude Haiku） | ドキュメントをそのままフロンティアモデルに渡す（検索なし） |
ローカル推論モデルにはMicrosoft Phi-4（14B、約140億パラメータ）をOllamaで実行、埋め込みモデルにはall-MiniLM-L6-v2、グラフDBにはNeo4j（公式サイト）を使用した。フロンティアモデルとの比較対象にはClaude Haiku 4.5を採用している。
評価軸はAccuracy（正確性）・Completeness（網羅性）・Reasoning（論理性）・Provenance（出典追跡性）の4次元で、スコアリングもClaude Haikuに担当させた。
結論から言うと：「どの問題を解くか」で答えは変わる
総合スコアではSystem D（フロンティアモデルへの全文渡し）が最高だった。しかしこれは「コーパスがコンテキストウィンドウに収まる規模だから成立する」という条件付きの結果だ。ドキュメントが数百本規模になれば、この手法は現実的ではなくなる。
より面白いのは、個々の質問での各システムの振る舞いだ。実験では4問の質問セットが用意されており、以下ではGraph RAGの特性が最も鮮明に出た代表ケース（Q1）を詳述する。残りのケースでは単一ドキュメント内の事実検索や要約など、システム間の差異が相対的に小さい設問が含まれており、総合的に見るとPlain RAGで十分な場面が多いという傾向が確認された。
Q1：複数ドキュメントをまたぐ推論
「4問構成のリスクフレームワークはSDLC（ソフトウェア開発ライフサイクル）セキュリティコントロールとどう関係するか？」という問い。フレームワークは一方の文書に、SDLCコントロールはもう一方の文書にしか登場しない。
- Plain RAG：関連チャンクは取得できたが、2文書をまたいだ接続ができず、モデルは「判断できない」と回答。安全ではあるが最も役立たない結果だった。
- Graph RAG：グラフの関係構造を使って2文書間の概念的なつながりを特定し、フレームワークとコントロールの関係を説明できた。
Graph RAGがPlain RAGを明確に上回ったのはこのケースだ。複数ドキュメントにまたがる概念の接続こそ、グラフが本来の強みを発揮する場面である。
Graph Onlyの落とし穴
System B（グラフのみ）には重大な限界があった。グラフはどの概念がどう繋がっているかを伝えられるが、元のテキストがないため、LLMは詳細情報が不足しハルシネーションで補完してしまった。構造だけではなく、テキストのグラウンディングが不可欠だということが実験で確認された。
グラフ構築での実装上の注意点
グラフ構築でも重要な知見が得られた。最初はPhi-4にエンティティ関係のラベルを自由に生成させたところ、一貫性のない関係ラベルが大量に生成されグラフが機能しなかった。たとえば「is_related_to」「relates_to」「has_relation_with」のように意味上は同一でも表記が異なるラベルが混在し、グラフ上で同じ概念が孤立した別ノードとして扱われてしまう状態になった。
この問題を解消するには、事前に「IMPLEMENTS」「MITIGATES」「PART_OF」といった関係タイプの語彙（constrained vocabulary）を定義し、LLMの出力をその語彙に制限することが必要だった。制約なしで自由生成させると、グラフは構造的には存在するが検索に使えない「見かけ倒し」になりやすい。実装者が見落としやすいポイントだ。
また、エンティティ抽出の粒度設計も重要で、粗すぎると関係の表現力が落ち、細かすぎるとノード数が爆発してクエリコストが跳ね上がる。本実験ではこの調整にも相応の試行錯誤が必要だったと報告されている。
いつGraph RAGを選ぶべきか
本実験の範囲から導ける判断基準は以下のとおりだ。
- Graph RAGが有効：複数ドキュメント間の概念的なつながりを推論する必要がある場合
- Plain RAGで十分：単一ドキュメント内の局所的な事実を検索するだけの場合
- フルコンテキストで十分：コーパスがコンテキストウィンドウに収まる規模の場合（エンジニアリングコストを考えると、この選択肢を最初に検討すべきだ）
Graph RAGの追加工数（グラフ構築、エンティティ抽出、関係設計、Neo4jの運用）は相応のコストを伴う。そのコストが正当化されるのは、情報が複数ソースに分散していて、それらの関係を明示的に辿る必要がある問題に限られる。Microsoft ResearchのGraphRAG論文が示した「グローバルな問いへの対応力」という強みは本実験でも再確認されたが、それ以外の多くの用途ではPlain RAGやフルコンテキストのほうがシンプルかつ高性能という現実も直視する必要がある。
詳細はWhen Does Graph RAG Actually Add Value? A Hands-On Experimentを参照していただきたい。
