Agentic RAG 生产架构：从控制循环到检索-推理-反思的工程治理

核心论点：Agentic RAG 的本质不是"更好的检索"，而是把检索变成一个由 Agent 控制的闭环决策过程。

传统 RAG 是一条线性管线：嵌入查询 → 向量检索 Top-K → 拼接上下文 → LLM 生成。这条管线有一个致命假设——检索步骤一定会返回正确的文档。2025 年 Shopify 工程师的内部复盘显示，他们的文档搜索系统在演示中表现良好，但在生产中 17% 的案例产生幻觉。原因不是模型差，而是检索错了，且系统没有任何机制知道这一点。分块顺序错误、相关信息跨越文档边界、嵌入模型对领域术语失去精度——这些失败模式在线性管线中无法被检测或纠正。

Agentic RAG 用自主控制循环替换了线性管线。一个 AI Agent 编排整个检索过程，在每一步做出决策：检索什么、从哪个源检索、检索结果是否充分、是否需要迭代。核心循环遵循 ReAct（Reason and Act）模式：Agent 接收查询 → 推理需要什么信息 → 执行检索动作 → 观察结果 → 评估检索到的上下文是否足以回答问题 → 决定继续检索还是生成最终答案。这个循环可以对每个查询执行多次。

关键架构差异在于对检索过程的"代理权"（agency）：传统 RAG 单次嵌入单次检索，Agentic RAG 将查询分解为子查询并执行多次定向检索；传统 RAG 信任检索结果，Agentic RAG 在每次检索后评估相关性和完整性；传统 RAG 没有中间推理，Agentic RAG 在检索步骤之间使用链式推理规划下一步行动。

Singh 等人（2025）的规范 surveys 沿四个轴定义了 Agentic RAG：Agent 基数（单 Agent vs 多 Agent）、控制结构（线性 vs 循环 vs 图状）、自主程度（被动 vs 主动 vs 自适应）、知识源（单一 vs 多源异构）。2026 年的生产系统已经在这四个维度上形成了明确的工程实践。

核心论点：Agentic RAG 的控制循环不是简单的 while 循环，而是一个有明确状态和转移条件的有限状态机。

理解控制循环的工程细节，需要把它建模为一个状态机。系统在任何时刻处于五种状态之一：规划（Planning）、检索（Retrieving）、评估（Evaluating）、反思（Reflecting）、生成（Generating）。状态之间的转移由明确的条件触发，而不是由开发者硬编码的固定流程决定。

规划状态是循环的起点。Agent 分析用户查询，判断需要哪些知识、从哪些源检索、用什么策略。对于复杂查询，Agent 会将其分解为多个子查询。例如"我们的 Q4 收入与前三名竞争对手相比如何，哪些市场因素导致了差异？"会被分解为：检索内部 Q4 收入数据、识别前三名竞争对手、检索它们的公开财务数据、检索相关时间段的市场分析。

检索状态执行实际的检索动作。根据规划阶段的决策，系统可能并行执行多个检索：向量数据库的语义搜索、关键词搜索（BM25）、知识图谱查询、外部 API 调用。Higress-RAG 框架（2026 年 2 月，arXiv:2602.23374）结合自适应路由和双混合检索（密集向量 + 稀疏 BM25 via BGE-M3），在企业数据集上实现了超过 90% 的召回率。

评估状态是控制循环的核心创新。在每次检索后，系统评估检索结果的质量。Corrective RAG（CRAG，Yan 等人 2024）在检索和生成之间添加了一个轻量级检索评估器。评估器将每个检索到的文档评分为 Correct、Ambiguous 或 Incorrect。评估器通常是一个小型微调模型——不是主 LLM——这将每次评估的延迟开销控制在 100 毫秒以内。

反思状态在评估结果为 Ambiguous 或 Incorrect 时触发。Agent 分析为什么检索失败：是查询表述不清、是知识源不完整、还是嵌入模型对领域术语失去精度？基于反思结果，Agent 决定下一步策略：改写查询、切换到替代知识源、或降低置信度向用户说明不确定性。

