將RAG擴展到生產環境是一項復雜的挑戰，需要考慮多個方面，本文將深入探討這些挑戰，并提供解決方案。

RAG如何演變？

RAG（Retrieval-Augmented Generation，檢索增強生成）是一種技術，通過為大型語言模型（LLM）提供額外的上下文信息，使其能夠生成更準確、更具體的響應。LLM在公開數據上進行訓練，本身非常智能，但由于缺乏特定領域知識，無法回答特定問題。RAG通過提供必要的上下文信息，幫助LLM正確回答查詢。

RAG是向LLM注入新知識或能力的一種方式，這種注入不是永久性的。另一種方法是通過微調LLM來添加新知識或能力。

通過微調添加新知識，難度大，成本高，且是永久性的。通過微調添加新能力，還會影響LLM之前擁有的知識。在微調過程中，我們無法控制哪些權重會被改變，因此無法控制哪些能力會增強或減弱。

無論是選擇微調、RAG，還是兩者結合，都取決于具體的任務。沒有一種方法適用于所有情況。

一個基本的RAG系統通常包含以下步驟：

• 將文檔拆分成更小的片段。
• 每個片段都是一段原始文本。
• 使用編碼器（例如OpenAI embeddings、sentence_transformer）為每個片段生成嵌入，并將其存儲在數據庫中。
• 找到Top-K個最相似的編碼片段，獲取這些片段的原始文本，并將它們與提示一起作為上下文提供給生成器。

RAG基本架構

最初的RAG面臨的問題是，這些組件并非設計為無縫協作，因為它們都是獨立設計的，因此各個組件之間存在很多摩擦。

RAG 2.0的演變

簡而言之，RAG 2.0開始對系統進行端到端訓練，從而使所有組件更加流暢，彼此協調。

一個好的生產級RAG系統應該能夠做到以下幾點：

• 開放域問答：能夠很好地處理自然的人類語言查詢。能夠正確檢索相關知識，并以人類語言準確地生成答案。
• 忠實度：系統必須能夠保持對檢索到的證據的依賴，避免幻覺。一些好的基準測試包括HaluEvalQA和TruthfulQA。
• 新鮮度：這些系統應該能夠通過使用網絡搜索索引來適應快速變化的全球知識，并在最近發生的事件中表現出準確性。

每個方面對于構建生產級RAG系統都至關重要。

真正的問題不在于技術，而在于流程

人們犯的一個最重要的錯誤是不理解他們試圖自動化哪些流程。

每個流程都處于完全確定性到極度隨機性的范圍內。根據具體任務，整個流程都會發生變化。例如，創意寫作是極度隨機的，而湍流計算需要高度確定性。

想象一下，你正在嘗試自動化醫療行業的流程。系統需要始終工作（幾乎）。沒有幻覺的容錯空間，這種系統的系統設計將與隨機系統的系統設計完全不同。你將嘗試在流程中最關鍵的部分集成人工干預。但如果系統是為餐廳設計的，你就不太在意這一點。

我經常看到，人們對他們的解決方案需要多少確定性一無所知。他們不斷地構建最常見或最著名的解決方案，這就是為什么這些POC無法擴展的原因。

在你構建任何RAG系統或任何其他系統之前，都要確定你真正需要什么。如果說的是RAG系統，主要有三個方面：

• 速度：一個包含一百萬份文檔的RAG系統，不可能設計成每次查詢都需要5分鐘才能得到答案，沒有人會使用它。嘗試將一百萬份文檔整合在一起，看看你POC的速度，它會慘敗。這種系統的系統設計需要使用最快的檢索機制。其他一切都是次要的。
• 基礎性：隨著文檔數量的增加，找到Top-K個相關文檔變得極其困難。特別是如果文檔包含很多交叉引用，這個問題就更加困難。
• 處理不同數據類型的能力：處理不同文檔所需的流程會隨著數據格式的變化而發生顯著變化。例如，PDF可能具有非常復雜的結構，包含大量表格數據、圖像，甚至布局。PDF中最難解決的挑戰之一是如何處理圖表、流程圖，以及文本出現在圖像中的情況。

沒有一個系統能夠解決所有這些挑戰，這就是主題領域專業知識發揮作用的地方。根據用例，整個流程將被設計為處理速度、基礎性和數據類型方面不同的問題。

主要挑戰

以下是人們在設計生產級RAG時面臨的一些基本挑戰：

與響應質量相關的挑戰

1. 知識庫中缺少上下文
2. 初始檢索過程中缺少上下文
3. 重新排序后缺少上下文
4. 未提取上下文
5. 輸出格式錯誤
6. 輸出的具體程度不正確
7. 輸出不完整

可擴展性

8. 無法擴展到更大的數據量
9. 速率限制錯誤

所有這些問題都在這兩篇博文中進行了詳細討論。

但讓我們討論更多挑戰，并了解下面流程中每個組件的作用。

RAG系統組件

1. 查詢分類

