作者 | 張穎峰

過去的 2025 年，對于檢索增強(qiáng)生成（RAG）技術(shù)而言，是經(jīng)歷深刻反思、激烈辯論與實質(zhì)性演進(jìn)的一年。

盡管圍繞其“臨時性”與“被替代性”的疑云一直籠罩，但縱觀全年發(fā)展軌跡，RAG 并未如部分激進(jìn)觀點(diǎn)所預(yù)言的那樣黯然退場，反而在企業(yè)級 AI 落地的深水區(qū)中，愈發(fā)彰顯出其作為數(shù)據(jù)基礎(chǔ)設(shè)施的不可替代性。

回顧全年，RAG 的發(fā)展態(tài)勢可謂錯綜復(fù)雜：

一方面，其實際應(yīng)用效果面臨諸多質(zhì)疑，部分源于 RAG 系統(tǒng)自身“易用難精”的調(diào)優(yōu)挑戰(zhàn)；另一方面，其輿論關(guān)注度也似乎被 2025 年大模型應(yīng)用的絕對焦點(diǎn)——AI Agents 所分流。

然而，一個頗具意味的現(xiàn)象是，盡管爭議增多且并非處于流量中心，但真正致力于構(gòu)建核心競爭力、嚴(yán)肅對待 AI 能力建設(shè)的企業(yè)，尤其是中大型組織，對 RAG 的投入反而更為深入和系統(tǒng)化。

RAG 在企業(yè) AI 架構(gòu)中非但未被邊緣化，反而更加穩(wěn)固地扮演著核心角色，其作為關(guān)鍵基礎(chǔ)設(shè)施的地位并未動搖，正如下圖所示，它構(gòu)成了企業(yè)智能能力的堅實底座。

因此，我們首先需要超越表面的爭議，深入審視 RAG 技術(shù)本身的生命力：它究竟只是一種彌補(bǔ)大模型知識缺陷的過渡性“創(chuàng)可貼”方案，還是具備持續(xù)演進(jìn)、并能成為下一代 AI 應(yīng)用基石的架構(gòu)？

要回答這個問題，我們必須系統(tǒng)盤點(diǎn)其在技術(shù)改進(jìn)、架構(gòu)演進(jìn)以及在 Agent 時代所扮演的新角色。

RAG 還能改進(jìn)么？

長上下文和 RAG 之爭

進(jìn)入 2025 年，圍繞 RAG 的諸多爭議，其根源可歸結(jié)為一個核心矛盾：企業(yè)對 RAG “既離不了，又不滿意”的普遍心態(tài)已形成共識。RAG 降低了接入私有知識的門檻，但其效果的穩(wěn)定性和準(zhǔn)確性（尤其是面對復(fù)雜查詢時）往往需要大量精細(xì)調(diào)優(yōu)，這使得其總擁有成本評估變得復(fù)雜。

因此，2024 年學(xué)術(shù)界與投資界熱烈探討的“長上下文（Long Context）能否取代 RAG”的理論命題，在 2025 年迅速進(jìn)入了實踐檢驗階段。部分對延遲和成本相對不敏感、且查詢模式相對固定的場景（如某些類型的合同條款審查、固定格式報告分析），開始嘗試直接利用長上下文窗口，將整篇或大量相關(guān)文檔一次性輸入模型，以期繞過 RAG 檢索可能帶來的信息丟失或噪聲問題，直接緩解對話效果不一致的痛點(diǎn)。

然而，關(guān)于兩者的技術(shù)對比，2024 年以來的研究已給出相對清晰的圖景：在 LLM 上下文窗口中機(jī)械地填充過長文本，本質(zhì)上是一種“暴力堆料”策略，它必然導(dǎo)致模型注意力分散，從而使得回答質(zhì)量顯著下降，產(chǎn)生所謂的“中間迷失”（Lost in the Middle）或“信息淹沒”效應(yīng)。

更重要的是，此舉伴隨著高昂的成本考量——處理長上下文的計算開銷呈非線性增長。

因此，對企業(yè)而言，真正具有實踐價值的思考并非糾結(jié)于“RAG 已死”的口號式辯論，而是回歸問題本質(zhì)：如何將最相關(guān)、最有效的信息，以最高性價比的方式納入模型的上下文處理體系。

這一命題，恰恰是 RAG 技術(shù)設(shè)計的初衷。長上下文能力的提升，非但沒有宣告 RAG 的終結(jié)，反而促使我們更深入地思考兩者如何協(xié)同。例如，可以在 RAG 系統(tǒng)中，利用長上下文窗口來容納更完整、語義更連貫的檢索結(jié)果塊，或者用于多步檢索與反思的中間結(jié)果匯總。

這種“檢索前置，長上下文容納”的協(xié)同模式，正是“上下文工程”（Context Engineering）這一新興領(lǐng)域需求興起的重要源頭。它標(biāo)志著工作重心從單一的“檢索算法”優(yōu)化，轉(zhuǎn)向?qū)Α皺z索 - 上下文組裝 - 模型推理”端到端鏈路的系統(tǒng)性設(shè)計。

當(dāng)前，向 LLM 提供外部知識的輸入范式主要分為四種：

• 單純依賴 LLM 的長上下文能力。

• 借助于 KV Cache 。

• 利用 Grep 等簡易搜索手段。

• 采用完整的 RAG 架構(gòu)。

從成本角度來看，方案 1 與方案 4 之間存在 2 個數(shù)量級的差距。方案 2 即將所有文檔數(shù)據(jù)經(jīng) LLM 前向傳播處理為張量后存入專門的 KV Cache 系統(tǒng)，其成本相比 RAG 仍高出至少一個數(shù)量級。

即便將 KV Cache 升級為數(shù)據(jù)庫與推理一體化引擎（如 AlayaDB【文獻(xiàn) 1】所倡導(dǎo)的路徑），在技術(shù)層面仍存在多重根本性限制：

• 大數(shù)據(jù)量與檢索性能的矛盾：

若預(yù)處理后的張量數(shù)據(jù)總量遠(yuǎn)超 GPU 顯存容量，則系統(tǒng)必須引入二級存儲和相應(yīng)的檢索機(jī)制來實現(xiàn)按需加載。這將導(dǎo)致推理過程變?yōu)椤斑吷蛇吽阉鳌保瑢?I/O 延遲和檢索速度的要求變得極其苛刻。

為了滿足極低延遲，通常不得不將整個數(shù)據(jù)集和 LLM 推理服務(wù)強(qiáng)綁定部署于同一物理機(jī)或高性能計算集群的緊密網(wǎng)絡(luò)域內(nèi)，這在架構(gòu)上極大地犧牲了靈活性與可擴(kuò)展性，限制了業(yè)務(wù)部署形態(tài)。

• 場景局限性：

該方法主要適用于相對靜態(tài)的、以事實性知識問答為主的文本庫，難以靈活、低成本地結(jié)合企業(yè)內(nèi)部復(fù)雜多變的業(yè)務(wù)規(guī)則、實時更新的知識以及進(jìn)行多樣化的組合查詢。

• 技術(shù)融合趨勢：

該方法與 RAG 并不沖突。即該方法未來走向?qū)嵱?，也極有可能被 RAG 技術(shù)體系所吸納和融合，成為 RAG 架構(gòu)中的一個優(yōu)化組件。

方案 3（無索引 RAG）因 Claude Code 為其代碼助手 Agent 引入而受到一定關(guān)注。那么，一個樸素的問題是：在特定領(lǐng)域，簡單的字符串匹配（Grep）能否取代復(fù)雜的基于檢索的 RAG 架構(gòu)？

對于組織良好、格式純粹、術(shù)語固定的代碼庫或某些高度結(jié)構(gòu)化的文本數(shù)據(jù)（如日志文件），基于規(guī)則的 Grep 或關(guān)鍵詞搜索或許能以極低成本獲得不錯的效果，從而節(jié)約索引構(gòu)建與維護(hù)的開銷。

