高級(jí)檢索增強(qiáng)生成技術(shù)(RAG)全面指南

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

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

現(xiàn)在已有大多數(shù)教程都挑選一種或幾種RAG技術(shù)并詳細(xì)解釋如何實(shí)現(xiàn)它們，而缺少一個(gè)對(duì)于RAG技術(shù)的系統(tǒng)化概述。本文的目的是想系統(tǒng)化梳理關(guān)鍵的高級(jí)RAG技術(shù)，并介紹它們的實(shí)現(xiàn)，以便于其他開發(fā)人員深入研究該技術(shù)。

1 -檢索增強(qiáng)生成(RAG)技術(shù)簡(jiǎn)介

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

RAG是2023年最流行的基于LLM的系統(tǒng)架構(gòu)。有許多產(chǎn)品幾乎完全基于RAG構(gòu)建-從將網(wǎng)絡(luò)搜索引擎與LLM相結(jié)合的問答服務(wù)到數(shù)百個(gè)與數(shù)據(jù)交互的應(yīng)用程序。

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

基于大模型的的應(yīng)用程序有多個(gè)最著名的開源庫(kù)，包括LangChain，LlamaIndex，AutoGen, PromptAppGPT等。對(duì)于LLM應(yīng)用開發(fā)可以參考如下文章進(jìn)一步了解：

2023年人工智能體(AI Agent)開發(fā)與應(yīng)用全面調(diào)研：概念、原理、開發(fā)、應(yīng)用、挑戰(zhàn)、展望

PromptAppGPT低代碼大語(yǔ)言模型應(yīng)用開發(fā)實(shí)戰(zhàn)：聊天機(jī)器人、智能文生圖、圖文搜索

2 - 基礎(chǔ)檢索增強(qiáng)生成(RAG)技術(shù)

基礎(chǔ)RAG流程圖。圖源：旺知識(shí)

基礎(chǔ)RAG流程簡(jiǎn)單來說如下：將文本分割成塊，然后使用編碼模型將這些塊嵌入到向量中，將所有這些向量放入索引中，最后為L(zhǎng)LM創(chuàng)建一個(gè)提示，告訴模型根據(jù)我們?cè)谒阉鞑襟E中找到的上下文來回答用戶的查詢。

在運(yùn)行時(shí)，我們使用相同的編碼器模型對(duì)用戶的查詢進(jìn)行矢量化，然后針對(duì)索引執(zhí)行該查詢向量的搜索，找到前k個(gè)結(jié)果，從數(shù)據(jù)庫(kù)中檢索相應(yīng)的文本塊，并將它們作為上下文輸入到LLM提示中。

下面是一個(gè)示例提示信息：

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

提示工程是可以嘗試改進(jìn)RAG系統(tǒng)的最便捷便宜的方法?？梢詤⒖既缦挛恼铝私飧嗵崾竟こ碳记桑?/p>

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

ChatGPT提示工程師必備基礎(chǔ)知識(shí)與進(jìn)階技巧！

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

3 - 高級(jí)檢索增強(qiáng)生成(RAG)技術(shù)

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

高級(jí)RAG的些關(guān)鍵流程圖。圖源：旺知識(shí)

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

3.1 - 分塊和矢量化

首先，我們要?jiǎng)?chuàng)建一個(gè)向量索引，表示我們的文檔內(nèi)容，然后在運(yùn)行時(shí)搜索所有這些向量與對(duì)應(yīng)于最接近語(yǔ)義的查詢向量之間的最小余弦距離。

3.1.1 - 分塊

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

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

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

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

a.分塊因素

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

被索引的內(nèi)容的性質(zhì)是什么？您是否正在處理長(zhǎng)文檔（例如文章或書籍）或較短的內(nèi)容（例如推文或即時(shí)消息）？答案將決定哪種模型更適合您的目標(biāo)，以及應(yīng)用哪種分塊策略。

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

您對(duì)用戶查詢的長(zhǎng)度和復(fù)雜性有何期望？它們會(huì)簡(jiǎn)短而具體，還是長(zhǎng)而復(fù)雜？這也可能會(huì)告訴您選擇對(duì)內(nèi)容進(jìn)行分塊的方式，以便嵌入式查詢和嵌入式塊之間有更緊密的相關(guān)性。

