目录
一、让系统更好理解用户问题：问题补全是 RAG 的“思维前置层”
（一）方案一：基于多轮对话的渐进式需求补全
1. 设计思路
2. 适用场景
3. 工程注意点
（二）方案二：问题转述与标准化，再进入 RAG
1. 设计思路
2. 实现流程
3. 提示词与知识库增强
4. 优势与边界
（三）方案三：基于意图模板的参数化信息补全（面向业务调用）
1. 设计思路
2. 完整流程拆解
3. 典型价值
（四）三种 Enrich 策略的对比与组合使用
二、多路召回与结果融合：解决向量搜索的单一视角局限
（一）Multi-Query 的核心思想：一个问题，多种“检索视角”
1. 多角度问题改写
2. 多路并行检索
（二）RAG-Fusion：从“多次召回”到“有效融合”
1. 去重（Deduplication）
2. 融合排序（Rank Fusion）
（1）基于排名的融合（Reciprocal Rank Fusion, RRF）
（2）加权相似度融合
（3）LLM-Based Re-Ranking
（三）Multi-Query 在 RAG 架构中的标准流程
（四）工程实践中的关键注意事项
1. 控制 Query 数量
2. Query 质量优于数量
3. 与其他 RAG 优化手段的协同
三、抽象理解（Step‑Back 抽象策略）
（一）为什么 Step Back 在复杂问题中非常重要
（二）Step Back 的核心目标
（三）Step Back 提示词设计的专业要点
1. 提示词的核心约束
2. 提示词结构拆解
四、问题分解（Decomposition）
（一）子问题生成（Sub-Question Generation）
1. 提示词的核心设计思想
2. 提示词语义拆解
3. 高质量子问题的特征
（二）并行 vs 串行：工程取舍建议
1. 子任务执行策略一：并行执行（Parallel）
2. 子任务执行策略二：串行执行（Serial / Sequential）
3. 对比实践
（三）与其他 RAG 优化策略的协同关系
五、假设驱动检索（HyDE）：解决语义鸿沟的关键策略
（一）为什么 HyDE 有效
（二）HyDE 的标准流程
（三）典型适用场景
六、工程实践中的注意事项与结论
参考文献
干货分享，感谢您的阅读！
检索增强生成（Retrieval‑Augmented Generation, RAG）已经从早期的“检索一次获取上下文然后生成答案”的简单范式，演化为一个复杂、模块化、可优化的智能问答框架。其核心是通过检索外部知识库补充 LLM（大型语言模型）的静态知识，从而提高回答的准确性、时效性和可解释性。然而，真实用户提问往往存在上下文不完整、表达歧义、信息缺失等问题，这直接影响检索的召回质量及最终回答的精确度。因此，在 RAG 架构中提高问题理解能力与检索质量已经成为推动其规模化应用的关键。
本文力求系统梳理多种 RAG *问题补全（Query Enrichment）与多路召回（Multi‑Query / RAG‑Fusion）策略，并从工程与研究角度分析它们的设计逻辑、优势、边界和组合模式，同时结合最新学术进展提供实证支撑。
一、让系统更好理解用户问题：问题补全是 RAG 的“思维前置层”
在标准 RAG（Retrieval-Augmented Generation）架构中，检索质量高度依赖用户问题质量。但真实场景下，用户输入往往具有以下特征：
语义模糊、上下文缺失（“这个怎么配置？”）
使用口语化或非专业表达
隐含前提较多，但未显式说明
参数不完整，难以直接驱动业务或查询
问题补全（Enrich）的核心目标并非“让用户问得更好”，而是在不增加用户心智负担的前提下，由系统自动提升问题的可理解性与可执行性，从而显著提高 RAG 的召回相关性和最终回答质量。
（一）方案一：基于多轮对话的渐进式需求补全
1. 设计思路
该方案的核心思想是：通过大模型主动发起澄清式对话，在多轮交互中逐步收敛用户真实意图，并补齐缺失信息。
在这一模式下，大模型不再是“被动回答者”，而是扮演需求分析师（Requirement Analyst）的角色。典型流程如下：
- 初始意图识别：对用户首轮输入进行粗粒度意图判断，判断是否存在信息缺失、歧义或多种解释路径
- 生成澄清问题：针对“关键信息缺失点”提出最小必要澄清，避免一次性追问过多问题，降低用户疲劳
- 上下文状态维护：将用户补充的信息结构化存储（Slot Filling），逐步构建完整的意图与参数集合
- 意图收敛与执行：当信息满足执行或检索条件后，生成标准化 RAG 查询或业务指令
2. 适用场景
咨询类、分析类问题（如技术方案选型、故障排查）
专业领域问答（医疗、法律、工程、架构设计等）
用户需求高度多样、难以预定义参数的系统
3. 工程注意点
必须设定最大追问轮次，防止对话发散
澄清问题应聚焦“区分度最高”的信息
建议引入置信度机制，在信息不足但可接受时提前执行
（二）方案二：问题转述与标准化，再进入 RAG
1. 设计思路
该方案强调单轮或弱多轮场景下的输入规范化，核心步骤是：
先让大模型“复述并规范用户问题”，再用该规范化问题驱动 RAG 检索与生成。
本质上，这是将大模型作为一个语义编译器（Semantic Rewriter）。
2. 实现流程
问题转述（Rewrite / Rephrase）：将口语化、碎片化输入转化为完整、专业的查询描述，补全隐含主语、上下文和限定条件
结构化意图表达：输出不仅是自然语言，还可以是：意图标签 + 约束条件、检索关键词列表、标准问题描述
生成 RAG 查询指令：基于规范化后的问题执行向量检索 / 混合检索，显著降低“问得随意、搜得离谱”的概率
3. 提示词与知识库增强
在工程实践中，通常会：
提供固定的提示词模板
给出“好问题”的示例（Few-shot）
引入知识库中的术语表、领域定义，帮助模型做专业化转述
例如，用户问：
“这个索引怎么老是慢？”
模型转述为：
“在 MySQL 中，某查询在使用联合索引的情况下仍然出现性能瓶颈，请分析可能原因（如最左前缀失效、回表、索引下推未生效等）。”
此时，RAG 的召回质量会出现数量级提升。
4. 优势与边界
优势：
不增加用户交互成本
架构简单，适合快速落地
对现有 RAG 改造成本低
边界：
对极端信息缺失问题能力有限
无法替代复杂业务参数收集
（三）方案三：基于意图模板的参数化信息补全（面向业务调用）
1. 设计思路
该方案面向“可执行型应用”，如订票、下单、预约、流程自动化等，其目标是：
将自然语言需求转化为结构化业务指令。
核心机制是Intent → Slot → Action。
2. 完整流程拆解
意图识别（Intent Classification）：可选技术：大模型直接分类/搜索引擎规则/向量相似度匹配，示例意图：订机票、查询订单、知识问答
选择业务模板：每个意图绑定一个参数模版，例如：舱位 / 座位偏好，时间，目的地，出发地
生成补全对话：大模型基于模板生成一段清晰、友好的提示，明确告知“还缺哪些信息”
参数收集与校验：将用户补充信息填入 Slot，可结合规则或模型做合法性校验
生成行动指令（Action）：输出结构化 JSON / API 调用参数，触发下游系统执行
3. 典型价值
实现真正的“自然语言驱动系统”
将 RAG 从“问答系统”升级为“智能代理”
大幅降低用户学习成本
（四）三种 Enrich 策略的对比与组合使用
| 方案 | 主要目标 | 用户交互 | 技术复杂度 | 典型场景 |
|---|---|---|---|---|
| 多轮对话补全 | 理解复杂需求 | 高 | 高 | 咨询、分析 |
| 问题转述标准化 | 提升检索质量 | 低 | 低 | 知识库问答 |
| 参数模板补全 | 业务自动执行 | 中 | 中~高 | 订票、自动化 |
在真实系统中，这三种策略并非互斥，而是常以组合形式出现，例如：
先做问题转述 → 判断为业务意图 → 进入参数补全流程 → 最终调用业务系统或 RAG。
问题补全（Enrich）并不是一个“锦上添花”的优化点，而是RAG 从“能用”走向“好用、可规模化”的关键能力。其本质是：让系统承担更多理解与澄清成本，而不是把复杂性留给用户。
当你开始认真设计 Enrich 层时，RAG 才真正具备走向生产级智能应用的可能性。
二、多路召回与结果融合：解决向量搜索的单一视角局限
让模型从多个角度改写同一个问题，并分别检索，再进行去重与排序，可以有效缓解向量相似度搜索的单一视角局限。
在标准 RAG 架构中，检索通常遵循以下流程：
用户问题 → 单一向量查询 → Top-K 相似文档 → LLM 生成答案
该模式的问题在于：向量检索本质上是“单一语义视角”的近似搜索，一旦用户问题表述存在偏差，就可能出现：
用词不同但语义相近的文档未被召回（同义词、领域术语差异）
用户问题同时包含多个子意图，但检索只覆盖其中一部分
抽象问题导致召回内容过泛，关键细节缺失
长问题中“真正关键信息”被稀释
多路召回的目标是：通过多种语义表达与检索路径，扩大召回覆盖面，在后续阶段再做精排与压缩，从而提升最终回答的准确性与完整性。
（一）Multi-Query 的核心思想：一个问题，多种“检索视角”
1. 多角度问题改写
Multi-Query 的第一步，并不是检索，而是问题扩展（Query Expansion）。
做法是：让大模型基于原始问题，生成多个语义等价但表达侧重点不同的子查询，例如：
技术视角
原理视角
实践 / 操作视角
故障 / 优化视角
关键术语显式化版本
关键点在于：
这些问题不是“随意改写”
而是刻意覆盖不同可能的文档组织方式
2. 多路并行检索
每一个子查询都会独立执行一次检索流程，例如：
向量检索（Embedding Search）
关键词 / BM25 检索
混合检索（Hybrid Search）
最终得到多组候选文档集合。
（二）RAG-Fusion：从“多次召回”到“有效融合”
如果只做多路召回而不做融合，结果往往是：
文档大量重复
噪声文档比例上升
上下游 Token 成本失控
因此，Fusion（融合）是多路召回的核心价值所在 。TECHCOMMUNITY.MICROSOFT.COM
1. 去重（Deduplication）
对多个召回结果进行：
基于文档 ID 的硬去重
基于语义相似度的软去重（防止同一内容多版本）
2. 融合排序（Rank Fusion）
常见的融合排序策略包括：
（1）基于排名的融合（Reciprocal Rank Fusion, RRF）
不关心相似度绝对值
更关注“在各自列表中的排名位置”
特别适合多检索器、多查询场景
优势：
对不同检索器尺度不敏感
工程实现简单，效果稳定
（2）加权相似度融合
为不同 Query 或检索器分配权重
适用于对“主问题 / 次问题”有区分的场景
（3）LLM-Based Re-Ranking
将融合后的候选文档交给大模型进行相关性判断
输出最终 Top-N
适合：
高价值查询
文档规模可控的场景
（三）Multi-Query 在 RAG 架构中的标准流程
一个典型的 Multi-Query / RAG-Fusion 流程如下：
用户原始问题输入
大模型生成 N 个语义改写问题
并行执行多次检索
合并所有候选文档
去重与融合排序
选取 Top-K 文档作为上下文
输入 LLM 生成最终答案
从系统角度看，多路召回本质上是一个Recall-First、Precision-Later的策略。
（四）工程实践中的关键注意事项
1. 控制 Query 数量
通常 3–5 个子查询已经足够
Query 过多会带来：
检索延迟
成本上升
噪声放大
2. Query 质量优于数量
更重要的是“视角差异”
而不是“语义同义”
建议通过 Prompt 约束生成方向。
3. 与其他 RAG 优化手段的协同
Multi-Query 通常与以下策略组合使用效果最佳：
问题补全（Enrich）
Hybrid Search（向量 + 关键词）
Context Compression
Re-Ranking
多路召回（Multi-Query / RAG-Fusion）解决的并不是“模型不会答”的问题，而是：模型根本没看到该看的内容。
通过引入多视角问题改写与检索结果融合机制，RAG 系统可以显著提升召回覆盖率、鲁棒性与复杂问题的处理能力。
在生产级 RAG 系统中，Multi-Query 往往不是“可选优化”，而是高质量问答的基础设施能力之一。
三、抽象理解（Step‑Back 抽象策略）
当用户描述极为复杂时，先让模型“退一步”理解问题的宏观类型，有助于优先检索高层次、通用性更强的知识。
Step Back 问题摘要，可以理解为一种“先抽象、再检索”的提问重构策略。
其核心做法是：在进入检索或推理之前，让大模型先“后退一步”，对用户的原始问题进行高度抽象和概括，提炼出一个更通用、更本质、更容易回答的上层问题。
这个“Step Back”并不是简化文本长度，而是从细节层面上升到问题类型与核心矛盾层面，得到一层高级语义语料（High-level Semantic Chunk），用于后续的 RAG 检索或推理。
（一）为什么 Step Back 在复杂问题中非常重要
在真实应用中，尤其是以下场景，原始问题往往不适合直接检索：
医疗咨询：用户描述大量症状、情绪、时间线，但未明确核心医学问题
法律咨询：大段事实陈述、背景信息、主观判断混杂在一起
技术咨询：夹杂环境信息、日志、推测结论，但真正的问题不清晰
投诉 / 申诉 / 纠纷描述：情绪信息多，问题结构弱
直接将这类问题送入向量检索，通常会导致：
检索向量被噪声稀释
命中“描述相似”而非“问题本质相同”的文档
RAG 上下文过长但不聚焦
Step Back 的作用正是：先判断“这到底是什么类型的问题”。
（二）Step Back 的核心目标
Step Back 策略并不直接生成最终答案，而是承担以下三项关键职责：
识别用户真实意图（Intent）
抽象问题类型（Problem Type）
提炼可复用的上层问题表达
其输出通常是一个比原问题更短，但语义更“干净”、更稳定的问题表达。
（三）Step Back 提示词设计的专业要点
1. 提示词的核心约束
一个高质量的 Step Back 提示词，必须明确要求模型：
不要回答问题
不要引入新事实
不要给解决方案
只做抽象、归类与概括
2. 提示词结构拆解
典型的提示词包含以下要素：
角色定义：强调模型具备领域通识与抽象能力
任务描述：明确是“paraphrase to a generic step-back question”
抽象原则：从细节到类型，从具体到通用，保留问题核心，不保留情绪和噪声
输出约束：一句话或极简表达，问题形式，而非陈述
Step Back 问题摘要的价值，并不在于“把问题说得更短”，而在于：
先判断问题的“类别与本质”，再进入检索与推理。
在医疗、法律、技术支持等高噪声、高复杂度场景中，Step Back 是提升 RAG 稳定性与专业度的关键前置能力。
它让系统像专家一样先想清楚“这是什么问题”，而不是急于回答“该怎么办”。
四、问题分解（Decomposition）
将复杂问题拆解为若干子问题，可采用并行或串行执行方式，特别适用于流程型、分析型问题场景。
在提示词工程中，Chain of Thought（CoT）强调的是：通过显式的中间推理步骤，提升模型对复杂问题的理解与推理能力。而在 RAG 体系中，这一思想被进一步“工程化”，演变为：在检索之前或检索过程中，把一个复杂问题拆解为多个可以独立回答的子问题，并围绕每个子问题分别检索与推理。
因此，这一策略也可以理解为：RAG 场景下的 CoT（Retrieval-augmented Chain of Thought）。
它解决的不是“模型不会推理”，而是：单一检索查询无法覆盖复杂问题所需的全部信息。
（一）子问题生成（Sub-Question Generation）
1. 提示词的核心设计思想
给出的提示词，本质上是在引导模型完成三件事：
识别问题的内部结构
拆解为多个可独立回答的子问题
将子问题直接作为检索查询（Search Query）使用
这是一个非常典型、且工程上成熟的设计。
2. 提示词语义拆解
以该提示词为例：
You are a helpful assistant that generates multiple sub-questions related to an input question. The goal is to break down the input into a set of sub-problems / sub-questions that can be answered in isolation. Generate multiple search queries related to: {question} Output (3 queries):其关键约束点包括：
“answered in isolation”
强调每个子问题应当是“信息自洽的”，避免相互强依赖“search queries”
明确输出是为了检索，而不是自然对话数量限制（3 queries）
控制召回规模，避免噪声扩散
3. 高质量子问题的特征
一个合格的子问题，通常具备以下特性：
聚焦单一维度（原理 / 实现 / 优化 / 风险等）
表达清晰、术语明确
可直接用于向量或关键词检索
不包含推测性结论
（二）并行 vs 串行：工程取舍建议
1. 子任务执行策略一：并行执行（Parallel）
执行方式
将所有子问题同时发起检索与问答
每个子问题：
独立检索上下文
独立生成答案
最后由大模型进行一次结果汇总与整合
适用场景
子问题之间相互独立
对实时性要求较高
各子问题重要性相对均衡
2. 子任务执行策略二：串行执行（Serial / Sequential）
执行方式
按预定顺序执行子问题
前一个子问题的答案，作为后一个子问题的上下文或约束
逐步逼近最终结论
适用场景
子问题之间存在明显依赖关系
需要逐步推理、逐步缩小问题空间
决策类、分析类问题
3. 对比实践
| 维度 | 并行执行 | 串行执行 |
|---|---|---|
| 子问题关系 | 独立 | 存在依赖 |
| 延迟 | 低 | 高 |
| 推理深度 | 中 | 高 |
| 容错性 | 高 | 较低 |
| 实现复杂度 | 较低 | 较高 |
在实践中，混合策略非常常见，例如：
先并行获取基础事实
再串行进行综合分析或决策
（三）与其他 RAG 优化策略的协同关系
子问题拆解往往与以下策略组合使用：
Step Back 抽象：先定“问题类型”，再拆细节
Multi-Query / RAG-Fusion：每个子问题本身也可多路召回
Context Compression：对子问题结果进行压缩后再汇总
五、假设驱动检索（HyDE）：解决语义鸿沟的关键策略
先生成一个“假设答案”，再以该答案作为检索查询，常用于知识库语义与用户表达差距较大的情况。
假设驱动检索（HyDE）的核心思想是：不直接用用户问题做检索，而是先让大模型生成一个“可能正确的假设答案”，再用该答案去做向量检索。
这里的“假设答案”并不是最终输出，而是一个中间语义桥梁，用于缩小用户表达与知识库语义分布之间的差距。
（一）为什么 HyDE 有效
在许多场景中，检索失败并非因为“库里没内容”，而是因为：
用户问题过于抽象或口语化
知识库以解释性、陈述性文档为主
问题本身不具备良好的向量检索特征
HyDE 通过生成一段结构化、专业化、接近文档风格的假设文本，使向量检索更容易命中高相关内容。本质上，HyDE 是一种“语义对齐策略”。
（二）HyDE 的标准流程
用户输入原始问题
大模型生成一个假设性答案 / 解释性文本
对该假设文本进行向量化
使用该向量进行检索
基于真实检索结果生成最终答案
需要强调的是：假设答案只用于检索，不直接作为最终输出。
（三）典型适用场景
HyDE 特别适合以下情况：
用户提问方式与文档写作方式差异大
问题偏“为什么 / 怎么理解”，而文档偏“是什么 / 如何实现”
专业知识库（技术、医学、法律）中术语密集、表达规范
例如：用户问得很“随意”，而知识库写得很“学术”，HyDE 能有效拉近二者。
HyDE 的价值不在于“猜答案”，而在于：用一个更像“文档”的表达，去检索真正的文档。
在用户语言与知识库语言存在明显断层的场景中，HyDE 是一种性价比极高的 RAG 召回增强手段。
六、工程实践中的注意事项与结论
RAG 系统在生产环境落地时还需要考虑：
控制 Multi‑Query 数量与生成质量：避免检索噪声与延迟激增；
抽象与分解策略的触发机制：设置复杂度阈值；
与 reranker、检索引擎结合：尤其是混合检索（Dense + Sparse）和交叉编码 rerank 有助于提高精确性。Emergent Mind
RAG 技术从“检索‑生成”的基础模型发展到今天，已经成为生产级问答系统的核心架构。在这一演进中：
问题补全提升了查询质量；
多路召回与融合提高了召回覆盖；
抽象与分解策略加强了对复杂问题的理解；
HyDE 和查询重写解决了语义鸿沟问题。
上述各类策略既可以独立使用，也可以组合部署，如：先 Step‑Back 再 Query Rewrite → Multi‑Query检索 → RRF融合 → HyDE增强检索。这样的组合策略，是高质量、可扩展 RAG 系统的基石。
参考文献
MaFeRw: Query Rewriting with Multi‑Aspect Feedbacks for RAG—https://arxiv.org/abs/2408.17072arXiv
DMQR‑RAG: Diverse Multi‑Query Rewriting for RAG—https://arxiv.org/abs/2411.13154arXiv
RQ‑RAG: Learning to Refine Queries for Retrieval Augmented Generation—https://www.emergentmind.com/papers/2404.00610Emergent Mind
Layered Query Retrieval: Adaptive Framework for Complex QA— MDPI Applied Sciences — https://www.mdpi.com/2076‑3417/14/23/11014MDPI
Best Practices in Retrieval‑Augmented Generation—https://www.emergentmind.com/articles/2407.01219Emergent Mind
Question Decomposition for RAG— ACL 2025 paper — https://aclanthology.org/2025.acl‑srw.32.pdfACL Anthology
Advanced Query Translation Techniques: Step‑Back Prompting & HyDE— https://medium.com/%40gauravbansalutd/advanced‑query‑translation‑techniques‑in‑rag‑systems‑0fad5ad6f500Medium
RAG Latest Advances in 2025—https://www.ppmy.cn/news/1716773.htmlPPmy
LLM‑RAG Survey Notes— https://zuti666.github.io/2024/11/27/Paper‑Reading‑Note‑7‑LLM‑RAG/英飞
RAG Computational Architecture in Vector Systems— https://crad.ict.ac.cn/cn/article/pdf/preview/10.7544/issn1000‑1239.202440411.pdf计算机研究与发展