但對于絕大多數(shù)企業(yè)環(huán)境中的多模態(tài)、非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)（如產(chǎn)品手冊、會議紀(jì)要、設(shè)計圖紙、含表格和圖片的報告），此方法則完全失效。

事實上，即使是看似規(guī)則的代碼搜索，領(lǐng)先的產(chǎn)品如 Augment Code 也未采用簡單的 Grep，而是專門微調(diào)了適用于代碼語義的 Embedding 模型。

原因在于，為代碼助手提供有效的上下文，不僅需要精確的字符串匹配（找函數(shù)名），更需要語義近似的代碼片段（實現(xiàn)相似功能的不同寫法）、相關(guān)的 API 文檔以及代碼塊的依賴關(guān)系。

至于企業(yè)級應(yīng)用所必需的多樣化自然語言查詢、高并發(fā)、低延遲響應(yīng)以及結(jié)合業(yè)務(wù)元數(shù)據(jù)的過濾與排序等需求，則更非 Grep 所能覆蓋。

因此，RAG 及其前身——企業(yè)搜索引擎，始終是面向復(fù)雜企業(yè)級需求的綜合性技術(shù)與架構(gòu)解決方案，其價值在于提供一種系統(tǒng)化、可擴(kuò)展、可治理的知識接入與管理能力。

RAG 對話效果的優(yōu)化路徑

回歸 RAG 技術(shù)本質(zhì)，其回答不準(zhǔn)確、不穩(wěn)定的常見根源，源于傳統(tǒng)“分塊 - 嵌入 - 檢索”流水線中存在一個結(jié)構(gòu)性矛盾：使用單一粒度、固定大小的文本塊（Chunk）同時承擔(dān)兩項存在內(nèi)在沖突的任務(wù)：

• 語義匹配（召回）：為了在語義空間中進(jìn)行相似度搜索時獲得高精度召回，需要文本塊較小（如 100-256 個 Token），使其語義焦點(diǎn)明確，減少無關(guān)信息的干擾。

• 上下文理解（利用）：為了向 LLM 提供足夠完整、連貫的上下文以生成優(yōu)質(zhì)回答，需要文本塊較大（如 1024 甚至更多 Token），以保證邏輯的完整性和背景信息的充足。

這導(dǎo)致系統(tǒng)設(shè)計者不得不在“精準(zhǔn)但碎片化”與“完整但模糊”之間進(jìn)行艱難權(quán)衡，常常顧此失彼。小切片可能導(dǎo)致檢索到的信息支離破碎，LLM 無法理解全貌；大切片則可能引入噪聲，降低檢索精度，并且由于向量表示是對整個塊的概括，也會丟失內(nèi)部細(xì)節(jié)的區(qū)分度。

因此，一個根本性的改進(jìn)思路是將 RAG 流程從“一步走”解耦為兩個邏輯階段——“搜索（Search）”與“檢索（Retrieve）”——并允許它們采用不同的文本粒度：

• 搜索（Search）：類比“掃描”或“定位”，核心目標(biāo)是快速、精準(zhǔn)地從海量數(shù)據(jù)中找出所有可能相關(guān)的“線索點(diǎn)”。此階段應(yīng)使用較小的、語義純凈的文本單元，以實現(xiàn)高召回率與高精度。像"掃描"或"定位"，需使用小塊文本以實現(xiàn)高精度的語義匹配。

• 檢索（Retrieve）：類比“閱讀”或“理解”，核心目標(biāo)是為 LLM 組裝出用于生成答案的“閱讀材料”。此階段應(yīng)基于搜索階段得到的線索，動態(tài)地聚合、拼接或擴(kuò)展出更大、更完整、更連貫的上下文片段。

RAGFlow 提出 TreeRAG 技術(shù)，正是這一思想的實踐。它通過借助 LLM 在離線階段自動化地分析文檔，構(gòu)建出層次化的樹狀目錄摘要結(jié)構(gòu)，從而巧妙地橋接了“小粒度搜索”與“大粒度閱讀”之間的鴻溝。其核心工作流體現(xiàn)了“先精準(zhǔn)定位，再展開閱讀”的智慧 ：

• 離線處理（知識結(jié)構(gòu)化）：文檔切分后，先送入 LLM 進(jìn)行分析，生成對應(yīng)的多級樹狀目錄摘要（例如，章 ->節(jié) ->子節(jié) ->關(guān)鍵段落梗概）。同時，還可以為每個節(jié)點(diǎn)或原始切片進(jìn)一步衍生出摘要、關(guān)鍵詞、實體、可能的問題、元數(shù)據(jù)、關(guān)聯(lián)的圖片上下文描述等豐富的語義增強(qiáng)信息。研究表明【文獻(xiàn) 3】，在離線處理階段，對原始切片的精細(xì)度要求可以適當(dāng)放寬，過于復(fù)雜的切分策略有時反而會破壞語義單元，簡單且重疊的切片策略往往在實踐中更有效和健壯。

• 在線檢索（動態(tài) Context 組裝）：當(dāng)用戶查詢到來時，首先使用最細(xì)粒度的“小片段”（原始切片或其摘要）進(jìn)行相似度搜索，實現(xiàn)快速、精準(zhǔn)的初步召回。然后，利用離線構(gòu)建的“樹狀目錄”這一導(dǎo)航圖，根據(jù)召回的切片節(jié)點(diǎn)，迅速定位到其所在的父節(jié)點(diǎn)、兄弟節(jié)點(diǎn)及相鄰節(jié)點(diǎn)，將這些語義相關(guān)的片段自動組合成一個邏輯完整的“大片段”，最后提供給 LLM。這種方法有效解決了因固定粒度切片造成的上下文碎片化問題，確保了提供給模型的材料既包含了精準(zhǔn)匹配的核心信息，也具備了理解該信息所需的周邊語境。

類似的工作還有 PageIndex【文獻(xiàn) 2】，它更側(cè)重于解析和利用文檔本身（如 PDF）固有的物理或邏輯目錄結(jié)構(gòu)。

這種方法在文檔結(jié)構(gòu)清晰、格式規(guī)范時非常高效，但其局限性在于高度依賴源文檔的質(zhì)量，當(dāng)文檔缺乏清晰目錄或目錄不準(zhǔn)確時，其自動定位能力就會大打折扣。

TreeRAG 及其同類技術(shù)有效緩解了因切片不當(dāng)導(dǎo)致的“Lost in the Middle”痛點(diǎn)。

然而，對于某些更為復(fù)雜的查詢，例如問題答案分散在數(shù)十個互不相鄰的切片中、或需要綜合多個獨(dú)立文檔的信息進(jìn)行推理的情況，僅靠樹狀結(jié)構(gòu)可能仍無法全面覆蓋所有關(guān)聯(lián)。

此時，業(yè)界很自然地將目光投向另一條技術(shù)路徑：GraphRAG。GraphRAG 通過從文檔中抽取實體及實體間關(guān)系，構(gòu)建知識圖譜，利用圖查詢與圖推理來發(fā)現(xiàn)間接關(guān)聯(lián)的信息片段。

然而，GraphRAG 自誕生以來，同樣讓許多嘗試者處于“愛恨交加”的境地，其主要挑戰(zhàn)源于以下幾個方面：

• Token 消耗巨大：

實體抽取、去重、社區(qū)摘要等步驟會導(dǎo)致數(shù)倍乃至數(shù)十倍于原文的 Token 消耗。

• 實體抽取質(zhì)量與預(yù)期存在落差：

傳統(tǒng)知識圖譜經(jīng)過領(lǐng)域?qū)＜揖脑O(shè)計與校驗，圖譜質(zhì)量高，可直接用于可視化分析與交互。而 GraphRAG 自動抽取的實體和關(guān)系常包含大量噪聲、冗余或錯誤，若以可視化知識圖譜的標(biāo)準(zhǔn)去審視和使用它，往往會感到失望，陷入“圖表美觀但實用性不強(qiáng)”的尷尬境地。

