我大部分時間都在構建和改進 Retrieval-Augmented Generation (RAG) 應用。

我相信 RAG 可能是最受歡迎的 AI 應用之一。它無處不在，從聊天機器人到文檔摘要。

圖片

我也相信，由于各種原因，許多 RAG 應用最終未能部署，其中很多并非技術原因。然而，我希望自己早知道一些技術方面的知識，以創建更有效的 RAG。

但這就是我們學習新事物的方式。沒有比構建并失敗更好的工程學習方法了。

從我的失敗中，我學到了一些寶貴的經驗教訓，這些經驗對首次構建 RAG 的人很有幫助。你不必重復我犯過的錯誤，這樣你就能更快前進。

那么，讓我們談談第一個錯誤。

向量數據庫并非硬性規定

幾乎所有關于 RAG 的網絡教程都使用向量數據庫。如果你搜索過 RAG 相關內容，你會明白我的意思。

基于向量的檢索無疑是 RAG 成功的重要因素。向量嵌入非常適合映射文本的語義含義。它們也適用于不同大小的文本。你的查詢可能是一句話，但你的文檔存儲包含整頁文章？——向量搜索可以處理。

然而，檢索并不僅限于基于向量的檢索。

RAG 可以從互聯網、關系數據庫、Neo4J 中的知識圖譜或三者的組合中檢索信息。

在許多情況下，我注意到混合方法能帶來更好的性能。

對于通用應用，你可以使用向量數據庫，但當向量數據庫中沒有所需信息時，你可以搜索互聯網。

對于客戶聊天機器人，你可能需要讓 RAG 訪問部分客戶數據庫，這可以是關系數據庫。

企業的知識管理系統可能會創建一個知識圖譜，并從中檢索信息，而不是使用向量數據庫。

這些都是 RAG 的定義。

然而，選擇數據源的過程并非直截了當。你需要嘗試各種選項，了解每種方法的優點。接受或拒絕一個想法的理由可能受技術和業務因素的影響。

例如，你可以為每個客戶簡介信息創建文本版本并進行向量化以供檢索。這對于查詢來說可能很高效，因為你只處理一個數據庫。但它的準確性可能不如運行 SQL 查詢。這是技術原因。

然而，讓 LLM 運行 SQL 查詢可能導致 SQL 注入攻擊。這是技術和業務上的問題。

向量數據庫在語義檢索方面也很高效。但這并不意味著其他數據庫不能處理語義檢索；幾乎所有其他數據庫都可以進行向量搜索。

因此，如果你決定在 RAG 中使用某種形式的向量嵌入，這里還有一個建議。

優先選擇經過微調的小模型

嵌入模型可以將任何內容轉化為向量形式。大型模型的性能通常優于小型模型。

但這并不意味著越大越好。

別管模型大小。所有模型都在公開數據集上訓練。它們能區分“蘋果”水果和“蘋果”品牌。但如果你和朋友用“蘋果”作為暗號，嵌入模型無法知道。

然而，我們創建的幾乎所有應用都專注于一個小的細分領域。

對于這些應用，大型模型的收益是微不足道的。

這里有一個不同的做法。

為你的領域數據創建一個數據集，并對小型嵌入模型進行微調。

小型模型足以捕捉語言細微差別，但可能無法理解在不同語境中有特殊含義的詞。

但仔細想想，你的模型為什么需要理解木星的衛星？

小型模型更高效。它們速度快，成本低。

為了彌補模型在領域知識方面的不足，你可以對其進行微調。

這兩個建議可以優化索引部分以實現高效檢索。然而，檢索過程也可以進一步優化。

檢索過程可以更高級

最直接的檢索過程是直接查詢。

如果你使用向量數據庫，可以對用戶輸入進行語義搜索。否則，你可以使用 LLM 生成 SQL 或 Cipher 查詢。

必要時你還可以調用 HTTP 端點。

但直接查詢方法很少能產生可靠的上下文。

你可以以更高級的方式查詢數據源。例如，你可以嘗試查詢路由技術來決定從哪個數據源獲取數據。具有良好推理能力的 LLM 可以用于此目的。你還可以在小型模型上進行指令微調，以節省成本并降低延遲。

另一種技術是鏈式請求。對于初始查詢，我們可以從數據源獲取信息。然后，根據獲取的文檔，我們可以獲取后續文檔。

分塊是 RAG 中最具挑戰性且至關重要的部分

當上下文包含無關信息時，LLM 容易出現幻覺。

防止 RAG 幻覺的最佳方法是分塊。

現代 LLM 可能支持更長的上下文長度。例如，Gemini 2.5 Pro 支持高達 200 萬個 token，足以容納兩到三本大學級別的物理教科書。

但對于基礎力學問題，你很少需要量子物理的上下文信息。

如果你將教科書分解成較小的部分，可能每個部分只討論一個主題，你就能只獲取回答問題所需的相關信息。

這里的挑戰在于分塊技術有很多種。每種技術都有其優缺點。適合你領域的技術可能不適用于其他領域。

遞歸字符分塊可能是最簡單的，也是我的默認選擇。然而，它假設文本中每個主題的討論長度相等，這很少是事實。盡管如此，這是最好的起點。

圖片

你甚至可以嘗試主題聚類和代理分塊。

嘗試重新排序

最后但同樣重要的是，重新排序。

事實證明，相關分塊的位置是高質量 LLM 響應的關鍵因素。

然而，常規向量搜索甚至數據庫查詢的排序方式并不智能。LLM 可以做到。

因此，我們使用專門的大型語言模型 (LLM) 作為重新排序器，重新排列獲取的上下文并進一步過濾，找出最相關的分塊。

這種二級重新排序在某些應用中有幫助，但在其他應用中未必。但你可以使用一些技術來改進重新排序的結果。

其中之一是獲取大量初始結果。寬松定義初始標準會拉取一些無關上下文，但會增加獲取正確內容的概率。

圖片

重新排序器現在可以處理這個大型集合并過濾出更相關的部分。

最終思考

構建 RAG 已成為任何 LLM 應用的必備。即使是 200 萬 token 的上下文窗口也無法挑戰它。

我們開發的原型通常未能部署。部分原因歸于業務決策，但也有可以解決的技術原因。

本文是我在構建 RAG 方面的經驗總結。

雖然這不是一個全面的列表，但考慮這五個方面將確保你開發出更持久的 RAG。