Adaptive RAGとは？クエリ主導の動的検索でコストと精度を両立する方法

Adaptive RAGとは、クエリの複雑さに応じて検索戦略を動的に切り替えるRAG（検索拡張生成）の拡張手法である。従来のRAGがすべてのクエリに同じ検索パイプラインを適用するのに対し、Adaptive RAGはシンプルなクエリはLLM単体で処理し、複雑なクエリのみ多段階検索を行うことで、コストと精度を同時に最適化する。本記事では、RAGの運用改善を担う開発者・MLエンジニアを対象に、Adaptive RAGの仕組みと従来手法との違い、実装前の準備から構築ステップ、コスト削減と精度担保の具体策、よくある失敗の回避方法までを体系的に解説する。

Adaptive RAGの本質は、「すべての質問に同じ検索処理」をやめ、クエリごとに最適な検索戦略を選択することにある。 まず従来の静的なRAGが抱える構造的な課題を整理し、そのうえで動的ルーティングの仕組みと、関連概念であるアクティブ・リトリーバルとの位置づけを確認する。

従来のRAGは、ユーザーの入力を受け取ると必ず「検索 → コンテキスト注入 → 生成」という固定のパイプラインを実行する。この設計は実装が単純な一方、クエリの性質を考慮しないため、両方向の非効率を生む。

社内FAQボットを想像してほしい。「こんにちは」という挨拶や「君は何ができるの？」という雑談にまでベクトルデータベースへの検索が走り、取得した無関係なチャンクがトークンを消費する。LLM単体で十分答えられる一般知識の質問でも同様だ。逆に「A製品とB製品の保証条件の違いを、規約改定の経緯を踏まえて教えて」のような複数の情報源を突き合わせる質問には、1回の検索では必要な文書がそろわず、回答精度が落ちる。

つまり静的パイプラインでは、単純なクエリには過剰な検索コストを払い、複雑なクエリには検索が不足するという、コストと精度のトレードオフが構造的に存在する。クエリの難易度分布が広いほど、この非効率は大きくなる。

Adaptive RAGの中核は、クエリを受け取った時点で複雑度を判定し、3つの検索戦略に振り分ける「クエリ複雑度分類器」にある。この枠組みを提案した研究（Jeong et al., NAACL 2024, arXiv:2403.14403）では、軽量な言語モデルを分類器として学習させ、次の3戦略にルーティングする。

分類器の学習データは人手でラベリングするのではなく、既存のQAデータセットに対して「どの戦略なら正答できたか」を実際に試して自動生成する点が実装上のポイントだ。同研究では、この適応的なルーティングにより、単一戦略に固定した場合と比べて精度と効率のバランスが改善することが報告されている。

重要なのは、分類器自体は小さく安価なモデルで足りることだ。ルーティングのオーバーヘッドを最小化できるため、全体のコスト削減効果を打ち消さずに済む。

Adaptive RAGとしばしば並べて語られるのが、能動的検索（アクティブ・リトリーバル）と呼ばれるアプローチだ。両者は「必要なときだけ検索する」という思想を共有するが、判断のタイミングが異なる。

アクティブ・リトリーバルの代表例であるFLARE（arXiv:2305.06983）は、回答を生成しながら「この先の文に自信が持てない」と判断した時点で検索を発動する。Self-RAG（arXiv:2310.11511）は、検索の要否や取得結果の有用性をモデル自身が特殊トークンで自己評価しながら生成を進める。いずれも生成プロセスの途中で動的に検索を挟む「実行中の最適化」だ。

これに対してAdaptive RAGは、クエリを受け取った入口の時点で戦略を決める「事前の最適化」と位置づけられる。両者は排他的ではなく、入口でAdaptive RAGが多段階検索と判定したクエリに対して、実行中はアクティブ・リトリーバルで検索タイミングを制御する、といった組み合わせも可能だ。エージェントが自律的に検索を計画するAgentic RAGは、この延長線上にある発展形と捉えるとわかりやすい。

Adaptive RAGは既存のRAG基盤の上に「分類器」と「複数の検索パス」を載せる構成のため、土台の品質が成否を左右する。 導入前に確認すべきコンポーネントと選定基準を整理する。

