一、引言：GenAI熱潮下的RAG應(yīng)用挑戰(zhàn)

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

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

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

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

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

二、Naive RAG：最基礎(chǔ)的RAG系統(tǒng)概述

在構(gòu)建RAG系統(tǒng)時，我們站在了巨人的肩膀上，利用現(xiàn)有的概念和技術(shù)，并以合適的方式將它們組合起來。很多技術(shù)都源于搜索引擎領(lǐng)域，目標(biāo)是圍繞LLMs建立一個流程，為模型提供正確的數(shù)據(jù)，以便做出決策或總結(jié)信息。

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

RAG所做的就是將這些組件連接起來，以解決特定的問題。就像必應(yīng)搜索，它將傳統(tǒng)的“必應(yīng)”網(wǎng)絡(luò)搜索與LLMs的能力相結(jié)合，使得其聊天機器人能夠回答與現(xiàn)實生活數(shù)據(jù)相關(guān)的問題，比如 “谷歌今天的股價是多少？”

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

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

但多“近”才算足夠“近”呢？我們無法設(shè)置一個相似度分?jǐn)?shù)的閾值來區(qū)分相關(guān)和不相關(guān)的內(nèi)容，你可以自己試試，就會發(fā)現(xiàn)這并不實際。

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

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

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

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

這就是Naive RAG的基本過程，一個向量存儲、一個嵌入模型、一個LLM、幾行Python代碼，當(dāng)然還有一些文檔，就構(gòu)成了這樣一個簡單的系統(tǒng)。但當(dāng)我們將這些系統(tǒng)擴展，從原型轉(zhuǎn)變?yōu)樯a(chǎn)解決方案時，就會遇到各種現(xiàn)實問題。

三、RAG在實際應(yīng)用中的潛在陷阱

在實際應(yīng)用中，RAG系統(tǒng)可能會遇到各種問題：

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

四、提升RAG系統(tǒng)性能的關(guān)鍵步驟與技術(shù)

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

（一）原始數(shù)據(jù)創(chuàng)建與準(zhǔn)備

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

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

（二）索引與分塊：分塊優(yōu)化

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

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

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

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

（三）增強數(shù)據(jù)質(zhì)量：處理縮寫、技術(shù)術(shù)語和鏈接

數(shù)據(jù)清理技術(shù)可以去除不相關(guān)的信息，或?qū)⑽谋静糠种糜诤线m的上下文中，使其更易于理解。有時候，一個較長文本中特定段落的含義，在知道書籍上下文的情況下似乎很清楚，但如果上下文缺失，就會變得難以理解。縮寫、特定技術(shù)術(shù)語或公司內(nèi)部術(shù)語會讓模型很難理解文本的完整含義。

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

（四）添加元數(shù)據(jù)

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

（五）優(yōu)化索引結(jié)構(gòu)：全搜索與近似最近鄰，HNSW與IVFPQ

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

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

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

五、檢索優(yōu)化技術(shù)

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

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

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

（二）多重系統(tǒng)提示

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

（三）查詢路由

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

（四）混合搜索

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

六、后檢索優(yōu)化：上下文增強

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

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

（一）句子窗口檢索

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

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

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

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

當(dāng)我們索引數(shù)據(jù)并進行相似度搜索時，我們使用最小的塊，即葉節(jié)點。在此步驟之后，我們找到與葉節(jié)點匹配的父節(jié)點。

七、生成與智能體

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

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

（二）智能體

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

八、評估RAG系統(tǒng)

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

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

然而，評估模型的響應(yīng)本身卻很棘手。因為語言具有模糊性，我們?nèi)绾谓o輸出一個評價呢？最直接的方法是詢問很多人他們是否認(rèn)為答案有幫助，比如找1000個人對LLM的答案進行評分，這能讓我們對模型的表現(xiàn)有一個大致的了解，但對于生產(chǎn)級解決方案來說，這相當(dāng)不切實際。因為每次我們對RAG流程稍作更改，都會影響結(jié)果，而且要說服領(lǐng)域?qū)＜襾頊y試我們的解決方案也很困難，我們不可能每次更改管道中的某些內(nèi)容時都這么做。

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

（一）LLM作為評判者

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

1. 步驟一：生成合成評估數(shù)據(jù)集

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

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

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

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

3.步驟三：測試RAG系統(tǒng)

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

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

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

生成方面：

• 忠實度：生成的答案在事實上的準(zhǔn)確性如何？
• 答案相關(guān)性：生成的答案與問題的相關(guān)性如何？

檢索方面：

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

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

（三）持續(xù)從應(yīng)用和用戶那里收集數(shù)據(jù)

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

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

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

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

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

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

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

本文轉(zhuǎn)載自公眾號Halo咯咯    作者：基咯咯

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