图中每条查询对应一个证据视角，覆盖矩阵用来发现还没有材料支持的子问题。
给同一个问题生成五条搜索语句，不代表获得了五种视角。它们可能只是同义改写，仍然全在寻找同一类内容。多查询的价值，应该体现在原问题所需证据是否更完整，而不是日志里出现了多少次检索调用。
把问题拆成需要证据的部分
自设一个任务：“某个离线工具升级后怎样确认仍能加载旧项目，并在失败时恢复？”这个问题至少包含兼容条件、验证方法与恢复步骤。三部分缺一，就可能得到一个表面相关却无法执行的回答。
可以先列出证据需求，而不是先要求模型随便换五种问法。兼容条件需要版本和格式说明；验证方法需要可检查的输入与预期结果；恢复步骤需要保存旧状态与恢复边界。之后再为这些需求生成搜索入口。
这样拆分仍然要忠于用户范围。如果用户只问加载兼容性，不能自动扩成全公司迁移治理；如果明确禁止联网，生成的子查询也不能把答案导向在线修复服务。覆盖不同方面，不等于扩大任务授权。
查询要有互补职责
一条查询围绕版本兼容，一条围绕最小验证流程，一条围绕失败恢复。它们可以共享核心对象，但各自负责补不同证据。相比三句意思一样的“升级后打不开怎么办”，这种分工更容易检查有没有遗漏。
也不是每个问题都需要拆成三条。有的事实问题只需要一份权威说明，增加大量子查询反而引入噪声。查询数量应由证据需求和资源限制决定，不需要给每个请求套相同的固定模板。
若某条子查询一直找不到材料，应该记录它对应的缺口。不要为了让结果列表显得充实，用主题相近但不回答该部分的段落替代。无法找到恢复依据，本身就是回答应保留的不确定性。
用覆盖矩阵检查“找到了什么”
矩阵的行可以是候选文档，列是兼容、验证和恢复。单元格记录该材料是否真正支持对应方面，以及支持的原文位置。不是标题含有“恢复”两个字就打勾，而是内容能否满足已定义的证据要求。
一份完整指南可能覆盖多列，几份简短材料也可能只覆盖同一列。前者不应因来自单一路径就被误认为多样性差；后者也不能因文档很多就被当作覆盖充分。条目数量与证据维度并不相等。
示例中，如果三条查询最终都只找回兼容说明，那么查询调用数是三，覆盖仍然只有一个方面。下一步应针对未覆盖的验证和恢复查找，而不是继续为兼容说明生成更多同义词。
排名融合不能替代内容覆盖
RRF 等方法可以汇总不同结果列表的排名支持，但它不会自动知道矩阵里哪一列空着。某份兼容说明被五条相近查询反复找回，分数可能很好，恢复步骤仍然没有出现。
因此，融合后的排序还应结合任务需求检查缺口。可以在候选预算内保留能补齐不同方面的有效材料，但不能为了填满矩阵而硬塞低质量内容。覆盖设计是选择证据的辅助，不是把任何相关词条都提升为可信答案。
重复查询的结果也不是相互独立的确认。相同语料、相同模型和相近表述，很可能共享同样的遗漏。多路一致可以帮助定位共同热门内容，却不能直接充当事实真实性的证明。
把成本花在尚未覆盖的地方
设定最大查询次数和停止条件：当必要方面已有足够依据，可以停止扩展；当达到预算仍有缺口，则交代缺失内容。继续检索是否有价值，要看是否可能补到新证据，而不是因为系统还有空余调用额度。
比较策略时，可以固定问题和语料，记录每个方面是否得到支持、重复比例及实际开销。自设覆盖表只验证检查规则，不证明真实模型一定能自动完成这些判断；关键任务仍需要合适标注和抽查。
回答最终也应能回到证据结构：哪些结论有材料，哪些只是合理推测，哪些尚未找到依据。若三份文档都只解释“为什么不兼容”，你会允许答案直接补出一套“怎样恢复”的具体步骤吗？