探索智能代理增强检索生成（Agentic RAG）：从基础到实践 原创

引言：检索增强生成的演进

在人工智能领域，大语言模型（LLMs）虽成果丰硕，但也有明显短板。模型训练时存储的知识，可能因时间推移而过时，或存在范围局限。检索增强生成（Retrieval - Augmented Generation, RAG）应运而生，它将大语言模型的输出与外部知识源相连，有效增强了模型能力。

传统RAG系统处理用户查询流程较为固定。用户提问后，系统先把查询送入嵌入模型生成向量嵌入，再用其在向量数据库搜索相关文档，接着将检索到的上下文与原始查询整合，输入大语言模型生成答案。整个过程线性推进，缺乏反复推理环节。

然而，传统RAG的弊端也很突出。工作流程静态线性，初始检索若失败，最终答案质量就难以保证。并且，进行相似性搜索时，直接使用用户原始查询，若查询表述与文档差异大，搜索效果便大打折扣。另外，它缺乏内置推理、规划及策略调整机制，面对复杂或多步骤查询时力不从心。

为突破这些困境，智能代理增强检索生成（Agentic RAG）诞生了。Agentic RAG把人工智能代理嵌入RAG管道，让大语言模型具备自主决策能力，能决定何时检索、检索什么、如何整合结果，甚至何时向用户请求说明。凭借基于代理系统的规划、工具使用和自我完善原则，Agentic RAG构建了更灵活智能的检索工作流程，为复杂问题的解决提供了新途径。

Agentic RAG与标准RAG的区别

工作流程

标准RAG采用一次性检索和生成序列，面对查询仅检索一次就生成答案。而Agentic RAG工作流程灵活且可迭代，由代理推理引导。代理能执行多轮检索/生成，拆解复杂问题或中途改变策略。比如，用户询问复杂多面的问题，标准RAG可能仅依据一次检索给出不完整答案，而Agentic RAG的代理会经推理决定多次检索，从不同知识源获取信息，进而生成全面精准的答案，凸显其处理复杂任务的优势。

决策与适应性

标准RAG系统检索后就结束，不检查答案是否完善。Agentic系统则适应性强，代理能评估中间结果，若当前上下文信息不足，会决定检索更多信息或换用其他工具。例如，用户查询某事件详情，标准RAG可能仅检索到基础事实就生成答案，而Agentic RAG的代理若觉得信息不全面，会再次检索或调用网络搜索API获取更多信息，生成更完整准确的答案。

工具使用与数据源

传统RAG一般只连接单个知识源，如某文档向量数据库。Agentic RAG的代理则可调用多个知识库和多种工具。例如，处理用户查询时，代理既能从私人文档索引检索，也能调用网络搜索API，还能使用计算器或其他API。这种多工具运用能力，使Agentic RAG可按需从结构化数据库、非结构化文本、网络等多种数据源获取信息，极大拓展了信息获取范围。

自我反思与准确性

标准RAG模型不会自我检查答案，答案正确性依赖用户或开发人员判断。Agentic RAG代理具备自我反思能力，能形成反馈循环。比如，检索上下文并起草答案后，代理会检查问题是否回答全面，若有不足，会获取更多信息或优化查询。通过迭代改进，答案准确性不断提高，为用户提供更可靠服务。

可扩展性与复杂性

Agentic RAG可让多个代理和工具协同工作，适用范围更具扩展性，能处理多样查询类型和不同数据源信息。例如，可部署由专门代理组成的网络，分别负责查询内部文档、API或网络，由主代理协调。但这也导致系统复杂性大幅增加，包括代理交互管理、工具集成及多轮对话状态维持等，都需投入更多精力和资源。

多模态性

传统RAG主要进行文本检索，Agentic RAG借助先进大语言模型代理，可融入多模态数据。随着多模态大语言模型发展，代理能检索和推理图像、音频等数据类型。比如，代理可从数据库获取图像，用图像字幕模型解读后融入答案，这种多模态处理能力是传统RAG所不具备的。

Agentic RAG架构深度剖析