生成状态在评估结果为 Correct 时触发。但即使是生成阶段，Agentic RAG 也增加了自我验证：Agent 检查生成的答案是否被检索到的文档支持，是否存在幻觉。Self-RAG（Asai 等人 2023）训练生成模型发出特殊的反思 token：[IsRel]（文档是否相关）、[IsSup]（文档是否支持该声明）、[IsUse]（回答是否有用）。这种自我评估在生成时发生，延迟开销极小。

核心论点：Agentic RAG 在生产环境中的失败不是随机的，而是集中在三类可预测的模式。理解这三类失败模式是设计工程治理方案的前提。

第一类：循环不收敛（Runaway Loops）。 这是最危险的失败模式。Agent 在检索-评估-反思循环中无法达到终止条件，无限循环直到超时或耗尽预算。触发原因通常有三种：评估器过于严格，永远不给 Correct 评分；反思阶段无法产生有效的查询改写，每次改写都返回相似的结果；查询本身存在逻辑矛盾，无论如何检索都无法满足。Fordel Studios 的生产监控数据显示，在没有最大轮数约束的系统中，约 3% 的查询会触发循环不收敛，平均循环次数达到 15-20 次后才超时。

第二类：评估器漂移（Evaluator Drift）。 评估器是控制循环的核心组件，但它本身也会随时间退化。嵌入漂移（Embedding Drift）是最常见的形式：嵌入索引是几个月前构建的，新文档使用不同的术语，嵌入不再准确表示当前语料库。评估器的评分阈值也会漂移：初始部署时 Ambiguous 阈值设为 0.6，但随着语料库扩展，相同质量的文档得分逐渐下降，导致越来越多文档被标记为 Incorrect，触发不必要的回退检索。Microsoft Research 的实验显示，未经校准的评估器在 6 个月后，False Negative 率从 5% 上升到 18%。

第三类：上下文爆炸（Context Explosion）。 每次检索都会向上下文窗口添加文档。在多轮循环中，上下文快速增长。如果每轮检索返回 5 个文档，每个文档 1000 token，3 轮循环就是 15000 token。加上系统提示、查询历史和生成内容，很容易触及模型的上下文窗口限制。更严重的是"中间丢失"（Lost in the Middle）问题：Liu 等人（2023）测量到，当相关信息位于上下文中间而非开头或结尾时，准确率下降约 30%。上下文越长，这个问题越严重。生产系统中常见的错误是：为了"给模型更多信息"而检索更多文档，结果模型的注意力被稀释，准确率反而下降。

核心论点：循环不收敛的治理不是简单地设置一个最大轮数，而是设计多层次的终止条件和降级策略。

最基础的治理是设置最大检索轮数。生产系统的默认值通常是 2-3 轮。Adaptive RAG（Jeong 等人 2024）使用训练好的分类器（通常是 T5-large 模型）将查询路由到三个层级：Tier A（简单）路由到基础单次检索 RAG；Tier B（中等）路由到多步检索加链式推理；Tier C（复杂）路由到完整的 Agentic 检索，包含查询分解、多源检索和迭代精炼。通过不对简单查询过度工程化，Adaptive RAG 将平均推理成本降低了 40%，同时保持了复杂查询的质量。

但最大轮数只是第一道防线。更精细的治理包括：

提前终止条件。 即使未达到最大轮数，如果连续两轮的检索结果相似度超过 90%（用余弦相似度衡量），说明系统在循环中打转，应该提前终止。另一个提前终止条件是置信度：如果评估器给出的最高分低于 0.4，说明知识源可能根本不包含答案，继续检索只会浪费资源，应该直接返回"无法回答"并说明原因。

降级策略。 当达到最大轮数仍未收敛时，系统不应该简单地报错。更好的做法是降级：使用当前检索到的最佳结果生成答案，但明确标注置信度为"低"，并向用户说明"这个回答可能不完整，因为系统在 X 轮检索后仍未找到充分信息"。这种透明的降级比硬超时或无限循环都好。

