在人工智慧領域，RAG 技術正成為推動大模型應用的關鍵。本文將深入探討 RAG 技術的原理、挑戰以及在不同階段的優化策略，幫助讀者全面瞭解並有效實施這一技術。如果你對提升 AI Agent 的性能感興趣，不妨繼續閱讀。

在《大佬們都在關注的 AI Agent，到底是什麼？用 5W1H 分析框架拆解 AI Agent（上篇）》中，風叔提到要實現良好的 AI Agent 性能，RAG 技術的使用至關重要，今天我們就來重點談一談 RAG。

對於 Rag 系統的整體框架，風叔做了梳理。想提前瞭解全部內容的同學，可以關注 GZH “風叔雲”，回復關鍵詞“ Rag 框架”，獲取完整內容。

一、什麼是 Rag？

RAG，Retrieval-Augmented Generation，中文名檢索增強生成，是 AI 領域非常重要的一種技術方案。其核心作用是給 LLM 大模型外掛專門的知識庫，指導大模型生成更準確的輸出。

為什麼要給 LLM 大模型外掛知識庫呢？因為雖然大模型的能力越來越強大，但其內在的缺點也非常明顯。

第一，存在幻覺問題。LLM 大模型的底層原理是基於數學概率進行預測，其模型輸出本質上是一種概率預測的結果。所以 LLM 大模型有時候會出現胡言亂語，或者生成一些似是而非的答案，在大模型並不擅長的領域，幻覺問題會更加嚴重。消費者要區分幻覺問題是非常困難的，除非消費者本身就具備了相應領域的知識，但這裡就會存在矛盾，已經具備相關知識的人是不會採用大模型生成的答案的。

第二，缺乏對生成結果的可解釋性。LLM 大模型本身就是一個黑盒，這個模型使用了什麼數據進行訓練，對齊策略是怎麼樣的，消費者都無從得知。所以對於大模型生成的答案，更加難以追蹤溯源。

第三，缺乏對專業領域知識的理解。LLM 大模型知識的獲取嚴重依賴訓練數據集的廣度，但目前市面上大多數的數據訓練集都來源於網路公開數據，對於企業內部數據、特定領域或高度專業化的知識，大模型無從學習。因此大模型的表現更像是一個及格的通才，但是在一些專業場景，比如企業內部的業務流，一個及格的通才是無法使用的，需要利用企業的專屬數據進行餵養和訓練，打造為優秀的專才。

第四，數據的安全性。這是對上面第三點的延伸，沒有企業願意承擔數據洩露的風險，將自身的私域數據上傳第三方平台進行訓練。因此，完全依賴通用大模型自身能力的應用方案，在企業場景下是行不通的。

第五，知識的時效性不足。大模型的內在結構會被固化在其被訓練完成的那一刻，但是當你詢問大模型一些最新發生的事情，則難以給出答案。

為了克服這些問題，第一種方式是微調，即 Finetune。但是由於生成模型依賴於內在知識，也就是各類參數的權重，即使做了微調，模型還是無法擺脫幻覺問題。此外在實際場景中，很多新的資訊、數據、政策每時每刻都在產生，除非對模型進行高頻的微調，否則模型的訓練速度永遠趕不上外部資訊更新的速度，而高頻微調的成本就太高了，

在 2020 年，Meta AI 的研究人員提出了檢索增強生成（RAG）的方法，為 LLM 大模型提供了一種與外部資訊高效互動的解決方案。其主要作用類似於搜尋引擎，找到用戶提問最相關的知識或者是相關的對話歷史，並結合原始提問，創造信息豐富的 prompt，指導 LLM 大模型生成更準確的輸出。

這就是 Rag 技術產生的背景和原因。

二、Rag 技術的基本原理

RAG 可分為 5 個基本流程：知識文檔的準備、嵌入模型、存入向量資料庫、查詢檢索和生產回答。

現實場景中，我們面對的知識源可能包括多種格式，如 Word 檔、TXT 文件、CSV 數據表、Excel 表格，甚至圖片和視頻。因此需要使用專門的文件載入器（例如 PDF 提取器）或多模態模型（如 OCR 技術），將這些豐富的知識源轉換為大語言模型可理解的純文本數據，然後開啟 RAG 的五個核心步驟。

第一步，文檔切片 / 分塊：在企業級應用場景中，文檔尺寸可能非常大，因此需要將長篇文檔分割成多個文本塊，以便更高效地處理和檢索資訊。分塊的方式有很多種，比如按段落、按內容或者其他特殊結構。同時，需要注意分塊的尺寸，如果分塊太小，雖然查詢更精準，但召回時間更長；如果分塊太大，則會影響查詢精準度。

第二步，嵌入模型：嵌入模型的核心任務是將文本轉換為向量形式，這樣我們就能通過簡單的計算向量之間的差異性，來識別語義上相似的句子。

