將RAG擴展到生產(chǎn)環(huán)境是一項復(fù)雜的挑戰(zhàn)，需要考慮多個方面，本文將深入探討這些挑戰(zhàn)，并提供解決方案。

RAG如何演變？

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

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

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

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

一個基本的RAG系統(tǒng)通常包含以下步驟：

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

RAG基本架構(gòu)

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

RAG 2.0的演變

簡而言之，RAG 2.0開始對系統(tǒng)進行端到端訓練，從而使所有組件更加流暢，彼此協(xié)調(diào)。

一個好的生產(chǎn)級RAG系統(tǒng)應(yīng)該能夠做到以下幾點：

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

每個方面對于構(gòu)建生產(chǎn)級RAG系統(tǒng)都至關(guān)重要。

真正的問題不在于技術(shù)，而在于流程

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

每個流程都處于完全確定性到極度隨機性的范圍內(nèi)。根據(jù)具體任務(wù)，整個流程都會發(fā)生變化。例如，創(chuàng)意寫作是極度隨機的，而湍流計算需要高度確定性。

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

我經(jīng)?？吹剑藗儗λ麄兊慕鉀Q方案需要多少確定性一無所知。他們不斷地構(gòu)建最常見或最著名的解決方案，這就是為什么這些POC無法擴展的原因。

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

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

沒有一個系統(tǒng)能夠解決所有這些挑戰(zhàn)，這就是主題領(lǐng)域?qū)I(yè)知識發(fā)揮作用的地方。根據(jù)用例，整個流程將被設(shè)計為處理速度、基礎(chǔ)性和數(shù)據(jù)類型方面不同的問題。

主要挑戰(zhàn)

以下是人們在設(shè)計生產(chǎn)級RAG時面臨的一些基本挑戰(zhàn)：

與響應(yīng)質(zhì)量相關(guān)的挑戰(zhàn)

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

可擴展性

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

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

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

RAG系統(tǒng)組件

1. 查詢分類

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

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

2. 分割

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

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

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

3. 利用元數(shù)據(jù)和混合搜索

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

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

4. 嵌入模型選擇

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

5. 向量數(shù)據(jù)庫

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

向量數(shù)據(jù)庫比較

向量數(shù)據(jù)庫比較（續(xù)）

6. 查詢轉(zhuǎn)換

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

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

每種轉(zhuǎn)換技術(shù)都會對檢索結(jié)果產(chǎn)生重大影響，因此值得根據(jù)你的延遲和準確性需求進行試驗。

7. 重新排序

檢索之后，我們可能會有幾個結(jié)果需要根據(jù)相關(guān)性進行排序。這就是重新排序的作用。

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

8. 文檔重新打包

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

9. 摘要

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

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

10. 微調(diào)生成器

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

此步驟與領(lǐng)域相關(guān)，因此請確保你在特定領(lǐng)域的數(shù)據(jù)庫上微調(diào)模型，以獲得最佳性能。

11. 多模態(tài)

如果你正在處理多模態(tài)輸入，例如圖像和文本，那么多模態(tài)檢索至關(guān)重要。例如，在處理圖像到文本的任務(wù)時，你可以檢索類似的圖像及其對應(yīng)的標題，以幫助LLM將其響應(yīng)與真實數(shù)據(jù)聯(lián)系起來。

結(jié)論

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

此外，如果它真的那么容易，那么每個人都可以做到，那么你比其他企業(yè)有什么優(yōu)勢？沒有。這就是為什么系統(tǒng)設(shè)計是你的技術(shù)棧在擁擠的AI代理領(lǐng)域脫穎而出的唯一因素。祝你好運，構(gòu)建你的生產(chǎn)級RAG流程。

本文轉(zhuǎn)載自 ??DevOpsAI??，作者： RAG