非エンジニアでもわかる REFRAG｜RAGを“最短で賢く”するMetaの新手法

2025.09.25AI 検索拡張（RAG）

1. REFRAGとは？一言でいうと

REFRAG（REpresentation For RAG）は、RAG（検索拡張生成）で「関連文書をそのまま長いテキストとして LLM に渡す」という常識を見直し、“文書＝たくさんのトークン”ではなく、“文書＝圧縮されたチャンク埋め込み（ベクトル）”として与えることで、応答の初速（TTFT: Time To First Token）やメモリ使用量を大幅に改善する手法です。論文では最大約 30.75 倍の TTFT 短縮を報告し、モデル改造なし・デコーダに新パラメータ追加なしで実現できる点も強調されています。

通常の RAG は「検索 →（長文）コンテキストを LLM に付与 → 生成」という流れですが、REFRAG は検索で得た各チャンクを事前にベクトル化し、それ自体をデコーダ入力として活用。必要に応じて軽量な強化学習（RL）ポリシーで“どのチャンクだけは生のトークンに戻すか”を選ぶため、速度と精度の両立が可能になります。

2. なぜ速い？仕組みをやさしく分解

2-1. “長い文章”を“短いベクトル列”へ置き換える

ポイントは入力の長さを劇的に短くすること。従来の RAG では、検索で見つかった複数の文書（数千〜数万トークン）がそのまま LLM に渡され、注意（Attention）計算が重くなるのがボトルネックでした。
REFRAG は、チャンク（例：16 トークン単位）ごとに圧縮した埋め込みを入力として使うため、入力列が短くなり、計算が軽くなるのです。しかも検索時にすでに計算している埋め込みを再利用できるため、重複計算を削減できます。

2-2. 必要なところだけ“原文トークン”に戻す

とはいえ、すべてをベクトルのままにすると細部のニュアンスを取りこぼす心配があります。そこで REFRAG は軽量な RL ポリシーを用い、重要なチャンクだけは生のトークンに“展開（expand）” 。
この“圧縮 → 感知 → 必要箇所だけ展開”の流れが、速さと正確さのバランスを生みます。研究ではこの方針により長い文脈でも遅延やメモリを抑制し、既存手法比で大幅な TTFT 改善が示されています。

2-3. システム全体で無駄を削る発想

論文は、RAG の遅さは「LLM が遅い」だけではなく、RAG の文脈には不要な計算が多いことに起因すると指摘します。重複チャンク、無関係チャンク、すでに検索で得た相関情報の使い回しなどをうまく活用すれば、推論全体を細やかに最適化できる――この発想が REFRAG の根底にあります。

補足として、日本語の解説記事でもRAG を最大 30 倍高速化というポイントや、ベクトルのままデコーダに注入という直観がわかりやすく紹介されています。初学者向けの導入として参考になります。

3. 従来のRAGや近縁手法との比較

表は“キーワード・数値中心”。長文の説明は本文で補います。

観点	従来 RAG（全文テキスト投入）	トークン圧縮系（例：既存要約・固定圧縮）	REFRAG
入力	長いトークン列	短縮したトークン列	チャンク埋め込み＋必要箇所のみトークン展開
速度（TTFT）	重い	改善	大幅改善（最大約 30.75×）
精度	高〜中	場合により劣化	RL で重要部分を展開し維持
メモリ	大	中	小（入力列が短い）
再利用	低（毎回再計算）	中	高（検索の埋め込みを活用）
モデル改造	不要	追加実装あり	LLM 側改造なし

TTFT の改善幅や設計要点は論文記載に基づく要約です。

4. ビジネスで効くユースケース

✅ カスタマーサポートの即応性向上

FAQ やログが増えるほど RAG のコンテキストは長くなりがち。REFRAG なら必要な情報を要領よく読み込むため、待ち時間を感じさせない対話が実現しやすくなります。問い合わせ急増時のスケール耐性も向上。

✅ 知識経営・社内検索（ナレッジベース）

ガイドライン、議事録、手順書など長大コンテンツを扱うときに効果的。要点だけを展開できるため、的確さを保ったまま高速回答が可能。現場の意思決定スピードが上がります。

✅ 要約・レポート生成（超長文対応）

長い文書を圧縮ベクトル → 必要部だけ原文で処理できるので、長文 × 大量でも遅延・コストを抑制。マネジメント向けレポートや契約書要約などで業務リードタイム短縮に寄与。

✅ マルチターンのエージェント実行

会話が続いて文脈が肥大化する場面でも、圧縮＋選択的展開でスムーズな継続対話を実現。論文はオートレグレッシブ（逐次生成）特性を保ったまま任意位置で圧縮を適用できる設計を示しています。

5. 導入時のチェックポイント

検索パイプラインとの連携：既存のベクトル DB や再ランキングの埋め込み再利用が鍵。キャッシュ戦略と合わせてレイテンシを詰めましょう。
チャンク設計：チャンク長（例：16 トークン単位）と圧縮率 kは精度・速度のトレードオフ。まずは短いチャンク＋重要箇所の展開から。
RL ポリシーの閾値：どこまで展開するかはユースケース依存。事実重視の応答では展開多め、速報性重視なら圧縮寄り、など運用ポリシーを設計。
評価指標：TTFT/TTIT/スループットの 3 点で体感速度を定量評価。品質は正答率・引用整合性で併用チェック。論文の測定軸もこの 3 指標です。

6. 今後の展望とまとめ

REFRAG は、「検索で得た情報は毎回フルテキストで渡すもの」という前提を崩し、表現（Representation）で渡すという発想に転換しました。これにより長文コンテキストの計算負荷を本質的に圧縮し、最大約 30.75× の初速改善を実証しています。しかもLLM アーキテクチャをいじらない実装方針で、RAG の現場にそのまま持ち込みやすい。

🔚 まとめ