編者按： 我們今天為大家?guī)淼倪@篇文章，作者的觀點是：即便在大語言模型上下文窗口不斷擴大的今天，檢索增強生成（RAG）技術(shù)依然具有不可替代的價值。

文章首先通過 Fiction.liveBench 基準測試結(jié)果展示了即使最先進的大模型在處理長上下文時也會遇到理解能力下降的問題，并指出：理論上下文長度 ≠ 有效上下文長度。

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

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

本文系原作者觀點，Baihai IDP 僅進行編譯分享

作者 | Skylar Payne

編譯 | 岳揚

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

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

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

接下來，請容我為您解釋為何即便上下文窗口擴展到了百萬 tokens，檢索增強生成（RAG）技術(shù)依然不可或缺。

01 接受基準測試 Fiction.liveBench 的現(xiàn)實檢驗

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

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

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

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

02 RAG 與上下文窗口的演進

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

但這催生了一個危險的觀點：認為增大上下文窗口大小最終將徹底消除對檢索機制的需求。

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

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

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

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

以某制藥公司為例：

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

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

3.2 "The Lost in the Middle"問題

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

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

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

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

3.3 模型推理的成本效益分析：長上下文的真實成本

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

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

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

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

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

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

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

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

1) token 處理時間縮減 97%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

尤為有趣的是，隨著上下文窗口的擴展，這些進化版 RAG 反而更加強大。擁有 10 萬 token 上下文窗口的模型可同時容納多份檢索文檔，進行比對、識別矛盾，其信息整合效率遠超小上下文窗口模型。

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

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

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

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

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

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

4) 構(gòu)建衡量核心指標的評估框架。 您的系統(tǒng)能否基于特定文檔準確回答問題？這比任何基準測試分數(shù)都重要。

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

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

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

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

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

About the author

Skylar Payne

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

END

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

?有沒有哪個行業(yè)/場景特別適合 RAG 技術(shù)？請分享一個您見過的應(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)載譯文，請聯(lián)系獲取授權(quán)。

原文鏈接：

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