查询分解
查询分解是一种 RAG 技术，它把一个复杂的、多部分的用户问题拆成若干个更简单的子问题，分别为每个子问题检索上下文，然后再组合出最终答案。系统不是要求检索器找到一个段落来一次性回答所有内容，而是并行地提出许多个范围狭窄的问题。
查询分解是一种 RAG 技术，它把一个复杂的、多部分的用户问题拆成若干个更简单的子问题，分别为每个子问题检索上下文，然后再组合出最终答案。系统不是要求检索器找到一个段落来一次性回答所有内容，而是并行地提出许多个范围狭窄的问题。
为什么重要
真实用户会问杂乱的问题："LCP 和 FCP 有什么区别，在 2026 年的移动端 SEO 中哪一个更重要？"把这个查询交给向量检索器，返回的段落往往只涉及 LCP 或 FCP 或 移动端 SEO 或 2026 年趋势之一，很少有单一段落能涵盖全部四点。查询分解把这个问题拆成子查询（"什么是 LCP？""什么是 FCP？""LCP 与 FCP""移动端 SEO 的 Core Web Vitals 2026"），分别为每个检索，再让模型从丰富的上下文中拼接出最终答案。Perplexity、Glean 和 Anthropic 的生产级 RAG 系统对复杂问题都采用了某种形式的分解，而 LangChain 的 2024 年基准显示，多跳问答的准确率提升了 15% 至 25%。
工作原理
1. 调用分解器 LLM：一个小模型接收用户查询并输出 2 至 5 个子问题。提示词："把这个问题拆成完整回答它所需的最少子问题。"
2. 并行检索：每个子问题独立地经过检索器，无论是向量、混合还是关键词检索。
3. 上下文聚合：把所有子问题检索到的段落合并成一个单一的上下文块。
4. 生成最终答案：主模型看到原始问题以及全部检索到的上下文，写出一个统一的答案。
5. 可选的综合步骤：对于多跳问题，可由一个中间步骤先组合出部分答案，再进行最终生成。
变体
并行分解：所有子问题同时运行。速度快，适合各部分相互独立的问题。
顺序分解（多跳）：后面的子问题依赖于前面的答案。"inblog 最大竞争对手的 CEO 是谁？"需要先回答"inblog 最大的竞争对手是谁？"，再去查那家公司的 CEO。
回退式提示：在分解之前，LLM 先问一个更抽象的问题版本，以引入更广泛的上下文。由 Google Research 在 2024 年推广。
HyDE（假设性文档嵌入）：先生成一个假设性的答案，对其做嵌入再检索，是显式分解的一种轻量替代方案。
何时使用
对比类问题："X 与 Y""哪个更适合 Z"
多跳推理："收购 Figma 的那家公司是谁创立的？"
复合问题：把"如何"与"为何"合并在一个查询中。
长尾的具体性：罕见问题，没有单一来源页面能覆盖，但多个页面各自涵盖一部分。
混合多个概念的问题："面向 SaaS 博客的中文技术 SEO"
何时不该使用它
简单的单一事实问题："法国的首都是哪里？"无需分解，那只会增加延迟和成本。
预算受限的应用：分解会成倍增加检索器调用。对于高流量聊天，成本冲击是实实在在的。
单文档答案很强的领域：法律合同、产品手册，一个好段落胜过五个平庸的。
权衡取舍
延迟：每个子问题都是一次往返。并行执行有所帮助，但无法消除它。
检索成本：向量搜索调用随子问题数量线性增长。
分解器质量：糟糕的分解会产生糟糕的检索结果。分解器的提示和模型，与最终生成器同等重要。
冗余检索：子问题常常彼此重叠，反复拉取相同的段落。去重能有所帮助。
常见误区
过度分解：把一个简单问题拆成 10 个子问题会浪费 token，并让最终模型困惑。
不做扎根就分解：传递子答案而非源段落，会让幻觉在多跳间不断累积。
忽视依赖关系：当第二步依赖第一步时却并行运行一个多跳问题，会得到错误答案。
不做评估：没有基准，你就无法判断分解相比基线的单次 RAG 究竟有没有真正帮上忙。
Sources: