REFRAGとは？MetaのRAG高速化論文の仕組みと「30倍」の条件・実装の現状

REFRAG（リフラグ）は、Meta Superintelligence Labsが2025年9月にarXivで公開した、RAG（検索拡張生成）の応答を速くするデコード手法です。検索で取ってきた文書をそのままトークンとしてLLMへ入れず、16トークン前後のかたまりごとに小さなエンコーダーで1本のベクトルへ圧縮して渡します。論文の見出し数字は「最初のトークンが出るまでの時間（TTFT）が30.85倍速い」です。この記事では、その数字がどの条件で測られたのか、どんな学習が要るのか、2026年11月時点で手元のRAGに組み込めるのかを、論文本文（arXiv v2）から確かめた範囲で整理します。

まとめ：REFRAGの要点と実務での扱い

• 正体：論文「REFRAG: Rethinking RAG based Decoding」（arXiv 2509.01092）。名称は REpresentation For RAG の略で、製品やライブラリではありません。
• 30.85倍の条件：LLaMA-2-7B比のTTFTで、圧縮率k=32の設定です。k=16・文脈16,384トークンでは16.53倍、チャンク埋め込みを事前計算しない場合は8.59倍まで下がります。
• 仕組み：検索文書をkトークンずつに区切ってRoBERTaで埋め込み化し、強化学習（RL）の方策が「圧縮のままでは困るチャンク」だけを元のトークンに戻します。
• 導入の重さ：LLMの構造は変えませんが、デコーダーの継続事前学習と用途別のファインチューニングが必要です。論文は8ノード×H100 8枚で学習しています。
• 公開状況：論文が予告した公式リポジトリ（facebookresearch/refrag）は2026年11月7日時点でも404です。非公式の再実装は公開されていますが、この記事で確認したものはいずれも、論文と同じ条件で性能を再現した結果を示していません。
• 後続研究：同じ「圧縮して必要な所だけ展開する」考え方を画像文書のRAGに当てたDoc-REFRAGが、EMNLP 2026の本会議に採択されています。
• 使えない場面：GPTやClaudeをAPIで呼ぶRAGでは使えません。API側が埋め込みベクトルを入力として受け付けないためです。

以下、数字の読み方、仕組み、学習レシピ、他手法との違い、実装と後続研究、採用判断の順に説明します。

REFRAGの概要：論文の出自と発表状況

原典はarXiv 2509.01092で、本文の数値は2025年10月のv2によります。倍率は第4節と付録A・B.5、学習レシピは第3節と付録B.2が該当箇所です。REFRAGはMeta Superintelligence Labsの研究で、シンガポール国立大学とライス大学の研究者が共著に入っています。

学会発表は本会議ではなく、NeurIPS 2025の「Workshop on Multi-Turn Interactions in Large Language Models」のポスターです。v2の改訂理由は「perplexity を log perplexity に訂正」と「最近の論文の追加」で、手法や主要な倍率は変わっていません。ただし、精度の指標がパープレキシティそのものではなく対数パープレキシティだと読み替える必要があります。

「refrag」で検索すると、FPSゲーム用語の「リフラグ（味方を倒した敵をすぐ倒し返すこと）」や、CS2の練習ツール「Refrag」が出てきます。これらはMetaのREFRAGとは無関係です。

「30倍高速化」の中身：倍率の測定条件

REFRAGの倍率は、どの指標を、どの圧縮率で、どの基準と比べたかで大きく変わります。「30倍」が何の指標を指すかを確認できるよう、比較対象・圧縮率・キャッシュの条件を並べます。

前提として、論文の序論は、プロンプトが長くなるとTTFTは長さの2乗で、2トークン目以降を1つずつ出す時間（TTIT）は長さに比例して伸びると整理しています。入力を縮める手法の効果がTTFTに大きく出て、生成全体には小さく出るのはこのためです。

TTFT・スループットの倍率と圧縮率kの関係

k=16のTTFTの行は文脈長16,384トークンでの測定です。システム性能の測定環境はA100 1枚・バッチサイズ1で、学習環境とは異なります。CEPEは2024年に発表された長文脈向けの先行手法で、論文はREFRAGの主な比較相手としています。論文はk=16でCEPEに対して平均9.3%の改善を報告していますが、この割合は文脈なしモデルと全文脈モデルの差で正規化した指標に基づきます。対数パープレキシティ自体の単純な減少率ではありません。k=32ではCEPEと同水準でした。文脈長の16倍は、もともと4,096トークンまでのLLaMA-2-7Bに、圧縮によってその16倍の文脈を入れられるという意味です。

