RAG 徹底爆了！一文讀懂其架構演進及核心要點

本文系統梳理了檢索增強生成（RAG）架構的演進歷程，從基礎架構到智能化解決方案的迭代路徑。文章通過對比 Naive RAG、Advanced RAG、Modular RAG 和 Agentic RAG 四代架構的核心特點與技術突破，揭示了 RAG 技術如何通過模塊化設計、智能體協同等創新解決知識更新、語義對齊和複雜任務處理等關鍵問題，爲 LLM 應用落地提供重要參考。由於作者水平有限，若相關理解有誤請以實際爲準。

01 引言

1.1 什麼是 RAG（維基）

檢索增強生成（英語：Retrieval-augmented generation, RAG ) 是賦予生成式人工智能模型信息檢索能力的技術。檢索增強生成優化大型語言模型 (LLM) 的交互方式，讓模型根據指定的一組文件迴應用戶的查詢，並使用這些信息增強模型從自身龐大的靜態訓練數據中提取的信息。檢索增強生成技術促使大型語言模型能夠使用特定領域或更新後的信息。應用案例，包括讓聊天機器人訪問公司內部資料，或來自權威來源的事實信息。

簡易 RAG 流程

元寶 RAG 示例

1.2 爲什麼需要 RAG

1、LLM 的已知問題

RAG 是解決上述問題的一種比較輕量的解決方案。

2、RAG 優點

3、RAG 缺點

02 RAG 演變流程

Navie RAG -> Advanced RAG -> Modular RAG -> Agentic RAG

2.1 Navie RAG

2.1.1 來源

最早由 meta 在論文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出，提出的原因爲: 大規模預訓練語言模型（LLM）雖在下游任務上表現優異，但由於知識存儲在參數中，無法及時更新且易出現 “幻覺”（hallucination）；爲此，引入外部可檢索的非參數化記憶（如 Wikipedia 向量索引），並將檢索結果與生成模型結合，從而提升知識密集型任務的準確性與可追溯性。

2.1.2 介紹

最簡單的架構，只包含 3 個階段：Indexing -> Retrieval -> Generation.

流程

1、索引構建 (離線)

2、在線檢索（在線）

缺點

2.2 Advanced RAG

2.2.1 來源

沒有明確的提出者，在 Navie RAG 架構之後由多方逐步演進得到，如微軟研究院提出 HyDE，谷歌引入 Rerank，以及如 Elastic 和 Cohere 公司提出的各種優化技術等，由多方共同構成 Advanced RAG 技術體系. 這些優化技術提出的動因，主要是由於 Navie RAG 仍存在一系列問題，如

2.2.2 介紹

基於 Navie Rag 增加兩個步驟，包含 5 個階段：Indexing -> Pre Retrieval -> Retrievel -> Post Retrievel -> Generation，旨在解決文檔召回的質量和準確率。Navie RAG 屬於 Advanced Rag 的一個特化，即 Pre Retrievel 和 Post Retrievel 爲空。

1、Pre-Retrieval

預檢索處理: 側重數據索引優化。

2、Post-Retrievel

後檢索處理: 側重數據結果的二次加工 & 過濾

2.3 Modular RAG

2.3.1 來源

Modular RAG 最早由 Yunfan Gao 等人在 2024 年 7 月的論文《Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks》中首次系統化提出。提出的動因有:

  1. RAG 系統日漸複雜：傳統 RAG 線性結構難以應對更復雜的需求，需要合理抽象及規劃，否則系統維護困難。

  2. 提升可重用性及維護，快速迭代：將各個環節抽象成一個個的可插拔模塊，便於 RAG 系統引入新的算法或計算策略。

對比 Advanced RAG 架構，該框架將系統各個部分抽象單獨的模塊與算子，實現模塊可複用，易擴展及維護的 RAG 架構。

2.3.2 介紹

Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks

模塊化 RAG，將 RAG 系統分爲 Module Type、Module 和 Operators 三層結構。每個 Module Type 代表 RAG 系統中的一個核心流程，包含多個功能模塊。每個功能模塊反過來都包含多個特定的運算符。整個 RAG 系統變成了多個模塊和相應運算符的排列組合，形成了我們所說的 RAG Flow。整體有 7 個部分：Indexing, Pre Retrieval, Retrievel, Post Retrievel, Memory, Generation, Orchestration. 這種範式在基於 Advanced RAG 的橫向架構上引入了縱向的結構，即 Module 和 Operators。

Orchestration 是 Modular RAG 區分 Advanced RAG 的一個重要部分，而 Memory 模塊雖然在原論文沒有提及，但筆者認爲也是 Modular RAG 的一個重要組成部分，用於賦予 RAG 系統的長期記憶能力

def _cosine_similarity(query_vec, doc_vec):  # 操作符
    return np.dot(query_vec, doc_vec) / (np.linalg.norm(query_vec)*np.linalg.norm(doc_vec))

關鍵區別

Modular Rag 舉個例子

1、代碼示例，使用 haystack 官方示例。

Haystack 是一個開源框架，用於邊界構建 LLM 應用程序，框架整體採用 “節點 + 流水線” 架構，允許開發者通過自由組合預構建組件（如檢索器、生成器、評估器）構建定製化管道工作流。

