一、引言：GenAI熱潮下的RAG應用挑戰

如今，人們成長為生成式人工智能（GenAI）專家的速度令人驚嘆。每個人都宣稱GenAI將帶來下一次工業革命。這是一個宏大的承諾，我也認同，這次是真的。人工智能終將徹底改變我們的工作和生活方式，很難想象會再次陷入人工智能寒冬。

大語言模型（LLMs）和多模態模型在現有流程中非常實用，而且“相對”容易實現。只需一個向量數據庫，幾行處理原始數據的代碼，再加上幾個API調用——至少理論上是這樣。

盡管聽起來很簡單，但Matt Turck最近在領英上的一篇帖子或許能更好地描述行業的實際進展：

• 2023年：我希望生成式人工智能不會把我們都干掉！
• 2024年：我希望生成式人工智能在未來12到18個月內，能從我們公司的概念驗證實驗發展到小規模生產部署，用于讀取PDF文件！

是的，構建一個RAG應用原型很容易，但要將其轉化為可投入生產的解決方案卻困難重重。這篇文章就是為那些在過去一個月里構建了自己的第一個LLM應用并開始將其產品化的人準備的。我們將探討17種技術，幫助你規避RAG過程中的一些陷阱，并逐步將你的應用發展成一個強大且穩健、可持續的解決方案。

二、Naive RAG：最基礎的RAG系統概述

在構建RAG系統時，我們站在了巨人的肩膀上，利用現有的概念和技術，并以合適的方式將它們組合起來。很多技術都源于搜索引擎領域，目標是圍繞LLMs建立一個流程，為模型提供正確的數據，以便做出決策或總結信息。

除了Transformer模型，我們還使用了一系列技術，比如語義搜索技術、處理文本數據的技術、知識圖譜以及小型的分類/回歸/NLP模型等等。這些技術其實已經存在多年，例如向量搜索庫FAISS在2019年就已發布，文本向量化也不是什么新鮮事。

RAG所做的就是將這些組件連接起來，以解決特定的問題。就像必應搜索，它將傳統的“必應”網絡搜索與LLMs的能力相結合，使得其聊天機器人能夠回答與現實生活數據相關的問題，比如 “谷歌今天的股價是多少？”

在標準的RAG過程中，當用戶提出問題時，Naive RAG會直接將用戶的問題與我們向量數據庫中的任何內容進行比較。我們想要找到相似的內容，而相似內容是指在向量空間中彼此接近的內容，其距離通常通過計算余弦相似度來衡量。

舉個例子，問題是 “湯姆·布雷迪（Tom Brady）打過什么位置？” 假設我們的向量數據庫中有兩個主要數據源：一是湯姆·布雷迪的維基百科文章，二是一本烹飪書的文章。在這個例子中，維基百科的內容應該更相關，因此與用戶問題的距離更近。

但多“近”才算足夠“近”呢？我們無法設置一個相似度分數的閾值來區分相關和不相關的內容，你可以自己試試，就會發現這并不實際。

當我們找到了一些與用戶問題相似的內容后，就需要將它們打包成一個有意義的提示。一個合適的提示至少包含三個組成部分：系統提示，用于告訴LLM該如何表現；用戶的問題；以及在進行相似度搜索后找到的相關文檔，即上下文。

例如這樣一個簡單的提示模板：

[系統提示：請僅使用提供的信息回答問題。]  
[用戶問題：湯姆·布雷迪（Tom Brady）打過什么位置？]  
[上下文：[從向量數據庫中找到的相關文檔內容]]

系統提示中 “...使用僅提供的信息” 這部分，將LLM變成了一個處理和解釋信息的系統，在這種情況下，我們不直接利用模型的知識來回答問題。

這就是Naive RAG的基本過程，一個向量存儲、一個嵌入模型、一個LLM、幾行Python代碼，當然還有一些文檔，就構成了這樣一個簡單的系統。但當我們將這些系統擴展，從原型轉變為生產解決方案時，就會遇到各種現實問題。