• 知識碎片化：

即便通過圖算法發(fā)現(xiàn)了關(guān)聯(lián)社區(qū)并生成了摘要，其產(chǎn)出仍然是圍繞特定主題的“知識片段”集合?；谶@些離散的片段去生成最終答案，對 LLM 的整合與連貫敘述能力提出了極高要求，容易產(chǎn)生回答缺乏邏輯主線或遺漏重要側(cè)面信息的問題。 實體和關(guān)系得到的是離散的知識點(diǎn)，即便圍繞社區(qū)生成的摘要也是碎片化的信息，基于此生成的回答難免缺乏連貫性。

由此可見，結(jié)合 TreeRAG 與 GraphRAG 的優(yōu)勢，有望進(jìn)一步緩解 RAG 的痛點(diǎn)：TreeRAG 擅長解決因物理切片導(dǎo)致的局部語義斷裂問題，提供連貫的上下文；GraphRAG 則能基于實體與關(guān)系網(wǎng)絡(luò)，利用圖遍歷算法（如 Personalized PageRank）輔助發(fā)現(xiàn)那些在語義上高度相關(guān)但在原始文檔中物理距離較遠(yuǎn)、甚至跨文檔的內(nèi)容片段。

因此，無論是 TreeRAG、GraphRAG，還是兩者融合的混合架構(gòu)（可以統(tǒng)稱為“長上下文 RAG”），其共同的核心范式都是在傳統(tǒng) RAG 流水線的基礎(chǔ)上，引入了額外的語義增強(qiáng)與結(jié)構(gòu)構(gòu)建層：

在數(shù)據(jù)寫入（Ingestion）階段，不僅進(jìn)行切片，更利用 LLM 進(jìn)行深度的語義理解、摘要生成和結(jié)構(gòu)提?。?/p>

在檢索（Retrieval）階段，則不僅僅依賴搜索，還結(jié)合了基于預(yù)定義結(jié)構(gòu)（樹、圖）的導(dǎo)航、關(guān)聯(lián)查詢和動態(tài)組裝能力。

因此，RAG 技術(shù)遠(yuǎn)非陷入停滯，其改進(jìn)方向正日益清晰：借助 LLM 本身的能力，在數(shù)據(jù)生命周期的早期階段就盡力彌合原始數(shù)據(jù)與最終問答之間的語義鴻溝。

通過在寫入階段使用不同指令的提示詞，多輪次、多角度地請求 LLM 分析文本，從中提取出豐富、多層次的語義信息（元數(shù)據(jù)），并在檢索階段，以這些增強(qiáng)語義為“導(dǎo)航圖”，在單純的向量相似度搜索之外，智能地完成上下文的篩選、聚合與填充。

這才是解決復(fù)雜、開放域問答挑戰(zhàn)的更可靠之道。

RAGFlow 等產(chǎn)品已在此方向展開深入實踐，其未來演進(jìn)將圍繞這些核心點(diǎn)持續(xù)深化。簡而言之，現(xiàn)代 RAG 系統(tǒng)的設(shè)計哲學(xué)是：充分協(xié)同“強(qiáng)大檢索與推理能力”與“有限但寶貴的 LLM 上下文窗口”，通過智能的預(yù)處理與動態(tài)組裝，在效果、性能與成本之間尋求最優(yōu)平衡。

從知識庫到數(shù)據(jù)底座

我們常強(qiáng)調(diào) RAG 本身是一種架構(gòu)范式而非具體應(yīng)用，但不可否認(rèn)，知識庫是 RAG 最直觀和成功的應(yīng)用形態(tài)。

隨著 AI Agent 開發(fā)的蓬勃興起，一個顯著的趨勢是：Agent 的復(fù)雜任務(wù)執(zhí)行越來越離不開對海量、多樣化企業(yè)數(shù)據(jù)的實時訪問與理解。因此，企業(yè)級的 RAG 產(chǎn)品開始超越“問答知識庫”的單一定位，向更底層、更通用的 Agent 數(shù)據(jù)基座演進(jìn)。它需要承擔(dān)起為各類 Agent 提供統(tǒng)一、高效、安全的非結(jié)構(gòu)化數(shù)據(jù)訪問服務(wù)的角色。

為此，一個健壯、可擴(kuò)展和可配置的數(shù)據(jù)注入管道（Ingestion pipeline） 已成為現(xiàn)代 RAG 引擎不可或缺的核心功能模塊。它承擔(dān)著“接管”企業(yè)內(nèi)部紛繁復(fù)雜的非結(jié)構(gòu)化數(shù)據(jù)（文檔、圖片、音視頻、代碼、郵件等），并將其“消化”成 RAG 引擎可索引、可檢索的標(biāo)準(zhǔn)格式的全過程。

如果說 ETL/ELT 是現(xiàn)代數(shù)據(jù)棧中處理結(jié)構(gòu)化數(shù)據(jù)的工業(yè)化標(biāo)準(zhǔn)管線（以 dbt、 Fivetran、 Airbyte 等工具為代表），為數(shù)據(jù)倉庫和數(shù)據(jù)湖提供了統(tǒng)一、靈活且可靠的數(shù)據(jù)集成方案，那么，面向非結(jié)構(gòu)化數(shù)據(jù)的 Ingestion pipeline（或可稱為 PTI: Parse-Transform-Index） 就是其在 AI 時代對等的關(guān)鍵基礎(chǔ)設(shè)施。

兩者在架構(gòu)定位與處理哲學(xué)上高度相似，但在具體技術(shù)手段上因數(shù)據(jù)特質(zhì)不同而有所區(qū)分，其核心環(huán)節(jié)對比如下圖所示：

具體來看各個環(huán)節(jié)的異同：

• Extract 與 Parsing：傳統(tǒng) ETL/ELT 的“Extract”階段主要從關(guān)系型數(shù)據(jù)庫、API、日志文件等結(jié)構(gòu)化或半結(jié)構(gòu)化源中抽取數(shù)據(jù)。而 Ingestion pipeline 在此基礎(chǔ)上，強(qiáng)化了“Parsing”環(huán)節(jié)，以專門攻克非結(jié)構(gòu)化數(shù)據(jù)的信息提取難題。

該環(huán)節(jié)需要綜合利用各種解析器，例如：用于 PDF /Word 的格式解析器、RAGFlow 自帶的 DeepDoc 專用文檔智能解析模型、基于視覺語言模型（VLM）微調(diào)的 OCR 模型等。其目標(biāo)是將多模態(tài)、多格式的原始文檔，轉(zhuǎn)化為純凈、結(jié)構(gòu)化的文本表示，并盡可能保留原始的邏輯結(jié)構(gòu)（如標(biāo)題、列表、表格）和元信息（如作者、日期）。

• Transform：這是兩者差異最大的環(huán)節(jié)。傳統(tǒng) ETL/ELT 的“Transform”側(cè)重于基于 SQL 或代碼進(jìn)行數(shù)據(jù)清洗、格式標(biāo)準(zhǔn)化、業(yè)務(wù)邏輯計算（如聚合、關(guān)聯(lián)）等。

而 Ingestion pipeline 的“Transform”階段，則是以 LLM 為核心的一系列語義理解與增強(qiáng)算子。它們負(fù)責(zé)把 Parser 輸出的原始文本流，轉(zhuǎn)變成檢索階段所需的各種高級“素材”。除了基礎(chǔ)的文本分塊（Chunking）外，前述的樹狀結(jié)構(gòu)生成、知識圖譜（實體 - 關(guān)系）抽取、摘要生成、問題生成、關(guān)鍵詞提取等所有旨在提升檢索效果與精度的處理，都在這個步驟完成。這個階段是注入“智能”的關(guān)鍵，決定了數(shù)據(jù)被“理解”的深度。