読み取るべき点は3つあります。まず、30倍台はk=32（32トークンを1ベクトルにする）設定の値で、k=16では16倍台です。付録の図8の実測ではk=32で32.99倍という値も出ています。次に「キャッシュあり」は、チャンク埋め込みを索引作成時に計算しておいた前提で、質問のたびに計算し直すと倍率はほぼ半分になります。最後に、速くなるのは主に最初のトークンが出るまでの時間で、回答全体を書き終えるまでの時間が30分の1になるわけではありません。スループットの改善は最大6.78倍です。

なお、要旨は30.85倍、序論は30.75倍と、同じ論文の中で値が一致していません。引用するときは要旨の30.85倍を使い、測定条件を添えるのが安全です。

理論上の上限：短い文脈ではk倍、長い文脈ではk²倍

論文の付録の理論解析では、文脈が短いときの加速はTTFT・スループットとも最大k倍、文脈が長くなると最大k²倍とされています。アテンションの計算量は入力長の2乗に比例するため、入力をk分の1にすると長文脈ほど効きます。逆に、検索文書が数百トークンしかないRAGでは、高速化の余地はもともと小さいということです。

「精度を落とさず」が成り立つ範囲

RAGの評価では、同じ数の検索文書を与えたときREFRAGはLLaMAとほぼ同じ精度で、ランダムに文書を混ぜる「弱い検索器」の設定ではわずかに上回りました。差が出るのは同じ遅延で比べたときです。表3の同遅延比較では、LLaMAに1件、REFRAG（k=8）に8件の文書を与えています。REFRAGはFEVER（62.04→66.59）、TQA（9.64→13.05）、StrategyQA（64.44→75.56）などで上回る一方、NQ（23.96→22.96）やBoolQ（29.24→3.30）では下回りました。文書を増やせばどのタスクでも正答率が上がるわけではありません。k=16・k=32の設定も、デコーダーへの入力が2〜4分の1でありながら、ファインチューニング済みLLaMAを上回りました。

一方で、圧縮率を上げるほど性能は下がります。論文はk=32まではまだ競争力があるとしつつ、k=64は「圧縮しすぎ」で性能が大きく落ちると書いています。上げられる圧縮率には実用上の限界があります。

多ターン会話：ターン数と検索文書数による精度差

論文の5.2節は、検索つきの多ターン会話をTopiOCQA・ORConvQA・QReCCの3データセットで評価しています。ターン数と検索文書を増やすほど、両者の差が開きます。表4のうち、検索文書10件・6ターン以上の行は次のとおりです。

ORConvQAとTopiOCQAでは5ポイント以上の差がつきました。一方、QReCCではk=16がLLaMAを下回り、ほぼ横ばいです。同じ表の2ターン以上・検索文書5件の行ではLLaMAとREFRAGの差は小さく、精度面の利点が大きく出るのは、会話履歴と検索結果を合わせると元の文脈長に収まらない場面です。論文は10件の設定で3データセットとも上回ったとしており（QReCCで上回るのはk=8とk=32）、その理由を、LLaMAの4,096トークンの上限で会話履歴を切り詰めざるを得ないことに求めています。

REFRAGの仕組み：圧縮・選択・展開の3段階

REFRAGは「compress（圧縮）・sense（選択）・expand（展開）」の流れで入力を作ります。質問文はそのままトークンで入れ、検索文書の部分だけを圧縮するのが要点です。

チャンク埋め込みへの圧縮とデコーダーへの入力

検索文書をkトークンずつのチャンクに区切り、RoBERTa（主要な比較ではRoBERTa-Large）が各チャンクを1本の埋め込みに変換します。その埋め込みを2層のMLP（射影層）でデコーダーのトークン埋め込みと同じ次元（LLaMA-2-7Bなら4,096）に揃え、質問のトークン埋め込みと並べてデコーダーへ入れます。デコーダーから見ると、k個のトークンがあった場所に1つの「圧縮トークン」が置かれた状態です。

