多路召回：合并、去重与延迟预算

多路召回，指的是同时用几种不同的检索方式取候选，再合并成一份候选集交给排序。它存在的前提是：没有任何一种检索方式能覆盖全部情况，而业务问题恰好分布在不同的盲区里

为什么需要多路

• 语义检索擅长处理表述差异：同一个意思的不同说法能被匹配上。
• 关键词检索擅长精确命中：编号、系统字段名、产品代码这类字符串语义检索容易漂移。
• 结构化过滤擅长范围限定：按部门、时间或类型先缩小范围，再谈相关性。

三类方式的能力互补，这也是多数企业内部检索最终都会走向多路的原因。但多路并不等于简单叠加 —— 叠加之后的问题从「找得到吗」变成了「怎么合」。

合并策略

• 分数归一化：不同来源的分数量级不同，合并前需要先统一到可比范围。
• 按来源配额：给每一路保留固定数量的候选，避免某一路结果特别多时把其余全部挤掉。
• 保留来源标记：合并后仍能看出每条候选来自哪一路，便于事后排查。
• 按问题类型加权：编号类问题提高关键词路权重，描述类问题提高语义路权重。

去重怎么做

• 同一条目多路命中：按条目标识去重，保留分数较高的那次。
• 同一文档不同片段：相邻片段的重复内容需要合并，避免上下文被同一份材料占满。
• 近似重复：不同版本的同名文档同时命中时，按版本或时效保留有效的一份。

延迟预算怎么定

• 并行发起：多路请求同时发出，总延迟取决于最慢的一路，而不是相加。
• 单路超时：为每一路设置超时，避免某一路拖慢整体响应。
• 总预算：先约定检索环节可接受的耗时上限，再据此决定路数与候选数量。
• 降级策略：超预算时退化为单路检索，并记录降级次数作为容量依据。

什么时候不值得做多路

内容总量很小、问题类型单一、或者单路检索已经能满足要求时，多路带来的复杂度与延迟代价并不划算。判断依据仍然是分阶段指标：如果召回遗漏比例很低，就不必再加一路。

验收

• 每一路都有独立的命中统计，能说明它贡献了什么。
• 合并与去重规则有记录，且可从结果反查来源。
• 延迟分布有测量，包含降级发生的次数。
• 新增一路之前与之后有对照结果，而不是凭感觉认为更全；长期没有贡献的路应当撤下。
• 问题表达高度一致时不必多路：使用者始终用同一种说法提问，单路往往已经足够。

与排序环节的分工

多路召回解决的是「候选里有没有」，排序解决的是「候选里哪条更该用」。两者职责不同，指标也应分开记录，否则合并策略的问题会被误判成排序问题

• 召回阶段只关心是否遗漏，不追求前几名的顺序。
• 合并之后再去比较不同来源的贡献，判断某一路是否值得保留。
• 排序阶段不再回退调整召回参数，避免两段互相干扰。