Adaptive RAGの構成要素は大きく3つある。

1. ベクターデータベース: 文書のエンベディングを格納し、類似検索を担う。既存RAGで運用中のベクトルデータベースをそのまま流用できる。
2. 生成用LLM: 回答を生成する本体。戦略によって使い分ける場合は複数モデルを用意する（後述のティアード処理）。
3. クエリ分類器: Adaptive RAGで新たに追加する要素。

分類器の実装方式は、学習済みの小型分類器（高速・低コストだが学習データが必要）、LLMへのプロンプトによるゼロショット分類（学習不要で導入が手軽だが、毎クエリに分類用の推論コストがかかる）、クエリ長やキーワードによるルールベース（最速だが表現の揺れに弱い）の3つに大別される。

初期導入ではゼロショット分類で挙動を確かめ、運用ログが蓄積した段階で小型分類器に置き換える、という段階的な構成が現実的だ。最初から完璧な分類器を目指す必要はない。

検索層の品質は、どの戦略にルーティングされても回答品質の土台になる。とくに確認したいのが検索方式とエンベディングモデルの2点だ。

検索方式は、キーワード一致（BM25など）とセマンティック検索を組み合わせたハイブリッド検索を推奨する。型番や固有名詞の完全一致はキーワード検索が強く、言い換えや概念的な質問はベクトル検索が強い。多様なクエリに対応するというAdaptive RAGの趣旨とも整合する。

エンベディングモデルの選定基準は次の3つだ。

• 対応言語: 日本語やタイ語など、実際に扱う言語での検索精度を、公開ベンチマークだけでなく自社の文書で検証する
• 次元数とコスト: 次元数が大きいほど表現力は上がるが、ストレージと検索のコストも増える
• ドメイン適合: 専門用語が多い領域では、汎用モデルの類似度判定が直感とずれることがある

検索結果の上位を並べ替える再ランキングの導入余地も、この段階で確認しておくとよい。

Adaptive RAGはゼロから作り直すものではなく、既存パイプラインの手前にルーティング層を挟む拡張である。組み込みやすさは、既存実装の分離度で決まる。

確認すべき観点は3つある。第一に、検索処理が生成処理から関数やAPIとして分離されているか。検索と生成が密結合した実装では、単一ステップ検索パスとしての流用が難しい。第二に、クエリの入口が一本化されているか。複数の入口からバラバラに検索が呼ばれている場合、先にエントリポイントを統一する必要がある。第三に、クエリと回答品質のログが取得できているか。このログは後述する分類器の学習データそのものであり、ログ基盤がないままAdaptive RAG化を進めると、分類器の改善サイクルが回らない。

3つのうちログ整備だけは、Adaptive RAG導入の有無にかかわらず先行して着手する価値がある。

構築は「分類器 → 戦略別パイプライン → ルーティング統合」の3ステップで進める。 各ステップは独立して検証できるため、段階的にリリースしながらリスクを抑えられる。

最初に取り組むのはクエリ複雑度分類器の設計だ。ラベルは前述の3分類（検索なし / 単一ステップ / 多段階）を基本とする。

学習データの作り方には、Adaptive RAGの提案研究（arXiv:2403.14403）が示した自動ラベリングが使える。手元のQAペアに対して3つの戦略をそれぞれ実行し、「正答できた最も軽い戦略」をそのクエリのラベルとする方法だ。人手アノテーションが不要なため、運用ログが貯まるほど学習データも増えていく。

では、学習データがまだない立ち上げ期はどうするか。ここで完璧な分類器を目指して止まってしまうチームは多いが、答えはシンプルで、最初はLLMへのゼロショット分類プロンプトで代用すればよい。「次のクエリは A: 検索不要 / B: 1回の検索で回答可能 / C: 複数の情報源の組み合わせが必要 のどれか」と問うだけでも、固定パイプラインよりは合理的な振り分けになる。

