編者按： 我們今天為大家?guī)?lái)的這篇文章，作者的觀點(diǎn)是：即便在大語(yǔ)言模型上下文窗口不斷擴(kuò)大的今天，檢索增強(qiáng)生成（RAG）技術(shù)依然具有不可替代的價(jià)值。

文章首先通過(guò) Fiction.liveBench 基準(zhǔn)測(cè)試結(jié)果展示了即使最先進(jìn)的大模型在處理長(zhǎng)上下文時(shí)也會(huì)遇到理解能力下降的問(wèn)題，并指出：理論上下文長(zhǎng)度 ≠ 有效上下文長(zhǎng)度。

隨后，作者從四個(gè)角度論證了 RAG 技術(shù)依然具有不可或缺的優(yōu)勢(shì)：1）企業(yè)私有數(shù)據(jù)體量遠(yuǎn)超任何模型的上下文窗口容量；2）模型存在“l(fā)ost in the middle”問(wèn)題，難以有效處理長(zhǎng)上下文中間部分的信息；3）長(zhǎng)上下文處理帶來(lái)的時(shí)間成本和費(fèi)用開銷非常大；4）RAG 架構(gòu)提供的組件分離設(shè)計(jì)擁有更高的系統(tǒng)可維護(hù)性和問(wèn)題可追溯性。

最后，文章對(duì) RAG 的發(fā)展方向進(jìn)行了展望，并為正在規(guī)劃或已經(jīng)部署 AI 系統(tǒng)的企業(yè)決策者和技術(shù)團(tuán)隊(duì)提供了五點(diǎn)切實(shí)可行的戰(zhàn)略建議。

本文系原作者觀點(diǎn)，Baihai IDP 僅進(jìn)行編譯分享

作者 | Skylar Payne

編譯 | 岳揚(yáng)

每次新的大語(yǔ)言模型問(wèn)世，標(biāo)題黨總遵循著固定套路：“百萬(wàn) tokens 級(jí)別上下文窗口的新模型橫空出世！”緊接著各路熱評(píng)紛至沓來(lái)：“RAG 技術(shù)已死！”“檢索機(jī)制可以淘汰了！”“直接把所有數(shù)據(jù)灌進(jìn)模型就行！”

但如果你真正部署過(guò)解決實(shí)際業(yè)務(wù)問(wèn)題的 AI 系統(tǒng)，就會(huì)明白事實(shí)絕非如此。甚至可以說(shuō)相差十萬(wàn)八千里。

我曾在谷歌和領(lǐng)英等公司擔(dān)任機(jī)器學(xué)習(xí)團(tuán)隊(duì)的負(fù)責(zé)人，主導(dǎo)過(guò)多個(gè)數(shù)據(jù)產(chǎn)品從零到推向國(guó)際市場(chǎng)的全過(guò)程，也見證過(guò)許多企業(yè)耗費(fèi)數(shù)百萬(wàn)美元卻收效甚微的 AI 項(xiàng)目。這些失敗案例有共同點(diǎn)嗎？都誤解了上下文窗口與檢索機(jī)制的關(guān)系。

接下來(lái)，請(qǐng)容我為您解釋為何即便上下文窗口擴(kuò)展到了百萬(wàn) tokens，檢索增強(qiáng)生成（RAG）技術(shù)依然不可或缺。

01 接受基準(zhǔn)測(cè)試 Fiction.liveBench 的現(xiàn)實(shí)檢驗(yàn)

在進(jìn)一步深入探討之前，我們先來(lái)看一組數(shù)據(jù)。Fiction.liveBench 是一項(xiàng)針對(duì)長(zhǎng)上下文理解能力的基準(zhǔn)測(cè)試，近期對(duì)主流大語(yǔ)言模型在不同上下文長(zhǎng)度下理解復(fù)雜敘事的能力進(jìn)行了評(píng)估[1]。

