ChatGPT、Midjourney等生成式人工智能（GenAI）在文本生成、文本到圖像生成等任務中表現出令人印象深刻的性能。然而，生成模型也不能避免其固有的局限性，包括產生幻覺的傾向，在數學能力弱，而且缺乏可解釋性。因此，提高他們能力的一個可行辦法是讓他們能夠與外部世界互動，以不同的形式和方式獲取知識，從而提高所生成內容的事實性和合理性。

檢索增強生成（Retrieval-Augmented Generation, RAG）技術研究旨在提供更有依據、更依賴事實的信息來幫助解決生成式AI的幻覺傾向、專業力弱等固有缺陷。

現在已有大多數教程都挑選一種或幾種RAG技術并詳細解釋如何實現它們，而缺少一個對于RAG技術的系統化概述。本文的目的是想系統化梳理關鍵的高級RAG技術，并介紹它們的實現，以便于其他開發人員深入研究該技術。

1 -檢索增強生成(RAG)技術簡介

檢索增強生成（又名RAG）為大語言模型提供從某些數據源檢索到的信息，作為其生成答案的依據。RAG通常包括兩個階段：檢索上下文相關信息和使用檢索到的知識指導生成過程。基本上，RAG是通過檢索算法找到的信息作為上下文，幫助大模型回答用戶問詢。查詢和檢索到的上下文都被注入到發送給LLM的提示中。

RAG是2023年最流行的基于LLM的系統架構。有許多產品幾乎完全基于RAG構建-從將網絡搜索引擎與LLM相結合的問答服務到數百個與數據交互的應用程序。

矢量搜索領域也受到了RAG火熱的推動而進一步提升了重要度。像chroma, weavaite.io, pinecone這樣的矢量數據庫初創公司都是建立在現有的開源搜索索引（主要是faiss和nmslib）的基礎上的最近為輸入文本添加了額外的存儲空間以及一些其他工具。

基于大模型的的應用程序有多個最著名的開源庫，包括LangChain，LlamaIndex，AutoGen, PromptAppGPT等。對于LLM應用開發可以參考如下文章進一步了解：

2023年人工智能體(AI Agent)開發與應用全面調研：概念、原理、開發、應用、挑戰、展望

PromptAppGPT低代碼大語言模型應用開發實戰：聊天機器人、智能文生圖、圖文搜索

2 - 基礎檢索增強生成(RAG)技術

基礎RAG流程圖。圖源：旺知識

基礎RAG流程簡單來說如下：將文本分割成塊，然后使用編碼模型將這些塊嵌入到向量中，將所有這些向量放入索引中，最后為LLM創建一個提示，告訴模型根據我們在搜索步驟中找到的上下文來回答用戶的查詢。

在運行時，我們使用相同的編碼器模型對用戶的查詢進行矢量化，然后針對索引執行該查詢向量的搜索，找到前k個結果，從數據庫中檢索相應的文本塊，并將它們作為上下文輸入到LLM提示中。

下面是一個示例提示信息：

def question_answering(context, query):
    prompt = f"""
                Give the answer to the user query delimited by triple backticks ```{query}```
                using the information given in context delimited by triple backticks ```{context}```.
                If there is no relevant information in the provided context, try to answer yourself, 
                but tell user that you did not have any relevant context to base your answer on.
                Be concise and output the answer of size less than 80 tokens.
                """




    response = get_completion(instruction, prompt, model="gpt-3.5-turbo")
    answer = response.choices[0].message["content"]
    return answer

提示工程是可以嘗試改進RAG系統的最便捷便宜的方法。可以參考如下文章了解更多提示工程技巧：

從1000+模板中總結出的10大提示工程方法助你成為提示詞大師！

ChatGPT提示工程師必備基礎知識與進階技巧！

顯然，盡管OpenAI是LLM提供商的市場領導者，但仍有許多替代方案，例如Anthropic的Claude、最近流行的較小但功能強大的模型，例如Mixtral形式的Mistral、Microsoft的Phi-2以及許多開源選項，例如Llama2、OpenLLaMA、Falcon。

