RAG 是2023年最流行的基于 LLM 的應用系統架構。有許多產品幾乎完全建立在 RAG 之上，覆蓋了結合網絡搜索引擎和 LLM 的問答服務，到成千上萬個數據聊天的應用程序。很多人將RAG和Agent 作為大模型應用的兩種主流架構，但什么是RAG呢？RAG又涉及了哪些具體的技術呢？

1. 什么是RAG

RAG即檢索增強生成，為 LLM 提供了從某些數據源檢索到的信息，并基于此修正生成的答案。RAG 基本上是 Search + LLM 提示，可以通過大模型回答查詢，并將搜索算法所找到的信息作為大模型的上下文。查詢和檢索到的上下文都會被注入到發送到 LLM 的提示語中。

嵌入式搜索引擎可以通過 Faiss 來實現，向量搜索領域成為了RAG的一個助力。像pinecone 這樣的向量數據庫可以構建開源搜索索引，為輸入文本增加了額外的存儲空間，還增加了一些其他工具。關于向量數據庫，可以參考解讀向量數據庫。

面向RAG的開發框架，對于基于 LLM 的流水線和應用程序，有兩個最著名的開源工具—— LangChain 和 LlamaIndex，分別是在2022年10月和11月創建的，隨著 ChatGPT 爆發，也在2023年獲得了大量采用。LlamaIndex 和 LangChain 都是令人驚嘆的開源項目，它們的發展速度非常快。

圖片

2. 基礎的 RAG 技術

RAG 系統的起點一般是一個文本文檔的語料庫，簡單看起來是這樣的: 把文本分割成塊，然后把這些分塊嵌入到向量與transformer編碼器模型，把所有這些向量建立索引，最后創建一個 LLM 提示語，告訴模型回答用戶的查詢，給出在搜索步驟中找到的上下文。在運行時，我們用相同的編碼器模型完成用戶查詢的向量化，然后執行這個查詢向量的索引搜索，找到top-k 的結果，從數據庫中檢索到相應的文本塊，并提供給 LLM 提示語Prompt作為上下文。

圖片

在OpenAI 平臺上，提示詞Prompt可以是這樣的:

def question_answering(context, query):
    prompt = f""" my query text...                
                """

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

關于提示詞和提示詞工程的更多介紹可以參考OpenAI 的提示詞工程手冊以及解讀提示工程（Prompt Engineering）。

顯然，盡管 OpenAI 在LLM 市場上處于領先地位，但還是有很多替代方案，比如 Anthroic 的 Claude，還有最近流行的更小但功能強大的模型，比如 Mistral，微軟的 Phi-2 以及許多開源選項，比如 Llama2，OpenLLaMA，Falcon等都可以用來開發面向RAG的大模型產品。

3. RAG中的高級技術

盡管并不是所有RAG系統中的高級技術都可以輕松地在一張圖中可視化，但給出一個描述核心步驟和算法的方案還是有意義的。

圖片

3.1. 分塊和矢量化

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

由于transformer模型有固定的輸入序列長度，即使輸入上下文的窗口很大，一個或幾個句子的向量也比一個在幾頁文本上取平均值的向量更能代表它們的語義意義 ，所以數據分塊是一個有意義的技術。把初始文檔分成一定大小的塊，同時又不失去它們的意義，也就是把文本分成句子或段落，而不是把一個句子分成兩部分。而且，已經有了各種能夠執行此任務的文本分割器實現。例如，在 LlamaIndex 中，NodeParser 就提供了一些高級選項，如定義自己的文本分割器、元數據、節點/塊關系等。

數據塊的大小是一個需要考慮的參數，它取決于使用的嵌入模型及其token容量，標準的transformer編碼模型，如BERT 的句子轉換器，最多只能使用512個token，OpenAI ada-002能夠處理更長的序列，如8191個token，但這里的折衷是足夠的上下文，讓 LLM 能夠推理以及特定的足夠文本嵌入，以便有效地執行搜索。