結(jié)果如何？ 即便是最先進(jìn)的模型（包括號(hào)稱具備 1000 萬(wàn) token 上下文的 Llama 4），在上下文長(zhǎng)度適中的基本理解任務(wù)（basic comprehension tasks）中也很吃力。 大多數(shù)模型的表現(xiàn)會(huì)在超過(guò)幾千 token 后明顯下降 —— 隨著上下文的增加，模型輸出的準(zhǔn)確率下降至接近隨機(jī)瞎猜的水平。

Fiction.liveBench 測(cè)試結(jié)果顯示模型性能隨上下文增長(zhǎng)而衰減

這一發(fā)現(xiàn)并非孤例。它反應(yīng)了從業(yè)人員日常能夠觀察到的現(xiàn)象：理論上下文長(zhǎng)度 ≠ 有效上下文長(zhǎng)度。問(wèn)題的關(guān)鍵不在于模型能否“吞下”10 萬(wàn) tokens，而在于它能否真正“消化”這些信息。

02 RAG 與上下文窗口的演進(jìn)

讓我們回顧一下歷史。早期的 LLM（如 GPT-3）僅有很小的上下文窗口（約 2K token），這使得 RAG 幾乎成為所有非簡(jiǎn)單應(yīng)用的必備方案。隨著上下文窗口擴(kuò)展至 8K、32K，直至如今的數(shù)百萬(wàn) token，某些場(chǎng)景確實(shí)可以在無(wú)需檢索機(jī)制的情況下運(yùn)行。

但這催生了一個(gè)危險(xiǎn)的觀點(diǎn)：認(rèn)為增大上下文窗口大小最終將徹底消除對(duì)檢索機(jī)制的需求。

這種二元對(duì)立的思維方式忽略了系統(tǒng)設(shè)計(jì)中一個(gè)重要的洞見：useful tradeoffs are multi-dimensional（譯者注：在系統(tǒng)設(shè)計(jì)中，不能通過(guò)單一變量（如僅增加上下文長(zhǎng)度）來(lái)優(yōu)化整體性能，而需要在多個(gè)相互制約的維度之間進(jìn)行平衡取舍。）。不應(yīng)該將 RAG 與長(zhǎng)上下文窗口視為互斥的關(guān)系，而是應(yīng)該考慮兩者在不同場(chǎng)景中如何協(xié)同互補(bǔ)。

03 為什么 RAG 能夠持續(xù)存在（并蓬勃發(fā)展）

3.1 數(shù)據(jù)體量的現(xiàn)實(shí)情況

大多數(shù)企業(yè)擁有 TB 數(shù)量級(jí)的文檔，包含數(shù)百萬(wàn)至數(shù)十億 tokens。即使 10M token 的上下文窗口（在實(shí)踐中能實(shí)現(xiàn)這個(gè)水平的模型極少）也無(wú)法容納整個(gè)知識(shí)庫(kù)。

以某制藥公司為例：

• 50,000+篇研究論文
• 10,000+份臨床試驗(yàn)報(bào)告
• 20 年的監(jiān)管申報(bào)材料
• 數(shù)千項(xiàng)專利

沒有任何大模型的上下文窗口能承載這些信息。檢索不是可走可不走的通道，而是必由之路。

3.2 "The Lost in the Middle"問(wèn)題

即便這些文檔在技術(shù)上符合上下文窗口的要求，LLM 仍會(huì)陷入研究者所稱的"lost in the middle"綜合癥。模型更關(guān)注上下文中開頭和結(jié)尾的信息，常會(huì)遺漏中間位置的關(guān)鍵細(xì)節(jié)。前文提到的 Fiction.liveBench 基準(zhǔn)測(cè)試結(jié)果已經(jīng)表明了該問(wèn)題的嚴(yán)重性 —— 而這還是在更理想化的“實(shí)驗(yàn)室環(huán)境”中，在具體問(wèn)題、具體領(lǐng)域中，效果可能更加糟糕。