三、RAG在實際應用中的潛在陷阱

在實際應用中，RAG系統可能會遇到各種問題：

1. 有價值內容與干擾項：最近鄰搜索總會找到一些相關內容，但這些內容的相關性究竟有多高呢？我們把那些對回答用戶問題不相關的數據點稱為干擾項。比如在搜索與體育相關的問題時，卻出現了一些與體育無關的烹飪類內容。
2. 分塊優化：單個內容片段的大小應該是多少，才能既足夠具體，又包含足夠的上下文信息呢？如果分塊太大，可能會包含過多不相關的信息；如果分塊太小，又可能無法提供足夠的上下文來準確回答問題。
3. 監控與評估：在實際操作中，我們該如何監控我們的解決方案呢？也就是LLMOps（大語言模型操作）方面的問題，比如如何衡量模型的性能、是否存在偏差等。
4. 智能體與多重提示：對于一些更復雜的查詢，無法用單個提示解決時，我們該如何處理呢？比如一些需要多步驟推理或涉及多個領域知識的問題。

四、提升RAG系統性能的關鍵步驟與技術

為了解決上述問題，我們可以從以下幾個方面對RAG系統進行改進，主要包括五個過程步驟：預檢索（將嵌入數據攝入向量存儲）、檢索（找到相關內容）、后檢索（在將結果發送給LLM之前進行預處理）、生成（使用提供的上下文解決用戶問題）、路由（請求的整體路由，比如使用智能體方法將問題分解并與模型來回交互）。下面我們詳細來看每個步驟的具體改進技術：

（一）原始數據創建與準備

在很多情況下，我們并非只能被動地使用已有的數據，而是可以影響文檔的創建過程。通過LLMs和RAG應用，我們突然需要對知識庫進行結構化。在Naive RAG中，模型只能看到單個文本片段，而不是整個維基百科的上下文，這就會帶來問題，比如當文檔中包含特定領域或文檔特定的縮寫、與維基百科其他部分相關聯的文本段落時，沒有背景知識的人很難理解這些文本片段的完整含義，LLM也會遇到同樣的困難。

為了改善這種情況，我們可以在數據準備階段就采取一些措施，比如以一種自解釋的方式準備數據。舉個例子，在教程和技術文檔中常見的內容結構，如果沒有多模態模型輔助，純LLM很難完全理解左邊版本1的內容，而右邊版本2至少給了它更好的理解機會。

（二）索引與分塊：分塊優化

由于Transformer模型有固定的輸入序列長度限制，所以我們發送給LLM和嵌入模型的提示的標記大小也受到限制。但這并非完全是壞事，我們可以思考文本片段和提示的最佳長度，因為這對系統性能有顯著影響，比如響應時間（以及成本）、相似度搜索準確性等。

有多種文本分割器可以用來分塊文本，分塊的大小是一個需要考慮的參數，它取決于你使用的嵌入模型及其標記容量。例如，基于BERT的句子Transformer等標準Transformer編碼器模型最多接受512個標記，而有些嵌入模型能夠處理更長的序列，達到8191個標記甚至更多。但并不是塊越大越好，有時候找到書中包含最重要信息的兩個句子，比找到包含答案的5頁內容更有效。

為了解決分塊大小選擇的問題，有不同的方法，比如：

1. 滑動窗口：這是確保所有信息被正確捕獲且不被遺漏的最簡單方法，即將整個文本嚴格分成若干部分，且文本部分相互重疊。
2. 遞歸結構感知分割：根據文本的結構層次進行分割，考慮到文本的邏輯關系。
3. 結構感知分割（按句子、段落）：按照句子或段落的自然結構進行分割。
4. 內容感知分割（Markdown、LaTeX、HTML）：根據文本的格式（如Markdown、LaTeX、HTML等）進行分割，以更好地保留文本的結構信息。
5. 使用NLP進行分塊：跟蹤主題變化：通過自然語言處理技術，根據文本主題的變化進行分塊。

（三）增強數據質量：處理縮寫、技術術語和鏈接

