GraphRAGはいつRAGの代わりに使うべき？

LLMアプリケーションを作るほとんどのチームは、RAGから始めます。これにはそれなりの理由があります。実用的で、理解しやすく、通常は単純なAIユースケースであれば十分に機能します。

しかし、ユーザーが単純な照会（ルックアップ）質問をやめて、関係性が重い質問をし始めると、標準的なRAGはすぐに浅くなってしまいます。

問題はRAGが悪いことではありません。問題は、多くの実際の質問が、関連する段落を見つけることだけにとどまらない点です。人・製品・システム・ドキュメント・出来事・依存関係にまたがるつながりをたどることが求められます。

GraphRAGが埋めようとしているのは、このギャップです。

RAG vs GraphRAG

RAGは、モデルが外部情報にアクセスできるようになったことで、LLMアプリケーションをより有用にしました。

学習データだけに基づいて答えさせるのではなく、RAGパイプラインはドキュメント、チケット、ウィキ、PDF、データベースから関連コンテンツを取得し、そのコンテンツをプロンプトに追加して、そこからモデルに回答させます。

これは多くのユースケースでうまく機能します。

もし質問が次のようなものであれば：

年額サブスクリプションの返金ポリシーは何ですか？

標準的なRAGパイプラインはドキュメントを検索し、正しいポリシーの該当箇所を見つけ、モデルに関連するテキストを渡せます。

問題は、質問が「正しいテキストを見つける」だけで終わらないときに始まります。答えが関係性に依存し始めるときです。

例えば：

特定のコンポーネント不足の影響を受ける製品について、納期遅延の原因になり得るサプライヤーはどれですか？

この質問は、単に一致する段落を探しているだけではありません。サプライヤー、コンポーネント、製品、出荷、遅延、依存関係をシステムに結び付ける必要があります。

ここでGraphRAGが役に立ちます。

RAGは関連しているように聞こえるテキストを見つけるのが得意です。GraphRAGは、答えが「どうつながっているか」に依存するときに、より適しています。

What RAG Does Well

Retrieval augmented generation（通常はRAGと略されます）は、言語モデルと外部の検索（リトリーバル）システムを組み合わせます。元の論文では、これを「パラメトリックなモデル（LLMそのもの）」と「非パラメトリックなメモリ（外部知識）」を組み合わせたもの、と説明しており、その外部知識は通常、外部コーパスから取得されます。

多くの現代的な実装では、この検索ステップで埋め込み（embeddings）を使います。基本的な流れは次のようになります：

1. ドキュメントをチャンクに分割する。
2. 各チャンクを埋め込みに変換する。
3. 埋め込みをベクトルインデックスに保存する。
4. ユーザーの質問を埋め込みに変換する。
5. 最も類似したチャンクを取得する。
6. 取得したチャンクをLLMのプロンプトに追加する。
7. 回答を生成する。

これは、答えが1つ、あるいは少数のテキストチャンクに含まれている可能性が高い場合に有用です。良いRAGのユースケースには次のようなものがあります：

• ドキュメント検索
• FAQアシスタント
• 社内ナレッジベース検索
• カスタマーサポートの回答生成
• 関連する小さな一連のドキュメントの要約

多くのチームにとって、これは適切な出発点です。知識グラフを構築するよりもシンプルで、素早く有用な結果を届けられます。

しかし問題は、類似性は理解と同じではないことです。

ベクトル検索システムは、クエリに近い雰囲気のチャンクを見つけられます。しかし、あるエンティティが別のエンティティを所有しているのか、依存しているのか、矛盾しているのか、あるいは複数ステップの連鎖を通じて別のエンティティに影響しているのかを、自動的に知っているわけではありません。

質問が関係性を含むものになったとき、その違いが重要になります。

Where RAG Gets Shallow

RAGは通常、孤立したテキストチャンクを取得します。その結果、いくつかのよくある問題が起きます。

まず、チャンク化によって文脈が壊れることがあります。ポリシー、顧客、取引、技術的な意思決定は、それが他の事実とどのように結び付いているかが見えないと、意味を成さない場合があります。ドキュメントをチャンクに分割すると、その構造が隠れてしまうことがあります。

次に、セマンティックな類似性によって過剰に取得してしまうことがあります。実際の回答には役立たないのに、関連しているように聞こえるチャンクが含まれてしまうかもしれません。

第三に、RAGは本質的に関係性をまたいで推論するわけではありません。サプライヤーに関するテキスト、製品に関するテキスト、出荷遅延に関するテキストを取得することはできても、それらがどうつながっているかを自動的に理解しているわけではありません。

次の質問を考えてみてください：

サプライヤーAの遅延した出荷の影響を受けるのは、どの顧客ですか？

標準的なRAGパイプラインは、サプライヤーAに言及した文書、遅延した出荷、顧客についての文書などを取得する可能性があります。これは役に立ちますが、それでも不完全です。

実際の答えには、例えば次のような経路が必要になるかもしれません：

