RAG 的未來，走向繁榮、重塑還是消亡？

作者 | AICon 全球人工智能開發與應用大會

策劃 | 李忠良

檢索增強生成 RAG 技術通過提供可靠且最新的外部知識，有效提升了大語言模型的輸出質量，極大地便利了各類任務，並對多個行業產生了日益顯著的影響。隨着 RAG 技術的持續進步和應用領域的擴展，其在企業實際落地中所面臨的侷限性與技術挑戰也逐漸顯現，亟需進一步的探索與改進。

12 月 14 日，在 AICon 全球人工智能開發與應用大會 2024 北京站【RAG 在企業落地的難點與創新】專題圓桌交流中，百度研究院商業智能實驗室負責人周景博博士擔任主持人，與百度靈醫大模型底座技術負責人夏源、Hugging Face Machine Learning Engineer 尹一峰、火山引擎技術專家田昕暉、阿里雲高級技術專家費躍，共同探討 RAG 技術在不同領域中的應用維度。

部分精彩觀點如下：

將 RAG 和 O1 相結合，能夠進一步提升推理效果。

不同的模型就像不同個性的人。

未來的趨勢可能是將 RAG 和 agent 結合起來，形成更加綜合的系統。

RAG 通過將外部知識庫的檢索與生成模型相結合，顯著提升了生成內容的時效性、準確性，顯著降低了幻覺率。如何應用和優化 GraphRAG、 Agentic RAG 等技術來提升複雜問題的解答能力；如何融合文本、圖像、音頻等多種數據形式的跨模態 RAG 的最新進展和應用創新？即將於 2025 年 4 月 10-12 日召開的 QCon 全球軟件開發大會（北京站）將給大家帶來相關實踐案例，直擊痛點，解鎖可複製的經驗與模式。如果你也有相關案例想要分享，歡迎通過以下鏈接提交演講申請：https://jsj.top/f/tUOLpz

以下內容基於現場速記整理，經 InfoQ 刪減。

周景博：RAG 對於 O1 類推理模型的意義何在？

夏源：首先，我想簡要介紹一下目前學界和業界對某些實現方案的看法。比如在訓練階段，需要大量涉及推理邏輯的數據。爲了獲取這樣的推理邏輯數據，通常採用的方式之一是通過人工介入，預先標註一批推理邏輯路徑數據，先建立一個種子模型，一旦有了這個種子模型，就可以進行訓練並人工合成推理數據，再將其輸入到模型中，以保證模型在輸出時具有思考過程。

目前，在推理階段業界猜測 O1 使用了谷歌提出 Testing Scaling Law（測試推理階段的規模化法則）的方式。我們希望在訓練完成後，能夠通過生成多個推理路徑進行選擇。例如，可以採用 MCTS（蒙特卡洛樹搜索）或 RL（強化學習）結合 PRM（過程獎勵模型）的方法，針對模型生成的每條路徑進行評估和打分。通過這種方式，我們可以篩選出最關鍵的推理路徑，從而達到優化推理效果的目的。然而，這種方法在訓練推理階段消耗算力較大，需要對每一步路徑進行評分。

關於 O1 模型，它在解決數學和物理問題上的表現非常突出，尤其是能夠解決一些強推理問題，比如數學競賽題。然而，當我們將其應用到真實世界的場景時，如醫療、金融等行業時，單純使用 O1 模型並不適用。比如我嘗試讓 O1 回答“_ 速福達是否適合 5 歲小孩使用？_”這個問題時，得到的結果錯誤且離譜。這是因爲 O1 只是一個推理強的模型，它並未引入真實世界的知識。爲了解決這一問題，我認爲 RAG 在 O1 模型中起到非常重要的作用。O1 作爲一個具有規劃能力的模型，擅長在推理過程中做得很好，但要使其適應實際應用，需要結合 RAG 來引入更多的領域知識。

我還想談談 O1 模型中的 PRM 打分問題。O1 模型依賴於其內化的知識來進行推理和打分，但對於一些真實問題，比如醫療領域的藥品適應症，它可能缺乏足夠的知識。因此，通過將 RAG 引入 O1 模型，能夠在 PRM 環節引入真實的知識，並提高模型在特定業務場景中的判斷能力。

我認爲將 RAG 和 O1 相結合，能夠進一步提升在真實世界場景的推理效果。然而，目前面臨的挑戰在於如何有效地標註數據，特別是在 RAG 階段。人工標註的成本很高，因此需要更多依賴合成數據，這也是未來的大趨勢。

