鍵.png)
使用NestJS和Prisma構(gòu)建REST API：身份驗(yàn)證
除了 Transformer 模型之外，我們還使用了一系列技術(shù)，例如：
所有這些技術(shù)都已經(jīng)存在多年。向量搜索庫(kù) FAISS 于 2019 年發(fā)布。此外，文本向量化也不是什么新鮮事。[Ilin, 2024]
RAG 只是連接這些組件，以解決特定的問題。
例如，必應(yīng)搜索將其傳統(tǒng)的“BING”網(wǎng)絡(luò)搜索與大型語(yǔ)言模型的功能相結(jié)合。這使得他們的聊天機(jī)器人能夠回答“真實(shí)”生活數(shù)據(jù)的問題，例如：
下圖顯示了標(biāo)準(zhǔn)的 RAG 流程。當(dāng)用戶提出問題時(shí)，樸素 RAG 會(huì)將用戶的問題直接與我們向量數(shù)據(jù)庫(kù)中的任何內(nèi)容進(jìn)行比較。
我們感興趣的是找到相似的內(nèi)容。?相似內(nèi)容是指在我們的向量空間中彼此接近的內(nèi)容。距離是通過計(jì)算?余弦相似度?來衡量的，例如。
示例：
問題：“湯姆·布雷迪打過什么位置？”
假設(shè)我們的向量數(shù)據(jù)庫(kù)中有兩個(gè)主要數(shù)據(jù)源：
在下面的示例中，來自維基百科的內(nèi)容應(yīng)該更相關(guān)，因此更接近用戶的問題。
但是“接近”到什么程度才算“足夠接近”？
我們無法為相似度分?jǐn)?shù)設(shè)置一個(gè)閾值，以便區(qū)分相關(guān)內(nèi)容和不相關(guān)內(nèi)容。您可以自己嘗試一下，但您可能會(huì)意識(shí)到這樣做是不切實(shí)際的。
找到內(nèi)容了嗎？讓我們構(gòu)建提示
現(xiàn)在我們找到了一些與用戶問題相似的內(nèi)容，我們需要將所有這些內(nèi)容打包成一個(gè)有意義的提示。我們得到了一個(gè)至少包含 3 個(gè)構(gòu)建塊的提示。
一個(gè)合適的提示模板可能如下所示：
系統(tǒng)提示中的 “… 僅使用提供的信息” 部分將大型語(yǔ)言模型變成了一個(gè)處理和解釋信息的系統(tǒng)。在這種情況下，我們不會(huì)直接利用模型的知識(shí)來回答問題。
就是這樣。—— 就是這么簡(jiǎn)單。一個(gè)向量存儲(chǔ)、一個(gè)嵌入模型、一個(gè)大型語(yǔ)言模型、幾行 Python 代碼 —— 當(dāng)然還有一些文檔。
當(dāng)我們擴(kuò)展這些系統(tǒng)并將它們從原型轉(zhuǎn)變?yōu)樯a(chǎn)解決方案時(shí)，我們就會(huì)回到現(xiàn)實(shí)。
在這個(gè)過程中，我們很可能會(huì)遇到各種陷阱，例如：
如上所述，我們有不同的組件相互交互。這為我們提供了一系列可能的方法來提高整個(gè)系統(tǒng)的性能。
基本上，我們可以嘗試改進(jìn)以下 5 個(gè)流程步驟：
如果我們更仔細(xì)地觀察它們，就會(huì)得到下圖。
讓我們來看看它們中的每一個(gè)。
我們從最明顯和最簡(jiǎn)單的方法開始 — 數(shù)據(jù)質(zhì)量。對(duì)于大多數(shù) RAG 用例，它是文本數(shù)據(jù)，例如一些維基文章。
我們并非總是需要使用現(xiàn)有的數(shù)據(jù)。我們通?？梢杂绊懳臋n的創(chuàng)建過程。
通過大型語(yǔ)言模型和 RAG 應(yīng)用程序，我們突然被迫構(gòu)建我們的知識(shí)庫(kù)。在樸素 RAG 中，我們搜索信息片段，這些片段在某種程度上與用戶的問題相似。
這樣，模型永遠(yuǎn)不會(huì)看到維基的整個(gè)上下文，而只會(huì)看到單個(gè)文本片段。當(dāng)文檔包含以下內(nèi)容時(shí)，就會(huì)出現(xiàn)問題，例如：
如果一個(gè)沒有背景知識(shí)的人很難理解文本片段背后的全部含義，那么大型語(yǔ)言模型也會(huì)遇到困難。
在本文的后面部分，您將找到一些技術(shù)，這些技術(shù)試圖在檢索步驟之后或期間解決這些問題。
在理想的世界中，我們不需要它們。
我們維基百科中的每個(gè)部分都應(yīng)該盡可能易于理解，這對(duì)我們?nèi)祟悂碚f也更容易理解。這樣，我們就可以同時(shí)提高維基百科的可讀性和 RAG 應(yīng)用程序的性能。雙贏。
以下示例展示了我們?nèi)绾瓮ㄟ^以正確的方式設(shè)置內(nèi)容來簡(jiǎn)化 RAG 應(yīng)用程序的工作。
在下圖中，你可以看到一個(gè)類似于你在教程和技術(shù)文檔中經(jīng)常看到的例子。如果我們沒有純LLM，而是一個(gè)多模態(tài)模型，LLM將很難完全理解左側(cè)版本 1 中的內(nèi)容。版本 2 至少給了它更好的機(jī)會(huì)去理解。
RAG流程的下一步是以有意義的方式對(duì)數(shù)據(jù)進(jìn)行分塊，將其轉(zhuǎn)換為嵌入，并對(duì)其進(jìn)行索引。
Transformer 模型具有固定的輸入序列長(zhǎng)度。因此，我們發(fā)送到LLM和嵌入模型的提示的標(biāo)記大小是有限的。
但我認(rèn)為，這不是一個(gè)限制。
考慮文本片段和提示的最佳長(zhǎng)度是有意義的，因?yàn)檫@對(duì)性能有重大影響，例如：
有各種可用的文本分割器來對(duì)文本進(jìn)行分塊。
分塊的大小是一個(gè)需要考慮的參數(shù)，它取決于你使用的嵌入模型及其在標(biāo)記方面的能力，像基于 BERT 的句子轉(zhuǎn)換器這樣的標(biāo)準(zhǔn)轉(zhuǎn)換器編碼器模型最多接受 512 個(gè)標(biāo)記，一些嵌入模型能夠處理更長(zhǎng)的序列，8191 個(gè)標(biāo)記甚至更多。
但更大并不總是更好。我寧愿在一本書中找到包含兩條最重要信息的兩個(gè)句子，也不愿找到 5 頁(yè)包含答案的頁(yè)面。
這里的折衷方案是：
足夠的上下文供LLM進(jìn)行推理 vs. 足夠具體的文本嵌入以便有效地執(zhí)行搜索
有多種方法可以解決這些塊大小選擇問題。在 LlamaIndex 中，這由 NodeParser 類涵蓋，該類具有一些高級(jí)選項(xiàng)，例如定義自己的文本分割器、元數(shù)據(jù)、節(jié)點(diǎn)/塊關(guān)系等。
確保正確捕獲所有信息并且沒有任何部分被遺漏的最簡(jiǎn)單方法是使用滑動(dòng)窗口將整個(gè)文本嚴(yán)格分成幾部分。
這很簡(jiǎn)單，文本部分重疊 — 就是這樣。
除此之外，你還可以嘗試許多其他分塊技術(shù)來改進(jìn)分塊過程，例如：
數(shù)據(jù)清理技術(shù)可以去除不相關(guān)的信息，或者將文本片段放入上下文中，使其更容易理解。
有時(shí)，如果你知道這本書的上下文，那么較長(zhǎng)文本中特定段落的含義就非常清楚了。如果缺少上下文，就很難理解。
縮寫、特定的技術(shù)術(shù)語(yǔ)或公司內(nèi)部術(shù)語(yǔ)會(huì)使模型難以理解其全部含義。
下圖顯示了一些示例。
為了緩解這個(gè)問題，我們可以嘗試在處理數(shù)據(jù)時(shí)獲取必要的額外上下文，例如，使用縮寫翻譯表將縮寫替換為全文。
當(dāng)你圍繞文本到 SQL 的用例工作時(shí)，你肯定需要這樣做。許多數(shù)據(jù)庫(kù)中的字段名稱通常都很奇怪。通常只有開發(fā)者和上帝才知道某個(gè)特定字段名稱背后的含義。
SAP（企業(yè)資源規(guī)劃解決方案）經(jīng)常使用德語(yǔ)單詞的縮寫形式來標(biāo)記其字段。字段“WERKS”是德語(yǔ)單詞“Werkstoff”的縮寫，它描述了零件的原材料。
當(dāng)然，這對(duì)定義數(shù)據(jù)庫(kù)結(jié)構(gòu)的團(tuán)隊(duì)來說可能是有意義的。其他人將很難理解，包括我們的模型。
你可以在所有向量數(shù)據(jù)庫(kù)中向向量數(shù)據(jù)添加元數(shù)據(jù)。元數(shù)據(jù)可以在我們執(zhí)行向量搜索之前幫助（預(yù)先）過濾整個(gè)向量數(shù)據(jù)庫(kù)。
假設(shè)我們向量存儲(chǔ)中的一半數(shù)據(jù)是針對(duì)歐洲用戶的，另一半是針對(duì)美國(guó)用戶的。如果我們知道用戶的地理位置，我們就不想搜索整個(gè)數(shù)據(jù)庫(kù)，我們希望能夠直接搜索相關(guān)位。如果我們將此信息作為元數(shù)據(jù)字段，大多數(shù)向量存儲(chǔ)允許我們?cè)趫?zhí)行相似性搜索之前預(yù)先過濾數(shù)據(jù)庫(kù)。
我不認(rèn)為相似性搜索是大多數(shù) RAG 系統(tǒng)的弱點(diǎn) — 至少當(dāng)我們查看響應(yīng)時(shí)間時(shí)不是 — 但我還是想提一下。
大多數(shù)向量分?jǐn)?shù)中的相似性搜索速度非?？?，即使我們有數(shù)百萬(wàn)個(gè)條目，因?yàn)樗褂昧私谱罱徏夹g(shù) — 例如 FAISS、NMSLIB、ANNOY ……
FAISS、NMSLIB 或 ANNOY 使用一些近似最近鄰使之成為可能。
對(duì)于只有幾千個(gè)條目的用例來說，這通常是多余的。如果我們執(zhí)行 ANN 或完全最近鄰搜索，只會(huì)稍微影響 RAG 系統(tǒng)的響應(yīng)時(shí)間。
但是，如果你想建立一個(gè)可擴(kuò)展的系統(tǒng)，你當(dāng)然可以加快速度。
在對(duì)文本塊進(jìn)行嵌入時(shí)，有多種選擇。如果不確定使用哪些模型，可以查看現(xiàn)有的文本嵌入模型性能基準(zhǔn)測(cè)試，例如 MTEB（大規(guī)模文本嵌入基準(zhǔn)測(cè)試）。
在嵌入方面，我們通常需要決定嵌入的維度數(shù)。更高的維度可以捕捉和存儲(chǔ)句子更多的語(yǔ)義方面，但另一方面，它需要更多的存儲(chǔ)空間和計(jì)算時(shí)間。
我們將所有內(nèi)容轉(zhuǎn)換為嵌入向量，并將它們添加到向量數(shù)據(jù)庫(kù)中?，F(xiàn)在有來自不同提供商的多種模型可用。如果想了解可以使用哪些模型，可以查看langchain.embeddings模塊支持的模型。在模塊的源代碼中，你會(huì)發(fā)現(xiàn)一個(gè)相當(dāng)長(zhǎng)的支持模型列表：
__all__ = [
"OpenAIEmbeddings",
"AzureOpenAIEmbeddings",
"CacheBackedEmbeddings",
"ClarifaiEmbeddings",
"CohereEmbeddings",
...
"QianfanEmbeddingsEndpoint",
"JohnSnowLabsEmbeddings",
"VoyageEmbeddings",
"BookendEmbeddings"
]查詢擴(kuò)展、查詢重寫或查詢翻譯，所有這些方法都必須修改發(fā)送給 LLM 的原始查詢。
基本上，我們正在利用 LLM 的力量來增強(qiáng)和優(yōu)化我們發(fā)送到向量搜索的查詢。
有多種方法，例如：
讓我們從第一個(gè)開始。
在執(zhí)行相似性搜索之前，我們使用 LLM 生成答案。如果這是一個(gè)只能使用我們的內(nèi)部知識(shí)才能回答的問題，我們會(huì)間接地要求模型進(jìn)行幻覺，并使用幻覺的答案來搜索與答案相似的內(nèi)容，而不是用戶查詢本身。
有幾種技術(shù)，例如 HyDE（假設(shè)文檔嵌入）、重寫-檢索-讀取、后退提示、Query2Doc、ITER-RETGEN 等。
在 HyDE 中，我們讓 LLM 首先在沒有上下文的情況下為用戶的查詢創(chuàng)建一個(gè)答案，并使用該答案在我們的向量數(shù)據(jù)庫(kù)中搜索相關(guān)信息。
作為 HyDE 等方法的替代方法，我們可以使用多個(gè)系統(tǒng)提示來擴(kuò)展用戶的查詢。
這個(gè)想法很簡(jiǎn)單：我們生成例如 4 個(gè)不同的提示，這些提示將提供 4 個(gè)不同的響應(yīng)。
你可以發(fā)揮創(chuàng)造力。提示之間的區(qū)別可以是任何東西。
這個(gè)想法在數(shù)據(jù)科學(xué)中隨處可見。在 Boosting 算法中，我們通常有簡(jiǎn)單的模型，每個(gè)模型略有不同，做出一個(gè)小的決策。最后，我們以某種方式整合結(jié)果。這個(gè)概念非常強(qiáng)大。
我們?cè)谶@里做的是一樣的，只是再次使用模型來整合不同的預(yù)測(cè)。缺點(diǎn)當(dāng)然是計(jì)算時(shí)間和/或響應(yīng)時(shí)間更長(zhǎng)。
在查詢路由中，我們使用 LLM 的決策能力來決定下一步做什么。
假設(shè)我們的向量存儲(chǔ)中有來自不同領(lǐng)域的數(shù)據(jù)。為了更有針對(duì)性地搜索相關(guān)內(nèi)容，讓模型在第一步中決定我們應(yīng)該使用哪個(gè)數(shù)據(jù)池來回答問題是有意義的。
下圖中的示例向量存儲(chǔ)包含來自世界各地的新聞。有關(guān)體育和足球的新聞、烹飪趨勢(shì)和政治新聞。當(dāng)用戶查詢我們的聊天機(jī)器人時(shí)，我們不想混合這些數(shù)據(jù)。
國(guó)家之間的體育競(jìng)爭(zhēng)不應(yīng)該與政治混為一談。如果用戶正在尋找有關(guān)政治的新聞，那么有關(guān)烹飪的內(nèi)容可能沒有幫助。
通過這種方式，我們可以顯著提高性能。我們還可以讓最終用戶選擇用于回答問題的主題。
基本上，RAG 管道的檢索步驟就是一個(gè)搜索引擎。這可能是我們 RAG 系統(tǒng)中最重要的部分。
當(dāng)我們想要改進(jìn)相似性搜索時(shí)，值得關(guān)注一下搜索領(lǐng)域?；旌纤阉鞣椒ň褪且粋€(gè)例子。我們執(zhí)行向量搜索和詞匯（關(guān)鍵字）搜索，并以某種方式將這些結(jié)果結(jié)合在一起。
在機(jī)器學(xué)習(xí)中，這是一種常見的方法。擁有不同的技術(shù)、不同的模型，預(yù)測(cè)相同的輸出，并匯總結(jié)果。其思想始終是一致的。
一群專家試圖找到解決方案并做出妥協(xié)，這比一個(gè)獨(dú)立的專家做出更好的決策。
上下文豐富 – 例如句子窗口檢索
我們通常會(huì)盡量保持文本塊較小，以便找到我們想要的內(nèi)容并保持較高的搜索質(zhì)量。
另一方面，如果不僅能看到最匹配的句子，還能看到它周圍的上下文，通常會(huì)更容易給出正確的答案。
讓我們看一下下圖中的例子：
我們有一堆文本塊，來自一篇關(guān)于德國(guó)足球俱樂部拜仁慕尼黑的維基百科文章。我還沒有測(cè)試過，但我可以想象第一個(gè)文本片段會(huì)帶來最高的相似度得分。
盡管如此，第二個(gè)塊中的信息可能更相關(guān)。我們也希望捕捉到那一個(gè)。這就是上下文豐富發(fā)揮作用的地方。
有各種方法可以豐富上下文，下面我將簡(jiǎn)要描述其中兩種：
相似度得分最高的文本塊表示找到的最匹配的內(nèi)容。在將內(nèi)容發(fā)送到 LLM 之前，我們?cè)谡业降奈谋緣K前后添加 k 個(gè)句子。這是有意義的，因?yàn)檫@些信息很可能與中間部分相關(guān)聯(lián)，而且中間文本塊中的信息可能不完整。
自動(dòng)合并檢索器也是這樣做的，只是這一次，每個(gè)塊都附加了一些“父”塊，這些父塊不一定是找到的塊之前和之后的塊。
自動(dòng)合并檢索器的工作原理類似，只是這一次每個(gè)小的文本塊都被分配了某些“父”塊，這些父塊不一定是找到的文本塊之前和之后的塊。
您可以發(fā)揮您的所有創(chuàng)造力，定義和識(shí)別文本塊之間的相關(guān)關(guān)系。
例如，當(dāng)我們查看技術(shù)文檔或法律合同時(shí)，段落或章節(jié)通常會(huì)引用合同的其他部分。挑戰(zhàn)在于用其他段落中的相關(guān)信息來豐富段落。因此，我們需要能夠識(shí)別文本中引用文檔其他部分的鏈接。
我們可以在此概念的基礎(chǔ)上構(gòu)建一個(gè)完整的層次結(jié)構(gòu)，就像一個(gè)決策樹，具有不同級(jí)別的父節(jié)點(diǎn)、子節(jié)點(diǎn)和葉節(jié)點(diǎn)。例如，我們可以有 3 個(gè)級(jí)別，具有不同的塊大小 [LlamaIndex, 2024]：
當(dāng)我們對(duì)數(shù)據(jù)進(jìn)行索引并執(zhí)行相似性搜索時(shí)，我們使用的是最小的塊，即葉節(jié)點(diǎn)。在此步驟之后，我們找到葉的匹配父節(jié)點(diǎn)。
在檢索步驟之后，我們必須解釋找到的內(nèi)容并使用它來解決用戶查詢。為此，我們使用大型語(yǔ)言模型 (LLM)。但是哪種模型適合我們的用例呢？
為您的應(yīng)用程序選擇合適的模型并不像您想象的那么容易。這取決于具體的應(yīng)用和您的流程是什么樣的。
有些人會(huì)說，最明顯的解決方案是：
直接使用最強(qiáng)大的那個(gè)
然而，使用更小、更便宜、更快的模型有一些不可否認(rèn)的優(yōu)勢(shì)。
在 RAG 流程的某些部分，準(zhǔn)確性可以低一些，但響應(yīng)時(shí)間應(yīng)該很快，例如：當(dāng)我們使用基于代理的方法時(shí)，我們需要沿著管道不斷做出簡(jiǎn)單的決策。
此外，如果較小模型的響應(yīng)和決策能力足以滿足我們的用例，那么就沒有必要去追求最強(qiáng)大的模型。您將降低解決方案的運(yùn)營(yíng)成本，用戶也會(huì)感謝您改進(jìn)系統(tǒng)的響應(yīng)時(shí)間。
但是我們?nèi)绾芜x擇模型呢？
有幾個(gè)基準(zhǔn)測(cè)試，從不同的角度比較了 LLM。但最終，我們只需要為我們的 RAG 解決方案嘗試一下它們。
代理結(jié)合了一些組件，并根據(jù)一定的規(guī)則迭代地執(zhí)行它們。
代理使用所謂的“思維鏈推理”概念，它描述了以下迭代過程：
下圖中的問題顯示了一個(gè)通常過于復(fù)雜而無法一次性回答的示例，因?yàn)榇鸢负芸赡軟]有寫在任何地方。
我們?nèi)祟悤?huì)把它分解成我們可以回答的更簡(jiǎn)單的子問題，然后計(jì)算出我們想要的答案。代理在這種情況下也是這樣做的。
使用基于代理的方法，我們可以顯著提高準(zhǔn)確性。當(dāng)然，總會(huì)有一個(gè)權(quán)衡。與一次性提示相比，我們?cè)黾恿怂璧挠?jì)算能力和響應(yīng)時(shí)間。但提高了準(zhǔn)確性。
盡管如此，使用這種方法，我們可以用更小、更快的模型超越更大模型的準(zhǔn)確性。最終，這對(duì)您的解決方案來說可能是更好的方法。
這始終取決于您的具體用例 — 當(dāng)我們構(gòu)建一個(gè)用于純粹信息檢索的機(jī)器人時(shí)，我們一直在與搜索引擎的超短響應(yīng)時(shí)間競(jìng)爭(zhēng)。
響應(yīng)時(shí)間是關(guān)鍵。
等待幾秒甚至幾分鐘的結(jié)果很糟糕。
基于 RAG 的系統(tǒng)的性能高度依賴于提供的數(shù)據(jù)和 LLM 提取有用信息的能力。為此，我們需要幾個(gè)組件協(xié)同工作。當(dāng)我們想要評(píng)估整個(gè)系統(tǒng)時(shí)，我們通常不僅要跟蹤整體性能，還要了解各個(gè)組件是如何完成其應(yīng)盡職責(zé)的。
和以前一樣，我們可以將其分為檢索器組件和生成器組件的評(píng)估。
我們可以使用典型的搜索指標(biāo)（如 DCG 和 nDCG）來評(píng)估搜索部分，這些指標(biāo)用于評(píng)估排名質(zhì)量。它們檢查真正相關(guān)的內(nèi)容在相似性搜索中是否確實(shí)被歸類為此類。[EvidentlyAI, 2024][Leonie Monigatti, 2023]
“理想排名”與真實(shí)排名：NDCG 作為一種幫助評(píng)估排名質(zhì)量的指標(biāo) — 圖片由作者提供 [EvidentlyAI, 2024]
評(píng)估模型本身的響應(yīng)非常棘手。
我們?nèi)绾卧u(píng)估響應(yīng)？語(yǔ)言是模棱兩可的，所以我們?nèi)绾谓o輸出一個(gè)類似于評(píng)級(jí)的評(píng)價(jià)呢？
最簡(jiǎn)單的方法是詢問很多人他們是否認(rèn)為答案有幫助——假設(shè)我們讓 1000 個(gè)人對(duì) LLM 的答案進(jìn)行評(píng)分。這將使您很好地了解它的工作情況。但對(duì)于一個(gè)高效的解決方案來說，這是不切實(shí)際的。
每次稍微更改 RAG 過程時(shí)，都會(huì)影響結(jié)果。我知道說服領(lǐng)域?qū)＜覝y(cè)試您的解決方案是多么困難。我們可以做一兩次，但不是每次我們更改管道中的某些內(nèi)容時(shí)都這樣做。
所以我們需要想出一個(gè)更好的辦法。一種方法是，我們不使用人工，而是使用其他 LLM 來評(píng)估結(jié)果——所以我們使用模型“作為評(píng)判者”的方法。
可以使用 LLM 作為評(píng)判者的方法來評(píng)估生成部分。這個(gè)概念很簡(jiǎn)單。
步驟 (1) — 生成一個(gè)合成評(píng)估數(shù)據(jù)集
通常是一組（1）上下文、（2）問題和（3）答案。我們不一定有一個(gè)完整的數(shù)據(jù)集。我們可以通過向 LLM 提供上下文并讓它猜測(cè)可能提出的問題來自己創(chuàng)建它。一步一步地建立一個(gè)合成數(shù)據(jù)集。
步驟 (2) — 建立一個(gè)所謂的“批評(píng)代理”
“批評(píng)代理”是另一個(gè) LLM（通常是一個(gè)強(qiáng)大的 LLM），我們使用它根據(jù)一些標(biāo)準(zhǔn)來評(píng)估系統(tǒng)的響應(yīng)，例如：
一個(gè)示例指標(biāo)定義可能如下所示 [Databricks, 2023]：
definition=(
"Professionalism refers to the use of a formal, respectful, and appropriate style of communication that is "
"tailored to the context and audience. It often involves avoiding overly casual language, slang, or "
"colloquialisms, and instead using clear, concise, and respectful language."
),
grading_prompt=(
"Professionalism: If the answer is written using a professional tone, below are the details for different scores: "
"- Score 1: Language is extremely casual, informal, and may include slang or colloquialisms. Not suitable for "
"professional contexts."
"- Score 2: Language is casual but generally respectful and avoids strong informality or slang. Acceptable in "
"some informal professional settings."
"- Score 3: Language is overall formal but still have casual words/phrases. Borderline for professional contexts."
"- Score 4: Language is balanced and avoids extreme informality or formality. Suitable for most professional contexts. "
"- Score 5: Language is noticeably formal, respectful, and avoids casual elements. Appropriate for formal "
"business or academic settings. "
),步驟 (3) — 測(cè)試 RAG 系統(tǒng)：使用剛剛創(chuàng)建的評(píng)估數(shù)據(jù)集，我們開始測(cè)試系統(tǒng)
對(duì)于我們要測(cè)試的每個(gè)指標(biāo)/標(biāo)準(zhǔn)，我們定義一個(gè)詳細(xì)的描述（例如，在 1-5 的范圍內(nèi)），然后讓模型做出決定。這不是一門精確的科學(xué)，模型的答案會(huì)有所不同，但它讓我們了解系統(tǒng)運(yùn)行情況。
您可以在 Prometheus 的提示模板 或 Databricks 的 MLFlow 教程 中找到此評(píng)分提示外觀的一些示例。
RAGAs（檢索增強(qiáng)生成評(píng)估） 是一個(gè)框架，允許您評(píng)估 RAG 系統(tǒng)的每個(gè)組件。
一個(gè)核心概念仍然是“LLM 作為評(píng)判者”/“LLM 輔助評(píng)估”背后的理念。但 Ragas 提供的遠(yuǎn)不止這些。它還提供了不同的工具和技術(shù)來實(shí)現(xiàn) RAG 應(yīng)用程序的持續(xù)學(xué)習(xí)。
值得一提的是一個(gè)核心概念，“組件式評(píng)估”。Ragas 提供預(yù)定義的指標(biāo)來分別評(píng)估 RAG 流水線的每個(gè)組件，例如 [Ragas, 2024]：
生成：
檢索：
其他指標(biāo)側(cè)重于端到端評(píng)估 RAG 流水線，例如：
收集數(shù)據(jù)是具體識(shí)別和填補(bǔ)流程中空白的關(guān)鍵。通常，知識(shí)庫(kù)中提供給系統(tǒng)的數(shù)據(jù)本身不夠好。為了意識(shí)到這一點(diǎn)，我們需要引入一些方法，讓用戶能夠盡可能輕松地提供反饋。
其他有趣的指標(biāo)有
RAG 系統(tǒng)是一個(gè)包含不同步驟的概念。為了優(yōu)化性能和響應(yīng)時(shí)間，我們需要知道瓶頸在哪里。這就是為什么我們要監(jiān)控這些步驟，以便我們能夠在最大的杠桿上努力。
沒有明確的道路可循。這是一個(gè)不斷試錯(cuò)的過程。與任何其他數(shù)據(jù)科學(xué)用例一樣，我們有一套特定的工具，可以使用這些工具來嘗試找到針對(duì)特定問題的解決方案。
這就是這些項(xiàng)目一開始就很有趣的原因。如果有一本靜態(tài)的食譜可以遵循，那不是很無聊嗎？
請(qǐng)?jiān)谠u(píng)論中告訴我你的想法。
文章轉(zhuǎn)自微信公眾號(hào)@知覺之門
對(duì)比大模型API的內(nèi)容創(chuàng)意新穎性、情感共鳴力、商業(yè)轉(zhuǎn)化潛力
一鍵對(duì)比試用API 限時(shí)免費(fèi)
