6月25日、Jim Allen Wallaceが「Knowledge graph RAG: structured retrieval for AI agents」と題した記事を公開した。ベクトル検索では解決できない複雑な多段推論（マルチホップ）に対して、ナレッジグラフRAGがどのようにAIエージェントの検索精度を向上させるかを詳しく論じた内容だ。
ベクトル検索が答えられない問いがある
まず具体的なシナリオから入ろう。サポートエージェントにこう聞いたとする。「前のチケットで報告したスロー同期のバグは、あなたが勧めたバージョンで修正されていますか？」
この質問に答えるには、3つの文書をつなぐ必要がある。過去のサポートチケット、新しいリリースノート、そして修正に紐づくエンジニアリングイシューだ。ベクトル検索は意味的に近いチャンクを10件返すかもしれないが、「reported in」「fixed by」という関係性のリンクを辿ることができないため、3つの文書を1つの回答に束ねられない。
これがナレッジグラフRAG（GraphRAG）が解決しようとする問題だ。
ベクトルRAGとナレッジグラフRAGの違い
ベクトルRAGは、文書をチャンクに分割してベクトル化し、類似度の高い上位k件を返す。意味的な近さは捉えられるが、「Jane Smith」と「J. Smith」が同一人物であること、2025年のポリシーが2023年版を上書きしていること——こうした構造的な関係は表現できない。
ナレッジグラフRAGは、LLMを使って非構造化テキストからエンティティと関係性を抽出し、ノード（エンティティ）とエッジ（関係）からなるグラフを構築する。検索の単位はチャンクの埋め込みではなく、ノードとエッジの集合だ。
典型的な処理フローは4段階で構成される：
- データ抽出：LLMがソースデータからエンティティ・関係性・メタデータを抽出する
- クエリエンティティのリンク：クエリから主要エンティティを抽出し、ベクトル検索で対応ノードを特定する
- グラフトラバーサル：Cypherなどのグラフクエリ言語を生成し、関係を辿る
- 回答生成：取得したグラフのコンテキストでプロンプトを補強する
マルチホップ検索：エージェントが本当に必要としているもの
記事が最も力を入れているのが、このマルチホップ検索の議論だ。
マルチホップ検索とは、複数ステップを経て回答を組み立てる検索手法を指す。前述のサポート質問なら「バグをチケットで特定 → そのバグを修正したリリースを特定」という2ホップの連鎖になる。
標準的なRAGはクエリに対して1回だけ検索して止まる。つまり、橋渡しとなる事実（bridging fact）を辿る前に処理が終わってしまう。
グラフトラバーサルはこの問題を解消する。ナレッジグラフはファクトを「2つのエンティティ＋関係」というトリプル構造で保持するため、バグノードから「fixed by」エッジを辿ってリリースノードへ、という連鎖的な検索が可能になる。
精度への効果も定量的に示されている。MuSiQue、2WikiMultiHopQA、HotpotQAといったマルチホップQAベンチマーク（いずれも、複数文書をまたいだ多段推論を要する質問に正確に答えられるかを測定するデータセット）において、グラフベースの手法は密ベクトル検索のベースラインと比較して36.25ポイント高い精度を報告している。また、各ホップに必要な証拠だけを取得することで、無関係なテキストがプロンプトに混入することを防ぎ、ハルシネーションの抑制にも寄与するとされている。
グラフが古ければ意味がない：鮮度問題
マルチホップ検索の精度がどれだけ高くても、グラフのデータが古ければ答えは間違える。記事はこの「鮮度問題」を重要な論点として取り上げている。
ベクトル埋め込みは時系列を考慮しない。廃止済みのAPIリファレンスと最新のドキュメントが同じスコアで返ってくる可能性がある。バッチインデックスでは夜間処理が1回なら数時間のラグが生じ、文書量が増えるほどそのウィンドウは広がる。
実際の障害パターンとして、以下が挙げられている：
- 関係の腐敗：退職した社員とアカウントのリンクが6ヶ月後もグラフに残る
- エンティティの劣化：グラフ構築時は正しかった事実がその後変化している
- バージョン盲点：バージョン依存の質問に対して標準GraphRAGは64%の精度しか達成できず、素朴なRAGとほぼ変わらない
解決策として記事が示すのは、Change Data Capture（CDC）を用いたニアリアルタイムの増分更新だ。CDCとは、データベースの変更ログを監視し、差分が生じた行・レコードだけを即座に下流システムへ伝播させる手法で、定期的な全件再構築と比べてグラフの鮮度を大幅に高められる。定期的な全件再構築ではなく、データが変化した際に即座にグラフを更新するアーキテクチャを推奨している。
エージェントのコンテキストパスにおける構造化検索の位置づけ
記事では、LLMを「CPU」、コンテキストウィンドウを「RAM」と例えた上で、エージェントのメモリ管理を3層に整理している：
| 層 | 内容 | 保持場所 |
|---|---|---|
| 短期ワーキングメモリ | 現在の会話・タスク | コンテキストウィンドウ（セッション終了で消滅） |
| 長期メモリ | エピソード履歴・意味的事実 | ベクトルストア＋構造化ストア |
| エンティティ関係・マルチホップ | ドメインのグラフモデル | ナレッジグラフ＋低レイテンシストア |
コンテキストを詰め込みすぎる（context rotと記事が呼ぶ状態）と、モデルはウィンドウの中央に埋もれた情報を見落とすようになる。各層に適切な情報を分担させることで、エージェントは次のステップに必要なものだけを受け取れる。
セキュリティ面では、text-to-SQLや大量のOpenAPIエンドポイントをMCPに変換してエージェントに直接叩かせるアプローチはスケールしないと指摘している。GitHubの公式MCPサーバーだけで90以上のMCPツール、4万6000トークン超を消費するという具体例が示されている。
Redis Irisによる実装
記事後半はRedisの自社製品「Redis Iris」の紹介に移る。上記のアーキテクチャ上の課題——低レイテンシ、グラフ鮮度、コンテキスト肥大化——をどう解消するかという文脈で示された数値であり、エンジニアとして設計の参考になる：
- 20ノードのAWSクラスターでサブミリ秒レイテンシを達成
- 10億ベクトルのベンチマークで、50並列クエリ下・上位100件取得において90%精度・約200msの中央値レイテンシ（往復時間含む）
- 同じリコール水準で他のベクトルデータベースと比較して最大3.4倍のスループット、4.7倍の低レイテンシを報告
- セマンティックキャッシュ（Redis LangCache）でLLM推論コストを最大73%削減（コード変更なし）
また、Redis Context Retriever（プレビュー）はPydanticでセマンティックモデルを定義するとMCPツールを自動生成する機能だ。コンテキスト肥大化を避けながら必要なツールだけを動的に提供する設計思想で、あるウェルスアドバイザー向け実装では25のMCPツールを生成し、コンテキスト肥大化を回避できたとされている。これらの数値はRedis Iris固有の実装環境下での結果であり、GraphRAG全般に適用できる数値とは性質が異なる点には留意が必要だ。
詳細はKnowledge graph RAG: structured retrieval for AI agentsを参照していただきたい。