• Load 與 Indexing： 傳統(tǒng) ETL/ELT 將處理后的干凈數(shù)據(jù)加載（Load）到目標(biāo)數(shù)據(jù)倉庫或數(shù)據(jù)湖表中。而 RAG 引擎則通過“Indexing”模塊，將 Transform 階段產(chǎn)出的豐富內(nèi)容（原始文本塊、摘要、向量、元數(shù)據(jù)、圖關(guān)系等）構(gòu)建成適合多種檢索方式的高效索引。

這是因為 RAG 引擎本質(zhì)上是一個高并發(fā)、低延遲的檢索服務(wù)層（Serving layer），它需要支持混合檢索（向量檢索 + 關(guān)鍵詞檢索 + 元數(shù)據(jù)過濾）、并可能集成上述的樹檢索、圖查詢等高級能力。

無論是處理結(jié)構(gòu)化數(shù)據(jù)的 ETL，還是處理非結(jié)構(gòu)化數(shù)據(jù)的 PTI，中間的“轉(zhuǎn)換（Transform）”步驟都是價值創(chuàng)造的核心環(huán)節(jié)。

對于 ETL，工程師需要根據(jù)具體的業(yè)務(wù)分析需求，精心設(shè)計轉(zhuǎn)換邏輯（SQL）；對于 PTI，由于 Ingestion pipeline 必須與最終的檢索（Retrieval）需求端到端協(xié)同設(shè)計，因此需要根據(jù)上層應(yīng)用（如問答、摘要、分析）對精度、速度、成本的不同要求，來決定 Transform 階段應(yīng)該采用何種粒度的切片、生成何種類型的增強(qiáng)語義、構(gòu)建何種復(fù)雜度的索引結(jié)構(gòu)。

因此，構(gòu)建優(yōu)秀 RAG 系統(tǒng)的關(guān)鍵點(diǎn)，并非僅僅在于選擇了某個最先進(jìn)的 Parser 模型或某款高性能的向量數(shù)據(jù)庫，而在于對整個“數(shù)據(jù)注入 -> 語義增強(qiáng) -> 索引構(gòu)建 -> 檢索服務(wù)”鏈路的協(xié)同設(shè)計與持續(xù)調(diào)優(yōu)。

當(dāng) RAG 系統(tǒng)具備了這樣強(qiáng)大、靈活且智能的 Ingestion pipeline，它就真正從一個“問答系統(tǒng)”升級為企業(yè)級非結(jié)構(gòu)化數(shù)據(jù)的統(tǒng)一處理與訪問平臺。它能夠以標(biāo)準(zhǔn)化、自動化的方式，消化企業(yè)內(nèi)部散落各處的知識資產(chǎn)，并將其轉(zhuǎn)化為可供 AI Agent 隨時調(diào)用的“燃料”。

這也是為何今天，當(dāng)企業(yè)決心構(gòu)建統(tǒng)一的 AI 能力中臺時，該中臺的核心與基石必然，也只能是這樣一個以 RAG 引擎為核心的、具備強(qiáng)大數(shù)據(jù)處理能力的數(shù)據(jù)底座。它為企業(yè)所有的 AI 應(yīng)用提供了唯一可信、實時更新的知識來源。

從 RAG 到 Context

2025 年 LLM 應(yīng)用側(cè)最火熱、最引人注目的無疑是各式各樣的 AI Agent。

從 Agent 框架的視角來看，它可以視 RAG 為一個提供外部知識訪問能力的工具（Tool） ，就如同調(diào)用計算器、查詢天氣 API 或操作數(shù)據(jù)庫的工具一樣。這種工具化的視角，加之“Agentic RAG”（利用 Agent 的規(guī)劃、反思等能力來增強(qiáng) RAG 流程本身）概念的興起，使得“RAG 將被更通用的 Agent 取代”或“RAG 只是 Agent 的一種普通工具”的論調(diào)在 2025 年尤其盛行。

然而，這種觀點(diǎn)可能過于簡化，甚至誤解了 RAG 在 Agent 生態(tài)中的根本價值與地位。

它忽視了 RAG 架構(gòu)的本質(zhì)——其核心能力與價值基石在于檢索（Retrieval），而并非僅僅在于“增強(qiáng)生成”。正是“高效、準(zhǔn)確、可擴(kuò)展地從海量私有數(shù)據(jù)中檢索相關(guān)信息”這一核心能力，使得 RAG 有潛力成為，且正在成為 Agent 最不可或缺、最基礎(chǔ)的數(shù)據(jù)底座。

因為無論多么智能的 Agent，其決策與行動的質(zhì)量，在根本上都取決于它所獲得的上下文（Context） 的質(zhì)量與相關(guān)性。如何為不同的任務(wù)、在不同的時刻，動態(tài)地、智能地組裝出最有效的上下文，成為了 2025 年下半年業(yè)界最熱門的技術(shù)探索與實踐指導(dǎo)原則，這就是上下文工程（Context Engineering）。

讓我們深入剖析 Context Engineering 所涉及的主要數(shù)據(jù)類型和技術(shù)，來理解為何“檢索”處于其絕對的核心：

Context Engineering 之所以成為一個獨(dú)立的工程領(lǐng)域，正是因為實踐反復(fù)證明：簡單粗暴地將所有可能相關(guān)的數(shù)據(jù)都塞進(jìn) LLM 的上下文窗口，不僅會導(dǎo)致成本無法承受，更會因信息過載而嚴(yán)重?fù)p害 LLM 的理解、推理與工具調(diào)用能力。因此，智能地篩選、排序、拼接上下文成為必須。

一個典型的 Agent 上下文通常需要精心組裝三類數(shù)據(jù)：

• 領(lǐng)域知識數(shù)據(jù)：

對于作為核心工具的知識庫（即 RAG 系統(tǒng)）來說，檢索結(jié)果的質(zhì)量直接決定答案成敗。返回過多無關(guān)片段會引入噪聲，干擾答案生成；遺漏關(guān)鍵片段則必然導(dǎo)致事實性錯誤或答案不完整。因此，RAG 本身就可以被視作最早期的、針對領(lǐng)域知識的上下文工程 1.0 實踐。

• 工具數(shù)據(jù)：

對于其他功能工具，特別是通過模型上下文協(xié)議（Model Context Protocol, MCP）等標(biāo)準(zhǔn)封裝的大量工具而言，其描述信息（名稱、功能、參數(shù)說明）本身也是上下文的一部分。當(dāng)可用工具只有少數(shù)幾個時，可以將其描述全部硬編碼在提示詞中。但在企業(yè)級場景下，通過 MCP 包裝的內(nèi)部服務(wù)、API、函數(shù)可能達(dá)到數(shù)百甚至上千個，每次對話都由人工或靜態(tài)規(guī)則指定調(diào)用哪幾個工具是不現(xiàn)實的。

這個“工具選擇”難題直到 2025 年底才被部分用戶深刻感知，甚至引發(fā)了《誕生才一周年，MCP 涼了》這樣的標(biāo)題黨文章【文獻(xiàn) 9】。

實際上，文章作者抱怨錯了對象——問題癥結(jié)在于將所有工具描述不加區(qū)分地堆進(jìn)上下文，導(dǎo)致 LLM “選擇困難癥”爆發(fā)，而非 MCP 協(xié)議本身。MCP 是一個極重要的協(xié)議，其目標(biāo)在于統(tǒng)一工具調(diào)用的接口標(biāo)準(zhǔn)，但它并不負(fù)責(zé)、也無法解決“在特定情境下該選擇哪個工具”的決策問題。

那么，這個決策責(zé)任應(yīng)該由誰承擔(dān)？這正是當(dāng)前多數(shù) Agent 框架缺失的關(guān)鍵一環(huán)。

答案依然是檢索 (Retrieval)。我們需要通過對所有工具描述信息進(jìn)行語義搜索，并結(jié)合對過往工具使用歷史中形成的“技巧”（Skills）、“操作手冊”（Playbook）或“最佳實踐指南”（Guideline）進(jìn)行檢索，才能動態(tài)地、精準(zhǔn)地為當(dāng)前 Agent 的當(dāng)前任務(wù)，篩選出最相關(guān)、最可能被正確使用的工具子集和工具調(diào)用參數(shù)放入上下文。