##################
### 0. 組件定義 ###
##################
from haystack import Document, Pipeline
from haystack.document_stores.in_memory import InMemoryDocumentStore
from haystack.components.embedders import SentenceTransformersTextEmbedder
from haystack.components.retrievers.in_memory import InMemoryEmbeddingRetriever
document_store = InMemoryDocumentStore(embedding_similarity_function="cosine")
text_embedder = SentenceTransformersTextEmbedder()
retriever = InMemoryEmbeddingRetriever(document_store=document_store)
##################
### 1. 添加組件 ###
##################
query_pipeline = Pipeline()
query_pipeline.add_component("component_name", component_type)
# Here is an example of how you'd add the components initialized in step 2 above:
query_pipeline.add_component("text_embedder", text_embedder)
query_pipeline.add_component("retriever", retriever)
# You could also add components without initializing them before:
query_pipeline.add_component("text_embedder", SentenceTransformersTextEmbedder())
query_pipeline.add_component("retriever", InMemoryEmbeddingRetriever(document_store=document_store))
##################
### 2. 連接組件 ###
##################
# This is the syntax to connect components. Here you're connecting output1 of component1 to input1 of component2:
pipeline.connect("component1.output1", "component2.input1")
# If both components have only one output and input, you can just pass their names:
pipeline.connect("component1", "component2")
# If one of the components has only one output but the other has multiple inputs,
# you can pass just the name of the component with a single output, but for the component with
# multiple inputs, you must specify which input you want to connect
# Here, component1 has only one output, but component2 has mulitiple inputs:
pipeline.connect("component1", "component2.input1")
# And here's how it should look like for the semantic document search pipeline we're using as an example:
pipeline.connect("text_embedder.embedding", "retriever.query_embedding")
# Because the InMemoryEmbeddingRetriever only has one input, this is also correct:
pipeline.connect("text_embedder.embedding", "retriever")

2、可視化示例，使用 LangFlow。

Modular RAG 下的 RAG 流

各個模塊之間的協作，可以有類似以下的工作流模式串聯

1、線性編排 (Linear Pattern)

整個 RAG 流由各個 Module 線性串聯起來，爲最簡單的模式。

2、條件編排 (Conditional Pattern)

RAG 流中會添加一些 Route 條件判斷，增強系統的靈活性。

3、分支 (並行) 編排(Branching)

RAG 流中存在多個並行的分支，各自處理後隨之合併到一起，這種情況多用於要增加生成結果的多樣性而引入

4、循環編排 (Loop Pattern)

核心: 在每次迭代中，ITER-RETGEN 利用上一次迭代的模型輸出作爲特定上下文來幫助檢索更多相關知識。

HyDE(Hypothetical Document Embeddings), 即預先讓 LLM 生成用戶問題的答案，然後再用答案去知識庫檢索更大範圍內的內容，即提升 query 的泛化性
如: query: 如何提高睡眠質量, 但知識庫爲 “不喝咖啡，睡前不玩手機等” 內容，此時可以用 LLM 先生成簡單的答案，可能未“提升睡眠質量要避免咖啡因和電子設備等…”，此時可以檢索到對應文檔

澄清樹: 當初始查詢不明確時，通過遞歸迭代不斷生成多層子問題。
每次迭代檢索，會基於上一次迭代的輸入，檢索結果和生成內容，重新文檔 rerank，生成新的節點插入到樹中，達到一定深度或者節點樹後合併成一個全面的答案。

TOC RAG 流，一種 rescursive retrieval 的實現

Tree of Clarification

Interative 和 rescursive 的比較：

2.4 Agentic RAG

2.4.1 來源

最早 Chidaksh Ravuru 等人於 2024 年 8 月 18 日在 arXiv 上發表的論文《Agentic Retrieval-Augmented Generation for Time Series Analysis》中正式提出。 提出動因：

對比傳統 RAG, Agentic RAG 將能力依託於智能體，提升了 RAG 系統的靈活性及擴展其應用邊界。

2.4.2 介紹

Agentic RAG：架構上引入 Agent 的思路，實現動態決策（如是否檢索、工具調用）和多輪迭代優化。相比上述提到的幾種 RAG，Agentic RAG 將實際輸入處理的多樣性交給 LLM 處理，可以解決更復雜的問題。

Agent 的核心部件：LLM + Memory + Planning + Tools

如何運作?

從 Modular RAG 的架構來看，只要是涉及 LLM 的模塊理論上都可以使用 Agent 來增強，但在該 Agentic RAG 架構中更多強調的是在 retrievel 模塊中使用。 在檢索階段，不同數據源可以視作不同的 tool，然後由檢索 Agent 集成這些 tool 動態檢索內容

一些 Agent Agentic RAG 架構

分層代理 RAG，爲 Multi-Agent Agentic RAG 架構的拓展，將整個系統分爲多個層級的 Agent，由頂級 Agent 驅動子 Agent，並聚合子 Agent 的結果。

Corrective RAG 的核心是他可以動態評估檢索到的文檔並糾正查詢，提升檢索文檔的質量。

Agentic Corrective RAG 系統建立在 5 個關鍵 Agent 上。

  1. Context Retrieval Agent: 負責從數據庫中檢索相關上下文。

  2. Relevance Evaluation Agent: 負責評估檢索到的文檔的相關性，並標記出不相關或不明確文檔並採取糾正措施。

  3. Query Refinement Agent: 重寫 query 增強檢索的 Agent。

  4. External Knowledge Retrieval Agent: 當 Context Retrieval Agent 檢索的上下文不足時，從其他備用數據源檢索數據 (如 Web 檢索)。

  5. Response Synthesis Agent: 組織響應 Agent。

自適應 Agent RAG, 與上述 Modular RAG 中的 Adaptive retrieval 一樣，語義上都是在各個環節引入了 LLM 判斷，並在引入 LLM 評測實現 Loop 自迭代。

Graph-Based Agentic RAG 在檢索中引入了圖檢索，合併圖數據及其他檢索數據增強檢索效果

03 總結

R8pevG

04 一些思考

Reference

原創作者｜黃志傑

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/-0PmwBVvL2t3eYMrup6_vA

猜你喜歡