これは何の論文か
この論文の問いはかなり実務寄りで、「エージェント型 RAG は本当に採用する価値があるのか？」である。RAG は本番システムの中心部品になり、固定パイプラインに ルーター、rewriter、再順位付け器を足す Enhanced RAGと、LLM が検索や再検索を判断するエージェント型 RAG のどちらを使うべきかが現場の設計判断になっている。
著者らは、RAG の弱点を4つに分けて比較する。対象外質問にも検索してしまうこと、質問と文書の表現がずれて検索が弱くなること、検索結果にノイズが混ざること、基盤 LLM の強さやコストに左右されることである。それぞれに対して、Enhanced は専用モジュール、エージェント型は LLM の判断で対処する。
結果はきれいな二択ではない。エージェント型 RAGは、明確なドメインでの意図判定と、ケースごとに変えられるクエリ書き換えで強い。一方で、検索後の文書リスト改善では、明示的な再順位付け器を使う Enhanced RAG のほうが良い。エージェント型が再検索しても、同じ文書を再び拾いやすく、方向転換が十分に起きなかった。
コストも重要で、エージェント型 RAG は平均で入力トークン 3.3 倍、出力トークン 1.9 倍、時間 1.5 倍を要する。結論としては、エージェント型 RAG は「賢い上位互換」ではなく「迷う必要がある検索」に向く方式であり、動的判断が効く場所だけに使い、再順位付けなど既知の弱点には Enhanced の明示的部品を残すのがよさそうである。
ただし実務では、論文の実験ほど綺麗に問題を切り分けられないことが多い。ユーザーが文書側の語彙に合わせて質問できるとは限らず、文書自体も整理されているとは限らない。検索対象の文書、過去ログ、運用メモリ、証拠の残し方まで含めて自動化できる現在では、検索器単体よりもエージェント型ワークフロー全体として見るほうが自然である。
Enhanced RAG とエージェント型 RAGを、複数データセット、複数評価軸、コストと遅延まで含めて比較する論文である。
Enhanced RAGは、ルーター、クエリ書き換え、検索器、再順位付け器、generator のような固定モジュール列として扱われる。エージェント型 RAGは、LLM が検索するか、クエリを書き換えるか、再検索するか、回答するかを選ぶループとして扱われる。
エージェント型側は単一 RAG ツールに限定されている。これは外部 API や複数ツールによる追加能力を混ぜず、Enhanced RAG と機能範囲を揃えるためである。
何が問題だったのか
RAG の議論では、単純な RAG よりエージェント型 RAG の方が賢い、という見方になりやすい。しかし、エージェント型にすれば常に良くなるわけではない。LLM に判断を増やすほど、入力トークン、出力トークン、処理時間、失敗の揺れも増える。
実務で困るのは、「検索が弱いから全部エージェント化しよう」と決めても、どこに効いて、どこでは過剰なのかが分からないことだ。検索するかどうかの判定、質問の書き換え、候補文書の並べ替え、回答生成では、それぞれ失敗の性質が違う。
この論文が扱う問題は、エージェント型 RAG を丸ごと採用すべきかではなく、どの失敗モードに対して、どの段階だけに動的な LLM 判断を入れるべきかである。性能だけでなく、コストと遅延も含めて比べないと、実運用の判断材料にならない。
提案手法の中身
意図判定では、Enhanced は意味的-ルーター と埋め込みによる valid / invalid 分類を使う。エージェント型は、LLM が検索を使うかどうかを自分で決める。
クエリ書き換えでは、Enhancedは HyDE 型の固定書き換えを行う。エージェント型は、検索クエリをどう書くかを状況に応じて決める。
文書リスト改善では、Enhancedは ELECTRA 系再順位付け器で上位20件を並べ替える。エージェント型は必要ならクエリを書き換えて再検索する。
基盤 LLM の比較では、Qwen3-0.6B、4B、8B、32B を使い、モデルの強さが Enhanced とエージェント型にどう効くかを見る。
どうやって確かめたのか
評価は、エージェント型 RAG がどの弱点には効き、どこでは Enhanced RAG の明示的な部品に負けるかを見るために組まれている。FIQA、NQ、FEVER、CQADupStack-English を使い、質問応答と情報検索・抽出の両方で見る。
比較対象は、単純な RAG、ルーターやクエリ書き換えや再順位付け器を持つ Enhanced RAG、LLM が動的に判断するエージェント型 RAG である。評価単位は、意図判定、クエリ書き換え、文書リスト改善、回答生成に分けられている。
測る指標は、F1、NDCG@10、入力トークン、出力トークン、処理時間である。性能だけでなく、どの段階をエージェント化すると費用と遅延が増えるかも確認する。
結果はどうだったのか
意図判定は、ドメインが明確な時だけエージェント型が強い
意図判定では、エージェント型 RAG は FIQA と CQADupStack-English で Enhanced RAG を少し上回った。FIQA では F1 が 98.8、CQADupStack-English では F1 が 99.8 で、検索すべきかどうかを LLM がうまく判断できている。
一方で、FEVER ではエージェント型の F1 が 64.6 まで落ち、Enhanced の 87.9 を大きく下回った。原因は、検索しなくてよい質問にも検索を使いがちだったことだ。金融や英語文法のように対象領域がはっきりしている時はエージェント型の判断が効くが、事実検証のように領域境界が広い時は、固定ルーターのほうが安定した。
クエリ書き換えは、エージェント型が平均で上回った
クエリ書き換えでは、エージェント型 RAG が平均 NDCG@10 で 55.6、Enhanced RAG が 52.8 だった。平均ではエージェント型が +2.8 ポイント高い。
特に NQ では、Enhanced が 43.9、エージェント型が 51.7 で、+7.8 ポイントの差が出ている。固定の HyDE 型書き換えより、質問ごとに書き換えるか、どう書き換えるかを変えられることが効いたと読める。
文書リスト改善は、Enhanced の再順位付け器が強い
文書リスト改善では、エージェント型 RAG は弱かった。FIQA と CQADupStack-English の平均 NDCG@10 は、Naive が 45.5、Enhanced の再順位付けなしが 48.0、Enhanced の再順位付けありが 49.5、エージェント型が 43.9 だった。
エージェント型は再検索できる設計だが、実際に再検索したのは約10%にとどまった。さらに、再検索した場合でも平均 53% の文書が前回と同じだった。つまり、いったん選んだ検索方向を LLM が十分に見直せず、検索後の候補選別では明示的な再順位付け器のほうが強かった。
モデルを大きくしても、エージェント型だけが特別に伸びるわけではない
Qwen3-0.6B、4B、8B、32B で基盤 LLM を変えると、Enhanced とエージェント型の両方で性能は上がる。ただし、エージェント型だけがモデルサイズの恩恵を特別に受ける、という結果ではない。
この結果は重要で、強い LLM にすればエージェント型 RAG の弱点が自然に消える、とは言いにくい。再順位付けのように専用部品が効く場所では、モデルを大きくするだけでは構造的な弱点を埋めきれない。
コストは明確にエージェント型のほうが重い
コスト分析では、エージェント型 RAG は Enhanced RAG と比べて、平均で入力トークン 3.3 倍、出力トークン 1.9 倍、処理時間 1.5 倍を要した。
Enhanced RAG でも LLM 呼び出しは重いが、検索や再順位付けそのものの時間は相対的に小さい。エージェント型では、判断や反復のために追加の推論が入るため、性能が少し上がる場面でもコストと遅延を一緒に見ないと割に合うか判断できない。
まとめると、エージェント型 RAG は「常に強い上位互換」ではない。検索要否の判断やクエリ書き換えのように、その場で判断を変える必要がある部分では強い。一方、検索後の候補選別のように失敗パターンがはっきりしている部分では、Enhanced RAG の明示的な部品を残したほうがよい。
限界・注意点
- 比較されているエージェント型 RAG は単一ツール設定であり、ブラウザ、コード実行、複数検索ツールを含むエージェント型調査システムとは違う。
- FEVER のようにドメイン境界が広いタスクでは、意図判定の定義が難しく、エージェント型の強みが出にくい。
- NQと FEVER の文書リスト改善は知識ベースが大きく、エージェント型 RAG では7日超かかる見込みとして除外されている。
- Enhanced 側の実装は意味的-ルーター、HyDE、ELECTRA 再順位付け器に依存する。別の部品を使うと差は変わる可能性がある。
- 実務では、ユーザーの言葉、文書の書き方、社内メモリ、過去ログ、更新状態が揺れる。ここが揺れないなら問題はかなり簡単であり、揺れるからこそエージェント型な判断余地が出てくる。
- 検索だけに焦点を当てると視野が狭い。検索対象の文書をどう整えるか、検索時に参照するメモリをどう選ぶか、足りない情報をどう追加収集するかまで含めて見る必要がある。
- 本番制約として最も重いのはコストとレイテンシーである。ただし、コストは1リクエストのトークン代だけではなく、チャンク設計、埋め込み、検索インデックスの構築と更新、再順位付け器、検索品質評価、文書更新時の再処理まで含めて見る必要がある。
- Enhanced が常に安いとは限らない。文書集合が安定しているなら Enhanced は強いが、対象文書やメモリが頻繁に変わる、探索対象が毎回違う、低頻度で深い調査をする、といった状況ではエージェント型ワークフローのほうが総運用コストに見合う場合もある。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、検索は「関連しそうな情報を取る」だけでは足りない。まず、質問が本当に検索を必要としているのか、どの資料群を探すべきなのか、検索語をどう変えるべきなのかを判断する必要がある。
この論文を使うなら、検索を検索器単体ではなく、クエリ書き換え、再順位付け、ツール出力、文脈予算、引用、停止判断を含むワークフローとして設計する。曖昧な問いや表現ずれが大きい問いにはエージェント型の判断が効く一方、検索後の候補選別のように専用部品が強い場所では、明示的な再順位付けを残したほうがよい。
注意点として、実運用では、どの問いを単純検索で済ませ、どの問いだけ深掘りに回すかを分ける設計が必要になる。エージェント型探索は便利だが、常時使うとトークン、時間、失敗の揺れが増える。
Q&A
この論文の結論を一言で言うと？
エージェント型 RAG は万能ではない。動的判断が必要な場面では強いが、既知の弱点を直すなら Enhanced RAG の明示的モジュールが安く強い場合がある。
エージェント型 RAG が向いているのはどこ？
明確なドメインで検索すべきかを判断する場面と、質問ごとにクエリ書き換えを変えたい場面。FIQAや CQADupStack-English、NQ の結果がそれを示している。
Enhanced RAG が向いているのはどこ？
検索後の文書リスト改善のように、弱点が明確で専用部品が効く場所。論文では再順位付け器付き Enhanced がエージェント型の再検索より良い結果を出している。
エージェント型 RAG はなぜ高くなる？
LLM が判断や反復を行うため、追加の推論ステップとツール呼び出しが増えるから。平均で入力トークン 3.3 倍、出力トークン 1.9 倍、時間 1.5 倍と報告されている。
強い LLM にすればエージェント型が圧勝する？
この実験ではそうではない。Qwen3 のサイズを上げると両方式で似たように性能が上がり、エージェント型だけが特別に伸びる傾向は見えていない。
FEVER でエージェント型が落ちた理由は？
FEVER は事実検証タスクでドメイン境界が広く、何が知識ベース対象外かが曖昧になりやすい。エージェント型は検索しなくてよい場合にも検索を使いやすかった。
実務ではどう組み合わせるのがよさそう？
エージェント型を全段に使うより、意図判定やクエリ書き換えに使い、再順位付けなどは Enhanced の明示的部品を残すのが自然。コストが厳しいならエージェント型ループは必要時だけに絞る。
Naive、Enhanced、エージェント型はどう使い分ける？
まず簡単に動かす、文書が少ない、質問が単純なら Naive。検索結果のノイズや対象外質問など既知の弱点を直すなら Enhanced。検索方法自体を質問ごとに考え直す必要があるならエージェント型が向く。
エージェント型 RAG を一番わかりやすく言うと？
エージェント型 RAG は「賢い RAG」というより「迷える RAG」に向いている。迷う必要がある仕事では強いが、迷わなくていい仕事では高くつきやすい。
実務では論文よりエージェント型が強く見えることはある？
ある。実務ではユーザーの言葉も文書の書き方も揺れ、検索対象の文書や運用メモリも未整理なことが多い。検索だけでなく、文書整備、メモリ選択、追加収集、証拠管理まで含めるとエージェント型なワークフローの価値は広がる。
それでもエージェント型 RAG を常時使わない理由は？
主にオンライン推論のコストとレイテンシーが増えるから。ただし Enhanced 側にもインデックス構築・更新、埋め込み、再順位付け器、検索品質評価の運用コストが乗るため、総コストでは単純に Enhanced が安いとは限らない。
この論文の注意点は？
エージェント型 RAG は単一ツール設定で評価されているため、複数ツールやブラウザを使う深い調査エージェントにはそのまま一般化できない。Enhanced 側の部品選択にも結果は依存する。
関連する記事
- Self-RAG、CRAG、HyDE、Probing-RAG などを読むと、RAG の弱点をどの段階で補うかの地図が作りやすい。
- コーパスを直接歩く検索エージェント や grepだけで十分なのか と合わせると、検索器単体ではなく、エージェントがコーパスをどう扱えるかというハーネス側の論点に接続できる。
- 実務 RAG では、まず失敗ログを「対象外検索」「クエリ表現のずれ」「検索結果ノイズ」「生成器問題」に分けると、この論文の知見を設計判断に落としやすい。