今回の論文
今回取り上げるのは、Zilong Wang、Zifeng Wang、Long T. Le らによる論文「Speculative RAG: Enhancing Retrieval Augmented Generation through Drafting」です。2024年7月11日に arXiv で公開され、その後 ICLR 2025 採択論文として公開されています。公開元は arXiv / ICLR 2025、研究分野は RAG、検索拡張生成、LLM 推論設計です。URL は https://arxiv.org/abs/2407.08223 です。
この論文を選んだ理由は、RAG の改善を「もっと長い文脈を読ませる」「検索を何度もやり直す」方向ではなく、「小さいモデルで候補を並列に作り、大きいモデルは検証だけに集中する」という構造で解いているからです。RAG の実装では精度と速度がしばしばトレードオフになりますが、この論文はその両方に手を入れており、実務への示唆が大きいです。
どんな技術か
Speculative RAG は、RAG の回答生成を1回勝負で行うのではなく、まず小さな専用モデルが複数の「下書き回答」を並列に作り、そのあと大きな汎用モデルが下書きと根拠を見比べて最も信頼できる回答を選ぶ技術です。
通常の RAG では、検索で取ってきた複数文書をまとめて1つの大きなプロンプトに入れ、LLM に一気に読ませます。これは単純ですが、文書数が増えるほど入力が長くなり、速度が落ちやすくなります。さらに、長い文脈の中で重要な証拠をうまく拾えず、いわゆる lost-in-the-middle のような問題も起きやすいです。
Speculative RAG はここを分解します。検索結果を複数の視点に分け、各視点を使って軽量な RAG drafter が短いコンテキストから回答候補と理由文を生成します。その後、より強い generalist LM が「どの候補が最も筋が通っているか」を採点して採用します。要するに、「全文書を1回で全部理解させる」のではなく、「小分けに理解してから検証で統合する」方式です。
課題
この技術が解決しようとしているのは、RAG における長文入力の重さと、長文を読んでも必ずしも正しく推論できないという問題です。
何が難しいのかというと、知識集約型の質問ほど、必要な証拠が複数文書に分散しやすいからです。安全側に倒すなら多めの文書を検索して全部読ませたくなりますが、そのぶん入力トークンが増え、推論コストとレイテンシが悪化します。しかも文書が多いほど、重要でない情報や重複文書も混ざりやすくなります。
既存の方法ではどこに限界があるのかというと、標準的な RAG は「全部読ませる」ので遅くなりやすく、Self-RAG や CRAG のような改良手法は追加の instruction tuning や反復処理が必要になりがちです。つまり、精度を上げようとすると構成が重くなり、速度を優先すると根拠の扱いが雑になりやすいわけです。
なぜこの課題を解く必要があるのかというと、実際の RAG アプリでは検索対象が社内文書、FAQ、ナレッジベース、Web、ログなどに広がり、1回の問い合わせで読む文書量が増えやすいからです。質問応答だけでなく、社内検索、カスタマーサポート、規約照会、医療文献確認、複数資料の照合などでは、精度だけでなく応答速度も UX とコストに直結します。
実際の AI システムでは、複数候補から答えを絞る場面や、長い文書群から短く正確な根拠を抽出したい場面で問題になります。たとえば問い合わせ回答支援、RAG ベースの社内アシスタント、調査エージェント、規制文書 QA のような用途では、この課題はかなり現実的です。
用語解説
- RAG（Retrieval-Augmented Generation）
- 外部検索で得た文書をもとに LLM が回答する仕組みです。Speculative RAG は、この基本形をそのまま強化するのではなく、回答生成と検証を役割分担させて効率化します。
- Speculative Decoding
- 小さいモデルで先に候補を作り、大きいモデルで確認する高速化手法です。Speculative RAG はこの考え方をトークン単位ではなく「回答候補単位」に持ち込んでいる点が重要です。
- lost-in-the-middle
- 長い文脈を与えると、中間付近の重要情報をモデルがうまく使えなくなる現象です。この論文では、1つの長い文脈をそのまま読ませず、短い文書サブセットに分けて扱うことで影響を減らそうとしています。
- Rationale
- 回答候補を支える短い理由文です。Speculative RAG では、この理由文が verifier にとっての圧縮済み根拠になり、元の長い文書を全部読まなくても候補の良し悪しを判断しやすくなります。
- Multi-perspective Sampling
- 検索文書を似た内容ごとにクラスタリングし、各クラスタから1文書ずつ選んで多様なサブセットを作る方法です。重複だらけの候補を避けつつ、異なる観点を含む下書きを作るために重要です。
技術の仕組み
Speculative RAG のコアは、「検索結果をどう分けるか」「下書きをどう作るか」「どの下書きを採用するか」の3段階にあります。
基本アイデア
普通の RAG は、検索結果を1つの大きな入力として LLM に渡します。Speculative RAG はそうせず、検索結果を複数の小さな文書集合に分け、それぞれから別々の回答候補を生成します。候補は並列に作られるため、入力を短く保ちながら複数の推論パスを同時に試せます。
そのうえで、最後に強いモデルが候補群を比較して最終回答を決めます。これは、1つのモデルに全部を読ませて全部を考えさせる方式より、役割分担が明確です。小さいモデルは「証拠から候補を作る」、大きいモデルは「候補を検証する」という分担です。
検索結果をクラスタリングして文書サブセットを作る
まず検索で得た文書集合を、その質問に対する内容の近さでクラスタリングします。論文では instruction-aware な埋め込みモデルを使い、K-Means で文書をいくつかのクラスタに分けています。
ここで重要なのは、各クラスタが検索結果の1つの観点を表すことです。たとえば同じ質問でも、背景説明、直接証拠、周辺情報、別表現の証拠が混ざっていることがあります。そこで各クラスタから1件ずつ文書を取り、重複を減らしながら多様な文書サブセットを作ります。
この multi-perspective sampling によって、すべて似た文書ばかり読んで同じ候補を量産するのを避けています。RAG では「関連文書を多く取る」だけだと冗長性が増えやすいので、この工夫はかなり実務的です。
Specialist RAG Drafter が並列に下書きと理由を書く
次に、小さな専用モデルである MDrafter が、各文書サブセットごとに回答候補と rationale を生成します。論文では Mistral 7B ベースのモデルを RAG 専用に instruction tuning し、回答だけでなく「なぜその回答になるか」という短い理由も一緒に出すようにしています。
ここがこの論文の大きな肝です。単に複数の候補を作るだけではなく、候補ごとに理由を持たせることで、後段の verifier は元の長い文書を全部読む代わりに、その候補の圧縮された根拠を見て判定できます。つまり rationale は説明文であると同時に、検証用の情報圧縮でもあります。
論文では、回答候補と rationale を生成する確率も ρDraft として保持しています。これは drafter 自身が「どれくらい自然にその候補を出せたか」の指標になっています。
Generalist RAG Verifier が採点する
下書き生成の後は、大きな汎用モデル MVerifier が各候補を採点します。ここでは追加の fine-tuning は不要で、既存の汎用 LLM の言語モデリング能力を使って候補の一貫性を測ります。
論文では主に2種類のスコアを使っています。
自己整合性スコア
1つ目は ρSelf-contain = P(α, β | Q) です。質問 Q に対して、回答候補 α と rationale β の組み合わせがどれくらい自然で自己整合的かを測るスコアです。回答と理由のつながりが弱い候補は、ここで不利になります。
自己反省スコア
2つ目は ρSelf-reflect = P("Yes" | Q, α, β, R) です。ここで R は「この rationale は回答を支持しているか」のような自己確認文です。モデルに yes/no 的な判定をさせ、その “Yes” の尤度を信頼度として使います。
要するに verifier は、「この回答と理由は自然につながっているか」「理由は本当に回答を支えていそうか」を確率的に評価しています。最終的な候補スコアは ρDraft × ρSelf-contain × ρSelf-reflect の形でまとめられ、最も高い候補が採用されます。
元文書ではなく rationale を使う意味
論文では、verifier に元の文書を渡す代わりに rationale を渡しても性能を保ちやすく、しかも速いことを示しています。TriviaQA では取得文書の平均トークン数が 357.04 に対して rationale は 41.42、PubHealth でも 272.11 に対して 34.94 と大きく短くなっています。
つまりこの手法は、「長い検索結果を短い検証素材に圧縮してから大きいモデルに渡す」構造になっています。これは RAG を高速化したいときの設計原則としてかなり強いです。
実験と結果
論文では、Speculative RAG が本当に精度と速度の両方で有利かを、自由記述 QA と閉集合タスクの両方で検証しています。
何を検証したのか
主な検証点は3つです。1つ目は、標準的な RAG や Self-RAG、CRAG より精度が上がるかです。2つ目は、入力文書を分割して複数下書きを作る構成がレイテンシ改善につながるかです。3つ目は、クラスタリングやスコアリングの各要素が本当に効いているかです。
データセットと評価指標
評価には TriviaQA、MuSiQue、PopQA、PubHealth、ARC-Challenge が使われています。TriviaQA、MuSiQue、PopQA は自由記述型 QA、PubHealth は医療クレームの真偽判定、ARC-Challenge は科学問題の多肢選択です。論文では主に accuracy を評価指標として使い、レイテンシも別途測定しています。
主要ベースラインを全データセットで上回った
最も強い構成である MVerifier-8x7B + MDrafter-7B は、5つのベンチマークすべてで有力ベースラインを上回りました。具体的には TriviaQA 74.24、MuSiQue 31.57、PopQA 57.54、PubHealth 76.60、ARC-Challenge 80.55 を記録しています。
比較対象として強い標準 RAG の Mixtral-Instruct8x7B は、それぞれ 73.91、29.42、53.68、63.63、78.41 でした。差分で見ると、TriviaQA で 0.33 ポイント、MuSiQue で 2.15 ポイント、PopQA で 3.86 ポイント、PubHealth で 12.97 ポイント、ARC-Challenge で 2.14 ポイント改善しています。特に PubHealth の伸びが大きく、根拠ベースで真偽を判断するタスクでこの構成が効いていることがわかります。
レイテンシも改善した
速度面でも改善が確認されています。論文では 100 サンプルを用いて平均レイテンシを測定し、MVerifier-8x7B + MDrafter-7B の Speculative RAG が競争力の高い標準 RAG より短時間で動くことを示しています。
標準 RAG と比べたレイテンシ削減率は、TriviaQA で 11.90%、MuSiQue で 15.07%、PopQA で 44.31%、PubHealth で 50.83%、ARC-Challenge で 22.77% でした。精度が上がっているだけでなく、入力を小分けにして並列化した効果がそのまま処理時間に出ています。
rationale を使った検証は、元文書を直接読むより効率がよい
TriviaQA と PubHealth では、verifier に rationale だけを渡す方法と、元文書を渡す方法も比較しています。TriviaQA では rationale ベースで accuracy 74.24、latency 1.93 秒、元文書ベースでは accuracy 74.08、latency 2.13 秒でした。PubHealth でも rationale ベースが 76.60、1.17 秒、元文書ベースが 76.09、1.31 秒です。
この結果から、長い文書をそのまま verifier に渡さなくても、drafter が作る短い rationale が十分に役立つことがわかります。RAG の高速化では検索そのものより「検索後に何を大きいモデルへ渡すか」の設計が重要だと読み取れます。
クラスタリングと検証スコアはどちらも効いている
アブレーションでは、文書サブセットをランダムに作ると TriviaQA で 1.22 ポイント、PubHealth で 1.22 ポイント低下し、同じクラスタからばかり取ると TriviaQA で 1.88 ポイント、PubHealth で 2.23 ポイント低下しました。つまり、多様な観点を確保するサンプリングが効いています。
また、検証なしでランダムに候補を選ぶと TriviaQA で 5.69 ポイント、PubHealth で 5.37 ポイント落ちています。これは「複数候補を作るだけ」では不十分で、最後の verifier がかなり重要だということです。
何に使える？
Speculative RAG の価値は、長い検索結果をそのまま大きいモデルに食べさせない設計にあります。これは実務のいろいろな RAG 系アプリに広く応用できます。
社内ナレッジ検索アシスタント
社内ドキュメント、議事録、仕様書、FAQ のように、似た内容の文書が大量にヒットする環境では相性がよいです。検索結果をそのまま詰め込むと冗長になりますが、Speculative RAG 的に観点を分けて候補を作ると、回答の軸が整理されやすくなります。
サポート業務やヘルプデスク
問い合わせ対応では、関連ナレッジが複数ページにまたがることが多いです。下書き候補を複数作って verifier で選ぶ方式にすると、1本の曖昧な回答に賭けるより安定しやすいです。誤答コストが高い領域ほど向いています。
医療・法務・規制文書の確認支援
PubHealth での改善幅が大きかったことからも分かる通り、「根拠に基づく真偽判定」や「文書をもとに主張を確認する」用途に向いています。もちろん実運用では人間確認が前提ですが、候補生成と根拠要約の段階をかなり整理できます。
調査エージェントや比較系ワークフロー
製品比較、競合調査、リサーチ支援のように、複数の資料を読みながら候補を絞るタスクにも向いています。下書きを複数視点で出す設計は、最終回答を1本化する前に論点の取りこぼしを減らしやすいです。
小型モデルと大型モデルの協調設計
この論文の発想は RAG に閉じません。小さいモデルで安く候補を作り、大きいモデルで高価な判断だけ行うという役割分担は、検索、要約、エージェント、ワークフロー自動化でも応用できます。これは論文の直接評価ではありませんが、構造上かなり自然な展開です。
開発や事業へのヒント
この論文から得られるヒントは、RAG の改善を「検索精度を上げる」か「もっと強い LLM を使う」だけで考えないことです。検索後の処理構造にも大きな改善余地があります。
全文書を大モデルに読ませる前提を疑う
多くの RAG 実装は、検索文書を並べてそのまま回答生成に入ります。しかし論文は、長い文脈を直接読ませるより、一度小さいモデルで圧縮してから大きいモデルに渡すほうがうまくいく場面があることを示しています。これはコスト設計にも効きます。
RAG の本質を「候補生成と候補選別」に分ける
RAG を1段の処理として見るのではなく、「候補をどう作るか」と「どれを採用するか」に分解すると設計の自由度が増えます。特に業務システムでは、候補生成は安価なモデル、最終判定は高性能モデルという構成が取りやすいです。
検索結果の多様性を明示的に扱う
実務では検索上位文書が似通うことが多く、それが回答の偏りにつながります。Speculative RAG の multi-perspective sampling は、rerank や dedup とは少し違い、「異なる観点を残したまま候補を作る」考え方です。比較や調査の質を上げたいプロダクトでは、この発想だけでも取り入れる価値があります。
小規模プロダクトでも部分導入しやすい
論文通りに専用 drafter を学習しなくても、まずは「検索結果をクラスタ分割する」「各クラスタから要約候補を出す」「最後に1つ選ぶ」という段階構成から試せます。小規模な SaaS や社内ツールでも、レイテンシと精度の両面で効果が出る可能性があります。
今後注目したい方向性
今後は、RAG の改善が retrieval、compression、verification、routing の組み合わせ問題として進みそうです。Speculative RAG はその中で、生成前に全部を一発で解こうとせず、候補生成と検証を分ける方向が有効だと示しています。エージェント的な複雑なワークフローにもつながる考え方です。
限界
まず、この手法は単なるプロンプト変更ではなく、専用の drafter モデルと並列実行構成を前提にしています。したがって、標準的なシンプル RAG より実装は複雑です。複数エンドポイント、文書クラスタリング、候補採点ロジックまで含めて設計する必要があります。
次に、drafter の品質にかなり依存します。論文では instruction tuning した MDrafter を使っており、この部分が弱いと良い候補自体が出ません。つまり verifier が強くても、下書き候補の母集団が悪ければ改善幅は小さくなります。
また、論文の主評価は QA や真偽判定ベンチマークが中心で、企業内の複雑な文書体系、表や図を含む文書、マルチモーダル検索、長い対話履歴込みの RAG で同じように効くかはまだ別途検証が必要です。
推論速度についても、並列化の前提が必要です。drafter を複数本立てて同時実行できる環境なら強いですが、単一 GPU や厳しいリソース制約では論文通りの速度改善が出ない可能性があります。
さらに、最終選択が尤度ベースなので、常に事実性の高い答えを保証するわけではありません。候補比較の改善には効きますが、検索失敗そのものや根拠文書の欠落を完全に解決する技術ではありません。
よくある質問
Q. Speculative RAG は speculative decoding と同じものですか？
A. 同じではありません。発想は似ていますが、speculative decoding はトークン列を先読みして検証する技術です。Speculative RAG はそれを RAG の回答候補レベルに拡張し、複数の答えの下書きを並列生成して検証します。
Q. 普通の RAG より、なぜ速くなるのですか？
A. 大きいモデルが長い検索文書全部を直接読む代わりに、小さいモデルが短い文書サブセットから候補と理由を作るからです。大きいモデルは圧縮済みの rationale を見て候補を選ぶだけなので、処理量が減ります。さらに下書き生成を並列化できる点も効きます。
Q. 既存の RAG システムにそのまま入れられますか？
A. 完全にそのままではありませんが、段階的な導入は可能です。まずは検索文書をクラスタ分割し、複数候補を作って rerank する構成から試せます。論文通りの性能を狙うなら、RAG 専用 drafter の学習や verifier の採点実装が必要です。
Q. どんなタスクで特に効果が出やすいですか？
A. 複数文書から根拠を整理して答えるタスクです。特に、検索結果が長い、重複が多い、複数の観点が混ざるといった条件で効きやすいです。論文では PubHealth のような根拠ベースの真偽判定で大きな改善が出ています。
Q. 検索精度が低い場合でも効果はありますか？
A. ある程度はありますが、限界があります。この手法は「取得した文書群からどう良い候補を作って選ぶか」を改善する技術なので、そもそも必要な証拠が検索で取れていない場合は改善しきれません。検索品質と組み合わせて使うのが前提です。
今日の学び
この論文は、RAG が長い検索結果を抱え込むことで遅くなり、しかも推論が不安定になりやすいという課題を扱っています。
それに対して、検索結果を視点ごとに分け、小さな専用モデルで複数の下書きと理由を作り、大きなモデルで検証して選ぶという構造で解こうとしました。
そこから得られるヒントは、RAG の改善は検索精度やモデルサイズだけの問題ではなく、検索後の情報圧縮と候補選別の設計でも大きく変わるということです。特に実務では、「全部を一度に読ませる」のではなく、「小さく分けてから強いモデルで選ぶ」発想が使えそうです。