当LLM遇到知识库，检索增强生成(Retrieval-Augmented Generation，RAG)系统应运而生。但随着技术演进，两种截然不同的范式正在争夺主导地位：一种是通过精心设计的模块链条逐步优化的"增强型RAG"，另一种是让LLM自主决策、动态调整的"Agentic RAG"。哪种方案更值得采用？成本与性能如何权衡？论文通过大规模实验给出了答案。
问题的核心：基础RAG的四大短板
论文指出，最简单的RAG系统（称为"朴素RAG"）存在明显缺陷：即使用户查询不需要外部知识，系统也会强制执行检索；查询与知识库文档在格式或语义上存在错配，导致检索效果不佳；检索结果可能包含噪声或次优文档；底层LLM的能力、成本和响应时间差异巨大。
为解决这些问题，业界发展出两条路径。增强型RAG通过添加专门模块来修补漏洞：路由器判断是否需要检索，查询重写器调整查询格式，重排序器筛选最相关文档。而Agentic RAG则让LLM成为"指挥官"，自主决定何时检索、如何改写查询、是否需要迭代——整个流程不再是固定管道，而是灵活的决策循环。
[Figure 1: 增强型RAG与Agentic RAG的架构对比] 左侧展示增强型RAG的固定流程：路由器→查询重写器→检索器→重排序器→生成器，每个模块负责特定任务。右侧展示Agentic RAG的动态流程：LLM作为agent在每一步自主选择是否调用RAG工具，可以多次迭代检索和上下文优化。
实验设计：四个维度的正面交锋
论文选取了四个代表性数据集进行测试：金融问答(FIQA)、通用问答(Natural Questions，NQ)、事实验证(FEVER)和论坛问题匹配(CQADupStack-English)，覆盖了问答(QA)和信息检索提取(IR/E)两大应用场景。
[Table 1: 评估维度总结] 针对朴素RAG的每个缺陷，论文定义了评估维度和对应的实现方案。增强型RAG使用语义路由、HyDE查询重写和编码器重排序；Agentic RAG则由agent自主决策是否检索、如何重写查询以及是否重复检索。
用户意图处理方面，增强型RAG使用semantic-router框架，通过示例查询集合进行分类；Agentic RAG则依靠LLM自行判断。实验在每个数据集上测试了500个有效查询和500个无效查询。
查询重写方面，增强型RAG强制执行HyDE方法（将查询改写为回答该问题的段落）；Agentic RAG可自由决定是否重写及如何重写。评估指标采用NDCG@10(Normalized Discounted Cumulative Gain，归一化折损累积增益)，衡量检索文档的排序质量。
[Table 2: 数据集概览] 四个数据集的查询数量从648到6666不等，文档数量从4万到268万不等，每个查询平均关联1.2到2.6个相关文档。
文档列表优化方面，增强型RAG使用基于ELECTRA的重排序模型筛选前20个候选文档；Agentic RAG通过多轮检索迭代优化上下文。
底层LLM影响方面，论文测试了Qwen3系列的四个规模模型（0.6B、4B、8B、32B参数），使用LLM-as-a-Judge范式（Selene-70B模型）评估最终答案质量。
实验结果：各有千秋的性能表现
在用户意图处理上，Agentic RAG在金融问答和论坛匹配任务中表现更优，F1分数分别达到98.8和99.8，而增强型RAG为95.7和96.6。但在事实验证任务(FEVER)中，增强型RAG以87.9的F1分数大幅领先Agentic RAG的64.6。论文分析认为，金融和语法论坛有明确的领域边界，agent更容易判断；而事实验证任务范围宽泛，agent难以准确识别哪些查询需要检索。
[Table 3: 用户意图处理性能] 在500个有效和无效查询的测试中，朴素RAG对所有查询都执行检索（召回率100%但F1仅66.7）。Agentic RAG在FIQA和CQA-EN上F1分数接近100，但在FEVER上召回率仅49.3。
查询重写带来了显著提升。Agentic RAG在四个数据集上的平均NDCG@10达到55.6，比朴素RAG提高5.3个百分点，比增强型RAG高2.8个百分点。论文认为，agent能够根据具体情况灵活决定是否重写以及如何重写，这种自适应能力是其优势所在。
[Table 4: 查询重写性能] 朴素RAG直接使用原始查询，平均NDCG@10为50.3。增强型RAG通过HyDE重写提升至52.8，Agentic RAG达到55.6。在FEVER任务上，Agentic RAG的NDCG@10达到83.1，比朴素RAG高出16.9个百分点。
文档列表优化方面，增强型RAG的重排序模块效果明显。在金融问答任务中，增强型RAG（含重写）的NDCG@10为51.0，而Agentic RAG仅为43.4。论文发现，agent虽然可以多次迭代检索，但无法像专门的重排序模型那样有效筛选最相关文档。
[Table 5: 文档列表优化性能] 朴素RAG的NDCG@10为45.5，增强型RAG通过重排序提升至49.5，而Agentic RAG反而下降至43.9。这表明显式的重排序步骤对提升检索质量至关重要。
底层LLM规模的影响在两种范式中呈现相似趋势。随着模型参数从0.6B增加到32B，两种系统的性能都稳步提升，且提升幅度相当。这说明模型能力的改进对两种范式的影响是一致的。
[Figure 2: 不同规模LLM的性能表现] 在FIQA任务上，随着模型规模增大，两种系统的分类指标都从约50%提升至95%左右。在CQADupStack-EN任务上，更大模型生成的答案被判定为更优的比例也呈现相同的上升趋势。
[Table 6: Qwen3系列模型性能] 在通用能力(GPQA-D)、指令遵循(IFEVAL)和数学推理(AIME)三个基准测试中，0.6B模型平均得分26.9，而32B模型达到78.3，显示出显著的能力差距。
成本与时间：不容忽视的现实考量
Agentic RAG的灵活性是有代价的。在金融问答任务中，Agentic RAG平均消耗的输入token数是增强型RAG的2.7倍，输出token数是1.7倍；在论坛匹配任务中，这一差距扩大到3.9倍和2.0倍。响应时间方面，Agentic RAG平均慢1.5倍。
论文详细分析了成本构成：两种系统都需要t3.large EC2实例运行向量数据库（每小时0.09美元）和t2.medium实例运行后端（每小时0.05美元）。开源LLM部署在8×A40 GPU集群上，等效AWS成本约每小时1.9美元。增强型RAG的重排序模型（300M参数）成本可忽略不计。
在增强型RAG中，约45-50%的时间用于生成答案，类似比例用于查询重写，检索和重排序各占0-5%和0-2%。这意味着优化重点应放在LLM调用上。
[Table 9: 时间与token消耗对比] 详细列出了两种系统在不同任务上的平均输入/输出token数和响应时间。Agentic RAG在所有场景下都消耗更多资源，但具体倍数因任务而异。
写在最后：没有银弹，只有权衡
论文的结论清晰而务实：增强型RAG和Agentic RAG各有优劣，选择取决于具体场景。
在领域明确、用户行为结构化的场景中，Agentic RAG的自主判断能力更有价值；但在领域宽泛或噪声较多的环境中，增强型RAG的路由系统更可靠。查询重写方面，Agentic RAG的动态适应能力带来更好的检索质量。然而，在文档筛选上，增强型RAG的显式重排序模块明显更有效——论文建议将重排序步骤整合到Agentic流程中可能带来显著收益。
成本分析揭示了一个关键事实：Agentic RAG的灵活性以高达3.6倍的成本为代价。对于预算敏感的应用，精心优化的增强型RAG可以在保持或超越Agentic性能的同时，显著降低开支。
论文也坦诚指出了研究的局限：未涵盖文档摘要、上下文重排等维度；agent仅配备单一工具，更复杂的工具集可能产生不同结果；每个增强型RAG模块的实现方案未进行全面对比。
最终建议：根据应用场景的领域特性、成本预算和性能要求，在两种范式间做出明智选择，而非盲目追逐新技术。
