Agentic RAG与传统RAG的对比与选型

rag-">一、对比背景：为什么需要重新审视RAG的检索质量

检索增强生成（Retrieval-Augmented Generation，RAG）已经成为构建知识问答、文档助手、企业知识库应用的主流范式。它的核心思路是在大语言模型生成答案之前，先从外部知识库中检索相关文档片段，再将检索结果作为上下文提供给模型，从而减少幻觉、提升答案的事实性和可追溯性。

然而，传统RAG在实际落地中暴露出一个普遍问题：检索质量高度依赖原始查询的表述方式。用户提出的问题往往存在口语化、指代不明、关键词缺失、术语不规范等情况，导致向量检索或关键词检索返回的文档与真实意图偏差较大。更棘手的是，传统RAG流程通常是一次性的——检索完成后直接将结果送入生成环节，即使检索结果明显不相关，系统也没有机制进行纠正，只能基于低质量上下文“硬生成”答案。

Agentic RAG正是在这一背景下提出的改进方案。它的核心主张是：将检索从一次性动作升级为可控制、可评估、可重试的循环过程。本文将从架构设计、质量关卡、失败恢复、使用边界等维度，对传统RAG与Agentic RAG进行系统对比，帮助读者判断在什么条件下应该引入后者，以及在迁移过程中需要关注哪些问题。

二、对比对象定义

2.1 传统RAG

传统RAG的流程可以概括为三个固定阶段：

1. 索引阶段：将文档加载、切分、向量化后存入向量数据库；
2. 检索阶段：对用户查询进行向量化，通过相似度匹配召回Top-K文档片段；
3. 生成阶段：将检索到的文档片段与用户查询拼接为提示词，交给大语言模型生成答案。

这个流程结构简单、实现成本低，但缺乏对中间结果的质量判断。检索器返回什么，生成器就用什么，系统不具备“质疑”检索结果的能力。

agentic-rag">2.2 Agentic RAG

Agentic RAG在传统RAG的流程中引入了智能体决策节点和质量检查环节。其基本工作逻辑是：

1. 智能体首先判断用户问题是否需要检索外部知识；
2. 若需要检索，调用检索工具获取候选文档；
3. 对检索结果进行相关性评分；
4. 若评分达标，进入生成环节；
5. 若评分不达标，触发查询重写，用改写后的查询重新检索；
6. 循环执行上述过程，直到获得合格上下文或达到最大重试次数。

可以看出，Agentic RAG的核心差异不在于检索算法本身，而在于在检索流程中嵌入了控制回路，使系统具备了自我检查和自我修正的能力。

三、相同点分析

尽管Agentic RAG在流程控制上做了显著增强，但它与传统RAG共享大量基础能力：

3.1 底层检索技术一致

两者都依赖向量检索或混合检索技术。文档的向量化表示、相似度计算、索引构建等基础组件完全相同。Agentic RAG不是替代这些技术，而是在其上增加了一层控制逻辑。

3.2 目标一致

两者的最终目标都是为大语言模型提供高质量的上下文，从而提升生成答案的准确性、相关性和可追溯性。无论流程中是否包含评分环节，这一根本目标没有变化。

3.3 索引管线可复用

文档加载、文本切分、嵌入生成、向量存储这条索引管线在两种方案中完全通用。从传统RAG迁移到Agentic RAG时，已经构建好的向量索引通常不需要重建。

3.4 生成环节的运作方式相同

一旦获得了合格的上下文文档，两者的生成逻辑完全一致：将上下文和用户问题按模板拼接，调用大语言模型生成最终答案。生成环节的提示词工程、上下文窗口管理、引用标注等实践可以无缝复用。

四、核心差异分析

4.1 架构差异：线性管道 vs 控制回路

传统RAG采用线性管道架构：查询 → 检索 → 生成。每个阶段只执行一次，数据单向流动，没有反馈路径。这种架构的优势在于简单、可预测、调试容易，但缺点是一旦某个环节出错，错误会被静默地传递到最终答案中。

Agentic RAG采用带控制回路的图结构：智能体 → 检索工具 → 评分 → [合格→生成 | 不合格→重写→智能体]。图中的关键设计是从“重写”节点返回“智能体”节点的边，这构成了一个闭环。系统可以多次经过检索环节，每次根据上一轮的失败原因调整策略。

从工程实现角度看，传统RAG可以用简单的函数调用链实现，而Agentic RAG通常需要基于有状态的工作流框架来构建，因为循环过程需要维护状态、记录重试次数、传递中间结果。

4.2 质量保障机制：无检查 vs 多级检查

传统RAG对检索结果的质量没有显式的检查机制。检索器返回Top-K结果后，系统默认这些结果就是可用的。即使返回的文档全部与问题无关，生成环节也只能照单全收。

