1 Retrieval Augmented Generation 檢索增強生成

**Why RAG？**

當我們將大模型應用于實際業務場景時會發現，通用的基礎大模型基本無法滿足實際業務需求，主要有以下幾方面原因：

• 知識的局限性：大模型自身的知識完全源于訓練數據，而現有的主流大模型（deepseek、文心一言、通義千問…）的訓練集基本都是構建于網絡公開的數據，對于一些實時性的、非公開的或私域的數據是沒有。
• 幻覺問題：所有的深度學習模型的底層原理都是基于數學概率，模型輸出實質上是一系列數值運算，大模型也不例外，所以它經常會一本正經地胡說八道，尤其是在大模型自身不具備某一方面的知識或不擅長的任務場景。
• 數據安全性：對于企業來說，數據安全至關重要，沒有企業愿意承擔數據泄露的風險，尤其是大公司，沒有人將私域數據上傳第三方平臺進行訓練會推理。這也導致完全依賴通用大模型自身能力的應用方案不得不在數據安全和效果方面進行取舍。

RAG（Retrieve,Augment,Generate）****從名字就可以拆分出 RAG 的三大部分，檢索、增強、生成，表面意思就是：

1、去知識庫檢索相關的各種東西

2、把檢索出來的信息，融合到 prompt 中，增強輸入信息

3、最后是大模型生成更符合事實性的回答

RAG是解決上述問題的一套有效方案。具體如下：

• 實時數據接入：RAG通過檢索模塊，可以實時接入最新的數據源。例如，企業內部的實時業務數據、行業動態報告等，這些數據能夠及時補充到模型的知識體系中，使模型對最新情況有準確的認知，從而生成更貼合當下實際情況的內容。
• 幻覺問題的緩解：檢索驗證機制，在生成內容之前，RAG會先通過檢索模塊從大量數據中找到與問題相關的可靠信息。這些檢索到的信息為模型的生成提供了明確的依據和約束，使得模型的輸出不再是憑空臆造，而是基于真實可靠的外部數據。例如，在回答一個專業領域的問題時，模型會先檢索該領域的權威文獻或數據，然后結合這些信息生成答案，從而大大降低幻覺問題的發生概率。
• 數據隔離與本地化處理：在RAG架構中，私域數據的檢索和處理可以在本地進行，無需將數據上傳到第三方平臺。這樣可以有效避免數據在傳輸和存儲過程中的泄露風險。企業可以完全掌控自己的數據，確保數據的安全性和隱私性。同時，RAG可以與企業的安全系統集成，進一步加強數據的保護措施。

綜上所述，RAG通過其獨特的檢索與生成結合的架構，有效解決了通用大模型在實際業務應用中面臨的知識局限性、幻覺問題和數據安全等關鍵問題。它為企業提供了一種更加可靠、安全和高效的利用大模型能力的方式，能夠更好地滿足企業多樣化的業務需求，推動大模型在實際業務中的廣泛應用。

2 RAG的流程

2.1 RAG 的核心流程

完整的RAG應用流程主要包含兩個階段：

• 數據準備階段：
  • 數據提?。〝祿虞dLoad）——>文本分塊（Chunk）——>向量化（embedding）——>數據入庫（index）
• 應用階段：
  • 用戶提問(Vector)——>數據檢索（Retrieve）——>增強Prompt（Augment）——>LLM生成答案(Generate)

2.1.1 數據準備階段：

數據準備一般是一個離線的過程，主要是將私域數據向量化后構建索引并存入數據庫的過程。主要包括：數據提取、文本分割、向量化、數據入庫等環節。

數據提取

• 數據加載：涵蓋多格式數據的加載以及從不同數據源獲取數據。依據數據的特性，將其統一處理為一致的格式范式，以確保數據的一致性和可處理性。
• 數據處理：涉及數據的過濾、壓縮以及格式化等操作，旨在優化數據質量，去除無關信息，提升數據的可用性。
• 元數據獲?。簭臄祿刑崛￡P鍵信息，如文件名、標題（Title）、時間戳等，這些元數據有助于后續的數據管理和檢索。

文本分塊：主要考慮兩個關鍵因素：