數據清理技術可以去除不相關的信息，或將文本部分置于合適的上下文中，使其更易于理解。有時候，一個較長文本中特定段落的含義，在知道書籍上下文的情況下似乎很清楚，但如果上下文缺失，就會變得難以理解。縮寫、特定技術術語或公司內部術語會讓模型很難理解文本的完整含義。

例如，如果你對籃球一無所知，就永遠不會將MJ與 “邁克爾·喬丹（Michael Jordan）” 聯系起來；如果你不知道某個句子描述的是供應鏈背景下的內容，可能會認為PO是 “郵局（post office）” 或其他以P和O開頭的單詞組合。為了緩解這個問題，我們可以在處理數據時引入必要的額外上下文，比如使用縮寫翻譯表將縮寫替換為全文。在處理文本到SQL的用例時，這一點尤為重要，因為很多數據庫的字段名常常很奇怪，只有開發者才知道其背后的含義，比如SAP（企業資源規劃解決方案）經常使用德語單詞的縮寫來標記字段，“WERKS” 是德語單詞 “Werkstoff” 的縮寫，意思是零件的原材料。

（四）添加元數據

在所有向量數據庫中，你都可以向向量數據添加元數據。元數據可以在進行向量搜索之前，幫助我們對整個向量數據庫進行（預）過濾。例如，假設我們向量存儲中的數據一半針對歐洲用戶，另一半針對美國用戶，如果我們知道用戶的位置，就不想搜索整個數據庫，而是希望能夠直接搜索相關的部分。如果我們將用戶位置信息作為元數據字段，大多數向量存儲都允許我們在進行相似度搜索之前對數據庫進行預過濾。

（五）優化索引結構：全搜索與近似最近鄰，HNSW與IVFPQ

雖然我認為相似度搜索并不是大多數RAG系統的弱點（至少從響應時間來看不是），但還是值得一提。在大多數向量存儲中，相似度搜索速度非常快，即使有幾百萬個條目，因為它們使用了近似最近鄰技術，比如FAISS、NMSLIB、ANNOY等。對于只有幾千個條目的用例，使用近似最近鄰搜索（ANN）或全最近鄰搜索對RAG系統的響應時間影響不大。但如果你想建立一個可擴展的系統，優化索引結構肯定可以加快速度。

（六）選擇合適的嵌入模型

將文本塊嵌入有多種選擇，如果你不確定使用什么模型，可以參考現有的衡量文本嵌入模型性能的基準測試，比如MTEB（大規模文本嵌入基準測試）。在進行嵌入時，我們通常需要決定嵌入的維度，更高的維度可以捕獲和存儲句子更多的語義方面，但需要更多的空間來存儲和更多的計算時間。現在有多個不同提供商的模型可供選擇，你可以查看langchain.embeddings模塊支持的模型，在該模塊的源代碼中，你會找到一長串支持的模型，如OpenAIEmbeddings、AzureOpenAIEmbeddings、CacheBackedEmbeddings等等。

五、檢索優化技術

檢索優化主要包括查詢翻譯、查詢重寫和查詢擴展等方法，它們的本質都是利用LLMs的能力來增強我們發送給向量搜索的查詢。具體有以下幾種方式：

（一）查詢擴展與生成答案：HyDE等技術

在進行相似度搜索之前，使用LLM生成一個答案。如果是一個只能使用我們內部知識回答的問題，我們就間接地讓模型進行“幻覺”，并使用這個幻覺的答案來搜索與答案相似的內容，而不是用戶的原始查詢。有多種技術可以實現這一點，比如HyDE（假設文檔嵌入）、Rewrite-Retrieve-Read、Step-Back Prompting、Query2Doc、ITER-RETGEN等。在HyDE中，我們先讓LLM在沒有上下文的情況下為用戶的查詢創建一個答案，然后使用這個答案在我們的向量數據庫中搜索相關信息。

（二）多重系統提示

