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

RAG如何演變？

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

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

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

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

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

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

RAG基本架構(gòu)

最初的RAG面臨的問題是，這些組件并非設(shè)計(jì)為無縫協(xié)作，因?yàn)樗鼈兌际仟?dú)立設(shè)計(jì)的，因此各個(gè)組件之間存在很多摩擦。

RAG 2.0的演變

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

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

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

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

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

人們犯的一個(gè)最重要的錯(cuò)誤是不理解他們?cè)噲D自動(dòng)化哪些流程。

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

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

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

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

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

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

主要挑戰(zhàn)

以下是人們?cè)谠O(shè)計(jì)生產(chǎn)級(jí)RAG時(shí)面臨的一些基本挑戰(zhàn)：

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

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

可擴(kuò)展性

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

所有這些問題都在這兩篇博文中進(jìn)行了詳細(xì)討論。

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

RAG系統(tǒng)組件

1. 查詢分類

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

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

2. 分割

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

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

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

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

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

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

4. 嵌入模型選擇

選擇合適的嵌入模型至關(guān)重要。你可以選擇閉源模型，例如GPT、Cohere的Command R或Meta的Llama。仔細(xì)決定你要使用哪種模型，因?yàn)槠渌M件可能依賴于它。

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

我將提供一個(gè)比較表，供你選擇。

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

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

6. 查詢轉(zhuǎn)換

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

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

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

7. 重新排序

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

以下是一些用于重新排序的選項(xiàng)：monoT5、RankLLaMA、TILDEv2

8. 文檔重新打包

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

9. 摘要

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

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

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

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

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

11. 多模態(tài)

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

結(jié)論

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

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

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