预算感知路由。 Higress-RAG 框架的实践表明，自适应路由层可以将平均推理成本降低 40%。关键是根据查询复杂度动态分配预算：简单查询分配 1 轮检索 + 500 token 上下文；中等查询分配 2 轮检索 + 2000 token 上下文；复杂查询分配 3 轮检索 + 5000 token 上下文。预算在规划阶段确定，循环中严格执行。

核心论点：评估器是控制循环的核心，但它本身也需要被治理。没有校准机制的评估器会在 6 个月内严重退化。

评估器漂移是 Agentic RAG 系统中最隐蔽的失败模式。它不会导致系统崩溃，而是让准确率缓慢下降，直到某天团队发现"系统最近回答质量变差了"，但找不到原因。

嵌入漂移是最常见的形式。嵌入模型在训练时看到的数据分布和部署后遇到的数据分布不同。例如，一个在通用语料库上训练的嵌入模型，部署到医疗领域后，对医学术语的理解可能不准确。更微妙的是时间漂移：即使领域不变，术语也会随时间演变。2024 年大家说"大模型"，2025 年说"Foundation Model"，2026 年说"Agentic AI"——同一个概念，不同的表述，嵌入向量可能差异很大。

阈值漂移是另一个问题。评估器的评分阈值通常在部署时通过 A/B 测试确定。但随着语料库扩展，相同质量的文档得分分布可能变化。初始部署时，Correct 文档的平均分是 0.8，Ambiguous 是 0.6，Incorrect 是 0.4。6 个月后，由于语料库中增加了大量低质量文档，整体得分分布下移，Correct 文档的平均分变成 0.7，Ambiguous 变成 0.5，Incorrect 变成 0.3。如果阈值不变，原本标记为 Correct 的文档现在可能被标记为 Ambiguous，触发不必要的回退检索。

校准方案需要三个层次的机制：

第一层是定期重新标注。每月从生产日志中抽样 500-1000 个查询，由人工标注检索结果的相关性。用这些标注数据重新评估评估器的性能，计算 Precision、Recall 和 F1。如果 F1 下降超过 5%，触发评估器微调或阈值调整。

第二层是滑动窗口阈值。不使用固定的 0.6/0.4 阈值，而是使用相对于当前语料库分布的百分位阈值。例如，Correct 阈值设为当前语料库得分分布的 70 百分位，Incorrect 阈值设为 30 百分位。这样即使整体得分分布变化，阈值的相对位置保持不变。

第三层是 A/B 测试驱动的阈值优化。每次调整阈值后，用 A/B 测试验证新阈值是否真的改善了生产指标（用户满意度、回答准确率、延迟）。不要仅凭离线指标做决策——离线指标和生产表现之间经常存在差距。

Microsoft Research 的实验显示，经过每月校准的系统，6 个月后 False Negative 率保持在 6% 以内；而未经校准的系统，False Negative 率上升到 18%。校准的成本是每月约 10 小时的人工标注时间，但避免了准确率的显著下降。

核心论点：上下文预算不是简单的 token 限制，而是一个分层的资源分配系统，需要在检索质量、延迟和成本之间做权衡。

上下文爆炸的治理需要分层预算管理。最简单的做法是设置一个硬限制：上下文不超过模型窗口的 80%。但这种方法过于粗糙，无法区分不同查询类型的需求。更精细的方案是分层预算：

第一层：全局硬限制。 无论如何，上下文不超过模型窗口的 80%。这个限制保护系统不会因为任何原因（包括 bug）而超出模型限制。对于 128K 窗口的模型，硬限制是 102K token。

第二层：查询类型软限制。 根据查询复杂度分配不同的预算。简单查询（FAQ 式问题）分配 500 token 上下文；中等查询（需要一些推理）分配 2000 token；复杂查询（多步推理、多源整合）分配 5000 token。软限制不是硬性的，但如果超过软限制，系统需要证明额外的上下文确实带来了准确率提升。

第三层：文档优先级排序。 当检索到的文档总长度超过预算时，不是简单地截断，而是按优先级排序。优先级由三个因素决定：评估器的相关性得分（权重 50%）、文档在检索结果中的排名（权重 30%）、文档的新鲜度（权重 20%）。优先保留高优先级文档，低优先级文档被截断或完全移除。