周景博：在 RAG 場景中，數據引擎的檢索能力還有哪些潛在的改進空間？

田昕暉：首先，我們觀察到現在在信息檢索領域，關於檢索能力的需求達成了普遍共識。比如，涉及到向量檢索、稠密和稀疏檢索、文本搜索以及混合搜索等方向。這些都是目前較爲關注的重點。

接下來，我認爲目前數據引擎和大模型結合的潛力還未得到充分挖掘，尤其是像“Text to SQL”這種應用場景。如何更好地利用現有的大量結構化數據，尤其是如何讓大模型更好地利用計算引擎的強大計算能力，這是一個亟待解決的問題。例如，複雜查詢的處理和優化器的設計，已經在計算引擎領域有很多年的積累和性能優化，但如何讓大模型能夠更充分地利用現有數據引擎的能力，以獲得更復雜的計算結果，仍是一個值得探索的方向。

從引擎的角度來看，我認爲我們可能可以進一步深入探討如何將大模型與數據引擎進行更加緊密的結合。當前，大模型調用鏈路中的數據引擎僅佔據了一個較小的環節，後續是否可以進一步深入，將數據引擎作爲大模型調用鏈路中的重要組成部分，從而支持更加複雜的應用場景。

費躍：從數據引擎用戶的角度來看，我們曾與多個做向量數據庫的團隊有過密切合作，發現了一些目前的問題。最初，向量數據庫只支持單一的密集向量檢索，後來隨着需求增加，開始支持混合檢索和全文搜索。然而，一些新的索引技術，如稀疏向量，ColBERT 多向量等等，大部分數據庫還沒有支持，更不用說目前比較火熱的圖結構索引了。這讓我覺得數據檢索引擎應該有更加統一的索引協議，減少下游用戶使用的困難。

此外，向量數據庫與 embedding 模型有較深的綁定關係，但由於 embedding 由客戶選擇，無法在創建時指定特定類型。當知識庫創建後再改變 embedding 模型會出現不一致的問題，因此可能需要引入 Meta Data 審查機制，確保索引數據的一致性。

另一個問題是查詢鏈路的執行過程，雖然介紹了很多算法，但對下游用戶而言仍然是黑盒。我們是否可以借鑑數據庫的思想，優化查詢鏈路，進行調試、版本控制，引入容災備份等核心功能？對於新興的純向量數據庫，這可能是一個挑戰。

觀衆：在做金融場景的年報解析時，對於一些專有名詞，大模型找不到正確的向量。有什麼解決方法？

費躍：看起來像語義不匹配的問題。

尹一峰：這個模型你們訓練了嗎？

觀衆：沒有，直接用 OpenAI 的。

尹一峰：OpenAI 上的金融數據很少，建議換一個模型。

觀衆：但我覺得這不是模型本身的問題，就是你無論用什麼模型，它都存在這個問題。

尹一峰：因爲向量很大，你可能把 200 個字壓成了一個向量，但是你要的信息可能只是這一段話裡一小段，這是你產品的問題了。你可以制定 hierarchy，把 trunk 做得很小很小，然後做 context enrichment，就能實現精準定位。

周景博：除了 RAG，還有哪些方法可以減少大型語言模型的幻覺問題並提高回答的準確性？

尹一峰：我們將同一問題分別交給三個大型模型——Gemini、Claude 和 GPT，看看它們的回答是否一致。如果三者回答相同，說明答案基本可信，因爲它們同時出錯的概率非常小。

要降低錯誤率，可以通過優化模型來提升其表現。模型只是我們工作流中的一環，輸入可以在進入模型前進行處理，輸出後也可以做進一步操作，如分類或聚類，以驗證其一致性。如果想大幅降低錯誤率，需要投入大量精力，尤其是在簡單場景下可以每月調整一次模型合作階段。複雜場景則難以做到如此低的錯誤率。

模型錯誤率受隨機性和領域知識掌握程度影響。隨機性意味着同一問題給模型兩次，可能得到不同的答案；領域知識掌握得越深入，錯誤率越低。部分模型經過後期訓練，可以明確告知“不知道”。不過，要讓模型達到這種能力，成本非常高。

周景博：一個不確定的問題，可以多問幾個模型看一看，但是不知道將來會不會這些模型的答案最終會收斂到同一個值上去。

