前言
用户在 RAG（检索增强生成）应用里提出的问题，往往并不是知识库中最容易被检索到的表达。
比如，用户问：“这个产品支持离线使用吗？”
而文档里写的是：“客户端提供本地缓存与断网可用能力。”
两者语义接近，但关键词几乎没有重合。若系统只拿用户原句做向量检索或关键词检索，很可能漏掉真正相关的内容。查询扩展就是为弥补这种鸿沟而出现的：它在检索前，主动把一个简短、口语化或含糊的问题，扩展为多个更适合“找资料”的查询表达。
查询扩展是什么
查询扩展是一类检索优化技术：系统不局限于用户输入的原始问题，而是生成或补充一组相关词、同义表达、上下文限定、子问题或假设性答案，再用它们共同检索知识库。
它不是替用户“改写问题”这么简单。更准确地说，它是在用户语言与知识库语言之间建立桥梁。
以“员工怎么申请报销？”为例，查询扩展可能产生：报销流程、费用报销审批、差旅费用申请、发票提交规范、企业费用管理制、报销申请单填写要求。这些表达未必都会展示给用户，但会成为检索阶段的辅助入口。系统可分别检索，再融合并重排结果，最后交给大模型生成答案。
为什么 RAG 特别需要它
RAG 的回答质量，本质上受制于检索上下文的质量。
即使生成模型再强，如果检索阶段没有找到正确资料，它也只能基于不完整甚至无关的上下文作答。查询扩展提升的正是“召回率”——让更多潜在相关的资料进入候选集合。
RAG 中常见的查询难题包括：
- 用户表达和文档表达不一致。用户说“退款”，制度文档可能写“撤销订单后的资金原路退回”。
- 问题过短，缺少约束。例如“怎么配置权限？”没有说明角色、产品模块或权限类型。
- 问题包含多意图。例如“部署后为什么登录不了、日志在哪里看？”实际包含故障排查与日志查询两个任务。
- 专业术语不统一。同一个概念可能同时存在英文缩写、行业名称、内部名称和俗称。
- 知识库结构复杂。答案分散在 FAQ、产品手册、操作规范和历史公告中，单次检索难以覆盖。
查询扩展的价值并不是让系统“搜索得更多”，而是让系统更有机会找到真正能回答问题的证据。
常见的查询扩展方式
1. 同义词与别名扩展
这是最基础也最容易落地的方式。系统根据词典、业务术语表或模型能力，将核心词替换或补充为近义表达。
例如：
| 用户表述 | 可扩展表达 |
|---|---|
| 登录不了 | 无法认证、鉴权失败、账号无法进入 |
| 订单取消 | 撤单、关闭订单、终止交易 |
| 离线使用 | 断网可用、本地缓存、无网络模式 |
| 权限 | 角色授权、访问控制、RBAC、成员权限 |
这种方式适合术语高度稳定、业务词汇明确的企业知识库。
2. 查询改写
查询改写不是简单替换词语，而是把用户的口语表达转换为更完整、更适合检索的句子。
例如，用户输入“新版有什么变化”，可以改写为：
查询产品最新版本的功能更新、兼容性变化、已废弃能力及升级注意事项。
改写能补齐检索对象与查询维度，让模糊问题变得更可检索。
3. 多查询生成
系统为一个问题生成多个语义不同但相关的问法，并分别检索。
例如，“如何降低 Redis 缓存穿透的风险？”可以拆成：
- Redis 缓存穿透的定义与成因
- 缓存穿透的布隆过滤器方案
- 空值缓存策略
- Redis 缓存穿透防护最佳实践
这尤其适合复杂技术问题，因为答案通常分布在多个主题片段中。
4. 问题分解
当问题包含多个子任务时，先拆解再检索往往比整体检索更准确。
例如：
“我们的订单接口变慢了，如何定位问题并优化 Redis？”
可以拆为：
- 订单接口延迟的常见排查指标
- Redis 慢查询与延迟诊断
- Redis 连接池与网络配置
- 热点 Key、缓存击穿和大 Key 优化
问题分解适合故障排查、方案设计、对比决策等多步骤任务。
5. HyDE：先生成“假设答案”，再检索
HyDE 是一种更有意思的方法。系统先让模型写出一段“可能的答案”，再用这段假设性文本的向量去搜索真实知识库。
为什么有效？因为用户问题通常很短，而文档段落通常更长、包含更多技术细节。假设答案在形式上更接近真实文档，向量检索更容易匹配到相似内容。
但它也有风险：假设答案可能夹带错误前提。因此 HyDE 应当只用于辅助检索，最终答案仍必须以真实检索证据为依据。
查询扩展不是越多越好
查询扩展最容易掉进一个误区：生成越多查询，检索就越全面。
实际上，过度扩展会带来三个问题：
- 噪声增加：不相关内容进入候选集，挤占真正证据的位置。
- 意图漂移：系统将用户问题“理解过头”，检索到别的问题上。
- 成本和延迟上升：每多一个查询，通常就多一轮检索、嵌入或重排开销。
例如，用户问“如何重置密码”，如果系统把“重置”扩展为“恢复、初始化、清除、删除账号”，就可能召回严重偏题的内容。
因此，一个成熟的 RAG 系统应遵循“有限扩展、证据优先”的原则：
- 只保留与原问题语义接近且互补的扩展查询；
- 对每一路检索结果打分与去重；
- 使用重排序模型筛选最相关片段；
- 当证据不足时，明确回答“知识库中未找到足够依据”，而不是强行生成。
如何判断是否该引入查询扩展
如果你的 RAG 应用已经出现以下现象，通常值得尝试查询扩展：
- 用户明明换一种说法就能得到正确答案；
- 知识库术语多、缩写多、内部叫法多；
- 用户常输入极短问题；
- 长问题中包含多个意图；
- 向量检索看似“语义相近”，但关键规则总是漏召回；
- FAQ、产品文档与制度文档的表述风格差异明显。
对于结构简单、术语统一、文档规模较小的知识库，先做好分块、元数据过滤、混合检索和重排序，往往比立即引入复杂扩展更划算。
一个实用的落地策略
可以采用由轻到重的四层方案：
- 建立业务同义词和别名词典。
- 对短问题执行一次查询改写。
- 对复杂问题生成 2～4 个互补子查询。
- 将多路结果融合后进行重排序，再限制进入模型上下文的片段数量。
同时，应记录“原始问题—扩展查询—召回文档—最终答案”的完整链路。这样，当回答不理想时，团队能准确判断问题出在理解、扩展、检索、重排还是生成环节。
结语
查询扩展的本质，是让 RAG 不再机械地拿用户原句去“碰运气”，而是主动理解用户真正想找什么，并用知识库更容易理解的语言去寻找证据。
它不能代替高质量文档、合理分块和可靠重排序，但能显著缓解用户语言与企业知识之间的表达鸿沟。一个好的 RAG 系统，既要听懂人话，也要会说“资料库的话”。
