RAG 又死了嗎？

人們對 RAG 究竟是愛中帶恨還是恨中帶愛，實在難說。

根據最近在 X 和 HN 上的討論，RAG 應該已經死了，又一次。這次，批評者聚焦於大多數 RAG 框架的過度工程化問題。正如 @jeremyphoward @HamelHusain @Yampeleg 所展示的，這些功能只需 20 行 Python 程式碼就能實現。

上一次出現這種氛圍是在具有超長上下文視窗的 Claude/Gemini 發布後不久。這次更糟的是，就連 Google 的 RAG 也產生了滑稽的結果，正如 @icreatelife @mark_riedl 所展示的。這很諷刺，因為在四月份的拉斯維加斯 Google Next 大會上，Google 將 RAG 作為基礎解決方案進行展示。

tagRAG 的兩大問題

我發現當今的 RAG 框架和解決方案存在兩個問題。

tag僅有前向傳遞

首先，幾乎所有的 RAG 框架只實現了「前向傳遞」路徑，而缺乏「反向傳播」路徑。這是一個不完整的系統。我記得 @swyx 在 @latentspacepod 的一集中提到，RAG 不會被 LLMs 的長上下文視窗殺死，因為：

長上下文對開發者來說成本高昂
長上下文難以除錯且缺乏可分解性

但如果所有 RAG 框架只專注於前向路徑，它怎麼會比 LLM 更容易除錯呢？有趣的是，許多人對某些隨機概念驗證中 RAG 的自動神奇結果過度興奮，完全忘記了在沒有反向調整的情況下增加更多前向層是個糟糕的主意。我們都知道，為神經網路增加一層會擴展其參數空間，從而增強其表示能力，使其能夠做更多潛在的事情，但沒有訓練，這一切都是徒勞的。灣區有一些新創公司正在做評估工作——本質上是試圖評估前向傳遞系統的損失。這有用嗎？有。但它有助於完成 RAG 的閉環嗎？沒有。

那麼誰在研究 RAG 的反向傳播呢？據我所知不多。我最熟悉的是來自 @stanfordnlp @lateinteraction 的 DSPy 庫，它將使命定位於此。

但即使對於 DSPy 來說，主要焦點也是在優化少量示例，而不是整個系統（或至少從社群使用來看是如此）。但為什麼這個問題很困難？因為信號非常稀疏，優化一個不可微分的流水線系統本質上是一個組合問題——換句話說，極其困難。我在博士期間學習了一些子模塊優化，我感覺這項技術將在 RAG 優化中發揮很好的作用。

tag現實世界中的基礎化很困難

儘管 Google 的搜索結果很滑稽，但我同意 RAG 是用於基礎化的。基礎化有兩種類型：搜索基礎化，使用搜索引擎來擴展 LLMs 的世界知識，以及檢查基礎化，使用私有知識（例如專有資料）來做事實核查。

在這兩種情況下，它都會引用外部知識來提高結果的事實性，前提是這些外部資源是可信的。在 Google 的滑稽搜索結果中，人們可以輕易看出網路上並非所有內容都是可信的（是的，大驚喜，誰能想到！），這使搜索基礎化看起來很糟糕。但我相信你現在只能笑笑。Google 搜索 UI 背後有一些隱含的反饋機制，會收集使用者對這些結果的反應，並權衡網站的可信度以實現更好的基礎化。總的來說，這應該只是暫時的，因為這個 RAG 只需要度過冷啟動期，結果就會隨著時間改善。

展示 Jina AI 搜索流程的圖表，包含「搜索基礎化」、「私有知識」和「檢查基礎化」區塊，以及相關的 U — 啟發 Jina Reader 的兩種基礎化類型

tag我的看法

RAG 既不是死亡也不是活著；所以別再爭論這個了。RAG 只是你可以使用的一種演算法模式。但如果你把它當作是唯一的演算法並加以崇拜，那麼你就是活在自己製造的泡沫中，而這個泡沫終將破滅。