尹一峰：所有模型的預訓練數據可能是相似的，通常來自 CC 數據集，但它們的後期訓練數據差異很大。因此，不同的模型就像不同個性的人。例如，Claude 注重安全性，表現得像一個 60 歲的老者，謹慎且不敢冒險；Gemini 則像是一個充滿驚喜的黃毛青年，偶爾給你帶來意外的回答；而 GPT 更像是一個大學生，時常表現出天真與自信，即便犯錯也不願承認。我們可以根據問題的特點和模型的特性，決定信任哪個模型。

田昕暉：模型的準確度可以通過多種機器學習技巧來提升，很多方法可以在數據引擎中通過算子實現。例如，使用多模型比較或評估精度的策略。從數據引擎的角度來看，我認爲可以將這種流水線式的處理方式整合到數據引擎中。若數據引擎能夠支持機器學習中的最佳實踐，如複用和抽象，那麼我們就可以將這些方法轉化爲數據操作算子，甚至構建成一個流水線，提升使用的便利性和可操作性。

觀衆：MOE 模型對於幻覺解決是否能帶來一些幫助？

夏源：MOE 最初並不是爲了解決幻覺問題，而是爲了解決推理速度。雖然 MOE 的效果很好，但它的核心目的是在推理時通過選擇性調用專家模型來加速推理過程，而不是全量運行。原始的技術報告和論文也沒有提到 MOE 能解決幻覺問題。MOE 應用減少的原因可能是由於最初其創新性吸引了大量關注，尤其是在 LLaMa 模型較弱時，大家認爲 MOE 是更好的選擇。然而，後續實踐表明，增加數據量和訓練輪次同樣能提升效果，導致 MOE 的使用逐漸減少。

觀衆：老師能再詳細解釋一下對 Claude、Gemini 和 GPT 的比喻嗎？國內的大模型也能這樣比喻嗎？

尹一峰：在硅谷，生意通常有三種類型：第一種是降維打擊，比如特斯拉用電動汽車替代傳統燃油車；第二種是“挖金子，我賣水”，即通過提供基礎設施支持來盈利；第三種是差異化競爭，即在相似產品中定位不同市場。例如，Anthropic 專注於安全；OpenAI 則更側重於幫助用戶解決問題，而且它不喜歡說“不”，不願意承認自己不懂；Gemini 的模型則表現得比較不穩定，其目標和定位不太明確。相比之下，國內的模型大多沒有明顯的“性格”，缺乏差異化競爭的優勢，這與國外的商業策略不同。

目前，Transformer 架構的潛力幾乎已經被挖掘殆盡，很多技術問題已經成爲組合學問題，選擇不同的激活函數等已經不再具有突破性的科技含量。因此，商業決策成爲了主要的推動力，模型的設計往往取決於企業的商業目標。國內的大模型往往缺乏個性和鮮明的市場定位，大家做的東西差不多，競爭非常激烈。

周景博：最近市面上出現了很多開源類的 RAG 類產品，如何看待這類產品的競爭力，以及他們未來的商業模式？

費躍：我覺得現在很多開源產品都做得很不錯，尤其是在易用性方面。比如在構建大模型應用的流程和交互上，它們做得很用心。開源產品的優勢在於它們非常適合初創公司或者用於快速驗證想法，也能很好地應用於一些不需要特別複雜的嚴肅場景，或者體量較小的服務，可以用開源工具像 Dify、fastgpt 這樣的方案快速部署和嘗試。

至於開源產品潛在的商業模式，我認爲一種是通過建立自己的 SaaS 服務，另一種是和雲廠商合作，像 Dify 與 AWS 的合作，通過 AWS 的資源提供高階版本和企業級支持。

田昕暉：一個產品能否成功商業化並且穩定落地，關鍵在於其壁壘有多強，以及其生態系統是否能夠防止被撬動。如果一個框架太過相似、沒有明顯的差異化，那麼它就容易被其他產品取代。因此，產品的成功不僅要看框架的設計，更要看它是否能在某些場景中與生態緊密結合，形成不可替代的壁壘。

開源對於提升差異性有幫助嗎？我覺得現在的開源框架的確很多都很相似，大家都在集中討論如何找到一種最適合大模型的框架，能在多種場景中良好運作。每個人都可以根據自己的需求做出定製，框架的定義變得非常靈活，因此還沒有一個特別穩定的調用方式。