3 - 高級檢索增強生成(RAG)技術

現在我們將深入了解高級RAG技術的核心步驟和所涉及算法。為了保持方案的可讀性，我們省略了一些邏輯循環和復雜的多步驟代理行為。

高級RAG的些關鍵流程圖。圖源：旺知識

方案圖中的綠色元素是進一步討論的核心RAG技術，藍色元素是文本。并非所有先進的RAG技術都可以在單個方案中輕松可視化，例如，省略了各種上下文放大方法，不過，我們將在文中深入探討這些技術。

3.1 - 分塊和矢量化

首先，我們要創建一個向量索引，表示我們的文檔內容，然后在運行時搜索所有這些向量與對應于最接近語義的查詢向量之間的最小余弦距離。

3.1.1 - 分塊

Transformer模型具有固定的輸入序列長度，即使輸入上下文窗口很大，一個或幾個句子的向量也比幾頁文本的平均向量更好地表示其語義，因此需要對數據進行分塊。分塊將初始文檔分割成一定大小的塊，盡量不要失去語義含義，將文本分割成句子或段落，而不是將單個句子分成兩部分。有多種文本分割器實現能夠完成此任務。

塊的大小是一個需要考慮的重要參數-它取決于您使用的嵌入模型及其令牌容量，標準轉換器編碼器模型（例如基于BERT的句子轉換器）最多需要512個令牌。OpenAI ada-002能夠處理更長的序列，如8191個標記，但這里就需要權衡是留有足夠的上下文供大語言模型進行推理，還是留足夠具體的文本表征以便有效地執行檢索。

例如，在語義搜索中，我們對文檔語料庫進行索引，每個文檔都包含有關特定主題的有價值的信息。通過應用有效的分塊策略，我們可以確保我們的搜索結果準確地捕捉用戶查詢的本質。如果我們的塊太小或太大，可能會導致搜索結果不精確或錯過顯示相關內容的機會。根據經驗，如果文本塊在沒有周圍上下文的情況下對人類有意義，那么它對語言模型也有意義。因此，找到語料庫中文檔的最佳塊大小對于確保搜索結果的準確性和相關性至關重要。

另一個例子是會話Agent。我們使用嵌入的塊根據知識庫為會話Agent構建上下文，該知識庫使Agent基于可信信息。在這種情況下，對我們的分塊策略做出正確的選擇很重要，原因有兩個：首先，它將確定上下文是否確實與我們的提示相關。其次，考慮到我們可以為每個請求發送的令牌數量的限制，它將確定我們是否能夠在將檢索到的文本發送到外部模型提供商（例如 OpenAI）之前將其放入上下文中。在某些情況下，例如在 32k 上下文窗口中使用 GPT-4 時，擬合塊可能不是問題。盡管如此，我們需要注意何時使用非常大的塊，因為這可能會對檢索結果的相關性產生不利影響。

a.分塊因素

有幾個因素在確定最佳分塊策略方面發揮著作用，這些變量根據用例而變化，以下是需要關注的一些關鍵方面：

被索引的內容的性質是什么？您是否正在處理長文檔（例如文章或書籍）或較短的內容（例如推文或即時消息）？答案將決定哪種模型更適合您的目標，以及應用哪種分塊策略。

您使用哪種嵌入模型，它在什么塊大小上表現最佳？例如，句子轉換器模型在單個句子上效果很好，但像text-embedding-ada-002這樣的模型在包含256或512個標記的塊上表現更好。

您對用戶查詢的長度和復雜性有何期望？它們會簡短而具體，還是長而復雜？這也可能會告訴您選擇對內容進行分塊的方式，以便嵌入式查詢和嵌入式塊之間有更緊密的相關性。

檢索到的結果將如何在您的特定應用程序中使用？例如，它們會用于語義搜索、問答、摘要或其他目的嗎？例如，如果您的結果需要輸入到具有令牌限制的另一個LLM中，您必須考慮到這一點，并根據您想要適應請求的塊數量來限制塊的大小。