Agentic RAG引入了显式的相关性评分环节。评分器对每个检索结果与用户问题的匹配程度进行判断，输出“相关”或“不相关”的二元结论，某些实现中还会给出更细粒度的分级。这个评分节点是整个系统最关键的质量关卡——只有通过评分的上下文才能进入生成环节。

4.3 失败恢复能力：硬失败 vs 软恢复

这是两者最根本的行为差异。

当传统RAG检索到不相关文档时，系统没有任何恢复手段。它不会意识到“检索失败了”，因此也就不会去改变策略重新尝试。最终呈现给用户的，往往是一份基于不相关上下文生成的“牵强附会”的答案，或者直接返回“未找到相关信息”。

Agentic RAG在检测到检索失败后会主动进入恢复流程。恢复的核心手段是查询重写：

• 将口语化表达转换为更规范的关键词组合；
• 补充缺失的领域术语或同义词；
• 调整查询的粒度（太宽泛则收窄，太具体则放宽）；
• 必要时将复杂问题拆解为多个子查询。

重写后的查询被送回检索器重新执行，整个过程构成一个检索-评估-修正的循环。这种设计使系统在面对初次检索失败时不会立即放弃，而是有策略地调整后再试。

4.4 决策能力：无决策 vs 有条件路由

传统RAG中不存在“决策”环节。无论用户问什么，系统都会走检索流程。这导致两类问题：对于简单的事实性问题（如“1+1等于几”），系统无谓地执行检索，增加了延迟和计算成本；对于需要检索的问题，系统也没有能力判断检索结果是否足够好。

Agentic RAG的智能体节点承担了入口决策职责。它首先判断用户问题是否需要外部知识检索，只有确认需要时才调用检索工具。这种条件路由能力避免了不必要的检索开销，也使系统行为更加贴近真实场景中“人”的决策方式——先想清楚需不需要查资料，再决定去查。

4.5 复杂性与运维成本

传统RAG的组件数量少、依赖关系简单，部署和调试的复杂度较低。监控的核心指标主要是检索延迟、索引大小和生成质量。

Agentic RAG引入了额外的组件（评分器、重写器、智能体状态管理），这带来：

• 更高的实现复杂度：需要定义状态结构、循环条件、终止策略；
• 更多的调试场景：可能出现评分器误判、重写器生成无效查询、循环不能收敛等新问题；
• 更高的运维要求：需要监控重试次数分布、评分通过率、重写有效性等新指标；
• 更长的响应延迟：多次检索-评分循环会显著增加端到端延迟，尤其在最坏情况下（重试耗尽）延迟可能翻倍。

下表总结了上述核心差异：

对比维度	传统RAG	Agentic RAG
流程结构	线性管道，单次执行	带反馈回路的图结构，可循环
质量检查	无显式检查	有评分节点把关
失败恢复	无恢复能力，硬失败	查询重写后重试，软恢复
入口决策	无条件执行检索	智能体判断是否需要检索
实现复杂度	低	中高，需状态管理
端到端延迟	较低且稳定	正常路径略高，重试路径显著增加
运维监控	简单	需增加循环相关指标
调试难度	低	中高，失败模式更多样

五、典型场景选择

5.1 传统RAG更适合的场景

（1）查询质量可控的封闭场景

如果用户的查询来自下拉菜单、表单选项或预定义模板，查询表述本身已经是规范化的，检索失败的概率很低。此时引入Agentic RAG的控制回路属于过度设计。

（2）对延迟有严格要求的在线服务

在实时对话、在线客服等场景中，用户对响应时间敏感。Agentic RAG的多次检索-评分循环可能导致可感知的延迟抖动。如果业务优先级是“快”而非“准”，传统RAG的确定性延迟特性反而更有优势。

（3）知识库内容同质且检索难度低

当知识库规模较小、文档主题集中、术语一致性高时，即便用户的原始查询不够规范，向量检索通常也能召回正确的文档。这种情况下的“检索失败率”本身就很低，引入修正机制收益有限。

5.2 Agentic RAG更适合的场景

（1）开放域问答，查询表述高度不可控

如果系统面向公众用户开放，用户会用什么方式提问完全不可预测。口语化、碎片化、模糊化的查询是常态。Agentic RAG的查询重写能力在此类场景中能够发挥直接价值。

（2）知识库规模大、异质性强

当知识库涵盖多个领域、文档写作风格差异大、术语体系不统一时，单一查询的检索召回质量会显著下降。Agentic RAG的多轮重试和策略调整能够在失败后尝试不同的查询表述，提高最终找回正确文档的概率。

（3）答案质量要求高、错误成本大

在医疗咨询、法律辅助、金融分析等专业场景中，基于错误上下文生成的答案可能造成严重后果。此时，系统值得为“确认检索质量”付出额外的延迟和计算成本。评分环节相当于给生成器加了一道安全门。

（4）需要与外部工具交互的复杂任务