圧縮が効く理由として、論文はRAGのアテンションの偏りを挙げています。検索で集めた文書どうしは内容の重なりが少なく、文書をまたぐアテンションはほぼゼロになる（ブロック対角になる）ため、文書内の細部まで全トークンで計算するのは大半が無駄だという主張です。入力長を短縮すると、プリフィル時の自己アテンション計算量は概ね入力長の2乗に応じて、入力分のKVキャッシュ量は入力長に応じて減ります。KVキャッシュの仕組みはKVキャッシュによるLLM推論の高速化とメモリ削減で解説しています。

RL方策による選択的展開と実効圧縮率

すべてを圧縮すると、数値や固有名詞のような細部が落ちる恐れがあります。そこで軽量なRL方策（チャンク埋め込みを入力とする2層のTransformer）が、元のトークンに戻す（展開する）チャンクを予算内で1つずつ選びます。展開の割合をpとすると、論文の実効圧縮率は k ÷ (1 − p + k × p) です。論文の比較では、RL方策で選ぶほうが、パープレキシティの高低で選ぶヒューリスティックやランダム選択より対数パープレキシティが低くなりました。

この式から、展開を少し増やすだけで圧縮率が大きく下がることが分かります。質問256トークン・文脈16,384トークンで計算すると次のとおりです（Python 3で実行確認済み）。この例は文脈長がkで割り切れる前提です。入力長は展開チャンク数を整数に丸め、実効圧縮率は質問を除く文脈について丸め前のpから計算しています。

def decoder_positions(q, s, k, p):
    """質問qトークン・文脈sトークンをチャンク長kで圧縮し、割合pのチャンクだけ展開したときのデコーダー入力長"""
    chunks = s // k
    expanded = round(chunks * p)
    return q + (chunks - expanded) + expanded * k

def effective_rate(k, p):
    """論文の実効圧縮率 k / (1 - p + k*p)"""
    return k / (1 - p + k * p)

q, s = 256, 16384
for k in (8, 16, 32):
    for p in (0.0, 0.1, 0.25):
        n = decoder_positions(q, s, k, p)
        print(f"k={k:2d} p={p:.2f} 入力長={n:6d} 実効圧縮率={effective_rate(k, p):5.2f}")

出力の抜粋です。

k=16 p=0.00 入力長=  1280 実効圧縮率=16.00
k=16 p=0.10 入力長=  2810 実効圧縮率= 6.40
k=16 p=0.25 入力長=  5120 実効圧縮率= 3.37
k=32 p=0.10 入力長=  2349 実効圧縮率= 7.80

k=16でもチャンクの1割を展開すれば実効圧縮率は6.4倍、4分の1を展開すれば3.37倍です。k=32に上げても1割展開で7.8倍にとどまります。精度のために展開を増やすほど、速度の取り分は急速に減ります。チャンクの大きさとトークン数の関係はチャンクとトークンの違いとチャンク分割のサイズ設計も参考になります。

REFRAGの学習レシピ：再構成タスクから用途別SFTまで

論文は「LLMの構造を変えず、デコーダーに新しいパラメータも足さない」と書いています。これは「手元のLLMにそのまま差し込める」という意味ではありません。エンコーダーの出力をデコーダーが読めるようにするため、次の3段階の学習が要ります。

1. 再構成タスク：デコーダーを凍結し、エンコーダーと射影層だけを学習します。圧縮した埋め込みからデコーダーが元のトークンを復元できるように揃える段階です。
2. 継続事前学習（CPT）：デコーダーの凍結を解き、前半の文章を圧縮して入れ、続きの段落を予測させます。データはSlimPajamaのうち長文の多いBookとArXivの部分です。
3. 用途別のSFT：RAG・多ターン会話・長文要約などの用途ごとにファインチューニングします。RAG用は5分野の質問応答データ約110万件です。

再構成タスクには、短い復元から始めて徐々に長くするカリキュラム学習が欠かせないと論文は示しています。16トークンの復元での対数パープレキシティは、カリキュラムなしで3.719、ありで0.669でした。学習はbfloat16・FSDPで、8ノード×H100 8枚の環境です。