這個方法的思路很簡單，我們生成例如4個不同的提示，這些提示會產生4個不同的響應。你可以發揮創意，提示之間的差異可以是任何方面的。比如當我們有一段長文本并想要總結它時，可以使用不同的提示在文本中尋找某些方面的信息，并在最終答案中總結這些發現；或者有4個大致相同的提示，上下文也相同，但系統提示略有不同，這樣我們就以稍微不同的方式告訴LLM 4次該如何處理文本或如何措辭答案。這個概念在數據科學中很常見，就像在提升算法中，我們通常有簡單的模型，每個模型略有不同，做出一個小決策，最后我們以某種方式整合結果，這個概念非常強大。當然，這種方法的缺點是計算時間和/或響應時間會更高。

（三）查詢路由

在查詢路由中，我們利用LLMs的決策能力來決定下一步該做什么。假設我們的向量存儲中有來自不同領域的數據，為了更有針對性地搜索相關內容，讓模型在第一步決定我們應該使用哪個數據池來回答問題是很有意義的。例如，我們的示例向量存儲包含來自世界各地的新聞，包括體育和足球新聞、烹飪趨勢以及政治新聞。當用戶向我們的聊天機器人查詢時，我們不希望混合這些數據，因為國家之間的體育競爭不應該與政治混合，而且如果用戶在尋找政治新聞，烹飪相關的內容可能也沒有幫助。通過這種方式，我們可以顯著提高性能，還可以為最終用戶提供選擇用于回答問題的主題的選項。

（四）混合搜索

基本上，RAG管道的檢索步驟就相當于一個搜索引擎，這可能是我們RAG系統中最重要的部分。當我們想要提高相似度搜索時，值得研究一下搜索領域的方法，混合搜索就是一個例子。我們同時進行向量搜索和詞匯（關鍵詞）搜索，并以某種方式將這些結果結合起來。在機器學習中，這是一種常見的方法，即使用不同的技術、不同的模型來預測相同的輸出，并總結結果，就像一群專家試圖找到解決方案并做出妥協，往往比一個獨立的專家做出的決策更好。

六、后檢索優化：上下文增強

通常我們試圖保持文本塊較小，以便實際找到我們要找的內容并保持較高的搜索質量。但另一方面，不僅看到最匹配的句子，還看到它周圍的上下文，往往更容易給出正確的答案。例如，我們有一堆來自維基百科關于德國足球俱樂部拜仁慕尼黑的文本塊，雖然第一個文本片段可能具有最高的相似度分數，但第二個塊中的信息可能更相關，我們也希望捕獲到它，這時上下文增強就發揮作用了。

有多種方法可以增強上下文，這里簡要介紹兩種：

（一）句子窗口檢索

具有最高相似度分數的文本塊代表了找到的最佳匹配內容。在將內容發送給LLM之前，我們添加找到的文本塊之前和之后的k個句子。這是有意義的，因為這些信息很可能與中間部分相關，而且中間文本塊中的信息可能不完整。

（二）自動合并檢索器（又名父文檔檢索器）

自動合并檢索器的工作方式類似，只是這次每個小塊文本都被分配了特定的“父”塊，這些“父”塊不一定是找到的文本塊之前和之后的塊。你可以充分發揮創造力，定義和識別文本塊之間的相關關系。例如，在查看技術文檔或法律合同時，段落或部分經常引用合同的其他部分，挑戰在于用來自其他段落的相關信息豐富段落，所以我們需要能夠識別文本中指向文檔其他部分的鏈接。我們可以在此基礎上建立一個完整的層次結構，就像一個具有不同級別的父節點、子節點和葉節點的決策樹。例如，我們可以有3個級別，不同的塊大小（如LlamaIndex，2024）：

• 第一級：塊大小為2048
• 第二級：塊大小為512
• 第三級：塊大小為128（葉節點）

當我們索引數據并進行相似度搜索時，我們使用最小的塊，即葉節點。在此步驟之后，我們找到與葉節點匹配的父節點。

七、生成與智能體

（一）選擇合適的LLM和提供商：開源與閉源，服務與自托管，小模型與大模型

