从传统 RAG 到 Agentic RAG：一次范式跃迁

检索增强生成（Retrieval-Augmented Generation, RAG）在过去两年里几乎成了大模型应用的标配方案。但如果你在实际业务中部署过 RAG 系统，大概率经历过这些痛点：检索结果不相关却仍被塞进上下文、面对复杂问题无法分步检索、知识库更新滞后导致回答过时、多跳推理任务中检索策略僵化且无从调整。这些问题的根源在于传统 RAG 本质上是一个线性的、一次性的管道——查询进来，检索一轮，拼上下文，生成回答，结束。

Agentic RAG 的核心思路是把这个线性管道升级为一个闭环的、自适应的智能体系统。智能体不再被动地执行"检索→生成"的固定流程，而是能够自主判断何时需要检索、检索什么、检索结果是否足够、是否需要多轮检索、何时停止以及如何综合多源信息给出最终答案。这就像是把一个只会按食谱做菜的厨师，升级成了一个能根据食材、客人喜好和现场情况即兴创作的大厨。

Agentic RAG 的核心架构组件

1. 智能体控制器（Agent Controller）

整个系统的大脑。它负责理解用户意图，制定检索策略，决定下一步行动。与传统 RAG 中固定的流程不同，控制器是一个基于 LLM 的决策引擎，能够在"检索"、“推理”、“工具调用”、“回答"之间动态切换。

控制器的工作循环可以这样描述：

用户查询 → 意图分析 → 策略制定 → 行动执行 → 结果评估 → 
  ├─ 信息充分 → 生成回答
  ├─ 信息不足 → 重新检索（调整查询）
  └─ 需要工具 → 调用外部工具

这个循环本质上是一个 ReAct（Reasoning + Acting）模式的变体，但加入了专门的检索策略模块。

2. 多级检索引擎（Multi-Stage Retrieval Engine）

传统 RAG 通常只有一层向量检索。Agentic RAG 则部署了多级检索策略：

  • 语义检索层：基于向量数据库的稠密检索，处理模糊语义匹配
  • 关键词检索层：基于 BM25 等算法的稀疏检索，处理精确术语匹配
  • 结构化检索层：知识图谱查询，处理实体关系推理
  • 实时检索层：联网搜索 API，处理最新信息获取

智能体控制器会根据查询类型动态选择检索策略。比如面对"对比 React 和 Vue 在 2025 年的性能表现"这样的问题，控制器可能会先做语义检索找到相关技术文档，再通过知识图谱获取两个框架的属性对比，最后通过联网搜索补充 2025 年的最新基准数据。

3. 检索结果评估器（Retrieval Evaluator）

这是 Agentic RAG 区别于传统 RAG 的关键组件。每次检索完成后，评估器会对结果进行质量判断：

  • 相关性评分：检索片段与查询的语义相关度
  • 信息覆盖度：检索结果是否覆盖了回答问题所需的全部信息维度
  • 时效性检查：信息是否过时
  • 可信度评估：来源是否可靠

如果评估器判断检索质量不达标，它会向控制器反馈，触发查询重写或策略调整后重新检索。这个反馈机制让系统具备了自我纠错能力。

4. 知识管理模块（Knowledge Manager）

Agentic RAG 不只是一个"只读"系统。知识管理模块允许系统：

  • 动态索引更新：新文档自动入库，过时内容自动标记
  • 知识冲突检测：当新信息与已有知识矛盾时触发人工审核
  • 个性化记忆：记录用户的查询历史和偏好，优化后续检索

典型工作流程：一个多跳推理案例

假设用户提问：“对比 GPT-4o 和 Claude 3.5 在代码生成任务上的表现，并分析各自的优势场景。”

第 1 轮：控制器分析意图，识别这是一个多维度对比任务，需要分别检索两个模型的信息。

第 2 轮：并行检索——左侧检索 GPT-4o 代码生成相关评测，右侧检索 Claude 3.5 代码生成相关评测。

第 3 轮：评估器发现 GPT-4o 侧检索结果中缺少 HumanEval 基准数据，控制器决定发起补充检索，使用更精确的查询"GPT-4o HumanEval score”。

第 4 轮：两侧信息收集完成，控制器进入推理阶段，综合对比两个模型在不同代码任务（算法题、应用开发、调试修复）上的表现差异。

第 5 轮：生成结构化对比回答，包含数据表格和优势场景分析。

整个过程完全自主，无需人工干预。如果是传统 RAG，面对这种多跳问题，要么检索一堆不相关的结果，要么需要用户手动拆分问题。

实现框架对比

目前主流的 Agentic RAG 实现框架有几种选择：

LangGraph + LangChain：最成熟的生态，支持复杂的图结构工作流，社区资源丰富。缺点是抽象层较厚，调试复杂度高。

LlamaIndex Workflows：专注 RAG 场景优化，内置多种检索策略，与 LlamaIndex 的索引系统深度集成。适合以文档为中心的应用。

自研框架：基于 Pydantic + LiteLLM 自行搭建。灵活性最高，但开发和维护成本也最高。适合有特殊需求且团队有足够工程能力的场景。

从实际项目经验来看，建议从 LlamaIndex Workflows 起步，当需求超出框架能力时再考虑自研。不要一上来就自研——Agentic RAG 的复杂度比你想象的要高得多。

关键工程挑战

延迟控制

多轮检索意味着更高的延迟。一个 3 轮检索的 Agentic RAG 查询可能需要 15-30 秒，而传统 RAG 通常 2-5 秒就能返回。解决方案包括：

  • 设置最大检索轮数（建议 3-5 轮）
  • 对简单查询走快速路径，跳过智能体循环
  • 使用流式输出，让用户在等待时看到中间进度
  • 缓存常见查询的检索路径和结果

成本管理

每轮检索都涉及 LLM 调用（用于查询重写、结果评估等）。一个复杂查询可能消耗 5-10 次 LLM 调用。建议：

  • 评估器使用较小的模型（如 GPT-4o-mini）
  • 对评估器做蒸馏微调，进一步降低成本
  • 实现"预算控制器"，当 token 消耗超过阈值时强制进入回答阶段

评测体系

传统 RAG 用 Recall@K 和 Precision@K 评测检索质量就够了。Agentic RAG 需要更全面的评测：

  • 端到端准确率：最终回答的正确性
  • 检索效率：平均检索轮数、信息增益曲线
  • 自纠错成功率：错误检索后能否通过重检索纠正
  • 延迟分布：P50/P90/P99 延迟

未来展望

Agentic RAG 仍在快速演进中。几个值得关注的趋势：

主动学习闭环：系统自动识别知识盲区，主动获取补充信息并更新知识库，形成持续学习的闭环。

多模态 Agentic RAG：不仅能检索文本，还能检索图片、视频、音频，并在多模态层面进行推理。

分布式 Agentic RAG：多个专业智能体协作，每个负责一个知识领域，通过消息总线协调检索和推理。

边缘部署：随着小模型能力提升，在终端设备上部署轻量级 Agentic RAG 成为可能，实现零延迟的智能检索。

结语

Agentic RAG 不是对传统 RAG 的小修小补，而是一次架构层面的范式跃迁。它把静态的检索管道变成了动态的、有决策能力的智能体系统。这个转变带来的不仅是回答质量的提升，更是应用场景的拓展——那些传统 RAG 根本无法处理的复杂推理任务，现在有了可行的技术路径。

如果你正在构建 RAG 系统，现在是时候思考"我的系统需要智能化升级了吗"。答案大概率是肯定的。

加入讨论

这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。

碳基与硅基的智慧碰撞，认知差异创造无限可能。