檢索到的結(jié)果將如何在您的特定應(yīng)用程序中使用？例如，它們會(huì)用于語(yǔ)義搜索、問答、摘要或其他目的嗎？例如，如果您的結(jié)果需要輸入到具有令牌限制的另一個(gè)LLM中，您必須考慮到這一點(diǎn)，并根據(jù)您想要適應(yīng)請(qǐng)求的塊數(shù)量來限制塊的大小。

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

b -分塊方法

分塊的方法有多種，每種方法可能適合不同的情況。通過檢查每種方法的優(yōu)點(diǎn)和缺點(diǎn)，我們的目標(biāo)是確定應(yīng)用它們的正確場(chǎng)景。

b.1 - 固定大小分塊

這是最常見、最直接的分塊方法：我們只需決定塊中的標(biāo)記數(shù)量，以及可選地確定它們之間是否應(yīng)該有重疊。一般來說，我們希望在塊之間保留一些重疊，以確保語(yǔ)義上下文不會(huì)在塊之間丟失。在大多數(shù)常見情況下，固定大小的分塊將是最佳路徑。與其他形式的分塊相比，固定大小的分塊計(jì)算成本低且易于使用，因?yàn)樗恍枰褂萌魏蜰LP庫(kù)。

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

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 - 內(nèi)容感知分塊

這種方法利用我們正在分塊的內(nèi)容的性質(zhì)并對(duì)其應(yīng)用更復(fù)雜的分塊的一組方法。這里有些例子：

句子分塊：正如我們之前提到的，許多模型都針對(duì)嵌入句子級(jí)內(nèi)容進(jìn)行了優(yōu)化。當(dāng)然，我們會(huì)使用句子分塊，并且有多種方法和工具可用于執(zhí)行此操作，包括：

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

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

NLTK：自然語(yǔ)言工具包(NLTK)是一個(gè)流行的Python庫(kù)，用于處理人類語(yǔ)言數(shù)據(jù)。它提供了一個(gè)句子標(biāo)記器，可以將文本分割成句子，幫助創(chuàng)建更有意義的塊。例如，要將NLTK與LangChain結(jié)合使用，可以執(zhí)行以下操作：

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

spaCy：spaCy是另一個(gè)用于NLP任務(wù)的強(qiáng)大Python庫(kù)。它提供了復(fù)雜的句子分割功能，可以有效地將文本分割成單獨(dú)的句子，從而在生成的塊中更好地保留上下文。例如，要將spaCy與LangChain結(jié)合使用，可以執(zhí)行以下操作：

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

遞歸分塊：遞歸分塊使用一組分隔符以分層和迭代的方式將輸入文本劃分為更小的塊。如果分割文本的初始嘗試沒有生成所需大小或結(jié)構(gòu)的塊，則該方法會(huì)使用不同的分隔符或標(biāo)準(zhǔn)在生成的塊上遞歸調(diào)用自身，直到達(dá)到所需的塊大小或結(jié)構(gòu)。這意味著雖然塊的大小不會(huì)完全相同，但它們?nèi)匀弧翱释本哂邢嗨频拇笮　?/p>

以下是如何在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是可能遇到的結(jié)構(gòu)化和格式化內(nèi)容的兩個(gè)示例。在這些情況下，可以使用專門的分塊方法在分塊過程中保留內(nèi)容的原始結(jié)構(gòu)。

Markdown：Markdown是一種輕量級(jí)標(biāo)記語(yǔ)言，通常用于格式化文本。通過識(shí)別Markdown語(yǔ)法（例如標(biāo)題、列表和代碼塊），您可以根據(jù)內(nèi)容的結(jié)構(gòu)和層次結(jié)構(gòu)智能地劃分內(nèi)容，從而產(chǎn)生語(yǔ)義上更連貫的塊。例如：

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是一種文檔準(zhǔn)備系統(tǒng)和標(biāo)記語(yǔ)言，常用于學(xué)術(shù)論文和技術(shù)文檔。通過解析LaTeX命令和環(huán)境，可以創(chuàng)建尊重內(nèi)容邏輯組織的塊（例如，部分、小節(jié)和方程），從而獲得更準(zhǔn)確且與上下文相關(guān)的結(jié)果。例如：

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 -分塊優(yōu)化

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

