文章轉載自公眾號：NLP工作站，本文只做學術/技術分享，如有侵權，聯系刪文。今天給大家帶來一篇知乎@孫鵬飛 的關于RAG實戰的文章。作者：孫鵬飛知乎：https://zhuanlan.zhihu.com/p/68225349601背景介紹RAG（Retrieval Augmented Generation，檢索增強生成 ）方法是指結合了基于檢索的模型和生成模型的能力，以提高生成文本的質量和相關性。該方法是Meta在2020年發表的文章《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出的，該方法讓LM（Language Model，語言模型）能夠獲取內化知識之外的信息，并允許LM在專業知識庫的基礎上，以更準確的方式回答問題。而在大模型時代，它更是用于解決幻覺問題、知識時效問題、超長文本問題等各種大模型本身制約或不足的必要技術。02RAG的挑戰RAG主要面臨三個方面的挑戰：檢索質量、增強過程和生成質量。2.1 檢索質量語義歧義：向量表示（例如詞嵌入）可能無法捕捉概念之間的細微差別。例如，“蘋果”一詞可能指的是水果或科技公司。嵌入可能會混淆這些含義，導致不相關的結果。用戶輸入變復雜：與傳統關鍵詞或者短語搜索邏輯不太一致，用戶輸入問題不再是詞或者短句，而是轉變成自然對話聲知識多輪對話數據，問題形式更加多元，緊密關聯上下文，輸入風格更加口語化。文檔切分：文檔切分主要有兩種方式：一種是基于形式的切分，比如利用標點和段落的結束；另一種是基于文檔內容的意義進行切分。如何將這些文檔塊轉換成電腦能夠理解和比較的形式（即“嵌入”），進而影響這些塊與用戶搜索內容的匹配程度。多模內容的提取及表征（例如表格、圖表、公式等）：如何對多模內容進行提取及動態表征，是目前面臨的現實問題，尤其是處理那些含糊或負面的查詢，對 RAG 系統的性能有顯著影響。2.2 增強過程上下文的集成：這里的挑戰是將檢索到的段落的上下文與當前的生成任務順利地集成。如果做得不好，輸出可能會顯得脫節或缺乏連貫性。冗余和重復：如果多個檢索到的段落包含相似的信息，則生成步驟可能會產生重復的內容。排名和優先級：確定多個檢索到的段落對于生成任務的重要性或相關性可能具有挑戰性。增強過程必須適當權衡每個段落的價值。2.3 生成質量過度依賴檢索內容：生成模型可能過于依賴增強信息，導致幻覺問題突出，而不是增加價值或提供合成。無關性：這是另一個令人擔憂的問題，即模型生成的答案無法解決查詢問題。毒性或偏見：這也是另一個問題，即模型生成的答案有害或令人反感。03整體架構3.1 產品架構從圖上可以清晰的看出，整個產品架構包含如下四層：最底層是模型層。在模型層屏蔽掉了模型的差異，不僅可以支持自研的序列猴子，也可以支持開源的大模型，第三方的模型。此外，為了優化embedding的效果，提出一種跨語言Embedding模型，有效的解決跨語言檢索問題，同時提高了模型的效果。離線理解層。在該層，主要圍繞智能知識庫和搜索增強兩個模塊設計的。關于智能知識庫主要負責將非結構化的文本進行處理，從而轉化為檢索知識庫，主要包括文本解析，表格識別，OCR識別等。搜索增強通過引入問句改寫、重排等模塊，保證檢索的精準度。在線問答層，為了滿足產品設計需要，這里支持多文檔、多輪次、多模態及安全性與拒識等，在一定程度上提高了產品的競爭力，同時也滿足了不同場景的用戶需求。場景層，針對不同行業的特點，預制多種場景類角色，降低產品使用門檻。3.2 技術架構為了理解檢索增強生成框架，我們將其分為三個主要組成部分：query理解、檢索模型和生成模型。query理解：該模塊旨在對用戶的query進行理解或者將用戶的query生成結構化的查詢，既可以查詢結構化的數據庫也可以查詢非結構化的數據，進而提高召回率。該模塊包括四部分，他們分別是query改寫，query擴寫和意圖識別等。各個模塊的介紹我們將在之后的章節進行詳細介紹。檢索模型：該模型旨在從給定的文檔集或知識庫中檢索相關信息。他們通常使用信息檢索或語義搜索等技術來根據給定的查詢識別最相關的信息。基于檢索的模型擅長查找準確且具體的信息，但缺乏生成創意或新穎內容的能力。從技術上來講， 檢索模型主要包括文檔加載、文本轉換、Embedding等模塊。我們將在之后的章節中詳細介紹。生成模型：該模型旨在根據給定的Prompt或上下文生成新內容。目前，生成模型可以生成富有創意且連貫的文本，但它們可能會在事實準確性或與特定上下文的相關性方面遇到困難。在RAG框架中，生成模型主要包括chat系統（長期記憶和短期記憶）、Prompt優化等。這些內容在之后的章節中也會介紹。總之，檢索增強生成結合了檢索模型和生成模型優勢，克服它們各自的局限性。在此框架中，基于檢索的模型用于根據給定的查詢或上下文從知識庫或一組文檔中檢索相關信息。然后，檢索到的信息將用作生成模型的輸入或附加上下文。通過整合檢索到的信息，生成模型可以利用基于檢索的模型的準確性和特異性來生成更相關、更準確的文本。這有助于生成模型立足于現有知識，生成與檢索信息一致的文本。04Query理解目前，RAG系統可能會遇到從知識庫中檢索到與用戶query不相關的內容。這是由于如下問題：（1）用戶問題的措辭可能不利于檢索，（2）可能需要從用戶問題生成結構化查詢。為了解決上述問題，我們引入query理解模塊。4.1 意圖識別意圖識別是指接收用戶的query和一組”選擇”（由元數據定義）并返回一個或多個選定的”選擇模塊”。它既可以單獨使用（作為 “選擇器模塊”），也可以作為查詢引擎或檢索器使用（例如，在其他查詢引擎/檢索器之上）。它是原理簡單但功能強大的模塊，目前主要利用 LLM 實現決策功能。它可以應用于如下場景：在各種數據源中選擇正確的數據源；決定是進行摘要（如使用摘要索引查詢引擎）還是進行語義搜索（如使用矢量索引查詢引擎）；決定是否一次 “嘗試 “多種選擇并將結果合并（使用多路由功能）。核心模塊有以下幾種形式：LLM 選擇器將選擇作為文本轉儲到提示中，并使用 LLM 做出決定；構建傳統的分類模型，包括基于語義匹配的分類模型、Bert意圖分類模型等。4.2 Query改寫該模塊主要利用LLM重新措辭用戶query，而不是直接使用原始的用戶query進行檢索。這是因為對于RAG系統來說，在現實世界中原始query不可能總是最佳的檢索條件。4.2.1 HyDEHypothetical Document Embeddings（HyDE）是一種生成文檔嵌入以檢索相關文檔而不需要實際訓練數據的技術。首先，LLM創建一個假設答案來響應query。雖然這個答案反映了與query相關的模式，但它包含的信息可能在事實上并不準確。接下來，query和生成的答案都被轉換為嵌入。然后，系統從預定義的數據庫中識別并檢索在向量空間中最接近這些嵌入的實際文檔。4.2.2 Rewrite-Retrieve-Read這項工作引入了一個新的框架–Rewrite-Retrieve-Read，從query改寫的角度改進了檢索增強方法。之前的研究主要是調整檢索器或LLM。與之不同的是，該方法注重query的適應性。因為對于 LLM 來說，原始query并不總是最佳檢索結果，尤其是在現實世界中。首先利用LLM 進行改寫query，然后進行檢索增強。同時，為了進一步提高改寫的效果，應用小語言模型（T5）作為可訓練的改寫器，改寫搜索query以滿足凍結檢索器和 LLM的需要。為了對改寫器進行微調，該方法還使用偽數據進行有監督的熱身訓練。然后，將 “先檢索后生成 “管道建模為強化學習環境。通過最大化管道性能的獎勵，改寫器被進一步訓練為策略模型。4.3 Query擴寫該模塊主要是為了將復雜問題拆解為子問題。該技術使用分而治之的方法來處理復雜的問題。它首先分析問題，并將其分解為更簡單的子問題，每個子問題會從提供部分答案的相關文件檢索答案。然后，收集這些中間結果，并將所有部分結果合成為最終響應。4.3.1 Step-Back Prompting該工作探索了LLM如何通過抽象和推理兩個步驟來處理涉及許多低級細節的復雜任務。第一步先是使用 LLM “后退一步”生成高層次的抽象概念，將推理建立在抽象概念的基礎上，以減少在中間推理步驟錯的概率。這種方法即可以在有檢索的情況下使用，也可以在無檢索的情況下使用。當在有檢索情況下使用時，抽象的概念和原始問題都用來進行檢索，然后這兩個結果都用來作為LLM響應的基礎。4.3.2 CoVeChain of Verification (CoVe) 旨在通過系統地驗證和完善回答以盡量減少不準確性，從而提高大型語言模型所提供答案的可靠性，特別是在事實性問題和回答場景中。它背后的概念是基于這樣一種理念，即大型語言模型（LLM）生成的響應可以用來驗證自身。這種自我驗證過程可用于評估初始響應的準確性，并使其更加精確。在RAG系統中，針對用戶實際場景中日益復雜的問題，借鑒了 CoVe技術，將復雜 Prompt 拆分為多個且能并行檢索的搜索友好型query，讓LLM對每個子查詢進行定向知識庫搜索，最終提供更準確詳實答案的同時減少幻覺輸出。4.3.3 RAG-Fusion在這種方法中，原始query經過LLM 生成多個query。然后可以并行執行這些搜索查詢，并將檢索到的結果一并傳遞。當一個問題可能依賴于多個子問題時，這種方法就非常有用。RAG-Fusion便是這種方法的代表，它是一種搜索方法，旨在彌合傳統搜索范式與人類查詢的多面性之間的差距。這種方法先是采用LLM生成多重查詢，之后使用倒數排名融合（Reciprocal Rank Fusion，RRF）來重新排序。4.3.4 ReAct最近，在RAG系統中，使用ReAct思想，將復雜查詢分解成更簡單的”子查詢”，知識庫的不同部分可能會圍繞整個查詢回答不同的 “子查詢”。這對組合圖尤其有用。在組成圖中，一個查詢可以路由到多個子索引，每個子索引代表整個知識語料庫的一個子集。通過查詢分解，我們可以在任何給定的索引中將查詢轉化為更合適的問題。ReAct的模式如上圖所示，它是將思維鏈提示（Chain of Thoughts，簡寫為CoT）和Action計劃生成結合起來，相互補充增強，提升大模型解決問題的能力。其中CoT的Reasoning推理跟蹤有助于模型誘導、跟蹤和更新行動計劃以及處理異常。Action操作允許它與知識庫或環境等外部來源接口并收集其他信息。4.4 Query重構考慮Query理解模塊整體pipeline的效率，參考Query改寫和Query擴寫核心思想，自研了Query重構模塊，該模塊強調了通過一次請求，實現對原始用戶輸入的復雜問題進行改寫、拆解和拓展，挖掘用戶更深層次的子問題，從而借助子問題檢索效果更高的特點來解決復雜問題檢索質量偏差的問題，旨在提高查詢的準確性和效率。05檢索模型5.1 檢索模型的挑戰依賴于Embedding模型的向量化是否準確依賴于外部數據是否有合理的分割（不能所有的知識轉化成一個向量，而是需要分割數據后轉化再存入向量數據庫）依賴于Prompt拼接，當我們將返回的最相似的文檔進行排序后，與用戶的問題一起送給大模型，實際上是想讓大模型在長上下文中準確識別定位到合適的內容進行回答。《Lost in the Middle: How Language Models Use Long Contexts》文章指出，當相關信息出現在輸入上下文的開頭或結尾時，性能往往最高，而當模型必須在長上下文中間獲取相關信息時，性能會明顯下降，即使對于明確的長上下文模型也是如此。5.2 架構圖片來源于langchain。5.3 文檔加載器文檔加載器提供了一種 “加載 “方法，用于從配置源加載文檔數據。文檔數據是一段文本和相關元數據。文檔加載器可從多種不同來源加載文檔。例如，有一些文檔加載器可以加載簡單的 .txt 文件或者加載任何網頁的文本內容，甚至加載 YouTube 視頻的副本。此外，文檔加載器還可以選擇實現 “懶加載”，以便將數據懶加載到內存中。5.4 文本轉換器檢索的一個關鍵部分是只獲取文檔的相關部分。當加載文檔后，通常需要對其進行轉換，以便更好地適應應用程序。這涉及幾個轉換步驟，以便為檢索文檔做好準備。其中一個主要步驟是將大型文檔分割（或分塊）成較小的塊，即文本轉換器。最簡單的例子是，當需要處理長篇文本時，有必要將文本分割成若干塊，以便能放入模型的上下文窗口中。理想情況下，希望將語義相關的文本片段放在一起。這聽起來很簡單，但潛在的復雜性卻很大。5.4.1 工作原理將文本分割成語義上有意義的小塊（通常是句子）。開始將這些小塊組合成一個大塊，直到達到一定的大小（用某個函數來衡量）。一旦達到一定大小，就將該語塊作為自己的文本，然后開始創建有一定重疊的新語塊（以保持語塊之間的上下文）。5.4.2 常見如下文本轉換器類型5.4.3 評估文本轉換器你可以使用 Greg Kamradt 創建的 Chunkviz 工具來評估文本轉換器。Chunkviz 是可視化文本轉換器工作情況的工具。它可以向你展示文本的分割情況，并幫助你調整分割參數。5.5 文本嵌入模型檢索的另一個關鍵部分是文檔嵌入模型。文檔嵌入模型會創建一段文本的向量表示。它可以捕捉文本的語義，讓你快速有效地找到文本中相似的其他片段。這非常有用，因為它意味著我們可以在向量空間中思考文本，并進行語義搜索等操作。理想情況下，檢索器應該具備將不同語種的翻譯文本做關聯的能力（跨語種檢索能力），具備將長原文和短摘要進行關聯的能力，具備將不同表述但相同語義的文本做關聯的能力，具備將不同問題但相同意圖的問題進行關聯的能力，具備將問題和可能的答案文本進行關聯的能力。此外，為了給大模型盡可能高質量的知識片段，檢索器還應該給出盡可能多的相關片段，并且真正有用的片段應該在更靠前的位置，可以過濾掉低質量文本片段。最后，期望我們的模型可以覆蓋盡可能多的領域和場景，可以實現一個模型打通多個業務場景，讓用戶獲得開箱即用的模型，不需要再做微調。關于文檔嵌入模型，這里向大家推薦看一下《從MTEB看RAG：深入理解embedding評估，讓AI更懂你！》文章。5.6 向量數據庫隨著嵌入式的興起，人們開始需要向量數據庫來支持這些嵌入式的高效存儲和搜索。存儲和搜索非結構化數據的最常見方法之一是嵌入數據并存儲由此產生的嵌入向量，然后在查詢時嵌入非結構化查詢并檢索與嵌入查詢 “最相似 “的嵌入向量。向量數據庫負責存儲嵌入數據并執行向量搜索。關于向量數據庫，這里向大家推薦看一下《大模型引發爆發增長的向量數據庫》文章。如果對向量數據庫已經有認知了，可以直接跳過本節進行閱讀。5.7 索引經過前面的數據讀取和文本分塊操作后，接著就需要對處理好的數據進行索引。索引是一種數據結構，用于快速檢索出與用戶查詢相關的文本內容。它是檢索增強 LLM 的核心基礎組件之一。下面介紹幾種常見的索引結構。為了說明不同的索引結構，引入節點(Node)的概念。在這里，節點就是前面步驟中對文檔切分后生成的文本塊(Chunk)。下面的索引結構圖來自 LlamaIndex 的《 How Each Index Works》。5.7.1 摘要索引（以前稱為鏈式索引）摘要索引只是將節點存儲為順序鏈。在后續的檢索和生成階段，可以簡單地順序遍歷所有節點，也可以基于關鍵詞進行過濾。5.7.2 樹索引樹索引將一組節點 ( 文本塊 ) 構建成具有層級的樹狀索引結構，其從葉節點 (原始文本塊) 向上構建，每個父節點都是子節點的摘要。在檢索階段，既可以從根節點向下進行遍歷，也可以直接利用根節點的信息。樹索引提供了一種更高效地查詢長文本塊的方式，它還可以用于從文本的不同部分提取信息。與鏈式索引不同，樹索引無需按順序查詢。5.7.3 關鍵詞表索引關鍵詞表索引從每個節點中提取關鍵詞，構建了每個關鍵詞到相應節點的多對多映射，意味著每個關鍵詞可能指向多個節點，每個節點也可能包含多個關鍵詞。在檢索階段，可以基于用戶查詢中的關鍵詞對節點進行篩選。5.7.4 向量索引向量索引是當前最流行的一種索引方法。這種方法一般利用文本嵌入模型將文本塊映射成一個固定長度的向量，然后存儲在向量數據庫中。檢索的時候，對用戶查詢文本采用同樣的Embedding模型映射成向量，然后基于向量相似度計算獲取最相似的一個或者多個節點。5.8 排序和后處理經過前面的檢索過程可能會得到很多相關文檔，就需要進行篩選和排序。常用的篩選和排序策略包括：基于相似度分數進行過濾和排序基于關鍵詞進行過濾，比如限定包含或者不包含某些關鍵詞讓 LLM 基于返回的相關文檔及其相關性得分來重新排序基于時間進行過濾和排序，比如只篩選最新的相關文檔基于時間對相似度進行加權，然后進行排序和篩選06生成模型6.1 回復生成策略檢索模塊基于用戶查詢檢索出相關的文本塊，回復生成模塊讓 LLM 利用檢索出的相關信息來生成對原始查詢的回復。這里給出一些不同的回復生成策略。一種策略是依次結合每個檢索出的相關文本塊，每次不斷修正生成的回復。這樣的話，有多少個的相關文本塊，就會產生多少次的 LLM 調用。一種策略是在每次 LLM 調用時，盡可能多地在 Prompt 中填充文本塊。如果一個 Prompt 中填充不下，則采用類似的操作構建多個 Prompt，多個 Prompt 的調用可以采用和前一種相同的回復修正策略。6.2 prompt拼接策略用于將提示的不同部分組合在一起。您可以使用字符串提示或提示來執行此操作。以這種方式構建提示可以輕松地重用組件。6.2.1 字符串提示使用字符串提示時，每個模板都會連接在一起。您可以直接使用提示或字符串（列表中的第一個元素必須是提示）。例如，langchain提供的prompt template。6.2.2 提示提示由消息列表組成。純粹為了開發人員體驗，我們添加了一種便捷的方式來創建這些提示。在此管道中，每個新元素都是最終提示中的一條新消息。例如，langchain提供的AIMessage， HumanMessage， SystemMessage。07插件（Demonstration Retriever for In-Context Learning，基于演示檢索的上下文學習）上下文學習（In-Context learning）是一種新興的范式，它是指通過給定一些示范性的輸入-輸出對（示例），在不更新模型參數的情況下實現對給定測試輸入的預測。它獨特的無需更新參數能力使得上下文學習的方法可以通過一個語言模型的推理，來統一各種自然語言處理任務，這使其成為監督式微調的一個有前途的替代方案。雖然，這種方法在各種自然語言處理的任務中都表現不錯，但它的表現依賴給定的示范性輸入-輸出對。在模型的prompt中為每個任務都指定示范性示例會影響prompt的長度，這導致每次調用大語言模型的成本增加，甚至超出模型的輸入長度。因此，這帶來一個全新的研究方向——基于演示檢索的上下文學習。這類方法主要是通過文本（或語義）檢索與測試輸入在文本或語義上相似的候選示范性示例，將用戶的輸入與獲得相似的示范性示例加入到模型prompt中作為模型的輸入，則模型就可以給出正確的預測結果。然而，上述單一的檢索策略使得召回率不高，造成示范性示例無法精準召回，致使模型的效果不佳。為了解決上述問題，我們提出了一種基于混合演示檢索的上下文學習方法。該方法充分考慮不同檢索模型的優劣，提出一種融合算法，通過利用文本檢索（例如，BM25和TF-IDF）和語義檢索（例如，OpenAI embedding-ada和sentence-bert）進行多路召回，解決單路召回率不高的問題。然而，這帶來全新的挑戰，即如何將不同的召回結果進行融合。這是由于不同檢索算法分數范圍不匹配，例如，文本檢索分數通常在 0 和某個最大值之間（這具體取決于查詢的相關性）；而語義搜索（例如，余弦相似度）生成 0 到 1 之間的分數，這使得直接對召回結果進行排序變得很棘手。因此，我們又提出一種基于倒序排序融合算法（Reciprocal Rank fusion）的重排方法，該算法在不需要調整模型的情況下，利用位置來組合不同檢索算法的結果，同時，考慮到大模型對相關信息出現在輸入上下文的開頭或結尾時，性能往往最高，設計重排算法，從獲得高質量的融合結果。具體的模型架構如下圖所示，它包括檢索模塊、重排模塊和生成模塊。7.1 檢索模塊檢索模塊又分為文本檢索和語義檢索。語義檢索采用雙塔模型，用OpenAI的embedding-ada作為表征模型，分別對用戶的輸入和每個任務的候選示例進行表征，獲取語義向量，之后利用k-近鄰算法（K-Nearest Neighbor，KNN）計算語義相似度，并依據相似度對候選結果進行排序。其中，對于每個任務的候選示例我們采用離線表征，并將其存入向量數據庫中，這是因為一旦任務確認，每個任務的候選示例是固定不變的。而對于用戶的輸入，我們采用實時表征，提高計算效率，這是因為用戶的輸入是多樣的、不固定的。文本檢索，我們先是對每個任務的候選示例進行文本預處理，去除掉停用詞、特殊符號等。同時，在文本檢索中采用倒排索引的技術加速查詢，并利用BM25計算文本相似度，最后按相似度進行排序。7.2 重排模塊對于重排模塊，我們提出了一種基于倒序排序融合的重排算法。該方法先是為了解決不同召回算法的分數范圍不匹配的問題，我們引入倒序排序融合算法，對多路的召回結果進行融合排序。雖然倒序排序融合算法可以很好將多路召回進行融合排序，但是這種排序無法滿足大模型具有對相關信息出現在輸入上下文的開頭或結尾時性能最高的特性。這使得簡簡單單的利用倒序排序融合進行輸出，效果不好。因此，我們在此基礎之上對融合排序后的結果進行重排，排序策略是依據融合排序后的結果進行兩端填充排序。例如，原本的順序為[1，2，3，4，5]，進行重排后的順序為[1，3，5，4，2]。7.3 生成模塊生成模塊可以生成富有創意且連貫的文本，它旨在根據給定的Prompt或上下文生成新內容，這里我們設計了prompt組裝模塊，通過將系統prompt與檢索到相關信息進行組合。此外，還在組裝模塊中融入長期對話記錄和短期對話記錄進行prompt封裝。08引用或歸因（attribution）生成8.1 什么是引用或歸因在RAG 的知識問答場景下，隨著越來越多的文檔、網頁等信息被注入應用中，越來越多開發者意識到信息來源的重要性，它可以讓模型生成的內容能夠與參考信息的內容作出對齊，提供證據來源，確保信息準確性，使得大模型的回答更加真實。這里為了統一，在之后的文章中用“歸因”特指“引用或歸因”。8.2 歸因的作用用戶角度：能夠驗證模型的回答是否靠譜。模型角度：提高準確性并減少幻覺。8.3 如何實現歸因8.3.1 模型生成直接讓模型生成歸因信息。可在Prompt 添加類似“每個生成的證據都需在參考信息中進行引用”的話。這種方法最簡單，但也對模型的指令遵循能力要求較高，一般會采用GPT-4 回答，或者微調模型讓模型學習在生成時附帶引用的回答方式。缺點也很明顯，極度依賴模型的能力（甚至可能引用也是編的），且針對實際場景現的badcase 修復周期長，干預能力弱。8.3.2 動態計算在模型生成的過程中進行引用信息的附加。具體的操作為在流式生成的場景下，對生成的文本進行語義單元的判斷（比如句號，換行段落等），當出現一個完整的語義單元時，將該語義單元和參考信息中的每個參考源進行匹配（關鍵字，embedding等），通過卡閾值的辦法找到Top-N 的參考源，從而將參考源進行附加返回。這種方法的實現相比方法一簡單了很多，badcase 修復周期也短，但受限于匹配方式和閾值，且存在一個前提假設：模型的生成文本來源于參考信息。更多關于歸因研究的工作可以參考：A Survey of Large Language Models Attribution 或 LLM+RAG 中關于回答片段歸因的討論9. 評估做開發的同學不管用沒用過，對 TDD(Test-Driven Development)的大名總歸是聽過的，類似的，開發大模型應用的時候也應該有個對應的 MDD(Metrics-Driven Development) 的概念，最舒服的姿勢肯定是預先定義好業務的場景、用到的數據、設定的指標以及需要達到的分值，然后按部就班的實現既定目標，員工士氣高老板也開心！但理想和現實之間總是如此糾纏，對大部分的大模型開發任務來講，更常見的情況是場景定義不清楚，數據光清洗就累死三軍，至于需要的指標和目標？想都沒想過！這一次，我們來補上本應該在最最開始的就考慮的，大模型應用如何量化業務指標，具體的，如何量化的證明，你的 RAG 就是比隔壁老王他們組的牛？到底該拿哪些量化的指標去說服同行？影響RAG系統性能的幾個方面：位置偏見：LLMs 有可能對文本中特定位置的內容給予更高的關注，比如位于段落開頭和結尾的內容更容易被采納。檢索內容相關性：由于query的表達多樣性，使得RAG系統可能檢索到不相關的內容，這種不相關的內容為LLMs理解帶來噪音，增加模型的負擔。9.1 評測指標Faithfulness是指用于評測生成的回答是否忠實于contexts，這對于避免幻覺并確保檢索到的上下文可以作為生成答案的理由非常重要。Answer Relevance是指的生成的答案應解決所提供的實際問題。Context Relevance是指檢索的上下文應重點突出，盡可能少地包含無關信息。理想情況下，檢索到的上下文應該只包含處理所提供查詢的基本信息。包含的冗余信息越少，context_relevancy越高。9.2 評測方法9.2.1 RGB（Benchmarking Large Language Models in Retrieval-Augmented Generation）這一工作系統地研究了檢索增強生成對大型語言模型的影響。它分析了不同大型語言模型在RAG所需的4項基本能力方面的表現，包括噪聲魯棒性、拒答、信息整合和反事實魯棒性，并建立了檢索增強生成基準。此外，現在做RAG都是做的pipeline，涉及到切塊、相關性召回、拒答等多個環節，每個環節都可以單獨做評測，文中提到的4個能力其實可以影射到每個環節當中。9.2.2 RAGAS（RAGAS: Automated Evaluation of Retrieval Augmented Generation）該工作提出了一種對檢索增強生成（RAG）pipeline進行無參考評估的框架。該框架考慮檢索系統識別相關和重點上下文段落的能力， LLM以忠實方式利用這些段落的能力，以及生成本身的質量。目前，該方法已經開源，具體可以參見github：https://github.com/explodinggradients/ragas9.2.3 Llamalindex-EvaluatingLlamaIndex提供了衡量生成結果質量的關鍵模塊。同時，還提供關鍵模塊來衡量檢索質量。10總結LLM這一波，催生的技術真的很多，每一個環節，要真正做好，符合企業應用，都可以讓我們研究好長一段時間，并需要不斷去實踐，才能打磨出精品。本文總結了過去一年在RAG實踐的關鍵模塊，希望本文總結對大家有一定的幫助。此外，本文還屬于大模型應用——RAG的一個大綱式的技術普及文章，這里面的很多技術細節，需要進一步研究，并需要不斷去實踐，才能打磨出精品。END點擊下方名片即刻關注我們