為你的應用選擇合適的模型并不像你想象的那么容易，這取決于具體的應用和你的流程。有些人可能會說，最明顯的解決方案是直接使用最強大的模型，但使用較小、更便宜和更快的模型也有一些不可否認的優勢。在RAG過程的某些部分，對準確性的要求可以低一些，但響應時間應該快，比如當我們使用基于智能體的方法時，需要在管道中不斷做出簡單的決策。而且，如果較小模型的響應和決策能力對我們的用例來說已經足夠強大，那么就沒有必要選擇最強大的模型，這樣可以降低解決方案的運營成本，用戶也會因為系統響應時間的提高而受益。那么如何選擇模型呢？有幾個基準測試從不同角度比較了不同的LLMs，但最終，我們還是需要為自己的RAG解決方案親自嘗試這些模型。

（二）智能體

智能體將一些組件組合起來，并根據一定的規則迭代執行它們。智能體使用所謂的“思維鏈推理”概念，描述了以下迭代過程：發送請求、使用LLM解釋響應、決定下一步并再次行動。例如，有些問題通常太復雜，無法一次性回答，因為答案可能沒有寫在任何地方，人類會將其分解為更簡單的子問題來回答，然后計算出我們要找的答案，在這種情況下，智能體也會做同樣的事情。通過基于智能體的方法，我們可以顯著提高準確性。當然，這總是有一個權衡，與單次提示相比，我們增加了所需的計算能力和響應時間，但提高了準確性。最終，這種方法可能會讓較小、更快的模型超越更大模型的準確性，這可能是適合你解決方案的更好方法，但這總是取決于你的具體用例。例如，當我們構建一個純粹用于信息檢索的機器人時，我們總是要與搜索引擎的超短響應時間競爭，在這種情況下，響應時間就是關鍵，讓用戶等待幾秒甚至幾分鐘來獲取結果體驗會非常糟糕。

八、評估RAG系統

基于RAG的系統的性能在很大程度上取決于所提供的數據以及LLM提取有用信息的能力。為了評估整個系統，我們通常不僅要跟蹤整體性能，還要了解各個組件是否按預期運行。我們可以將其分為對檢索器組件和生成器組件的評估。

對于檢索部分，我們可以使用典型的搜索指標，如DCG（折扣累積增益）和nDCG（歸一化折扣累積增益）來評估排名質量，它們檢查在相似度搜索中真正相關的內容是否實際上被正確分類。

然而，評估模型的響應本身卻很棘手。因為語言具有模糊性，我們如何給輸出一個評價呢？最直接的方法是詢問很多人他們是否認為答案有幫助，比如找1000個人對LLM的答案進行評分，這能讓我們對模型的表現有一個大致的了解，但對于生產級解決方案來說，這相當不切實際。因為每次我們對RAG流程稍作更改，都會影響結果，而且要說服領域專家來測試我們的解決方案也很困難，我們不可能每次更改管道中的某些內容時都這么做。

所以我們需要想出更好的方法，其中一種方法是不使用人類評估，而是使用其他LLM來評估結果，也就是“LLM作為評判者”的方法。

（一）LLM作為評判者

使用“LLM作為評判者”的方法來評估生成部分，這個概念很簡單：

1. 步驟一：生成合成評估數據集

通常是一組包含（1）上下文、（2）問題和（3）答案的數據集。我們不一定有一個完整的數據集，可以通過向LLM提供上下文并讓它猜測可能的問題來自己創建，逐步構建一個合成數據集。

2. 步驟二：設置所謂的批評智能體

批評智能體是另一個LLM（通常是功能強大的），我們用它根據一些標準來評估系統的響應。例如，評估標準可以包括專業性，其定義可以是“專業性是指使用正式、尊重且適合上下文和受眾的溝通風格。通常包括避免過于隨意的語言、俚語或口語表達，而是使用清晰、簡潔和尊重的語言”。評分提示可以是：

