在技術(shù)飛速更新迭代的今天，每隔一段時間就會出現(xiàn)「XX 已死」的論調(diào)?！杆阉饕阉馈?、「Prompt 已死」的余音未散，如今矛頭又直指 RAG。

向量數(shù)據(jù)庫 Chroma 創(chuàng)始人兼 CEO Jeff Huber 在播客與訪談中拋出「RAG 已死，上下文工程當(dāng)立」的表述，主張以上下文工程框架取代對「RAG」這一術(shù)語的狹義依賴。

對于眾多 AI 應(yīng)用開發(fā)者而言，RAG 并不陌生。自 2022 年以來，為解決 LLM 輸入長度有限（如 GPT-3.5 的 4K tokens）的問題，RAG 作為一種「外掛」知識庫的解決方案，迅速成為行業(yè)標(biāo)準(zhǔn)。

其核心邏輯如同搜索引擎：將龐大文檔切分成小塊，通過向量嵌入和相似度搜索，找到與用戶問題最相關(guān)的片段，再喂給 LLM 生成答案。

作為近幾年最炙手可熱的 LLM 應(yīng)用范式之一，RAG 似乎正在經(jīng)歷一場生存危機。長上下文窗口的崛起和 Agent 能力的進(jìn)化，正在動搖著它的核心地位。

那么，RAG 真的過時了嗎？我們從三篇代表性文章中，梳理了業(yè)界對 RAG「生死問題」的不同回答。

RAG 未死，它在進(jìn)化為「智能體檢索」

• 博客文章：RAG is dead, long live agentic retrieval
  
• 博客地址：https://www.llamaindex.ai/blog/rag-is-dead-long-live-agentic-retrieval

來自 RAG 基礎(chǔ)設(shè)施巨頭 LlamaIndex 的這篇文章提供了一種演進(jìn)主義的視角。它不認(rèn)為 RAG 正在被替代，而是正在經(jīng)歷一個演進(jìn)階段，其中 AI 智能體成為一種全新的、更強大的 RAG 架構(gòu)的核心。

文章指出，RAG 技術(shù)已經(jīng)超越了早期「樸素的區(qū)塊檢索」階段，進(jìn)入了一個以「Agentic 策略」為核心的新時代?，F(xiàn)代 AI 工程師需要掌握一系列復(fù)雜的數(shù)據(jù)檢索技術(shù)，如混合搜索、CRAG、Self-RAG 等。

作者以 LlamaCloud 的檢索服務(wù)為例，系統(tǒng)性地展示了如何從基礎(chǔ)的 RAG 逐步構(gòu)建一個能夠智能查詢多個知識庫的、完全由 agent 驅(qū)動的高級檢索系統(tǒng)。

第一階段：基礎(chǔ)的「Top-k」檢索

這是 RAG 技術(shù)的起點。其工作原理如下：

• 將文檔分割成多個「區(qū)塊」（Chunks）。
• 將這些區(qū)塊的嵌入存儲在向量數(shù)據(jù)庫中。
• 當(dāng)用戶提出查詢時，系統(tǒng)計算查詢的嵌入，并從數(shù)據(jù)庫中找出最相似的 k 個區(qū)塊作為上下文，提供給 LLM 以生成答案。

作者還提及，在 LlamaCloud 的實現(xiàn)中，除了默認(rèn)的按區(qū)塊檢索（chunk 模式），還提供了兩種額外的文件級檢索模式：

• files_via_metadata：當(dāng)查詢明確提及文件名或路徑時（例如，「2024_MSFT_10K.pdf 這份文件說了什么？」），此模式直接檢索整個文件。
• files_via_content：當(dāng)查詢是關(guān)于某個主題的寬泛問題，但需要完整文件作為背景時（例如，「微軟的財務(wù)前景如何？」），此模式會根據(jù)內(nèi)容相關(guān)性檢索整個文件。

第二階段：引入輕量級 agent——自動路由模式

在實際應(yīng)用中，系統(tǒng)通常無法預(yù)知用戶會提出哪種類型的問題。為了解決這個問題，作者介紹了一種名為「自動路由」（auto_routed）的檢索模式。

該模式本質(zhì)上是一個輕量級的 agent 系統(tǒng)。它會首先分析用戶的查詢，然后智能地判斷應(yīng)該采用上述三種模式（chunk、files_via_metadata 或 files_via_content）中的哪一種來執(zhí)行檢索。這實現(xiàn)了在單一知識庫內(nèi)的檢索策略自動化。

第三階段：擴展至多個知識庫——復(fù)合檢索 API

當(dāng)一個系統(tǒng)需要處理多種不同格式的文檔時（如財報 PDF、會議 PPT、客服記錄等），將它們?nèi)糠旁谝粋€索引中并用相同的解析規(guī)則處理是低效的。更優(yōu)的做法是為每種類型的文檔創(chuàng)建獨立的、高度優(yōu)化的索引。

