多路召回合并是什么
多路召回让模型把一个问题改写成多个不同视角的子查询，各自检索后合并去重，用增加候选多样性的方式降低「一种说法漏召回」的概率。它适合用户表述与文档措辞差异较大的场景，代价是多几次检索与一次额外的模型调用，路数过多会推高在线延迟。
基本信息
| 做法 | 一个问题改写成多条子查询，各自检索后合并 |
|---|---|
| 路数 | 常见 3 到 5 条，过多会拖慢在线延迟 |
| 合并方式 | 按片段标识或内容哈希去重，再按融合策略排序 |
| 额外成本 | 一次改写调用加多路检索耗时 |
LangChain 示例
LangChain 示例
from langchain.retrievers.multi_query import MultiQueryRetriever
retriever = MultiQueryRetriever.from_llm(
retriever=base_retriever, llm=llm)
docs = retriever.invoke("如何给向量库做容量规划？")使用要点
- 先抽查看改写质量：多条改写高度雷同时几乎没有增益
- 限制路数：三到五条是常见区间，超过后收益递减而延迟明显上升
- 合并必须去重：同一片段被多份改写重复召回会占满上下文
- 与融合策略配合：多路结果按排名融合比直接拼接更稳
- 记录每路各自的命中贡献，便于判断哪条改写真正有用
路数与收益
| 路数 | 收益 | 代价 |
|---|---|---|
| 1 条 | 无额外开销 | 表述不匹配时直接漏召回 |
| 3 到 5 条 | 覆盖面明显提升 | 一次改写加多路检索耗时 |
| 过多 | 收益递减 | 噪声候选增多，延迟与成本上升 |
常见问题
- 子查询互相重叠：改写提示词要求从不同角度出发可缓解
- 合并后条数暴涨：缺少去重与截断，上下文直接被塞满
- 延迟超标：改写与多路检索串行执行，改为并行可显著改善
- 效果不稳定：改写模型输出随机性大，需要固定参数并做多次对照
多路结果合并后要按片段标识或内容哈希去重；路数控制在三到五条较为常见，过多会拖慢在线延迟。
效果验证方法
- 固定一批问题，分别测单查询与多路召回的命中率差异
- 把每路子查询与它带回的新增片段记录下来，判断哪条改写真正有效
- 观察候选池里新增片段的占比，占比过低说明改写同质化
- 与改写前的基础查询做对照，避免把检索本身的改进算到多路召回头上