基于 RAG（檢索增強生成）的 AI 系統(tǒng)，過去是，現(xiàn)在仍然是企業(yè)利用大語言模型（LLM）的最有價值的應用之一。我記得差不多兩年前我寫了第一篇關于 RAG 的文章，那時候這個術語還未被廣泛采用。

我當時描述的是一個以最基礎方式實現(xiàn)的 RAG 系統(tǒng)。自那以后，這個行業(yè)不斷發(fā)展，在此過程中引入了各種先進技術。

在這篇文章，我們將探討 RAG 的演進歷程 —— 從基礎版本（Naive）到 Agentic。閱讀本文后，您將理解 RAG 系統(tǒng)演進過程中的每一步都攻克了哪些挑戰(zhàn)。

1.Naive RAG 的出現(xiàn)

2022 年底 ChatGPT 的推出讓 LLMs 成為了主流，幾乎與此同時，Naive RAG 也應運而生。檢索增強生成（RAG）技術的出現(xiàn)旨在解決原生 LLM 所面臨的問題。簡而言之就是：

• 幻覺問題。
• 有限的上下文窗口大小。
• 無法訪問非公開數(shù)據(jù)。
• 無法自動獲取訓練截止日期后的新信息，且更新這些知識需要重新訓練模型。

RAG 的最簡單實現(xiàn)形式如下：

Naive RAG.

預處理過程（Preprocessing）：

1）將整個知識庫的文本語料分割成文本塊（chunk） —— 每個文本塊代表一段可供查詢的上下文片段。目標數(shù)據(jù)可來自多種來源，例如以 Confluence 文檔為主、PDF 報告為輔的混合資料庫。

2）使用嵌入模型（Embedding Model）將每個文本塊轉換為向量嵌入（vector embedding）。

3）將所有向量嵌入存儲到向量數(shù)據(jù)庫（Vector Database）中。同時分別保存代表每個嵌入的文本及其指向嵌入的指針。

檢索過程（Retrieval）：

4）在向量數(shù)據(jù)庫或知識檢索系統(tǒng)中，為了確保查詢和存儲的知識能夠準確匹配，需要用同一個嵌入模型（Embedding Model）來處理存儲到知識庫中的文檔內容和用戶提出的問題或查詢。

5）使用生成的向量嵌入在向量數(shù)據(jù)庫的索引上運行查詢。選擇要從向量數(shù)據(jù)庫中檢索的向量數(shù)量 —— 等同于你將檢索并最終用于回答查詢的上下文數(shù)量。

6）向量數(shù)據(jù)庫針對提供的向量嵌入在索引上執(zhí)行近似最近鄰（ANN）搜索，并返回之前選定數(shù)量的上下文向量。該過程會返回在給定嵌入空間（Embedding/Latent space）中最相似的向量，需將這些返回的向量嵌入映射到其對應的原始文本塊。

7）通過提示詞（prompt）將問題連同檢索到的上下文文本塊傳遞給 LLM。指示 LLM 僅使用提供的上下文來回答給定問題。這并不意味著不需要提示詞工程（Prompt Engineering）——你仍需確保 LLM 返回的答案符合預期范圍，例如，如果檢索到的上下文中沒有可用數(shù)據(jù)，則應確保不提供編造的答案。

2.Naive RAG 系統(tǒng)的動態(tài)組件

即便不采用任何高級技術，在構建生產(chǎn)級 RAG 系統(tǒng)時也需要考慮許多動態(tài)組件。

RAG - 動態(tài)組件

檢索環(huán)節(jié)：

F) 分塊策略 - 如何對用于外部上下文的數(shù)據(jù)進行分塊

• 小文本塊與大文本塊的選擇
• 滑動窗口或固定窗口的文本分塊方法
• 檢索時是否關聯(lián)父塊/鏈接塊，或僅使用原始的檢索數(shù)據(jù)