サプライヤーA -> 補給する -> コンポーネントX -> に使用される -> 製品Y -> に含まれる -> 出荷Z -> に割り当てられる -> 顧客C

この経路は、単なるテキストの類似性ではありません。構造そのものです。

アプリケーションが、このような質問に答える必要があるなら、ナレッジベースを平坦なチャンクとして扱うのは、この問題に対する弱いモデルです。

What GraphRAG Adds

GraphRAGは、RAGの有用な部分である検索（retrieval）を保持します。しかし、情報をエンティティと関係として表現するグラフ層を追加します。Microsoftの論文GraphRAG for query focused summarizationは、このパターンを広め、グラフ構造を使って、より広いつながりを持つ文脈を必要とする質問に答える方法として定着させるのに役立ちました。

「次のようなチャンクだけを保存する」のではなく：

サプライヤーAはコンポーネントXを提供する。コンポーネントXは製品Yで使用される。製品Yは出荷Zの一部である。

グラフは構造を直接表します：

(Supplier A)-[:SUPPLIES]->(Component X)
(Component X)-[:USED_IN]->(Product Y)
(Product Y)-[:INCLUDED_IN]->(Shipment Z)
(Shipment Z)-[:ASSIGNED_TO]->(Customer C)

これにより、システムは似たテキストを一致させるだけでなく、関係性をたどることで文脈を取得できるようになります。

GraphRAGのパイプラインは、次のように動作するかもしれません：

1. セマンティック検索、キーワード検索、または別の方法を使って出発点を見つける。
2. グラフ内で関連するノード、またはノードの集合を特定する。
3. つながった関係性をたどる（トラバースする）。
4. 接続された文脈を評価し、フィルタし、圧縮する。
5. 最終的な文脈をLLMに送る。

重要な違いは、検索が「どこから始めるか」を見つけるのに対し、グラフ探索（トラバース）は「何がつながっているか」を見つける点です。

そのためGraphRAGは、次のような関係性が重いユースケースで有用です：

• システムが製品、コンポーネント、サプライヤー、遅延した出荷を追跡する必要があるサプライチェーン分析
• 不審な挙動が共有アカウント、デバイス、取引、またはアドレスにまたがって現れる場合の不正検知
• アラートをユーザー、資産、権限、攻撃経路に結び付ける必要がある場合のサイバーセキュリティ調査
• 病気、遺伝子、薬、臨床エビデンスの関係性に答えが依存する場合のヘルスケアまたはライフサイエンス研究
• サポートチケット、購入、製品の利用状況、アカウント履歴を結び付ける必要がある場合のカスタマー360アプリケーション

これは単なるドキュメント検索の問題ではありません。関係性の問題です。

RAG と GraphRAG は敵ではない

この話題の手抜き版はこうです。「RAG は悪い、GraphRAG は良い」。

それは違います。RAG はまだ有用です。データが主に非構造化テキストで、質問がストレートであるなら、標準的な RAG パイプラインで十分かもしれません。GraphRAG は、答えの形が接続された事実に依存するときに役立ちます。より良い考え方は次のとおりです。

実際には、両方を使う優れたシステムも多いです。ベクトル検索 は意味的に関連する入口を見つけられます。グラフ探索 は、その入口から接続された文脈へと広げられます。

この組み合わせは、多くの場合、どちらか一方の手法だけよりも役に立ちます。

検索ロジックをデータの近くに保つ

GraphRAG は、あらゆる検索ステップが別々の場所に分かれていると、保守が難しくなります。

あるサービスが類似する断片を見つけます。別のサービスがグラフを保存します。さらに別のサービスが関係性を展開します。別のサービスが結果をランキングします。別のサービスが最終的なプロンプトを組み立てます。

それでも動作することはありますが、答えが間違っているときにデバッグすべき可動部品が増えることになります。

よりきれいなパターンは、可能な限り検索ロジックをグラフ自身の近くに保つことです。検索は開始地点を見つけられます。探索は文脈を広げられます。ランキングとフィルタリングは、プロンプトに渡される前に結果を減らせます。

それが Memgraph における Atomic GraphRAG の考え方です。オーケストレーション用のコードの山に分散させるのではなく、可能な限り、取得経路を単一の実行レイヤーとして表現します。

より広い教訓は、ツールに固有のものではありません。GraphRAG のパイプラインが検査しにくいなら、信頼しにくくなります。取得経路は、見える化され、テスト可能で、変更しやすくあるべきです。

実務的なルール

関連するテキストを取得する必要があるなら RAG を使います。接続された文脈を取得する必要があるなら GraphRAG を使います。それが本当の違いです。

質問が適切な段落を見つけることで答えられるなら、おそらく RAG で十分です。質問が、人、製品、システム、ドキュメント、出来事、リスク、あるいは依存関係の間にある関係性を追跡する必要があるなら、単にテキストを取得しているだけではありません。グラフを取得しているのです。

重要なのは、GraphRAG を追加の層として使い始めることではなく、問題に対して適切な取得モデルである場所で使うことです。