下一步是選擇一個模型來生產所選塊的嵌入，同樣有很多方法，例如搜索優化的模型（ bge-large 或者E5 系列），MTEB 排行榜可以得到最新的一些方法信息。關于文檔分塊和向量化步驟的端到端實現，可以具體地參考https://docs.llamaindex.ai/en/latest/moduleguides/loading/ingestionpipeline/root.html#。

3.2. 搜索的索引

面向RAG的大模型應用的關鍵部分是用于搜索的索引，它存儲前面得到的向量化內容。當然，查詢總是首先向量化，對于 top k 分塊也是一樣的。最簡單的實現使用一個平鋪的索引，在查詢向量和所有塊向量之間進行距離計算并遍歷。

一個合適的搜索索引，為了在一萬多個元素的尺度上有效地檢索而優化，需要一個向量索引， faiss，nmslib 或 annoy等使用一些近似最近鄰方式實現，如聚類，樹或 HNSW 算法。還有一些受管理的解決方案，比如 ElasticSearch以及向量數據庫，它們負責處理數據攝取的流水線。

根據索引的選擇，數據和搜索需求還可以將元數據與向量一起存儲，然后使用元數據過濾器在某些日期或數據源中搜索信息。LlamaIndex 支持許多向量存儲索引，也支持其他更簡單的索引實現，如列表索引、樹索引和關鍵字表索引。

如果有許多文檔，就需要能夠有效地在其中進行搜索，找到相關信息，并將其聚合在一個帶有源引用的答案中。對于大型數據庫，一個有效的方法是創建兩個索引，一個由摘要組成，另一個由文檔塊組成，然后分兩個步驟進行搜索，首先通過摘要過濾掉相關文檔，然后再通過相關組進行搜索。

圖片

另一種方法是要求 LLM 為每個塊生成一個問題，并將這些問題嵌入到向量中，在運行時對這個問題的向量索引執行查詢搜索(在索引中用問題向量替換塊向量) ，然后路由到原始文本塊并將它們作為 LLM 獲得答案的上下文發送。這種方法提高了搜索質量，因為與實際塊相比，查詢和假設問題之間具有更高的語義相似性。還有一種被稱為 HyDE 的反向邏輯方法, 要求一個 LLM 生成一個假設的給定查詢的響應，然后使用它的向量和查詢向量來提高搜索質量。

為了獲得更好的搜索質量而檢索更小的塊，就要為 LLM 添加周圍的上下文。有兩種選擇，一個是句子窗口檢索，即在檢索到的較小塊周圍按句子展開上下文，另一個是父文檔檢索，即遞歸地將文檔分割成若干較大的父塊，其中包含較小的子塊。

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

父文檔檢索與句子窗口檢索非常相似，都是搜索更細粒度的信息，然后在將上下文提供給 LLM 進行推理之前擴展過的上下文窗口。文檔被拆分成引用較大父塊中的較小子塊。具體而言，文檔被分割成塊的層次結構，然后最小的葉子塊被發送到索引。在檢索期間，獲取較小的塊，然后如果在top-k 檢索的塊中有超過 n 個塊鏈接到同一個父節點(較大的塊) ，就用這個父節點替換提供給 LLM 的上下文。需要注意的是，搜索僅在子節點索引中執行。

還有一個相對較老的思路，可以像 tf-idf 或BM25這樣的稀疏檢索算法那樣從現代語義或向量搜索中獲取最佳結果，并將其結合在一個檢索結果中。這里唯一的技巧是將檢索到的結果與不同的相似度得分恰當地結合起來，這個問題通常借助于Reciprocal Rank 融合算法（RRF）來解決，對檢索到的結果重新排序以得到最終的輸出。

圖片

在 LangChain中，這是在集成檢索器類中實現的，例如，一個 Faiss 矢量索引和一個基于 BM25的檢索器，并使用 RRF 進行重新排序。在 LlamaIndex 中，也是以一種非常類似的方式完成的。

混合或融合搜索通常在考慮查詢和存儲文檔之間有語義相似性和關鍵字匹配的情況下，將兩種互補的搜索算法結合起來，提供更好的檢索結果。

