RAG 作者：RAG 已死，RAG 萬歲！

作者：Douwe Kiela，編譯：思考機器編輯：DataWhale

本文作者 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 精準定位所需信息要昂貴得多。