但開源框架在大模型的演進中仍然非常重要，因爲它們提供了一個探索和共識的過程。就像關係數據庫模型的演進一樣，開源推動了共識的形成。當我們確定了一些基本的框架和調用方式後，接下來就是看哪些大模型框架能在這基礎上持續發展，並推動更多的創新。所以，開源生態對 RAG 模型的構建是非常有幫助的。

尹一峰：我覺得這些專注於 RAG 的公司，比如 LangChain、LangGraph 和 LLaMa Index，可能面臨的最大挑戰是它們的應用場景比較窄，可能難以像 Docker 那樣廣泛普及。Docker 的應用幾乎是所有軟件開發者都需要的，而這些 RAG 框架，雖然在某些場景下很有用，但對於很多工程師來說，尤其是高水平的工程師，這些框架提供的功能並沒有特別大的優勢。如果你能寫 Python 代碼，使用這些框架可能需要花費更多的時間和精力，而實際上自己寫代碼可能會更簡潔、更優雅。

舉例來說，LangChain 現在已經變得有點繁瑣，許多優秀的工程師覺得它不夠簡潔和優雅，開始選擇自己動手開發解決方案。因此，儘管它們現在可能有一定的市場，但最終能否達到 Docker 的水平，我並不看好。它們可能最終成爲一些愛好者項目，或者在市場競爭中逐漸被淘汰。

夏源：我認爲，目前的 RAG 開源架構對於通用領域的應用可能有一定的價值，但對於垂直行業來說，它們的適用性非常有限。大部分現有的框架集中在檢索環節，而檢索只是整個 RAG 流程的一部分。即使檢索做得再好，如果前置的內容理解不足，結果依然不理想。就像常說的，“垃圾進，垃圾出”。

例如，在處理金融表格時，即使檢索很好，若前期沒有將表格內容整理好，直接將表格上傳到模型中，效果會大打折扣。一個更好的方法可能是先將表格解析成結構化的數據（，再結合類似於 Pandas 這樣的工具進行數據處理，然後用代理模型來進一步分析。這種方法相比直接放入未處理的表格可能更有效。

周景博：未來 RAG，是否有希望發展成類似像數據庫一樣的獨立基礎設施？

夏源：狹義的 RAG 通常指的是僅僅在中間環節進行檢索，但我認爲這種做法最終會融入到更大的框架中。其實，Agent 可以看作是更廣義的 RAG，因爲它不僅僅限於檢索環節，可能還包括了召回、數據庫查詢，甚至是基於其他模型的結果或校驗工具。未來的趨勢可能是將 RAG 和 Agent 結合起來，形成更加綜合的系統。

尹一峰：我把 RAG 類比爲 Docker，因爲 Docker 已經成爲底層基礎設施的一部分，而我認爲 RAG 也有類似的潛力。Docker 的成功在於它被許多 SaaS 公司作爲基礎架構的一部分，類似於一種“載體”幫助他們構建產品。未來，RAG 也可能會被一些大型模型，如 LLaMa，所吸收，但我認爲它不會完全消失。

田昕暉：我認爲 RAG 能否發展出自己的一套通用範式是關鍵。如果能的話，它就有可能沿着數據庫的發展路徑，逐步形成類似於“Schema”和“Data Model”的概念。同時，RAG 的核心也還是和大模型的調用環節相關，無論是與 Agent 結合，還是與其他 PE 技術融合。最近，也有一些大佬在討論 LMOS（大模型操作系統）這一概念，大家似乎都在朝這個方向探索。

費躍：我認爲 RAG 肯定會成爲一個獨立的基礎設施，並且大模型可能會將其納入其中，作爲一個模塊或單元。未來，大模型可能會發展成一個複雜的系統，類似於夏老師提到的 Agent 和 RAG 將是其中的一部分。

會議推薦

在 AI 大模型技術如洶涌浪潮席捲軟件開發領域的當下，變革與機遇交織，挑戰與突破共生。2025 年 4 月 10 - 12 日，QCon 全球軟件開發大會將在北京召開，以 “智能融合，引領未來” 爲年度主題，匯聚各領域的技術先行者以及創新實踐者，爲行業發展撥雲見日。現在報名可以享受 8 折優惠，單張門票立省 1360 元，詳情可聯繫票務經理 18514549229 諮詢。

今日薦文

你也「在看」嗎？