• embedding模型的Tokens限制：不同embedding模型對輸入文本的長度（以Tokens為單位）有特定限制。
• 語義完整性對檢索效果的影響：分割后的文本片段應盡量保持語義完整性，以確保檢索結果的準確性和相關性。

常見的文本分割方式包括：

• 句分割：以句子為單位進行切分，確保每個句子的語義完整。常見的切分符號包括句號、感嘆號、問號、換行符等。
• 固定長度分割：根據embedding模型的token長度限制，將文本分割為固定長度（例如256或512個tokens）。這種分割方式可能會損失部分語義信息，通常通過在文本片段的開頭和結尾增加一定量的冗余內容來緩解這一問題。

當然也有其他的分塊方式：

向量化（embedding）：

向量化是一個將文本數據轉化為向量矩陣的過程，該過程會直接影響到后續檢索的效果。目前常見的embedding模型可以查看MTEB排行榜：https://huggingface.co/spaces/mteb/leaderboard

表中展示了常見的模型，這些embedding模型基本能滿足大部分需求，但對于特殊場景（例如涉及一些罕見專有詞或字等）或者想進一步優化效果，則可以選擇開源Embedding模型微調或直接訓練適合自己場景的Embedding模型。

模型名稱	描述
ChatGPT-Embedding	ChatGPT-Embedding 由 OpenAI 公司提供，以接口形式調用。
ERNIE-Embedding V1	ERNIE-Embedding V1 由百度公司提供，依賴于文心大模型能力，以接口形式調用。
M3E	M3E 是一款功能強大的開源 Embedding 模型，包含 m3e-small、m3e-base、m3e-large 等多個版本，支持微調和本地部署。
Qwen3 Embedding	由阿里巴巴通義實驗室推出的最新一代嵌入模型，專為處理文本語義表示而設計。
BGE	BGE 由北京智源人工智能研究院發布，同樣是一款功能強大的開源 Embedding 模型，包含了支持中文和英文的多個版本，同樣支持微調和本地部署。

數據入庫：

數據向量化后構建索引，并寫入數據庫的過程可以概述為數據入庫過程，適用于RAG場景的數據庫包括：FAISS、Chromadb、ES、milvus等。一般可以根據業務場景、硬件、性能需求等多因素綜合考慮，選擇合適的數據庫。

2.1.2 應用階段

在應用階段，我們根據用戶的提問，通過高效的檢索方法，召回與提問最相關的知識，并融入Prompt；大模型參考當前提問和相關知識，生成相應的答案。關鍵環節包括：數據檢索、增強Prompt等。

數據檢索里面有很多技術：比如數據檢索，重排，查詢轉換；

原始的RAG技術：

高級的RAG技術：

A 數據**檢索**：

**RAG 管道的關鍵部分是檢索**，它存儲了我們在上一步中獲得的向量化內容。最原始的實現是使用平面索引 — 查詢向量和所有塊向量之間的暴力計算距離。

為了實現1w+元素規模的高效檢索，搜索索引應該采用向量索引，比如 faiss、nmslib 以及 annoy。這些工具基于近似最近鄰居算法，如聚類、樹結構或HNSW算法。

此外，還有一些托管解決方案，如 OpenSearch、ElasticSearch 以及向量數據庫，它們自動處理上面提到的數據攝取流程，例如Pinecone、Weaviate和Chroma。

取決于你的索引選擇、數據和搜索需求，還可以存儲元數據，并使用元數據過濾器來按照日期或來源等條件進行信息檢索。

1，分層索引：在大型數據庫的情況下，一個有效的方法是創建兩個索引——一個由摘要組成，另一個由文檔塊組成，然后分兩步進行搜索，首先通過摘要過濾掉相關文檔，然后只在這個相關組內搜索。

2，假設性問題和 HyDE

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

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

還有一種叫做 HyDE 的反向邏輯方法——你要求 LLM 在給定查詢的情況下生成一個假設的響應，然后將其向量與查詢向量一起使用來提高搜索質量。

3， 內容增強

這里的內容是將相關的上下文組合起來供 LLM 推理，以檢索較小的塊以獲得更好的搜索質量。

有兩種選擇：一種是圍繞較小的檢索塊的句子擴展上下文，另一種是遞歸地將文檔拆分為多個較大的父塊，其中包含較小的子塊。

---

a 語句窗口檢索器