第三步，存入向量資料庫：將文檔切片和嵌入模型的結果存儲進入向量資料庫。向量資料庫的主要優勢在於，它能夠根據數據的向量接近度或相似度，快速、精確地定位和檢索數據，實現很多傳統資料庫無法實現的功能，比如根據旋律和節奏搜索出特定的歌曲、在電影中搜索浪漫的片段、在文件中找出意圖相近的段落等等。

第四步，用戶查詢檢索：用戶的問題會被輸入到嵌入模型中進行向量化處理，然後系統會在向量資料庫中搜索與該問題向量語義上相似的知識文本或歷史對話記錄並返回，這就是檢索增強。

第五步，生成問答：最終將用戶提問和上一步中檢索到的信息結合，構建出一個提示模版，輸入到大語言模型中，由大模型生成最終的結果並返回。

Rag 技術一經問世，就取得了非常廣泛的使用，成為 AI 大模型產品落地中必不可少的一環。根據具體的使用場景，可以分為以下幾類。

通用問答系統：RAG 可以根據檢索到的相關信息生成準確的答案，幫助員工更快地獲取所需資訊，提高決策效率，比如搭建企業內部知識庫、公司規章制度查詢、新員工入職培訓、公司合同資料解讀和查詢等。

智慧客服系統：RAG 可以結合產品資料庫、聊天記錄、用戶反饋等數據，自動為使用者提供更精準的回答，已經有非常多的初創公司選擇用 RAG 技術構建新一代的智慧客服系統。

智能數據分析：RAG 可以結合外部數據源，如資料庫、API、檔等，為使用者提供更便捷的數據分析服務。傳統企業的數據分析主要靠 BI 分析師，每天都需要寫大量的 SQL 語句進行查詢，而在 RAG 的支援下，企業的每個員工都能以自然對話的方式獲取數據。比如門店店長直接用語音對話，“請幫我找出上周銷量排名前 10，但本周銷量下滑最快的品類”，系統即可直接給出答覆。

自動化文件處理：企業還可以利用 RAG 和 LLM 大模型自動化文件處理流程，例如自動生成合同、撰寫週報、總結會議紀要等，節省時間和人力成本。

三、Rag 實施路徑

Rag 技術雖然相對比較容易入門，但是要部署到生產環境並且對外提供穩定的服務，還是有很多路要走的，尤其是其流程的各個環節都有非常多的優化空間。

從優化的方向來看，主要包括四個方面，知識分塊與索引優化、使用者 query 改寫優化、數據召回優化和內容生成優化。當然，“羅馬不是一天建成的”，Rag 相關項目的實施也需要分階段逐步進行反覆運算和優化，風叔建議可以按照以下三個階段來實施。

第一階段，可運行，即系統能跑通整體流程

1）知識分塊與索引

在 RAG 系統中，文件需要分割成多個文本塊再進行向量嵌入。在不考慮大模型輸入長度限制和成本問題情況下，其目的是在保持語義上的連貫性的同時，儘可能減少嵌入內容中的雜訊，從而更有效地找到與用戶查詢最相關的文檔部分。

如果分塊太大，可能包含太多不相關的資訊，從而降低了檢索的準確性。相反，分塊太小可能會丟失必要的上下文資訊，導致生成的回應缺乏連貫性或深度。

第一階段可先按固定字元拆分知識，並通過設置冗餘字元來降低句子截斷的問題，使一個完整的句子要麼在上文，要麼在下文。這種方式能盡量避免在句子中間斷開的問題，且實現成本最低，非常適合在業務起步階段。

2）使用者 Query 改寫

在 RAG 系統中，用戶的查詢問題會被轉化為向量，然後在向量資料庫中進行匹配，因此查詢的措辭準確度會直接影響搜索的結果。在向量空間中，對人類來說看似相同的兩個問題其向量大小並不一定很相似

我們可以採用“查詢重寫”方案，即直接利用 LLM 大模型重新表述問題。在進行多輪對話時，用戶提問中的某些內容可能會指代上文中的部分資訊，可以將歷史資訊和用戶提問一併交給 LLM 大模型進行重新表述。

總體來說，第一階段可以先直接使用大模型的理解能力，結合上下文，突出使用者意圖。此時不需要做過多的 Query 改寫，以測試大模型理解能力和跑通流程為主。

3）數據召回

第一階段可以先使用最簡單的向量召回方式，找到在語義向量維度最近似的答案進行召回。這裡需要注意的是，要找一個和自己業務比較契合的 embedding 模型和向量資料庫。

召回結果的數量是另一個關鍵因素，更多的結果可以提供豐富的預料，有助於系統更好地理解問題的上下文和隱含細節。但是結果數量過多可能導致資訊過載，降低回答準確性並增加系統的時間和資源成本。第一階段我們可以先把召回數量設置為 10。

