用户 Query 长什么样先把问题摆出来。你的 RAG 系统接到的查询90% 不长这样“请问 Transformer 的 Multi-Head Attention 机制与 Scaled Dot-Product Attention 的数学关系是什么”它们长这样• “那个东西咋退货”• “帮我查一下 Q3 财务那页”• “跟上周说的一样的问题”• “xxx 怎么弄”5 个字的短 queryembedding 之后落到语义空间里离真实答案文档的距离比一段完整的描述性文字远得多。用这个向量去检索本质上是在用碎片指纹匹配完整脸。检索层再强Query 层不做处理召回天花板就摆在那儿。四种 RAG 查询改写技术一张地图看清楚改写方向可以沿两个维度来分按改写方向 扩展变多 压缩变少/变抽象 ┌──────────────┬──────────────┐扩展 │ Multi-Query │ Step-back │假设 │ HyDE │ Query 改写 │ └──────────────┴──────────────┘•扩展派Multi-Query、HyDE——覆盖面广代价是检索路数变多•压缩派Step-back、Query 改写——聚焦精准代价是可能丢细节四种方法不是竞争关系是不同问题的不同解法。下面逐个拆。方法一Query 改写——成本最低先上原理口语化 query → 书面化精确表达。用户问“那个东西咋退货” → 改写后“如何申请商品退货及退款流程”一次 LLM 调用延迟 ~0.5s是四种方法里最轻量的。适用场景用户提问质量差——口语化、缩写、错别字、指代不清。企业内部知识库场景这种情况尤其高发因为用户习惯像聊天一样发消息。代码示意from openai import OpenAIclient OpenAI()def rewrite_query(raw_query: str) - str: prompt f将以下用户问题改写为适合文档检索的规范表达。要求书面化、消除歧义、保留核心意图。只输出改写后的问题不要解释。用户原始问题{raw_query}改写后 response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.0, ) return response.choices[0].message.content.strip()小七注temperature 设 0 是为了改写结果稳定可复现。如果你的场景对多样性有要求比如同一 query 每次稍微换个角度可以调到 0.30.5。方法二Multi-Query——歧义问题的通用解原理把一个问题改写成 3~5 个不同角度的子问题分别检索结果合并去重。原始「这个东西咋退货」 ├── 改写1退货流程和操作步骤 ├── 改写2如何申请退款 ├── 改写3售后服务政策 └── 改写4商品退换货规定- 4 路结果合并去重 - 召回覆盖率 10~15%S2/S7通用场景估算召回率提升的来源很直观不同角度的改写覆盖了原始 query 没有触达的语义区域。一个反直觉发现某 RAG benchmark 测试S6探索性质HotpotQA 50 条中Multi-Query 扩展2 个改写 1 个 step-back 查询在两跳问题HotpotQA上比 GraphRAG 高18 个百分点0.60 vs 0.42。更反直觉的是——这个测试里用的是 Qwen-1.5B-Instruct4-bit一个非常小的模型。改写质量本身参差不齐但 RRF 融合把噪声吸收掉了。你不需要一个超强的大模型来做改写。另一个工程细节很重要原始问题必须保留在检索路里。别只用改写版本改写过程可能丢失细节原始 query 是 ground truth。代码示意def generate_multi_queries(raw_query: str, n: int 4) - list[str]: prompt f为以下问题生成 {n} 个不同角度的改写版本用于文档检索。每行一个问题不要编号不要解释。原始问题{raw_query} response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.7, ) rewrites response.choices[0].message.content.strip().split(\n) rewrites [q.strip() for q in rewrites if q.strip()] return [raw_query] rewrites # 保留原始 querydef multi_query_retrieve(raw_query: str, retriever, top_k: int 5) - list: queries generate_multi_queries(raw_query) all_docs [] seen_ids set() for q in queries: docs retriever.retrieve(q, top_ktop_k) for doc in docs: if doc.id not in seen_ids: all_docs.append(doc) seen_ids.add(doc.id) return all_docs方法三HyDE——短 Query 场景的杀手锏原理不用原始 query 的 embedding 去检索而是先让 LLM 生成一段假设答案~200 字再用假设答案的 embedding 去检索。直觉是对的5 个字的 query 和 200 字的假设答案哪个离真实答案文档在语义空间里更近HyDEHypothetical Document Embeddings来自 CMU 的论文S4arXiv 2212.10496在多种数据集上优于 BM25 和无监督 Contriever在 TREC DL19/20 上与微调模型保持竞争力多语言检索韩语、日语也有显著提升S4 定性结论S5 转述。零样本通用场景下估算召回提升15~25%S2英文场景通用估算且 LLM 调用次数不增加——用假设答案替换原 query检索路数不变。def hyde_retrieve(raw_query: str, retriever, top_k: int 5) - list: # 生成假设答案 prompt f请为以下问题写一段假设性的回答约150-200字。不需要真实准确只需要在语义上接近可能的真实答案文档。问题{raw_query}假设回答 response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.7, ) hypothetical_doc response.choices[0].message.content.strip() # 用假设答案而非原始 query 去检索 return retriever.retrieve(hypothetical_doc, top_ktop_k)HyDE 的反模式数值查询和精确匹配别用这是踩坑最多的地方必须单独说。用户问“帮我找 2024 年 Q3 的财务报告净利润那页”LLM 生成的假设答案会编造假数字——“2024 Q3 净利润同比增长 23.5%”。用这个编造数字的向量去检索会把方向拉向讨论增长率的文档而不是真实报表。arXiv 2604.01733 这篇 benchmark 论文S1明确指出HyDE 对数值查询有害S1 S2 双源核实。决策规则• Query 含精确数字、人名、编码、型号、日期 →跳过 HyDE直接检索或走 metadata filter• 短 query、模糊概念、知识问答类 → HyDE 效果最好方法四Step-back Prompting——“先想原理”原理把具体问题先后退一步抽象为更通用的原理性问题先检索原理再映射回具体场景。Google DeepMind 2023 年的论文S3arXiv 2310.06117ICLR 2024验证了这个思路方法MMLU PhysicsMMLU ChemistryPaLM-2L 基线66.4%70.9%PaLM-2L CoT65.0%75.3%PaLM-2L Step-Back73.2%81.8%GPT-470.3%79.9%Physics 6.8ppChemistry 10.9pp。Step-Back 打败了 GPT-473.2% vs 70.3%。注意这组数字是 LLM 推理场景非 RAG 系统直接数据作为方法有效性的原理支撑。RAG Step-Back 的变体在 TimeQA 上提升 27.2ppS3PaLM-2L Step-Back RAG vs 基线——但这是 LLMRAG 变体的组合效果不要单独归功于 Step-back。RAG 场景的用法用户问「特斯拉 2024 Q3 电池成本下降的原因是什么」 ↓ Step-back先检索「影响动力电池成本的关键技术和经济因素有哪些」 ↓ 检索原理文档再映射拿着原理去回答具体问题代码示意def stepback_retrieve(raw_query: str, retriever, top_k: int 5) - list: # 生成后退问题 prompt f将以下具体问题后退一步生成一个更通用、更原理性的版本。只输出改写后的问题不要解释。具体问题{raw_query}更通用的原理性问题 response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.0, ) abstract_query response.choices[0].message.content.strip() # 双路检索原始 query 后退 query original_docs retriever.retrieve(raw_query, top_ktop_k) abstract_docs retriever.retrieve(abstract_query, top_ktop_k) # 合并去重 seen_ids set() all_docs [] for doc in original_docs abstract_docs: if doc.id not in seen_ids: all_docs.append(doc) seen_ids.add(doc.id) return all_docs不适用场景简单事实查询特斯拉 CEO 是谁不需要后退精确数值查询后退反而引入噪声。RAG 查询改写成本对比选哪个方法LLM 调用额外检索路延迟增加何时该用Query 改写10~0.5s用户提问质量差Multi-Query3 路1批量生成3 路~2s歧义、多变、多跳推理HyDE10替代原 query~1s短 query、零样本、非数值Step-back11 路~1s过于具体、需背景知识四者组合1~2可合并3~5 路~3s召回要求极高85%有一个工程细节容易忽略多查询扩展虽然增加检索路数但 LLM 调用可以合并。一次生成多个改写 step-back 问题实际边际成本主要是检索延迟不是 LLM 调用费。3s 额外延迟换来的是召回率大幅提升大多数场景值。RAG 查询改写决策树你的场景该用哪个用户 Query 进来 │ ▼含精确数字/人名/型号/日期 ├── 是 → 直接检索或 metadata filter跳过 HyDE 和 Step-back └── 否 → 继续 │ ▼ Query 质量差口语化/缩写/错别字 ├── 是 → 先做 Query 改写成本最低 └── 否 → 继续 │ ▼ 问题过于具体缺背景知识 ├── 是 → Step-back双路原始 后退 └── 否 → 继续 │ ▼ Query 很短10字或零样本场景 ├── 是 → HyDE └── 否 → 继续 │ ▼ 问题多义/歧义/多跳 ├── 是 → Multi-Query └── 否 → 直接检索不需要改写 这张决策树建议收藏RAG 系统设计时对照着用。组合用法SEQUOIA Pro 的做法查询层四种方法不互斥可以叠加。某 RAG benchmarkS6探索性HotpotQA 50 条样本测试了一个叫 SEQUOIA Pro 的配置2 个 Multi-Query 改写 1 个 Step-back 查询三路独立检索后 RRF 融合。在两跳推理问题HotpotQA上的结果方法HotpotQA gold_in_contextSEQUOIA ProMulti-Query Step-back0.60GraphRAG0.42Agentic RAG0.00Multi-Query 扩展比 GraphRAG 高 18pp比 Agentic RAG 高 60pp。而且延迟约 10s/样本比 Agentic RAG 的 30~40s 快3 倍。⚠️ 数据来源B 级开源项目样本量小有探索性质。但方向是对的查询理解层组合改写 RRF 融合是应对复杂多跳问题的高 ROI 路径。和 Reranker 的关系有一个常见误解需要说清楚。查询改写解决的是召回前的问题Reranker 解决的是召回后的问题。两者互补不是二选一。• 查询层处理得好 → 更多相关文档进入召回集 → Reranker 有更好的候选可排• Reranker 再强召回集里没有相关文档它也排不出来完整的 RAG 链路是用户 Query ↓查询理解层改写 / HyDE / Multi-Query / Step-back ↓多路检索向量 BM25 混合 ↓RRF 融合 ↓Reranker 精排 ↓LLM 生成答案从投入产出比来看如果你的系统还没有查询理解层先在这里优化比换更好的 Embedding 模型便宜得多提升幅度也不会更小。小结RAG 查询理解层该不该上•漏召的根源往往在检索之前Query 质量差是系统层可以干预的问题不要等用户自己改写•四种方法各有适用场景不是越多越好对照决策树按需叠加•HyDE 遇到数值/精确查询时有害这个反模式要内置进路由逻辑•小模型做改写也够用RRF 融合能吸收改写噪声不需要 GPT-4 级模型•12 次 LLM 调用换来 1025% 的召回提升是查询理解层的基本价值主张学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】