Skip to content
Agentic RAG:AI代理如何变革检索增强生成

Agentic RAG:AI代理如何变革检索增强生成

Updated on

标准RAG(检索增强生成)有一个根本性的局限:它只检索一次,生成一次。系统搜索向量数据库,获取Top-K个分块,将它们塞入提示词,然后期望答案在这些分块中。当相关信息分散在多个文档中、需要多步推理或需要在检索前进行澄清时,基本RAG会默默失败——返回听起来很有把握但基于不完整上下文的答案。

Agentic RAG通过用一个能够规划、迭代检索、评估结果并判断何时拥有足够信息来回答的自主AI代理来替代静态的检索-生成管道,解决了这个问题。代理不仅仅是获取文档——它会推理应该搜索什么,判断检索到的内容是否充分,并在不充分时采取额外行动。

📚

基本RAG vs Agentic RAG

基本RAG管道

用户查询 → 嵌入查询 → 向量搜索 → Top-K分块 → LLM → 回答

这种方法的问题:

  • 单次检索:如果第一次搜索错过了相关文档,没有恢复机制
  • 没有关于检索什么的推理:查询原样嵌入,没有分解
  • 没有评估:系统无法判断检索到的分块是否真正回答了问题
  • 没有多步检索:无法链接搜索,让第一个结果指导下一个查询

Agentic RAG管道

用户查询 → 代理规划 → 搜索工具 → 评估结果 →
  → 需要更多信息? → 优化查询 → 再次搜索 →
  → 足够的上下文? → 综合 → 回答

代理作为智能编排器,能够:

  1. 将复杂查询分解为子问题
  2. 选择工具:向量搜索、网络搜索、SQL查询、API调用
  3. 评估检索到的上下文是否充分
  4. 用优化的查询迭代直到有信心
  5. 综合来自多轮检索的信息

Agentic RAG的工作原理

核心架构

组件基本RAGAgentic RAG
查询处理直接嵌入查询分解与规划
检索单次向量搜索多种工具,迭代检索
评估检索上下文的自我评估
推理单次LLM调用使用工具的多步推理
错误恢复使用优化查询重试
数据源通常一个向量数据库多个来源(数据库、网络、API)

代理决策流程

Agentic RAG系统通常遵循以下决策模式:

  1. 分析问题:是简单的(单次检索)还是复杂的(需要分解)?
  2. 规划检索策略:查询哪些来源?按什么顺序?
  3. 执行检索:搜索第一个来源
  4. 评估结果:这些分块是否包含答案?
  5. 决定下一步行动:回答、优化查询或搜索其他来源
  6. 综合:合并所有检索步骤的信息
# 概念性Agentic RAG循环(伪代码)
def agentic_rag(query, tools, max_iterations=5):
    context = []
    plan = agent.plan(query)  # 分解为子问题
 
    for step in plan:
        # 代理决定使用哪个工具
        tool = agent.select_tool(step, tools)
        results = tool.execute(step.query)
        context.extend(results)
 
        # 代理评估是否有足够的信息
        if agent.has_sufficient_context(query, context):
            break
 
        # 代理根据学到的内容优化查询
        step.query = agent.refine_query(step, results)
 
    return agent.synthesize(query, context)

Agentic RAG的关键模式

1. 查询分解

将复杂问题拆分为更简单的子查询:

原始问题:"比较Apple和Microsoft 2025年第三季度的收入增长,
           并解释哪家公司的营业利润率更高"

分解后:
  1. "Apple 2025年Q3收入增长"
  2. "Microsoft 2025年Q3收入增长"
  3. "Apple 2025年Q3营业利润率"
  4. "Microsoft 2025年Q3营业利润率"

每个子查询检索聚焦的、相关的文档,而不是期望单次宽泛搜索返回所有需要的信息。

2. 自适应检索

代理根据查询类型决定如何检索:

查询类型检索策略
事实查找单次向量搜索
比较对每个实体进行并行搜索
多步推理顺序搜索,每次由前一次的结果指导
时间性按日期过滤,然后语义搜索
聚合SQL查询 + 文档搜索

3. 自我评估

每个检索步骤后,代理评估:

  • 相关性:检索到的分块是否关于正确的主题?
  • 完整性:是否包含足够的信息来回答?
  • 一致性:多个来源是否一致?
  • 时效性:信息是否足够最新?

4. 工具选择

Agentic RAG不限于向量搜索:

工具何时使用
向量搜索语义相似度查询
关键词搜索(BM25)精确术语匹配、技术查询
网络搜索当前事件、最新信息
SQL查询结构化数据、聚合
API调用实时数据(价格、天气)
代码执行计算、数据转换

实现方法

LangChain代理

from langchain.agents import create_react_agent
from langchain_openai import ChatOpenAI
from langchain.tools import Tool
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings
 
# 创建检索工具
vectorstore = FAISS.from_texts(documents, OpenAIEmbeddings())
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
 
def search_docs(query: str) -> str:
    results = retriever.invoke(query)
    return "\n".join([doc.page_content for doc in results])
 
tools = [
    Tool(
        name="SearchDocuments",
        func=search_docs,
        description="Search the knowledge base for relevant information"
    ),
]
 
llm = ChatOpenAI(model="gpt-4o", temperature=0)
agent = create_react_agent(llm, tools, prompt_template)

LlamaIndex代理

from llama_index.core.agent import ReActAgent
from llama_index.core.tools import QueryEngineTool
from llama_index.core import VectorStoreIndex
 
# 创建查询引擎工具
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine(similarity_top_k=5)
 
tools = [
    QueryEngineTool.from_defaults(
        query_engine=query_engine,
        name="knowledge_base",
        description="Search the company knowledge base"
    ),
]
 
agent = ReActAgent.from_tools(tools, llm=llm, verbose=True)
response = agent.chat("What were our Q3 results?")

何时使用Agentic RAG

场景基本RAGAgentic RAG
单一来源的简单问答最佳选择过度设计
多文档推理困难擅长
需要计算的问题无法做到使用代码工具
动态数据(API、数据库)有限天然适合
模糊查询效果差可以澄清和迭代
成本敏感更便宜(1次LLM调用)更贵(多次调用)
延迟要求更快更慢(迭代式)

权衡

优势劣势
更高的回答质量更高的延迟(多次LLM调用)
处理复杂查询每次查询成本更高
自我修正的检索构建和调试更复杂
多源集成代理可能陷入循环
更好地处理模糊查询行为更难预测

为Agentic RAG构建数据管道

为Agentic RAG设置数据管道——文档分块、创建嵌入、构建向量索引——是迭代性的实验工作。RunCell (opens in a new tab)提供了一个AI驱动的Jupyter环境,你可以在其中借助AI辅助原型化RAG管道、交互式调试检索质量、迭代优化分块策略。

对于检索评估指标的可视化(相关性分数、延迟分布、回答质量),PyGWalker (opens in a new tab)允许你在Jupyter中交互式地探索RAG评估数据集。

FAQ

什么是Agentic RAG?

Agentic RAG将检索增强生成与自主AI代理相结合。不同于静态的检索-生成管道,AI代理会规划检索策略、执行多次搜索、评估结果,并迭代直到拥有足够的上下文来准确回答。

Agentic RAG与基本RAG有何不同?

基本RAG执行单次检索并生成一个答案。Agentic RAG使用一个AI代理,能够分解查询、选择不同的工具(向量搜索、网络搜索、SQL)、评估检索到的上下文是否充分,并用优化的查询进行迭代。它处理基本RAG无法处理的复杂多步问题。

Agentic RAG比基本RAG更贵吗?

是的,Agentic RAG通常每次查询成本更高,因为它进行多次LLM调用(规划、评估、综合)和多次检索操作。权衡是对复杂查询显著提高的回答质量。对于简单的事实查找,基本RAG更具成本效益。

哪些框架支持Agentic RAG?

LangChain、LlamaIndex和Haystack都支持Agentic RAG模式。LangChain提供带工具使用的ReAct代理,LlamaIndex提供查询规划代理,Haystack有基于管道的代理架构。你也可以直接使用OpenAI或Anthropic的function calling API构建自定义代理。

我应该在什么时候使用Agentic RAG而不是基本RAG?

对于来自单一知识库的简单事实问答,使用基本RAG。当查询需要跨多个文档推理、涉及比较、需要实时数据,或基本RAG持续返回不完整答案时,使用Agentic RAG。

总结

Agentic RAG通过用能够规划、迭代检索和评估自身结果的智能代理替代静态管道,解决了基本RAG的核心局限。它处理跨越多个文档、需要推理或需要来自多个来源数据的复杂查询。权衡是每次查询更高的成本和延迟。对于大多数应用,最佳方法是对简单查询使用基本RAG,将复杂问题路由到Agentic RAG——仅在简单系统难以应对时使用代理。

📚