9月24日、Neo4jが「Vector RAG vs. GraphRAG: Which retrieval do you need?」と題した記事を公開した。Neo4jは自社製品であるグラフデータベースを提供する企業であり、本記事はその公式ブログに掲載されたものである点は念頭に置いておきたい。内容はVector RAGとGraphRAGの仕組みの違いと、どちらをAIパイプラインに採用すべきかの判断基準について解説したものだ。
Vector RAGの限界——「つながり」を検索できない問題
RAG（Retrieval-Augmented Generation）の実装として広く使われているVector RAGは、テキストをチャンク分割してベクトル埋め込みし、クエリとの類似度でランキングする仕組みだ。「返品ポリシーについて教えて」という質問に対して、その言葉を使っていない文書でも意味的に近いものを返せる点は強力である。
しかし、「先週3件のチケットを引き起こしたのはどのベンダーの障害か？」という質問になると話が変わる。チケット、サービスレコード、障害報告書がそれぞれインデックスに存在していても、それらが互いに名指しで言及していなければ類似度検索でつなげる方法がない。top_k（返すチャンク数）を増やしても減らしても本質的な解決にはならない。ベクトルはそもそも「関係性」を保存していないからだ。
GraphRAGが複雑な質問に強い理由
GraphRAGは類似度ランキングではなく、グラフ上のリレーションシップをトラバース（巡回）することでコンテキストを取得する。チケットはサービスにつながり、サービスはベンダーにつながり、ベンダーは障害レコードにつながる。この構造があれば、「チケット→サービス→ベンダー→障害」という経路を1回の検索で辿れる。
GraphRAGの検索は多くの場合、ベクトル検索から始まる。最初に質問に最も近いノードをベクトルで特定し、そこからCypherクエリ（Neo4jのグラフクエリ言語）でリレーションシップを展開する、という構造だ。
実装はneo4j-graphragパッケージ（pip install neo4j-graphrag）で以下のように書ける：
from neo4j_graphrag.retrievers import VectorCypherRetriever
graph_retriever = VectorCypherRetriever(
driver,
index_name="ticket_embeddings",
embedder=embedder,
retrieval_query="""
WITH node AS ticket
MATCH (ticket)-[:AFFECTS]->(service:Service)
<-[:RUNS]-(vendor:Vendor)
-[:HAD]->(outage:Outage)
RETURN ticket.text AS ticket_text,
service.name AS service,
vendor.name AS vendor,
outage.summary AS outage_summary
"""
)
ベクトルインデックスが最近傍チケットを見つけ、Cypherクエリがそこから関連するサービス・ベンダー・障害情報を引き出す。Vector RAGなら複数回の別々の検索が必要な箇所を、1パスで処理できる。
GraphRAGはもう一つの利点として回答の根拠を追跡できる点がある。どのノードとリレーションシップを使って答えを組み立てたかが残るため、デバッグやガバナンス対応がしやすい。
ベンチマーク結果について
元記事では、UK国立データイノベーションセンター（NICD）が実施した検証として、「データベースなし」「ベクトルのみ」「ベクトル＋グラフ」の3構成を複雑な質問群で比較した結果が紹介されている。元記事に記載された数値によれば、GraphRAGはVector RAGに対して正確性（truthfulness）で大きく上回る結果が示されているとのことだが、これらの具体的な数値（「約80%上回った」「65.3% vs 28.9%」など）については、元記事を直接確認することを強く推奨する。紹介記事の見出しや本文で断定的に引用することのリスクを考慮し、ここでは原文への参照にとどめる。
また、元記事ではNeo4jスポンサーのIDC調査（2026年5月）として、Neo4jを本番運用している企業でGenAIのハルシネーション率が低下したという結果も言及されている。ただし、この調査はNeo4j自身がスポンサーであり、調査対象もすでにNeo4jを採用している企業に限定されている。NICDの検証とはスコープ・条件が大きく異なるため、双方の数値を同列に扱うことには注意が必要だ。
※編集部の考察：元記事がNeo4j公式ブログである以上、GraphRAGに有利な研究・調査が選択的に紹介されている可能性は否定できない。比較検討の際は独立した第三者による評価も参照することが望ましい。
どちらを選ぶか——判断の実践的な手順
記事では、アーキテクチャを変える前に現在の検索失敗がどの種類か確認することを勧めている。
- 意味的なマッチが外れている → チャンキング・埋め込み・フィルタリングのチューニング問題
- 正しい事実は取れているが、それらの関係が答えに反映されない → チューニングでは解決しない
判断には本番トラフィックを模したテストセットを作り、以下の指標を計測することを推奨している：
- Context Precision（取得結果のうち関連していた割合）
- Context Recall（必要な証拠のうち取得できた割合）
- 回答の忠実度、レイテンシ、トークンコスト
GraphRAGでこれらの数値が改善しなければ、グラフのモデリングと維持コストに見合わない。改善するなら、それが導入の根拠になる。
両者の比較まとめ
| Vector RAG | GraphRAG | |
|---|---|---|
| 検索方式 | 埋め込みチャンクの類似度検索 | グラフのリレーショントラバーサル（ベクトル検索と組み合わせることが多い） |
| 多段推論 | 単独では不可 | 複数ホップのリレーションを直接辿れる |
| 説明可能性 | 結果は確認できるが関係パスはない | 回答の根拠となるリレーションパスを返す |
| 適した用途 | 単一事実の検索、意味的マッチング | 多段推論、複数ソースからのコンテキスト収集 |
なお、GraphRAGはVector RAGを置き換えるものではない。Neo4jは同一データベース上でベクトル検索とグラフトラバーサルの両方をサポートしており、必要な場面でGraphRAGを追加するという設計が可能だ。
詳細はVector RAG vs. GraphRAG: Which retrieval do you need?を参照していただきたい。