這遠(yuǎn)非當(dāng)前的 Anthropic Skills 等產(chǎn)品特性所能涵蓋。如何將 Skills / Playbook / Guideline 的生成、檢索與使用形成閉環(huán)并產(chǎn)品化，是 Context Engineering 必須解決的核心問題，這本質(zhì)上是一個數(shù)據(jù)基礎(chǔ)設(shè)施（Infra）問題，而非單純的模型能力問題。

• 會話和狀態(tài)數(shù)據(jù)：

除了靜態(tài)知識和工具，上下文還需要包含動態(tài)的、與當(dāng)前交互相關(guān)的數(shù)據(jù)，例如：當(dāng)前會話的歷史消息、用戶的個性化信息與偏好、以及部分 Agent 的內(nèi)部狀態(tài)信息（例如 Human-in-the-loop 中的人工輸入）。

這類數(shù)據(jù)的管理與訪問常被形象地稱為“記憶（Memory）”，它在 2025 年上半年至年中成為獨(dú)立的熱門概念。但從技術(shù)實現(xiàn)內(nèi)核看，記憶系統(tǒng)的核心能力——對歷史交互信息的存儲、索引與檢索——與 RAG 并無本質(zhì)區(qū)別，可以看作是針對特定數(shù)據(jù)源（會話日志）和特定使用模式（更強(qiáng)調(diào)時序和會話關(guān)聯(lián)）的檢索系統(tǒng)特化版。

通過對上下文組成的解構(gòu)，我們可以清晰地看到，Context Engineering 的核心任務(wù)，仍然是基于 Agent 所需三大類數(shù)據(jù)源的檢索：

• 針對企業(yè)私有化、非結(jié)構(gòu)化的領(lǐng)域文檔數(shù)據(jù)的檢索——即 RAG。

• 針對 Agent 交互過程中產(chǎn)生的會話歷史與狀態(tài)數(shù)據(jù)，特別是 LLM 生成內(nèi)容的檢索——即記憶（Memory）。

• 針對企業(yè)現(xiàn)有服務(wù)與 API 封裝而成的工具描述及使用指南數(shù)據(jù)的檢索——可稱之為工具檢索（Tool Retrieval），這類數(shù)據(jù)同樣可以放入專用區(qū)域如 Memory。

由此可見，RAG 技術(shù)在 AI Agent 時代將無可爭議地升級，它不再僅僅是“檢索增強(qiáng)生成”中的一個環(huán)節(jié)，而是以“檢索”為核心能力，擴(kuò)展其數(shù)據(jù)范疇，演進(jìn)為支撐所有上下文組裝需求的上下文引擎（Context Engine），真正成為服務(wù)于 LLM 應(yīng)用的、統(tǒng)一的上下文層（Context Layer）與數(shù)據(jù)底座。

Agent 所需的 Retrieval vs 傳統(tǒng)搜索

理解這種演進(jìn)，需要對比傳統(tǒng)搜索時代與 Agent 時代檢索范式的根本差異：

在傳統(tǒng)搜索時代（如使用谷歌或企業(yè)內(nèi)搜索），檢索的發(fā)起者、執(zhí)行者和結(jié)果消費(fèi)者都是人。用戶提出問題，搜索引擎返回一系列相關(guān)文檔鏈接，用戶需要自己打開多個鏈接，閱讀、比較、綜合信息，最終形成答案或決策。這是一個“人機(jī)協(xié)同、人工主導(dǎo)”的循環(huán)。

而在 Agent 時代，檢索的發(fā)起者和初級消費(fèi)者是 Agent（由 LLM 驅(qū)動）。其典型工作流是：LLM 首先對用戶復(fù)雜問題進(jìn)行理解與拆解（假設(shè) / 規(guī)劃），然后代表用戶自動發(fā)起一次或多次檢索請求，接著對檢索返回的原始結(jié)果進(jìn)行理解、核驗與提煉（反思），最后將加工后的信息拼接成最終生成答案的上下文。檢索的內(nèi)容也從單一的網(wǎng)頁或文檔，擴(kuò)展到工具使用、記憶片段等。

整個“問題理解 -> 檢索 -> 結(jié)果處理 -> 上下文組裝”的閉環(huán)是由 Agent 自動完成的。

因此，Agent 所需的檢索系統(tǒng)面臨著前所未有的新要求：

請求頻率極高（可能會超過傳統(tǒng)搜索時代人類發(fā)出的檢索請求次數(shù)的一到兩個數(shù)量級）、查詢類型多樣化（對文檔的語義查詢、對工具的關(guān)鍵詞匹配、對工具使用指導(dǎo)的參數(shù)匹配、對記憶的關(guān)聯(lián)查詢）、延遲要求苛刻（直接影響 Agent 的響應(yīng)速度）、需要與 Agent 的推理流程緊密耦合。

這遠(yuǎn)非一個獨(dú)立的搜索引擎或向量數(shù)據(jù)庫所能滿足。它需要在存儲與索引層之上，構(gòu)建一個智能的中間服務(wù)層，該層理解 Agent 的意圖，能根據(jù)上下文組裝策略，動態(tài)地協(xié)調(diào)對背后不同數(shù)據(jù)源（文檔庫、記憶庫、工具庫）的檢索請求，并對結(jié)果進(jìn)行必要的融合、去重、排序與格式化，最終打包成 LLM-ready 的上下文。

這種使用模式，意味著 Agent 開發(fā)中最為繁瑣和專業(yè)的“上下文工程”部分，有望從高度手工、嵌入在提示詞硬編碼中的狀態(tài)，走向聲明式配置甚至自動化，從而大幅降低 Agent 開發(fā)與維護(hù)的復(fù)雜度，提升其效果的一致性與可復(fù)用性。

工具也是需要搜索的

工具的多樣性直接決定了 Agent 能夠解決問題的廣度和深度。

在簡單的演示或原型開發(fā)中，常見的做法是將所有可用工具的描述（通常是一段自然語言文本）一次性全部嵌入 Agent 的提示詞中。

然而，當(dāng)工具數(shù)量從幾個增長到幾十個、幾百個時，這種做法的弊端將暴露無遺：首先，它占用了大量寶貴的上下文 Token，這些 Token 本可用于容納更重要的任務(wù)描述和中間結(jié)果；其次，過多的選項會給 LLM 的工具選擇邏輯帶來巨大負(fù)擔(dān)，增加其“幻覺”調(diào)用或選擇錯誤工具的概率。

特別是在企業(yè)級場景中，工具的數(shù)量可能達(dá)到驚人的規(guī)模。因為從理念上講，幾乎所有現(xiàn)有的企業(yè)內(nèi)部服務(wù)、數(shù)據(jù)庫、API 和工作流，都可以被包裝成 Agent 可以理解和調(diào)用的標(biāo)準(zhǔn)化工具接口。這正是 MCP 等協(xié)議致力于解決的問題——成為 Agent 時代的“TCP/IP”，解決連通性問題。

但必須清醒認(rèn)識到，MCP 解決的是“如何調(diào)用”的協(xié)議問題，而不是“應(yīng)該調(diào)用哪個”的決策問題。優(yōu)秀的模型（如一些正在研發(fā)的 SOTA 模型）或許能在上下文中勉強(qiáng)處理數(shù)百個工具描述，但這絕非高性價比的解決方案。將上下文窗口視為稀缺資源，盡可能少地填入無效或低概率使用的信息，對于控制成本和提升整體系統(tǒng)效果都是至關(guān)重要的設(shè)計原則。

因此，工具檢索（Tool Retrieval） 在 2025 年底開始受到學(xué)術(shù)界和業(yè)界的前沿關(guān)注。