在此方案中，文檔中的每個句子都是單獨嵌入的，這為上下文余弦距離搜索提供了極大的查詢準確性。

為了在獲取最相關的單個句子后更好地推理找到的上下文，我們將上下文窗口擴展為檢索到的句子前后的 k 個句子，然后將這個擴展的上下文發送到 LLM。

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

b 自動合并檢索器（或父文檔檢索器)

這里的思路與語句窗口檢索器非常相似——搜索更精細的信息片段，然后在在LLM 進行推理之前擴展上下文窗口。文檔被拆分為較小的子塊，這些子塊和較大的父塊有引用關系。

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

c 融合檢索或混合搜索

這是一個很早以前的思路：結合傳統的基于關鍵字的搜索（稀疏檢索算法，如 tf-idf 或搜索行業標準 BM25）和現代語義或向量搜索，并將其結果組合在一個檢索結果中。

這里唯一的關鍵是如何組合不同相似度分數的檢索結果。這個問題通常通過 Reciprocal Rank Fusion 算法來解決，該算法能有效地對檢索結果進行重新排序，以得到最終的輸出結果。

在 LangChain 中，這種方法是通過 Ensemble Retriever 來實現的，該類將你定義的多個檢索器結合起來，比如一個基于 faiss 的向量索引和一個基于 BM25 的檢索器，并利用 RRF 算法進行結果的重排。

混合或融合搜索通常能提供更優秀的檢索結果，因為它結合了兩種互補的搜索算法——既考慮了查詢和存儲文檔之間的語義相似性，也考慮了關鍵詞匹配。

d 重排（reranking）和過濾（filtering）

我們使用上述任何算法獲得了檢索結果，現在是時候通過過濾、重排或一些轉換來完善它們了。在 LlamaIndex 中，有各種可用的后處理器，根據相似性分數、關鍵字、元數據過濾掉結果，或使用其他模型（如 LLM）、sentence-transformer 交叉編碼器，Cohere 重新排名接口或者基于元數據重排它們。

這是將檢索到的上下文提供給 LLM 以獲得結果答案之前的最后一步。

現在，我們將探索更高級的 RAG 技術，比如查詢轉換和路由。這些技術涉及到大語言模型的使用，代表了一種更復雜的邏輯思維——在 RAG 流程中融合了 LLM 的推理能力。

e 查詢轉換

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

對于復雜的查詢，大語言模型能夠將其拆分為多個子查詢。比如，

• 當你問：“在 Github 上，Langchain 和 LlamaIndex 這兩個框架哪個更受歡迎？”，

我們不太可能直接在語料庫找到它們的比較，所以將這個問題分解為兩個更簡單、具體的合理的子查詢：

• “Langchain 在 Github 上有多少星？”
• “Llamaindex 在 Github 上有多少星？”

這些子查詢會并行執行，檢索到的信息隨后被匯總到一個 LLM 提示詞中。這兩個功能分別在 Langchain 中以多查詢檢索器的形式和在 Llamaindex 中以子問題查詢引擎的形式實現。

1. Step-back prompting 使用 LLM 生成一個更通用的查詢，以此檢索到更通用或高層次的上下文，用于為我們的原始查詢提供答案。同時執行原始查詢的檢索，并在最終答案生成步驟中將兩個上下文發送到 LLM。這是 LangChain 的一個示例實現。
2. 查詢重寫使用 LLM 來重新表述初始查詢，以改進檢索。LangChain 和 LlamaIndex 都有實現，個人感覺LlamaIndex 解決方案在這里更強大。

f 聊天引擎

關于構建一個可以多次用于單個查詢的完美 RAG 系統的下一件工作是聊天邏輯，就像在 LLM 之前時代的經典聊天機器人中一樣考慮到對話上下文。

這是支持后續問題、代詞指代或與上一個對話上下文相關的任意用戶命令所必需的。它是通過查詢壓縮技術解決的，將聊天上下文與用戶查詢一起考慮在內。

與往常一樣，有幾種方法可以進行上述上下文壓縮——一個流行且相對簡單的 ContextChatEngine，首先檢索與用戶查詢相關的上下文，然后將其與內存緩沖區中的聊天記錄一起發送到 LLM，以便 LLM 在生成下一個答案時了解上一個上下文。

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

