RAG 领域有一个心照不宣的假设：每个环节都有开源排行榜证明自己有效，那么把验证过的组件串起来，效果理应叠加。嵌入模型选个高分 reranker，检索再加一层 query expansion，生成端上个 context compression——1+1+1 应该大于 3。

10 月 21 日提交到 arXiv 的论文《Retrieval Augmented Generation Compositionality》（arXiv:2610.29722）用 450 组受控实验给了这个假设一记闷棍：三个各自有效的检索技巧，单独评测预期合计提升 47%，真组合起来只有 17%。

论文做了什么

作者 Ido Levy、Segev Shlomov、Leshem Choshen 搭了一个叫 LASAGNA 的开源评估框架，核心方法论是「预注册假设 + 全栈受控实验」：

• 450 组配置，覆盖嵌入、分块、检索、重排、查询增强、上下文压缩、Agent 式验证等 RAG 全流程组件；
• 8 个基准，语料规模从 5K 到 200K 文档横跨四个数量级；
• 103 页论文、68 张表格，代码开源。

这不是又一篇「我们提出新方法」的论文，而是一篇方法论审计——它量的是现有技巧在真实组合中到底兑现了多少承诺。

三个反直觉的发现

一、单点有效 ≠ 组合有效。 三个检索技巧独立评估时预测合计 +47%，实际组合只拿到 +17%。原因不难想象：它们优化的往往是同一批失败案例，收益高度重叠；而各自的副作用（比如 query expansion 引入的噪声）却会叠加。这和软件工程里的经典教训同构——独立测试通过的模块，集成测试照样会炸。

二、检索质量和答案忠实度遵循不同的组合规律。 一个对检索命中率有效的组件组合，可能损害答案的忠实度（faithfulness），反之亦然。如果你的评估只看检索指标，优化方向可能正在悄悄毁掉生成质量——这对所有「用检索指标选型」的团队是一记警告。

三、最优组合随语料规模漂移。 在 5K 文档的小语料上夺冠的配置，到 200K 文档规模可能不再是最佳。小语料上做的方法验证，不能直接外推到生产规模——而大多数论文的实验规模，恰恰都很小。

对工程团队的三个实操结论

1. 选型必须带全栈测。评估任何新 RAG 组件时，把它放进你自己的完整 pipeline 测，而不是相信它在论文基准上的孤立增益。LASAGNA 开源框架的意义正在于此——它让「在我的栈里跑一遍」变得可执行。
2. 检索指标和忠实度要一起监控，只看一头的优化迟早翻车。
3. 在接近生产规模的语料上验证，小规模实验的结论不要直接搬。

结语

这篇论文的立场其实很谦逊：它没有提出新技术，只是证明了「组合性」本身是需要被研究的对象。对一个开源组件满天飞、基准榜单日更的领域来说，这可能是比又一个 SOTA 更有价值的东西——RAG 工程的下一步成熟标志，不是更多组件，而是知道哪些组件能一起活下来。

顺带一提，论文的命名颇有意趣：LASAGNA（千层面），一层层叠起来的 RAG 组件，正如千层面——叠错了层，整锅都塌。

参考来源： - arXiv:2610.29722《Retrieval Augmented Generation Compositionality》（Ido Levy, Segev Shlomov, Leshem Choshen，2026-10-21 提交） - arXiv-vanity 论文页：https://arxiv-vanity.com/papers/2610.29722