Meta 再出狠招:REFRAG,讓 RAG 長上下文提速 31 倍,還能看 16 倍更多內(nèi)容 原創(chuàng)
過去兩年,大語言模型(LLM)逐漸成為知識工作流的“新大腦”。但凡接觸過 RAG(檢索增強(qiáng)生成) 的人,大概率都遇到過這樣的問題: 文檔越長,推理速度越慢;知識庫一大,延遲直接爆炸。甚至有時候,模型還沒輸出第一個字,用戶耐心就已經(jīng)消耗殆盡。
為什么會這樣?根源在于 長上下文的計算成本。注意力機(jī)制的復(fù)雜度隨著輸入長度是二次增長的——文本翻倍,算力就要漲四倍。對于企業(yè)級應(yīng)用來說,這幾乎等于“不可用”。
這一次,Meta Superintelligence Labs 聯(lián)合新加坡國立大學(xué)、萊斯大學(xué),帶來了一套全新框架——REFRAG(REpresentation For RAG)。它不僅把上下文窗口擴(kuò)展到了 16 倍,還能在生成第一個 token 的時間上做到 31 倍加速,并且?guī)缀醪粻奚鼫?zhǔn)確率。
聽起來是不是很炸裂?接下來我們分幾個部分拆解一下,看看它到底是怎么做到的。
1. 為什么長上下文是 LLM 的死穴?
要理解 REFRAG 的價值,先得弄清楚問題本身。
在 LLM 推理中,注意力機(jī)制是最昂貴的部分。當(dāng)輸入序列從 2K token 增加到 4K token,計算量不是翻倍,而是翻四倍。這導(dǎo)致:
- 推理延遲陡增:用戶體驗直線下降;
- KV 緩存膨脹:顯存占用急劇增加,硬件成本隨之上升;
- 無效計算嚴(yán)重:在 RAG 中,很多被檢索到的段落其實并沒用,但模型依舊要為它們“埋單”。
換句話說,哪怕檢索結(jié)果里只有 20% 的內(nèi)容對答案有價值,其余 80% 的“冗余”依舊會拖慢整個推理過程。
這就是為什么業(yè)界長期以來在追求各種壓縮、裁剪和緩存技術(shù),卻始終沒有一個能同時解決“快”和“準(zhǔn)”的通用方案。
2. REFRAG 的思路:先壓縮,再解碼
REFRAG 的核心創(chuàng)新點在于:重構(gòu)了 RAG 的解碼方式。它不是簡單地縮短輸入,而是通過“表示學(xué)習(xí)”把原始文本壓縮成緊湊的嵌入表示。
具體做法是:
- 分塊:將檢索到的文本切分成固定長度的 token 塊(例如 16 個一組);
- 壓縮:用一個輕量級編碼器把這些塊轉(zhuǎn)化為chunk embedding;
- 替換輸入:原本需要喂給解碼器的幾千上萬 token,現(xiàn)在只需要一小串 embedding;
- 保持架構(gòu)不變:解碼器無需修改,直接接收壓縮后的輸入。
最終效果是:輸入長度直接縮短 16 倍,而模型結(jié)構(gòu)卻不用大改。
這就像原來要把整本書逐字掃描,現(xiàn)在只需提煉成“章節(jié)摘要”,但依然保留關(guān)鍵信息。