回答這些問題將使您能夠開發一種平衡性能和準確性的分塊策略，這反過來又將確保查詢結果更相關。

b -分塊方法

分塊的方法有多種，每種方法可能適合不同的情況。通過檢查每種方法的優點和缺點，我們的目標是確定應用它們的正確場景。

b.1 - 固定大小分塊

這是最常見、最直接的分塊方法：我們只需決定塊中的標記數量，以及可選地確定它們之間是否應該有重疊。一般來說，我們希望在塊之間保留一些重疊，以確保語義上下文不會在塊之間丟失。在大多數常見情況下，固定大小的分塊將是最佳路徑。與其他形式的分塊相比，固定大小的分塊計算成本低且易于使用，因為它不需要使用任何NLP庫。

下面是使用LangChain執行固定大小分塊的示例：

text = "..." # your text
from langchain.text_splitter import CharacterTextSplitter
text_splitter = CharacterTextSplitter(
    separator = "

",
    chunk_size = 256,
    chunk_overlap  = 20
)
docs = text_splitter.create_documents([text])

b.2 - 內容感知分塊

這種方法利用我們正在分塊的內容的性質并對其應用更復雜的分塊的一組方法。這里有些例子：

句子分塊：正如我們之前提到的，許多模型都針對嵌入句子級內容進行了優化。當然，我們會使用句子分塊，并且有多種方法和工具可用于執行此操作，包括：

直接分割：最直接的方法是按句點（“.”）和換行符分割句子。雖然這可能快速且簡單，但這種方法不會考慮所有可能的邊緣情況。這是一個非常簡單的例子：

text = "..." # your text
docs = text.split(".")

NLTK：自然語言工具包(NLTK)是一個流行的Python庫，用于處理人類語言數據。它提供了一個句子標記器，可以將文本分割成句子，幫助創建更有意義的塊。例如，要將NLTK與LangChain結合使用，可以執行以下操作：

text = "..." # your text
from langchain.text_splitter import NLTKTextSplitter
text_splitter = NLTKTextSplitter()
docs=text_splitter.split_text(text)

spaCy：spaCy是另一個用于NLP任務的強大Python庫。它提供了復雜的句子分割功能，可以有效地將文本分割成單獨的句子，從而在生成的塊中更好地保留上下文。例如，要將spaCy與LangChain結合使用，可以執行以下操作：

text = "..." # your text
from langchain.text_splitter import SpacyTextSplitter
text_splitter = SpaCyTextSplitter()
docs = text_splitter.split_text(text)

遞歸分塊：遞歸分塊使用一組分隔符以分層和迭代的方式將輸入文本劃分為更小的塊。如果分割文本的初始嘗試沒有生成所需大小或結構的塊，則該方法會使用不同的分隔符或標準在生成的塊上遞歸調用自身，直到達到所需的塊大小或結構。這意味著雖然塊的大小不會完全相同，但它們仍然“渴望”具有相似的大小。

以下是如何在LangChain中使用遞歸分塊的示例：

text = "..." # your text
from langchain.text_splitter import RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(
    # Set a really small chunk size, just to show.
    chunk_size = 256,
    chunk_overlap  = 20
)




docs = text_splitter.create_documents([text])

專門分塊：Markdown和LaTeX是可能遇到的結構化和格式化內容的兩個示例。在這些情況下，可以使用專門的分塊方法在分塊過程中保留內容的原始結構。

Markdown：Markdown是一種輕量級標記語言，通常用于格式化文本。通過識別Markdown語法（例如標題、列表和代碼塊），您可以根據內容的結構和層次結構智能地劃分內容，從而產生語義上更連貫的塊。例如：

from langchain.text_splitter import MarkdownTextSplitter
markdown_text = "..."




markdown_splitter = MarkdownTextSplitter(chunk_size=100, chunk_overlap=0)
docs = markdown_splitter.create_documents([markdown_text])

LaTex：LaTeX是一種文檔準備系統和標記語言，常用于學術論文和技術文檔。通過解析LaTeX命令和環境，可以創建尊重內容邏輯組織的塊（例如，部分、小節和方程），從而獲得更準確且與上下文相關的結果。例如：