預(yù)處理數(shù)據(jù)：在確定應(yīng)用程序的最佳塊大小之前，您需要首先預(yù)處理數(shù)據(jù)以確保質(zhì)量。例如，如果您的數(shù)據(jù)是從網(wǎng)絡(luò)檢索的，您可能需要?jiǎng)h除HTML標(biāo)簽或只會(huì)增加噪音的特定元素。

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

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

在大多數(shù)情況下，對(duì)內(nèi)容進(jìn)行分塊非常簡(jiǎn)單-但當(dāng)您開始偏離常規(guī)時(shí)，它可能會(huì)帶來一些挑戰(zhàn)。沒有一種萬(wàn)能的分塊解決方案，因此適用于一種用例的方法可能不適用于另一種用例。希望這篇文章能夠幫助您更好地了解如何為應(yīng)用程序進(jìn)行分塊。

3.1.2 矢量化

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

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

對(duì)于分塊和矢量化步驟的端到端實(shí)現(xiàn)，可以參考查看LlamaIndex中完整數(shù)據(jù)攝取管道的示例：

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

3.2 -搜索索引

3.2.1 - 向量存儲(chǔ)索引

基本索引檢索流程圖。圖源：旺知識(shí)

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

同時(shí)還有OpenSearch或ElasticSearch等托管解決方案以及矢量數(shù)據(jù)庫(kù)，例如Pinecone、Weaviate或Chroma，負(fù)責(zé)在后臺(tái)處理數(shù)據(jù)攝取管道。

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

LlamaIndex支持大量向量存儲(chǔ)索引，但也支持其他更簡(jiǎn)單的索引實(shí)現(xiàn)，例如列表索引、樹索引和關(guān)鍵字表索引。

3.2.2 - 層次索引

層次索引流程圖。圖源：旺知識(shí)

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

3.2.3 - 假設(shè)問題和HyDE

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

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

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

3.2.4 - 上下文豐富

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

a -句子窗口檢索

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

句子窗口檢索。圖源：旺知識(shí)

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

b - 自動(dòng)合并檢索器（又名父文檔檢索器）

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

父子塊檢索。圖源：旺知識(shí)

文檔被分成塊的層次結(jié)構(gòu)，然后最小的葉塊被發(fā)送到索引。在檢索時(shí)，我們檢索k個(gè)葉子塊，如果有n個(gè)塊引用同一父塊，我們用該父塊替換它們并將其發(fā)送到LLM進(jìn)行答案生成。

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

3.2.5 - 融合檢索或混合搜索

一個(gè)自然的想法是，可以充分利用兩個(gè)世界的優(yōu)點(diǎn)—基于關(guān)鍵字的老式搜索—稀疏檢索算法（如tf-idf或搜索行業(yè)標(biāo)準(zhǔn)BM25）和現(xiàn)代語(yǔ)義或向量搜索，并將其組合到一個(gè)檢索結(jié)果中。

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

融合檢索。圖源：旺知識(shí)

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

混合或融合搜索通常會(huì)提供更好的檢索結(jié)果，因?yàn)榻Y(jié)合了兩種互補(bǔ)的搜索算法，同時(shí)考慮了查詢與存儲(chǔ)文檔之間的語(yǔ)義相似性和關(guān)鍵字匹配。

3.3 - 重新排序和過濾

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

現(xiàn)在是時(shí)候?qū)W習(xí)更復(fù)雜的RAG技術(shù)了，比如查詢轉(zhuǎn)換和路由，它們都涉及LLM，從而代表Agent行為，涉及復(fù)雜的邏輯，涉及RAG管道中的LLM推理。

3.4 - 查詢轉(zhuǎn)換

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

查詢轉(zhuǎn)換原理圖解。圖源：旺知識(shí)

如果查詢很復(fù)雜，可以將其分解為多個(gè)子查詢。例如，如果你問：

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

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

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

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

它們將并行執(zhí)行，然后將檢索到的上下文合并到一個(gè)提示中，供LLM合成初始查詢的最終答案。這兩個(gè)庫(kù)都實(shí)現(xiàn)了此功能-作為L(zhǎng)angChain中的多查詢檢索器和LlamaIndex中的子問題查詢引擎。

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

查詢重寫：使用LLM重新制定初始查詢以改進(jìn)檢索。LangChain和LlamaIndex都有實(shí)現(xiàn)，只是有點(diǎn)不同，我發(fā)現(xiàn)LlamaIndex解決方案在這里更強(qiáng)大。

參考文獻(xiàn)引用