つまり、REFRAGを使うにはデコーダーの重みを自分で継続学習できることが前提になります。デコーダーの重みと埋め込み入力を制御できるモデル、追加学習の計算資源が必要です。ただし、論文のH100複数ノード構成は実験環境であり、導入に必要な最小構成を示すものではありません。

従来RAG・長文脈の高速化手法との違い

REFRAGは長い入力を速く処理する手法の一つです。論文の関連研究の節が挙げる手法と、何を減らすかで比べると次のようになります。

CEPEとの違いは、圧縮した文脈を入力のどこにでも置けるかどうかです。CEPEはクロスアテンションで文脈を読むため因果構造が崩れ、多ターンのRAGや要約には向かないと論文は指摘しています。REFRAGは圧縮トークンを通常の入力列に並べるので、会話の途中に検索結果を差し込めます。LLMLinguaのようなプロンプト圧縮はテキストのまま削るので、どのLLMにも使えます。その代わり削った情報は戻せません。

実務で今すぐ使える高速化は、REFRAGとは別の層にあります。生成側を速くするSpeculative Decoding（投機的デコーディング）や、推論基盤全体の選び方を扱ったLLM推論の仕組みと高速化の手法も合わせて比較してください。

REFRAGの実装状況と後続研究（2026年11月時点）

公式コードと学習済み重みの公開状況

論文の冒頭には「Code: Will be available at https://github.com/facebookresearch/refrag」とありますが、このリポジトリは2026年11月7日時点でもGitHub APIから404が返り、公開されていません。arXivの版もv2（2025年10月12日）のままで、Hugging Faceで「refrag」を検索しても、Metaが配布する学習済みの重みは見つかりません。論文公開から1年以上たった今も、論文の数値を手元で再現する公式の手段はありません。

非公式の再実装と同名の別プロジェクト

GitHubで「refrag」を検索すると再実装がいくつか見つかります。非公式実装の一例はsimulanics/REFRAG（MITライセンス・2025年9月10日作成・最終pushは2025年12月26日（いずれもUTC））で、1ファイルの refrag.py に検索・エンコーダーと射影層・選択的展開・CPT・生成が入っています。READMEは論文の最初の11ページの構成を再現したと説明しており、展開の選択にはRL方策のほか、パープレキシティによるヒューリスティックの代替経路も用意されています。論文の倍率や精度を再現したものではありません。

名前が同じでも中身が違うリポジトリがある点にも注意が必要です。Shaivpidadi/refrag は、論文のようにベクトル空間で圧縮するのではなくテキストのまま圧縮し、展開の選択もRLではなくヒューリスティックで行う独自実装です。marcusjihansson/dspy-refrag は REFRAG を「Retrieval-Enhanced Fine-Grained Retrieval Augmented Generation」と別の語で展開しています。導入前には出典だけでなく、埋め込みをデコーダーへ直接入力するか、デコーダーの追加学習とRL方策を実装しているか、再現実験の条件と結果があるかを確認してください。

後続研究Doc-REFRAG：画像文書RAGへの応用

REFRAGの名前と考え方を引き継いだ研究に、Doc-REFRAG（arXiv 2608.30163）があります。2026年8月31日に公開され、arXivのコメント欄には「Accepted by EMNLP 2026 Main」とあります。著者はRuofan Huら8名で、REFRAGの著者とは重なりません。

対象はテキストではなく、PDFやスキャンなど画像になった文書を検索して答えるマルチモーダルRAGです。公式リポジトリのREADMEによると、文書画像1枚を324個の視覚トークンにし、連続する3トークンを2層のMLPで1つのチャンク埋め込みへ圧縮します。そのうえで質問に関係するチャンクだけを、強化学習（GRPO）で学習した選択器が元の解像度に戻します。学習は単一画像の再構成、複数画像での継続事前学習、選択器の学習の3段階で、REFRAGの学習レシピとほぼ同じ形です。論文は1問あたり平均37.4枚の画像を検索したQA 34.3万件のデータセットDocLongRAGを作り、6つのベンチマークで11の比較手法を精度で上回り、推論の遅延も短かったと報告しています。

REFRAG本体と違い、こちらはMITライセンスでコードが公開されています。ただし2026年11月7日時点で公開されているのは、ランダム初期化の小さなモデルでCPU上で流れを確かめられる参照実装までです。READMEの公開予定には、DocLongRAGデータセット、学習済みチェックポイント、論文で使ったDocOwl2用のアダプタ、評価スクリプトが未完了のまま並んでいます。論文の精度を手元で出せる状態ではありません。