4）內容生成

內容生成環節更多的是考慮用戶體驗，在第一階段我們可以先簡單一些，能順利輸出答案即可。因為數據召回環節只有向量召回，因此這一步可以只將上一步召回環節返回的 top 10 的知識篩選出來，然後提供給大模型生成答案。

第一階段的系統可能會存在較多問題，大家會發現生成答案的相關性和準確度都比較低。但是沒關係，這一階段的首要任務是跑通系統流程，優化的工作我們放在第二和第三階段再做。

第二階段，可使用，即系統初步達到可上線水準

知識的分塊與索引，對最終答案生成的準確性有非常大的影響，尤其是在處理超長文本的時候，會出現索引混淆問題。

索引混淆是指知識文檔的核心關鍵詞被湮沒在大量的無效資訊中，比如大量無關緊要的助詞、語氣詞、或無關資訊，導致建立的索引中核心知識比重少，從而影響生成答案的品質。針對這個問題，我們可以採用三種優化方案，索引降噪、多級索引和 HYDE。

索引降噪：是根據業務特點，去除索引數據中的無效成分，突出其核心知識，從而降低噪音的干擾，保障核心知識的比重。比如原文檔內容是“ How can I download source code from github.com ”，其核心內容是“ download source code、github ”，其他噪音可以忽略。

多級索引：是指創建兩個索引，一個由文檔摘要組成，另一個由文檔塊組成，並分兩步搜索，首先通過摘要過濾掉相關文件，然後只在這個相關組內進行搜索。這種多重索引策略使 RAG 系統能夠根據查詢的性質和上下文，選擇最合適的索引進行數據檢索，從而提升檢索質量和回應速度。但為了引入多重索引技術，我們還需配套加入多級路由機制，比如對於查詢“最新發表的 Rag 論文推薦”，RAG 系統首先將其路由至論文專題的索引，然後根據時間篩選最新的 Rag 相關論文。

HYDE：全稱是 Hypothetical Document Embeddings，用 LLM 生成一個“假設”答案，將其和問題一起進行檢索。HyDE 的核心思想是接收用戶提問后，先讓 LLM 在沒有外部知識的情況下生成一個假設性的回復。然後，將這個假設性回復和原始查詢一起用於向量檢索。假設回復可能包含虛假資訊，但蘊含著 LLM 認為相關的資訊和文件模式，有助於在知識庫中尋找類似的文件。

直接使用原始的使用者 query 進行檢索，會存在一些問題。比如知識庫內的數據無法直接回答，需要組合多種知識才能找到答案；此外，涉及細節比較多的問題，大模型往往無法進行高品質的回答。可以使用 Rag-Fusion 進行優化。

RAG-Fusion：首先對使用者的原始 query 進行擴充，即使用 LLM 模型對使用者的初始查詢，進行改寫生成多個查詢；然後對每個生成的查詢進行基於向量的搜索，形成多路搜索召回；接著應用倒數排名融合演算法，根據文件在多個查詢中的相關性重新排列文檔，生成最終輸出。

在第一階段，我們使用了單純的語義向量做召回，但是當文本向量化模型訓練不夠好時，向量召回的準確率會比較低，此時需要利用其他召回方式作為補充。

分詞召回：一種有效的稀疏搜索演算法是最佳匹配 25（BM25），它基於統計輸入短語中的單詞頻率，頻繁出現的單詞得分較低，而稀有的詞被視為關鍵詞，得分會較高。我們可以結合稀疏和稠密搜索得出最終結果。

多路召回：多路召回的結果經過模型精排，最終篩選出優質結果。至於使用幾種召回策略，根據業務而定。

根據前幾個環節的優化策略，內容生成環節也需要有相應的調整。

文件合併去重：多路召回可能都會召回同一個結果，針對這部分數據要去重，否則對大模型輸入的 token 數是一種浪費；其次，去重后的文件可以根據數據切分的血緣關係，做文件的合併。

重排模型：重排模型通過對初始檢索結果進行更深入的相關性評估和排序，確保最終展示給用戶的結果更加符合其查詢意圖。這一過程通常由深度學習模型實現，如 Cohere 模型。這些模型會考慮更多的特徵，如查詢意圖、詞彙的多重語義、用戶的歷史行為和上下文資訊等。

經過第二階段的優化，答案生成的相關性和準確度都會大幅提升，但是仍然會有較大概率出現答非所問的情況，我們還需要對系統做更進一步的優化。

第三階段，很好用，即系統回答的準確率達到用戶滿意水準

下面，風叔介紹一些更高級的 Rag 優化策略。

雖然在第二階段，我們通過索引降噪、多級索引、HYDE 等方式，大幅提升了知識庫的準確度，但是按固定字元切，有時候會遇到句子含義聯繫比較緊密的片段被切分成了兩條數據，導致數據質量比較差。