為了能夠同時查詢這些分散的知識庫，作者介紹了「復(fù)合檢索 API」。其核心功能是：

• 整合多個索引：允許將多個獨立的索引（例如，「財報索引」和「幻燈片索引」）添加到一個復(fù)合檢索器中。
• 智能路由：通過為每個子索引提供描述（例如，「用于公司財務(wù)報告」），復(fù)合檢索器利用一個 agent 層來分析用戶查詢，并將其路由到一個或多個最相關(guān)的子索引。
• 結(jié)果重排：從所有被查詢的索引中收集結(jié)果，并進(jìn)行重排序，最終返回最相關(guān)的 top-n 個結(jié)果。

第四階段：構(gòu)建完全由 agent 驅(qū)動的知識系統(tǒng)

作者的最終目標(biāo)是將上述技術(shù)整合，構(gòu)建一個在每個環(huán)節(jié)都由 agent 進(jìn)行智能決策的、完全自動化的檢索系統(tǒng)。這個系統(tǒng)的運作流程形成了一個雙層 agent 架構(gòu)：

• 頂層 agent（復(fù)合檢索器）：接收到用戶查詢后，該 agent 首先進(jìn)行 LLM 分類，判斷查詢與哪個或哪些知識庫（子索引）最相關(guān)，并將查詢分發(fā)下去。

• 例如，當(dāng)查詢「2024 年第四季度財報中的收入增長情況如何？」時，頂層 agent 會識別出「財報」關(guān)鍵詞，并將查詢路由至 financial_index。

• 子索引層 agent（自動路由模式）：當(dāng)一個特定的子索引接收到查詢后，其內(nèi)部的 auto_routed 模式 agent 會啟動，分析查詢的具體意圖，并決定在該索引內(nèi)部使用最合適的檢索方法（是按區(qū)塊、按文件名還是按內(nèi)容檢索）。

• 例如，對于上述查詢，子索引 agent 可能會判斷這是一個針對特定信息的問題，從而選擇 chunk 模式進(jìn)行精確區(qū)塊檢索。

通過這種分層 agent 的方法，系統(tǒng)能夠以高度動態(tài)和智能化的方式響應(yīng)復(fù)雜多樣的用戶查詢，在正確的時間、從正確的知識庫、用正確的方式獲取最精準(zhǔn)的上下文。

作者總結(jié)道，簡單的 RAG 已經(jīng)過時，智能體驅(qū)動的檢索才是未來。高級檢索服務(wù)通過這種分層、智能的能力，充當(dāng)著高級 AI 智能體不可或缺的「知識骨干」。

別說 RAG 已死，它正成為一門嚴(yán)肅的工程學(xué)科

• 博客文章：Stop Saying RAG Is Dead
  
• 博客地址：https://hamel.dev/notes/llm/rag/not_dead.html

這篇博客的主要作者是資深機器學(xué)習(xí)工程師、曾就職于 GitHub 和 Airbnb 等知名企業(yè)的 Hamel Husain。

文章包含 6 個部分，作者邀請多位專家共同系統(tǒng)性地探討了為什么 RAG 不僅沒有死，反而正以前所未有的重要性，進(jìn)化為構(gòu)建可靠、高效 AI 應(yīng)用的核心工程學(xué)科。

Part 1 & 2: 重新定義 RAG 與評估范式

Ben Clavié（RAGatouille 作者）和 Nandan Thakur（BEIR、FreshStack 基準(zhǔn)測試設(shè)計者）首先澄清了核心誤解。

Clavié 指出，將所有信息塞入長上下文窗口在經(jīng)濟和效率上都是不切實際的。RAG 的本質(zhì)（為語言模型提供其訓(xùn)練時未見的外部知識）是永恒的需求。

我們告別的只是幼稚的單向量語義搜索，正如我們用 CSS 升級 HTML，我們正在用更先進(jìn)的檢索技術(shù)升級 RAG。

Thakur 則顛覆了傳統(tǒng)的評估體系。他認(rèn)為，像 BEIR 這類為傳統(tǒng)搜索引擎設(shè)計的基準(zhǔn)，其目標(biāo)是「找到排名第一的正確答案」，這與 RAG 的目標(biāo)不符。

RAG 系統(tǒng)的檢索目標(biāo)應(yīng)該是：

• 覆蓋率：是否找到了生成答案所需的所有事實證據(jù)？
• 多樣性：是否避免了信息冗余，高效地提供了不同方面的信息？
• 相關(guān)性：檢索到的信息是否切題？

為此，他設(shè)計了 FreshStack 基準(zhǔn)，為衡量現(xiàn)代 RAG 系統(tǒng)的真實性能提供了新的標(biāo)尺。

Part 3 & 4: 新一代檢索模型：會推理、無損壓縮