Anthropic 等實(shí)驗(yàn)室的研究一致表明，即便是最先進(jìn)的模型也會(huì)表現(xiàn)出明顯的 position bias（譯者注：模型在注意力機(jī)制作用下，對(duì)不同位置信息的關(guān)注度權(quán)重分布不均衡。）。實(shí)際應(yīng)用中這意味著：

• 位于第 10,000 位的文檔對(duì)模型輸出的影響力低于第 500 位的文檔
• 上下文中間位置的關(guān)鍵信息常被忽視
• 單純將文檔塞入上下文并不能確保其被有效利用

而 RAG 系統(tǒng)通過(guò)檢索并優(yōu)先處理最相關(guān)的信息來(lái)解決這個(gè)問(wèn)題，確保 LLM 減少誤關(guān)注上下文中無(wú)關(guān)部分的機(jī)會(huì)。

3.3 模型推理的成本效益分析：長(zhǎng)上下文的真實(shí)成本

每次增加上下文窗口大小，我們都在實(shí)實(shí)在在地為此付出代價(jià)。這個(gè)說(shuō)法并非來(lái)自于理論推演，而是直接體現(xiàn)在性能指標(biāo)和月度賬單中。

根據(jù) Glean 對(duì) GPT-4 Turbo 的研究[2]，輸入 token 數(shù)量與響應(yīng)時(shí)間存在線性關(guān)系。其基準(zhǔn)測(cè)試顯示，每增加一個(gè) token 會(huì)使首 token 的生成時(shí)間（TTFT）延長(zhǎng)約 0.24 毫秒。這對(duì)上下文只有少量 token 的情況而言當(dāng)然微不足道，但是會(huì)快速累積：

• 10,000 token 上下文：生成任何內(nèi)容前需額外等待 +2.4 秒
• 50,000 token 上下文：+12 秒純等待時(shí)間
• 100,000 token 上下文：獲得首個(gè)模型回復(fù)前需等待 +24 秒

對(duì)于期待獲得即時(shí)響應(yīng)的用戶而言，這些延遲不容忽視。在 Glean 的測(cè)試中，僅將 3,000 token 的上下文拆分為三個(gè)并行的 1,000 token 檢索，就能改善近半秒的響應(yīng)時(shí)間。

財(cái)務(wù)成本則體現(xiàn)得更為直接。以下列模型的定價(jià)作為參考：

• GPT-4 Turbo：0.01 美元/1K input tokens
• Claude 3 Opus：0.015 美元/1K input tokens
• Mistral Large：0.008 美元/1K input tokens

這意味著單個(gè) 100K token 上下文的查詢，在生成任何輸出前就可能耗費(fèi) 1.00-1.50 美元。若乘以企業(yè)每天數(shù)千次的查詢量，成本將呈指數(shù)級(jí)增長(zhǎng)。

RAG 提供了一個(gè)直擊痛點(diǎn)的解決方案：不必每次輸入提示詞都塞入 100K token，只需檢索最相關(guān)的 2-3K token。實(shí)現(xiàn) 97% 的上下文規(guī)?？s減意味著：

1) token 處理時(shí)間縮減 97%

2) token 相關(guān)成本節(jié)省 97%

3) 更快的響應(yīng)速度帶來(lái)更佳的用戶體驗(yàn)

沒有企業(yè)愿意為處理無(wú)關(guān) token 付費(fèi)，沒有用戶愿意等待模型處理無(wú)用文本。RAG 不僅經(jīng)濟(jì)高效，更是大規(guī)模生產(chǎn)系統(tǒng)的實(shí)用方案。

3.4 組件分離的優(yōu)勢(shì)