評価で見るべきは分類精度そのものより、誤分類のコストの非対称性だ。単純なクエリを多段階検索に回す誤りは「コストの無駄」で済むが、複雑なクエリを検索なしに回す誤りは「誤答」に直結する。後者を重く罰する評価設計にし、迷ったら検索あり側に倒すしきい値を設定する。

次に、ルーティング先となる3つのパイプラインをそれぞれ独立に構築する。

• 検索なしパス: LLM単体で回答する。注意点は、システムプロンプトで「社内固有の情報は検索パスに委ねる」前提を明示し、知らないことを推測で答えないよう制約することだ。
• 単一ステップ検索パス: 既存のRAGパイプラインをほぼそのまま流用できる。検索 → 上位チャンクの注入 → 生成という標準構成だ。
• 多段階検索パス: クエリを部分質問に分解し、検索と推論を交互に繰り返して回答を組み立てる。ループ制御（最大反復回数・終了条件）を含むため、3つの中で最も実装が複雑になる。

ポイントは、各パスを単体でテストできる状態を保つことだ。パスごとに評価用クエリセットを用意しておくと、後段のルーティング統合で問題が起きたとき、分類器の誤りなのかパス自体の劣化なのかを切り分けられる。

最後に、分類器と3つのパスを接続してエンドツーエンドで動かす。実装自体は「分類結果に応じた分岐」にすぎないが、運用品質を決めるのは次の3点だ。

1. フォールバック設計: 分類器の確信度が低いクエリは、単一ステップ検索に倒すデフォルトを設ける。多段階検索が最大反復回数に達しても根拠がそろわない場合に、「わかる範囲の回答＋不足の明示」へ切り替える出口も用意する。
2. 戦略別のモニタリング: ルーティングの分布（どの戦略に何割流れたか）、戦略ごとのレイテンシ・トークン消費・回答品質を分けて記録する。この内訳がないと、改善すべきが分類器なのか特定パスなのか判断できない。
3. 段階的リリース: いきなり全トラフィックを切り替えず、まずルーティング判定だけを記録して既存RAGと並走させるシャドーモードで分布を確認し、その後一部トラフィックから切り替える。

統合後は、従来の固定パイプラインとのコスト・精度比較を同一クエリセットで実施し、効果を定量化してから全面移行する。

Adaptive RAGのコスト削減効果は、ルーティングだけでなくパイプライン内部のトークン設計で決まる。 ここでは戦略別に調整できる3つの最適化レバーを解説する。

入力トークン量は「チャンクサイズ × 取得件数（top-k）」でほぼ決まる。ここを戦略別に変えられるのが、Adaptive RAGのコスト面での利点だ。

固定パイプラインでは、複雑なクエリに合わせて大きめのチャンク・多めのkを全クエリに適用しがちで、単純なクエリにも同じトークンコストを払うことになる。Adaptive RAGなら、単一ステップ検索パスは小さめのk、多段階検索パスは反復ごとに少数ずつ取得、と分けられる。

チャンクサイズ自体の調整は従来のRAGと同様で、小さすぎると文脈が分断されて検索精度が落ち、大きすぎると無関係な内容がコンテキストウィンドウを圧迫する。見出しや段落など文書の論理構造に沿った分割を基本に、自社文書での検索評価で調整する。

なお、コンテキストウィンドウが大きいモデルに文書を丸ごと流し込む力技は、Adaptive RAGが解決しようとしている「無駄なトークン消費」を増幅する方向であり、本末転倒になりやすい。

処理の全段階に最上位のLLMを使う必要はない。役割ごとにモデルの「ティア（階層）」を分けることで、品質を保ったままコストを下げられる。

結論として、分類のような軽量タスクはSLMに、複数文書の統合や推論を伴う生成はLLMに割り当てるのが基本形だ。

データ主権の要件やクエリ量によっては、分類器や軽量パスをローカルLLMで動かす構成も選択肢になる。その場合は量子化による精度への影響を自社タスクで検証したうえで採用する。

3つ目のレバーは、そもそもLLM呼び出し自体を減らすことだ。

