想像してみてください。ChatGPTに質問をすると、それは自分の"脳"から答えを探すだけでなく、外部の知識ベースも探してから返答します。これがRAG（検索拡張生成）システムが行うことです。しかし、問題があります。システムを固定されたフローに従わせるのか、それともAI自身が"プロジェクトマネージャー"となり、各ステップを自主的に決定するのか？
この論文はこの問題に答えようとしています。研究チームはRAGシステムを2つの阵营に分けました：
- Enhanced RAG（拡張型RAG）：精心に設計された流水線のように、専門の"クエリ書き換え工"、"ドキュメント順序付け工"などがあり、各々が職責を果たします。
- Agentic RAG（エージェントRAG）：大規模言語モデルを総指揮官とし、自ら検索が必要かどうか、クエリを書き換えるかどうかを決定し、完全に自主的に制御します。
現在、業界ではこの2つの方案にそれぞれの支持者がありますが、どちらがより使いやすいのでしょうか？どのようなシナリオでどちらを選ぶべきでしょうか？コストと性能のバランスはどう取るのでしょうか？これらの問題には明確な答えがありません。そこで、研究チームは「華山論剣」のような全面的な比較を行うことを決めました。
彼らの核心的な貢献は2点あります。第一に、4つの重要な维度から2つのシステムの実際のパフォーマンスを評価したことです。第二に、コストと計算時間の違いを詳細に分析し、実際の応用に非常に実用的な参考を提供したことです。
関連研究：RAG技術の進化の流れ
RAGという概念は、Lewisらによって2020年に最初に提案されました。最初の設計は非常にシンプルでした。クエリを受け取る→関連ドキュメントを検索する→ドキュメントとクエリをモデルに一緒に供給する→答えを生成する。しかし、この"素のRAG"（論文ではNaïve RAGと呼ばれる）には多くの問題がありました。時には検索が必要ないにもかかわらず検索を実行し、リソースを浪費します。時には検索されたドキュメントの品質が低く、関連性のない内容ばかりです。ユーザーの質問と知識ベースのドキュメントの表現方法が大きく異なり、マッチング効果が悪いです。
そこでEnhanced RAGが登場しました。研究者たちはこの流水線に様々な"拡張モジュール"を追加し始めました：
- クエリ書き換えモジュール（例えばHyDE技術。問題を仮想の答えの段落に書き換えてからマッチングする）
- セマンティックルーティングモジュール（この問題が本当に検索が必要かどうかを判断する）
- 再順序付けモジュール（検索されたドキュメントを関連性に基づいて再順序付けする）
一方、GPT-4のようなモデルの推論能力が爆発的に向上するにつれて、Agentic RAGが頭をもたげ始めました。この方案の核心的な思想は、モデルがこれほど賢くなったのなら、なぜ自らワークフローを決定させないのか？というものです。LangGraph、LlamaIndex、CrewAIなど、様々なAgentフレームワークが雨後の筍のように出現しました。
しかし興味深いことに、この2つの技術ルートは両方とも人気ですが、学術界ではまだ体系的な比較実験が行われていません。NehaとBhatiは2025年に理論的な区別を提案しましたが、実際にテストは行っていません。この論文はこの空白を埋めるために書かれました。
核心方法：4つの维度での「拳拳到肉」の比較
研究チームは4つの重要な维度を選んでこの2つのシステムを比較しました。各维度はNaïve RAGの一つの痛点に対応しています：
1. ユーザー意図図処理：検索すべきかどうかの判断力
問題の状況：ユーザーが「今日の天気はどうですか？」と尋ねた場合、システムは知識ベースからドキュメントを探すべきではありません。しかし、「会社のQ3売上報告書の重要なデータは何ですか？」と尋ねた場合は、検索が必要です。この判断能力は重要です。
Enhancedの方法：semantic-routerフレームワークを使用し、事前に「有効な質問」と「無効な質問」の例を準備します。新しい質問が来ると、これらの例と類似度を比較して、どちらのカテゴリに属するかを判断します。
Agenticの方法：GPT-4o自身に決定させ、「RAGツールを呼び出す」か「直接回答する」かを選択させます。
テスト方法：FIQA（金融質問）、FEVER（事実検証）、CQADupStack（フォーラム質問）の3つのデータセットで、各500の有効なクエリと500の無効なクエリを準備し、どちらが正確に判断できるかを確認します。
2. クエリ書き換え：問題とドキュメントを「同じ言語で話させる」
問題の状況：ユーザーが「フリーランスの税務影響は何ですか？」と尋ねた場合、知識ベースのドキュメントには「フリーランス者は以下の税種を納付する必要があります…」と書かれているかもしれません。表現方法が異なるため、直接マッチングすると効果が悪いです。
Enhancedの方法：HyDE書き換えを強制実行します。問題を仮想の答えの段落（例：「フリーランス者は特定の税種を納付する必要があります…」）に書き換え、このテキストを知識ベースとマッチングします。
Agenticの方法：プロンプト内でAgentがクエリを書き換えることができると伝えますが、Agent自身が書き換えるかどうか、どのように書き換えるかを決定します。
評価指標：NDCG@10（正規化減衰累積利得）を使用して検索品質を測定します。これは情報検索分野のゴールドスタンダードです。
その中で：
はi番目のドキュメントの関連性タグです。
3. ドキュメントリスト最適化：検索後もさらに精選できる
問題の状況：最初の検索で20個のドキュメントを取得できるかもしれませんが、その中にはあまり関連性のないものもあるため、さらに絞り込む必要があります。
Enhancedの方法：ELECTRAベースの再順序付けモデルを使用し、20個のドキュメントを再順序付けして、最も関連性の高い10個を選出します。
Agenticの方法：Agentは検索ツールを複数回呼び出すことができ、毎回クエリ戦略を調整して、自ら反復的に最適化できます。
4. 底層モデルの影響：「脳」を変えると性能がどれだけ変わるか
実験設計：Qwen3シリーズの4つのモデル（0.6B、4B、8B、32Bパラメータ）をそれぞれテストし、モデルサイズが2つのシステムに与える影響が一貫しているかどうかを確認します。
評価方法：Selene-70Bを「AI審判」として使用し、生成された答えの品質を評価します。このモデルはLLM-as-a-Judgeアリーナで高い順位にあり、金融質問タスクでは人間の評価と高度に一致します。
実験効果：どちらが強いかは具体的なシナリオによる
ユーザー意図処理：Enhancedは複雑なシナリオでより安定
結果は非常に興味深いものでした。FIQA（金融）やCQADupStack（英語文法）のような領域の境界が明確なシナリオでは、Agentic RAGがより良いパフォーマンスを示し、F1スコアはそれぞれ98.8と99.8に達しました。しかし、FEVER（事実検証）のようなオープンドメインタスクでは、Agenticの再現率は49.3%に過ぎず、Enhancedより35ポイントも低いです！
理由は明らかです。タスクの境界が曖昧な場合、Agentはしばしば"過剰に熱心"になり、検索すべきでないものまで検します。一方、Enhancedの例ベースのルーティングシステムは、このような状況ではむしろより安定しています。
クエリ書き換え：Agentの柔軟性が勝利
すべてのデータセットで、Agentic RAGの検索品質はEnhanced RAGより平均的に2.8 NDCG@10ポイント高かったです。特にNQ（自然質問）データセットでは、Agenticは51.7に達し、Enhancedの43.9より約8ポイントも高いです。
これは何を意味するのでしょうか？Agentは具体的な問題に応じて柔軟に書き換え戦略を決定できるのに対し、Enhancedは「一刀両断」の強制書き換えであり、時には蛇足となることもあります。
ドキュメント最適化：Enhancedの再順序付けが圧勝
この結果は予想外でした。Enhanced RAGは再順序付けモジュールを通じて、FIQAでは45.0から51.0に（6ポイント向上）、CQADupStackでは46.0から48.0に向上しました。
ではAgentic RAGはどうでしょうか？検索ツールを複数回呼び出すことを許可しても、パフォーマンスはベースラインより悪くなりました（FIQAは43.4に低下、CQADupStackは44.4に低下）。Agentは自主的に決定できますが、「ドキュメントを厳選する」という点では、専門的に訓練された再順序付けモデルほど信頼できないようです。
モデルサイズの影響：両者のパフォーマンスが収束
EnhancedでもAgenticでも、底層モデルが0.6Bから32Bに大きくなるにつれて、パフォーマンスは着実に向上し、その向上曲線はほぼ一致しています。これはモデル能力の影響がシステム全体にまたがっていることを意味します。どちらのアーキテクチャを選ぶかと、どのくらいの大きさのモデルを選ぶかは、独立して考えられます。
コスト分析：Agenticの「贅沢税」は無視できない
この部分のデータは、実際の応用者にとって最も関心が高いかもしれません：
Token消費比較（FIQAデータセット）：
- AgenticはEnhancedより2.7倍の入力tokenを消費
- 出力tokenは1.7倍多い
- 全体の所要時間は1.5倍増加
CQADupStackデータセットでは差が更大：
- 入力tokenは3.9倍多い
- 出力tokenは2.0倍多い
実際の金額に換算すると、OpenAIのAPIを使用している場合、Agentic RAGのコストはEnhancedの3-4倍になる可能性があります。大規模な応用では、これは小さな金額ではありません。
なぜこんなことになるのでしょうか？Agenticは常に「思考」する必要があるからです。各ステップでツールを呼び出すかどうか、どのように呼び出すかを推論しなければならず、これらの中間ステップはすべてtokenを消費します。一方、Enhancedは固定されたフローであり、すべきことを行い、追加で「思考」する必要はありません。
分布図から可以看出、Agenticのtoken消費と所要時間には明らかな「ロングテール」現象があります。あるクエリは特に手間がかかり、Agentは何度もツールを呼び出すことがあります。
論文まとめ：銀の弾丸はなく、トレードオフだけがある
この論文の最大の価値は、「新しい技術は必ずしもより良い」という神話を破ったことです。
主な発見をまとめると：
狭い領域のタスクにはAgenticを、オープンドメインのタスクにはEnhancedを選択：金融や文法のような境界が明確なシナリオでは、Agentの理解力が優位性を発揮します。しかし、FEVERのような「何でも質問できる」シナリオでは、ルールベースのルーティングの方が信頼できます。
クエリ書き換えの段階ではAgenticが優位：柔軟な書き換え戦略は確かに検索品質を向上させ、平均的に2.8 NDCGポイント向上します。この優位性は実際のものです。
ドキュメントの厳選には再順序付けが必須：Agentの複数回数回検索の戦略は、Enhancedの専用再順序付けモデルほど使い勝手が良くありません。これはAgenticアーキテクチャの最大の短所かもしれません。論文はこう提案しています。なぜAgenticにも再順序付けツールを追加しないのか？
コスト差は無視できない：3-4倍のコスト増加は多くの応用では耐え難いものです。性能に極限的な要求がない限り、最適化されたEnhanced RAGの方が安価かもしれません。
モデルサイズの影響は両者で一致：これは、まずアーキテクチャを選択し、予算に応じてモデルを選択できることを意味します。2つの決定は比較的独立しています。
実用的なアドバイス：
企業開発者で、小規模で予算が限られたシナリオでは、Enhanced RAGの方が賢明な選択かもしれません。性能は十分で、コストは管理可能です。
極限的なユーザー体験を追求している場合、または応用シナリオが特に複雑で変化しやすい場合は、Agentic RAGの柔軟性に価値があるかもしれません。
しかし、最も理想的な方案は「ハイブリッドアーキテクチャ」かもしれません。Enhancedの再順序付けモジュールとAgenticの柔軟な決定を組み合わせ、両者の長所を取り入れます。研究チームも認めていますが、彼らのAgentic実装では1つのツール（RAG）しか使用していません。もしAgentにより豊富なツールボックスを配置した場合、結果は全く異なるかもしれません。
この対決には絶対的な勝者はいませんが、私たちに明確な参考枠を提供しました。RAGシステムを選ぶには、シナジオ、予算、ニーズを見極め、盲目的に新しいものを追うより、理性的にトレードオフを考えることです。