C) 選擇嵌入模型，將外部上下文嵌入到 latent space 或從 latent space 中查詢。需要考慮上下文嵌入（Contextual embeddings）。

D) 向量數(shù)據(jù)庫

• 選擇哪種數(shù)據(jù)庫
• 選擇部署位置
• 應與向量嵌入一并存儲哪些元數(shù)據(jù)？這些數(shù)據(jù)將用于檢索前的預篩選和檢索后的結果過濾。
• 索引構建策略

E) 向量搜索

• 選擇相似度度量標準
• 選擇查詢路徑：元數(shù)據(jù)優(yōu)先，還是近似最近鄰（ANN）優(yōu)先
• 混合搜索方案

G) 啟發(fā)式規(guī)則 - 應用于檢索流程的業(yè)務規(guī)則

• 根據(jù)文檔的時間相關性調整權重
• 對上下文進行去重（根據(jù)多樣性進行排序）
• 檢索時附帶內容的原始來源信息
• 根據(jù)特定條件（如用戶查詢意圖、文檔類型）對原始文本進行差異化預處理

生成環(huán)節(jié)：

A) 大語言模型 - 為你的應用程序選擇合適的 LLM

B) 提示詞工程 - 即使能在提示詞（prompt）中調用上下文信息，也仍需精心設計提示詞 —— 你依然需要調整系統(tǒng)（譯者注：包括設定角色（Role）、規(guī)則（Rules）、輸出格式（Format）等對齊手段。），才能生成符合預期的輸出，并防范越獄攻擊。

完成上述所有工作后，我們才得以構建可運行的 RAG 系統(tǒng)。

但殘酷的事實是，此類系統(tǒng)往往難以真正解決業(yè)務問題。由于各種原因，這種系統(tǒng)的準確性可能很低。

3.改進 Naive RAG 系統(tǒng)的高級技術

為不斷提高 Naive RAG 系統(tǒng)的準確性，我們采用了以下一些較為成功的技術：

• 查詢改寫（Query Alteration） - 可采用以下幾種技巧：

查詢重寫（Query rewriting）：讓大語言模型（LLM）重寫原始查詢，以更好地適應檢索過程。重寫的方式有多種，例如，修改語法錯誤，或將查詢簡化為更簡短精煉的語句。

查詢擴展（Query Expansion）：讓 LLM 對原始查詢進行多次改寫，創(chuàng)建多個變體版本（variations）。接著，多次運行檢索過程，以檢索更多可能相關的上下文。

• 重排序（Reranking） - 對初次檢索出的文檔，用比常規(guī)上下文搜索更復雜的方法進行重排序。通常，這需要使用更大的模型，并且在檢索階段有意獲取遠超實際所需數(shù)量的文檔。重排序（Reranking）與前文提到的查詢擴展（Query Expansion）配合使用效果尤佳，因為后者通常能返回比平時更多的數(shù)據(jù)。整個過程類似于我們在推薦系統(tǒng)中常見的做法。
• 嵌入模型的微調（Fine-Tuning of the embedding model） - 某些領域（如醫(yī)療）在使用基礎嵌入模型進行數(shù)據(jù)檢索效果不佳。此時，你就需要對自己的嵌入模型進行定制化微調。

接下來，我們再看些其它高級的 RAG 技術與架構。

4.上下文檢索（Contextual Retrieval）

上下文檢索（Contextual Retrieval）的概念由 Anthropic 團隊在去年年底提出。其目標在于提升基于檢索增強生成（RAG）的 AI 系統(tǒng)中檢索到的數(shù)據(jù)的準確性和相關性。

我非常喜歡上下文檢索的直觀性和簡潔性。而且它的確能帶來不錯的效果。

以下是上下文檢索的實現(xiàn)步驟：

上下文檢索（Contextual Retrieval）

預處理階段（Preprocessing）：

1）使用選定的分塊策略將每份文檔分割成若干個文本塊。

2）將每個文本塊單獨與完整文檔一起加入提示詞中。

