图中不同查询各自产生一个排名列表，融合时对同一文档累加排名贡献。
同一个问题换几个表达再检索，结果未必能直接拼起来。不同列表有自己的顺序，分数尺度也可能不同。RAG-Fusion 把多查询召回与排名融合连接起来，其中常见的 RRF 规则不比较原始分数，而是根据文档在各列表里的名次累计贡献。
先生成不同的搜索入口
自设一个问题：“离线部署时怎样核对模型资源完整？”可以分别围绕文件校验、版本兼容和加载失败检索，再把候选归并。前提是这些视角仍然服务原问题，而不是把离线要求改成下载在线资源。
多查询不是越多越好。若只是把一句话换几个同义词，它们可能召回几乎相同的资料，却增加生成和检索成本。若生成器扩展了未经确认的实体或条件，又可能把候选池带偏。因此查询生成与结果融合应分别检查。
RRF 用名次换成可相加贡献
本文约定名次从一开始，某文档在一个列表里排第 r，贡献记为 1/(k+r)，k 为非负的平滑常数。把文档在各列表中出现时的贡献相加，再按总和排序，就是这里采用的基本 RRF。
没有出现在某个截断列表中的文档，在这一列表贡献为零，不是给它随意补一个不存在的名次。一个列表内部重复出现同一文档，也应该先按约定去重，不能让它在同一路里重复投票。跨列表的同一文档则累加不同路径的贡献。
这里按排名而不是原始分数融合，可以避免直接相加不同量纲的分值。但它也舍弃了原始分数的间距信息：第一名领先第二名多少，在这个公式里没有被直接保留。
用两个短列表算一遍
令列表 A 为 [a，b，c]，列表 B 为 [b，d，a]，示例取 k=60。a 的贡献为 1/61 加 1/63，约为 0.03227；b 为 1/62 加 1/61，约为 0.03252，因此 b 排在 a 前。
d 只在 B 的第二名出现，得分约为 0.01613；c 只在 A 的第三名出现，约为 0.01587。最终顺序是 b、a、d、c。这个例子说明多路较靠前的共同结果会得到累计支持，不表示它一定是事实最正确的文档。
k 取六十是常见示例和研究设置之一，不是对所有数据集都最优的常数。k 越大，前几名之间的贡献差异相对越平缓；不同常数还会与列表长度、出现次数产生共同影响，应在明确口径下比较。
文档身份要先统一
如果同一段落在两条结果里分别使用带参数 URL 和原始 URL，直接按字符串去重可能把它当成两份材料。相反，两个不同版本若错误共用同一标识，又可能被合并得只剩一份。融合之前，需要明确标识代表文档、版本还是片段。
可以保留融合得分、各路名次和来源映射，方便解释某个结果为什么上升。若只留下总分，后来发现一个查询被重复生成，就难以判断它对结果贡献了多少额外权重。重复查询会放大相关列表的影响，并不构成独立证据。
分数相同还应有明确的稳定排序规则，例如按固定标识排序。否则同一输入多次运行出现不同先后，会干扰后续比较，甚至让测试误以为策略发生变化。
融合之后仍要核对证据
RRF 不理解某个事实是否正确，也不会自动解决版本冲突、权限或候选内容缺失。它处理的是已有排名的组合，后面仍可以做精细重排、证据过滤与回答生成，每一步都应有自己的检查范围。
评估时可以比较原查询、多查询但不融合、以及融合后的结果，观察答案证据是否进入候选和最终上下文。自设列表算例只能验证公式与排序实现，不能当成真实检索准确率提升。
面试里把“生成查询、各路召回、统一身份、按排名融合、再验收证据”串起来即可。如果把完全相同的查询重复十遍，融合分数变高，为什么不能说明证据变得更可靠？