深入淺出從 RAG 到 Agentic RAG：AI 智能體如何重構檢索增強生成的技術閉環？
1. 引言
從2024年邁入2025年，AI領域的焦點正從檢索增強生成（RAG）轉向更具突破性的——具能動性RAG（Agentic RAG）。本文將為你介紹具能動性RAG的概念、實現方式及其優缺點。
圖片
1.1 具能動性RAG概述
檢索增強生成（RAG）是人工智能領域的重要進步，它將大型語言模型（LLM）的生成能力與實時數據檢索相結合。盡管LLM在自然語言處理中表現出色，但其依賴靜態預訓練數據的特性常導致響應過時或不完整。RAG通過從外部源動態檢索相關信息并融入生成過程，解決了這一局限，實現了上下文準確且實時更新的輸出。
1.2 RAG與具能動性RAG的對比
RAG系統的架構集成了三個主要組件：
- 檢索模塊：負責查詢知識庫、API或向量數據庫等外部數據源。高級檢索器利用密集向量搜索和基于Transformer的模型提升檢索精度和語義相關性。
- 增強模塊：處理檢索到的數據，提取并總結最相關信息以匹配查詢上下文。
- 生成模塊：將檢索信息與LLM的預訓練知識結合，生成連貫且符合上下文的響應。
圖片
圖片
具能動性RAG引入了使用AI智能體的自主決策與編排能力，支持更健壯靈活的檢索-生成工作流，其核心流程包括：
- 智能體導向的查詢分析：用戶查詢被路由至AI智能體，解析查詢意圖與上下文。
- 記憶與策略制定：智能體利用短期（會話）和長期（歷史）記憶跟蹤上下文，制定動態檢索與推理策略。
- 工具選擇與數據收集：智能體智能選擇工具（如向量搜索、API連接器或其他智能體），從相關知識庫（如MCP服務器、圖數據庫、文檔存儲）檢索數據。
- 提示詞構建：檢索內容與結構化上下文、系統指令結合，形成增強提示詞并傳遞給LLM。
- LLM響應生成：LLM處理優化后的上下文提示詞，生成高相關性、可解釋且自適應的響應。
2. RAG范式的演進
檢索增強生成（RAG）領域已顯著演進，以應對現實應用中日益增長的復雜性——上下文準確性、可擴展性和多步推理能力至關重要。從簡單的基于關鍵詞的檢索開始，RAG已發展為復雜、模塊化且自適應的系統，能夠集成多樣化數據源和自主決策流程。這一演進凸顯了RAG系統高效處理復雜查詢的迫切需求。
2.1 樸素RAG
樸素RAG是檢索增強生成的基礎實現，其核心是基于關鍵詞的檢索和靜態數據集的“檢索-讀取”工作流。這類系統依賴TF-IDF和BM25等簡單關鍵詞檢索技術從靜態數據集中獲取文檔，再利用檢索文檔增強語言模型的生成能力。
局限性：
- 缺乏上下文感知：依賴詞法匹配而非語義理解，導致檢索文檔常無法捕捉查詢的語義細微差別。
- 輸出碎片化：缺少高級預處理或上下文集成，易產生不連貫或過于泛化的響應。
- 可擴展性問題：基于關鍵詞的檢索技術在處理大規模數據集時，難以識別最相關信息。
圖片
2.2 高級RAG
高級RAG系統通過引入語義理解和增強檢索技術，彌補了樸素RAG的不足。這類系統利用密集檢索模型（如Dense Passage Retrieval, DPR）和神經排序算法提升檢索精度，實現語義增強的檢索和迭代式上下文感知流水線。
圖片
2.3 模塊化RAG
模塊化RAG代表了RAG范式的最新演進，強調靈活性和可定制性。該系統將檢索與生成流水線分解為獨立可復用的組件，支持領域特定優化和任務適應性，其架構包含混合檢索策略、可組合流水線和外部工具集成。
圖片
2.4 圖結構RAG
圖結構RAG通過集成圖數據結構擴展了傳統RAG系統，利用圖數據中的關系和層次結構增強多跳推理和上下文豐富性。通過引入圖檢索，圖結構RAG能生成更豐富準確的輸出，尤其適用于需要關系理解的任務（如醫療診斷、法律研究）。
圖片
局限性：
- 可擴展性有限：依賴圖結構可能限制大規模數據源的擴展。
- 數據依賴性：高質量圖數據是生成有意義輸出的關鍵，限制了其在非結構化或標注不良數據集中的應用。
- 集成復雜度：將圖數據與非結構化檢索系統集成增加了設計和實現難度。
圖片
2.5 具能動性RAG
具能動性RAG通過引入能夠動態決策和工作流優化的自主智能體，實現了范式轉換。與靜態系統不同，具能動性RAG采用迭代優化和自適應檢索策略，以處理復雜、實時和多領域的查詢。該范式在引入基于智能體的自主性的同時，利用了檢索和生成過程的模塊化特性。
圖片
3. 傳統RAG系統的挑戰與局限
盡管檢索增強生成（RAG）通過結合生成能力與實時數據提升了LLM性能，但在復雜現實場景中仍存在關鍵挑戰：
- 上下文集成難題：即使RAG系統成功檢索到相關信息，也常難以將其無縫融入生成響應。檢索流水線的靜態特性和有限的上下文感知能力，導致輸出碎片化、不一致或過于泛化。示例：當被問及“阿爾茨海默病研究的最新進展及其對早期治療的影響”時，RAG可能提取相關研究，但無法將這些發現轉化為患者護理的可操作見解。
- 多步推理缺失：復雜問題通常需要多步推理，但傳統RAG通常僅執行單跳檢索，缺乏深度綜合能力。示例：“歐洲可再生能源政策中有哪些經驗可應用于發展中國家，潛在經濟影響如何？”這類查詢需要結合政策數據、本地上下文和經濟預測，而RAG常無法將這些要素整合成連貫答案。
- 可擴展性與延遲問題：隨著外部數據增長，搜索和排序大規模數據集會降低響應速度，這對實時用例（如實時金融分析或客戶支持）構成挑戰。
4. 具能動性RAG的分類體系
4.1 單智能體具能動性RAG：路由型
單智能體具能動性RAG作為集中式決策系統，由單個智能體管理信息的檢索、路由和集成，適用于工具或數據源有限的場景。
工作流程：
- 查詢提交與評估：用戶提交查詢，協調智能體分析并確定合適的數據源。
- 知識源選擇：包括結構化數據庫（如PostgreSQL、MySQL）、語義搜索（如PDF、書籍）、網頁搜索和推薦系統。
- 數據集成與LLM綜合：檢索數據傳遞給LLM，生成連貫響應。
- 輸出生成：系統為用戶生成簡潔、可操作的響應。
圖片
4.2 多智能體具能動性RAG系統
多智能體系統中，多個專門智能體協同工作，每個智能體專注于特定數據源或任務，支持復雜查詢的可擴展、模塊化處理。
圖片
工作流程：
- 查詢提交：協調智能體接收查詢并分發給專門智能體。
- 專門檢索智能體：如處理結構化數據的智能體、語義搜索智能體、實時網頁搜索智能體等。
- 工具訪問與數據檢索：并行利用向量搜索、Text-to-SQL、網頁搜索和外部API。
- 數據集成與LLM綜合：聚合數據傳遞給LLM，生成全面輸出。
4.3 分層式具能動性RAG系統
分層系統采用結構化的多層方法處理信息檢索與流程，智能體按層級組織，高層智能體監督指導低層智能體，實現多級決策。
工作流程：
- 查詢接收：頂層智能體接收查詢并負責初始評估與任務分配。
- 戰略決策：頂層智能體評估查詢復雜度，根據領域相關性和數據可靠性選擇下屬智能體、數據庫或API。
- 任務委派：任務分配給專門的低層智能體，獨立執行檢索。
- 聚合與綜合：低層智能體將結果返回頂層智能體，集成綜合為統一響應。
4.4 具能動性糾正型RAG
糾正型RAG引入自我糾正機制，通過在工作流中嵌入智能體，迭代優化檢索結果，提升文檔利用率和響應質量。
工作流程：
- 上下文檢索智能體：從向量數據庫檢索初始上下文文檔。
- 相關性評估智能體：評估檢索文檔的相關性，標記不相關或模糊文檔。
- 查詢優化智能體：利用語義理解重寫和優化查詢，改善檢索結果。
- 外部知識檢索智能體：若上下文不足，執行網頁搜索或訪問替代數據源。
圖片
4.5 自適應具能動性RAG
自適應RAG通過基于查詢復雜度定制檢索策略，引入動態查詢處理能力，提升靈活性和效率。
圖片
核心邏輯：
- 簡單查詢：直接生成響應（如“水的沸點是多少？”）。
- 中等復雜查詢：單步檢索（如“我最新的電費賬單狀態如何？”）。
- 復雜查詢：多步檢索與迭代優化（如“城市X過去十年人口變化及其影響因素”）。
圖片
4.6 基于圖結構的具能動性RAG
4.6.1 Agent-G：圖結構RAG的具能動性框架
Agent-G引入新型架構，將圖知識庫與非結構化文檔檢索結合，提升RAG系統的推理和檢索精度，其核心包括圖知識庫、非結構化文檔處理、批評模塊和反饋循環。
4.6.2 GeAR：圖增強型具能動性RAG
GeAR通過集成圖結構檢索和智能體控制，增強傳統RAG，改善復雜查詢的多跳檢索能力，其核心是圖擴展模塊和基于智能體的檢索策略管理。
圖片
4.7 具能動性文檔工作流（ADW）
ADW通過在以文檔為中心的流程中編排端到端知識工作自動化，擴展傳統RAG，集成解析、檢索、推理和結構化輸出與智能體。
5. 具能動性RAG框架的對比分析
圖片
6. 構建具能動性RAG系統
本教程將構建一個檢索智能體，使LLM能夠決策是從向量存儲檢索上下文還是直接響應用戶。
圖片
6.1 文檔預處理
- 獲取文檔：使用
WebBaseLoader獲取Lilian Weng博客的最新頁面：
from langchain_community.document_loaders import WebBaseLoader
urls = [
"https://lilianweng.github.io/posts/2024-11-28-reward-hacking/",
"https://lilianweng.github.io/posts/2024-07-07-hallucination/",
"https://lilianweng.github.io/posts/2024-04-12-diffusion-video/",
]
docs = [WebBaseLoader(url).load() for url in urls]- 分割文檔：將文檔分割為小塊以便索引到向量存儲：
from langchain_text_splitters import RecursiveCharacterTextSplitter
docs_list = [item for sublist in docs for item in sublist]
text_splitter = RecursiveCharacterTextSplitter.from_tiktoken_encoder(
chunk_size=100, chunk_overlap=50
)
doc_splits = text_splitter.split_documents(docs_list)6.2 創建檢索工具
- 初始化向量存儲：使用內存向量存儲和OpenAI嵌入：
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_openai import OpenAIEmbeddings
vectorstore = InMemoryVectorStore.from_documents(
documents=doc_splits, embedding=OpenAIEmbeddings()
)
retriever = vectorstore.as_retriever()- 創建檢索工具：使用LangChain的
create_retriever_tool：
from langchain.tools.retriever import create_retriever_tool
retriever_tool = create_retriever_tool(
retriever,
"retrieve_blog_posts",
"Search and return information about Lilian Weng blog posts.",
)- 測試工具：
retriever_tool.invoke({"query": "types of reward hacking"})6.3 生成查詢
構建generate_query_or_respond節點，調用LLM基于當前圖狀態生成響應，決定是檢索還是直接響應：
from langgraph.graph import MessagesState
from langchain.chat_models import init_chat_model
response_model = init_chat_model("openai:gpt-4.1", temperature=0)
def generate_query_or_respond(state: MessagesState):
"""根據當前狀態調用模型生成響應，決定檢索或直接回答。"""
response = (
response_model
.bind_tools([retriever_tool]).invoke(state["messages"])
)
return {"messages": [response]}6.4 文檔評分
在構建智能體增強檢索生成（Agentic RAG）系統時，文檔評分是關鍵環節，它能評估檢索結果的相關性并決定后續處理流程。以下是具體實現步驟及代碼解析：
6.4.1 添加條件邊：文檔相關性評估
我們需要創建一個條件邊grade_documents，通過結構化輸出模型判斷檢索文檔是否與用戶問題相關。該函數會根據評分結果決定下一步操作（生成答案或重寫問題）。
代碼實現：
from pydantic import BaseModel, Field
from typing import Literal
# 定義文檔評分提示詞，用于評估檢索文檔與問題的相關性
GRADE_PROMPT = (
"你是一個評分器，負責評估檢索到的文檔與用戶問題的相關性。\n"
"以下是檢索到的文檔：\n\n{context}\n\n"
"以下是用戶問題：{question}\n"
"如果文檔包含與用戶問題相關的關鍵詞或語義含義，則評為相關。\n"
"請給出二進制評分'yes'或'no'，表示文檔是否與問題相關。"
)
# 定義結構化輸出模型，用于規范評分結果格式
class GradeDocuments(BaseModel):
"""使用二進制評分檢查文檔相關性"""
binary_score: str = Field(
descriptinotallow="相關性評分：'yes'表示相關，'no'表示不相關"
)
# 初始化評分模型（使用GPT-4.1，溫度系數為0以保證確定性）
grader_model = init_chat_model("openai:gpt-4.1", temperature=0)
def grade_documents(
state: MessagesState,
) -> Literal["generate_answer", "rewrite_question"]:
"""判斷檢索到的文檔是否與問題相關"""
question = state["messages"][0].content # 提取用戶問題
context = state["messages"][-1].content # 提取檢索到的文檔內容
# 格式化提示詞，傳入問題和文檔內容
prompt = GRADE_PROMPT.format(questinotallow=question, cnotallow=context)
# 調用評分模型，使用結構化輸出解析結果
response = (
grader_model
.with_structured_output(GradeDocuments).invoke(
[{"role": "user", "content": prompt}]
)
)
score = response.binary_score # 提取評分結果
if score == "yes":
return"generate_answer"# 相關則進入答案生成環節
else:
return"rewrite_question"# 不相關則重寫問題6.4.2 測試：不相關文檔的評分流程
通過模擬不相關的檢索結果，驗證評分函數是否能正確識別并觸發重寫問題邏輯。
代碼實現：
from langchain_core.messages import convert_to_messages
# 構造測試輸入：用戶問題、檢索工具調用、不相關的工具響應（"meow"）
input = {
"messages": convert_to_messages(
[
{
"role": "user",
"content": "Lilian Weng 對獎勵黑客的類型有什么看法？",
},
{
"role": "assistant",
"content": "",
"tool_calls": [
{
"id": "1",
"name": "retrieve_blog_posts",
"args": {"query": "types of reward hacking"},
}
],
},
{"role": "tool", "content": "meow", "tool_call_id": "1"},
]
)
}
# 調用文檔評分函數，查看返回的下一步操作
grade_documents(input) # 應返回"rewrite_question"6.4.3 測試：相關文檔的評分流程
使用包含正確信息的檢索結果，驗證評分函數是否能正確識別并允許生成答案。
代碼實現：
# 構造測試輸入：用戶問題、檢索工具調用、相關的工具響應（包含獎勵黑客類型的描述）
input = {
"messages": convert_to_messages(
[
{
"role": "user",
"content": "Lilian Weng 對獎勵黑客的類型有什么看法？",
},
{
"role": "assistant",
"content": "",
"tool_calls": [
{
"id": "1",
"name": "retrieve_blog_posts",
"args": {"query": "types of reward hacking"},
}
],
},
{
"role": "tool",
"content": "獎勵黑客可分為兩類：環境或目標指定錯誤，以及獎勵篡改",
"tool_call_id": "1",
},
]
)
}
# 調用文檔評分函數，查看返回的下一步操作
grade_documents(input) # 應返回"generate_answer"6.4.4 核心邏輯解析
- 評分機制：通過提示詞引導模型分析文檔與問題的語義相關性，使用二進制評分（yes/no）簡化決策流程。
- 結構化輸出：利用Pydantic模型
GradeDocuments確保評分結果格式統一，避免非結構化文本導致的解析錯誤。 - 動態路由：根據評分結果決定流程走向：
若相關（yes），進入generate_answer生成最終回答；
若不相關（no），進入rewrite_question優化查詢語句，避免無效檢索。
6.4.5 實際應用優化建議
- 評分提示詞優化：可根據領域特性調整提示詞，例如在醫療場景中加入專業術語匹配規則。
- 多輪評分機制：對于復雜問題，可引入多輪評分（如結合TF-IDF權重和語義相似度），降低誤判率。
- 人工反饋集成：在生產環境中，可收集人工標注數據微調評分模型，提升長期準確性。
通過文檔評分環節，Agentic RAG系統能夠自主過濾無效信息，確保后續生成的回答基于高質量上下文，這是區別于傳統RAG系統的核心能力之一。
6.5 重寫問題
在智能體增強檢索生成（Agentic RAG）系統中，當檢索工具返回不相關文檔時，需要通過重寫問題來優化查詢邏輯。這一環節能有效提升檢索準確性，避免因原始問題表述模糊導致的無效響應。以下是具體實現步驟及代碼解析：
6.5.1 構建rewrite_question節點
該節點的核心功能是基于原始用戶問題生成更精準的查詢語句，引導檢索工具獲取相關信息。通過調用語言模型，系統能理解問題的深層語義意圖，并重新組織表述方式。
代碼實現：
# 定義問題重寫提示詞，引導模型分析問題語義并優化表述
REWRITE_PROMPT = (
"請分析輸入內容，推理其潛在的語義意圖/含義。\n"
"以下是初始問題：\n"
"------- \n"
"{question}"
"\n ------- \n"
"請構建一個優化后的問題："
)
def rewrite_question(state: MessagesState):
"""重寫原始用戶問題，提升檢索相關性"""
messages = state["messages"] # 獲取對話狀態中的消息列表
question = messages[0].content # 提取用戶的原始問題
# 格式化提示詞，傳入原始問題
prompt = REWRITE_PROMPT.format(questinotallow=question)
# 調用語言模型生成優化后的問題
response = response_model.invoke([{"role": "user", "content": prompt}])
# 返回重寫后的問題，更新對話狀態
return {"messages": [{"role": "user", "content": response.content}]}6.5.2 功能測試：重寫問題流程演示
通過模擬不相關檢索結果的場景，驗證rewrite_question節點是否能生成更精準的查詢語句。
代碼實現：
# 構造測試輸入：用戶問題、檢索工具調用、不相關的工具響應（"meow"）
input = {
"messages": convert_to_messages(
[
{
"role": "user",
"content": "Lilian Weng 對獎勵黑客的類型有什么看法？",
},
{
"role": "assistant",
"content": "",
"tool_calls": [
{
"id": "1",
"name": "retrieve_blog_posts",
"args": {"query": "types of reward hacking"},
}
],
},
{"role": "tool", "content": "meow", "tool_call_id": "1"},
]
)
}
# 調用問題重寫函數
response = rewrite_question(input)
# 打印重寫后的問題
print("重寫后的問題：")
print(response["messages"][-1]["content"])6.5.3 核心邏輯解析
- 語義理解：通過提示詞引導語言模型分析原始問題的深層意圖，而非僅關注表面關鍵詞。例如，將“獎勵黑客的類型”理解為“分類方式”或“具體類別”。
- 表述優化：模型會將模糊或歧義的問題轉化為更精準的查詢。例如，將“什么看法”轉化為“如何分類”或“包含哪些類型”。
- 流程閉環：重寫后的問題會重新觸發檢索流程，形成“查詢優化-重新檢索”的閉環，確保系統能自主修正檢索方向。
6.5.4 實際應用優化建議
- 領域特定提示詞：針對不同場景（如醫療、法律）定制重寫提示詞，融入領域術語。例如，在法律場景中，將“合同問題”重寫為“合同條款爭議類型”。
- 用戶意圖聚類：通過歷史對話數據聚類用戶意圖，預定義常見問題的優化模板，提升重寫效率。
- 多輪重寫機制：對于復雜問題，可設置多輪重寫（如首次重寫聚焦語義，二次重寫補充限定條件），逐步縮小檢索范圍。
6.5.5 示例：重寫效果演示
原始問題：“Lilian Weng 對獎勵黑客的類型有什么看法？”不相關檢索結果：“meow”（模擬無效數據）重寫后問題（可能輸出）：“Lilian Weng 論文中提到的獎勵黑客分類方式有哪些？”
通過添加“論文中提到的”限定條件，明確了信息來源，同時將“類型”轉化為“分類方式”，更符合學術文獻的表述習慣，從而提升后續檢索的相關性。
問題重寫是Agentic RAG系統實現自主優化的關鍵環節，它賦予系統“反思”和“調整”的能力，避免傳統RAG中“錯誤查詢-無效結果”的死循環。
6.6 生成答案
在智能體增強檢索生成（Agentic RAG）系統中，當檢索文檔通過相關性評分后，需要基于用戶問題和檢索內容生成最終回答。這一環節要求語言模型（LLM）不僅能整合信息，還能以自然、簡潔的方式呈現結果。以下是具體實現步驟及代碼解析：
6.6.1 構建generate_answer節點
該節點的核心功能是根據用戶問題和檢索到的上下文生成回答。通過定制提示詞，引導模型提煉關鍵信息并控制輸出長度，確?；卮鸷啙嵡覝蚀_。
代碼實現：
# 定義答案生成提示詞，引導模型基于上下文回答問題
GENERATE_PROMPT = (
"你是一個問答助手。請使用以下檢索到的上下文回答問題。"
"如果不知道答案，請直接說明不知道。"
"最多使用三個句子，保持回答簡潔。\n"
"問題：{question} \n"
"上下文：{context}"
)
def generate_answer(state: MessagesState):
"""基于用戶問題和檢索上下文生成最終答案"""
question = state["messages"][0].content # 提取用戶問題
context = state["messages"][-1].content # 提取檢索到的上下文內容
# 格式化提示詞，傳入問題和上下文
prompt = GENERATE_PROMPT.format(questinotallow=question, cnotallow=context)
# 調用語言模型生成回答
response = response_model.invoke([{"role": "user", "content": prompt}])
# 返回生成的答案，更新對話狀態
return {"messages": [response]}6.6.2 功能測試：答案生成流程演示
通過模擬相關檢索結果的場景，驗證generate_answer節點是否能正確整合信息并生成有效回答。
代碼實現：
# 構造測試輸入：用戶問題、檢索工具調用、相關的工具響應（包含獎勵黑客類型的描述）
input = {
"messages": convert_to_messages(
[
{
"role": "user",
"content": "Lilian Weng 對獎勵黑客的類型有什么看法？",
},
{
"role": "assistant",
"content": "",
"tool_calls": [
{
"id": "1",
"name": "retrieve_blog_posts",
"args": {"query": "types of reward hacking"},
}
],
},
{
"role": "tool",
"content": "reward hacking can be categorized into two types: environment or goal misspecification, and reward tampering",
"tool_call_id": "1",
},
]
)
}
# 調用答案生成函數
response = generate_answer(input)
# 打印生成的答案
print("生成的答案：")
response["messages"][-1].pretty_print()6.6.3 核心邏輯解析
- 信息整合：模型會從上下文中提取與問題相關的關鍵信息。例如，從“兩類：環境或目標指定錯誤、獎勵篡改”中提煉分類結果。
- 格式控制：通過提示詞限定回答長度（最多三句話），避免生成冗長或無關內容，提升信息密度。
- 不確定性處理：若上下文缺乏足夠信息，模型會遵循提示詞要求，直接說明“不知道”，避免虛構答案。
6.6.4 實際應用優化建議
- 回答風格定制：根據應用場景調整提示詞，例如：
客服場景：“請用口語化表達，分點說明解決方案”
學術場景：“請引用上下文觀點，并補充相關研究背景”
- 證據溯源機制：在回答中加入上下文引用標記（如“根據文檔第3段”），提升回答可信度。
- 多輪生成優化：對于復雜問題，可先生成草稿回答，再通過提示詞優化表述（如“將技術術語轉化為通俗語言”）。
6.6.5 示例：答案生成效果
用戶問題：“Lilian Weng 對獎勵黑客的類型有什么看法？”檢索上下文：“獎勵黑客可分為兩類：環境或目標指定錯誤，以及獎勵篡改?！?/span>生成答案：
Lilian Weng將獎勵黑客分為兩類：環境或目標指定錯誤，以及獎勵篡改。她認為獎勵黑客是一個更廣泛的概念，其中包含了獎勵篡改。部分研究將獎勵篡改單獨定義，但Weng將其歸為獎勵黑客的范疇。該回答不僅整合了上下文的分類信息，還補充了概念范疇的說明，符合“三句話內簡潔回答”的要求，同時保持了學術表述的嚴謹性。
答案生成是Agentic RAG系統的最終輸出環節，其質量直接影響用戶體驗。通過精準的提示詞設計和模型調用，系統能將檢索到的碎片化信息轉化為結構化回答。
6.7 組裝圖結構
在完成文檔預處理、檢索工具創建、查詢生成、文檔評分、問題重寫和答案生成等核心組件后，需要將這些功能模塊組裝成一個完整的圖結構工作流。通過狀態圖（StateGraph）的形式，Agentic RAG系統能夠實現組件間的動態路由和條件跳轉，形成自主決策的檢索-生成閉環。以下是具體實現步驟及架構解析：
6.7.1 構建狀態圖工作流
使用LangGraph框架的StateGraph類定義組件間的連接關系，通過條件邊實現基于規則的流程控制。以下是完整的圖結構組裝代碼：
代碼實現：
from langgraph.graph import StateGraph, START, END
from langgraph.prebuilt import ToolNode
from langgraph.prebuilt import tools_condition
# 初始化狀態圖，指定狀態類型為MessagesState（包含對話消息列表）
workflow = StateGraph(MessagesState)
# 添加核心功能節點
workflow.add_node(generate_query_or_respond) # 查詢生成/響應節點
workflow.add_node("retrieve", ToolNode([retriever_tool])) # 檢索工具節點
workflow.add_node(rewrite_question) # 問題重寫節點
workflow.add_node(generate_answer) # 答案生成節點
# 定義起始節點到查詢生成節點的連接
workflow.add_edge(START, "generate_query_or_respond")
# 添加條件邊：根據查詢生成節點的輸出決定是否調用檢索工具
workflow.add_conditional_edges(
"generate_query_or_respond",
# 使用tools_condition函數判斷是否需要調用工具
tools_condition,
{
"tools": "retrieve", # 如需調用工具則跳轉至檢索節點
END: END # 如直接響應則結束流程
},
)
# 添加檢索節點后的條件邊：根據文檔評分結果決定下一步
workflow.add_conditional_edges(
"retrieve",
# 調用grade_documents函數評估文檔相關性
grade_documents,
{
"generate_answer": "generate_answer", # 相關則生成答案
"rewrite_question": "rewrite_question"# 不相關則重寫問題
},
)
# 添加最終節點連接
workflow.add_edge("generate_answer", END) # 答案生成后結束流程
workflow.add_edge("rewrite_question", "generate_query_or_respond") # 重寫問題后重新生成查詢
# 編譯狀態圖為可執行的工作流
graph = workflow.compile()6.7.2 圖結構可視化
通過Mermaid語法繪制狀態圖，直觀展示組件間的交互邏輯。以下是生成可視化圖像的代碼：
代碼實現：
from IPython.display import Image, display
# 生成狀態圖的Mermaid格式并轉換為PNG圖像
display(Image(graph.get_graph().draw_mermaid_png()))6.7.3 圖結構核心組件解析
- 節點類型：
- 生成查詢/響應節點（
generate_query_or_respond）：決定是否調用檢索工具或直接回答。 - 檢索節點（
retrieve）：調用向量數據庫獲取相關文檔。 - 問題重寫節點（
rewrite_question）：優化查詢語句。 - 答案生成節點（
generate_answer）：整合信息生成回答。
- 邊的類型：
tools_condition：根據LLM是否返回工具調用指令決定是否檢索。grade_documents：根據文檔相關性評分決定生成答案或重寫問題。- 無條件邊（
add_edge）：固定流程跳轉（如起始節點到查詢生成節點）。 - 條件邊（
add_conditional_edges）：
- 狀態流轉邏輯：
graph TD
START --> generate_query_or_respond
generate_query_or_respond -->|需要工具| retrieve
generate_query_or_respond -->|直接響應| END
retrieve -->|文檔相關| generate_answer
retrieve -->|文檔不相關| rewrite_question
rewrite_question --> generate_query_or_respond
generate_answer --> END6.7.4 動態路由機制詳解
- 工具調用判斷：
tools_condition函數會檢查LLM輸出中是否包含tool_calls字段。若有，則觸發檢索工具；若無，則直接生成回答。 - 文檔相關性決策：
grade_documents函數根據評分結果（yes/no）決定流程走向，形成“檢索-評估-修正”的閉環。 - 重寫優化循環：當文檔不相關時，系統通過
rewrite_question節點優化查詢，再重新進入檢索流程，避免重復無效檢索。
6.7.5 實際應用架構優化建議
- 分層圖結構設計：對于復雜場景（如多數據源檢索），可采用分層架構，將節點按“策略層-執行層-優化層”分組，提升可維護性。
- 并行檢索節點：在多智能體場景中，可添加并行檢索節點（如同時查詢內部知識庫和外部API），通過聚合節點合并結果。
- 超時熔斷機制：在檢索節點中加入超時控制，當響應時間超過閾值時自動觸發備用流程（如使用緩存數據或降級回答）。
6.7.6 圖結構的核心優勢
- 可視化流程管理：通過狀態圖可直觀監控系統運行路徑，便于調試和優化。
- 可擴展性：新增功能（如多模態檢索）時，只需添加新節點并定義邊的連接規則，無需修改現有邏輯。
- 故障定位：當輸出異常時，可通過狀態圖追溯具體節點的輸入輸出，快速定位問題環節。
圖片
狀態圖的組裝標志著Agentic RAG系統從組件開發進入整體集成階段。通過圖結構的動態路由能力，系統能夠像人類一樣自主規劃檢索策略、修正查詢方向并生成回答。
6.8 運行智能體RAG
在完成智能體增強檢索生成（Agentic RAG）系統的圖結構組裝后，需要通過實際案例演示完整工作流的執行過程。以下將通過模擬用戶查詢場景，展示系統如何從問題分析、文檔檢索、內容評估到最終答案生成的全流程自主決策能力，并解析關鍵環節的運行機制。
6.8.1 全流程運行演示
通過graph.stream()方法啟動流式運行，實時觀察每個節點的輸出和狀態流轉。以下是完整的運行代碼及輸出解析：
代碼實現：
# 定義用戶查詢：關于Lilian Weng對獎勵黑客類型的觀點
user_query = "What does Lilian Weng say about types of reward hacking?"
# 啟動流式運行，獲取每個節點的實時輸出
for chunk in graph.stream(
{
"messages": [
{
"role": "user",
"content": user_query
}
]
}
):
for node, update in chunk.items():
print(f"【節點輸出：{node}】")
print("-" * 50)
# 解析消息內容，區分AI回復、工具調用等類型
messages = update["messages"]
for msg in messages:
if msg.role == "assistant"and msg.tool_calls:
# 處理工具調用指令
tool_call = msg.tool_calls[0]
print(f"AI決策：調用工具 {tool_call.name}")
print(f"工具參數：{tool_call.args}")
elif msg.role == "tool":
# 處理工具返回結果
print(f"工具響應：{msg.content[:100]}...") # 截斷長內容便于展示
else:
# 處理最終答案
print(f"最終回答：{msg.content}")
print("\n" + "=" * 60 + "\n")6.8.2 運行流程分步解析
第一步：查詢生成節點（generate_query_or_respond）
【節點輸出：generate_query_or_respond】
--------------------------------------------------
AI決策：調用工具 retrieve_blog_posts
工具參數：{'query': 'types of reward hacking'}
==================================================- 核心邏輯：系統分析用戶問題后，判斷需要調用檢索工具（
retrieve_blog_posts），并生成關鍵詞查詢“types of reward hacking”。 - 決策依據：用戶問題涉及特定領域知識（Lilian Weng的研究），需外部文檔支持，因此觸發工具調用。
第二步：檢索節點（retrieve）
【節點輸出：retrieve】
--------------------------------------------------
工具響應：Detecting Reward Hacking#In-Context Reward Hacking#...（截斷顯示）
==================================================- 核心邏輯：檢索工具根據查詢詞從向量數據庫中獲取相關文檔，返回包含“獎勵黑客分類”的內容片段。
- 關鍵信息：文檔中明確提到“獎勵黑客可分為兩類：環境或目標指定錯誤（environment or goal misspecification）和獎勵篡改（reward tampering）”。
第三步：文檔評分節點（grade_documents）
- 隱式執行：在圖結構中，檢索節點輸出后自動觸發
grade_documents評分，判斷文檔是否相關。 - 評分結果：文檔包含用戶問題的關鍵詞（“types”“categorized”），評分結果為“yes”，流程跳轉至答案生成節點。
第四步：答案生成節點（generate_answer）
【節點輸出：generate_answer】
--------------------------------------------------
最終回答：Lilian Weng categorizes reward hacking into two types: environment or goal misspecification, and reward tampering. She considers reward hacking as a broader concept that includes both of these categories. Some work defines reward tampering separately, but Weng includes it under the umbrella of reward hacking.
==================================================- 核心邏輯：系統基于用戶問題和檢索到的上下文，生成結構化回答，明確分類內容并補充概念范疇說明。
- 格式控制：回答符合提示詞要求的“三句話限制”，同時保持學術表述的嚴謹性。
6.8.3 全流程狀態圖追溯
- 關鍵跳轉：
起始節點→查詢生成節點：觸發工具調用決策。
檢索節點→答案生成節點：因文檔評分“相關”，跳過問題重寫環節。
6.8.4 異常場景模擬：文檔不相關時的流程
若檢索工具返回不相關內容（如“meow”），系統會進入問題重寫流程：
# 模擬不相關檢索結果的運行（簡化輸出）
for chunk in graph.stream({...}):
# 第一步：同上，調用檢索工具
# 第二步：工具返回不相關內容
【節點輸出：retrieve】
工具響應：meow
==================================================
# 第三步：文檔評分結果為“no”，跳轉至問題重寫節點
【節點輸出：rewrite_question】
重寫后的問題：What specific categories of reward hacking are discussed in Lilian Weng's research papers?
==================================================
# 第四步：重新進入查詢生成節點，觸發二次檢索
【節點輸出：generate_query_or_respond】
AI決策：調用工具 retrieve_blog_posts
工具參數：{'query': 'Lilian Weng reward hacking categories research papers'}
==================================================
# 第五步：檢索到相關文檔，生成答案
【節點輸出：generate_answer】
最終回答：...（同正常流程）- 核心機制：通過“檢索-評估-重寫”的閉環，系統能自主修正查詢策略，提升檢索成功率。
6.8.5 性能優化與監控建議
- 實時日志追蹤：在生產環境中，可記錄每個節點的輸入輸出、處理耗時及決策依據，便于后續分析優化。
- 緩存機制：對高頻查詢的檢索結果和答案進行緩存，當相同問題再次出現時直接返回緩存結果，降低延遲。
- 資源監控：監控向量數據庫查詢耗時、LLM調用頻率等指標，設置閾值觸發告警（如檢索超時、成本超限）。
6.8.6 Agentic RAG的核心價值體現
- 自主決策能力：系統能根據實時反饋動態調整檢索策略，無需人工干預。
- 上下文連貫性：通過狀態圖維護對話歷史，確保多輪交互中檢索策略的一致性（如持續優化同一問題）。
- 錯誤容錯機制：當檢索失敗時，自動觸發問題重寫等補救措施，提升系統魯棒性。
運行智能體RAG標志著從理論架構到實際應用的落地。通過上述案例可以看到，Agentic RAG系統不僅能完成“檢索-生成”的基礎任務，還具備類似人類的“反思-修正”能力。