from langchain.text_splitter import LatexTextSplitter
latex_text = "..."
latex_splitter = LatexTextSplitter(chunk_size=100, chunk_overlap=0)
docs = latex_splitter.create_documents([latex_text])

c -分塊優化

如果常見的分塊方法（例如固定分塊）無法輕松應用于用例，那么這里有一些提示可以幫助您找到最佳的分塊大小。

預處理數據：在確定應用程序的最佳塊大小之前，您需要首先預處理數據以確保質量。例如，如果您的數據是從網絡檢索的，您可能需要刪除HTML標簽或只會增加噪音的特定元素。

選擇塊大小范圍：數據經過預處理后，下一步是選擇要測試的潛在塊大小范圍。如前所述，選擇應考慮內容的性質（例如，短消息或冗長的文檔）、您將使用的嵌入模型及其功能（例如，令牌限制）。目標是在保留上下文和保持準確性之間找到平衡。首先探索各種塊大小，包括用于捕獲更精細語義信息的較小塊（例如，128或256個標記）和用于保留更多上下文的較大塊（例如，512或1024個標記）。

評估每個塊大小的性能：為了測試各種塊大小，您可以使用多個索引或具有多個命名空間的單個索引。使用代表性數據集，為要測試的塊大小創建嵌入并將它們保存在索引中。然后，您可以運行一系列查詢，可以評估其質量，并比較不同塊大小的性能。這很可能是一個迭代過程，您可以針對不同的查詢測試不同的塊大小，直到可以確定內容和預期查詢的最佳性能塊大小。

在大多數情況下，對內容進行分塊非常簡單-但當您開始偏離常規時，它可能會帶來一些挑戰。沒有一種萬能的分塊解決方案，因此適用于一種用例的方法可能不適用于另一種用例。希望這篇文章能夠幫助您更好地了解如何為應用程序進行分塊。

3.1.2 矢量化

下一步是選擇一個模型來嵌入我們的塊，有很多選項，我選擇針對搜索優化過的模型，如bge-large或E5嵌入系列。這里可以參考MTEB排行榜以獲取最新模型效果：

https://huggingface.co/spaces/mteb/leaderboard

對于分塊和矢量化步驟的端到端實現，可以參考查看LlamaIndex中完整數據攝取管道的示例：

https://docs.llamaindex.ai/en/latest/module_guides/loading/ingestion_pipeline/root.html

3.2 -搜索索引

3.2.1 - 向量存儲索引

基本索引檢索流程圖。圖源：旺知識

RAG流程的關鍵部分是搜索索引，她用于存儲在上一步中獲得的矢量化內容。最簡單的實現使用平面索引—遍歷查詢向量和所有塊向量之間的距離。Faiss、nmslib、annoy等使用一些近似最近鄰實現（如聚類、樹或HNSW算法）來提升檢索效率，實現在10000多個元素尺度上進行有效索引和檢索。

同時還有OpenSearch或ElasticSearch等托管解決方案以及矢量數據庫，例如Pinecone、Weaviate或Chroma，負責在后臺處理數據攝取管道。

根據索引選擇、數據和搜索需求，還可以將元數據與向量一起存儲，然后使用元數據過濾器來搜索某些日期或來源內的信息。

LlamaIndex支持大量向量存儲索引，但也支持其他更簡單的索引實現，例如列表索引、樹索引和關鍵字表索引。

3.2.2 - 層次索引

層次索引流程圖。圖源：旺知識

如果有許多文檔需要檢索，就需要能夠有效地在其中進行檢索，找到相關信息并將其綜合到一個答案中并給出參考來源。在大型數據庫的情況下，一種有效的方法是創建兩個索引—一個由摘要組成，另一個由文檔塊組成，并分兩步檢索，首先通過摘要過濾掉相關文檔，然后只在這個相關組內檢索。

3.2.3 - 假設問題和HyDE

