常被当作RAG必备的小重排器，实测让准确率掉9个百分点

我们对照 Google 的 FRAMES 基准，把 18 种 RAG 管道和一个代理循环做了对比。最佳管道拿到 78.9%，代理循环拿到 92.7%。

混合搜索、重排、查询分解和查询扩展常常被视为做好 RAG 的必备组件。我们想看看每一项到底有多大帮助，所以做了测试。相同的模型、相同的嵌入、相同的文档，覆盖 FRAMES 中全部 824 个多跳问题。

我们构建了 18 种管道变体。最佳得分为 78.9%。我们的代理循环（带有检索工具）能够读取结果并再次搜索，得分为 92.7%——大致相当于直接把正确文章交给模型。

重排器的结果可能会让你意外。一个小型重排器让最佳管道的准确率掉了 9 个百分点，而一个更大的重排器几乎没什么帮助。我之前就怀疑重排在这里帮助不大，但想验证一下这个假设。

我们还注意到一件事：即使明确告诉模型要忠于检索到的文档，模型有时还是会从记忆里补全空缺。那些答案仍然可能满是引用。我们最后把每个正确答案都和系统实际读到的内容做了核对。

如果你感兴趣，这里是完整报告：
Agentic RAG vs. traditional RAG on FRAMES

全披露：我在 PipesHub 工作，它是开源的。基准测试代码和运行手册在仓库里：[https://github.com/pipeshub-ai/pipeshub-ai/tree/frames1

关于这些数字的含义，简单说明一下：它们是端到端的答案准确率，不是检索分数。每个答案都由一个 LLM 裁判（Claude Sonnet 5）使用 FRAMES 论文自己的评分提示进行评估，并由第二个裁判（Gemini Flash 3.8）独立复评。两者在几乎所有答案上意见一致（Cohen“s κ 0.93–0.98）。我们还把每个正确答案与系统实际看到的文本做了比对，所以那些来自模型记忆的答案不会被算作检索的功劳。

―― 高票评论(帖子共 43 条讨论)――

[+12] u/DistanceAlert5706: 这些百分比是什么意思？
通常你测试检索质量时会用 mrr@k 或 precision@k。

你的重排结论完全不对，重排器的作用是提升排序、改善@1精确率，它不会影响候选检索质量。

真正的答案和生成部分通常用 LLM 作为裁判来测试评估。

另外，在一个 RAG 本不适合的任务上测试 RAG，然后说 RAG 不好，这种做法有问题。人们到处塞 LLM，而现在的毕业生根本不知道重排器是什么。

[+3] u/Rachel_talks: 这里掩藏的细节——记忆补全检查——值得单独发一篇帖子。我在发布之前对所有内容都会跑一遍主张核查——不是因为这些文字写得不好，而是因为引用是双向最容易造假的东西。一篇文章可以引用三个真实来源，但其核心主张却来自模型先验知识。半数引用会被挂到来源根本不支持的那些句子上。

真正有效的检查很笨：每个主张都对照抓取到的文本去匹配，而不是对照引用列表。如果一个句子没有模型先验知识就站不住，那就会被删掉或改写为来源实际支持的表述。

让我意外的是它有多依赖主题。冷门话题几乎不需要检查——没什么可补的。危险区是那些模型”知道“的东西：价格、日期、规格表，任何略带过时的先验知识读起来都完全像一个正确答案。

[+0] u/numberwitch: 呵欠

[+2] u/Strong-Leg-9636: 这个方法很扎实，把每个正确答案与系统实际读取的内容进行核对、而不仅仅是看最终文本，这是大多数基准测试报告都会略过的部分，而正是这一点才能让你发现模型在靠记忆作答并附带假引用。双裁判在那样高的 Cohen”s kappa 下达成一致，也是一个大多数人懒得做的合理健康检查。

重排器的发现仍然让我在意。一个更差的重排器竟然主动扣掉 9 分，而不只是没起作用，说明它是在自信地把好结果重新排到靠后位置，而不是仅仅制造噪声。

报告里我没看到的一点是：92.7% 的代理循环和 78.9% 的最佳静态管道之间，延迟/成本差异有多大？如果代理循环每个问题都要发起多轮检索，那对准确率的提升来说就是一个实实在在的取舍，取决于具体使用场景。

[+1] u/Icy_Butterscotch6661: 那时间花费呢

[+1] u/CalligrapherFar7833: “我们”是谁？

[+1] u/Marcus_MSC: 92.7% 的结果很有说服力，尤其是结合了对代理实际读取内容的检查。我希望除了管道结果之外，还能看到每个问题在搜索次数、模型调用和 token 上的分布。一个在大多数问题上只多花一点、但在少数问题上多花很多钱的循环，和一个成本可预测的循环，是截然不同的部署选择。

[+1] u/wayne_oddstops: 大批铁皮人一起涌进来推动“讨论”、制造参与度上涨，这在你试图触达的那类人眼里是个大红旗。

[+1] u/9gxa05s8fa8sh: RAG 重要，但没法轻易做出强大方案。企业付得起几个百分点的性能提升，但看起来普通人还是会用本地简单搜索应用。

[+0] u/mb194dc: RAG AL 加上你选的逻辑引擎，跑在本地，才是赢家……

那在 S1 中，赢的是哪个。.？

[+0] u/wren6991: LLM 生成的文章配一个薄薄的广告，还有一堆 LLM 生成的回复说它多么诚实、多么有分量。为什么这还挂着？

[+-1] u/xmnstr: 对我来说 RAG 已经死了，类型化图才是正道。