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

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

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

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

一、接受基準測試 Fiction.liveBench 的現實檢驗

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

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

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

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

二、RAG 與上下文窗口的演進

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

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

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

三、為什么 RAG 能夠持續存在（并蓬勃發展）

3.1 數據體量的現實情況

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

以某制藥公司為例：

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

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

3.2 "The Lost in the Middle"問題

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

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

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

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

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

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

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

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

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

財務成本則體現得更為直接。以下列模型的定價作為參考：

• 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 美元。若乘以企業每天數千次的查詢量，成本將呈指數級增長。

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

1) token 處理時間縮減 97%

2) token 相關成本節省 97%

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

沒有企業愿意為處理無關 token 付費，沒有用戶愿意等待模型處理無用文本。RAG 不僅經濟高效，更是大規模生產系統的實用方案。

3.4 組件分離的優勢

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

我在 LinkedIn 領導機器學習工程團隊時，深刻認識到包含確定性與非確定性組件的混合系統更易調試、測試和進行改進。使用 RAG 架構時，若出現故障（生產環境必然會發生故障），可快速定位問題根源：

1) 檢索組件選擇了不相關的文檔

2) LLM 誤解了優質文檔

3) 知識庫中根本不存在該信息

這種模塊化架構帶來的問題可追溯性非常寶貴。在純 LLM 系統中出現幻覺時，你往往只能猜測故障原因。

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

在實際應用中，這意味著您能持續迭代優化系統，而非將其視為不可拆解的黑箱。任何構建過真實 AI 系統的工程領導者都會明白，這種設計理念具有無可替代的價值。

超越傳統的 RAG：持續進化的檢索增強生成

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

最新進展在保留 RAG 核心優勢的同時，正突破其傳統局限：

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

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

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

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

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

探討前文技術分析對企業部署 AI 系統的戰略指導意義

如果您正在構建 AI 系統，我的建議如下：

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

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

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

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

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

結論：RAG 正在進化，而非消亡

“RAG 已死”的論調反映出很多人對 AI 系統設計的誤解。并不是要在檢索與長上下文之間二選一，而是如何恰當地結合二者。

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

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