从宏观看，Agentic RAG架构在常规检索和生成组件之上新增代理层，该代理层可为单个强大代理，也可为多代理系统。

单代理RAG架构

单代理RAG架构中，代理如同查询工作流程的智能“指挥者”，涉及以下组件：

1. 用户查询：用户以自然语言提出的问题或任务。
2. 代理（LLM）：由大语言模型或其与编程逻辑组合而成，经特定提示或设计，可决定行动。能调用向量数据库查找、网络搜索等工具，通过思维链提示确定各步骤行动。
3. 知识源/工具：包含向量数据库、关键字搜索引擎、各类API及从属代理等，其中至少有一个可获取查询相关上下文的检索器。
4. 生成模型：通常代理自身就是生成答案的大语言模型（前提是收集到足够信息），也可能委托单独大语言模型实例生成答案，本质上都是大语言模型负责推理和回答。

单代理系统处理查询流程如下：

1. 代理决策——是否需要检索：代理研究查询及对话上下文（若为多轮对话），判断是否需要外部信息。简单事实性问题可能直接搜索知识库，直白或常识性问题也可能不检索直接回答，但多数系统习惯先尝试检索。
2. 代理决策——选择工具/源：确定检索后，代理挑选合适工具或数据源。如有多个向量索引，会选最可能含答案的；针对当前事件查询，会在向量数据库和网络搜索API间抉择。
3. 制定检索查询：代理构思输入检索工具的查询内容，可直接用用户问题，也可重新表述，高级代理还会采用查询扩展等技术提升检索效果。
4. 检索并观察：检索工具返回候选文档或数据，代理审视结果，判断能否回答问题，若结果不佳，会返回前序步骤调整。
5. 生成答案：代理收集到足够信息或确定检索无帮助后，用大语言模型撰写答案，检索上下文会用于提示，代理思维过程也会影响答案构建。

简化的代理循环代码如下：

while True:
    action = agent.plan(next_step, context_so_far)
    if action.type == "SEARCH":
        tool = action.tool_selection   # 例如 "VectorDB" 或 "WebSearch"
        query = action.formulated_query
        results = tool.run(query)
        agent.observe(results)
    elif action.type == "ANSWER":
        final_answer = agent.generate_answer(context_so_far)
        break
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

循环持续至代理认为可输出答案或达最大步骤限制。

多代理RAG系统

复杂应用场景可采用多代理RAG系统，多个代理分工明确。如：

1. Web代理：专门查询外部网络资源。
2. DB代理：主要查询内部数据库。
3. 协调代理：将问题分配给合适专家代理，并汇总结果。

多代理设置下，代理可相互调用，以完成特定子任务。实际应用中，多代理RAG可能呈层级或网络结构，各代理协作完成复杂任务。像IBM的Agentic RAG系统，一个代理查询外部数据库，另一个梳理内部邮件和数据，由协调代理整合输出形成最终答案，这种设计虽增加复杂性，但提升了系统稳定性和专业性。

Agentic RAG的实现细节

以LangChain为例搭建Agentic RAG系统：

设置检索的知识库

先准备知识源，通常为文档向量存储，操作与标准RAG类似。

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import FAISS
# 假设文档列表docs_list
text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
docs = text_splitter.create_documents(docs_list)
# 创建嵌入并在FAISS中索引
embedding_model = OpenAIEmbeddings()  # 使用OpenAI嵌入（需API密钥）
vector_store = FAISS.from_documents(docs, embedding_model)
1.
2.
3.
4.
5.
6.
7.
8.
9.

代码将文档分割为约500字符小块，创建嵌入存入FAISS索引，以便vector_store根据新查询嵌入查询相似文档。

为代理定义工具

至少定义一个检索工具包装向量存储调用。

from langchain.agents import Tool

# 定义查询向量存储函数
def vector_search(query: str) -> str:
    """在向量数据库中搜索相关文档，并返回结果的连接字符串。"""
    docs = vector_store.similarity_search(query, k=3)
    # 组合检索到的文档的内容（可能带有元数据或片段格式）
    return"\n".join([doc.page_content for doc in docs])