另一種方法是要求LLM為每個塊生成一個問題并將這些問題嵌入向量中，在運行時針對該問題向量索引執行查詢檢索（用索引中的問題向量替換塊向量），然后在檢索后路由到原始數據文本塊并將它們作為上下文發送給LLM以獲得答案。

與實際塊相比，查詢和假設問題之間的語義相似性更高，因此這種方法提高了搜索質量。

還有一種稱為HyDE的反向邏輯方法-要求LLM根據給定的查詢生成假設的響應，然后使用其向量和查詢向量來提高檢索質量。

3.2.4 - 上下文豐富

這里的概念是檢索較小的塊以獲得更好的搜索質量，但添加周圍的上下文供LLM進行推理。有兩種選擇：通過圍繞較小檢索塊的句子來擴展上下文，或者將文檔遞歸地拆分為多個包含較小子塊的較大父塊。

a -句子窗口檢索

在該方案中，文檔中的每個句子都是單獨嵌入的，這為上下文余弦距離搜索的查詢提供了很高的準確性。為了在獲取最相關的單個句子后更好地對找到的上下文進行推理，我們將上下文窗口在檢索到的句子之前和之后擴展了k個句子，然后將此擴展的上下文發送給LLM。

句子窗口檢索。圖源：旺知識

綠色部分是在索引中搜索時找到的句子嵌入，整個黑色+綠色段落被饋送到LLM以擴大其上下文，同時根據所提供的查詢進行推理。

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

這里的想法與句子窗口檢索器非常相似—搜索更細粒度的信息，然后擴展上下文窗口，然后將所述上下文提供給LLM進行推理。文檔被分割成較小的子塊，引用較大的父塊。

父子塊檢索。圖源：旺知識

文檔被分成塊的層次結構，然后最小的葉塊被發送到索引。在檢索時，我們檢索k個葉子塊，如果有n個塊引用同一父塊，我們用該父塊替換它們并將其發送到LLM進行答案生成。

首先在檢索期間獲取較小的塊，然后如果前k個檢索到的塊中超過n個塊鏈接到同一父節點（較大的塊），我們將通過該父節點替換饋送到LLM的上下文-工作原理類似于自動合并一些檢索到的塊塊合并成一個更大的父塊，因此得名方法。請注意-搜索僅在子節點索引內執行。

3.2.5 - 融合檢索或混合搜索

一個自然的想法是，可以充分利用兩個世界的優點—基于關鍵字的老式搜索—稀疏檢索算法（如tf-idf或搜索行業標準BM25）和現代語義或向量搜索，并將其組合到一個檢索結果中。

這里唯一的技巧是將檢索到的結果與不同的相似度分數正確地結合起來—這個問題通常是借助Reciprocal Rank Fusion (RRF)算法來解決的，對檢索到的結果進行重新排序以獲得最終輸出。

融合檢索。圖源：旺知識

在LangChain中，這是在Ensemble Retriever類中實現的，結合了定義的檢索器列表，例如Faiss矢量索引和基于BM25的檢索器，并使用RRF算法進行重新排名。在LlamaIndex中，也是以非常相似的方式完成的。

混合或融合搜索通常會提供更好的檢索結果，因為結合了兩種互補的搜索算法，同時考慮了查詢與存儲文檔之間的語義相似性和關鍵字匹配。

3.3 - 重新排序和過濾

使用上述任何算法都得到了檢索結果，現在需要通過過濾、重新排序或某種轉換來優化它們。在LlamaIndex中，有多種可用的后處理器，可以根據相似度得分、關鍵詞、元數據過濾結果，或者使用LLM等其他模型對結果進行重新排名，句子轉換器交叉編碼器，Cohere重排序端點或者基于日期新近度等元數據。

現在是時候學習更復雜的RAG技術了，比如查詢轉換和路由，它們都涉及LLM，從而代表Agent行為，涉及復雜的邏輯，涉及RAG管道中的LLM推理。

3.4 - 查詢轉換

查詢轉換是一系列使用LLM作為推理引擎來修改用戶輸入以提高檢索質量的技術。有不同的選擇可以做到這一點。

查詢轉換原理圖解。圖源：旺知識

