Agentic RAG实测：Agent循环以92.7%碾压传统管道

一个让RAG从业者意外的基准测试

开源项目 PipesHub 团队在 Google 的 FRAMES 基准上做了一组对照实验，结果颇具冲击力：精心调优的传统 RAG 管道最高只达到 78.9% 的准确率，而一个简单的 Agent 循环（能读取检索结果并再次搜索）直接拿下 92.7%——这个分数几乎等同于把正确文章直接喂给模型。

FRAMES 是专门考验多跳推理（multi-hop reasoning）的数据集，本次测试覆盖了全部 824 道多跳问题。为保证公平，所有管道变体使用了相同的模型、相同的嵌入向量、相同的文档库，唯一变化的是检索与编排策略。团队总共搭建了 18 个管道变体来逐项拆解各个组件的真实贡献。

FRAMES（Factuality, Retrieval, And Multi-hop Evaluation of Systems）是 Google DeepMind 于 2024 年发布的多跳问答基准数据集，专门用来评估模型在需要跨多个文档综合推理时的表现。与单跳问答不同，多跳推理要求系统先检索到中间事实，再以此为线索继续检索，最终拼接出完整答案——例如"某位获得X奖项的科学家所在的大学位于哪个城市"，就需要先找到获奖者姓名，再查其所属机构。FRAMES 因此比传统问答基准更能暴露检索策略的结构性缺陷，被认为是衡量 RAG 系统真实上限的严苛测试床。

混合检索、重排、查询分解到底值不值

在主流 RAG 实践中，混合检索（hybrid search）、重排（reranking）、查询分解（query decomposition）和查询扩展（query expansion）几乎被当作「标配」。但这组实验想回答的核心问题是：这些组件各自究竟带来了多少增益？

最反直觉的结论来自重排器。团队发现一个小型 reranker 反而让最佳管道的准确率下降了 9 个百分点，而换用更大的 reranker 也几乎没有带来提升。作者坦言自己此前就怀疑重排在这个任务上帮助有限，这次实验验证了这一假设。

这对很多默认「加了重排就一定更好」的工程团队是个提醒：组件的价值高度依赖任务类型和数据分布，多跳问答场景未必适用于通用的检索增强套路。盲目堆叠组件不仅可能无效，甚至会损害效果。

混合检索指将稀疏检索（如 BM25 基于词频的关键词匹配）与稠密检索（基于嵌入向量的语义相似度搜索）结合，通常用 RRF（Reciprocal Rank Fusion）等融合算法合并两路结果，目的是兼顾精确关键词命中与语义泛化能力。重排器（reranker）则是在粗召回之后引入的第二阶段排序模型，常见方案是用交叉编码器（cross-encoder）对"查询-文档"对进行更精细的相关性打分，以期从 Top-K 粗排结果中筛出真正相关的文档。这两种技术在单跳问答和关键词检索场景下往往有稳定收益，但在多跳场景中，检索的瓶颈不在于单次召回质量，而在于能否动态调整搜索方向，因此这些"精化"组件的边际价值可能远低于预期。

Agent 循环为什么能拉开差距

传统 RAG 本质上是「一次检索 + 一次生成」的线性流程，检索质量决定了答案上限。而 Agent 循环引入了迭代能力：模型可以审视第一轮检索结果，判断信息是否充分，不够就再次发起搜索。

在多跳问题中，答案往往散落在多个文档里，需要先找到线索 A 才能知道该去查线索 B。线性管道很难覆盖这种依赖链，而 Agent 循环天然契合——它把「检索」从一次性动作变成了可反复执行的工具调用。

92.7% 的成绩逼近「把正确文章直接提供给模型」的理论上限，说明在合适的编排下，检索缺陷可以通过多轮自我修正来弥补。这也呼应了业界近来从静态 RAG 向 Agentic RAG 迁移的趋势。

一个容易被忽视的评估陷阱

团队还观察到一个值得所有 RAG 评估者警惕的现象：即便明确要求模型只依据检索到的文档作答，它仍会凭记忆补全空缺，而且这些「脑补」出来的答案往往还带着看似规范的引用。

换句话说，带引用不等于有依据。如果只看最终答案是否正确、是否有 citation，很可能把模型靠参数记忆蒙对的题目也算作检索成功，从而高估系统能力。

为此，团队对每一个「正确答案」都进行了二次核验——比对系统实际读取的内容与答案是否一致。这种严格的「忠实度」校验，是让基准数字真正可信的关键步骤，也是很多 RAG 评测中被省略的一环。

这一现象被研究者称为"幻觉引用"（hallucinated citations）或参数化知识泄漏（parametric knowledge leakage）。大语言模型在预训练阶段记忆了海量事实，即便在 RAG 设定下被要求依据上下文作答，仍会在检索内容不足时将参数记忆与检索内容混合输出，并自动生成格式规范的来源标注，令其难以与真实基于文档的回答区分。这使得"答案正确率"与"检索忠实度"成为两个相互独立的评估维度。忠实度（faithfulness）评估需要验证答案中的每个关键主张是否能从检索文档中直接溯源，而非仅判断答案结论是否正确。当前许多 RAG 评估框架（如 RAGAS）已将 faithfulness 列为核心指标，但在实际工程评测中该步骤仍常被简化或跳过。

对工程实践的启示

这组实验给出了几点可直接落地的参考。其一，不要迷信「标配组件」，每个优化项都应在自己的数据上做 A/B 验证，重排器尤其需要谨慎评估。其二，对于多跳、需要信息拼接的复杂查询，Agent 循环的迭代检索可能比堆砌单轮管道技巧更划算。其三，评估阶段必须核查答案是否真的来自检索内容，否则准确率指标会失真。

需要说明的是，作者本人就职于开源项目 PipesHub，基准代码与运行手册均已公开在仓库中。这既是利益相关的披露，也意味着结论可被独立复现——这在当下充斥营销话术的 RAG 讨论中尤为难得。

不过也应客观看待：结论基于单一数据集 FRAMES，且专注多跳问答，是否能推广到其他任务类型仍需更多验证。但它至少提供了一个清晰信号——Agentic 范式在复杂检索场景下确有结构性优势。