Agentic RAG的智能体决策能力不只限于“要不要检索”，还可以扩展到“调用哪个数据源”“是否需要进行计算”“是否需要查询数据库”等多工具路由场景。这是传统RAG的线性管道难以支撑的。

六、选型建议

选型不应基于“新不新”或“先不先进”，而应基于检索失败的实际概率、失败成本与恢复收益的平衡。

以下条件化判断思路可以作为参考：

• 如果检索失败率实测低于5%，且用户对偶尔的不相关回答容忍度高，传统RAG足以满足需求。引入Agentic RAG的额外复杂度不划算。
• 如果检索失败率在5%到20%之间，且业务对答案准确性有明确要求，建议开始考虑Agentic RAG。可以先只引入评分和重写两个节点，不做完整的智能体入口决策，以控制复杂度。
• 如果检索失败率超过20%，或者存在多数据源路由需求，Agentic RAG的价值会显著超过其成本，值得完整引入。

团队能力也是重要考量因素。 如果团队对工作流框架、状态管理和图结构调试不熟悉，直接上手完整的Agentic RAG可能遇到较大学习成本。此时建议分阶段演进：先加上检索后评分，再加重写重试，最后引入智能体入口决策。

七、迁移与使用注意事项

从传统RAG迁移到Agentic RAG，不需要重建索引管线，但以下问题需要提前评估。

7.1 循环终止条件设计

Agentic RAG的循环必须有明确的终止条件。典型的终止条件包括：

• 评分通过，进入生成；
• 达到最大重试次数N，强制进入生成（使用当前上下文）或返回降级答案；
• 重写器连续生成相同查询，检测到循环停滞，提前终止。

伪代码示例如下：

function agentic_retrieve(query):
    max_retries = 3
    current_query = query
    for attempt in range(max_retries):
        # 步骤1：执行检索
        docs = retrieve(current_query)
        # 步骤2：相关性评分
        grade = evaluate_relevance(current_query, docs)
        # 步骤3：判断是否合格
        if grade.is_relevant:
            return docs
        # 步骤4：不合格则重写查询
        new_query = rewrite_query(query, docs, grade.feedback)
        # 步骤5：检查是否陷入停滞
        if new_query == current_query:
            break
        current_query = new_query
    # 重试耗尽后的降级策略
    return fallback_response(query)

7.2 评分器的误判风险

评分器本身也可能出错。误判为“相关”会导致不相关上下文溜进生成环节，Agentic RAG的安全网失效；误判为“不相关”会导致不必要的重试，浪费计算资源并增加延迟。实践中需要根据具体业务调整评分器的判定阈值，并定期用真实查询数据验证评分准确率。

7.3 重写器的质量依赖

查询重写的效果直接影响系统的恢复能力。如果重写器只是简单做同义词替换，对复杂的检索失败场景帮助有限。建议在重写器中加入：

• 提取用户原始查询中的核心意图；
• 识别并修正口语化表达；
• 补充领域术语和关联概念；
• 将过长或过短的问题调整为适合检索的长度。

7.4 延迟预算控制

Agentic RAG在重试场景下会增加端到端延迟。面向在线服务时，需要为整个检索-评分-重写循环设置总体延迟预算。当预算耗尽时，系统应退回最后一次检索结果或启动降级策略，而不是无限循环。

7.5 日志与可观测性

由于Agentic RAG的执行路径具有分支和循环特性，简单的线性日志不足以支撑问题排查。建议至少记录以下信息：

• 每次循环的轮次编号；
• 当前使用的查询文本；
• 检索返回的Top-K文档标识和相似度分数；
• 评分器的判定结果和置信度；
• 重写器生成的新查询及与原查询的差异；
• 最终进入生成的上下文来源（第几轮检索结果）。

这些日志对于理解系统行为、定位“为什么这次检索失败了”和“为什么重写没有效果”等问题至关重要。

八、总结

传统RAG与Agentic RAG的本质区别不在于检索算法或生成模型，而在于系统是否具备对自身检索行为的检测与修正能力。传统RAG将检索视为一个“发射后不管”的环节，而Agentic RAG在检索流程中嵌入了智能体决策、质量评分和查询重写三个关键节点，使系统从“一次性尝试”升级为“带有自我修正的循环过程”。

这种升级不是没有代价的。更高的实现复杂度、更长的响应延迟、更复杂的调试和运维需求，都是选择Agentic RAG时必须承担的成本。因此，选型的关键在于评估检索失败的概率和失败的代价：当检索失败频繁发生且答案质量至关重要时，Agentic RAG的自我修正机制是值得投入的；当查询质量可控、检索失败率低、或者延迟敏感时，传统RAG的简洁和确定性反而是优势。

对于计划迁移的团队，建议采取渐进策略：保留已有的索引管线，先引入评分节点积累对检索质量的真实度量数据，再决定是否需要进一步引入查询重写和循环控制。用数据驱动的判断替代对新概念的盲从，是更稳健的工程选择。