• セマンティックキャッシュ: 「有給休暇の申請方法は？」と「有休ってどう申請するの？」のような意味的に同じクエリを、エンベディングの類似度で検出し、過去の回答を再利用する。FAQ性の高いワークロードでは効果が大きい。
• エンベディングキャッシュ: 同一テキストのエンベディング再計算を避ける。文書更新時の差分埋め込みと組み合わせる。
• プロンプトキャッシュ: 主要なLLM APIが提供するプロンプトキャッシュ機能を使い、システムプロンプトや定型コンテキストの再処理コストを削減する。
• スロットリング: ユーザー単位・テナント単位のレート制御で、暴走したクライアントや悪意ある連投によるコスト急増を防ぐ。

注意点はキャッシュの鮮度管理だ。ナレッジベースの文書を更新したら、関連するキャッシュを無効化する仕組みをセットで設計しないと、古い回答を返し続けることになる。

コストを下げても、誤った回答を返しては意味がない。 Adaptive RAGの精度面の要は、検索結果の品質を機械的に評価するグラウンディングチェックと、複雑なクエリへの多段階対応にある。

グラウンディングとは、LLMの回答を検索で得た根拠文書に接地させることだ。Adaptive RAGでは、検索後と生成後の2箇所にチェックポイントを挟める。

検索後のチェックとして参考になるのが、CRAG（Corrective RAG, arXiv:2401.15884）が提案した検索評価器だ。取得した文書がクエリに本当に関連しているかを軽量な評価器で判定し、品質が低ければそのまま生成に進まず、クエリの書き換えによる再検索や、別の情報源への切り替えといった修正アクションを取る。「検索結果が悪いまま生成するとハルシネーションになる」という因果の上流で手を打つ発想だ。

生成後のチェックでは、回答の各主張が根拠文書のどの箇所に対応するかを検証し、根拠のない記述を検出する。回答に出典（どの文書のどの部分か）を付ける設計にしておくと、ユーザー自身が検証できるため、誤答が紛れた場合の実害も抑えられる。

どこまで厳密にやるかはユースケース次第だが、最低限「検索結果の関連性スコアがしきい値未満なら、その旨を明示して回答を保留する」だけでも、自信満々の誤答はかなり減らせる。

「X社との契約条件と、現行の社内規程の間に矛盾はあるか」のような質問は、複数の文書を取得して突き合わせる必要があり、1回の検索では答えられない。多段階検索パスの設計パターンは3つある。

1. クエリ分解: 元の質問を部分質問に分解し、それぞれ検索してから統合する。部分質問を並列実行できるため、レイテンシを抑えやすい。
2. 交互検索: 推論を進めながら「次に必要な情報」を特定し、検索を繰り返す。前の検索結果が次のクエリを決めるため逐次的だが、依存関係のある推論に強い。
3. 自己評価付き生成: Self-RAG（arXiv:2310.11511）のように、生成の途中で検索の要否と取得結果の有用性をモデル自身に評価させる。

いずれのパターンでも、最大反復回数と終了条件を必ず設ける。根拠がそろわないまま反復が続くとコストが膨らむため、上限に達したら「判明している範囲」と「不足している情報」を分けて回答する設計が安全だ。

なお、エンティティ間の関係をたどる質問（組織図・依存関係など）が多い場合は、知識グラフを使うGraphRAGの併用が向いている。

Adaptive RAGの障害は、派手なエラーではなく「静かな品質劣化」として現れることが多い。 代表的な2つの失敗パターンと回避策を押さえておく。

最も典型的な失敗は、複雑なクエリが「検索なし」パスに誤って振り分けられるケースだ。このときシステムはエラーを出さない。LLMが手元の知識だけで、もっともらしい誤答を自信のある口調で返すだけだ。ユーザーからの「答えが薄い」「事実と違う」という報告で初めて発覚し、原因がルーティングにあるとは気づきにくい。

回避策は4つある。