REFRAGの採用判断：効く条件と効かない条件

結論から言うと、2026年11月時点で一般的な業務RAGにREFRAGを組み込む理由はほとんどありません。論文の価値は、手法の考え方と「検索文書は全トークンで読まなくてよい」という知見にあります。

REFRAGの採用検討を優先しやすいのは、次の条件がそろう場合です。

• オープンウェイトのLLMを自社で継続事前学習・SFTできる（GPU予算と学習基盤がある）
• 1回の質問で数千〜数万トークンの検索文書を入れており、TTFTがボトルネックになっている
• 文書の更新頻度が低く、チャンク埋め込みを索引作成時に計算して保存できる

次の場合は採用すべきではありません。

• GPT・Claude・GeminiをAPIで呼んでいる：API側に埋め込みベクトルを直接入れる手段がないため、仕組み上使えません。
• 検索文書が短い：数百トークン程度なら理論上の加速はk倍が上限です。その入力ですでに遅延目標を満たしているなら、追加学習を伴うREFRAGを優先する理由はありません。
• 再計算込みでは遅延目標を満たせない：k=16・文脈16,384トークンでは、キャッシュなしのTTFT高速化は8.59倍です。更新頻度だけで不採用とせず、再計算を含めた遅延で判断します。
• 条文番号や金額など一字一句の正確さが要る：圧縮されたチャンクの細部は、展開されない限り元の文字列としては読まれません。展開を増やすほど圧縮による速度の利点は小さくなるため、原文照合を含む精度評価と遅延測定が必要です。

API型のRAGで遅延を減らしたいなら、まず検索件数とチャンクの大きさを見直し、リランクで入力を絞るのが先です。検索件数・チャンク設計・リランクの組み合わせを自社データで決める作業は、RAG構築支援でも扱っています。文書を詰め込みすぎると中ほどの情報が無視される問題もあり、Lost in the Middle現象とRAG設計での対策で詳しく扱っています。モデルごとの入力上限と有効長の考え方はコンテキストウィンドウのトークン上限と溢れ対策を参照してください。

よくある質問

REFRAGの正式名称と読み方は？

正式名称は REpresentation For RAG で、読み方は「リフラグ」です。RAGは Retrieval-Augmented Generation（リトリーバル・オーグメンテッド・ジェネレーション）の略で、日本語では検索拡張生成と訳されます。

REFRAGのコードはGitHubで公開されている？

公式コードは2026年11月7日時点で未公開です。論文が予告した facebookresearch/refrag は404です。simulanics/REFRAG などの非公式再実装はありますが、論文の数値を再現したものではありません。画像文書向けの後続研究Doc-REFRAGは参照実装を公開していますが、学習済みの重みはまだ配布されていません。

FPSゲームの「refrag」と関係はある？

関係ありません。FPSやCS2で使うrefragは、倒された味方の仇をすぐ取る「トレードキル」を指すゲーム用語です。CS2の練習プラットフォームにも同名の「Refrag」がありますが、MetaのREFRAGとは別物です。

GPTやClaudeのAPIでREFRAGは使える？

使えません。REFRAGは圧縮した埋め込みをデコーダーへ直接入れ、そのためにデコーダーを継続学習します。API経由のモデルは埋め込みを入力として受け付けず、重みも変更できません。

REFRAGのチャンクとトークンの違いは？

トークンはLLMが扱う最小単位で、REFRAGのチャンクはk個（論文では8・16・32）の連続したトークンのかたまりです。REFRAGはチャンク1つを1本の埋め込みに圧縮するので、k=16なら16トークン分の位置が1つになります。RAGの文書分割でいう「チャンク」より小さい単位です。

関連記事

• RAGパイプラインとは？取り込み系と推論系に分ける工程設計と再索引の実装判断
• KVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断を実装者向けに解説【2026年版】
• チャンクとトークンの違いとは？チャンク分割の手法とRAGのサイズ設計を日本語で実測【2026年版】
• Lost in the Middle現象とは｜RAG精度が落ちる仕組みと設計での対策
• コンテキストウィンドウとは？トークン上限の数え方と有効長・溢れ対策を実装者向けに解説