其核心思想是：為所有工具建立一個專門的描述信息索引庫（可以是向量索引，也可以是關(guān)鍵詞索引，或兩者混合）。當(dāng) Agent 需要調(diào)用工具時，先根據(jù)當(dāng)前對話的上下文和任務(wù)目標(biāo)，生成一個針對工具功能的“查詢”，去這個索引庫中進(jìn)行快速檢索，只召回最相關(guān)的少數(shù)幾個（例如 Top-3）工具描述，并將其動態(tài)插入到當(dāng)前上下文中，供 LLM 進(jìn)行最終的選擇和調(diào)用。

研究表明【文獻(xiàn) 10】，即使是簡單的 BM25 關(guān)鍵詞檢索算法，在這個任務(wù)上也能作為一個很強(qiáng)的基線（Baseline）方法。當(dāng)然，使用經(jīng)過微調(diào)的專用嵌入模型，能夠獲得更精準(zhǔn)的匹配結(jié)果。

除了工具本身的描述信息，在 Agent 的開發(fā)、測試和實際使用過程中，還會自然沉淀出一系列關(guān)于“如何正確使用工具”的元知識。例如：“在處理客戶退款請求時，應(yīng)依次調(diào)用 A 工具驗證訂單、B 工具檢查庫存、C 工具執(zhí)行退款，且參數(shù) X 必須來自會話歷史 Y?！边@類“操作手冊”或“攻略”性文本，是比工具描述更豐富、更具指導(dǎo)性的上下文素材。

它們同樣應(yīng)該被納入可檢索的體系：當(dāng) Agent 面臨一個復(fù)雜任務(wù)時，可以先檢索相關(guān)的任務(wù)指南，將指南作為上下文的一部分，這樣 LLM 就能像“開卷考試”一樣，遵循最佳實踐來規(guī)劃行動。

這類關(guān)于工具使用的指南數(shù)據(jù)，其數(shù)量和數(shù)據(jù)密度可能遠(yuǎn)大于工具描述本身，對其的高效利用毫無疑問必須依賴于檢索技術(shù)。早期的探索如 Dspy 框架中的 GEPA 優(yōu)化器【文獻(xiàn) 11】，它利用遺傳算法自動演化出更好的提示詞（可能包含工具使用邏輯），但其焦點(diǎn)在于優(yōu)化提示詞文本本身。

而更系統(tǒng)的工作如 ACE（Agentic Context Engineering）框架【文獻(xiàn) 12】，開始體系化地研究如何生成、管理和利用這類指導(dǎo)性上下文。雖然這不屬于本文的重點(diǎn)，但我們必須認(rèn)識到，這代表了 Context Engineering 向深度發(fā)展的一個重要方向，而這類工作產(chǎn)生的結(jié)果，必然毫無疑問需要被納入到 Retrieval 需要涵蓋的體系之中，連同工具描述一起提供上下文。

Memory 值得成為單獨(dú)的 Infra 么？

“記憶”在 2025 年的技術(shù)討論中獲得了遠(yuǎn)高于 RAG 的關(guān)注度，常被各類文章和產(chǎn)品宣傳列為 Agent 基礎(chǔ)設(shè)施層的核心組件之一，甚至出現(xiàn)了“記憶將取代 RAG ”等模糊邊界的觀點(diǎn)。

那么，記憶究竟是什么？層出不窮的開源記憶項目與 RAG 系統(tǒng)在底層上有何區(qū)別與聯(lián)系？

簡而言之，記憶系統(tǒng)的出現(xiàn)，最初是為了滿足對 Agent 歷史交互信息進(jìn)行有效管理和再利用的需求。

其基本使用模式與 RAG 如出一轍：當(dāng)新的對話發(fā)生時，系統(tǒng)根據(jù)當(dāng)前查詢，從存儲的歷史會話記錄中檢索出相關(guān)的過往對話片段（例如，同一用戶之前的提問、LLM 之前的回答、用戶的反饋等），然后將這些片段作為上下文的一部分，與新問題一起提交給 LLM，以便模型能保持對話的連貫性、記住用戶偏好或避免重復(fù)。因此，從功能接口和核心技術(shù)（檢索） 上看，記憶與 RAG 共享同一內(nèi)核。

它們的核心區(qū)別在于數(shù)據(jù)來源與管理目標(biāo)：

• RAG：處理的數(shù)據(jù)主要是預(yù)先存在的、相對靜態(tài)的企業(yè)私有知識資產(chǎn)（文檔、手冊、知識庫文章等）。其目標(biāo)是提供領(lǐng)域事實和背景知識。

• 記憶：處理的數(shù)據(jù)主要是 Agent 在運(yùn)行過程中動態(tài)產(chǎn)生的交互日志與派生數(shù)據(jù)（用戶輸入、LLM 輸出、可能的交互狀態(tài)、由 LLM 生成的摘要或反思等）。其目標(biāo)是維持會話的連續(xù)性、實現(xiàn)個性化、以及從歷史經(jīng)驗中學(xué)習(xí)。

隨著研究的深入，記憶系統(tǒng)內(nèi)部的數(shù)據(jù)組織也出現(xiàn)了更精細(xì)的劃分，借鑒了認(rèn)知科學(xué)中的概念，通常包括 Working Memory ，Episodic Memory，Semantic Memory，Meta Memory 等。這些不同的“記憶區(qū)域”，在實現(xiàn)上可以類比為數(shù)據(jù)庫中的不同表或集合。

記憶系統(tǒng)的復(fù)雜性不僅在于存儲和檢索，更在于記憶的管理邏輯：新產(chǎn)生的原始對話何時、以何種方式被寫入記憶？何時觸發(fā) LLM 對一段對話進(jìn)行摘要，并將摘要存入語義記憶？如何建立不同記憶片段之間的關(guān)聯(lián)？這些“記憶的流轉(zhuǎn)、加工與生命周期管理”功能，其地位完全等價于 RAG 系統(tǒng)中的 Ingestion pipeline，只不過它處理的是動態(tài)產(chǎn)生的流式數(shù)據(jù)。

如果我們把視野放大，在記憶系統(tǒng)中專門劃分出一個區(qū)域（或單獨(dú)建立一個緊密關(guān)聯(lián)的知識庫）來存儲和檢索上文提到的工具使用指南，那么，一個支撐 AI Agent 的完整數(shù)據(jù)基座的藍(lán)圖就清晰浮現(xiàn)了：

這個藍(lán)圖清晰地表明：記憶（處理動態(tài)交互數(shù)據(jù)）與 RAG（處理靜態(tài)領(lǐng)域知識）在技術(shù)上同源（均基于檢索），在功能上互補(bǔ)，共同構(gòu)成了 AI Agents 賴以生存的完整數(shù)據(jù)基座。

所有 Agent 對數(shù)據(jù)的訪問需求——無論是已有的非結(jié)構(gòu)化文檔（通過 RAG）、實時產(chǎn)生的交互日志（通過記憶），還是結(jié)構(gòu)化的服務(wù)接口（通過 MCP 封裝，其元數(shù)據(jù)、使用指導(dǎo)和攻略的檢索可納入專用知識庫）——都可以被統(tǒng)一規(guī)劃、治理和接入到一個一體化的平臺中。

這個平臺，正是像 RAGFlow 這樣的系統(tǒng)正在演進(jìn)的方向：上下文引擎（Context Engine）或上下文平臺（Context Platform）。它不再是一個孤立的檢索工具，而是一個為 AI 應(yīng)用提供全方位、智能化上下文組裝服務(wù)的基礎(chǔ)設(shè)施。

從上下文工程到上下文平臺

“Context Platform” 這一前瞻性提法，可能最早由投資機(jī)構(gòu) Theory Ventures 在其系列文章中系統(tǒng)闡述【文獻(xiàn) 13, 14】。事實上，這家富有遠(yuǎn)見的機(jī)構(gòu)早在 2024 年就旗幟鮮明地指出了檢索對于 LLM 應(yīng)用的根本重要性【文獻(xiàn) 15】。