這個(gè)沒有數(shù)字，因?yàn)樗袷且环N工具，而不是檢索改進(jìn)技術(shù)，盡管這是一個(gè)非常重要的技術(shù)。如果我們使用多個(gè)源來生成答案，要么是由于初始查詢的復(fù)雜性（我們必須執(zhí)行多個(gè)子查詢，然后將檢索到的上下文合并到一個(gè)答案中），要么是因?yàn)槲覀冊(cè)诟鞣N文檔中找到了單個(gè)查詢的相關(guān)上下文，問題是我們是否能夠準(zhǔn)確地回溯我們的來源。有幾種方法可以做到這一點(diǎn)：

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

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

3.5 - 聊天引擎

構(gòu)建一個(gè)可以針對(duì)單個(gè)查詢多次工作的優(yōu)秀RAG系統(tǒng)的下一個(gè)重要事項(xiàng)是聊天邏輯，考慮到對(duì)話上下文，與LLM時(shí)代之前的經(jīng)典聊天機(jī)器人相同。

這需要支持與先前對(duì)話上下文相關(guān)的后續(xù)問題、照應(yīng)或任意用戶命令。它將聊天上下文與用戶查詢一起考慮在內(nèi)，通過查詢壓縮技術(shù)來解決。

有幾種方法可以實(shí)現(xiàn)上下文壓縮：

一個(gè)流行且相對(duì)簡(jiǎn)單的ContextChatEngine，首先檢索與用戶查詢相關(guān)的上下文，然后將其與內(nèi)存緩沖區(qū)中的聊天歷史記錄一起發(fā)送給LLM，以便LLM在生成下一個(gè)答案時(shí)了解先前的上下文。

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

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

還有其他聊天引擎類型，例如ReActAgent，但讓我們?cè)诘?.7節(jié)中說明。

3.6 - 查詢路由

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

查詢路由器還用于選擇索引或更廣泛的數(shù)據(jù)存儲(chǔ)，將用戶查詢發(fā)送到何處-要么您有多個(gè)數(shù)據(jù)源，例如經(jīng)典向量存儲(chǔ)和圖形數(shù)據(jù)庫(kù)或關(guān)系數(shù)據(jù)庫(kù)，要么您有索引的層次結(jié)構(gòu)-對(duì)于多文檔存儲(chǔ)，一個(gè)非常經(jīng)典的情況是摘要索引和文檔塊向量的另一個(gè)索引。

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

3.7 - RAG中的Agent

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

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

在LlamaIndex中，有一個(gè)OpenAIAgent類將這種高級(jí)邏輯與ChatEngine和QueryEngine類結(jié)合起來，提供基于知識(shí)和上下文感知的聊天，以及在一個(gè)對(duì)話輪中調(diào)用多個(gè)OpenAI函數(shù)的能力，這真正帶來了智能Agent行為。

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

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

該方案展示了一種先進(jìn)的RAG架構(gòu)，其中包含每個(gè)相關(guān)Agent做出的大量路由決策。這種方法的好處是能夠比較不同文檔中描述的不同解決方案或?qū)嶓w及其摘要以及經(jīng)典的單文檔摘要和QA機(jī)制-這基本上涵蓋了最常見的與文檔集合聊天的用例。

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

這種復(fù)雜方案的缺點(diǎn)可以從圖片中猜到，由于我們Agent內(nèi)部使用LLM進(jìn)行了多次來回迭代，它有點(diǎn)慢。以防萬(wàn)一，LLM調(diào)用始終是RAG管道中最長(zhǎng)的操作，搜索在設(shè)計(jì)上針對(duì)速度進(jìn)行了優(yōu)化。因此，對(duì)于大型多文檔存儲(chǔ)，我們建議對(duì)該方案進(jìn)行一些簡(jiǎn)化，使其具有可擴(kuò)展性。

3.8 - 響應(yīng)合成器

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

但是，與往常一樣，還有其他更復(fù)雜的選項(xiàng)，涉及多個(gè)LLM調(diào)用，以細(xì)化檢索到的上下文并生成更好的答案。

響應(yīng)合成的主要方法包括：

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

2.總結(jié)檢索到的上下文以適應(yīng)提示

3.根據(jù)不同的上下文塊生成多個(gè)答案，然后將它們連接或總結(jié)。