如果查詢很復雜，可以將其分解為多個子查詢。例如，如果你問：

“LangChain或LlamaIndex哪個框架在Githu上擁有更多星星？”

并且我們不太可能在語料庫中的某些文本中找到直接比較，因此在兩個子查詢中分解這個問題是有意義的，假設更簡單和更具體的信息檢索：

“LangChain在Github上有多少顆星？”

“LlamaIndex在Github上有多少顆星？”

它們將并行執行，然后將檢索到的上下文合并到一個提示中，供LLM合成初始查詢的最終答案。這兩個庫都實現了此功能-作為LangChain中的多查詢檢索器和LlamaIndex中的子問題查詢引擎。

后退提示(Step-back prompting)：使用LLM生成更通用的查詢，并檢索我們獲得更通用或高級上下文的內容，這些上下文有助于為原始查詢提供答案。還執行原始查詢的檢索，并且在最終答案生成步驟中將兩個上下文饋送到 LLM。

查詢重寫：使用LLM重新制定初始查詢以改進檢索。LangChain和LlamaIndex都有實現，只是有點不同，我發現LlamaIndex解決方案在這里更強大。

參考文獻引用

這個沒有數字，因為它更像是一種工具，而不是檢索改進技術，盡管這是一個非常重要的技術。如果我們使用多個源來生成答案，要么是由于初始查詢的復雜性（我們必須執行多個子查詢，然后將檢索到的上下文合并到一個答案中），要么是因為我們在各種文檔中找到了單個查詢的相關上下文，問題是我們是否能夠準確地回溯我們的來源。有幾種方法可以做到這一點：

將此引用任務插入到我們的提示中，并要求LLM提及所用來源的ID。

將生成的響應部分與索引中的原始文本塊進行匹配-LlamaIndex針對這種情況提供了一種基于模糊匹配的高效解決方案。如果您還沒有聽說過模糊匹配，這是一種非常強大的字符串匹配技術。

3.5 - 聊天引擎

構建一個可以針對單個查詢多次工作的優秀RAG系統的下一個重要事項是聊天邏輯，考慮到對話上下文，與LLM時代之前的經典聊天機器人相同。

這需要支持與先前對話上下文相關的后續問題、照應或任意用戶命令。它將聊天上下文與用戶查詢一起考慮在內，通過查詢壓縮技術來解決。

有幾種方法可以實現上下文壓縮：

一個流行且相對簡單的ContextChatEngine，首先檢索與用戶查詢相關的上下文，然后將其與內存緩沖區中的聊天歷史記錄一起發送給LLM，以便LLM在生成下一個答案時了解先前的上下文。

更復雜的情況是CondensePlusContextMode—在每次交互中，聊天歷史記錄和最后一條消息都會壓縮為一個新查詢，然后該查詢轉到索引，檢索到的上下文與原始用戶消息一起傳遞給LLM，以生成一個回答。

不同聊天引擎類型和原理。圖源：旺知識

還有其他聊天引擎類型，例如ReActAgent，但讓我們在第3.7節中說明。

3.6 - 查詢路由

查詢路由是LLM支持的決策步驟，根據給定的用戶查詢下一步該做什么，選項通常是總結、針對某些數據索引執行搜索或嘗試多種不同的路由，然后將其輸出綜合到單一答案。

查詢路由器還用于選擇索引或更廣泛的數據存儲，將用戶查詢發送到何處-要么您有多個數據源，例如經典向量存儲和圖形數據庫或關系數據庫，要么您有索引的層次結構-對于多文檔存儲，一個非常經典的情況是摘要索引和文檔塊向量的另一個索引。

路由選項的選擇是通過LLM調用執行的，以預定義的格式返回其結果，用于將查詢路由到給定的索引，或者，如果我們采用父系行為，則路由到子鏈甚至其他Agent如節的多文檔代理方案所示。LlamaIndex和LangChain都支持查詢路由器。

3.7 - RAG中的Agent