3.3. Rerank和過濾

在得到了檢索結果后，需要通過過濾來重新排序。LlamaIndex 提供了多種可用的后處理程序，根據相似度評分、關鍵詞、元數據過濾掉結果，或者用其他模型對結果進行重新排序，比如基于句子transformer的交叉編碼器、 根據元數據(比如日期最近性)內聚重新排序等等。這是將檢索到的上下文提供給 LLM 以獲得結果答案之前的最后一步。

3.4. query變換

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

如果查詢很復雜，LLM 可以將其分解為幾個子查詢。例如，如果問“ 在Github上Langchain 或 LlamaIndex 上哪個有更多顆星?”，不太可能在語料庫中找到直接的對比，將這個問題分解為兩個子查詢是有意義的，前提是要有更簡單和更具體的信息檢索，例如 “ Langchain 在 Github 上有多少顆星?”“Llamaindex 在 Github 上有多少顆星?”它們將并行執行，然后將檢索到的上下文組合在一個提示語中，以便 LLM 合成對初始查詢的最終答案。在 Langchain 作為多查詢檢索器，在 Llamaindex 作為子問題查詢引擎。

圖片

后退提示（Step-back prompting）使用 LLM 生成一個更一般的查詢，為此檢索獲得一個更一般或更高級別的上下文，以便將原始查詢的答案建立在這個上下文上。此外，還將執行對原始查詢的檢索，并在最后的應答生成步驟中將兩個上下文提供給 LLM。LangChain 有一個參考實現https://github.com/langchain-ai/langchain/blob/master/cookbook/stepback-qa.ipynb。query重寫使用 LLM 重新制定初始查詢，以提高檢索效率。LangChain 和 LlamaIndex 都有實現，但 LlamaIndex 參考實現更強大https://llamahub.ai/l/llamapacks-fusionretriever-query_rewrite。

如果使用多個來源來生成一個答案，要么是由于初始查詢的復雜性，需要必須執行多個子查詢，然后將檢索到的上下文合并到一個答案中，要么是在多個文檔中發現了單個查詢的相關上下文，能夠準確地反向引用。可以將這個引用任務插入到提示語中，并要求 LLM 提供所使用源的 id，然后將生成的響應部分與索引中的原始文本塊匹配，Llamaindex 為這種情況提供了一種有效的基于模糊匹配的解決方案。

3.5. 聊天引擎

構建一個可以在單個查詢中多次運行RAG系統的一個重要特性是聊天邏輯，考慮到對話上下文，就像在 LLM 時代之前的經典聊天機器人一樣。這是支持后續問題，重復指代，或任意用戶命令相關的以前對話上下文所必需的。查詢壓縮技術可以同時考慮聊天上下文和用戶查詢。有幾種方法可以實現上下文壓縮，一種流行且相對簡單的 ContextChatEngine，首先檢索與用戶查詢相關的上下文，然后將其連同聊天歷史從存緩發送給 LLM，讓 LLM 在生成下一個答案時能夠意識到前一個上下文。

圖片

更復雜的實現是 CondensePlusContextMode，在每次交互中，聊天歷史記錄和最后一條消息被壓縮成一個新的查詢，然后這個查詢進入索引，檢索到的上下文被傳遞給 LLM連同原始用戶消息來生成一個答案。

3.6. query 路由

Query路由是由 LLM 驅動的決策步驟，在給定用戶查詢的情況下，決定接下來做什么。這些選項通常是總結、針對某些數據索引執行搜索或嘗試多種不同的路由，然后在一個答案中綜合它們的輸出。

Query路由還可以用于選擇索引，或者更廣泛的數據存儲，將用戶查詢發送到何處，例如，經典的向量存儲和圖形數據庫或關系數據庫。對于多文檔存儲來說，一個非常經典的情況是一個摘要索引和另一個文檔塊向量索引。

