RAG 查询分解和 Multi-Query 有什么区别？复杂问题应该怎么拆开检索？

知识点详解：拆问题之前，先判断缺的是措辞还是信息

同一件事搜不到，先考虑换表达

假设用户问：“离职以后，公司的账号什么时候不能用了？”

知识库里可能写的是“人员离任”“身份停用”和“访问权限回收”。直接使用用户原句，可能漏掉这些内容。

Multi-Query 可以生成几种查询表述，例如围绕离任后的账号停用时间、权限回收时限来检索。几路结果共同服务于同一个答案：什么时候不能继续访问。

重点是保持原意，不能把“离职后的权限回收”改成“所有账号的密码更新”。查询多了，范围却跑偏，反而会带来不相关资料。Multi-Query 官方接口资料

一个问题需要几块信息，才考虑分解

假设用户问：“产品甲与产品乙在备份频率、恢复时间和保留期限上有什么区别？”

至少需要两款产品、三个方面的资料。只检索一个长句，很容易拿到产品甲的介绍，却漏掉产品乙的保留期限。

可以先列一张证据需求表：

子问题	需要取得的证据	回答原问题的哪部分
甲的备份、恢复与保留规则	甲对应版本的运维资料	比较的一侧
乙的备份、恢复与保留规则	乙对应版本的运维资料	比较的另一侧
两份资料的口径是否相同	版本、套餐、配置和时间单位	保证可以比较

第三行不一定要再检索一次，但必须核对。否则，一边是免费套餐、一边是企业套餐，最后做出的表格很整齐，比较本身却不成立。

查询分解解决的是把信息需求展开，而不是机械地拆成固定三个问题。NVIDIA 查询分解说明

子问题有依赖，就不能全部同时做

再换一个假设问题：“当前维护这套 SDK 的团队，还维护哪些开源项目？”

第一步要找到当前维护团队。只有确认团队名称，第二步才能可靠地查询其他项目。

如果直接并行，模型可能先猜一个团队，后面的检索全都围绕这个猜测展开。结果可能看起来有很多出处，但对象一开始就找错了。

因此，要区分两种路线：已知对象各自查属性，可以并行；先查出对象再查其属性，需要把第一轮证据传给下一轮。第一轮缺资料时，下一轮应该暂停或保留不确定性，而不是靠模型补出一个名字。

汇总时，保留原问题和证据缺口

每个子问题的答案最好带上资料来源与适用条件。最后汇总时，再用原问题检查有没有遗漏。

比如产品乙的恢复时间没有公开资料，就明确写“当前资料无法确认”，不要把产品甲的时间填过去，也不要把“支持恢复”改写成一个具体时长。

还要控制子查询数量和轮数。用户只是问一个术语定义，没必要先拆五个问题；复杂问题拆分后，也不能允许“缺资料就继续拆”无限循环。

评测应同时看正确资料是否进入候选、各子问题是否有证据、最终是否完整回答，以及增加了多少等待时间。更多检索是成本，不是效果证明。

面试官继续追问

查询分解后，还能再用 Multi-Query 吗？

可以。先拆出需要取证的子问题，再对其中难以匹配资料用词的子问题生成多种表述。但两层都会增加检索量，应分别限制数量，避免组合后请求数失控。

子问题答案互相矛盾，怎么处理？

先核对来源版本、对象和时间范围，判断是不是比较口径不同。不能直接让汇总模型“挑一个顺眼的答案”。无法消除冲突时，最终回答应保留冲突及其出处。

怎么知道该拆，而不是直接扩大 Top-k？

先检查失败样本：如果缺的是不同方面的资料，分解可能有帮助；如果正确资料已召回，只是被排序压下去，应该优先处理排序和上下文选择。方案要对应具体缺口。

面试速记卡

• Multi-Query：为同一信息需求生成多种检索表述。
• 查询分解：把复杂问题拆成分别取证的子问题。
• 执行顺序：独立子问题可并行，依赖子问题分轮完成。
• 汇总要求：回到原问题检查覆盖，保留来源、条件和缺口。
• 取舍：增加检索必须换来可验证的收益，而不是只增加次数。