專業性：如果答案使用專業語氣書寫，以下是不同分數的詳細信息：
- 分數1：語言非常隨意、不正式，可能包括俚語或口語表達，不適合專業場合。
- 分數2：語言隨意但總體尊重，避免強烈的不正式或俚語，在一些非正式的專業場合可以接受。
- 分數3：語言總體正式，但仍有一些隨意的單詞/短語，處于專業場合的邊緣。
- 分數4：語言平衡，避免極端的不正式或正式，適合大多數專業場合。
- 分數5：語言明顯正式、尊重，避免隨意元素，適合正式的商業或學術場合。

3.步驟三：測試RAG系統

使用剛剛創建的評估數據集來測試系統。對于我們要測試的每個指標/標準，我們定義一個詳細的描述（例如在1到5的范圍內），然后讓模型做出決定。這不是一門精確的科學，模型的答案會有所不同，但它能讓我們了解系統的性能表現。你可以在Prometheus的提示模板或Databricks的這個MLFlow教程中找到一些這種評分提示的示例。

（二）RAGAs（檢索增強生成評估）

RAGAs是一個框架，允許你評估RAG系統的每個組件。其核心概念之一同樣是“LLM作為評判者”/“LLM輔助評估”的思想，但Ragas提供了更多功能，包括不同的工具和技術，使你的RAG應用能夠持續學習。一個值得一提的核心概念是“組件級評估”。Ragas提供了預定義的指標來單獨評估RAG管道的每個組件，例如：

生成方面：

• 忠實度：生成的答案在事實上的準確性如何？
• 答案相關性：生成的答案與問題的相關性如何？

檢索方面：

• 上下文精度：檢索到的上下文的信噪比。
• 上下文召回率：它能否檢索到回答問題所需的所有相關信息？

其他指標則側重于評估RAG管道的端到端性能，比如答案語義相似度和答案正確性。

（三）持續從應用和用戶那里收集數據

收集數據是具體識別和填補流程中差距的關鍵。通常，我們提供給系統的知識庫中的數據本身可能不夠好。為了意識到這一點，我們需要引入一些方法，讓用戶盡可能輕松地提供反饋。其他有趣的指標包括時間戳、RAG管道中每個步驟的響應時間（向量化、相似度搜索、LLM響應等）、使用的提示模板、找到的相關文檔及其版本、LLM響應等等。RAG系統是由不同步驟組成的概念，為了優化性能和響應時間，我們需要知道瓶頸在哪里，這就是為什么我們要監控這些步驟，以便能夠針對最關鍵的部分進行改進。

九、總結：探索RAG之路，在試錯中前行

在RAG系統的發展和應用中，并沒有一條清晰明確的道路可以遵循，這需要大量的嘗試和錯誤。就像其他任何數據科學用例一樣，我們有一系列特定的工具可以用來嘗試找到解決我們特定問題的方案。

這也正是這些項目的樂趣所在，如果有一本固定的“食譜”可以遵循，那該多無趣啊。從Naive RAG到各種進階的RAG技術，我們在不斷地優化和改進，以應對實際應用中出現的各種挑戰。無論是數據質量的提升、索引和分塊的優化、檢索和生成過程的改進，還是系統的評估和持續數據收集，每一個環節都至關重要。

通過合理運用這17種進階RAG技術，我們能夠將RAG應用從一個簡單的原型逐步發展成為一個強大的、可投入生產的解決方案，更好地服務于用戶，推動人工智能在實際場景中的應用和發展。希望這些技術和方法能夠為正在探索RAG領域的你提供一些幫助和啟發，讓我們一起在RAG的世界里不斷探索和進步。

如果你在實際應用中對這些技術有任何疑問，或者有新的想法和經驗，歡迎在評論區留言分享，讓我們共同成長，共同推動RAG技術的發展。

最后，希望大家都能在RAG的應用中取得理想的成果，讓人工智能真正為我們的生活和工作帶來更多的便利和價值！

本文轉載自公眾號Halo咯咯    作者：基咯咯

原文鏈接：??https://mp.weixin.qq.com/s/pK6K-deSn-BUx8qOjHzFdg??