RAGのボトルネックは生成側でなく検索側にある時がある──証拠を前倒しする「PACE」という数学的な保証つき手法

RAG（検索拡張生成）を高速化する取り組みの多くは「LLMに渡すコンテキストをどう圧縮するか」という下流側の最適化に集中してきた。しかしarXivで2026年8月25日に公開された論文（arXiv:2608.25115）は、負荷や再順位付け予算の条件次第では、ボトルネックが下流のLLM生成ではなく上流のリランキング（再順位付け）そのものに移ることを実測で示している。

3行まとめ

• RAGはエンドツーエンドのシステムであり、ボトルネックは負荷や再順位付け予算次第で上流のリランキングと下流の生成の間を移動する。高いクエリレートや大きな再順位付け予算のもとでは、リランキングが支配的なボトルネックになり得ると実証
• 再順位付け予算を単純に減らすとボトルネックは緩和できるが、支持証拠を取りこぼしてリコール（再現率）を落とす。この対処として、証拠の前倒し（evidence frontloading）と圧力適応型の予算調整（pressure-adaptive budgeting）を組み合わせた学習不要のフレームワーク「PACE」を提案
• PACEは候補を「クエリとの関連性・相補性・多段推論の証拠チェーンへの有用性」でスコアリングし直す並べ替えが劣モジュラ性を満たすことを示し、貪欲選択に(1-1/e)の近似保証を与えている。3つのマルチホップQAデータセットとオンラインサービングのシミュレーションで、証拠のリコール改善とp95レイテンシの削減を確認

ボトルネックは「動く」という指摘

論文のアブストラクトはこう述べている。

RAG is an end-to-end system, and its bottleneck can shift between upstream reranking and downstream generation under different serving loads and reranking budgets. [...] upstream reranking can become the dominant bottleneck under high query rates or large reranking budgets.

（RAGはエンドツーエンドのシステムであり、そのボトルネックは負荷や再順位付け予算によって上流のリランキングと下流の生成の間を移動し得る。［中略］高いクエリレートや大きな再順位付け予算のもとでは、上流のリランキングが支配的なボトルネックになり得る）

これまでのRAG高速化研究の多くが「LLMへの入力コンテキストをどう圧縮するか」という下流最適化に偏っていたのに対し、この論文はまず「ボトルネックの位置そのものが状況依存で動く」ことを実証的に示すところから議論を始めている。

PACEの2つの仕組み

PACE（Prioritized Adaptive Coverage of Evidence）は2つの要素の組み合わせだ。

• 証拠の前倒し（evidence frontloading）：候補文書を「クエリとの関連性」「他の候補との相補性」「多段推論（multi-hop）の証拠チェーンを形成する上での有用性」で並べ替え、上位に証拠密度の高い候補を集める
• 圧力適応型の予算調整（pressure-adaptive budgeting）：リランカーとLLMそれぞれの負荷の相対的な圧力に応じて、再順位付けの予算を動的に調整する

論文は、この並べ替えの目的関数が単調劣モジュラ（monotone submodular）であることを示しており、これによって貪欲選択に**(1-1/e)の近似保証**（劣モジュラ関数の最大化問題で貪欲法が得られる標準的な理論的下限）が付くとしている。実務的な工学のアイデアに数学的な裏付けを与えている点が、この論文の特徴だ。

パラメータ比92.5倍でも、リランカーがボトルネックになる

論文のHTML全文（arXiv:2608.25115のフルテキスト版）を読むと、「ボトルネックが動く」という主張を裏付ける具体的な数字が載っている。実験ではLLMにQwen2.5-3B-Instruct（軽量モデル）とQwen2.5-7B-Instructを、リランカーにtrecdl22-crossencoder-debertav3とms-marco-MiniLM-L12-v2を組み合わせて使っている。このうちQwen-3BとMiniLM-L12のペアはパラメータ数の比が92.5倍（LLMの方が圧倒的に大きい）にもかかわらず、QPS（1秒あたりのクエリ数）が2.5に達すると、生成側ではなくリランカー側がボトルネックに転じると報告されている。「大きなモデルの方が遅い」という直感に反して、負荷が上がるほど小さいリランカーの方が先に詰まる、という逆転が実測で示されている点が、この論文の核となる観察だ。

3つのデータセットとベースライン、具体的な効果の数字

評価に使われたのはHotpotQA・2WikiMultiHop・MuSiQueという3つのマルチホップQAデータセットで、いずれも複数の文書にまたがる推論を要求するベンチマークだ。比較対象（ベースライン）として、学習不要の並べ替え手法5つが使われている。

このうちDartboardの元論文（arXiv:2407.12101）を確認すると、MMRのように多様性と関連性を明示的にトレードオフさせるのではなく、「relevant information gain」という単一の最適化指標に基づく点が新規性だと説明されている。PACE論文はこのDartboardを含む5手法をベースラインとして、証拠密度の高い並べ替えの効果を測っている。

具体的な効果として論文が挙げている数字はこうだ。「HotpotQAにおいて、PACEはD=20（再順位付け候補20件）で、最良のベースラインがD=40で達成する証拠リコールに匹敵する——つまり半分の予算で同等の結果を得ている」。評価プロトコルは、ハイパーパラメータを持つベースラインについては各データセット100クエリの較正セットで最良設定を選び、それを評価スプリットにそのまま適用するという方式で、各実行を固定乱数シードで3回繰り返してp95レイテンシとGPUメモリ使用量を測定している。

3つのデータセットとオンラインサービングのシミュレーションを通じて、証拠のリコール（再現率）が改善し、リランキング負荷が高いワークロード下でのp95レイテンシ（全リクエストのうち遅い方から5%が収まる時間）が削減されたと報告されている。論文のタイトル通り「less can be more（少ない方が多くを得られる）」という逆説的な結論として、「証拠密度の高い上位候補があれば、より少ない再順位付け候補数でもより高い最終リコールを実現できる」と主張されている。

RAGを自前で組んでいる人にとっての意味

RAGパイプラインを自作している場合、「リランキングの候補数を増やせば増やすほど精度が上がる」という直感で予算を大きく取りがちだが、この論文はその前提自体に疑問を投げかけている。負荷が高い場面では、候補数を増やすことがレイテンシの支配的な原因になり得るため、候補の並べ替えの質を上げて数を絞る方が有利になり得る、という考え方は、既存のRAG設計を見直す上での視点として参考になる。

p95レイテンシの改善率とコードの所在は確認できなかった

本記事はarXiv:2608.25115のアブストラクト・HTML全文・arXiv APIメタデータ、および比較ベースラインの一つDartboardの元論文アブストラクトを情報源としている。並べ替えスコアの数式（劣モジュラ関数の定義式）自体はHTML全文中に記載があったが、本記事では数式そのものの転記は避け、「単調劣モジュラ性を満たすことを示した」という主張の紹介にとどめた。p95レイテンシが具体的に何%削減されたか、証拠リコールが何ポイント改善したかという定量的な数値は、論文中では主に図（Figure）として提示されており、本文のテキスト抽出では正確な数値を拾いきれなかったため、本記事では「改善した」という定性的な記述にとどめている。また、PACEの実装コードを公開するGitHubリポジトリへのリンクは論文中に見当たらず、著者らが公開しているかどうかは確認できていない。自分のRAGパイプラインでこの手法を実装して再現する検証も行っていない。

関連記事: RAG（検索拡張生成）とは / AIエージェントとは / MCPとは

感想・指摘はコメント欄へ。