Orion Weller（約翰霍普金斯大學(xué)）和 Antoine Chaffin（LightOn）介紹了兩種突破性的檢索模型范式，它們讓檢索器本身具備了「思考」能力。

Weller 的研究將大模型的指令遵循和推理能力直接嵌入檢索過程。他展示了兩個模型：

• Promptriever：一個「指令感知」的 bi-encoder 模型，能夠理解并執(zhí)行復(fù)雜指令，如「用隱喻尋找關(guān)于數(shù)據(jù)隱私的文檔」，從而發(fā)現(xiàn)傳統(tǒng)模型無法觸及的結(jié)果。
• Rank1：一個能生成明確推理鏈的 reranker 模型，它通過「思考過程」來判斷相關(guān)性，不僅提升了準(zhǔn)確率，還發(fā)現(xiàn)了許多被以往基準(zhǔn)測試忽略的有效文檔。

Chaffin 則直指單向量檢索的核心缺陷——信息壓縮損失。他介紹了「延遲交互」模型（如 ColBERT），這種模型不將整個文檔壓縮成一個向量，而是保留了每個 token 的向量表示。

這使得一個僅有 150M 參數(shù)的小模型，在推理密集型任務(wù)上的表現(xiàn)甚至超過了 7B 參數(shù)的大模型。同時，PyLate 等開源庫的出現(xiàn)，正讓這種強大的技術(shù)變得前所未有地易于使用。

Part 5 & 6: 架構(gòu)的進(jìn)化：從單一地圖到智能路由與上下文工程

最后兩部分由 Bryan Bischof 和 Ayush Chaurasia，以及 Chroma 公司的 Kelly Hong，將視角從模型本身拉升到系統(tǒng)架構(gòu)和工程實踐。

Bischof 和 Chaurasia 提出，我們不應(yīng)再尋找那個「完美」的嵌入模型或表示方法。正確的做法是，為同一份數(shù)據(jù)創(chuàng)建多種表示，就像為同一個地方準(zhǔn)備多張不同功能的地圖（如地形圖、交通圖）。

然后，利用一個智能「路由器」（通常是一個 LLM Agent）來理解用戶意圖，并將其導(dǎo)向最合適的「地圖」進(jìn)行查詢。他們的「語義點彩藝術(shù)」應(yīng)用生動地展示了這種架構(gòu)的靈活性和強大效果。

Kelly Hong 的研究則為「長上下文萬能論」敲響了警鐘。她提出了「上下文腐爛」現(xiàn)象：隨著輸入上下文的增長，尤其是在存在模糊信息和「干擾項」時，大模型的性能會顯著下降，甚至在簡單任務(wù)上也變得不可靠。這證明了精巧的上下文工程和精準(zhǔn)的檢索比簡單粗暴地填充上下文窗口更為重要。

RAG 的訃告：

被 Agent 殺死，被長上下文掩埋

• 博客文章：The RAG Obituary: Killed by Agents, Buried by Context Windows
  
• 博客地址：https://www.nicolasbustamante.com/p/the-rag-obituary-killed-by-agents

這篇文章的作者是 Fintool 創(chuàng)始人 Nicolas Bustamante，他擁有十年法律和金融搜索平臺構(gòu)建經(jīng)驗，直言整個 RAG 架構(gòu)正在成為一個不必要的、臃腫的歷史包袱。

作者指出 RAG 架構(gòu)從根基上就存在難以克服的「原罪」：

• 切分的困境：RAG 的第一步「切塊」就是災(zāi)難的開始。以一份復(fù)雜的 SEC 10-K 財報為例，強制按固定長度切分，會將表格的標(biāo)題與數(shù)據(jù)分離，風(fēng)險因素的解釋被攔腰斬斷，管理層討論與相關(guān)財務(wù)數(shù)據(jù)脫鉤。作者所在公司 Fintool 雖開發(fā)出保留層級結(jié)構(gòu)、表格完整性、交叉引用等高級切分策略，但這依然是「在碎片上跳舞」，無法解決上下文被物理割裂的根本問題。
• 檢索的噩夢：純粹的向量搜索在專業(yè)領(lǐng)域常常失靈。嵌入模型難以區(qū)分「收入確認(rèn)」（會計政策）和「收入增長」（業(yè)務(wù)表現(xiàn)）這類術(shù)語的細(xì)微差別。文章舉了一個生動的例子：當(dāng)查詢「公司的訴訟風(fēng)險」時，RAG 可能只找到明確提及「訴訟」字眼的段落，從而報告 5 億美元的風(fēng)險；而實際上，加上或有負(fù)債、后續(xù)事項、賠償義務(wù)等其他部分，真實風(fēng)險高達(dá) 51 億美元，相差十倍。
• 無盡的「補丁」：為了彌補向量搜索的不足，業(yè)界引入了混合搜索，結(jié)合關(guān)鍵詞匹配（如 BM25）與向量語義，并通過 RRF 等算法融合結(jié)果。但這還不夠，為了提升最終喂給 LLM 內(nèi)容的質(zhì)量，還需要增加一個「重排序」環(huán)節(jié)。每增加一個環(huán)節(jié)，都意味著延遲的飆升、成本的疊加以及系統(tǒng)復(fù)雜性的指數(shù)級增長。作者將其形容為「級聯(lián)失敗問題」，任何一環(huán)的失誤都會被層層放大。
• 沉重的基礎(chǔ)設(shè)施負(fù)擔(dān)：維護(hù)一個生產(chǎn)級的 Elasticsearch 集群本身就是一項艱巨的任務(wù)，涉及 TB 級的索引數(shù)據(jù)、高昂的內(nèi)存成本、耗時數(shù)天的重建索引以及持續(xù)的版本管理和優(yōu)化。

