今回の論文
今回取り上げるのは、Guanzheng Chen、Qilong Feng、Jinjie Ni、Xin Li、Michael Qizhe Shieh による論文「RAPID: Long-Context Inference with Retrieval-Augmented Speculative Decoding」です。2025年の ICML 2025（Proceedings of Machine Learning Research, Volume 267）で公開されました。研究分野としては、長文LLM推論、RAG、speculative decoding、推論最適化に当たります。URL は https://proceedings.mlr.press/v267/chen25s.html です。
この論文を選んだ理由は、長文コンテキストとRAGを対立する選択肢として扱わず、「RAGを推論高速化の部品として使う」 方向へ発想を進めているからです。RAG は通常、外部知識を足すための仕組みとして語られますが、RAPID はそれを長文推論のレイテンシ問題に使います。RAG基盤を持つ開発チームにも、長文LLMを使いたい開発チームにも、そのまま設計のヒントになります。
どんな技術か
RAPID は、長い文脈をそのまま読むターゲットLLMの前で、短く圧縮した検索文脈だけを見るドラフトLLM を動かし、そのドラフト結果を speculative decoding で検証しながら長文推論を速くする技術です。
普通の speculative decoding は、小さなドラフトモデルを使って数トークン先を先読みし、大きなターゲットモデルがまとめて正誤判定します。ただし長文コンテキストでは、ドラフト側も長いKVキャッシュを持つ必要があり、そこで速度のうまみが薄れます。
RAPID はそこを逆手に取ります。全文を読む代わりに、質問や直近の生成に関係しそうなチャンクだけを取り出してドラフト側に渡します。するとドラフト側は短い文脈で高速に動けます。そのうえで、ドラフトが持つ「関連箇所だけ読んでいる強み」を、推論時の知識転移でターゲット側にも反映させます。
要するに RAPID は、RAG を精度向上のためだけでなく、長文推論を軽くするためにも使う 手法です。
課題
この技術が解決しようとしているのは、長文LLMの推論が重すぎる一方で、単純なRAGだけでは長文全体を読む利点を捨ててしまう、という問題です。
何が難しいのかというと、長文コンテキスト推論では1トークン生成するたびに巨大なKVキャッシュを参照し続ける必要があるからです。理論上は長文を全部読めるモデルでも、実運用ではレイテンシやGPUメモリ帯域がボトルネックになります。特に 100K トークン級の入力では、生成そのものよりキャッシュ操作が足を引っ張ります。
既存の speculative decoding には別の限界があります。本来は小型ドラフトモデルが高速に候補トークン列を作ることで効率化しますが、長文入力ではドラフトモデルも長文を抱えるため、思ったほど速くなりません。さらに、長文全体を読むモデルと、検索で要点だけ読むRAGモデルでは、得意な誤差パターンが違います。通常の speculative decoding はターゲット分布に厳密に合わせるので、RAG側の「むしろよい候補」を捨ててしまうことがあります。
なぜこの課題を解く必要があるのかというと、実際のAIシステムでは長文を扱う機会が増えているからです。コードベース全体の解析、長い対話履歴を持つエージェント、契約書やログの解析、社内ナレッジの長いスレッド参照などでは、長文を読めるだけでは足りず、その処理を現実的な応答時間で返せること が重要です。
用語解説
- Speculative Decoding
- 軽いドラフトモデルで複数トークンを先に提案し、重いターゲットモデルがまとめて検証する推論高速化手法です。RAPID はこの枠組みを使いながら、ドラフト側の文脈を検索で短くする点が核心です。
- 長文コンテキスト推論
- 数万から十数万トークン以上の入力をそのままモデルへ与えて推論することです。RAG と違って全文を保持できる利点がありますが、KV キャッシュが大きくなりやすく、推論コストが急増します。
- RAG（Retrieval-Augmented Generation）
- 入力や質問に関連する文書断片だけを検索して生成に渡す手法です。RAPID では最終回答そのものをRAGで作るのではなく、ドラフト生成を軽くして関連情報へ集中させる役割で使われます。
- KVキャッシュ
- Transformer が過去トークンの Key と Value を保存して再利用する仕組みです。長文推論ではこのキャッシュの保持と読み出しが重くなり、speculative decoding の速度差を食いつぶす主要因になります。
- 推論時知識転移
- 学習時ではなく推論時に、あるモデルの分布情報を別のモデルの出力へ反映させる考え方です。RAPID では RAG ドラフタを教師、長文ターゲットLLMを生徒のように見立て、受理判定に使う分布を補正します。
技術の仕組み
RAPID の技術的な肝は、単に「短い文脈でドラフトする」だけではありません。ドラフトの効率性と、長文ターゲットの正しさを両立するために、検索・検証・分布補正を一体で設計しています。
基本アイデア
長文入力全体を C、検索で圧縮した短い文脈を C_S とすると、ターゲットLLMは C を見て通常どおり生成し、ドラフトLLMは C_S を見て先読みします。RAPID の狙いは、|C_S| << |C| にすることで、ドラフト側の計算とメモリアクセスを一気に軽くすることです。
ここで重要なのは、「短い文脈だから速い」だけではありません。検索によってノイズの少ない関連チャンクへ寄せるので、ドラフトが出す候補トークンがむしろ当たりやすくなる場面があります。論文はここを、長文全体を見るモデルとRAGモデルの補完関係として扱っています。
モデル構造
1. 長文ターゲットLLM
ターゲットモデルは、フルの長文コンテキストを保持する本命モデルです。LLaMA-3.1 や Qwen2.5 の長文設定が使われています。最終的な分布の基準はこのモデルです。
2. RAGドラフタ
ドラフトモデルは、長文全体ではなく検索で得た短縮文脈だけを入力に取ります。論文では長文を 512 トークン単位に分割し、BGE-M3 で埋め込み、クエリとのコサイン類似度で上位チャンクを回収しています。類似度 0.3 未満のチャンクは除外し、取得文脈長は最低 4096 トークン、かつ元入力長の 1/24 以下に抑えています。
この設計により、ドラフトモデルは同じスケールのモデルでも十分軽く動けます。さらに RAPID では、小さいターゲットを大きいRAGドラフタで補助する upward-speculation まで可能にしています。普通の speculative decoding では、ドラフトが大きいと計算面で成立しにくいので、ここはかなり新しい点です。
推論フロー
1. 長文をチャンク化して関連部分を検索する
入力長文を固定長チャンクへ分け、クエリや現在のタスクに近い部分だけを取得します。これにより、ドラフト側は全文ではなく要点だけを見ます。
2. RAGドラフタが複数トークンを先読みする
論文では 1 ステップあたり γ=10 トークンをドラフトします。短い検索文脈上で先読みするため、ここは長文ターゲットより軽く回せます。
3. ターゲットLLMがまとめて検証する
ドラフトトークンは通常の speculative decoding と同様にターゲット側で検証されます。ただし RAPID は受理確率に使う分布をそのままのターゲット分布にはしません。
重要な工夫1: Retrieval-Augmented Target Distribution
RAPID の本質はここです。ドラフト分布 q(x) とターゲット分布 p(x) が食い違ったとき、普通の speculative decoding だとターゲット基準で弾かれてしまいます。ですがRAGドラフタは、関連情報へ絞って読んでいるぶん、長文ターゲットよりよい候補を持っていることがあります。
そこで論文は、ターゲットのロジット z(x) をそのまま使う代わりに、q(x) - p(x) の差を使って補正した新しい分布 p̂(x) を定義します。式の形は、
p̂(x_i) = softmax(z(x_i)/T + η · (q(x_i) - p(x_i)))
です。ここで η は、ドラフトの知識をどれだけ強く混ぜるかを決める係数です。
この補正は、直感的には 「ターゲットが迷っているが、RAGドラフタは強く推している候補」を少し持ち上げる 動きです。論文ではこれを、推論時の知識蒸留に近いものとして説明しています。
重要な工夫2: 分布を変えても理論保証を壊さない検証
受理分布を変えると、「本来のターゲットモデルと同じ分布を保てるのか」が問題になります。RAPID は、拒否されたときに使う残差分布も調整し、最終的に元のターゲット分布と整合するように設計しています。
このため RAPID は、単なるヒューリスティックな再ランキングではなく、speculative decoding の理論枠組みの中でRAG知識を注入する 手法になっています。
データの扱い方
学習時に新しい専用データセットを作る方式ではありません。長文を 512 トークン単位へ区切り、埋め込み検索で短縮文脈を作るだけなので、既存の長文アプリにも比較的載せやすいです。必要なのは、長文をチャンク化して検索できる前処理と、ドラフト用の検索文脈を作る仕組みです。
実務上は、RAG 基盤をすでに持っているなら、その検索器を「回答生成用」だけでなく「ドラフト生成用」にも流用できる可能性があります。
実験と結果
論文では、RAPID が本当に速いのか、単に速いだけでなく精度も上がるのか、検索が多少外れても耐えるのかを段階的に検証しています。
何を検証したのか
主な検証対象は3つです。1つ目は、長文推論ベースラインより性能が上がるかどうかです。2つ目は、実際のスループットがどれだけ改善するかです。3つ目は、入力長や取得文脈長、検索品質が変わっても安定するかどうかです。
どんなデータセットや評価指標を使ったのか
ベンチマークとしては、100K 超の文脈を含む ∞Bench と、8K から 2M words 相当までの長さを含む LongBench v2 が使われています。∞Bench では長文QA、選択式QA、要約を評価し、指標は F1、Accuracy、ROUGE-L-Sum です。LongBench v2 では全体精度に加え、長いChain-of-Thought系サブセットでのスループットも見ています。
効率面では、pre-fill time と throughput speedup が主要指標です。論文の速度評価は、おおむね 120K トークン前後の入力と最大 1K トークン生成を想定しています。
自己スペキュレーション設定での結果
同じスケールのRAGドラフタを使う self-speculation では、LLaMA-3.1-8B の ∞Bench 平均が 39.33 から 42.83 に上がり、LongBench v2 全体も 28.0 から 32.4 へ改善しました。スループットは 2.10 倍です。
LLaMA-3.1-70B でも、∞Bench 平均は 45.07 から 50.62、LongBench v2 全体は 31.6 から 40.2 まで伸び、スループットは 2.69 倍でした。Qwen2.5 系でも、7B で 2.65 倍、72B で 1.98 倍の高速化が報告されています。
ここで重要なのは、RAGを足したのに精度を落として速くしたのではなく、精度も速度も両方伸ばしている 点です。長文ターゲット単独と、短縮文脈RAG単独の中間ではなく、両者の長所を足し合わせる形になっています。
Upward-Speculation の結果
RAPID の面白い結果は、小さいターゲットに大きいRAGドラフタを組み合わせた upward-speculation です。たとえば LLaMA-3.1-8B ターゲットに LLaMA-3.1-70B のRAGドラフタを使うと、∞Bench 平均は 49.98 まで上がっています。
速度は self-speculation より控えめですが、長文ターゲットを大きくせず、検索側だけ強いモデルを使って回答品質を持ち上げる という設計が見えてきます。これは実務でも、常時 70B を長文全文に走らせるのは厳しいが、短い検索文脈だけなら回せる、という構成に対応できます。
文脈長と取得長の分析
論文では、RAPID はターゲット文脈長が 32K を超えるあたりから安定して speedup が 1.0 倍超になり、素朴な speculative decoding より早く効き始めると報告しています。また、取得文脈長は 4K から 8K 程度でほぼ同等の効率を出しつつ、16K を超えるとドラフト側の計算負荷が効き始めます。
つまり、取得文脈は長ければよいわけではありません。RAPID は 「必要十分な関連情報だけ持たせる」 ことで最も効きやすい設計です。
実運用に近い対話評価
長いマルチターン対話履歴を持つ 122K トークン級の設定では、RAPID は GPT-4-Turbo-1106 を用いた LLM-as-a-Judge 評価で 4.21 点を記録し、ターゲット単独の 2.82、RAGドラフタ単独の 3.95、素朴な speculative decoding の 2.94 を上回りました。受理率も 76.94% と高く、素朴な speculative decoding の 56.34% よりかなり安定しています。
この結果から、RAPID は単なるベンチマーク上の高速化ではなく、長い会話履歴のような現実的な入力でも、関連部分へ寄ったドラフトが効く可能性を示しています。
何に使える？
RAPID が効きそうなのは、長文を全部読ませたいが、そのままでは遅すぎるシステムです。特に、すでにRAGを使っているプロダクトなら応用しやすいです。
長い社内ナレッジを読むRAG
社内Wiki、議事録、問い合わせ履歴、設計書を横断して回答するシステムでは、長文全文を読めるLLMは魅力的ですが、毎回全文推論するのは高コストです。RAPID 的な構成なら、全文を持つターゲットを残しつつ、ドラフト側は検索結果だけで軽く回せます。検索がうまく刺さる質問ほど、速度と品質の両方が改善しやすいです。
長い対話履歴を持つAIエージェント
エージェントは、対話履歴、途中メモ、ツール出力、過去の失敗ログなどで文脈がすぐ太ります。RAPID は、履歴全体はターゲット側に保持しながら、ドラフトでは今のターンに効きそうな履歴断片だけを見るので、長い会話での応答短縮に向いています。
コードベース全体を読む開発支援
大きなリポジトリ要約や影響範囲調査では、長文コンテキストを読む能力が欲しい一方、毎回フルスキャンは重いです。RAPID の発想なら、全文を見られる保険を残しつつ、先読みはシンボル検索や埋め込み検索で絞ったファイル群に寄せられます。
高価格モデルの部分活用
upward-speculation の考え方は、短い検索文脈だけ強いモデルで見せる設計に向いています。たとえば、回答本体は 8B 級長文モデルで作りつつ、ドラフトだけ 70B 級の短いRAG文脈で走らせる構成です。これなら高価格モデルの使用量を限定しながら、品質向上の恩恵だけを取りにいけます。
開発や事業へのヒント
この論文から得られるヒントは、RAG と長文コンテキストを二者択一で考えないことです。両者を推論パイプラインの別の役割として組み合わせると、設計の自由度がかなり上がります。
RAGは回答生成だけに使う必要がない
多くのプロダクトでは、RAG は「関連文書を拾ってそのまま回答に使う」ものとして設計されています。しかし RAPID は、RAG を ドラフト生成のための圧縮器 として扱います。これは実務でも応用しやすく、検索品質が十分なら、最終回答より前段の推論効率化にRAGを回せます。
推論パイプラインで役割分担を作る
同じモデルにすべてをやらせるより、「全文を読む責任」と「関連部分だけで先読みする責任」を分けたほうが、コスト設計しやすい場面があります。小規模なプロダクトでも、軽量検索器とドラフト層を足すだけで、長文機能の体感速度を改善できる可能性があります。
高性能モデルは全文ではなく要所だけ使う
upward-speculation は、事業設計としても面白いです。高性能モデルを毎回フル文脈で動かすのではなく、短い取得文脈のドラフトに限定すれば、コストを抑えつつ品質を上げられます。これは有料プラン向けの高品質モードや、重要問い合わせだけ精度を上げたいサポート運用にも向いています。
長文時代の差別化はモデル選定だけではない
長文LLMが増えると、差別化は「どのモデルを選ぶか」より、「どう前処理し、どうドラフトし、どう検証するか」に移りやすくなります。RAPID はその典型で、推論オーケストレーション自体がプロダクト価値になることを示しています。
限界
もちろん RAPID にも限界があります。
まず、検索品質に依存します。論文では無関係な取得文脈でもある程度の頑健性が示されていますが、実運用で検索が継続的に外れると、ドラフトの質も受理率も下がりやすいはずです。検索器の評価なしに導入しても、期待どおりには効かない可能性があります。
次に、取得文脈を長くしすぎると、ドラフト側の負荷が増えて速度のうまみが薄れます。論文でも 16K を超える取得長ではオーバーヘッドが目立つと示されています。つまり、RAPID は「長く取れば安全」ではなく、「必要なところだけ取る」検索設計が前提です。
また、実装は簡単ではありません。通常のRAGに加えて、speculative decoding、受理判定、補正分布、残差サンプリングまで一体で実装する必要があります。既存の推論サーバーがこの種のカスタム検証に対応していない場合、導入コストは高めです。
さらに、論文での主要検証は LLaMA-3.1 と Qwen2.5 系です。別アーキテクチャや商用API型モデルで同じ効果が出るかは未確定です。特に、内部ロジットや受理処理を触れない閉じたAPIでは、そのままの再現は難しいです。
最後に、短い入力では恩恵が小さい可能性があります。RAPID の利点は、長文でKVキャッシュが重いときに大きく効きます。数千トークン程度の通常チャットなら、検索やドラフトの追加段が逆に無駄になるかもしれません。
よくある質問
Q. RAPID は普通のRAGと何が違うのですか？
A. 普通のRAGは、検索した文脈をそのまま使って最終回答を生成します。RAPID は、検索文脈を主にドラフト生成の高速化に使い、最終的な整合性は長文ターゲットLLMで担保する点が違います。
Q. RAPID は長文LLMをRAGで置き換える技術ですか？
A. 置き換えではありません。むしろ長文LLMを残したまま、その前段にRAGドラフタを置いて補助する技術です。全文を読める強みを残しつつ、関連部分だけ読む速さも取りにいく設計です。
Q. どんなプロダクトで導入価値が高いですか？
A. 100K トークン級の長い入力を日常的に扱うプロダクトです。長い対話履歴を持つエージェント、巨大ドキュメント解析、コードベース検索、長いサポート履歴参照などで特に相性がよさそうです。
Q. 検索が少し外れても使えますか？
A. 論文では、無関係な取得文脈でも η を適切に調整すると、自己スペキュレーション設定で一定の精度改善が残ると報告されています。ただし、これは完全に検索品質へ依存しないという意味ではなく、実運用では検索器の改善余地を別途見るべきです。
Q. 小規模チームでも考え方を活かせますか？
A. はい。論文そのものを完全再現しなくても、長文全文推論の前に「検索で絞った文脈で軽い先読みや候補生成をする」という発想は、小規模なRAGアプリでも応用できます。特に高価な大モデルを全文へ毎回投げている場合、設計の見直し余地があります。
今日の学び
この論文は、長文LLM推論がKVキャッシュ由来で遅くなりやすいという課題を扱っています。それに対して、RAPID は検索で圧縮した文脈を見るRAGドラフタと、推論時知識転移を組み合わせた speculative decoding で解こうとしました。
ここから得られるヒントは、RAG と長文コンテキストは競合技術ではなく、役割を分けて組み合わせられるということです。今後のAI開発では、モデル選定だけでなく、検索・ドラフト・検証のパイプライン設計そのものが差別化の中心になっていきそうです。