Agentic RAG：当你的检索流水线需要一颗大脑时

2024 年，90% 的智能体 RAG（Agentic RAG）项目在生产环境中失败了。原因并非技术本身存在缺陷，而是工程师们仅仅将向量搜索、提示词（prompt）和大语言模型（LLM）组合在一起，称之为检索管道并直接发布——却忽略了从查询到回答之间每一层累积的失败成本。

经典的 RAG 是一个确定性函数：嵌入查询 → 向量搜索 → 填充上下文 → 生成。它单向运行一次，没有反馈循环。当查询是针对分块良好的语料库进行简单的单步查找时，这种方式很有效。但当用户询问“比较这五份合同中的责任条款”或“总结自第三季度事故以来我们的基础设施配置发生了哪些变化”，或者任何需要先综合多份文档中的证据才能形成答案的问题时，它就会惨遭失败。

智能体 RAG 将那种单次运行的管道转换为控制循环。检索步骤变成了一个决策：调用哪个工具、结果是否足够好、以及是否需要重试。这就是函数调用与具有条件转换的状态机之间的区别。

五组件控制循环

典型的智能体 RAG 架构包含五个阶段，取代了线性管道：

路由（Router）→ 检索器（Retriever）→ 评分器（Grader）→ 生成器（Generator）→ 幻觉检查器（Hallucination Checker）

失败时，会有一个从评分器返回到检索器的反馈弧。

路由将每个查询分发到正确的检索模式——是对私有语料库进行向量搜索、实时网络搜索、针对通用知识问题的 LLM 直接回答，还是当答案存在于数据库中时的结构化 SQL 查询。RouteQuery Pydantic 模型强制执行输出契约。在生产环境中，缓存路由决策可以消除 30–40% 针对重复查询模式的路由 LLM 调用。

检索器获取候选文档。评分器——一次轻量级的 LLM 调用，理想情况下使用 GPT-4o-mini 或 Claude Haiku 等小型模型以保持合理的成本——为每个检索到的文档评估相关性。如果文档未达到相关性阈值，智能体将重写查询并重新检索，而不是基于糟糕的上下文产生幻觉。

生成器将评分后的上下文综合为答案，幻觉检查器验证每个事实主张是否都基于检索到的片段。未经验证的主张要么被删除，要么被标记以供人工审核。

这个循环正是智能所在。智能体在每一步都决定是继续、重试、升级还是停止。

查询规划：处理复杂问题的四种技术

简单的路由处理查询分发。查询规划则处理结构复杂性——即那些过于复杂、无法通过单次检索解决的查询。

子问题分解 (Sub-question decomposition) 将比较型查询分解为独立的子查询，并行针对每个子查询进行检索，在综合之前进行去重和重排序。“在维度 A、B 和 C 上比较 X 和 Y”变成了三个并发运行的独立检索操作。当你可以在子查询之间没有依赖关系的情况下进行并行化时，这就是正确的模式。

HyDE (Hypothetical Document Embeddings，假设文档嵌入) 解决了嵌入空间不匹配的问题。短查询和长文档在嵌入空间中往往相距较远，即使文档中包含答案。HyDE 先生成一个合理的假设性答案，然后将其作为检索查询与原始问题相比，假设性答案的嵌入与实际答案文档的距离要近得多。

后退提示 (Step-Back Prompting) 通过先提取更高层级的概念来处理过于具体的查询。当查询过于狭窄时（例如“在 X 服务 2.3.4 版本中，配置标志 --max-retry-count 有什么作用？”），后退查询会先询问更广泛的原则，在该层级进行检索，然后再深入到细节。它在概念层级而非语法层级处理信息复杂性。

FLARE (Forward-Looking Active Retrieval，前瞻性主动检索) 在生成阶段而非检索前运行。当模型生成内容时，它会监控 Token 的置信度。当预测 Token 的置信度低于阈值时，模型会暂停，根据预期的后续内容形成检索查询，进行抓取，然后继续生成。这是一种嵌入在生成过程中的细粒度检索——对于信息需求在文档中途不断变化的细长内容，它是正确的工具。

分层多智能体架构

对于大规模、异构的语料库，扁平化检索无法扩展。解决方案是采用两层智能体层级：文档智能体（document agents）和元智能体（meta-agent）。

每个文档智能体负责一个文档或文档簇。它拥有语义搜索和摘要工具，并根据强制使用工具的系统提示进行操作——它不能仅凭参数记忆（parametric memory）回答问题。这种约束至关重要：如果没有它，文档智能体将根据训练数据而非语料库产生幻觉。

顶层元智能体处理工具检索——选择调用哪些文档智能体——并协调整个语料库的路由。元智能体通过思维链（chain-of-thought）推理哪些智能体拥有查询所需的信息，进行并发分发，并使用重排序层（reranker layer）综合结果。

这种架构支持水平扩展。增加文档意味着增加文档智能体，而无需重写编排逻辑。权衡之处在于延迟：协调多个智能体增加了往返次数，而在生产规模下（1,000+ 文档智能体），编排开销将成为首要的工程考量。

当 Agentic RAG 的成本入不敷出时

Agentic RAG 的能力提升伴随着切实的成本：单次查询需要 5–15 次 LLM 调用，而 Naive RAG 仅需 1 次；延迟为 4–8 秒，而 Naive RAG 则在亚秒级；单次查询成本为 $0.06–$0.31，而 Naive RAG 仅为 $0.001–$0.005。

这些数字并不意味着 Agentic RAG 总是昂贵的 —— 它们意味着路由决策至关重要。如果一个查询可以通过单跳向量查找解决，路由层应该将其分发到那里，并完全跳过控制循环。实际的权衡方案是自适应分层模型：