更多詳細(xì)信息，可以參考響應(yīng)合成器模塊文檔：

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

4 - RAG系統(tǒng)模型微調(diào)

RAG系統(tǒng)涉及多個(gè)模型，可以考慮對(duì)它們進(jìn)行微調(diào)：

編碼器模型(Transformer)：負(fù)責(zé)內(nèi)容向量編碼，從而負(fù)責(zé)上下文檢索質(zhì)量

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

排序器(Ranker)：負(fù)責(zé)對(duì)檢索結(jié)果排序優(yōu)選

如今的一大優(yōu)勢(shì)是可以使用GPT-4等高端LLM來生成高質(zhì)量的合成數(shù)據(jù)集。但應(yīng)該始終意識(shí)到，采用由專業(yè)研究團(tuán)隊(duì)在仔細(xì)收集、清理和驗(yàn)證的大型數(shù)據(jù)集上訓(xùn)練的開源模型，并使用小型合成數(shù)據(jù)集進(jìn)行快速調(diào)整可能會(huì)縮小模型的總體能力。

4.1 - 編碼器微調(diào)

我們?cè)贚lamaIndex設(shè)置中測(cè)試了通過微調(diào)bge-large-en-v1.5（撰寫本文時(shí)MTEB排行榜前4名）帶來的性能提升，結(jié)果顯示檢索質(zhì)量提高了2%。沒什么戲劇性的，但很高興有這個(gè)選項(xiàng)，特別是如果你有構(gòu)建RAG的領(lǐng)域數(shù)據(jù)集。

4.2 - 排序器微調(diào)

另一個(gè)好的選項(xiàng)是如果您不完全信任基本編碼器，則可以對(duì)檢索到的結(jié)果進(jìn)行重新排名。

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

結(jié)果表明，通過交叉編碼器微調(diào)，成對(duì)分?jǐn)?shù)(pairwise)提高了4%，這里可以找到這種調(diào)整過程的一個(gè)很好的例子：

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

4.3 - LLM微調(diào)

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

最近的論文RA-DIT：MetaAIResearch的檢索增強(qiáng)雙指令調(diào)整中演示了一種更復(fù)雜的方法，提出了一種同時(shí)調(diào)整LLM和Retriever的技術(shù)，優(yōu)化關(guān)于查詢、上下文和答案的三元組。具體實(shí)現(xiàn)方式請(qǐng)參考本指南:

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

該技術(shù)用于通過微調(diào)API和Llama2開源模型（在原始論文中）對(duì)OpenAI LLM進(jìn)行微調(diào)，從而使知識(shí)密集型任務(wù)指標(biāo)增加約5%（與帶有RAG的Llama265B相比）常識(shí)推理任務(wù)也增加了幾個(gè)百分點(diǎn)。

5 - RAG系統(tǒng)評(píng)估

RAG系統(tǒng)性能評(píng)估有多個(gè)框架，它們共享一些獨(dú)立指標(biāo)的想法，例如總體答案相關(guān)性、答案基礎(chǔ)性、忠實(shí)性和檢索到的上下文相關(guān)性。上一節(jié)提到的Ragas使用忠實(shí)度和答案相關(guān)性作為生成的答案質(zhì)量指標(biāo)，并使用經(jīng)典的上下文精確度和召回率作為RAG方案的檢索部分。

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

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

可以在此處找到一個(gè)非常簡(jiǎn)單的檢索器評(píng)估管道的好示例，并將其應(yīng)用于編碼器微調(diào)部分：https://github.com/run-llama/finetune-embedding/blob/main/evaluate.ipynb

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

LangChain有一個(gè)非常先進(jìn)的評(píng)估框架LangSmith，可以在其中實(shí)現(xiàn)自定義評(píng)估器，并且它監(jiān)視RAG管道內(nèi)運(yùn)行的跟蹤，以使您的系統(tǒng)更加透明。

如果您使用LlamaIndex進(jìn)行構(gòu)建，可以使用rag_evaluator llama包，它提供了一個(gè)使用公共數(shù)據(jù)集評(píng)估管道的快速工具。

6 -總結(jié)展望

我們?cè)噲D系統(tǒng)化梳理RAG的核心方法，并舉例說明其中的一些方法，希望這可能會(huì)激發(fā)一些新穎的思路，以便在RAG系統(tǒng)中進(jìn)行探索。

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

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

審核編輯：劉清