需要注意的是，LlamaIndex 中還支持基于 OpenAI 智能體的聊天引擎，提供更靈活的聊天模式，Langchain 還支持 OpenAI 功能 API。

g 查詢路由

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

查詢路由器還用于選擇數據存儲位置來處理用戶查詢。這些數據存儲位置可能是多樣的，比如傳統的向量存儲、圖形數據庫或關系型數據庫，或者是不同層級的索引系統。在處理多文檔存儲時，通常會用到摘要索引和文檔塊向量索引這兩種不同的索引。

定義查詢路由器包括設置它可以做出的選擇。

選擇特定路由的過程是通過大語言模型調用來實現的，其結果按照預定義的格式返回，以路由查詢指定的索引。如果是涉及到關聯操作，這些查詢還可能被發送到子鏈或其他智能體，如下面的多文檔智能體方案所展示的那樣。

LlamaIndex 和 LangChain 都提供了對查詢路由器的支持。

B 增強Prompt：

Prompt作為大模型的直接輸入，是影響模型輸出準確率的關鍵因素之一。在RAG場景中，Prompt一般包括任務描述、背景知識（檢索得到）、任務指令（一般是用戶提問）等，根據任務場景和大模型性能，也可以在Prompt中適當加入其他指令優化大模型的輸出。一個簡單知識問答場景的Prompt如下所示：

【任務描述】
假如你是一個專業的客服機器人，請參考【背景知識】，回
【背景知識】
{content} // 數據檢索得到的相關文本
【問題】
蘋果17的價格是多少？

C: Agentic RAG

智能體幾乎從第一個 LLM API 發布開始就已經存在——這個思路是為一個具備推理能力的 LLM 提供一套工具和一個要完成的任務。這些工具可能包括一些確定性功能，如任何代碼函數或外部 API，甚至是其他智能體——這種 LLM 鏈接思想是 LangChain 得名的地方。

智能體本身就是一個復雜的技術，不可能在 RAG 概述中深入探討該主題，所以我將繼續基于 agent 的多文檔檢索案例，并簡要提及 OpenAI 助手，因為它是一個相對較新的概念，在最近的 OpenAI 開發者大會上作為 GPTs 呈現，并在下文將要介紹的 RAG 系統中發揮作用。

OpenAI 助手基本上整合了開源 LLM 周邊工具——聊天記錄、知識存儲、文檔上傳界面。最重要的是函數調用 API， 其提供了將自然語言轉換為對外部工具或數據庫查詢的 API 調用的功能。

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

讓我們來看一下多文檔智能體的方案—— 這是一個非常復雜的配置，涉及到在每個文檔上初始化一個Agent（OpenAIAgent），該智能體能進行文檔摘要制作和傳統問答機制的操作，還有一個頂層智能體，負責將查詢分配到各個文檔智能體，并綜合形成最終的答案。

每個文檔智能體都有兩個工具：向量存儲索引和摘要索引，它根據路由查詢決定使用哪一個。對于頂級智能體來說，所有文檔智能體都是其工具。

該方案展示了一種高級 RAG 架構，其中每個智能體都做路由許多決策。這種方法的好處是能夠比較不同的解決方案或實體在不同的文檔及其摘要中描述，以及經典的單個文檔摘要和 QA 機制——這基本上涵蓋了最常見的與文檔集合聊天的用例。

這種復雜配置的缺點可以通過圖片發現 —— 由于需要在智能體內部的大語言模型之間進行多次往返迭代，其運行速度較慢。順便一提，LLM 調用通常是 RAG 管道中耗時最長的操作，而搜索則是出于設計考慮而優化了速度。因此，對于大型的多文檔存儲，我建議考慮對此方案進行簡化，以便實現擴展。

如下圖為一個文本到SQL的 RAG+混合agentic workflow：

2.2 RAG的工具

參考：

1，一文搞懂大模型RAG應用（附實踐案例）：https://zhuanlan.zhihu.com/p/668082024

2，RAG基礎框架http://www.rzrgm.cn/ExMan/p/18727189

3, 圖解高級RAG技術https://zhuanlan.zhihu.com/p/674755232

4，Advanced RAG Techniques: an Illustrated Overviewhttps://pub.towardsai.net/advanced-rag-techniques-an-illustrated-overview-04d193d8fec6