在相關(guān)討論中，有一個(gè)容易被忽視的核心工程原則：the value of separating concerns（譯者注：該原則在系統(tǒng)設(shè)計(jì)中指將復(fù)雜系統(tǒng)拆分為功能獨(dú)立、責(zé)任清晰的模塊，每個(gè)模塊專注于單一核心任務(wù)。）。RAG 架構(gòu)將 AI 工作流拆分為獨(dú)立的檢索組件與生成組件。這種分離不僅是一種“系統(tǒng)架構(gòu)美學(xué)”，還具有實(shí)質(zhì)性的技術(shù)優(yōu)勢(shì)。

我在 LinkedIn 領(lǐng)導(dǎo)機(jī)器學(xué)習(xí)工程團(tuán)隊(duì)時(shí)，深刻認(rèn)識(shí)到包含確定性與非確定性組件的混合系統(tǒng)更易調(diào)試、測(cè)試和進(jìn)行改進(jìn)。使用 RAG 架構(gòu)時(shí)，若出現(xiàn)故障（生產(chǎn)環(huán)境必然會(huì)發(fā)生故障），可快速定位問(wèn)題根源：

1. 檢索組件選擇了不相關(guān)的文檔
2. LLM 誤解了優(yōu)質(zhì)文檔
3. 知識(shí)庫(kù)中根本不存在該信息

這種模塊化架構(gòu)帶來(lái)的問(wèn)題可追溯性非常寶貴。在純 LLM 系統(tǒng)中出現(xiàn)幻覺時(shí)，你往往只能猜測(cè)故障原因。

此外，這種分離設(shè)計(jì)還能實(shí)現(xiàn)對(duì)各組件的獨(dú)立優(yōu)化。你可以在不改動(dòng)生成模塊的情況下改進(jìn)檢索系統(tǒng)，無(wú)需重構(gòu)檢索架構(gòu)就能升級(jí)大語(yǔ)言模型，或者直接新增內(nèi)容源而無(wú)需重新訓(xùn)練任何組件。整個(gè)系統(tǒng)因此變得更模塊化、更具適應(yīng)性且易于維護(hù)。

在實(shí)際應(yīng)用中，這意味著您能持續(xù)迭代優(yōu)化系統(tǒng)，而非將其視為不可拆解的黑箱。任何構(gòu)建過(guò)真實(shí) AI 系統(tǒng)的工程領(lǐng)導(dǎo)者都會(huì)明白，這種設(shè)計(jì)理念具有無(wú)可替代的價(jià)值。

04 超越傳統(tǒng)的 RAG：持續(xù)進(jìn)化的檢索增強(qiáng)生成

RAG 并非一成不變的技術(shù)。它正與所增強(qiáng)的生成模型一起不斷發(fā)展。未來(lái)的方向不是拋棄檢索機(jī)制，而是使其更智能、更動(dòng)態(tài)，并與模型推理深度整合。

最新進(jìn)展在保留 RAG 核心優(yōu)勢(shì)的同時(shí)，正突破其傳統(tǒng)局限：

自省式檢索（Self-reflective retrieval） ：新一代系統(tǒng)能動(dòng)態(tài)判斷何時(shí)需要補(bǔ)充檢索，而非依賴單次檢索。這樣，模型就能自主識(shí)別自己的不確定性，實(shí)時(shí)獲取額外的上下文。

遞歸優(yōu)化（Recursive refinement） ：系統(tǒng)不再滿足于一次性檢索，而是基于部分信息迭代優(yōu)化搜索查詢 —— 正如人類研究某個(gè)課題時(shí)逐步聚焦關(guān)注范圍的過(guò)程。

這些方法并非取代 RAG，而是對(duì)其進(jìn)行增強(qiáng)。它們體現(xiàn)的是進(jìn)化（evolution），而非徹底變革（revolution）。最重要的是，它們依然保持檢索與生成的分離，只是組件間的交互接口變得更加精密。