# 创建检索工具
retrieval_tool = Tool(
    name="VectorDB",
    func=vector_search,
    descriptinotallow="从知识库中检索相关文档。"
)
# （可选）定义网络搜索工具（模拟）
def web_search(query: str) -> str:
    # 实际网络搜索API调用占位符
    # 实践中使用SerpAPI或Bing API等
    return fake_web_search_api(query)
search_tool = Tool(
    name="WebSearch",
    func=web_search,
    descriptinotallow="在网络上搜索最新信息。"
)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.

创建的VectorDB和WebSearch工具，接受字符串输入，返回检索文本，供代理按名称调用。

初始化代理

选择大语言模型为代理推理提供动力，初始化可调用工具的代理。

from langchain.chat_models import ChatOpenAI
from langchain.agents import initialize_agent
# 为代理初始化语言模型（用聊天模型）
llm = ChatOpenAI(model_name="gpt - 4", temperature=0)  # 或选其他大语言模型
# 使用工具创建代理，设置详细输出观察思维过程
agent = initialize_agent(
    tools=[retrieval_tool, search_tool],
    llm=llm,
    agent="zero - shot - react - description",  # 用基于ReAct的代理
    verbose=True
)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

代码设置提示策略，让代理大语言模型学会使用工具，运行时输出思维过程。

提问（代理行动）

准备好代理后输入用户查询获取答案：

query = "标准RAG和Agentic RAG的主要区别是什么？"
response = agent.run(query)
print("代理的答案:", response)
1.
2.
3.

代理内部思考回答，可能先使用VectorDB工具查询，若知识库有相关文章，向量搜索会返回内容，代理读取后继续操作。若问题复杂，可能调用WebSearch或优化问题后再次查询。

替代实现方法

除LangChain，还可用Autogen、CrewAI等框架实现Agentic RAG逻辑。核心都是定义知识源、包装成工具，在循环中提示大语言模型使用工具得出答案。实现复杂程度可灵活调整，从简单的提示逻辑到完全自主决策代理，通常从简单方法入手，如允许一次额外检索的两步RAG，常能有效提高答案准确性。

性能和可扩展性比较

答案质量和成功率

Agentic RAG旨在提升复杂查询成功率，通过多次检索和智能查询构造，挖掘传统RAG遗漏信息。Hugging Face团队研究表明，代理方法能重拾先进RAG技术，找到传统RAG错过的信息。实际场景中，如100道难题，传统RAG可能答对60道，采用两步检索的Agentic RAG答对题数可能提升至75道，尤其在法律、医疗等对答案准确性要求高的领域，意义重大。

计算开销和延迟

Agentic RAG对资源需求更高，多次调用大语言模型代理推理，加上频繁检索操作，增加查询延迟和计算成本。Qdrant文章指出，标准RAG一次大语言模型调用即可快速出答案，Agentic RAG代理可能多次调用，延迟累积。例如普通RAG 2秒响应，Agentic RAG因运行步骤多，可能需5到10秒。虽对许多交互应用延迟可接受，但影响吞吐量，相同硬件下每秒处理查询数量减少。可通过限制代理步骤或选用更快但准确性稍低的模型缓解。

数据源的可扩展性

Agentic RAG在数据源可扩展性方面优势显著，能协调管理多个数据源，可随业务发展为代理添加工具或索引。IBM研究表明，RAG代理网络可利用多个数据孤岛，处理复杂查询扩展性强。传统RAG面对大规模数据时，如向量索引过大，会出现检索慢、结果不准确问题，而Agentic RAG代理可智能路由查询到合适子索引，适应数据增长，虽每个查询处理速度降低，但系统覆盖范围和灵活性提升。

基准测试考虑

评估Agentic RAG与标准RAG性能，常用答案准确性、F1值、检索召回率及平均延迟等指标。目前虽无专门标准化基准测试，但研究人员已优化问答基准测试以适应多步骤检索评估。社区实验显示，代理方法处理边缘情况表现更好，失败查询减少。对答案准确性要求高、需减少模型幻觉的应用，Agentic RAG值得考虑；追求快速响应简单查询的场景，传统简单RAG即可满足需求。