定義Query路由包括設置它可以做出的選擇。路由選擇是通過一個 LLM 調用來執行的，它以預定義的格式返回結果，用于將查詢路由到給定的索引。如果采用了代理的方式，則將查詢路由到子鏈甚至其他代理，如下面的多文檔代理方案所示。LlamaIndex 和 LangChain 都支持Query路由。

3.7. RAG中的智能體Agent

智能體Agent幾乎自第一個 LLM API 發布以來就一直存在，其想法是為一個能夠推理的 LLM 提供一套工具以及需要完成的任務。這些工具可能包括一些確定性函數，比如任何代碼函數或外部 API，甚至包括其他代理，這種 LLM 鏈接思想就是 LangChain 來源。

代理本身就是一個巨大的話題，OpenAI 助手基本上已經實現了很多圍繞 LLM 所需的工具，也許最重要的是函數調用 API。后者提供了將自然語言轉換為對外部工具或數據庫查詢的 API 調用的功能。在 LlamaIndex 中，有一個 OpenAIAgent 類將這種高級邏輯與 ChatEngine 和 QueryEngine 結合在一起，提供基于知識和上下文感知的聊天功能，以及一次性調用多個 OpenAI 函數的能力，這確實帶來了智能代理的使用方式。

圖片

以多文檔代理為例，在每個文檔上會初始化一個代理(OpenAIAgent) ，能夠進行文檔摘要和經典的 QA 機制，以及一個頂級總代理，負責將查詢路由到文檔代理和最終答案合成。每個文檔代理都有兩個工具ーー向量存儲索引和摘要索引，并根據路由查詢決定使用哪個工具。該體系結構由每個相關代理做出大量的路由決策。這種方法的好處是能夠比較不同的解決方案或實體，這些解決方案或實體在不同的文檔及其摘要以及經典的單一文檔摘要和QA 機制中進行了描述，這基本上涵蓋了最常見的與文檔集聊天的使用場景。

該方案由于在內部使用 LLM 進行了多次來回迭代，因此速度有點慢。為了防萬一，LLM 調用通過 RAG 流水線中最長的搜索操作來優化速度。因此，對于大型多文檔存儲，可以對該方案進行一些簡化，使其具有可伸縮性。

3.8. 響應合成

響應合成是任何 RAG 流水線的最后一步，根據檢索的所有上下文和初始用戶查詢生成一個答案。最簡單的方法是將所有獲取的上下文(高于某個相關性閾值)與查詢一起連接并提供給 LLM。但是，還有其他更復雜的選項涉及多個 LLM 調用，以細化檢索到的上下文并生成更好的答案。響應合成的主要方法有：

1. 通過逐塊向LLM發送檢索到的上下文來迭代地細化答案；
2. 總結檢索到的上下文以適應提示；
3. 根據不同的上下文塊生成多個答案，然后將其連接或總結。

有關響應合成的更多信息，可以參考文檔中的示例https://docs.llamaindex.ai/en/stable/moduleguides/querying/responsesynthesizers/root.html。

4. 面向RAG的編碼器和大模型微調

對 RAG 流水線中涉及的深度學習模型進行一些微調，一個是負責嵌入質量從而提高上下文檢索質量的 Transformer Encoder，另一個負責利用提供的上下文來回答用戶查詢的 LLM。可以使用 GPT-4這樣的高端 LLM 來生成高質量的合成數據集。但是應該始終注意到，采用一個大型數據集進行訓練的開源模型，并使用小型合成數據集進行快速調優，可能會削弱模型的總體能力。

較新版本的transformer編碼器優化搜索是相當有效的，bge-large-en-v1.5即便在筆記本電腦環境中仍能夠有較大的檢索質量提升。

4.1.編碼器微調

一個很好的老選擇是有一個交叉編碼器。如果不完全信任基本編碼器，交叉編碼器可以對檢索到的結果重新排序。它的工作原理是把查詢和每個最高k個檢索到的文本塊傳遞給交叉編碼器，用一個標記分隔，然后對它進行微調，相關的塊輸出為1，不相關的塊輸出為0。這種調整過程可以參考https://docs.llamaindex.ai/en/latest/examples/finetuning/crossencoderfinetuning/crossencoderfinetuning.html#。