• 无需检索：LLM 训练数据范围内的简单事实性问题
• Naive RAG：针对干净语料库的单跳查找
• Agentic RAG：需要综合处理的多跳、对比或分析性查询

在以下情况使用 Agentic RAG：查询确实复杂（多跳、跨文档综合）、答案需要实时数据配合静态语料库、任务是异步的（研究、文档审查、代码分析），或者失败会产生严重的下游后果且你需要审计追踪。请让它远离对延迟要求在亚秒级的高并发 FAQ 工作负载。

四种生产环境失败模式

大多数生产环境的失败都属于以下四种模式之一：

检索抖动（Retrieval thrash）：智能体反复获取语义冗余的文档，但没有提高回答质量。评分器的相关性阈值过于严格，导致当语料库根本不包含答案时触发重写。诊断方法：如果超过 30% 的查询触发了重新检索，问题在于基础检索流水线，而不是智能体层。要区分“检索失败”（语料库缺失）和“低置信度检索”（重写并重试）。

无限循环（Infinite loops）：如果在状态机中没有重写计数器，智能体在不确定时默认会“获取更多上下文”。请强制限制在三次迭代以内。超过三次重新检索后，应优雅降级 —— 返回“未找到足够信息”而不是持续空转。在将任何内容推向生产环境之前，请先实现这一点。

上下文膨胀（Context bloat）：检索到的文档在多次迭代中累积。到第三次重试时，上下文窗口包含 6–12 个段落，其中大部分是冗余的。LLM 的注意力在长且嘈杂的上下文中会下降。解决方法：在每次生成调用前对检索到的段落进行基于哈希的去重，并对每次迭代中最相关的 Top-K 文档使用滑动窗口（实践证明 K=3–5 有效）。

幻觉放大（Hallucination amplification）：这是最隐蔽的失败。如果幻觉检查器仅测试内部一致性（“这听起来对吗？”）而不是外部根据（“该声明是否溯源至检索到的段落？”），迭代生成会放大自信但错误的叙述。每个重新生成步骤都会使幻觉变得更复杂且更难捕捉。引用门控（Citation gating）可以解决这个问题：生成器必须将每个事实声明溯源到特定的检索段落。对于法律、医疗或合规用例，这是不容谈判的。

分块是基础设施，而非细节

2025 年一项针对政策文档 RAG 的研究发现，固定大小分块（fixed-size chunking）的忠实度得分为 0.47–0.51，而语义分块（semantic chunking）的得分则为 0.79–0.82 —— 仅通过分块策略的改变就使检索质量几乎翻倍。研究共识很明确：80% 的 RAG 失败可以追溯到分块决策，而不是检索算法或生成模型。

合适的分块大小取决于内容类型。技术文档在 256–512 token 时分块效果良好。叙事和政策文档需要 1,024–2,048 token 以保留上下文。结构化数据应按实体或行边界分块，而不是按 token 边界。相邻块之间始终保留 20% 的重叠，以避免边界伪影（即一个概念跨越块边界，导致两半都没被检索到）。

分块策略属于基础设施范畴，与数据库模式和索引同等重要。将其视为 Prompt 工程后的次要想法的工程师，通常会在六个月后重新构建其检索流水线。

以延迟换取准确性：理解权衡

在多跳问答基准测试中，Agentic RAG 的表现显著优于 Naive RAG：在类 HotpotQA 评估中约为 95% 对 73%，且在跨文档综合任务上差距进一步扩大。准确性方面的优势是真实的。

但延迟情况同样值得关注。单次迭代的 Agentic RAG 运行耗时 2–4 秒。带有两次检索迭代的多跳运行耗时 4–8 秒。带有激进重写的重新检索策略可能会推迟到 30 秒 —— 这对交互式应用来说是不可接受的。

对于用户期望亚秒级响应的应用，解决方案是带有渐进式披露（progressive disclosure）的流式传输：从第一次检索中返回初始答案，然后在后续步骤完成时流式传输精炼后的内容。这在生产级搜索应用中是标准做法，并能清晰地映射到 Agentic RAG 控制循环中。

衡量关键指标

四个指标涵盖了 Agentic RAG 系统的生产运行状况：

• 检索召回率（Retrieval recall）：至少返回一个相关文档的查询百分比。
• 评分器精确度（Grader precision）：被标记为相关的文档中实际相关的百分比（评分器校准）。
• 回答忠实度（Answer faithfulness）：回答中的所有声明是否都基于检索到的段落？（RAGAS 忠实度指标）。
• 回答相关性（Answer relevance）：回答是否解决了用户的实际意图？

运行监控：维护一个包含 100 个代表性查询的标注测试集。每晚对生产样本进行 LLM-as-judge 评估。对检索召回率下降、重新检索率飙升至 30% 以上以及评分器精确度漂移进行告警。这三个信号能在大多数回归事件影响到用户之前捕获它们。

语义缓存（Semantic caching）在高度重复的工作负载中可降低 20–35% 的成本 —— 在系统稳定且了解查询模式后，值得实施。

实践路径

Agentic RAG 并非 naive RAG 的直接替代式升级。它是一种解决不同类别问题的不同架构。那些成功交付该系统的工程师会从五组件控制循环（router、retriever、grader、generator、hallucination checker）入手，将迭代次数硬上限设为三次，使用混合 BM25 + vector retrieval 作为底层，并在优化其他任何环节之前，先将 chunking strategy 作为基础设施进行投入。

而那些失败的工程师在交付了 naive RAG 后便觉得万事大吉，等系统出问题时再塞进检索重试机制——没有 grader，没有 hallucination checker，也没有迭代上限。最终生成的系统从外部看像是 agentic，而内部表现得却像一个不可靠的 pipeline。

控制循环即架构。请从一开始就进行有意识的构建。