這個情況下可以嘗試訓練專門的語義理解小模型，然後使用實際語義進行句子拆分，使拆分出來的知識片段語義更加完整。

另外一種方法是構建元數據，增加內容摘要、時間戳、使用者可能提出的問題等附加資訊來豐富知識庫，而元數據不需要被向量化。此外，我們還可以添加諸如章節或小節的引用，文本的關鍵資訊、小節標題或關鍵詞等作為元數據，有助於改進知識檢索的準確性。

還有一種更加有效的方式是建立知識圖譜。嵌入模型雖然簡單，但是沒法有效捕捉實體之間的複雜關係和層次結構，所以導致傳統 RAG 在面對複雜查詢的時候特別吃力。比如，用戶詢問“《跨越鴻溝》這本書的主旨是什麼”，傳統 Rag 技術是肯定回答不出來的。但是知識圖譜技術可以做到，因為利用知識圖譜對數據集建立索引的時候，會做提取實體以及實體之間的關係，這樣就能構建一種全域性的優勢，從而提升 RAG 的精確度。

但是，知識圖譜雖然很強大，可惜成本太高了，會大幅提升 token 用法，大家需要綜合產品體驗和成本進行評估。

2）使用者 query 改寫

Step-Back Prompting：如果果原始查詢太複雜或返回的資訊太廣泛，我們可以選擇生成一個抽象層次更高的“退後”問題，與原始問題一起用於檢索，以增加返回結果的數量。例如，對於問題“勒布朗詹姆斯在 2005 年至 2010 年在哪些球隊？”這個問題因為有時間範圍的詳細限制，比較難直接解決，可以提出一個後退問題“勒布朗詹姆斯的職業生涯是怎麼樣的？”，從這個回答的召回結果中再檢索上一個問題的答案。

圖譜召回：如果在知識分塊環節使用了知識圖譜，那麼我們就可以直接用圖譜召回，大幅提升召回準確度。

Agentic-rag：RAG 應用退化成一個 Agent 使用的知識工具。我們可以針對一個文檔 / 知識庫構建多種不同的 RAG 引擎，比如使用向量索引來回答事實性問題；使用摘要索引來回答總結性問題；使用知識圖譜索引來回答需要更多關聯性的問題等。

在單個文件 / 知識庫的多個 RAG 引擎之上設置一個 DocAgent，把 RAG 引擎作為該 Agent 的 tools，並利用 LLM 的能力由 ToolAgent 在自己“負責”的文件內使用這些 tools 來回答問題。最後設置一個總的頂級代理 TopAgent 來管理所有的低階 DocAgent，將 DocAgent 看作自己的 tools，仍然利用 LLM 來規劃、協調、執行用戶問題的回答方案

Prompt 優化：RAG 系統中的 prompt 應明確指出回答僅基於搜尋結果，不要添加任何其他資訊。例如可以設置 prompt：“你是一名智慧客服。你的目標是提供準確的資訊，並盡可能幫助提問者解決問題。你應保持友善，但不要過於囉嗦。請根據提供的上下文資訊，在不考慮已有知識的情況下，回答相關查詢。” 此外，使用 Few-shot 的方法指導 LLM 如何利用檢索到的知識，也是提升 LLM 生成內容品質的有效方法。

Self-rag：self-rag 通過檢索評分（令牌）和反思評分（令牌）來提高品質，主要分為三個步驟：檢索、生成和批評。Self-RAG 首先用檢索評分來評估用戶提問是否需要檢索，如果需要檢索，LLM 將調用外部檢索模組查找相關文件。接著，LLM 分別為每個檢索到的知識塊生成答案，然後為每個答案生成反思評分來評估檢索到的文檔是否相關，最後將評分高的文檔當作最終結果一併交給 LLM。

四、總結

本篇文章重點介紹了 Rag 技術的概念、產生原因、基本原理和實施路徑，可以作為 AI 產品經理和研發同學在實際專案中的參考資料。

圍繞 Rag 相關的各項技術和理念仍然在飛速反覆運算，從大方向來說，風叔比較看好知識圖譜和 AI Agent 在 Rag 系統中的使用。

知識圖譜的成本一定會繼續下降，那麼一定存在一個臨界點，即使用知識圖譜帶來的對實體和實體關係的理解優勢，會遠遠大於對成本的考量。

對於 AI Agent，其本身和 Rag 也是相輔相成的關係。Rag 系統為 AI Agent 提供長期記憶能力，而 AI Agent 的規劃與反思也會為 Rag 系統提供非常好的規劃管理和路由能力。

相信 Rag 會在各個領域的 AI 產品落地過程中，持續扮演重要的角色。

題圖來自 Unsplash，基於 CC0 協定。