作者認(rèn)為，智能體（Agent）和 LLM 長上下文窗口這兩項技術(shù)進(jìn)步將直接「殺死」RAG。

作者的「頓悟時刻」來源于 Anthropic 發(fā)布的 Claude Code。他發(fā)現(xiàn)這個編碼助手在沒有使用任何 RAG 的情況下，表現(xiàn)遠(yuǎn)超傳統(tǒng)方法。

其秘訣在于放棄了復(fù)雜的索引管道，回歸了最原始但極其高效的工具：grep（文本搜索）和 glob（文件模式匹配）。

這種「智能體搜索」范式的工作方式是「調(diào)查」而非「檢索」：

• 直接訪問，而非索引：Agent 可以直接在文件系統(tǒng)上運行 grep，實時、高速地查找信息，無需預(yù)處理和索引，也就不存在索引延遲。
• 完整加載，而非碎片：隨著 Claude Sonnet 4 達(dá)到 200K、Gemini 2.5 達(dá)到 1M、甚至 Grok 4-fast 達(dá)到 2M tokens 的上下文窗口，LLM 現(xiàn)在可以直接「讀入」整份財報、整個代碼庫。當(dāng)你可以閱讀全書時，為什么還要滿足于幾張書簽?zāi)兀?/span>
• 邏輯導(dǎo)航，而非相似度匹配：Agent 能夠像人類分析師一樣，在完整文檔中進(jìn)行邏輯跳轉(zhuǎn)。例如，在財報中看到「參見附注 12」，它會直接導(dǎo)航到附注 12，再根據(jù)附注內(nèi)容跳轉(zhuǎn)到其他相關(guān)章節(jié)，從而構(gòu)建一個完整的理解鏈條。

作者的結(jié)論并非要徹底消滅 RAG，而是將其「降級」。在新的范式下，RAG 不再是系統(tǒng)的核心架構(gòu)，而僅僅是 Agent 工具箱中的一個選項。

在面對海量文檔需要初步篩選時，Agent 可能會先用混合搜索（RAG 的核心）進(jìn)行一次粗篩，然后將排名靠前的幾份完整文檔加載到上下文中，進(jìn)行深度分析和推理。

結(jié)語

綜合這三種觀點，我們可以得出一個清晰的結(jié)論：初級的、樸素的 RAG（Naive RAG）確實已經(jīng)「死亡」。那種簡單的「切塊-向量化-相似度搜索」流程，已無法滿足日益復(fù)雜的 AI 應(yīng)用需求。

然而，RAG 本身所代表的核心思想——為 LLM 提供精準(zhǔn)、可靠的外部知識——的需求是永恒的。

未來的圖景更可能是：

• RAG 的角色轉(zhuǎn)變：RAG 不再是所有應(yīng)用的默認(rèn)核心架構(gòu)，而是被「降級」為 Agent 工具箱中的一個強大組件。它將與代碼解釋器、API 調(diào)用、文件系統(tǒng)操作等工具平起平坐。

• 場景決定架構(gòu)：對于需要從海量、非結(jié)構(gòu)化數(shù)據(jù)中快速篩選信息的場景（如智能客服、企業(yè)知識庫初篩），由 Agent 驅(qū)動的、高度工程化的高級 RAG 系統(tǒng)仍是最佳選擇。

• 長上下文的統(tǒng)治力：對于需要對少量、結(jié)構(gòu)復(fù)雜的文檔進(jìn)行深度推理和分析的場景（如財報分析、法律合同審查），「長上下文窗口 + Agent 調(diào)查」的范式將展現(xiàn)出碾壓性的優(yōu)勢。

對于開發(fā)者而言，關(guān)鍵在于理解不同技術(shù)范式的優(yōu)劣，并根據(jù)具體的應(yīng)用場景，靈活地將它們組合成最高效、最可靠的解決方案。

更多細(xì)節(jié)請參看原博客。