文章摘要RAG召回效果差时很多团队第一反应是“多生成几个查询”。但Multi-Query、HyDE和问题分解解决的并不是同一种缺陷Multi-Query主要缓解用户措辞与文档表达不一致HyDE通过生成一段假设性文档将极短或抽象问题映射到更接近语料的Embedding空间问题分解则把需要多跳证据的复杂问题拆成多个可独立检索的子问题。三种策略都可能提高Recall但也会带来更多模型调用、更多向量检索、更大的候选集合、更高Reranker成本和更复杂的错误传播。HyDE生成的假设文档还可能带有虚构细节问题分解可能遗漏全局约束Multi-Query则容易产生大量同义重复Query。Spring AI的模块化RAG已经提供RewriteQueryTransformer和MultiQueryExpander等查询处理组件并支持通过RetrievalAugmentationAdvisor组合检索流程。本文从召回缺陷、输入类型、语料特征、延迟、Token成本、可解释性、权限、评测和降级等维度给出三种策略的适用边界、组合方法与生产落地决策树。一、先确定你要修复的到底是什么问题查询增强不是通用增益开关。在引入任何策略前先把失败分成以下类型。1. 措辞不匹配用户为什么账户一直转圈文档登录会话刷新失败导致前端持续加载这是表达角度不同Multi-Query通常有效。2. 用户问题过短或过于抽象用户渠道控盘文档是完整行业方案包含经销商流向-终端动销-防窜货-费用核销-扫码风控。短Query的Embedding信息不足HyDE可能有帮助。3. 多跳问题某产品在华东区域销量下降是渠道库存上升、终端覆盖下降还是活动核销异常导致需要分别检索销量-渠道库存-终端覆盖-活动核销。这是问题分解场景。4. 精确Token丢失HTTP 429 ZX-4100B 合同编号HT-2026-0081这不是Multi-Query或HyDE优先解决的问题而应先保护原始Token并使用Sparse检索。5. 索引本身缺失或错误如果正确文档根本没有入库查询增强只会更昂贵地返回错误结果。二、Multi-Query的工作方式Multi-Query由LLM将一个问题生成多个语义角度不同的查询。原问题 ↓ Query 1从业务术语角度改写 Query 2从技术症状角度改写 Query 3从原因诊断角度改写 ↓ 分别检索 ↓ 去重与融合Spring AI提供MultiQueryExpander可以设置生成数量并默认将原始Query包含在扩展列表中。概念代码MultiQueryExpanderexpanderMultiQueryExpander.builder().chatClientBuilder(chatClientBuilder).numberOfQueries(3).includeOriginal(true).build();ListQueryqueriesexpander.expand(newQuery(userQuery));三、Multi-Query最适合什么场景1. 用户表达多样同一业务概念有多种叫法防窜货 窜货预警 跨区流通 异地扫码 渠道异常流向2. 文档语言与用户语言不同用户说口语文档写正式术语。3. 召回需要多个角度但不需要多跳推理例如“订单为什么无法取消”可能需要状态限制-时间限制-权限限制-库存占用。4. 查询较完整但单次Embedding召回不稳定Multi-Query通过多个向量入口扩大候选。四、Multi-Query的主要风险1. 查询同质化模型生成如何取消订单 订单取消方法是什么 怎样进行订单取消三条几乎相同只增加成本。2. 实体与约束被改坏生成Query可能修改编号-否定-时间-权限范围。每条扩展Query都必须经过保护校验。3. 候选集合膨胀3条Query、每条Top 30最多90个候选Reranker和上下文裁剪成本会显著增加。4. Recall增加但Precision下降扩展角度过宽会引入大量看似相关但不回答问题的文档。五、Multi-Query的生产控制publicrecordMultiQueryPolicy(intmaximumQueries,inttopKPerQuery,booleanincludeOriginal,doubleminimumDiversity,intmaximumFusedCandidates,Durationdeadline){}生成后执行实体保护 ↓ 语义去重 ↓ 预算裁剪 ↓ 并行检索 ↓ 稳定融合查询多样性可以用Embedding相似度约束if(cosineSimilarity(queryAEmbedding,queryBEmbedding)0.95){removeDuplicate(queryB);}六、HyDE的工作方式HyDE即Hypothetical Document Embeddings。流程用户问题 ↓ LLM生成一段“可能回答该问题的假设文档” ↓ 对假设文档生成Embedding ↓ 在真实语料向量空间中检索相似文档重要区别假设文档不是最终答案 也不应该直接作为证据交给用户。它只是检索桥梁。例如用户输入渠道控盘HyDE可能生成渠道控盘通常通过经销商流向追踪、终端库存监控、区域防窜货、费用核销和扫码数据分析实现……这段文本包含更丰富的领域词汇Embedding更容易靠近相关行业方案文档。七、HyDE最适合什么场景1. Query极短RAG幻觉 渠道动销 设备离线2. 文档是长篇专业叙述用户只给概念文档却是说明书、方案书或论文。3. 没有标注数据进行Retriever微调HyDE原始研究针对零样本稠密检索使用生成的假设文档作为中间表示。4. 用户不知道领域术语模型可以把用户描述扩展为语料中常见的专业表达。八、HyDE的主要风险1. 虚构细节影响检索方向假设文档可能生成不存在的产品名-法规-版本-原因-结论。虽然HyDE只用于Embedding但虚构实体仍可能把向量推向错误区域。2. 不适合精确编号查询ZX-4100B错误码E1027假设文档会稀释关键Token。3. 成本高于普通改写假设文档通常比Query长生成与Embedding成本更高。4. 可解释性弱需要保存假设文档、模型版本和检索结果才能解释为什么召回某些文档。九、HyDE的安全实现publicrecordHyDEQuery(StringrawQuery,StringhypotheticalDocument,SetStringpreservedEntities,StringmodelProfile,StringpromptVersion){}Prompt必须约束1. 不得发明具体编号、人名、金额或日期。 2. 只生成领域相关的通用说明文本。 3. 保留原始Query中的全部关键实体。 4. 不输出最终结论。 5. 不将假设文档展示为真实证据。检索时建议原始Query向量检索 HyDE向量检索 原始Query稀疏检索而不是只使用HyDE。十、问题分解的工作方式问题分解把一个复合问题转换成多个子问题。原始 为什么某区域销售下降 子问题 1. 该区域出货量变化是什么 2. 经销商库存是否上升 3. 活跃终端数是否下降 4. 促销核销是否异常每个子问题独立检索随后聚合证据。十一、问题分解适合什么场景1. 多跳证据最终结论依赖多份文档或多个数据源。2. 比较问题方案A与方案B在成本、延迟和安全方面有什么差异3. 原因分析需要分别查找多个可能因素。4. 需要跨系统检索知识库-业务数据库-指标平台-工具接口。5. 复杂合规判断需要同时满足多个条件。十二、问题分解的主要风险1. 子问题遗漏全局约束原问题仅分析华东区域2026年第二季度的经销商。某个子问题可能丢掉华东-2026年第二季度-经销商。2. 子问题之间重复多个子问题可能检索同一证据浪费成本。3. 错误传播分解错误后后续检索再准确也没有意义。4. 需要聚合逻辑最终答案必须说明哪个子结论来自哪些证据-子结论是否互相冲突-证据是否完整。5. 延迟高如果串行执行分解LLM N次检索 N次Rerank 聚合LLMP95会明显上升。十三、问题分解的数据模型publicrecordDecomposedQueryPlan(StringoriginalQuery,ListSubQuerysubQueries,SetStringglobalConstraints,AggregationStrategyaggregationStrategy,intmaximumParallelism,Durationdeadline){}publicrecordSubQuery(StringsubQueryId,Stringtext,SetStringinheritedConstraints,SetStringrequiredEvidenceTypes,intpriority,booleanmandatory){}每个子问题必须显式继承全局约束。十四、三种策略核心对比维度Multi-QueryHyDE问题分解主要目标扩展表达角度改善短Query语义表示拆解多跳任务典型输入单一但措辞多样过短、抽象复合、多条件检索次数多次通常原始HyDE每个子问题一次或多次额外生成短Query列表较长假设文档子问题计划延迟中中高Token成本低到中中中到高实体风险中中高高可解释性较好中较好但链路长适合Sparse原始Query适合不适合直接替代每个子问题可适配最常见失败同义重复虚构方向遗漏约束十五、不要按“复杂度越高越先进”选型错误思路问题分解最复杂 → 能力最强 → 所有请求都使用正确思路使用解决当前缺陷所需的最小策略简单FAQ使用问题分解会增加延迟-成本-随机性-排障难度。十六、推荐决策树Query是否包含精确编号、型号或错误码 ├─ 是原始QuerySparse优先必要时受控改写 └─ 否继续 问题是否包含多个独立子目标或需要多跳证据 ├─ 是问题分解 └─ 否继续 Query是否过短、抽象且语料是长篇专业文本 ├─ 是原始QueryHyDE └─ 否继续 主要问题是否是用户措辞与文档表达不一致 ├─ 是Multi-Query └─ 否原始Query或普通Rewrite十七、可以组合但必须分层推荐组合一原始Query Multi-Query Sparse/Dense RRF推荐组合二短抽象Query HyDE 原始Query Dense 原始Query Sparse Rerank推荐组合三复杂问题分解 ↓ 每个子问题根据特征选择Raw/Multi-Query/HyDE ↓ 子问题内融合 ↓ 跨子问题证据聚合禁止无上限组合5个子问题 × 5个Multi-Query × 原始HyDE × TopK 50这会产生数千候选和不可接受成本。十八、统一策略路由器ServicepublicclassQueryEnhancementStrategyRouter{publicQueryEnhancementStrategyroute(QueryFeaturesfeatures,RetrievalBudgetbudget){if(features.exactTokenDensity()0.5){returnQueryEnhancementStrategy.RAW_HYBRID;}if(features.multiHopScore()0.75budget.allowDecomposition()){returnQueryEnhancementStrategy.DECOMPOSE;}if(features.abstractnessScore()0.8features.queryLength()20budget.allowHyde()){returnQueryEnhancementStrategy.HYDE_AND_RAW;}if(features.ambiguityScore()0.55budget.allowMultiQuery()){returnQueryEnhancementStrategy.MULTI_QUERY;}returnQueryEnhancementStrategy.RAW_ONLY;}}十九、预算模型publicrecordRetrievalBudget(intmaximumGeneratedQueries,intmaximumSearchRequests,intmaximumCandidates,intmaximumRerankDocuments,intmaximumInputTokens,BigDecimalmaximumCost,Durationdeadline){}每种策略估算成本publicrecordStrategyCostEstimate(intgenerationCalls,intembeddingCalls,intretrievalCalls,intrerankCandidates,intestimatedTokens,BigDecimalestimatedCost,DurationestimatedLatency){}预算不足时按顺序降级问题分解 → Multi-Query → Rewrite → Raw Hybrid二十、候选融合多查询召回不能简单拼接。常见方法去重后取最高分-加权分数-RRF-DBSF-统一Reranker。RRF示例score(document)Σ1/(krank_i(document))实现时稳定Key应包含tenant_id document_id document_version chunk_id不能只按正文Hash去重否则不同版本可能被错误合并。二十一、权限不能在增强之后补Multi-Query、HyDE和问题分解都不能扩大用户权限。每一次检索必须携带同一个AccessContext Metadata Filter ACL不能让子问题生成查询所有客户合同然后再期待答案阶段不泄露。二十二、如何评测真实增益指标至少包括RecallK MRR NDCG PrecisionK required_document_recall forbidden_document_rate claim_support_rate P50/P95延迟 单请求成本 候选数量 Reranker输入量按查询类型分Slice短Query-精确Token-多跳-口语-多轮-高风险-无证据。全局平均提升不能掩盖精确编号查询退化。二十三、PoC设计同一数据集运行BaselineRaw Hybrid Candidate AMulti-Query Candidate BRawHyDE Candidate CDecomposition记录每条Case召回文档 生成Query 假设文档 子问题 融合排名 Rerank结果 最终答案 成本 延迟概率性生成至少重复3次。二十四、推荐上线策略阶段一影子只记录候选策略不影响用户。阶段二低风险Query先开放FAQ-无精确编号-无副作用-无权限敏感。阶段三按Slice扩大分别观察Recall提升-Precision下降-成本-延迟-错误实体。阶段四保留策略开关rag:query-enhancement:multi-query-enabled:truehyde-enabled:falsedecomposition-enabled:false每种策略独立回滚。二十五、常见错误所有Query都生成5个变体 只使用增强Query丢弃原始Query HyDE假设文档直接作为真实证据 问题分解不继承全局过滤条件 候选不去重直接送Reranker 不限制查询数量和并发 只看Recall不看Precision与成本 没有保存生成Query无法复现二十六、上线前检查清单□ 已明确当前召回缺陷类型 □ 精确Token查询优先保留原始Query □ Multi-Query执行语义去重 □ HyDE不作为最终证据 □ HyDE Prompt禁止发明具体实体 □ 子问题继承全部全局约束 □ 所有分支使用同一AccessContext □ 查询、检索和候选数量均有预算上限 □ 候选使用稳定文档Key去重 □ 融合后再进入统一Reranker □ 每种策略独立可关闭和回滚 □ 评测同时检查Recall、Precision、延迟和成本 □ 高风险Slice单独设置门禁总结Multi-Query、HyDE和问题分解分别解决表达不一致 语义表示不足 复杂问题不可一次检索推荐原则是精确查询保留Raw 表达多样使用Multi-Query 短抽象查询尝试HyDE 多跳任务使用问题分解真正成熟的RAG系统不会固定使用一种查询增强策略而是根据Query特征、风险、预算和真实评测结果动态选择并始终保留原始Query作为安全基线。