3）在提示詞中添加指令，要求 LLM 定位該文本塊在文檔中的位置，并為其生成簡短的上下文。隨后將此提示詞輸入選定的 LLM。

4）將上一步生成的上下文，與其對應的原始文本塊合并。

5）將組合后的數(shù)據(jù)輸入一個 TF-IDF 嵌入器（embedder）。

6）再將數(shù)據(jù)輸入一個基于 LLM 的嵌入模型（embedding model）。

7）將步驟 5 和步驟 6 生成的數(shù)據(jù)存入支持高效搜索的數(shù)據(jù)庫中。

檢索階段（Retrieval）：

8）使用用戶查詢（user query）檢索相關上下文。使用近似最近鄰（ANN）搜索實現(xiàn)語義匹配，同時使用 TF-IDF 索引進行精確搜索。

9）使用排序融合（Rank Fusion）技術對檢索結果進行合并、去重，并選出排名前 N 的候選項。

10）對前一步的結果進行重排序（Rerank），將范圍縮小至前 K 個候選項。

11）將步驟 10 的結果與用戶查詢一起輸入 LLM，生成最終答案。

一些思考：

• 步驟 3. 聽起來（并且實際也）耗費驚人，但通過應用提示詞緩存技術（Prompt Caching），成本可以顯著降低。
• 提示詞緩存技術既可在專有（閉源）模型場景下使用，也可在開源模型場景下使用（請參閱下一段內容）。

5.緩存增強生成（Cache Augmented Generation）的曇花一現(xiàn)

2024 年底，一份白皮書在社交媒體上短暫刷屏。它介紹了一項有望徹底改變 RAG (檢索增強生成) 的技術（真的能嗎？）—— 緩存增強生成（Cache Augmented Generation, CAG）。我們已經(jīng)了解了常規(guī) RAG 的工作原理，下面簡要介紹一下 CAG：

RAG vs. CAG

1）將所有外部上下文預計算至 LLM 的 KV 緩存中，并存入內存。該過程僅需執(zhí)行一次，后續(xù)步驟可重復調用初始緩存而無需重新計算。

2）向 LLM 輸入包含用戶查詢（user query）的系統(tǒng)提示詞，同時提供如何使用緩存上下文的指令。

3）將 LLM 生成的答案返回用戶。完成后清除緩存中的臨時生成內容，僅保留最初緩存的上下文，使 LLM 準備好進行下一次生成。

CAG 承諾，通過將所有上下文存儲在 KV 緩存中（而非每次生成時只檢索部分數(shù)據(jù)），實現(xiàn)更精準的檢索?，F(xiàn)實如何？

• CAG 無法解決因上下文極長而導致的不準確問題。
• CAG 在數(shù)據(jù)安全方面存在諸多局限性。
• 對大型組織而言，將整個內部知識庫加載到緩存近乎不可能。
• 緩存會失去動態(tài)更新能力，添加新數(shù)據(jù)非常困難。

事實上，自從多數(shù) LLM 提供商引入提示詞緩存（Prompt Caching）技術后，我們已在使用的正是 CAG 的一種變體。我們的做法可以說是 CAG 與 RAG 的融合，具體實施過程如下：

RAG 和 CAG 的融合

數(shù)據(jù)預處理：

1）在緩存增強生成（CAG）中，我們僅使用極少變化的數(shù)據(jù)源。除了要求數(shù)據(jù)更新頻率低外，我們還應該考慮哪些數(shù)據(jù)源最常被相關查詢命中。確定這些信息后，我們才會將所有選定的數(shù)據(jù)預計算至 LLM 的 KV 緩存中，并將其緩存在內存中。此過程僅需執(zhí)行一次，后續(xù)步驟可多次運行而無需重新計算初始緩存。

2）對于 RAG，如有必要，可將向量嵌入預計算并存入兼容的數(shù)據(jù)庫中，供后續(xù)步驟 4 檢索。有時對于 RAG 來說，只需更簡單的數(shù)據(jù)類型，常規(guī)數(shù)據(jù)庫即可滿足需求。

