在简单的 RAG 系统中，通常直接用用户的原始问题作为检索查询，去向量数据库中搜索相关片段。但在实际业务场景里，用户的提问往往包含多层含义、隐含条件，或者措辞比较随意，导致单次检索的召回效果不佳。多查询生成（Multi-Query Generation）就是一种让系统自动从一个用户问题衍生出多个不同角度、不同表述的检索查询，分别执行检索后再合并结果的技术，目的是提升检索的覆盖率和鲁棒性。
1. 为什么要生成多个查询
用户的自然语言提问通常不是为检索优化的：
- 措辞差异大：用户可能说“笔记本充不进电怎么办”，而知识库里的文档标题是“电池故障排查指南”。
- 隐含多个子问题：一个问题可能涉及原因、处理方法、政策条款等多个侧面，单次检索只能捕捉其一。
- 同义词和简称：产品型号、专业术语、内部简称等，检索匹配可能出现偏差。
多查询生成的做法，就是利用大模型的语言理解能力，先把用户的自然语言问题“翻译”成几个更精准、更适合查询的表述，用这些表述分头检索，再综合结果，从而提高找到正确答案的概率。
2. 具体如何实现
这种方法的核心步骤很简单，通常借助同一个大模型来完成查询扩充：
- 构造查询生成提示
设计一个提示模板，告诉模型“请根据用户的问题，生成3-5个不同角度的检索查询，每个查询独立成行”。必要时，可以给出示例，或要求模型从“问题本身”、“关键词提取”、“假设答案方向”等角度构造查询。
例如：
你是一个搜索查询生成助手。请根据用户问题，生成4个不同表述的检索查询，
用来在知识库中搜索相关信息。要求：每个查询一行，尽量减少停用词，使用关键术语。
用户问题：员工离职后，年假怎么折算成工资？
生成的查询：
模型可能输出：
年假折算工资 规则
离职员工 未休年假 补偿标准
年假 折算 计算公式
离职 年假 薪资结算 政策
- 并行或串行执行检索
将生成的多个查询分别送入向量数据库（或混合搜索引擎），获取各自的前 N 个结果。通常每个查询取 top‑k 条片段，然后合并所有结果。
- 去重与重新排序
多个查询可能召回相同的片段，需要先按文档 ID 或文本内容去重。随后，可以用一个简单的重排序模型（cross‑encoder）或基于 BM25 的打分，对合并后的候选集重新排序，送出最相关的前几位进入生成阶段。
- 继续后续生成流程
获得高质量上下文后，按照正常的 RAG 方式将上下文和用户原始问题拼入提示，生成最终答案。
3. 一个实用示例
某公司的 IT 支持知识库，用户问题：“我的电脑连不上公司的 Wi‑Fi，一直提示无法获取 IP 地址。”
- 单查询检索（直接用原句）可能只搜到一些泛泛的网络问题排查文档。
- 多查询生成：
- 查询1：“无法获取 IP 地址 修复 步骤”
- 查询2：“Wi‑Fi 连不上 DHCP 故障”
- 查询3：“公司网络 IP 分配失败 解决方法”
- 通过这三个查询，分别从技术手册、已知问题列表和内部论坛帖子中召回相关片段，最终拼装出完整的回答，涵盖“重启 DHCP 服务”、“检查 MAC 地址过滤”、“更新网卡驱动”等多个可能的原因。
这样得到的答案比单一查询更全面，降低了漏掉关键信息的风险。
4. 实际使用时的注意事项
- 查询数量不宜过多：一般 3‑5 个即可，太多会引入大量噪音，并增加检索延迟和费用。
- 查询质量依赖提示工程：建议在提示里约束模型输出格式（如每行一个查询），方便解析；必要时提供 few‑shot 示例。
- 可加入原始问题一起检索：有些实现会保留原始问题作为额外查询，保证最直接的语义匹配不丢失。
- 延迟和成本可接受：多查询会增加几次检索和一次简短的 LLM 调用，但相比让用户反复提问或命中错误答案造成的损失，通常是值得的。
- 适用于复杂查询：如果是简单的关键词问题（如“年假天数”），多查询可能没有明显收益，可以结合查询复杂度的判断来选择性触发。
多查询生成本质上是一个轻量级的“查询改写”策略，它几乎没有改变 RAG 的架构，只是在前端加入了一个微型的查询扩充步骤，实现成本低但实用价值高，尤其适合那些用户表达多样、知识库文档风格统一的场景。