時至今日，如何將技術(shù)視角的 Retrieval Engine 升級為 Context Engine，正在成為決定 AI Agent 能否在企業(yè)中規(guī)?；?、低成本落地的關(guān)鍵勝負(fù)手。

從前文的全面分析可見，許多所謂“Agent 智能”要解決的問題，其本質(zhì)仍然是在正確的時間，為 LLM 找到并呈現(xiàn)正確的信息。如果 Agent 能擁有一個強(qiáng)大的“外腦”（Context Engine），幫助它高效地查找、篩選、驗證和梳理所有相關(guān)數(shù)據(jù)，那么用戶最終獲得的體驗和結(jié)果將遠(yuǎn)超一個僅依靠龐大參數(shù)和復(fù)雜提示詞的“裸”模型。

從 Context Engineering 到 Context Engine / Platform，這標(biāo)志著上下文的創(chuàng)建、管理與交付，正從一項高度依賴專家經(jīng)驗的手工藝術(shù)，向高度自動化、產(chǎn)品化和可運(yùn)維的平臺科學(xué)演進(jìn)。

當(dāng)前企業(yè)在開發(fā)定制 Agent 時，往往需要投入大量工程師和數(shù)據(jù)科學(xué)家手工編寫復(fù)雜的提示詞模板，精心設(shè)計上下文拼接邏輯，并硬編碼到工作流編排中。這種方式難以維護(hù)、無法規(guī)?；?，且上下文的所有權(quán)和更新流程混亂。

未來的上下文平臺將致力于改變這一現(xiàn)狀：

• 上下文的創(chuàng)建將通過與數(shù)據(jù)源的深度集成自動完成，并持續(xù)同步更新。

• 上下文的交付將不再是硬編碼的，而是根據(jù)每次對話的實時意圖，通過平臺統(tǒng)一的檢索與編排層，動態(tài)地從各類數(shù)據(jù)源中檢索、組裝而成。

• 上下文的維護(hù)將從供應(yīng)商主導(dǎo)的手動服務(wù)，轉(zhuǎn)變?yōu)榭蛻艨勺灾鞴芾?、可視化配置的自動化流程，上下文的所有?quán)和控制權(quán)將明確歸屬于客戶。

這帶來的范式轉(zhuǎn)變是巨大的：企業(yè) AI 落地的核心價值，正從追求“最智能的模型”和“最巧妙的提示詞”，回歸到構(gòu)建“最豐富、最準(zhǔn)確、最易用的上下文”。

上下文的質(zhì)量、實時性、動態(tài)組裝能力和產(chǎn)品化水平，將直接決定下一代企業(yè) AI 應(yīng)用的競爭力。上下文的產(chǎn)品化，將是解鎖 AI 大規(guī)模應(yīng)用的最后一道關(guān)鍵枷鎖。它標(biāo)志著企業(yè) AI 正式從“手工作坊式定制”的早期階段，邁入“平臺化、可擴(kuò)展、可持續(xù)運(yùn)營”的工業(yè)化時代。

多模態(tài) RAG 進(jìn)展

在 2024 年的年終回顧中，我們曾預(yù)測以“延遲交互”為基座的多模態(tài) RAG 將成為 2025 年的技術(shù)關(guān)鍵詞。然而，這一預(yù)測并未完全成為現(xiàn)實。

這是否意味著多模態(tài) RAG 缺乏實際意義？

答案顯然是否定的。以專門針對醫(yī)療文獻(xiàn)設(shè)計的基準(zhǔn)數(shù)據(jù)集 M3Retrieve【文獻(xiàn) 4】的測試結(jié)果為例，多模態(tài) RAG 的價值與定位已得到清晰印證：

• 在圖文結(jié)合任務(wù)中表現(xiàn)卓越：在視覺上下文檢索、基于圖像的問答等場景下，多模態(tài) RAG 能夠綜合利用文本與視覺信息，表現(xiàn)顯著優(yōu)于純文本方案。

• 在文本主導(dǎo)任務(wù)中優(yōu)勢不顯：對于摘要生成、純文本病例檢索等任務(wù)，成熟的單模態(tài) RAG 憑借其高效與精準(zhǔn)，依然占據(jù)優(yōu)勢。

由此可見，產(chǎn)品級的多模態(tài) RAG 并非簡單地將圖像與文本模型拼接，其核心需求在于實現(xiàn)真正高效的跨模態(tài)檢索與理解。從技術(shù)演進(jìn)脈絡(luò)看，多模態(tài) RAG 無疑是 RAG 體系深入發(fā)展、覆蓋更廣泛數(shù)據(jù)類型的必然方向。

當(dāng)前，處理圖文等多模態(tài)文檔主要存在兩種技術(shù)路徑：

• 模態(tài)轉(zhuǎn)換路徑：

借助 OCR 或 VLM（視覺語言模型），將圖像、表格等內(nèi)容轉(zhuǎn)化為純文本描述，從而將多模態(tài)問題降維為單模態(tài)的文本檢索問題。這種方法兼容現(xiàn)有文本 RAG 架構(gòu)，但可能丟失原始視覺布局、顏色、細(xì)微特征等關(guān)鍵信息。

• 原生多模態(tài)路徑：

將圖像直接進(jìn)行視覺分詞（Tokenize），與文本 Token 一同輸入統(tǒng)一的多模態(tài)編碼器，生成融合的多向量（Multi-Vector）表示。在檢索排序階段，則借助延遲交互（Late Interaction）模型進(jìn)行精細(xì)化的相似度計算。

其流程可概括為下圖：

Google DeepMind 在今年 9 月發(fā)表的理論指導(dǎo)文章【文獻(xiàn) 5】明確指出，基于單一的全局向量進(jìn)行檢索存在固有的語義損失，而使用多向量（即高維張量）表示能夠更完整地保留文檔的細(xì)粒度語義信息。

既然理論優(yōu)勢如此明確，為何在 2025 年仍未涌現(xiàn)出成熟的、產(chǎn)品化的多模態(tài) RAG 解決方案？

其根本原因在于從技術(shù)原型到穩(wěn)定產(chǎn)品的工程化挑戰(zhàn)尚未被完全攻克。

工程化跨模態(tài)檢索的首要挑戰(zhàn)是確定召回單元與檢索策略。以文檔“頁”為召回單元是常見做法，具體實施方案包括：

• 混合索引方案：為文本內(nèi)容同時建立全文索引和張量索引，為圖片建立獨(dú)立的張量索引。檢索時，對三種索引進(jìn)行混合搜索與結(jié)果融合。

• 文本為主、張量重排方案：僅利用 PDF 解析出的文本，建立全文和單向量索引進(jìn)行初步召回，然后利用將整頁作為圖像生成的張量表示，對初篩結(jié)果進(jìn)行精細(xì)化重排。此方案也可用于純文本檢索，以獲取更好的語義召回效果。

• 純張量檢索方案：完全依賴張量索引。對于跨模態(tài)頁面，分別計算查詢與文本張量、圖像張量的相似度，取最大值作為該頁的最終相關(guān)性得分。

盡管上述方案在技術(shù)上均可行，但它們共同面臨一個棘手的工程化瓶頸：因 Token 數(shù)量爆炸導(dǎo)致的張量數(shù)據(jù)存儲與計算開銷激增。

假設(shè)使用類似 ColPali 的模型，默認(rèn)每頁圖像輸出 1024 個 Token（每個 Token 對應(yīng)一個特征向量），每個向量維度為 128，采用 float32 精度存儲，那么僅一頁圖像對應(yīng)的張量數(shù)據(jù)就需占用約 512KB 空間。對于一個百萬頁級別的文檔庫，其索引體積將膨脹至 TB 級別，這對存儲成本、內(nèi)存加載和檢索延遲都是巨大挑戰(zhàn)。

要推動多模態(tài) RAG 走向工程實用化，目前主要有兩條技術(shù)路徑可供實踐：

