Agentic RAG:AI代理如何变革检索增强生成
Updated on
标准RAG(检索增强生成)有一个根本性的局限:它只检索一次,生成一次。系统搜索向量数据库,获取Top-K个分块,将它们塞入提示词,然后期望答案在这些分块中。当相关信息分散在多个文档中、需要多步推理或需要在检索前进行澄清时,基本RAG会默默失败——返回听起来很有把握但基于不完整上下文的答案。
Agentic RAG通过用一个能够规划、迭代检索、评估结果并判断何时拥有足够信息来回答的自主AI代理来替代静态的检索-生成管道,解决了这个问题。代理不仅仅是获取文档——它会推理应该搜索什么,判断检索到的内容是否充分,并在不充分时采取额外行动。
基本RAG vs Agentic RAG
基本RAG管道
用户查询 → 嵌入查询 → 向量搜索 → Top-K分块 → LLM → 回答这种方法的问题:
- 单次检索:如果第一次搜索错过了相关文档,没有恢复机制
- 没有关于检索什么的推理:查询原样嵌入,没有分解
- 没有评估:系统无法判断检索到的分块是否真正回答了问题
- 没有多步检索:无法链接搜索,让第一个结果指导下一个查询
Agentic RAG管道
用户查询 → 代理规划 → 搜索工具 → 评估结果 →
→ 需要更多信息? → 优化查询 → 再次搜索 →
→ 足够的上下文? → 综合 → 回答代理作为智能编排器,能够:
- 将复杂查询分解为子问题
- 选择工具:向量搜索、网络搜索、SQL查询、API调用
- 评估检索到的上下文是否充分
- 用优化的查询迭代直到有信心
- 综合来自多轮检索的信息
Agentic RAG的工作原理
核心架构
| 组件 | 基本RAG | Agentic RAG |
|---|---|---|
| 查询处理 | 直接嵌入 | 查询分解与规划 |
| 检索 | 单次向量搜索 | 多种工具,迭代检索 |
| 评估 | 无 | 检索上下文的自我评估 |
| 推理 | 单次LLM调用 | 使用工具的多步推理 |
| 错误恢复 | 无 | 使用优化查询重试 |
| 数据源 | 通常一个向量数据库 | 多个来源(数据库、网络、API) |
代理决策流程
Agentic RAG系统通常遵循以下决策模式:
- 分析问题:是简单的(单次检索)还是复杂的(需要分解)?
- 规划检索策略:查询哪些来源?按什么顺序?
- 执行检索:搜索第一个来源
- 评估结果:这些分块是否包含答案?
- 决定下一步行动:回答、优化查询或搜索其他来源
- 综合:合并所有检索步骤的信息
# 概念性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
| 场景 | 基本RAG | Agentic 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——仅在简单系统难以应对时使用代理。