在 RAG 系统中，检索质量直接影响最终回答的准确性。很多人将注意力集中在知识库构建和模型调优上，却忽略了一个关键环节：用户输入的原始问题往往并不适合直接用于检索。查询优化（Query Optimization）的目的，就是对用户问题进行改写、扩展或分解，使其更匹配知识库的索引特征，从而召回更相关、更完整的上下文片段。
14.2.1 为什么原始查询不够好
真实场景中的用户提问普遍存在以下问题：
- 用词口语化或模糊：用户可能问“那个怎么弄”，而不使用文档中的正式术语。
- 信息密度低：问题中包含大量背景叙述，但真正的检索意图只有几个关键词。
- 范围过宽或过窄：“最近有什么新政策”太宽泛；“3月15日下午发的那个通知”缺少实质内容。
- 多意图混合：一句话里问了多个独立问题，例如“年假怎么算？如果没休完能折现吗？申请流程是什么？”
- 与知识库用词不一致：用户说“退款”，文档里写的是“退货退款流程”；用户说“打卡”，文档里是“考勤签到”。
直接将这类原始查询进行向量化检索，得到的结果往往包含大量噪声，漏掉真正关键的内容。
14.2.2 常见查询优化方法
以下方法可以单独或组合使用，根据业务场景灵活选择。
1. 查询重写（Query Rewriting）
让 LLM 在检索前先对用户问题进行重构，使其更接近知识库中的表达方式。
- 去口语化与标准化：将“那玩意儿咋退货啊”改写为“如何申请退货”。
- 补充上下文：结合对话历史，将“那个通知具体怎么说”改写为“关于2025年年假调整的通知具体内容是什么”。
- 术语对齐：将业务黑话转为正式术语，如“撸铁福利”改写为“员工健身房报销政策”。
实现方式通常是在检索前调用一次轻量 LLM，提示词大致如下：
你是一个查询优化助手。请将用户的原始问题改写成一个更清晰、更完整、更适合在知识库中检索的查询语句。不要添加多余解释。
这一步的代价很小（只生成一句话），却能让后续检索的命中率大幅提升。
2. 多查询生成（Multi-Query Generation）
针对用户问题，生成多个不同角度、不同措辞的子查询，分别检索后合并结果。这种方法尤其适合覆盖范围较广或表述模糊的问题。
- 原始问题：“出差报销需要注意什么？”
- 生成的子查询：
- “出差报销需要提交哪些材料？”
- “出差住宿和交通费标准是多少？”
- “出差报销审批流程是什么？”
多查询并行检索后，将各组结果的并集或去重后的片段一起送入生成步骤，能显著提高关键信息的召回完整性。
3. 假设文档嵌入（HyDE）
HyDE（Hypothetical Document Embedding）的基本思路是：让 LLM 先凭空“写出”一个可能回答当前问题的假设性文档，然后将这个假设文档进行向量化，用它去知识库中检索真正的内容。
这种方法利用了大模型对文本结构的理解能力。即便假设文档包含不准确的事实，它的用词风格和段落结构往往与知识库中的真实文档高度相似，因此其向量更容易匹配到相关片段。
例如，用户问：“工伤认定的标准是什么？”模型先生成一个假设回答：
“根据《工伤保险条例》，工伤认定需要满足在工作时间和工作场所内，因工作原因受到事故伤害等条件……”
哪怕这个假设回答并不完全准确，它包含的关键词与句式也能帮助检索模块在法条原文中找到真正对应的条款。
4. 查询分解（Query Decomposition）
针对包含多个独立子问题的复杂查询，先将其拆解为多个简单查询，分别检索并回答，最后汇总。
- 原始问题：“季度绩效评估怎么打分？什么时候提交？结果会影响奖金吗？”
- 拆解后：
- 子问题1：季度绩效评估的评分标准和打分流程
- 子问题2：季度绩效评估的提交截止日期
- 子问题3：季度绩效结果与奖金的关联规则
每个子查询单独检索和处理，最后将各部分的答案组合起来。这样避免了“一锅粥”式的检索导致所有子问题都答得不够深入的问题。
5. 对话历史感知的查询补全
在多轮对话场景中，用户的当前问题往往依赖之前讨论的上下文。如果不做处理，“它怎么申请”这种问题完全无法独立检索。
通过在查询优化时注入最近的对话历史，将省略的信息补全：
- 用户第1轮：“今年的体检合作机构有哪些？”
- 用户第2轮：“预约流程是什么？”
优化后发给检索的应该是：“2025年度员工体检合作机构的预约流程是什么”。
14.2.3 整合到 RAG 流水线
查询优化模块通常放置在用户输入到达后、向量检索开始前。一个经过优化的标准流水线如下：
- 接收用户原始输入（含对话历史）
- 查询优化处理：改写/补全/分解（可组合使用）
- 向量检索：用优化后的查询在知识库中召回片段
- 生成：将检索结果与优化后的查询一起送入 LLM
在实践中，不建议所有查询都走完整的优化链路。可以根据问题复杂度判断：简单术语类问题可直接检索；需要多步推理或明显口语化的触发重写；复杂多意图的触发分解。这样能平衡效果与延迟。
14.2.4 实用建议与注意事项
- 先评估，再优化：在盲目加查询优化前，用一批真实问题测试当前检索的召回率和准确率，找出是哪些类型的问题在吃亏，然后针对性优化。
- 保持轻量：查询优化本身增加了一次 LLM 调用（或多次，如果是多查询生成）。选择小模型、复用 embedding 调用、设置缓存等手段可以控制延迟和成本。
- 不要忽略停用词和标点：某些优化方法会过度精简查询，去掉看似无关的词，反而丢失了用户强调的限定条件（如“必须”“不包括”）。
- 定期评估优化效果：查询优化带来的提升是否稳定，需要通过持续的线上评估（如用户反馈、人工抽检）来验证。
- 与知识库维护协同：如果查询优化反复出现某些术语映射不到文档的情况，也许说明知识库本身缺少该角度内容，应从内容侧补充。
查询优化是连接用户真实意图与知识库内容的桥梁。一个设计得当的查询优化策略，可以在不修改检索器和模型的前提下，明显提升 RAG 系统的回答质量，是投入产出比很高的改进方向。