• 張量量化壓縮：

對張量中的每個向量進(jìn)行二值化或低比特量化（如用 1 個比特表示），可將存儲壓縮至原來的 1/32 甚至更低。代價是會引入一定的精度損失。這條路徑的可行性，取決于能否訓(xùn)練出對量化操作魯棒性強(qiáng)的專用嵌入模型。

• Token 剪枝：

顯著減少每頁圖像生成的 Token 數(shù)量，例如從 1024 個降至 128 個或更少。具體實現(xiàn)方法包括：

• 隨機(jī)投影：將大量 Token 對應(yīng)的向量投影到單個高維（如 1 萬維）向量中，如 MUVERA 算法【文獻(xiàn) 6】。這種方法計算高效，但會損失較多的細(xì)粒度信息。

• Token 聚類：對生成的 Token 對應(yīng)的向量進(jìn)行無監(jiān)督聚類，用聚類中心代表原始集合。該方法不依賴模型改動，但同樣會犧牲精度。

• 模型端 Token 剪枝：改造 Embedding 模型（特別是其底層的 VLM），使其能夠根據(jù)內(nèi)部注意力機(jī)制主動輸出更少但信息量更大的“精煉” Token。這是最根本的方法。

因此，多模態(tài) RAG 的成熟不僅要求底層檢索引擎具備對張量索引（Tensor Index）和張量重排器（Tensor Reranker） 的原生高效支持，更有賴于整個 AI 社區(qū)涌現(xiàn)出更多對量化友好、支持自適應(yīng) Token 剪枝的下一代多模態(tài) Embedding 模型。

這兩者的發(fā)展相輔相成：缺乏成熟易用的 Retrieval Engine，會阻礙新模型在真實場景中的驗證與迭代；而沒有高效的模型，Retrieval Engine 也無用武之地。所幸的是，這個話題已經(jīng)引起了廣泛重視，專門以延遲交互為主題的 Workshop 也將在 26 年上半年舉行【文獻(xiàn) 7】。

展望 2026 年，隨著 AI 基礎(chǔ)設(shè)施層對張量計算與存儲的支持日益完善，我們有望看到更多為工程化量身定制的優(yōu)秀多模態(tài)模型問世，從而真正解鎖跨模態(tài) RAG 的實用潛力。

而它的工程化落地，將自然而然地催生多模態(tài)上下文的普遍需求——例如，能夠同時理解和記憶文本、圖像乃至視頻的“多模態(tài)記憶”系統(tǒng)已不再是理論設(shè)想，而是進(jìn)入了原型研發(fā)階段【文獻(xiàn) 16】。

展望 2026

邁入 2026 年，企業(yè)對 LLM 應(yīng)用的關(guān)注點(diǎn)，必將從概念驗證與早期嘗鮮，轉(zhuǎn)向規(guī)?；涞嘏c投資回報的務(wù)實階段。在這一進(jìn)程中，作為整個 AI 應(yīng)用數(shù)據(jù)基座層的 RAG 技術(shù)，將迎來更為堅實、體系化的建設(shè)浪潮。

如果說 AI Agent 在企業(yè)復(fù)雜場景中的終極價值與形態(tài)尚處于廣泛探索期，那么 RAG 對于所有 Agent 乃至 LLM 應(yīng)用的基礎(chǔ)支撐作用，已成為越來越多技術(shù)決策者的共識。

一個明顯的趨勢是：許多企業(yè)已率先啟動以“AI 中臺”或“智能數(shù)據(jù)底座”為核心的能力建設(shè)，而其樞紐正是以 RAG 引擎為基座的非結(jié)構(gòu)化數(shù)據(jù)處理與供給平臺。相比之下，上層 Agent 的具體構(gòu)建與引入，反而可以基于這一穩(wěn)固底座，以更靈活、更循序漸進(jìn)的節(jié)奏展開。

若要用一句話概括從 2025 到 2026 年 RAG 技術(shù)的演進(jìn)軌跡與未來展望，那便是：RAG 將完成其自身的深刻蛻變，從“檢索增強(qiáng)生成”的特定模式，升維為以“智能檢索”為核心能力的“上下文引擎（Context Engine）”。 這一演進(jìn)趨勢已不可逆轉(zhuǎn)，并必將從技術(shù)后臺走向戰(zhàn)略前臺，成為企業(yè)構(gòu)建下一代智能化基礎(chǔ)設(shè)施時不可或缺的核心組件。

而 RAGFlow，正是為這一宏大而確定的未來圖景而生。

我們所構(gòu)建的，不僅僅是一個開源的高效 RAG 系統(tǒng)，更是通往“上下文引擎”時代的關(guān)鍵基石與推進(jìn)器。從深耕多模態(tài)解析與語義增強(qiáng)的 DeepDoc，到探索 TreeRAG 等前沿架構(gòu)以彌合語義鴻溝，再到打造服務(wù)于 Agent 的上下文引擎——RAGFlow 的每一次迭代，都旨在將文中探討的技術(shù)方向，轉(zhuǎn)化為穩(wěn)定、易用、高性能的產(chǎn)品能力，推動企業(yè)智能化從構(gòu)想穩(wěn)步邁向現(xiàn)實。

我們堅信，以檢索為核心的 Context Engine，是釋放 LLM 與 Agent 全部潛能的關(guān)鍵。

歡迎持續(xù)關(guān)注 RAGFlow 的演進(jìn)，并前往 GitHub 點(diǎn)亮 Star，與全球開發(fā)者一同，見證并參與構(gòu)建下一代企業(yè) AI 的基礎(chǔ)設(shè)施。

參考文獻(xiàn)

AlayaDB: The Data Foundation for Efficient and Effective Long-context LLM Inference https://arxiv.org/abs/2504.10326?

https://github.com/VectifyAI/PageIndex

A Systematic Framework for Enterprise Knowledge Retrieval: Leveraging LLM-Generated Metadata to Enhance RAG Systems https://arxiv.org/abs/2512.05411

M3Retrieve: Benchmarking Multimodal Retrieval for Medicine https://arxiv.org/abs/2510.06888

On the Theoretical Limitations of Embedding-Based Retrieval https://arxiv.org/abs/2508.21038

MUVERA: Multi-Vector Retrieval via Fixed Dimensional Encodings https://arxiv.org/abs/2405.19504

https://www.lateinteraction.com/

https://huggingface.co/blog/QuentinJG/introducing-vidore-v3

誕生才一周年，MCP 涼了

https://huggingface.co/datasets/bowang0911/ToolSearch

Dspy GEPA https://dspy.ai/api/optimizers/GEPA/overview/

Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models https://arxiv.org/abs/2510.04618

Why the Business Context Layer Is the Key to Making AI Work in Enterprise https://theoryvc.com/blog-posts/business-context-layer

From Context Engineering to Context Platforms https://theoryvc.com/blog-posts/from-context-engineering-to-context-platforms

https://www.linkedin.com/pulse/every-llm-company-search-hard-future-retrieval-systems-7zigc/

MemVerse: Multimodal Memory for Lifelong Learning Agents https://arxiv.org/abs/2512.03627

作者簡介

張穎峰，資深技術(shù)創(chuàng)業(yè)者，現(xiàn)為領(lǐng)先開源項目 RAGFlow 的聯(lián)合創(chuàng)始人。RAGFlow 是一款廣受歡迎的企業(yè)級 RAG 引擎，在其主導(dǎo)下于 GitHub 已收獲 7 萬星標(biāo)，成為業(yè)界在知識檢索與 Agent 開發(fā)領(lǐng)域廣泛采用的開源解決方案。其本人擁有多年基礎(chǔ)設(shè)施與人工智能核心算法的研發(fā)經(jīng)驗，曾支撐過億級用戶規(guī)模的業(yè)務(wù)系統(tǒng)，致力于通過扎實的技術(shù)產(chǎn)品推動企業(yè)實現(xiàn)智能化升級。