Agent幾乎自第一個LLM API發布以來就已經存在了，其想法是提供一個能夠推理的LLM，并提供一組工具和一個要完成的任務。這些工具可能包括一些確定性函數，例如任何代碼函數或外部API甚至其他Agent，這種LLM鏈思想就是LangChain名稱的由來。

這里我們將繼續基于Agent的多文檔檢索案例描述的RAG系統的底層工作。Open AI Assistants基本上已經實現了我們之前在開源中擁有的LLM所需的許多工具：聊天記錄、知識存儲、文檔上傳接口，以及也許最重要的函數調用API。

在LlamaIndex中，有一個OpenAIAgent類將這種高級邏輯與ChatEngine和QueryEngine類結合起來，提供基于知識和上下文感知的聊天，以及在一個對話輪中調用多個OpenAI函數的能力，這真正帶來了智能Agent行為。

讓我們看一下多文檔Agent方案，它涉及在每個文檔上初始化代理（OpenAIAgent），能夠進行文檔摘要和經典的QA機制，以及一個頂級Agent，負責將查詢路由到文檔代理并用于最終答案合成。

每個文檔Agent都有兩個工具-向量存儲索引和摘要索引，并根據路由查詢決定使用哪一個。而對于頂層Agent來說，所有的文件Agent都尊稱是工具。

該方案展示了一種先進的RAG架構，其中包含每個相關Agent做出的大量路由決策。這種方法的好處是能夠比較不同文檔中描述的不同解決方案或實體及其摘要以及經典的單文檔摘要和QA機制-這基本上涵蓋了最常見的與文檔集合聊天的用例。

多文檔Agent的方案，涉及查詢路由和代理行為模式。圖源：旺知識

這種復雜方案的缺點可以從圖片中猜到，由于我們Agent內部使用LLM進行了多次來回迭代，它有點慢。以防萬一，LLM調用始終是RAG管道中最長的操作，搜索在設計上針對速度進行了優化。因此，對于大型多文檔存儲，我們建議對該方案進行一些簡化，使其具有可擴展性。

3.8 - 響應合成器

這是任何RAG管道的最后一步-根據我們仔細檢索的所有上下文和初始用戶查詢生成答案。最簡單的方法是將所有獲取的上下文（高于某個相關閾值）與查詢一起連接并立即提供給LLM。

但是，與往常一樣，還有其他更復雜的選項，涉及多個LLM調用，以細化檢索到的上下文并生成更好的答案。

響應合成的主要方法包括：

1.通過將檢索到的上下文逐塊發送到LLM來迭代地細化答案

2.總結檢索到的上下文以適應提示

3.根據不同的上下文塊生成多個答案，然后將它們連接或總結。

更多詳細信息，可以參考響應合成器模塊文檔：

https://docs.llamaindex.ai/en/stable/module_guides/querying/response_synthesizers/root.html

4 - RAG系統模型微調

RAG系統涉及多個模型，可以考慮對它們進行微調：

編碼器模型(Transformer)：負責內容向量編碼，從而負責上下文檢索質量

大語言模型(LLM)：負責最好地使用所提供的上下文來回答用戶查詢

排序器(Ranker)：負責對檢索結果排序優選

如今的一大優勢是可以使用GPT-4等高端LLM來生成高質量的合成數據集。但應該始終意識到，采用由專業研究團隊在仔細收集、清理和驗證的大型數據集上訓練的開源模型，并使用小型合成數據集進行快速調整可能會縮小模型的總體能力。

4.1 - 編碼器微調

我們在LlamaIndex設置中測試了通過微調bge-large-en-v1.5（撰寫本文時MTEB排行榜前4名）帶來的性能提升，結果顯示檢索質量提高了2%。沒什么戲劇性的，但很高興有這個選項，特別是如果你有構建RAG的領域數據集。

4.2 - 排序器微調

另一個好的選項是如果您不完全信任基本編碼器，則可以對檢索到的結果進行重新排名。

它的工作方式如下：將查詢和檢索到的前k個文本塊傳遞給交叉編碼器，并用SEP令牌分隔，并將其微調為輸出1表示相關塊，輸出0表示不相關。

