10月16日、KDNuggetsのライターVinod Chuganiが「Agentic RAG vs. Naive RAG: When Your Retrieval System Should Think for Itself」と題した記事を公開した。この記事では、RAGシステムの二つのアーキテクチャ（Naive RAGとAgentic RAG）の違いと、実装判断のための具体的な基準について詳しく解説されている。
「一発勝負」か「反復調査」か——RAGの本質的な違い
LLMのハルシネーション対策として定着したRAG（Retrieval-Augmented Generation）だが、複雑なクエリに対して標準的なRAGパイプラインが破綻するケースが増えている。記事の核心は、Naive RAGの「線形性」こそが限界の根本原因という指摘だ。
Naive RAGのフローは Retrieve → Read → Generate の三段階で固定されている。ユーザーのクエリをベクトル埋め込みに変換し、ベクトルDBで類似検索を実行、上位k件のチャンクをLLMのコンテキストに渡して回答を生成する。シンプルで低コスト、デバッグも容易だ。
問題はこのパイプラインが「一発勝負」である点だ。最初の検索が失敗しても、システムはそれに気づく術を持たない。
Naive RAGが詰まる典型的なシナリオ
記事が挙げる最もわかりやすい例がマルチホップ推論の失敗だ。
「WhatsAppを買収した企業がEUで従っている規制ポリシーは何か？」
このクエリに正答するには最低2ステップ必要だ：
- MetaがWhatsAppを買収したという事実を取得する
- MetaのEU規制方針を取得する
「WhatsApp EU規制ポリシー」という単一ベクトル検索では、この2つの情報が別ドキュメントに分散している場合、正しくブリッジできない。Naive RAGにはクエリを分解して逐次検索する機能がないためだ。
Agentic RAGの4つのメカニズム
Agentic RAGはLLMを「コンテキストの受け取り手」ではなく「検索プロセス全体のオーケストレーター」として位置づける。フローは Plan → Execute → Evaluate → Repeat のループになる。
この差を生むのは以下の4つの仕組みだ。記事では4つが均等に紹介されており、それぞれが異なるユースケースで効いてくる。
① Self-Reflection and Critique
検索結果をそのままGenerationステップに渡さず、LLM自身が「この検索結果はクエリに答えているか？」を評価する。不十分・矛盾・的外れと判断すれば、クエリを書き直して再検索する。
このループはコストと遅延の膨張を防ぐため、反復回数の上限が設定される。「悪いコンテキストをサイレントに渡す」というNaive RAGの構造的な欠陥を、リアルタイムで自己修正できる点がAgentic RAGの中核的な特徴だ。
② Query Decomposition
複雑なクエリを独立して回答可能なサブクエリに分解してから検索を実行する。先述のWhatsAppの例では、まず「WhatsAppを買収した企業はどこか」を検索してMetaという中間回答を得て、その結果を使って「MetaのEU規制方針」を検索する。各答えが次の検索を構築する連鎖だ。
③ Query Routing
すべてのクエリを同一の検索機構に通すのではなく、クエリの性質に応じて最適なデータソースを選択する。財務分析ならSQL DB、ポリシー調査なら非構造化ドキュメントのセマンティック検索、最新情報ならWeb検索API——といった振り分けをLLMが判断する。
④ Tool Use and Function Calling
テキストDBへのクエリに留まらず、計算機・Web検索API・SQLエグゼキューター・社内APIなど外部ツールを推論の途中で呼び出せる。AnthropicのFunction CallingやOpenAIのFunction Callingがその実装基盤となる。
どちらを選ぶか——コストと能力のトレードオフ
記事は「どちらが優れているか」という問いを立てず、ユースケースの性質によって適切なアーキテクチャが決まるという立場をとっている。以下がその判断基準だ。
Naive RAGを選ぶべき場合：
- クエリが明確でシングルホップ
- レスポンス速度が最優先（コンシューマー向けチャットボット、社内FAQなど）
- ナレッジベースが整理されており、単一のセマンティック検索で正しい情報が引ける
- スケール時にLLMの複数呼び出しコストが許容できない
Agentic RAGを選ぶべき場合：
- 複数ドキュメントや異種データソースをまたいだ推論が必要
- 速度より精度が重要（財務分析、法律調査、医療文献レビュー）
- 設計時に想定できない複雑・オープンエンドな質問が来る
- 外部ツール・API・ライブデータとの連携が必要
- 誤答がビジネス上・評判上の重大なリスクになる
なお記事では、シンプルな大量クエリはNaive RAGで捌き、複雑・高リスクなクエリのみAgentic RAGループに回すハイブリッドアプローチも現実的な選択肢として挙げられている。タイトルにある「境界線」とはすなわち、この判断軸——クエリの複雑さ・精度要件・コスト許容度——を指している。
学習リソース
実装に進む場合の出発点として、記事は以下を挙げている。それぞれ異なる切り口でAgentic RAGに入門できる。
- LangChain / LlamaIndex の公式ドキュメント：クエリルーティング・分解・Self-Reflectionの実装例が充実しており、コードベースで各メカニズムの動作を確認できる
- Gao et al. (2023) "RAG Survey"：Naive/Advanced/Modularの各アーキテクチャを実証比較した学術論文。理論的な位置づけを整理したい場合の参照先として挙げられている
- DeepLearning.AI の短期コース "Building and Evaluating Advanced RAG"：評価指標の設計まで含めたコードベースの実践入門。Naive RAGから一歩進んだ実装に取り組む際の足がかりになる
詳細はAgentic RAG vs. Naive RAG: When Your Retrieval System Should Think for Itselfを参照していただきたい。
