今回の論文
今回取り上げるのは、Soyeong Jeong、Jinheon Baek、Sukmin Cho、Sung Ju Hwang、Jong C. Park による論文「Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity」です。2024年に arXiv で公開され、NAACL 2024 でも発表されています。公開元は arXiv、研究分野は RAG、オープンドメイン質問応答、検索戦略の最適化です。URL は https://arxiv.org/abs/2403.14403 です。
この論文を選んだ理由は、RAG を「検索するかしないか」の二択ではなく、質問の難しさに応じて検索の深さそのものを切り替える設計 として扱っているからです。RAG は多くのプロダクトで使われていますが、実務では「全部に重い検索をかけると遅い」「軽くすると難問に弱い」という悩みがよくあります。Adaptive-RAG はその中間をかなり実装しやすい形で示しています。
どんな技術か
Adaptive-RAG は、入力された質問を見て、その質問がどれくらい複雑かをまず分類し、その結果に応じて次の 3 通りの解き方を切り替える技術です。
- 検索なしで LLM だけで答える
- 1 回だけ検索して答える
- 検索と推論を複数回まわして答える
RAG では「検索を足せば精度が上がる」と考えがちですが、実際には簡単な質問まで毎回重い検索や多段推論を回すと、速度もコストも悪化します。逆に、難しい質問を単発検索だけで処理すると、複数文書をまたぐ推論が足りません。
Adaptive-RAG のポイントは、ここを固定パイプラインにせず、質問ごとに最適な処理深さを選ぶ ことです。言い換えると、「RAG を入れるかどうか」ではなく、「どこまで RAG をやるべきか」を前段で判断するアーキテクチャです。
課題
この技術が解決しようとしている課題は、現実の質問が同じ難しさではないのに、RAG システム側が同じ処理を全件に適用しがちなことです。
何が難しいのかというと、質問の種類によって必要な外部知識量も推論ステップ数も違うからです。たとえば「2024年のノーベル物理学賞受賞者は誰か」のような単純な事実確認は、1 回の検索か、場合によってはモデル内部知識だけでも答えられます。一方で「ある事件に関わった人物が所属していた組織の創設者は誰か」のような質問は、複数の文書をつないで読む必要があります。
既存の方法では、単発検索型の RAG は簡単な質問には十分でも、多段推論が必要な問題では弱くなりがちでした。逆に multi-hop 前提の手法は複雑な質問に強い反面、毎回 LLM と検索器を何度も呼ぶため、簡単な質問には過剰です。
なぜこの課題を解く必要があるのかというと、RAG は本番環境では検索品質だけでなく、レスポンス速度、API コスト、システム負荷に直結するからです。社内ナレッジ検索、FAQ ボット、業務支援エージェント、顧客向け検索 SaaS などでは、難問は確かに重要ですが、実際の問い合わせの多くは中程度か単純なものです。そこに毎回重いパイプラインを流すと、精度のわりに費用が膨らみます。
つまり課題の本質は、RAG の精度そのものだけではなく、質問の複雑さと処理コストを釣り合わせる制御層が不足していた ことにあります。
用語解説
- Single-hop QA
- 1つの文書や1回の検索結果から答えにたどり着きやすい質問応答のことです。Adaptive-RAG では、この種の質問に重い multi-hop 処理をかけないことが効率化の重要な前提になります。
- Multi-hop QA
- 複数文書の情報をつなぎ合わせて答える質問応答です。Adaptive-RAG が 3 段階の戦略を用意している理由は、この multi-hop 問題に単発検索だけでは足りないからです。
- クエリ複雑度分類器
- 入力質問を見て、検索なしでよいか、1回検索が必要か、反復検索が必要かを予測する小型モデルです。Adaptive-RAG の中心は RAG 本体よりも、この前段の振り分けにあります。
- 反復検索
- 最初の検索結果を読んで終わるのではなく、中間的な推論結果を手がかりに再検索しながら答えを組み立てる方式です。複雑な質問には有効ですが、計算コストが高いため Adaptive-RAG は必要な場合だけ使います。
- Silver Label
- 人手で付けた正解ラベルではなく、既存モデルの予測結果などから自動生成した学習ラベルです。この論文では「どの戦略で正しく答えられたか」を使って複雑度ラベルを作り、分類器の学習に使っています。
技術の仕組み
Adaptive-RAG は、検索器や LLM を新しく発明した論文ではありません。既存の 3 種類の QA 戦略を束ねて、その中から適切なものを選ぶ制御設計が本体です。
基本アイデア
著者らは QA の解き方を次の 3 段階に分けます。
- 検索なし:
LLM(q) - 単発検索:
Retriever(q)で文書を取得しLLM(q, d)で回答 - 多段検索: 検索結果や途中回答を使って再検索しながら答える
この 3 つを全部持っておき、質問ごとに A・B・C の 3 ラベルへ振り分けます。A は検索不要、B は 1 回検索、C は複数回検索が必要、という意味です。
重要なのは、Adaptive-RAG が「全部の質問に多段 RAG をかけるほうが安全」という発想を取っていないことです。現実には簡単な質問も大量に来るので、難しさに見合う処理だけを選ぶほうが、精度と効率の両方で得になるという設計です。
モデル構造
構造としては比較的シンプルです。大きく分けると 2 層あります。
実行器の層
下側には実際に答えを出す 3 種類の QA 実行器があります。
- LLM 単体で答える実行器
- 1 回検索してから答える実行器
- 検索と推論を反復する実行器
この部分は既存の RAG や multi-hop QA 手法をそのまま使えます。論文の価値は、ここを差し替え可能なモジュールとして扱っている点です。
分類器の層
上側には小型の言語モデルを使った複雑度分類器があります。この分類器が入力質問 q に対して A・B・C のどれかを出し、その結果で下側の実行器を選びます。
つまりパイプラインとしては、質問 -> 複雑度分類 -> 実行戦略選択 -> 回答生成 です。RAG の前に「どこまで検索すべきか」という意思決定を1段入れているのが、この論文の核心です。
学習方法
この論文で面白いのは、複雑度分類器の教師データを人手で作っていないことです。著者らは 2 つのやり方を組み合わせて自動ラベルを作っています。
1. 実際にどの戦略で解けたかを見る
まず各質問に対して、検索なし、単発検索、多段検索の 3 戦略を走らせます。そして、最も単純な方法で正しく答えられた戦略にラベルを付けます。たとえば検索なしで解けたなら A、検索なしでは無理だが単発検索で解けたなら B、そこでも足りず多段検索が必要なら C です。
この設計には意味があります。単に「複雑そうに見える」ではなく、その質問を解くのに本当に必要だった処理深さ をラベルとして使っているからです。
2. データセットの性質も補助的に使う
ただし、3 戦略とも失敗する質問だとラベルが決めにくくなります。そこで論文では、single-hop データセット由来の未ラベル質問には B、multi-hop データセット由来の未ラベル質問には C を補います。
これは厳密な真値ではありませんが、データセットが持つ構造的なバイアスを活かした補完です。著者自身も、ここは自動ラベルなのでノイズがありうると明示しています。
推論方法
推論時の流れはかなり実践的です。
- 質問を分類器に入れる
- A・B・C の予測ラベルを得る
- ラベルに応じて実行器を切り替える
- 選ばれた経路だけを走らせて回答する
ここで効いているのは、簡単な質問を早めに軽い経路へ逃がせることです。論文では、予測ラベルの内訳として A が 8.60%、B が 53.33%、C が 38.07% と報告されています。つまり半分以上は単発検索で処理でき、一定割合は検索なしでも十分です。全部を multi-hop 化しない理由が、実測でも裏づけられています。
データの扱い方
評価では single-hop と multi-hop の両方を混ぜて扱っています。single-hop には SQuAD、Natural Questions、TriviaQA、multi-hop には MuSiQue、HotpotQA、2WikiMultiHopQA を使っています。
この構成が重要なのは、Adaptive-RAG が単一ジャンル向けの最適化ではなく、難易度の異なる質問が混在する現実の問い合わせ環境 を前提にしているからです。
重要な工夫
この論文の工夫は大きく 3 つあります。
二値判断ではなく三値判断にした
既存の adaptive retrieval は「検索するかしないか」の二択に寄りがちでした。しかし Adaptive-RAG は、その中間に「1 回検索」を独立させています。これにより、軽い質問と重い質問の間にある多数の中程度クエリを扱いやすくしています。
分類器を小さくして制御コストを抑えた
前段で複雑な判定器を回すと、その時点で重くなります。Adaptive-RAG は小型 LM を使うことで、戦略選択のオーバーヘッドを本体より十分軽く保っています。
実行器を差し替え可能な構成にした
論文の実験では特定の QA モジュールを使っていますが、考え方としては任意の RAG スタックへ載せ替えやすいです。つまり Adaptive-RAG は「1つの固定モデル」ではなく、「RAG オーケストレーションのパターン」として見ると実務向きです。
実験と結果
論文では、Adaptive-RAG が本当に精度と効率のバランスを改善するのかを、複数の LLM と複数の QA データセットで検証しています。
何を検証したのか
主に見ているのは次の 3 点です。
- 単純戦略や常時 multi-hop 戦略より総合性能が高いか
- 適応的な二値検索戦略より細かい制御が効くか
- 分類器による振り分けが実際に計算コスト削減へ効くか
ここでのポイントは、精度だけでなく Time/Query や平均ステップ数も明示的に見ていることです。
どんなデータセットや評価指標を使ったのか
single-hop 側では SQuAD v1.1、Natural Questions、TriviaQA、multi-hop 側では MuSiQue、HotpotQA、2WikiMultiHopQA を使っています。モデルは FLAN-T5-XL 3B、FLAN-T5-XXL 11B、GPT-3.5 Turbo Instruct などです。
評価指標は EM、F1、Accuracy に加えて、平均ステップ数と相対時間です。つまり「正しく答えられたか」だけでなく、「何回検索や推論を回したか」「そのぶんどれだけ重かったか」まで追っています。
平均結果では multi-step より軽く、adaptive retrieval より強い
全データセット平均では、FLAN-T5-XL 3B において Adaptive-RAG は F1 46.94、Accuracy 42.10 でした。これは単発の Adaptive Retrieval の F1 32.24、Accuracy 26.73 を大きく上回っています。一方で、常時 multi-step は F1 48.85、Accuracy 43.70 とやや高いものの、時間は 8.81 に対して Adaptive-RAG は 3.60 でした。
つまり、ほぼ multi-step に近い精度を、かなり少ない処理コストで実現した ことになります。精度だけなら常時重い戦略が有利な場面もありますが、運用を考えると Adaptive-RAG のバランスがかなり良いです。
単純な質問では過剰処理を減らせる
single-hop データセットを見ると、たとえば FLAN-T5-XL で Natural Questions では Adaptive-RAG が単発検索と同じ F1 47.30 を出しつつ、平均ステップ数は 1.00 に収まっています。TriviaQA でも F1 60.70 と単発検索の 62.40 に近く、常時 multi-step のような 5 ステップ前後の重い処理を避けられています。
これは、簡単な質問まで多段検索に流さずに済んでいることを意味します。RAG 実装では「難問向けに強い構成を全件に適用して遅くなる」ことがよくあるので、この差は実務的です。
複雑な質問では二値適応より有利
multi-hop データセットでは差がよりはっきり出ます。たとえば FLAN-T5-XL で HotpotQA の F1 は、Adaptive Retrieval が 32.22 なのに対して Adaptive-RAG は 53.82 です。MuSiQue でも 15.80 に対して 31.80、2WikiMultiHopQA でも 39.44 に対して 49.75 まで伸びています。
この結果から言えるのは、検索の有無だけを決める二値制御では、多段推論が必要な質問を救えないということです。Adaptive-RAG は「1回検索では足りない」という第三の経路を持っているため、複雑な質問で明確に効いています。
分類器は完全ではないが十分役に立つ
分類器の混同行列では、C を B に、B を C に取り違えるケースが一定数あります。また A を B に寄せてしまう誤判定も見られます。論文では、A の誤分類先として B が約 47%、C の誤分類先として B が約 31% と報告しています。
それでも全体性能が改善しているのは、分類器が完璧でなくても、質問群を大きく軽・中・重に分けるだけで十分な節約になるからです。実務でも、完全分類より「明らかに軽い質問を重いパスから外す」だけで価値が出ることは多いです。
計算時間の内訳も現実的
論文ではラベル別の時間も出しており、1 問あたりの時間は A が 0.35 秒、B が 3.08 秒、C が 27.18 秒です。C の重さが極端に大きいため、C に送る質問を絞るだけでも全体効率は大きく変わります。
ここはプロダクト設計の観点でも重要です。Adaptive-RAG の価値は「複雑な質問にも対応できる」こと以上に、高コスト経路を必要な時だけ発火させる制御 にあります。
何に使える？
Adaptive-RAG は、RAG を使いたいが全件に重い検索をかけたくないシステムに向いています。
社内ナレッジ検索
社内文書検索では、「この制度の締切は？」のような単純質問と、「ある案件で使った提案書の根拠を複数部門資料からまとめて」のような複雑質問が混在します。Adaptive-RAG なら、軽い質問は単発検索、重い質問だけ多段検索へ回せるため、体感速度を落としにくいです。
FAQ ボットや顧客サポート
顧客向けサポートでは、よくある質問は短時間で返したい一方、複雑な契約条件や障害切り分けは複数情報源をまたぐことがあります。この技術は、問い合わせの種類ごとに検索回数を変える制御層として使えます。
RAG ベースの業務エージェント
業務エージェントは、検索、要約、比較、判断を混ぜて使うことが多く、常時フル探索すると遅くなります。Adaptive-RAG の考え方を入れると、まず質問やタスクを難易度分類し、軽い依頼は単発検索だけで処理し、重い依頼だけ探索を深くする構成が作れます。
検索コストが重い SaaS
外部検索 API やベクトル DB、再ランキング、長文コンテキスト投入にコストがかかる SaaS では、1 問ごとの検索深さを最適化するだけで原価が下がります。Adaptive-RAG は、推論品質と単価のあいだを制御する設計として相性がよいです。
開発や事業へのヒント
この論文から得られるヒントは、RAG の差別化は検索器や埋め込みモデルだけではなく、質問をどう振り分けるか にもあるということです。
まずは二段階化するだけでも価値がある
Adaptive-RAG は 3 分岐ですが、実装上は最初から完全再現しなくても構いません。まずは「検索なし or 単発検索」「単発検索 or 深掘り検索」の二段階判定だけでも、かなりの改善余地があります。小規模プロダクトでも導入しやすい考え方です。
RAG の前に lightweight judge を置く発想は広く使える
この論文の本質は、重い処理の前に軽い判断を置くことです。これは RAG だけでなく、ツール呼び出し、長文要約、コード解析、エージェント分岐にも応用できます。高価なステップを全件実行する前に、必要性を判定する層を置く設計は、かなり汎用的です。
評価指標に時間を入れないと設計を誤る
論文は F1 だけでなく Time/Query を前面に出しています。実務でも、RAG 改善を精度だけで評価すると、重い多段手法ばかり採用しがちです。特にプロダクトでは first response の速さや GPU/API コストも KPI になるので、時間と検索回数をセットで見るべきです。
将来は学習済み分類器より policy 学習へ進む余地がある
Adaptive-RAG は明快ですが、分類器は 3 クラス固定です。今後は、検索回数、再ランキング有無、コンテキスト長、ツール呼び出し回数まで含めた policy 学習に発展させる余地があります。これは推測を含みますが、実運用で最適化したいパラメータが多いほど、この方向は有望です。
限界
Adaptive-RAG にも注意点があります。
まず、分類器の誤判定がそのまま経路ミスになります。簡単な質問を重い経路へ送るだけならコスト問題で済みますが、複雑な質問を軽い経路へ送ると精度低下につながります。
次に、複雑度の定義が QA タスク寄りです。この論文は single-hop と multi-hop QA を中心に評価しているため、要約、抽出、社内文書照合、SQL 生成など別タスクで同じ 3 分類がそのまま最適とは限りません。
また、分類器の教師ラベルは自動生成なのでノイズがあります。どの戦略で正答したかをベースにしているため、モデルの偶然の正解やデータセット特性に引っ張られる可能性があります。
実装面では、検索なし、単発検索、多段検索の 3 系統をメンテナンスする必要があります。つまり Adaptive-RAG は単一パイプラインより運用が複雑です。モニタリング、ログ設計、経路別評価も別途必要になります。
さらに、論文の多段経路はかなり重く、1 問 27 秒級のケースもあります。リアルタイム性が厳しいプロダクトでは、そのまま入れるより「一定時間を超えたら浅い経路で打ち切る」などの制御が必要になるでしょう。
よくある質問
Q. Adaptive-RAG は普通の RAG と何が違うのですか？
A. 普通の RAG は多くの場合、質問ごとにほぼ同じ検索フローを流します。Adaptive-RAG はその前に複雑度判定を入れ、検索なし、1回検索、多段検索を切り替える点が違います。違いは検索品質よりも、検索戦略のオーケストレーションにあります。
Q. まずは検索するかしないかの二値判定だけでも十分ですか？
A. 一定の効果はありますが、この論文の結果では multi-hop 質問への対応が不足しやすいです。難しい質問を救いたいなら、「検索する」だけでなく「何回検索するか」まで分ける価値があります。
Q. 実務で使うなら、分類器はどう作るのが現実的ですか？
A. 最初は人手ラベルより、既存ログを使った自動ラベル生成が現実的です。たとえば単発検索で十分だった問い合わせ、再検索が必要だった問い合わせ、検索なしで解けた問い合わせを集め、軽量分類器を学習させる形です。論文もこの方向を取っています。
Q. QA 以外の RAG アプリにも応用できますか？
A. できます。ただし複雑度ラベルの意味は調整が必要です。たとえば文書要約なら「検索なし / 参照文書1件 / 参照文書複数件」、業務エージェントなら「即答 / 単発ツール / 複数ツール連鎖」のように、対象タスクに合わせて経路設計を変える必要があります。
Q. この技術だけで回答品質は十分に上がりますか？
A. 必ずしもそうではありません。Adaptive-RAG は主に検索戦略の最適化なので、検索器の質、再ランキング、文書分割、生成プロンプトが弱いと限界があります。品質改善の土台として有効ですが、それ単体で全問題を解く手法ではありません。
今日の学び
この論文は、RAG を全件同じ深さで回すと、簡単な質問には無駄が多く、複雑な質問には浅すぎるという課題を扱いました。そこで Adaptive-RAG は、質問の複雑さを小さな分類器で見極め、検索なし、1 回検索、反復検索を切り替えることで解こうとしました。
ここから得られるヒントは、RAG の改善は検索器を強くするだけではなく、どの質問にどの重さの処理を当てるかを制御すること でも進められるということです。AI アプリ開発では、重い推論や検索を全件に流す前に、軽い判定層を挟む設計を意識すると、速度と品質の両立につながります。