結果表明，通過交叉編碼器微調，成對分數(pairwise)提高了4%，這里可以找到這種調整過程的一個很好的例子：

https://docs.llamaindex.ai/en/latest/examples/finetuning/cross_encoder_finetuning/cross_encoder_finetuning.html

4.3 - LLM微調

最近OpenAI開始提供LLM微調API，LlamaIndex有一個關于在RAG設置中微調GPT-3.5-turbo的教程，以“提煉”一些GPT-4知識。這里的想法是拿一份文檔，用GPT-3.5-turbo生成一些問題，然后使用GPT-4根據文檔內容生成這些問題的答案（構建一個由GPT4驅動的RAG管道），然后進行細化-在該問答對數據集上調整GPT-3.5-turbo。用于RAG管道評估的ragas框架顯示忠實度指標增加了5%，這意味著經過微調的GPT3.5-turbo模型比原始模型更好地利用提供的上下文來生成答案。

最近的論文RA-DIT：MetaAIResearch的檢索增強雙指令調整中演示了一種更復雜的方法，提出了一種同時調整LLM和Retriever的技術，優化關于查詢、上下文和答案的三元組。具體實現方式請參考本指南:

https://docs.llamaindex.ai/en/stable/examples/finetuning/knowledge/finetune_retrieval_aug.html#fine-tuning-with-retrieval-augmentation

該技術用于通過微調API和Llama2開源模型（在原始論文中）對OpenAI LLM進行微調，從而使知識密集型任務指標增加約5%（與帶有RAG的Llama265B相比）常識推理任務也增加了幾個百分點。

5 - RAG系統評估

RAG系統性能評估有多個框架，它們共享一些獨立指標的想法，例如總體答案相關性、答案基礎性、忠實性和檢索到的上下文相關性。上一節提到的Ragas使用忠實度和答案相關性作為生成的答案質量指標，并使用經典的上下文精確度和召回率作為RAG方案的檢索部分。

在AndrewNG、LlamaIndex和評估框架Truelens最近發布的優秀短期課程《構建和評估高級RAG》中，他們提出了RAG三元組——檢索到的與查詢的上下文相關性、接地性（LLM答案在多大程度上受所提供的上下文支持）并回答與查詢相關的問題。

關鍵和最可控的指標是檢索到的上下文相關性。上述高級RAG技術的第3.1-3.7部分加上編碼器和Ranker微調部分旨在改進該指標，而第3.8部分和LLM微調則注重回答相關性(relevance)和事實性(groundedness)。

可以在此處找到一個非常簡單的檢索器評估管道的好示例，并將其應用于編碼器微調部分：https://github.com/run-llama/finetune-embedding/blob/main/evaluate.ipynb

OpenAI演示了一種更先進的方法，不僅考慮命中率，還考慮平均倒數排名（一種常見的搜索引擎指標）以及生成的答案指標（例如忠實度和相關性）。

LangChain有一個非常先進的評估框架LangSmith，可以在其中實現自定義評估器，并且它監視RAG管道內運行的跟蹤，以使您的系統更加透明。

如果您使用LlamaIndex進行構建，可以使用rag_evaluator llama包，它提供了一個使用公共數據集評估管道的快速工具。

6 -總結展望

我們試圖系統化梳理RAG的核心方法，并舉例說明其中的一些方法，希望這可能會激發一些新穎的思路，以便在RAG系統中進行探索。

還有很多其他事情需要考慮，比如基于網絡搜索的RAG(由LlamaIndex、webLangChain等提供的RAG)、深入研究代理架構以及關于LLM長期記憶的一些想法。

除了答案相關性(relevance)和忠實性(faithfulness)之外，RAG系統的主要生產挑戰是速度，特別基于更靈活的Agent方案的RAG系統。ChatGPT和大多數其他助手使用的這種流媒體回復僅僅是一種縮短感知答案生成時間的方法。這就是為什么我們看到較小的LLM也有一個非常光明的未來，最近發布的Mixtral和Phi-2正在引領我們朝這個方向發展。

審核編輯：劉清