長上下文窗口、Agent崛起，RAG已死？
在技術飛速更新迭代的今天，每隔一段時間就會出現「XX 已死」的論調。「搜索已死」、「Prompt 已死」的余音未散，如今矛頭又直指 RAG。
向量數據庫 Chroma 創始人兼 CEO Jeff Huber 在播客與訪談中拋出「RAG 已死，上下文工程當立」的表述，主張以上下文工程框架取代對「RAG」這一術語的狹義依賴。
對于眾多 AI 應用開發者而言，RAG 并不陌生。自 2022 年以來，為解決 LLM 輸入長度有限（如 GPT-3.5 的 4K tokens）的問題，RAG 作為一種「外掛」知識庫的解決方案，迅速成為行業標準。
其核心邏輯如同搜索引擎：將龐大文檔切分成小塊，通過向量嵌入和相似度搜索，找到與用戶問題最相關的片段，再喂給 LLM 生成答案。
作為近幾年最炙手可熱的 LLM 應用范式之一，RAG 似乎正在經歷一場生存危機。長上下文窗口的崛起和 Agent 能力的進化，正在動搖著它的核心地位。
那么，RAG 真的過時了嗎？我們從三篇代表性文章中，梳理了業界對 RAG「生死問題」的不同回答。
RAG 未死，它在進化為「智能體檢索」
- 博客文章：RAG is dead, long live agentic retrieval
- 博客地址：https://www.llamaindex.ai/blog/rag-is-dead-long-live-agentic-retrieval
來自 RAG 基礎設施巨頭 LlamaIndex 的這篇文章提供了一種演進主義的視角。它不認為 RAG 正在被替代，而是正在經歷一個演進階段，其中 AI 智能體成為一種全新的、更強大的 RAG 架構的核心。
文章指出，RAG 技術已經超越了早期「樸素的區塊檢索」階段，進入了一個以「Agentic 策略」為核心的新時代。現代 AI 工程師需要掌握一系列復雜的數據檢索技術，如混合搜索、CRAG、Self-RAG 等。
作者以 LlamaCloud 的檢索服務為例，系統性地展示了如何從基礎的 RAG 逐步構建一個能夠智能查詢多個知識庫的、完全由 agent 驅動的高級檢索系統。
第一階段：基礎的「Top-k」檢索
這是 RAG 技術的起點。其工作原理如下：
- 將文檔分割成多個「區塊」（Chunks）。
- 將這些區塊的嵌入存儲在向量數據庫中。
- 當用戶提出查詢時，系統計算查詢的嵌入，并從數據庫中找出最相似的 k 個區塊作為上下文，提供給 LLM 以生成答案。
作者還提及，在 LlamaCloud 的實現中，除了默認的按區塊檢索（chunk 模式），還提供了兩種額外的文件級檢索模式：
- files_via_metadata：當查詢明確提及文件名或路徑時（例如，「2024_MSFT_10K.pdf 這份文件說了什么？」），此模式直接檢索整個文件。
- files_via_content：當查詢是關于某個主題的寬泛問題，但需要完整文件作為背景時（例如，「微軟的財務前景如何？」），此模式會根據內容相關性檢索整個文件。
第二階段：引入輕量級 agent——自動路由模式
在實際應用中，系統通常無法預知用戶會提出哪種類型的問題。為了解決這個問題，作者介紹了一種名為「自動路由」（auto_routed）的檢索模式。
該模式本質上是一個輕量級的 agent 系統。它會首先分析用戶的查詢，然后智能地判斷應該采用上述三種模式（chunk、files_via_metadata 或 files_via_content）中的哪一種來執行檢索。這實現了在單一知識庫內的檢索策略自動化。
第三階段：擴展至多個知識庫——復合檢索 API
當一個系統需要處理多種不同格式的文檔時（如財報 PDF、會議 PPT、客服記錄等），將它們全部放在一個索引中并用相同的解析規則處理是低效的。更優的做法是為每種類型的文檔創建獨立的、高度優化的索引。
為了能夠同時查詢這些分散的知識庫，作者介紹了「復合檢索 API」。其核心功能是：
- 整合多個索引：允許將多個獨立的索引（例如，「財報索引」和「幻燈片索引」）添加到一個復合檢索器中。
- 智能路由：通過為每個子索引提供描述（例如，「用于公司財務報告」），復合檢索器利用一個 agent 層來分析用戶查詢，并將其路由到一個或多個最相關的子索引。
- 結果重排：從所有被查詢的索引中收集結果，并進行重排序，最終返回最相關的 top-n 個結果。
第四階段：構建完全由 agent 驅動的知識系統
作者的最終目標是將上述技術整合，構建一個在每個環節都由 agent 進行智能決策的、完全自動化的檢索系統。這個系統的運作流程形成了一個雙層 agent 架構：
- 頂層 agent（復合檢索器）：接收到用戶查詢后，該 agent 首先進行 LLM 分類，判斷查詢與哪個或哪些知識庫（子索引）最相關，并將查詢分發下去。
- 例如，當查詢「2024 年第四季度財報中的收入增長情況如何？」時，頂層 agent 會識別出「財報」關鍵詞，并將查詢路由至 financial_index。
- 子索引層 agent（自動路由模式）：當一個特定的子索引接收到查詢后，其內部的 auto_routed 模式 agent 會啟動，分析查詢的具體意圖，并決定在該索引內部使用最合適的檢索方法（是按區塊、按文件名還是按內容檢索）。
- 例如，對于上述查詢，子索引 agent 可能會判斷這是一個針對特定信息的問題，從而選擇 chunk 模式進行精確區塊檢索。
通過這種分層 agent 的方法，系統能夠以高度動態和智能化的方式響應復雜多樣的用戶查詢，在正確的時間、從正確的知識庫、用正確的方式獲取最精準的上下文。
作者總結道，簡單的 RAG 已經過時，智能體驅動的檢索才是未來。高級檢索服務通過這種分層、智能的能力，充當著高級 AI 智能體不可或缺的「知識骨干」。
別說 RAG 已死，它正成為一門嚴肅的工程學科
- 博客文章：Stop Saying RAG Is Dead
- 博客地址：https://hamel.dev/notes/llm/rag/not_dead.html
這篇博客的主要作者是資深機器學習工程師、曾就職于 GitHub 和 Airbnb 等知名企業的 Hamel Husain。
文章包含 6 個部分，作者邀請多位專家共同系統性地探討了為什么 RAG 不僅沒有死，反而正以前所未有的重要性，進化為構建可靠、高效 AI 應用的核心工程學科。
Part 1 & 2: 重新定義 RAG 與評估范式
Ben Clavié（RAGatouille 作者）和 Nandan Thakur（BEIR、FreshStack 基準測試設計者）首先澄清了核心誤解。
Clavié 指出，將所有信息塞入長上下文窗口在經濟和效率上都是不切實際的。RAG 的本質（為語言模型提供其訓練時未見的外部知識）是永恒的需求。
我們告別的只是幼稚的單向量語義搜索，正如我們用 CSS 升級 HTML，我們正在用更先進的檢索技術升級 RAG。
Thakur 則顛覆了傳統的評估體系。他認為，像 BEIR 這類為傳統搜索引擎設計的基準，其目標是「找到排名第一的正確答案」，這與 RAG 的目標不符。
RAG 系統的檢索目標應該是：
- 覆蓋率：是否找到了生成答案所需的所有事實證據？
- 多樣性：是否避免了信息冗余，高效地提供了不同方面的信息？
- 相關性：檢索到的信息是否切題？
為此，他設計了 FreshStack 基準，為衡量現代 RAG 系統的真實性能提供了新的標尺。
Part 3 & 4: 新一代檢索模型：會推理、無損壓縮
Orion Weller（約翰霍普金斯大學）和 Antoine Chaffin（LightOn）介紹了兩種突破性的檢索模型范式，它們讓檢索器本身具備了「思考」能力。
Weller 的研究將大模型的指令遵循和推理能力直接嵌入檢索過程。他展示了兩個模型：
- Promptriever：一個「指令感知」的 bi-encoder 模型，能夠理解并執行復雜指令，如「用隱喻尋找關于數據隱私的文檔」，從而發現傳統模型無法觸及的結果。
- Rank1：一個能生成明確推理鏈的 reranker 模型，它通過「思考過程」來判斷相關性，不僅提升了準確率，還發現了許多被以往基準測試忽略的有效文檔。
Chaffin 則直指單向量檢索的核心缺陷——信息壓縮損失。他介紹了「延遲交互」模型（如 ColBERT），這種模型不將整個文檔壓縮成一個向量，而是保留了每個 token 的向量表示。
這使得一個僅有 150M 參數的小模型，在推理密集型任務上的表現甚至超過了 7B 參數的大模型。同時，PyLate 等開源庫的出現，正讓這種強大的技術變得前所未有地易于使用。
Part 5 & 6: 架構的進化：從單一地圖到智能路由與上下文工程
最后兩部分由 Bryan Bischof 和 Ayush Chaurasia，以及 Chroma 公司的 Kelly Hong，將視角從模型本身拉升到系統架構和工程實踐。
Bischof 和 Chaurasia 提出，我們不應再尋找那個「完美」的嵌入模型或表示方法。正確的做法是，為同一份數據創建多種表示，就像為同一個地方準備多張不同功能的地圖（如地形圖、交通圖）。
然后，利用一個智能「路由器」（通常是一個 LLM Agent）來理解用戶意圖，并將其導向最合適的「地圖」進行查詢。他們的「語義點彩藝術」應用生動地展示了這種架構的靈活性和強大效果。
Kelly Hong 的研究則為「長上下文萬能論」敲響了警鐘。她提出了「上下文腐爛」現象：隨著輸入上下文的增長，尤其是在存在模糊信息和「干擾項」時，大模型的性能會顯著下降，甚至在簡單任務上也變得不可靠。這證明了精巧的上下文工程和精準的檢索比簡單粗暴地填充上下文窗口更為重要。
RAG 的訃告：
被 Agent 殺死，被長上下文掩埋
- 博客文章：The RAG Obituary: Killed by Agents, Buried by Context Windows
- 博客地址：https://www.nicolasbustamante.com/p/the-rag-obituary-killed-by-agents
這篇文章的作者是 Fintool 創始人 Nicolas Bustamante，他擁有十年法律和金融搜索平臺構建經驗，直言整個 RAG 架構正在成為一個不必要的、臃腫的歷史包袱。
作者指出 RAG 架構從根基上就存在難以克服的「原罪」：
- 切分的困境：RAG 的第一步「切塊」就是災難的開始。以一份復雜的 SEC 10-K 財報為例，強制按固定長度切分，會將表格的標題與數據分離，風險因素的解釋被攔腰斬斷，管理層討論與相關財務數據脫鉤。作者所在公司 Fintool 雖開發出保留層級結構、表格完整性、交叉引用等高級切分策略，但這依然是「在碎片上跳舞」，無法解決上下文被物理割裂的根本問題。
- 檢索的噩夢：純粹的向量搜索在專業領域常常失靈。嵌入模型難以區分「收入確認」（會計政策）和「收入增長」（業務表現）這類術語的細微差別。文章舉了一個生動的例子：當查詢「公司的訴訟風險」時，RAG 可能只找到明確提及「訴訟」字眼的段落，從而報告 5 億美元的風險；而實際上，加上或有負債、后續事項、賠償義務等其他部分，真實風險高達 51 億美元，相差十倍。
- 無盡的「補丁」：為了彌補向量搜索的不足，業界引入了混合搜索，結合關鍵詞匹配（如 BM25）與向量語義，并通過 RRF 等算法融合結果。但這還不夠，為了提升最終喂給 LLM 內容的質量，還需要增加一個「重排序」環節。每增加一個環節，都意味著延遲的飆升、成本的疊加以及系統復雜性的指數級增長。作者將其形容為「級聯失敗問題」，任何一環的失誤都會被層層放大。
- 沉重的基礎設施負擔：維護一個生產級的 Elasticsearch 集群本身就是一項艱巨的任務，涉及 TB 級的索引數據、高昂的內存成本、耗時數天的重建索引以及持續的版本管理和優化。
作者認為，智能體（Agent）和 LLM 長上下文窗口這兩項技術進步將直接「殺死」RAG。
作者的「頓悟時刻」來源于 Anthropic 發布的 Claude Code。他發現這個編碼助手在沒有使用任何 RAG 的情況下，表現遠超傳統方法。
其秘訣在于放棄了復雜的索引管道，回歸了最原始但極其高效的工具：grep（文本搜索）和 glob（文件模式匹配）。
這種「智能體搜索」范式的工作方式是「調查」而非「檢索」：
- 直接訪問，而非索引：Agent 可以直接在文件系統上運行 grep，實時、高速地查找信息，無需預處理和索引，也就不存在索引延遲。
- 完整加載，而非碎片：隨著 Claude Sonnet 4 達到 200K、Gemini 2.5 達到 1M、甚至 Grok 4-fast 達到 2M tokens 的上下文窗口，LLM 現在可以直接「讀入」整份財報、整個代碼庫。當你可以閱讀全書時，為什么還要滿足于幾張書簽呢？
- 邏輯導航，而非相似度匹配：Agent 能夠像人類分析師一樣，在完整文檔中進行邏輯跳轉。例如，在財報中看到「參見附注 12」，它會直接導航到附注 12，再根據附注內容跳轉到其他相關章節，從而構建一個完整的理解鏈條。
作者的結論并非要徹底消滅 RAG，而是將其「降級」。在新的范式下，RAG 不再是系統的核心架構，而僅僅是 Agent 工具箱中的一個選項。
在面對海量文檔需要初步篩選時，Agent 可能會先用混合搜索（RAG 的核心）進行一次粗篩，然后將排名靠前的幾份完整文檔加載到上下文中，進行深度分析和推理。
結語
綜合這三種觀點，我們可以得出一個清晰的結論：初級的、樸素的 RAG（Naive RAG）確實已經「死亡」。那種簡單的「切塊-向量化-相似度搜索」流程，已無法滿足日益復雜的 AI 應用需求。
然而，RAG 本身所代表的核心思想——為 LLM 提供精準、可靠的外部知識——的需求是永恒的。
未來的圖景更可能是：
- RAG 的角色轉變：RAG 不再是所有應用的默認核心架構，而是被「降級」為 Agent 工具箱中的一個強大組件。它將與代碼解釋器、API 調用、文件系統操作等工具平起平坐。
- 場景決定架構：對于需要從海量、非結構化數據中快速篩選信息的場景（如智能客服、企業知識庫初篩），由 Agent 驅動的、高度工程化的高級 RAG 系統仍是最佳選擇。
- 長上下文的統治力：對于需要對少量、結構復雜的文檔進行深度推理和分析的場景（如財報分析、法律合同審查），「長上下文窗口 + Agent 調查」的范式將展現出碾壓性的優勢。
對于開發者而言，關鍵在于理解不同技術范式的優劣，并根據具體的應用場景，靈活地將它們組合成最高效、最可靠的解決方案。
更多細節請參看原博客。
