RAG 优化叠加，为何收益没有相加

RAG 效果不好，就加混合检索、查询扩展、重排器，听起来很合理。但单项测试都涨分，接起来却未必更好。原文讨论的正是这个落差：组件之间会互相干扰，检索指标上涨，也不保证回答更可信。

作者引用一组覆盖 450 种流水线配置的实验，提醒团队把优化对象从「某个检索组件」移到「整条问答链路」。对正在给知识库加功能的程序员来说，最有用的问题是：新增环节到底解决了用户的问题，还是只改善了一张测试报表？

三项优化各自有效，为什么接起来只剩 +17%？

原文先描绘了一条常见升级路线：基础稠密向量检索对领域术语不够精准，于是加入 BM25 混合检索，测试提升 15%；再加入倒数排名融合（reciprocal rank fusion，RRF），提升 18%；接着通过 HyDE 做查询扩展，又提升 14%。

这些数字是文章开头的情境描述，不能直接当成后续实验的逐项数据。它们制造的诱惑很直观：三次两位数提升，仿佛能让系统比基线好近 50%。但作者描述的生产结果却是，幻觉投诉没怎么减少，延迟变成三倍。

原文随后引用 IBM 与 Weizmann Institute of Science 研究团队的论文《Retrieval Augmented Generation Compositionality》，编号为 arXiv:2610.29722。研究者 Ido Levy、Segev Shlomov 和 Leshem Choshen 使用开源评估框架 LASAGNA，测试了八个标准基准上的 450 种流水线配置。

其中最关键的对比，是三种技术的独立收益推算与实际组合收益。这段示意保留了原文的量级：

Expected additive gain:  [=============================== +47%]
Actual composed gain:    [=========== +17%]

要看的是第二行：组合后实际测得 +17%，比预期少了 30 个百分点，接近三分之二的预期收益没有兑现。

单项增益不能直接相加，因为后一个组件接到的输入，已经被前一个组件改过了。

查询改写可能把问题扩展到相邻却无关的主题；cross-encoder 重排器需要处理这些新增干扰项，而它训练时面对的段落分布未必如此；上下文压缩器又可能依据局部 token 显著性裁剪内容，破坏完整的事实关系。

最后交给生成模型的材料，可能每段都很像答案，却缺少真正能定论的那一句。

Recall@K 涨了，回答为什么反而更容易编？

很多团队用 Recall@K 或平均倒数排名（MRR）评估检索。它们能帮助判断相关材料是否被找到、排得是否靠前，但无法独自回答另一个问题：模型最终有没有忠实依据材料作答？

原文称，LASAGNA 的部分配置在提高召回的同时，也增加了生成结果中的事实幻觉。

这里的冲突不难理解。为了提高召回，系统把多个重叠片段塞进上下文。如果三个片段存在措辞冲突，或者分别对应不同时间，模型可能把它们拼成一个听起来通顺的结论，而没有依据其中具有权威性的句子回答。

问题因此不只是「有没有找全」，还包括「找回来的材料能不能共同支持一个答案」。

不过，原文没有交代这些冲突样本的具体比例、生成模型配置和忠实度评分方法。可以从中接受评估方向上的提醒，但不能据此断言提高召回必然增加幻觉。

检索质量与回答质量仍然都要测，只是不能把两份各自漂亮的成绩单，当成整条链路可靠的证明。

在 5,000 篇文档上调好的配置，为什么上线就变味？

实验语料规模从 5,000 篇扩展到 50,000 篇，再到 200,000 篇。原文称，小语料上领先的配置，在规模扩大后经常被其他配置超过。

作者给出的解释是：候选文档越多，与问题表面语义相似、实际上却不相关的内容也会增多。小语料中有帮助的宽泛查询扩展，到了大语料中可能召回大量高分噪声。更严格的词法过滤，以及更保守的检索数量，此时可能更占优势。

这也是 chunk 切分策略、top-k 参数和重排阈值不能脱离数据规模讨论的原因。同一个 top-k，放在几千篇文档和几十万篇文档的索引里，背后的候选竞争已经不同。

但原文把小规模调参描述为到了生产环境「几乎必然失败」，这个判断过强。实验能支持配置排名可能变化，不能直接推出所有小规模调参都无效。文档重复程度、领域分布和版本冲突，也会影响结果，文章没有逐项展开。

我的判断

我认同作者把新增组件视为一种「交互成本」：它不仅增加计算，还改变后续组件面对的数据。团队应该要求它在现有流水线中证明收益。

但这篇文章给出的证据摘要，还不足以指导具体选型。它没有列出三项组合技术的完整配置，也没有解释 +47% 与 +17% 对应的指标、计算口径和统计波动。开头的 15%、18%、14% 更不能直接拿来复现论文结果。论文编号、开源框架和实验结论，在所给材料里也没有进一步核验依据。

因此，「组件越少越好」更适合作为工程偏好，而非已经证明的普遍规律。相比继续叠加查询扩展和重排，检查文档版本、权威来源与片段冲突，也值得进入排查顺序；但原文没有给这些替代做法的对照数据，不能承诺它们一定更有效。

该保留的不是最短流水线，而是能在目标语料和真实任务上证明收益的流水线。

能拿来做什么

• 给现有知识库问答建立一组固定问题，同时检查检索结果和最终回答。涉及版本、时间与来源冲突的问题，应单独观察，避免只看 Recall@K 或 MRR。
• 在 Node 问答服务中加入 HyDE、BM25 或 reranker 前，先记录当前答案质量与延迟，再测试新增环节的实际组合，并通过移除组件判断它是否仍有贡献。
• 调整 chunk、top-k 和重排阈值时，用接近生产规模与内容分布的索引复测。如果目前只有 5,000 篇文档的测试集，就把结论明确限制在这个范围内。