第四层：文档压缩。 对于必须保留但过长的文档，使用压缩技术减少 token 数。最简单的方法是提取关键段落：用 LLM 对每个文档生成一个 100 token 的摘要，用摘要替代原文。更高级的方法是检索增强压缩（Retrieval-Augmented Compression）：只保留与查询最相关的句子，其他部分删除。Microsoft Research 的 LazyGraphRAG 将索引成本降低到完整 GraphRAG 的约 0.1%——1000 倍的降低——同时保持可比较的质量。

"中间丢失"问题的治理。 Liu 等人（2023）的研究表明，当相关信息位于上下文中间时，模型准确率下降约 30%。治理方法包括：将最重要的文档放在上下文的开头和结尾；使用分隔符明确标记每个文档的边界；在系统提示中明确告诉模型"请特别注意中间部分的信息"。生产数据显示，这些方法可以将"中间丢失"的影响从 30% 降低到 10-15%。

成本监控。 上下文长度直接影响成本。生产系统应该监控每个查询的平均上下文长度、每轮检索的上下文增量、以及上下文长度与准确率的关系。如果发现准确率与上下文长度负相关（即更长的上下文反而导致更差的准确率），说明系统存在注意力稀释问题，需要降低上下文预算或改进文档压缩。

核心论点：Agentic RAG 不是单一架构，而是一个架构家族。生产系统需要根据查询类型、知识源特性和性能要求选择合适的模式。

2026 年的生产环境中，四种 Agentic RAG 模式已经成熟：Corrective RAG、Self-RAG、Adaptive RAG 和 GraphRAG。每种模式解决不同的失败模式，适用于不同的场景。

Corrective RAG（CRAG） 在检索和生成之间添加一个轻量级检索评估器。评估器将每个检索到的文档评分为 Correct、Ambiguous 或 Incorrect，基于评分触发不同的纠正路径。CRAG 特别适合事实性问答场景，其中检索语料库可能不完整或过时。评估器通常是小型微调模型，延迟开销在 100 毫秒以内。适用场景：客户支持、技术文档问答、知识库检索。

Self-RAG 训练生成模型发出特殊的反思 token，在生成时自我评估检索和生成质量。模型生成 [IsRel]（文档是否相关）、[IsSup]（文档是否支持该声明）、[IsUse]（回答是否有用）等 token。Self-RAG 在基准测试上表现强劲，但需要微调 LLM 来发出这些反思 token，这锁定了特定模型版本，使模型升级更复杂。适用场景：对准确率要求极高、可以接受模型锁定风险的场景，如医疗问答、法律咨询。

Adaptive RAG 使用训练好的分类器将查询路由到不同复杂度的检索策略。简单查询走单次检索，中等查询走多步检索加链式推理，复杂查询走完整的 Agentic 检索。Higress-RAG 框架结合自适应路由和双混合检索，在企业数据集上实现超过 90% 召回率，同时将平均推理成本降低 40%。适用场景：查询复杂度分布广泛的通用系统，如企业知识管理平台。

GraphRAG 不检索单个文本块，而是先从文档语料库构建知识图谱——实体、关系和社区结构——然后在查询时在图上进行检索。Microsoft Research 的基准显示，GraphRAG 在需要跨文档推理的问题上达到 80% 准确率，而传统向量检索只有 50%——3.4 倍的提升。LazyGraphRAG 变体将索引成本降低到完整 GraphRAG 的约 0.1%，查询成本降低 700 倍以上，同时保持可比较的质量。适用场景：文档之间有大量引用关系的领域，如法律、学术研究、企业合规。

生产系统通常不会只用一种模式。最常见的架构是混合栈：顶层是 Agentic 编排（通常是 Adaptive RAG 的路由层），底层是向量检索 + 重排序用于大多数查询，GraphRAG 用于关系密集型领域，长上下文用于语料库可以放入窗口且召回率比精确率更重要的少数场景。

核心论点：Agentic RAG 的迁移不应该是大爆炸式的重构，而应该是渐进的、可度量的、可回滚的演进。

从传统 RAG 迁移到 Agentic RAG，建议分四个阶段：