尤為有趣的是，隨著上下文窗口的擴(kuò)展，這些進(jìn)化版 RAG 反而更加強(qiáng)大。擁有 10 萬(wàn) token 上下文窗口的模型可同時(shí)容納多份檢索文檔，進(jìn)行比對(duì)、識(shí)別矛盾，其信息整合效率遠(yuǎn)超小上下文窗口模型。

從這個(gè)意義上說(shuō)，長(zhǎng)上下文模型與先進(jìn)檢索技術(shù)是互補(bǔ)關(guān)系。二者相互賦能，而非彼此替代。

05 探討前文技術(shù)分析對(duì)企業(yè)部署 AI 系統(tǒng)的戰(zhàn)略指導(dǎo)意義

如果您正在構(gòu)建 AI 系統(tǒng)，我的建議如下：

1) 不要為了追求更長(zhǎng)的上下文而放棄 RAG。 最高效的系統(tǒng)會(huì)兩種技術(shù)兼用，根據(jù)具體使用場(chǎng)景智能匹配方案。

2) 投資更好的檢索系統(tǒng)，而不僅是更大的模型。 向量搜索（vector search）與混合檢索（hybrid retrieval）技術(shù)的改進(jìn)，往往比換用僅支持稍長(zhǎng)上下文的最新模型帶來(lái)更大的商業(yè)價(jià)值。

3) 為現(xiàn)實(shí)場(chǎng)景設(shè)計(jì) AI 系統(tǒng)，而非為營(yíng)銷噱頭。 在假設(shè)長(zhǎng)上下文方案可行前，請(qǐng)用實(shí)際數(shù)據(jù)量和 query patterns（譯者注：用戶查詢請(qǐng)求中存在的規(guī)律性特征） 測(cè)試系統(tǒng)。

4) 構(gòu)建衡量核心指標(biāo)的評(píng)估框架。 您的系統(tǒng)能否基于特定文檔準(zhǔn)確回答問(wèn)題？這比任何基準(zhǔn)測(cè)試分?jǐn)?shù)都重要。

5) 保持靈活性。 該領(lǐng)域發(fā)展迅速，但核心的信息檢索原則已被證明具有持久價(jià)值。

06 結(jié)論：RAG 正在進(jìn)化，而非消亡

“RAG 已死”的論調(diào)反映出很多人對(duì) AI 系統(tǒng)設(shè)計(jì)的誤解。并不是要在檢索與長(zhǎng)上下文之間二選一，而是如何恰當(dāng)?shù)亟Y(jié)合二者。

隨著上下文窗口的擴(kuò)大，確實(shí)存在更多無(wú)需 RAG 的使用場(chǎng)景。但在可預(yù)見的未來(lái)，檢索技術(shù)仍將是 AI 工程師的核心能力。

這一論斷絕非主觀臆斷 —— 數(shù)據(jù)不會(huì)說(shuō)謊，成功案例自會(huì)印證：唯有真正融合檢索與生成技術(shù)優(yōu)勢(shì)的系統(tǒng)，才能持續(xù)創(chuàng)造商業(yè)價(jià)值。那些一味追逐技術(shù)熱點(diǎn)的方案，終究只是曇花一現(xiàn)。

About the author

Skylar Payne

AI made easy. AI executive for startups. Ex-Google. Ex-LinkedIn.

END

本期互動(dòng)內(nèi)容 ??

?有沒有哪個(gè)行業(yè)/場(chǎng)景特別適合 RAG 技術(shù)？請(qǐng)分享一個(gè)您見過(guò)的應(yīng)用案例。

文中鏈接

[1]??https://fiction.live/stories/Fiction-liveBench-April-6-2025/oQdzQvKHw8JyXbN87??

[2]??https://www.glean.com/blog/glean-input-token-llm-latency??

本文經(jīng)原作者授權(quán)，由 Baihai IDP 編譯。如需轉(zhuǎn)載譯文，請(qǐng)聯(lián)系獲取授權(quán)。

原文鏈接：

??https://skylarbpayne.com/posts/rag-not-dead??