4.2.大模型微調

最近 OpenAI 開始提供 LLM 微調 API，LlamaIndex 有一個關于在 RAG 設置中微調 GPT-3.5-turbo 以“提取”一些 GPT-4知識的教程。基本思路是獲取一個文檔，使用 GPT-3.5-turbo 生成一系列問題，然后使用 GPT-4根據文檔內容生成這些問題的答案即構建一個基于 GPT4的 RAG 流水線 ，然后在問答對的數據集上對 GPT-3.5-turbo 進行微調。通過對 RAG 流水線的評估，可以初步確定經過微調的 GPT 3.5-turbo 模型比原始模型能夠更好地利用所提供的上下文來生成其答案。

在論文 RA-DIT: Meta AI Research 的檢索增強雙指令優化中，有一種更為復雜的方法，提出了一種在查詢、上下文和答案這個三元組上同時優化 LLM 和檢索器(原論文中的雙重編碼器)的技術。這種技術被用于通過微調 API 和 Llama2開源模型來微調 OpenAI LLM (在原論文中) ，導致知識密集型任務指標增加約5% (與使用 RAG 的 Llama265B 相比) ，并且常識推理任務增加了幾個百分點。有關實施細節，可以參考https://docs.llamaindex.ai/en/stable/examples/finetuning/knowledge/finetuneretrievalaug.html#fine-tuning-with-retrieval-augmentation。

5. 面向RAG的性能評估

有幾個框架都可以應用于RAG 系統的性能評估，指標包括總體答案相關性、答案溯源性、可信度和檢索到的上下文相關性等等。

Ragas框架,使用可信度和答案相關性作為 RAG 檢索部分生成答案的質量指標和經典的上下文準召率。評估框架 Truelens 建議采用檢索與查詢的上下文相關性、答案溯源性以及與查詢的答案相關性，將這三個指標作為 RAG 系統的性能評估三元組。其中，關鍵且最可控的指標是檢索到的上下文相關性，其次是答案相關性和溯源性。

LangChain 有一個非常先進的評估框架 LangSmith，可以實現自定義的評估器，還可以跟蹤 RAG 流水線的運行狀態，以使系統更加透明。而在LlamaIndex 中有一個rag_evaluator的包，提供了一個簡便工具使用公共數據集來評估RAG系統。

6. 小結

RAG 系統的主要挑戰除了答案的相關性和可信度之外，還有就是速度。然而，還有很多其他事情需要考慮，比如基于網絡搜索的 RAG，與Agent架構的深度融合，以及關于 LLM 長期記憶的一些方式方法。即便如此，RAG 仍然有著廣泛的應用范圍，我們在使用RAG落地應用的時候， 希望本文中提到的這些技術能夠對大家有所幫助。

圖片

【參考資料】

• https://docs.llamaindex.ai/en/stable/apireference/servicecontext/nodeparser.html
• https://huggingface.co/spaces/mteb/leaderboard
• https://huggingface.co/BAAI/bge-large-en-v1.5
• https://huggingface.co/intfloat/multilingual-e5-large
• http://boston.lti.cs.cmu.edu/luyug/HyDE/HyDE.pdf
• https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf
• https://python.langchain.com/docs/modules/dataconnection/retrievers/MultiQueryRetriever
• https://docs.llamaindex.ai/en/stable/examples/queryengine/subquestionqueryengine.html
• https://github.com/langchain-ai/langchain/blob/master/cookbook/stepback-qa.ipynb
• https://docs.ragas.io/en/latest/index.html
• https://arxiv.org/pdf/2310.01352.pdf
• https://github.com/truera/trulens/tree/main
• https://docs.smith.langchain.com/
• https://github.com/run-llama/llama-
• hub/tree/dac193254456df699b4c73dd98cdbab3d1dc89b0/llamahub/llamapacks/rag_evaluator