GraphRAG 入門 #2 グラフは「検索の索引」か「データ本体」か？GraphRAG と KGQA の 2 つのパターンを整理してみた【Amazon Neptune】
はじめに
こんにちは！AI 事業本部のこーすけです。
本記事は GraphRAG 入門シリーズの 2 本目です。1 本目はこちらです。
この後のブログでは、実際に手を動かしながら検証していく予定ですが、調べると GraphRAG という言葉がさす意味や技法の定義があいまいでよくわかりませんでした。
GraphRAG という言葉は、データソースであるドキュメント（テキスト情報）からグラフを構築するためのエンティティや関係を LLM によって抽出し、それを検索に活用する手法のことを指すことがまず多いと思います。ベクトル検索の代わりに、あるいはベクトル検索と併用してグラフによる検索を行い、より高い検索精度を期待するものです。
一方でナレッジグラフという言葉があります。これは GraphRAG が登場する以前からある技術で、知識の関係をノードとエッジで表現したデータ構造のことです。
また近年、LLM の登場によって質問内容からグラフを検索するためのクエリをより高い精度で生成することができるようになってきたため注目されている言葉です。
つまり、LLM がこの技術を活用する際の文脈としては、既存のナレッジグラフあるいは表などの構造化データに対し、質問内容からクエリを生成する text-to-SQL、text-to-Cypher といった内容を指しているときもあるように見受けられました。
整理すると、両者の違いは、グラフを 「ドキュメントを検索するための索引」 として使うのか、 「データ本体」 として使うのかという点にあります。
今回はこれら 2 つの、「LLM による回答生成を強化する」ために（あえて周りくどい言い方をします）グラフを活用する技術を 2 つのパターンに分けて捉え直し、次回以降のハンズオンで両者を検証していくための土台とします。
この記事で整理する内容は以下となります。
- ベクトル RAG（一般的な RAG）がどのような質問を苦手とするか
- パターン ①: テキスト文書しかない場合 — 文書からグラフを自動構築して検索を補強する
- パターン ②: 構築済みのナレッジグラフがある場合 — グラフに自然言語で問い合わせる
- 2 つのパターンの比較と使い分け
なお、本記事の内容は筆者が現時点で調査できた範囲に基づく整理であり、正確性を保証するものではありません。特に用語の定義は文献によって揺れがあるため、一つの見取り図としてお読みください。誤りにお気づきの際はご指摘いただけると幸いです。
通常のベクトル RAG の仕組みと苦手なパターン
RAG（Retrieval-Augmented Generation）は、質問に関連する情報を検索で集め、それを根拠として LLM に回答させる仕組みです。処理の流れは次の通りです。
- 文書をチャンクに分割する
- 各チャンクを埋め込みモデルでベクトル化し、ベクトル DB に保存する
- 質問もベクトル化し、意味が近いチャンクを上位 k 件取得する
- 取得したチャンクを根拠として LLM が回答を生成する
まずは従来のベクトル検索を用いた RAG には、対応できない、または苦手なパターンがあることを押さえておきます。
このベクトル検索は「質問文と意味的に似ているチャンクを探す」検索手法です。
この性質が問題になるケースを、具体例で説明します。
社内の障害対応ナレッジとして、次の 3 種類の文書が蓄積されているとします。
- 障害報告書: 障害 ID・発生日時・影響を受けたサービス名を記載
- サービス構成台帳: 各サービスが依存するコンポーネントを記載
- 顧客契約一覧: 各サービスをどの顧客が契約しているかを記載
ここでとある社員が、「過去に、障害 INC-1042 の影響を受けた可能性がある顧客はどこか」という質問をしたいとします。
回答には、障害報告書から影響サービスを特定し、顧客契約一覧でそのサービスの契約顧客を引く、という文書の突き合わせが必要です。しかし顧客契約一覧の文面は、質問文である「INC-1042 の影響を受けた顧客」とは意味的に似ていないため、ベクトル検索による類似度比較の際には上位に挙がってこず、回答に必要なチャンクを取得することはむずかしいはずです。
そのほかにもベクトル RAG が苦手とする質問を整理します。
- 多ホップの質問: 上記の例のように、答えに至る情報が複数の文書に分かれている質問で、正解をたどるまでの中間・末端の文書はユーザーの質問文と意味的に似ていないため、類似検索では拾えない。
- 集計を含む質問: 「今期もっとも障害件数が多かったサービスは？」のような質問で、全件の突き合わせが必要だが、類似検索は上位 k 件しか取得しないため抜け漏れが発生する。
- 否定・不在の質問: 「一度も障害報告のないサービスは？」のような質問で、「ない」ことは文書に書かれていないため、検索で拾えず、確定情報として扱えない。
こういった既存の弱点を、グラフ構造で補うアプローチが冒頭で説明した 2 つの手法です。
グラフが用意されているか
「グラフ構造で補うアプローチ」といっても、その前段には「そのグラフはどうやって整備するのか」という問題があります。実際の現場を想定すると、状況はおおむね次のどちらかだと思います。
一つは、文書だけ整備されているという状況です。社内 Wiki・設計書・報告書・議事録など、多くの組織でナレッジの大半は非構造の文書として蓄積されています。この場合、グラフは存在しないため、グラフを検索に活用するためにはグラフを作成するところから必要になります。
もう一つは、構築済みのナレッジグラフがある場合です。この場合はそのグラフデータ自体を直接 LLM に参照させればよさそうです。
どちらの状況にあるかで、グラフの位置づけと仕組みが根本的に変わると思います。前者をパターン ①、後者をパターン ② として順に整理していきます。
パターン ①: ナレッジグラフがない場合 → GraphRAG
「LLM による回答生成を強化する」方法として、ドキュメント検索をより高精度にするためにグラフを活用するパターンです。
処理の流れは次の通りです。
- ドキュメントデータの取り込み時、チャンク分割・ベクトル化に加えて、LLM が各チャンクからエンティティ（人・組織・サービス・ID など）と関係を自動抽出する
- 抽出したエンティティをノードとして、チャンクとエンティティを紐づけたグラフを構築する。同じエンティティに言及する複数のチャンクは、グラフ上でつながる
- 検索時は、まずベクトル検索でチャンクを特定し、グラフをたどって「同じエンティティに言及する関連チャンク」まで検索範囲を拡張する
- 拡張して集めたチャンク群を根拠に LLM が回答する
重要なのは、最終的に LLM に渡るコンテキストはあくまで文書チャンクのテキストであるという点です。グラフは「どのチャンクを追加で取得するか」を決める経路、すなわち検索用のインデックスとして機能するもので、ベクトル検索と組み合わせてより高精度な検索を実現するために活用される方法です。
この構成が一般に GraphRAG と呼ばれているように思います。AWS では Amazon Bedrock Knowledge Bases の GraphRAG がこのパターンのマネージド実装にあたります。バックエンドのグラフは Amazon Neptune Analytics 上に自動構築されるため、利用者は S3 に文書を配置するだけでよく、グラフのモデリングや構築作業は不要です。文書しかない状態から追加の設計なしにグラフの恩恵を受けられるので、AWS 上でまず試す際はこちらがお手軽だと思います。
一方で、把握しておくべき性質もあります。グラフの品質が LLM による自動抽出の精度に依存することです。エンティティの表記ゆれ（同一のサービスが「認証基盤」「認証基盤サービス」の 2 ノードに分裂する等）や抽出漏れ（ID 文字列がエンティティとして認識されない等）が起きると、グラフが分断され、検索経路が途中で途切れます。
グラフ設計を省略できることとのトレードオフなので、実際に抽出されたグラフの構造を確認する必要があります。この挙動は次回（#3）のハンズオンで実際に確認します。
パターン ②: 構築済みのナレッジグラフがある場合 → KGQA
もう一方は、ナレッジグラフがすでに整備されている場合です。構成管理 DB や業務システムのマスタデータのように、エンティティ間の関係が正確に管理されたデータをグラフとして保持しているケースがこれにあたります。
このパターンでは、グラフを索引として使うのではなく、グラフのデータそのものを回答の情報源として使います。検索対象は文書チャンクではなく、グラフのノード・エッジ・プロパティです。
つまり「LLM による回答生成を強化する」方法として、グラフそのものの知識を活用するパターンです。
やることは「グラフ DB に蓄積したデータを、クエリ言語を知らないユーザーでも自然言語で照会できるようにする」ことで、広義の意味では RAG の一種ともいえるとは思いますが、この技術領域は GraphRAG とは別に KGQA（Knowledge Graph Question Answering） と呼ばれています。
KGQA 自体は LLM の登場以前、2010 年代から Wikidata や Freebase といった大規模ナレッジグラフを対象に研究されてきた分野です。従来は、質問文をグラフクエリ（SPARQL 等）に変換する専用モデルを学習させる方式や、質問と候補ノードの類似度をランキングする方式が主流でしたが、いずれも大量の学習データや対象グラフごとの作り込みが必要でした。LLM の登場によって、この「自然言語からグラフ探索への変換」を学習なしで行えるようになった、というのが現在の状況です。本記事のパターン ② が扱うのは、この LLM を使った構成です。
LLM を使った構成での処理の流れは次の通りです。
- 質問文から、LLM がグラフ探索の手がかり（起点となるエンティティ、たどる関係の仮説、実行可能なグラフクエリなど）を生成する
- それを使って実際にグラフを検索する（エンティティの照合、パスの探索、クエリの実行）
- 検索で得られたノード・エッジ・クエリ実行結果を根拠に、LLM が回答を生成する
パターン ① と対比して重要なのは、LLM の役割に「自然言語をグラフ探索に変換する」タスクが加わる点です。クエリ変換の工程だけを見れば、RAG というより text-to-SQL（データベースへの自然言語インターフェース）に近い技術だと思います。
先ほどの障害対応の例で言えば、障害・サービス・顧客の関係がグラフとして正確に登録されているので、「INC-1042 の影響顧客」は関係をたどるだけで確定します。さらに、ベクトル RAG の弱点として挙げた集計（「今期もっとも障害件数が多かったサービスは？」）や否定・不在（「一度も障害報告のないサービスは？」）の質問も、グラフ全体への集計クエリや不在条件のクエリとして実行できるため、構造的に対応できます。パターン ① ではこれらはチャンクを広く集めて LLM の突き合わせに頼るしかなかったので、ここは索引方式とデータ本体方式の差が出るところだと思います。
一方で、把握しておくべき性質もあります。パターン ① のリスクだった「自動抽出の精度」は、グラフを人間や業務システムが正確に構築しているため、このパターンには存在しません。代わりにリスクは「LLM が正しいクエリ・探索に変換できるか」に移ります。存在しないリレーション名を推測してクエリが空振りする、質問中の表現をグラフ上のノードにうまく照合できない、といった失敗がこれにあたり、グラフのスキーマを LLM に提示したり、検索結果をフィードバックして反復させたりする工夫がこの領域の研究テーマになっているようです。また、そもそも正確なグラフを構築・維持するコスト自体はこのパターンの前提として必要になります。
AWS 周辺では、awslabs の OSS である byokg-rag（graphrag-toolkit のサブプロジェクト）がこのパターンの実装です。名前の BYO は "Bring Your Own"、つまり構築済みのグラフを持ち込む方式であることを表しています。シリーズの #5 でハンズオンします。
比較と使い分け
2 つのパターンを並べて比較します。
| パターン ①: GraphRAG | パターン ②: KGQA | |
|---|---|---|
| 入力データ | 文書（非構造化） | 構築済みグラフ（構造化） |
| グラフの位置づけ | 自動生成される検索用の索引 | データ本体 |
| グラフを作るのは | LLM（自動抽出） | 人間・業務システム |
| LLM に渡る根拠 | 文書チャンク | ノード・エッジ・クエリ実行結果 |
| リスクの所在 | 抽出精度（表記ゆれ・漏れ） | クエリ変換精度 |
| 近い技術 | ベクトル RAG の拡張 | text-to-SQL |
| AWS での実装 | Bedrock Knowledge Bases の GraphRAG | byokg-rag（OSS） |
- 文書しかない → パターン ①。グラフの設計・構築なしで検索拡張を利用できます。ただし自動抽出の精度リスクを許容する必要があります。
- 正確なグラフがある、または構造化データから作れる → パターン ②。抽出リスクがなく、集計・否定条件を含む質問にもクエリで対応できます。ただしグラフの構築・維持が必要となります。
- 両者は排他ではないので、文書由来の知識はパターン ①、業務データはパターン ②、と使い分けるハイブリッド採用もあり得ると思います。
このシリーズの今後について
残りの記事では、この 2 つのパターンを実際に AWS 上で検証していきます。
- #3: パターン ① のルート。Bedrock Knowledge Bases のマネージド GraphRAG を、同じ文書・同じ条件のベクトル RAG と比較し、多ホップ質問への強さと、自動抽出のリスクが実際にどう現れるかを確かめます。
- #4: パターン ② の準備。ナレッジグラフを Amazon Neptune Database 上に自分の手で構築します。
- #5: パターン ② のルート。#4 のグラフに byokg-rag で自然言語の質問を投げ、多ホップ・集計・否定条件の質問にどこまで答えられるかを検証します。
おわりに
今回は、RAG でグラフを活用する 2 つのパターンと、GraphRAG・KGQA という用語の関係を整理しました。
- ベクトル RAG は「情報のつながりをたどる」質問が構造的に苦手です。
- 文書しかない場合は、グラフを検索の索引として自動生成する文書起点の GraphRAG（Bedrock のマネージド GraphRAG）。情報源は文書です。
- 構築済みのグラフがある場合は、グラフをデータ本体として自然言語で照会する KGQA（byokg-rag）。情報源はグラフです。
なお、この「索引かデータ本体か」という整理は、GraphRAG のサーベイ論文（参考文献の A Survey of Graph Retrieval-Augmented Generation for Customized Large Language Models）にも同様の分類が記載されていました。同サーベイでは、グラフを索引として使い元テキストを返す構成を Index-based GraphRAG、グラフ自体を知識の担体として使う構成を Knowledge-based GraphRAG と呼び分けており、本記事のパターン ①・② はおおむねこの 2 つに対応します。
次回からはハンズオンに戻り、まずパターン ① のマネージド GraphRAG を実際に動かして、ベクトル RAG との差を確かめます。
最後まで読んでいただきありがとうございました！
参考文献
- Amazon Bedrock Knowledge Bases が GraphRAG をサポート（AWS ドキュメント）
- Amazon Neptune Analytics（AWS ドキュメント）
- awslabs/graphrag-toolkit（GitHub） — byokg-rag を含む OSS ツールキット
- BYOKG-RAG: Multi-Strategy Graph Retrieval for Knowledge Graph Question Answering（arXiv） — パターン ②（KGQA）側の代表的な手法
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization（arXiv） — GraphRAG という名前の由来になった Microsoft Research の論文
- Graph Retrieval-Augmented Generation: A Survey（arXiv） — GraphRAG の定義と、グラフデータ源・下流タスクの分類を整理したサーベイ
- A Survey of Graph Retrieval-Augmented Generation for Customized Large Language Models（arXiv） — グラフを索引として使う Index-based と、知識の担体として使う Knowledge-based に分類したサーベイ。本記事のパターン ①/② の整理に対応する
- neo4j-graphrag-python（Neo4j Docs） — Text2CypherRetriever を含む GraphRAG ライブラリ
- 大規模言語モデルとナレッジグラフを用いたエージェントベースの質問応答手法の分析（人工知能学会 SIG-SWO-067-03） — KGQA 手法の分類と比較分析