3. 加速效果:從 2–8 倍到 31 倍
REFRAG 在加速上幾乎“碾壓”了此前的主流方法。
實驗數(shù)據(jù)顯示:
- 在k=16的場景下,首 token 延遲(TTFT)提升 16.53 倍;
- 在k=32的場景下,直接拉到30.85 倍;
- 吞吐量提升也很夸張,比 LLaMA 基線高出6.78 倍。
相比之下,之前最強(qiáng)的 CEPE 框架,能做到的加速也只有 2–8 倍。可以說 REFRAG 在性能上做到了一個數(shù)量級的躍升。
4. 準(zhǔn)確率怎么保證?RL 來兜底
速度提上去了,另一個擔(dān)憂自然是:會不會犧牲準(zhǔn)確率?
REFRAG 的解決方案是 強(qiáng)化學(xué)習(xí)(RL)監(jiān)督的壓縮策略:
- 對于大部分普通段落,用 embedding 表示即可;
- 對于包含關(guān)鍵數(shù)字、專有名詞等高價值信息的塊,則跳過壓縮,直接保留原始 token;
- 模型通過 RL 訓(xùn)練學(xué)會判斷哪些塊值得“例外處理”。
這種“選擇性壓縮”讓 REFRAG 在多個長上下文數(shù)據(jù)集上不僅沒有掉點,甚至在一些場景下 比 CEPE 更準(zhǔn)。
比如在 PG19、ProofPile 這些長文本任務(wù)上,REFRAG 的困惑度(perplexity)平均提升了 **9.3%**。
5. 實驗結(jié)果:又快又準(zhǔn)
研究團(tuán)隊在多個任務(wù)上測試了 REFRAG,包括:
- 長文檔理解(Books、Arxiv、PG19、ProofPile);
- RAG 問答;
- 多輪對話;
- 長文檔總結(jié)。
結(jié)果顯示:
- 上下文長度擴(kuò)展了16 倍,遠(yuǎn)超 LLaMA-2 的 4K token 限制;
- 在弱檢索(噪聲多)的情況下,REFRAG 依舊能保持較高準(zhǔn)確度,因為它能在同樣延遲下處理更多段落;
- 在大多數(shù)任務(wù)上,REFRAG 的表現(xiàn)顯著超過 CEPE 以及 LLaMA 基線。
一句話總結(jié):速度和準(zhǔn)確率雙雙拉滿。
6. 應(yīng)用場景:RAG 終于能落地了?
REFRAG 的價值并不僅僅是論文指標(biāo),而是直接作用在實際應(yīng)用上。
- 企業(yè)知識庫問答:以前 FAQ 文檔一大堆,模型要花很久才能“看完”;現(xiàn)在延遲縮短幾十倍,終于能接近實時交互。
- 長文檔分析:比如合同審查、學(xué)術(shù)論文綜述,REFRAG 能處理的上下文是傳統(tǒng) LLM 的 16 倍,這讓“整本書喂進(jìn)去”成為可能。
- 多輪對話助手:在客戶服務(wù)、咨詢場景中,跨會話的上下文終于能保留更久,不再“失憶”。
- 大規(guī)模檢索增強(qiáng)系統(tǒng):在檢索到的大量段落中,REFRAG 能快速篩選并壓縮信息,顯著降低算力消耗。
可以說,它解決了 RAG 一直以來的“雞肋問題”:能做,但做得不夠快、不夠穩(wěn)。
7. 限制與展望
當(dāng)然,REFRAG 不是完美無缺的。
- 依賴額外的壓縮模塊:需要訓(xùn)練一個高效的 encoder,工程復(fù)雜度增加;
- RL 策略訓(xùn)練成本高:在新領(lǐng)域應(yīng)用時可能需要重新調(diào)優(yōu);
- 極端長文本場景:雖然擴(kuò)展了 16 倍,但面對百萬 token 級別的任務(wù),依舊存在瓶頸。
但不可否認(rèn),REFRAG 已經(jīng)為長上下文 RAG 系統(tǒng)開了一扇窗。未來,如果進(jìn)一步結(jié)合動態(tài)檢索、分層存儲、模型裁剪等方法,長文檔 AI 助手可能會真正走向大規(guī)模落地。
結(jié)尾:速度與規(guī)模的平衡點
長上下文是 LLM 落地的一道硬門檻。REFRAG 的出現(xiàn),等于告訴我們:這扇門不是打不開,只是需要換一把鑰匙。
通過表示壓縮和選擇性保留,Meta 團(tuán)隊在“快”與“準(zhǔn)”之間找到了一種新的平衡方式。它不僅是一項技術(shù)突破,更是對未來大模型架構(gòu)的一種暗示:我們不一定非要無限加大模型,而是要學(xué)會“聰明地用信息”。
對開發(fā)者和企業(yè)來說,REFRAG 的意義在于——RAG 系統(tǒng)終于可以在真實業(yè)務(wù)中跑起來,而不僅僅是實驗室里的概念。
你怎么看?如果有一天,長上下文的限制徹底被解決,我們是不是就能真正實現(xiàn)“給模型整個世界,它都能即時回答”?
本文轉(zhuǎn)載自??Halo咯咯?? 作者:基咯咯

