• 非対称なしきい値: 分類の確信度が低いときは検索あり側に倒す。誤って検索する無駄コストは、誤って検索しない誤答より安い
• シャドーモード運用: 本番切り替え前にルーティング判定だけを記録し、既存RAGの回答と突き合わせて誤分類の傾向を把握する
• 戦略別の品質モニタリング: 「検索なしパスの回答への低評価率」のように、パス別の品質指標を分けて監視する。全体の平均値では特定パスの劣化が埋もれる
• 定期的な再学習: 運用ログから誤分類事例を集め、分類器を継続的に更新する。クエリの傾向は運用とともに変わる

「分類器も劣化する運用対象である」という前提でモニタリングを設計することが、結局のところ最大の回避策になる。

もう1つの失敗は、検索層そのものの劣化だ。原因は2系統ある。

1つ目はナレッジベースの経年劣化。文書の重複や旧版の残存が進むと、検索上位が古い情報で占有され、どの戦略にルーティングしても回答品質が下がる。文書の更新日・版数をメタデータとして持ち、検索時に新しい版を優先する設計と、定期的な重複排除のルーチン化で防ぐ。

2つ目はRAGポイズニングと呼ばれる外部起因のリスクだ。ナレッジベースの取り込み元（共有ドライブ、Webページ、外部から受領した文書など）に悪意あるテキストが混入すると、それが検索でヒットした際にLLMへの間接的なプロンプトインジェクションとして機能し、回答の誘導や情報漏えいにつながりうる。

対策は、取り込みソースを信頼度で区分して権限管理すること、取り込み時に命令文らしきパターンを検査すること、そして回答に出典を必ず表示して人間が検証できる経路を残すことだ。検索対象が広がるほどこのリスクは増えるため、「何でも取り込む」運用は避ける。

Q. Adaptive RAGと通常のRAGはどちらを選ぶべき？ クエリの多様性で判断します。ユーザーの質問が定型的で難易度が均質なら、固定パイプラインの通常のRAGで十分です。挨拶レベルの雑談からマルチホップ推論まで難易度の幅が広く、かつクエリ量が多いシステムほど、Adaptive RAGのコスト削減と精度改善の効果が大きくなります。

Q. Adaptive RAGとAgentic RAGは何が違う？ 判断の主体と範囲が違います。Adaptive RAGは「どの検索戦略を使うか」を入口で1回判定する仕組みです。一方Agentic RAGは、エージェントが検索・ツール実行・再計画を自律的に繰り返す、より広い枠組みを指します。Adaptive RAGの多段階検索パスにエージェント的な制御を採用すれば、両者は自然に重なります。

Q. クエリ分類器にはどんなモデルを使えばいい？ 段階的に進めるのが現実的です。立ち上げ期はLLMへのゼロショット分類プロンプトで開始し、運用ログが蓄積したらSLMや軽量分類器を学習させて置き換えます。全クエリで実行される処理のため、最終的には低レイテンシ・低コストのモデルに寄せるのが定石です。

Q. Adaptive RAGの導入でコストはどれくらい下がる？ クエリ分布に依存するため一概には言えません。検索が不要な単純クエリの割合が高いワークロードほど削減幅は大きくなります。導入前に既存ログをサンプリングして「検索なしで回答可能なクエリの割合」を見積もると、自社での効果を事前に概算できます。提案研究（arXiv:2403.14403）でも効果は精度と効率のバランス改善として報告されており、絶対的な削減率はワークロード次第です。

Adaptive RAGとは、クエリの複雑さを入口で判定し、検索なし・単一ステップ検索・多段階検索の3戦略を動的に使い分けるRAGの拡張手法である。すべてのクエリに同じパイプラインを適用する従来構成の「単純なクエリへの過剰コスト」と「複雑なクエリへの精度不足」を、1つの仕組みで同時に解消できる点が最大の価値だ。

導入は、ゼロショット分類による小さなルーティングから始め、運用ログで分類器を育て、グラウンディングチェックとモニタリングで品質を守る——という段階的な進め方が現実的だ。完成された分類器を最初から用意する必要はなく、既存のRAGパイプラインを活かしながら拡張できる。

当社では、RAGパイプラインの設計・運用改善を含むAI活用の支援を行っている。自社のクエリ分布に合わせたAdaptive RAGの導入を検討する際は、まず運用ログの分析から着手することをおすすめする。