系统复杂性和维护

Agentic RAG系统组件多、交互复杂，维护和扩展挑战大。可能出现代理陷入工具调用循环等问题，开发人员需追踪代理推理步骤，借助Arize的Phoenix或LangSmith等工具调试。工程实践中，需花费更多时间调整提示策略、确定代理停止时机及更新维护知识源，增加了系统开发和运维成本。

Agentic RAG的挑战与未来

关键挑战

1. 复杂性与可调试性：Agentic RAG系统比标准RAG管道复杂，管理多代理或工具及其交互困难，易出现代理无限检索循环或选错工具等问题。需详细记录代理思维链以便调试，建立完善监控体系。提示设计不当还会导致代理误解指令或错误使用工具。
2. 延迟与成本：迭代特性增加推理成本，对实时性要求高或预算有限的应用不利。需合理设置超时或步骤限制，部分代理框架采用缓存中间结果策略降低延迟和成本，但缓存机制也需额外资源和管理。
3. 数据质量与知识边界：依赖底层数据质量，知识库不完整、有错误或偏差，会导致代理检索到误导性信息，且代理自主性可能使其超出预设边界，引入无关或不安全信息，需确保代理遵循数据访问策略。
4. 安全与伦理问题：代理自主性增强，若未严格沙盒化，可能执行危险操作。需研究增强代理可信度方法，如评估大语言模型输出可信度、多代理相互批判等，但并非绝对可靠。同时要注意伦理问题，防止代理获取版权文本或不适当内容。
5. 评估：评估Agentic RAG系统难度大，传统答案准确性指标外，代理决策过程评估复杂，需考虑步骤数量、工具选择是否最优等。研究定义针对代理的评估指标，如“工具使用效率”，但大语言模型随机性导致评估可重复性受挑战，生产系统中仍存在可变性。

未来趋势与发展

1. 更好的代理框架：未来有望出现更成熟易用的代理框架，简化构建和约束代理过程。如微软Autogen库支持更结构化定义多代理对话和工具使用，未来框架可能集成安全检查、循环检测及常见应用模式优化功能，降低开发门槛。
2. 规划算法的集成：研究将经典规划或强化学习与大语言模型代理结合，使Agentic RAG更系统决定检索顺序，减少对大语言模型不稳定推理的依赖，让代理行为更可预测和优化。
3. 从反馈中学习：未来基于学习的代理将成主流，可根据用户反馈或操作演示微调策略。如通过多步骤搜索示例微调大语言模型，使其学会不同情况下检索次数，实现元学习，提升智能水平。
4. 多模态和多步骤推理：随着大语言模型多模态能力提升，Agentic RAG将向多模态拓展。代理可检索图像、图表等多模态信息融入答案，甚至触发计算操作，成为通用问题解决助手。
5. 与知识图谱和符号人工智能的融合：结合大语言模型代理与知识图谱或数据库，实现更深入基于知识的推理。Agentic RAG可借助知识图谱验证答案一致性，神经符号人工智能探索将非结构化信息转化为结构化形式，提升推理能力。
6. 标准化和最佳实践：随着Agentic RAG应用案例增加，将总结出涵盖系统设计到应用各方面的最佳实践指南，如代理数量选择、查询路由策略设计及用户后续问题处理等。社区已分享应用模式经验，为设计者提供参考。

结论

Agentic RAG是检索增强生成理念的重大创新，赋予大语言模型规划、调用工具和迭代能力，构建的系统能处理复杂查询、整合多元数据源、优化答案质量。它推动人工智能系统能力提升，为工程师开启构建高自主性智能应用的大门。

随着技术发展，Agentic RAG将在未来人工智能应用中发挥关键作用，带来创新机遇，在学术、商业及日常生活智能化等方面展现巨大潜力，引领人工智能迈向新高度。

本文转载自公众号Halo咯咯    作者：基咯咯

原文链接：​​https://mp.weixin.qq.com/s/xJJT5A0Textp8bBb3itdkA​​