來源 | 思考機器 作者 |Douwe Kiela

本文作者 Douwe Kiela，RAG 論文（Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks）作者之一。

以下為全文：

每隔幾個月，人工智能領域就會經歷類似的模式。一個具有更大上下文窗口的新模型問世，社交媒體上便會充斥著“RAG 已死”的宣言。Meta 最近的突破再次引發了這場討論——Llama 4 Scout 驚人的 1000 萬（理論上）token 上下文窗口代表著一次真正的飛躍。

但這些論斷——無論是針對上下文窗口的突破、微調技術的進步，還是模型上下文協議（MCP）的出現——都誤解了 RAG 的目的，以及為何它在人工智能領域將永遠占有一席之地。

RAG的初衷

五年前，我在 Meta 基礎人工智能研究中心（FAIR，前身為 Facebook 人工智能研究中心）的團隊提出了 RAG（Retrieval-Augmented Generation，檢索增強生成）的概念。RAG 的目標是利用外部知識來增強模型，創造一種結合了參數化記憶和非參數化記憶的兩全其美的解決方案。

簡單來說，RAG 通過檢索語言模型未經訓練的數據源中的相關信息，并將其注入模型的上下文中，從而擴展了語言模型的知識庫。

這種方法旨在解決生成式語言模型的許多固有缺陷：

• 無法訪問私有（企業內部）數據：模型通常基于公共數據進行訓練，但往往需要那些不斷變化和擴展的專有信息。

• 過時的參數知識：即使模型頻繁更新，其訓練數據截止日期與當前時間之間總會存在差距。

• 幻覺和歸因問題：模型經常編造聽起來合理但錯誤的信息。RAG 通過將回答基于真實來源，并提供引文讓用戶核實信息，解決了這個問題。

聽起來耳熟嗎？現在已經不是 2020 年了，但這些同樣的問題至今依然存在。甚至可以說，隨著組織推動 AI 系統處理日益復雜和關鍵的任務，這些問題變得更加突出了。核心挑戰依然是：我們如何將強大的生成式模型與公司所依賴的海量知識庫連接起來？

為什么我們仍然需要RAG（并且永遠需要）

高效而精確的檢索在人工智能中將始終扮演重要角色。這一點在一個廣為流傳的 LinkedIn 帖子中得到了很好的闡述，但我將重申為什么我們不能僅僅將所有數據加載到模型的上下文中：自首個具備大上下文窗口的 LLM 問世以來，RAG 就一直面臨“消亡”的論調。

該 LinkedIn 帖子：

一些值得注意的 RAG“死亡宣告”包括：

• 2023 年 5 月：Anthropic 的 Claude，上下文窗口達 10 萬 token

• 2024 年 2 月：Google 的 Gemini 1.5，上下文窗口達 100 萬 token

• 2025 年 3 月：模型上下文協議（Model Context Protocol）讓你能直接與你的數據對話 (注：原文日期可能是筆誤)

但現實情況是：

即使擁有高達 200 萬 token 這樣驚人的上下文窗口，當前的長上下文 LLM 也只能處理演示性質的數據集（toy datasets）。
例如，100 萬 token 的上下文窗口（大致）相當于約 1500 頁文檔。
這對于演示來說很亮眼，但對于生產級別的應用而言是不足夠的。

不過，讓我們假設我們擁有一個無限 token 的上下文窗口：

• 可擴展性與成本：處理數百萬 token 速度緩慢，且在計算和財務上都代價高昂。即使計算成本在下降，延遲對于應用程序來說也可能是一個大問題。

• 性能下降：LLM 仍然受困于“中間丟失”（lost in the middle）的問題。這意味著它們無法有效利用長文本中間部分的信息。通過剔除不相關文檔并避免“大海撈針”的情況，您將獲得更好的結果。

• 數據隱私：將 所有 數據提供給基礎模型可能引發嚴重的數據隱私問題。尤其是在醫療保健或金融服務等受到嚴格監管的行業，您需要對數據強制執行基于角色的訪問控制。

底線是：您同時需要長上下文 LLM 和 RAG。

但既然“RAG”這個術語似乎如此具有爭議性，那我們不妨這樣說：
我們不必非得稱之為 RAG。
我們可以就叫它檢索 (retrieval)。
或者叫上下文篩選 (context curation)。

