您的RAG流水線可能毫無用處。這裏有一個更好的替代方案

檢索增強生成（RAG）已成為將文檔與大語言模型（LLM）連接的標準方法。其模式簡單：對語料庫進行嵌入，通過向量相似性檢索最相關的塊，並將其注入提示中。在演示和許多生產系統中，這種方法效果良好，但也會以可預測、有記錄的方式失敗，且這些失敗只有在規模擴大時才會顯現。

最常見的失敗模式是檢索不相關。用户查詢產假政策，檢索器返回2022年版本、2024年版本以及一篇文化博客文章。每個塊由於與查詢共享詞彙而在嵌入距離上得分很高，但都沒有回答用户實際提出的問題。模型不知道檢索到的內容已過時或離題，它將多個塊混合成一個自信、詳細但事實錯誤的答案。這是主題相似性而非事實相關性，是生產RAG系統中的主導失敗模式。

另一種更微妙的失敗是上下文污染。企業知識庫通常包含同一政策文檔的多個版本。當檢索器返回不同版本的塊時，模型不會指出矛盾，而是選擇其中一個、混合兩者，或呈現一個自信的綜合答案。讀者得到一個答案，但答案可能是錯誤的。用户和模型都不知道這一點。

根本原因在於塊-嵌入-檢索流程中的結構性衝突。良好的召回需要小塊（約100-256個token）以實現聚焦檢索，而良好的上下文理解需要大塊（1024個token以上）以保證連貫性。每個RAG設計者都只能選擇其一併接受權衡。

當標準RAG表現不佳時，常見的修復方法是使其更復雜：更高維的嵌入、更精細的重排序、多步檢索。但這隻會加劇問題。一家全球製造公司為其RAG系統預算40萬美元，第一年實際花費120萬美元，技術文檔查詢的最終準確率僅為23%，項目被終止。一家醫療企業在第六個月時向量數據庫成本達到每月7.5萬美元。這些結果反映了一個更廣泛的模式：2025年企業RAG實施的第一年失敗率為72%。更高維的嵌入和更復雜的向量模型並不會自動提高性能，它們只會提高計算成本，並推遲一個更有用的問題：檢索架構本身是否是正確的選擇。

當RAG失敗時，有以下替代方案：

長上下文提示：如果語料庫適合模型的上下文窗口，直接加載並讓模型閲讀。一項基準研究發現，當計算資源可用時，長上下文LLM在問答任務上始終優於RAG，而基於塊的檢索表現最差。成本權衡顯著：在100萬token時，延遲比RAG流水線慢30-60倍，每次查詢成本約為1250倍。但對於高流量應用，通過提示緩存，長上下文可以變得具有成本競爭力。一個常見的決策規則：如果語料庫適合上下文窗口且查詢量適中，長上下文提示是更乾淨的起點。僅在語料庫超出窗口、延遲違反SLO或查詢量超過經濟盈虧平衡點時，再添加檢索。

記憶壓縮：當語料庫太大而無法放入上下文窗口時，在檢索前進行摘要。基於摘要的檢索在注入前壓縮文檔，而不是提取原始塊。基準測試顯示，這種方法的表現與完整長上下文方法相當，而基於塊的檢索始終落後於兩者。一個具體結果：使用精心選擇的4.8萬個token的保序RAG方法，在13個F1分數點上優於使用11.7萬個token的全上下文檢索，而token預算僅為後者的七分之一。一個壓縮良好的相關文檔勝過一堆粗略相關的原始塊。

結構化檢索：當檢索是正確架構時，解決方案是根據查詢類型進行路由，而不是統一應用更好的嵌入。EMNLP 2024的研究引入了Self-Route，讓模型在運行前分類查詢是否需要全文上下文或聚焦檢索。簡單事實查找走聚焦RAG，需要全局理解的複雜多跳問題走長上下文。結果是在更低計算成本下獲得更好的整體準確率。使用這種混合方法的自適應系統通過混合搜索和重排序顯示出15-30%的檢索精度提升。關鍵變化是使路由顯式化：每個查詢在運行任何檢索前被分類，系統不再將所有查詢視為相同的嵌入問題。

圖譜推理：對於需要理解數據集內關係而非獲取特定段落的查詢，向量檢索天生失敗。這些是多跳問題：董事會在第三季度推翻了哪些決定，每次的陳述理由是什麼？沒有單個塊能回答這個問題，答案存在於文檔之間的連接中。微軟研究院在2024年引入了GraphRAG，該系統從語料庫構建知識圖譜，然後遍歷實體關係而非匹配向量。它直接解決了標準RAG無法處理的失敗情況：需要關係推理的跨文檔綜合。代價是成本：知識圖譜提取比基線RAG貴3-5倍，並且需要領域特定調優。GraphRAG對於主題分析和多跳推理值得開銷，但對於單段落事實查找則不然。

RAG是許多用例的合理默認選擇，但它以可預測的方式失效：詞彙匹配但語義偏離時的檢索不相關，語料庫中存在矛盾版本時的上下文污染，以及塊大小無法同時滿足召回和連貫性時的結構性限制。給一個破碎的檢索設計增加複雜性只會使問題更昂貴。有四個更好的路徑，取決於具體情況：如果語料庫適合上下文窗口，長上下文提示完全避免檢索問題；如果需要上下文壓縮，檢索前摘要優於原始塊檢索；如果查詢類型多樣，顯式路由與結構化檢索提高準確性和成本效益；如果查詢需要文檔間的關係綜合，圖譜推理是正確架構。將架構與查詢類型匹配。