并非所有查詢都需要檢索。一些查詢，例如“梅西是誰？”，答案存儲在LLM的內部知識庫中，因此不需要檢索。這就是查詢分類的概念，根據查詢的復雜程度來確定是否需要檢索。

王等人將查詢劃分為15個任務類別，并使用二元分類器來評估一個查詢是“足夠”（LLM本身可以回答）還是“不足”（需要檢索）。這一初始步驟簡化了流程，確保系統在LLM有足夠信息的情況下不會執行不必要的檢索。

2. 分割

這里的挑戰是找到適合你的檢索過程的理想片段大小。如果你的片段太大，你可能會在檢索過程中增加噪音和不必要的成本。太小？你可能會丟失關鍵的上下文信息。

通常情況下，256到512個token之間的尺寸是最佳的。但是，這會根據你的數據而有所不同，因此評估是關鍵。使用從小到大的方法——從小的片段開始搜索，然后轉向較大的片段進行生成，這在調整流程時可能會有所幫助。

另一種技術是使用滑動窗口來創建重疊的片段，確保在各個片段之間不會丟失任何重要信息。

3. 利用元數據和混合搜索

元數據在檢索方面可以改變游戲規則。添加標題、關鍵詞或假設問題等元數據可以提高檢索到的文檔的相關性。將元數據與混合搜索（將_向量搜索_用于語義匹配，將BM25用于基于關鍵詞的匹配）相結合，可以實現精確結果的完美平衡。

另一種有趣的技術是HyDE（假設文檔嵌入），它生成偽文檔來提高檢索質量。雖然它可以提供更好的結果，但它效率低下，會增加顯著的延遲。對于大多數情況，混合搜索是兼顧效率和質量的最佳選擇。但請記住，每個案例都不同，因此要進行適當的評估。

4. 嵌入模型選擇

選擇合適的嵌入模型至關重要。你可以選擇閉源模型，例如GPT、Cohere的Command R或Meta的Llama。仔細決定你要使用哪種模型，因為其他組件可能依賴于它。

5. 向量數據庫

我將提供一個比較表，供你選擇。

向量數據庫比較

向量數據庫比較（續）

6. 查詢轉換

在將你的查詢發送到檢索引擎之前，我們需要進行查詢轉換來提高準確性。方法包括：

• 查詢重寫：重新措辭或簡化查詢，使其更清晰。
• 查詢分解：將復雜的查詢分解成更小、更容易管理的子查詢。
• HyDE：根據查詢生成偽文檔，但這會增加顯著的延遲。

每種轉換技術都會對檢索結果產生重大影響，因此值得根據你的延遲和準確性需求進行試驗。

7. 重新排序

檢索之后，我們可能會有幾個結果需要根據相關性進行排序。這就是重新排序的作用。

以下是一些用于重新排序的選項：monoT5、RankLLaMA、TILDEv2

8. 文檔重新打包

重新排序后，我們需要重新打包文檔，以優化它們呈現給LLM的方式。一項研究表明，“反向”方法，即最相關的文檔放在序列的開頭或結尾，效果最好。這有助于LLM在生成過程中有效地處理最重要的信息。按照相關性升序排列文檔可以提高生成任務的性能。

9. 摘要

將大型提示發送給LLM既昂貴又往往是多余的。在將檢索到的文檔傳遞給LLM之前，摘要是一個至關重要的步驟，可以減少文檔的大小。

Recomp是一個出色的工具，它提供提取式摘要和抽象式摘要。提取式摘要選擇最重要的句子，而抽象式摘要將來自多個來源的信息綜合成更簡潔的格式。但是，如果你在時間限制下工作，可以考慮跳過此步驟。

10. 微調生成器

你是否應該為生成任務微調LLM？當然！使用相關文檔和不相關文檔的混合進行微調，有助于生成器變得更加健壯。雖然我們不知道相關文檔與不相關文檔的確切比例，但結果很明顯：微調會導致更準確、更具上下文意識的響應。

此步驟與領域相關，因此請確保你在特定領域的數據庫上微調模型，以獲得最佳性能。

11. 多模態

如果你正在處理多模態輸入，例如圖像和文本，那么多模態檢索至關重要。例如，在處理圖像到文本的任務時，你可以檢索類似的圖像及其對應的標題，以幫助LLM將其響應與真實數據聯系起來。

結論

本文討論的每個組件都需要花費更多的時間思考，你可能需要所有這些組件，甚至可能需要更多組件。選擇合適的組件對于生產級RAG的成功至關重要。市面上有很多拖放式的AI代理和RAG，但它們往往在生產環境中無法正常工作。

此外，如果它真的那么容易，那么每個人都可以做到，那么你比其他企業有什么優勢？沒有。這就是為什么系統設計是你的技術棧在擁擠的AI代理領域脫穎而出的唯一因素。祝你好運，構建你的生產級RAG流程。

本文轉載自 ??DevOpsAI??，作者： RAG