無論您決定怎么稱呼它，能夠控制進入上下文窗口的數據質量，將決定最終生成輸出的質量。

畢竟，垃圾進，垃圾出。

• 可擴展性– 您的企業知識庫是以 TB 或 PB 來衡量的，而不是 token。即使有 1000 萬 token 的上下文窗口，您仍然只能看到可用信息的極小一部分。這就是為什么檢索技術的創新一直快速發展，混合搜索、查詢轉換、自我反思、主動檢索以及對結構化數據的支持等方面的進步，都在幫助您在知識庫中找到正確的信息。

• 準確性– 有效的上下文窗口與產品發布時宣傳的大相徑庭。研究一致表明，模型在遠未達到其官方極限時性能就會下降。在實際測試中，同樣的模式也會出現，模型難以準確引用深埋在其上下文中的信息。這種“上下文懸崖”意味著僅僅將更多內容塞入窗口并不會帶來更好的結果。

• 延遲– 將所有內容加載到模型上下文中會導致響應時間顯著變慢。對于面向用戶的應用程序，這會造成糟糕的用戶體驗，人們會在得到答案前就放棄交互。基于檢索的方法可以通過僅添加最相關的信息來提供更快的響應。

• 效率– 你會在需要回答一個簡單問題時去讀完整本教科書嗎？當然不會！RAG 提供了相當于直接翻到相關頁面的能力。處理更多 token 不僅更慢，而且極其低效，并且比使用 RAG 精準定位所需信息要昂貴得多。

在谷歌搜索“RAG vs”，你會看到一長串建議的查詢補全——“長上下文”、“微調”、“MCP”。這種框架設定制造了一種人為的選擇，并沒有反映這些技術實際上如何協同工作的最佳方式。

實際上，這些概念沒有一個是相互排斥的，甚至不是相互沖突的——它們都以互補的方式幫助解決前沿模型的局限性：

• RAG提供了訪問模型知識庫之外信息的途徑

• 微調改善了信息處理和應用的方式

• 更長的上下文允許檢索更多信息供模型推理

• MCP簡化了 Agent 與 RAG 系統（及其他工具）的集成

我們在生產環境中看到的最復雜的 AI 系統結合了這些方法，根據各自的優勢來使用每種工具，而不是宣布某一個獲勝并將其他工具拋棄。

正如一位 Twitter 用戶最近所說：“聲稱大型 LLM 上下文窗口取代了 RAG，就像說因為有足夠的內存（RAM）就不需要硬盤一樣。”正是如此！你的電腦有磁盤、內存和網卡是有原因的。它們服務于不同的目的，并作為一個系統協同工作。RAG、微調和大型上下文窗口在 AI 中也是如此。

結論

我們不需要在 RAG 與長上下文窗口、微調或 MCP 之間做出選擇。真正能創造價值的 AI 解決方案不會固守單一方法；它們會根據要解決的具體問題混合搭配使用工具。

但下一次宣稱“RAG 已死”的論調出現只是時間問題，所以，如果你將來想引用這篇文章，可以在 isragdeadyet.com 找到它。這個網站將作為一個活生生的證明，展現檢索在 AI 系統中持久的重要性，并且每當下一波“RAG 已死”的帖子不可避免地出現時，它都會更新。

如果你的系統無法利用你的專有數據，持續提供過時信息，或者缺乏你所需的專業知識，那么讓我們談談。我們構建了一個將智能檢索與前沿 LLM 相結合的系統，來解決這些長期存在的難題。因為重要的不是哪種技術在某場人為的競賽中獲勝，而是構建能夠真正解決實際問題的方案。”

原文鏈接： https://contextual.ai/blog/is-rag-dead-yet/

最后推薦一個我正在學習的DeepSeek應用開發課

本課程將會涉及當前業界最主流的 AI 應用開發思想、套路、工具以及框架，設計的實戰項目也會聚焦 DeepSeek 模型的某個特點。對于 AI 開發老鳥，可以與時俱進，查漏補缺，掌握業界前沿的開發思想和工具；而對于 AI 開發新手，則可以繞過過去幾年我摸爬滾打的彎路，借力 DeepSeek，快速入門 AI 應用開發領域。