阶段一：混合检索 + 重排序（2-4 周）。 这是最低成本的升级，也是后续所有阶段的基础。在现有向量检索基础上添加关键词检索（BM25），用重排序器（如 Cohere Rerank 3.5）合并和重排序结果。Cohere Rerank 3.5 的价格是每 1000 次搜索 2.00 美元，支持 4096 token 上下文和 100+ 语言，已经原生集成到 Pinecone、AWS Marketplace、Oracle Generative AI 和 Azure Marketplace。这个阶段的目标是将检索准确率提升 15-25%，为后续阶段奠定精确的检索基础。

阶段二：添加检索评估器（2-4 周）。 在检索和生成之间添加一个轻量级评估器，实现 Corrective RAG 的核心逻辑。评估器可以是一个小型分类器（如基于 BERT 的模型），训练数据可以从人工标注的查询-文档对中获得。这个阶段的目标是检测检索失败并触发纠正，将幻觉率降低 30-50%。关键指标：评估器的 Precision、Recall 和 F1；幻觉率的变化；延迟开销。

阶段三：实现控制循环（4-8 周）。 在评估器基础上添加反思和迭代检索逻辑，实现完整的 Agentic RAG 控制循环。这个阶段需要仔细设计状态机、转移条件和终止条件。建议从简单的 2 轮循环开始，逐步增加复杂度。关键指标：循环次数分布、收敛率、准确率 vs 轮数的关系、延迟分布。

阶段四：引入 GraphRAG 和高级路由（8-16 周）。 对于文档间有大量引用关系的领域，引入 GraphRAG。LazyGraphRAG 将索引成本降低到完整 GraphRAG 的 0.1%，使得中小规模语料库也可以负担得起。同时实现 Adaptive RAG 的查询路由，根据查询复杂度动态分配检索策略。关键指标：GraphRAG 相比向量检索的准确率提升；路由器的分类准确率；整体系统的成本和延迟分布。

每个阶段都应该有明确的验收标准和回滚计划。阶段一完成后，检索准确率应该提升 15-25%；如果没有达到，应该先解决检索质量问题，再进入阶段二。阶段二完成后，幻觉率应该降低 30-50%；如果没有达到，应该先校准评估器，再进入阶段三。渐进迁移的核心是：每一步都验证价值，再进入下一步。

本文的工程实践和数据来源：

1. Fordel Studios. "Your RAG Pipeline Retrieves Once, Guesses Once, and Calls It an Answer." 2026-03-25（更新于 2026-05-08）. https://fordelstudios.com/research/agentic-rag-production-retrieval-control-loop-2026

2. BestAIWeb. "Agentic RAG, GraphRAG, and the Long-Context Threat: Where Retrieval-Augmented Generation Is Heading in 2026." 2026-04-29（更新于 2026-06-12）. https://www.bestaiweb.ai/agentic-rag-graphrag-and-the-long-context-threat-where-retrieval-augmented-generation-is-heading-in-2026/

3. EncodeDots. "The Complete Guide to RAG Architecture in 2026: Types, Use Cases, Best Practices & Enterprise Implementation." 2026-07-23. https://www.encodedots.com/blog/rag-architecture-guide

4. Singh et al. "Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG." arXiv:2501.13919. 2025. https://arxiv.org/abs/2501.13919

5. Yan et al. "Corrective Retrieval Augmented Generation." arXiv:2401.15884. 2024. https://arxiv.org/abs/2401.15884

6. Asai et al. "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection." arXiv:2310.11511. 2023. https://arxiv.org/abs/2310.11511

7. Jeong et al. "Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity." arXiv:2403.14403. 2024. https://arxiv.org/abs/2403.14403

8. Microsoft Research. "GraphRAG: Unlocking LLM Discovery on Narrative, Global Topics." 2024. https://microsoft.github.io/graphrag/

9. Liu et al. "Lost in the Middle: How Language Models Use Long Contexts." arXiv:2307.03172. 2023. https://arxiv.org/abs/2307.03172

10. Higress-RAG Framework. arXiv:2602.23374. 2026-02. 自适应路由与双混合检索。https://arxiv.org/abs/2602.23374