查詢路徑：

3）構建一個提示詞，需包含用戶查詢及系統(tǒng)提示詞，明確指導大語言模型如何利用緩存的上下文（cached context）及外部檢索到的上下文信息。

4）將用戶查詢轉化為向量嵌入，用于通過向量數(shù)據(jù)庫進行語義搜索，并從上下文存儲中檢索相關數(shù)據(jù)。若無需語義搜索，則查詢其他來源（如實時數(shù)據(jù)庫或互聯(lián)網(wǎng)）。

5）將步驟 4 中獲取的外部上下文信息整合至最終的提示詞中，以增強回答質量。

6）向用戶返回最終生成的答案。

接下來，我們將探討最新的技術發(fā)展方向 —— Agentic RAG。

6.Agentic RAG

Agentic RAG 新增了兩個核心組件，試圖降低應對復雜用戶查詢時的結果不一致性。

• 數(shù)據(jù)源路由（Data Source Routing）。
• 答案驗證與修正（Reflection）。

現(xiàn)在，讓我們來探究其工作機制。

Agentic RAG

1）分析用戶查詢：將原始用戶查詢傳遞給基于大語言模型的智能體進行分析。在此階段：

a. 原始查詢可能會被改寫（有時需多次改寫），最終生成單個或多個查詢傳遞至后續(xù)流程。

b. 智能體判斷是否需要額外數(shù)據(jù)源來回答查詢。這是體現(xiàn)其自主決策能力的第一環(huán)節(jié)。

2）如果需要其他數(shù)據(jù)，則觸發(fā)檢索步驟，此時進行數(shù)據(jù)源路由（Data Source Routing）。系統(tǒng)中可預置一個或多個數(shù)據(jù)集，智能體被賦予自主權來選擇適用于當前查詢的具體數(shù)據(jù)源。舉幾個例子：

a. 實時用戶數(shù)據(jù)（如用戶當前位置等實時信息）。

b. 用戶可能感興趣的內部文檔。

c. 網(wǎng)絡公開數(shù)據(jù)。

d. …

3）一旦從潛在的多個數(shù)據(jù)源檢索到數(shù)據(jù)，我們就會像在常規(guī) RAG 中一樣對其進行重排序。這也是一個關鍵步驟，因為利用不同存儲技術的多個數(shù)據(jù)源都可整合至此 RAG 系統(tǒng)中。檢索過程的復雜性可被封裝在提供給智能體的工具背后。

4）嘗試直接通過大語言模型生成答案（或生成多個答案，或生成一組操作指令）。此過程可在第一輪完成，或在答案驗證與修正（Reflection）環(huán)節(jié)后進行。

5）對生成的答案進行分析、總結，并評估其正確性和相關性：

a. 若智能體判定答案已足夠完善，則返回給用戶。

b. 若智能體認為答案有待改進，則嘗試改寫用戶查詢并重復這個生成循環(huán)（generation loop）。此處體現(xiàn)了常規(guī) RAG 與 Agentic RAG 的第二大差異。

近期 Anthropic 的開源項目 MCP，將為 Agentic RAG 的開發(fā)提供強勁助力。

7.總結 (Wrapping up)

至此，我們回顧了現(xiàn)代檢索增強生成（RAG）架構的演進歷程。RAG 技術并未消亡，也不會在短期內消失。我相信其架構在未來一段時間內仍將持續(xù)演進。學習這些架構并了解何時使用何種方案，將是一項有價值的投資。

一般來說，方案越簡單越好，因為增加系統(tǒng)復雜性會帶來新的挑戰(zhàn)。一些新出現(xiàn)的挑戰(zhàn)包括：

• 對端到端系統(tǒng)進行評估的困難。
• 多次調用大語言模型導致的端到端延遲增加。
• 運營成本的增加。
• …