查询改写配置怎么设置，检索结果才不跑偏

查询改写配置的核心只有一句话：先确认原始查询本身能召回相关文档，再开启改写。
如果原始检索就已经跑偏，改写只会把偏差放大。
下面按“判断是否需要、配置、验证、避坑”的顺序说明，环境以常见的检索服务或 RAG 框架的查询改写模块为例，具体参数名以你所用版本的界面或配置文件为准。

先判断：你的检索真的需要改写吗

查询改写（Query Rewrite）是在检索前用模型把用户问题改写成更适合检索的表达，常见形式有同义扩展、补全上下文、拆分子问题。
它解决的是“用户问法太短、太口语、指代不清”导致的召回不足，而不是解决所有检索问题。

动手配置前，先用 10 到 20 条真实用户问题跑一遍原始检索，记录每条问题返回的前几条文档是否相关。
判断标准可以这样定：

• 原始查询能召回相关文档，只是排序靠后：优先调召回数量和重排序，不必急着开改写。
• 原始查询召回为空或明显不相关，且问题本身很短、有代词、有口语化表达：适合开启改写。
• 问题本身已经很长很具体：改写收益通常有限，反而可能引入噪声。

这个前置检查能避免一个常见误区：把检索不准全归因于没开改写。

配置查询改写的关键项

不同框架的配置入口不一样，但需要关心的项基本一致，下面按通用结构说明。

改写模型：选择支持指令跟随的对话模型，温度建议调低（如 0 到 0.3），避免每次改写结果差异过大导致检索不稳定。
模型能力不足时，改写结果可能偏离原意。

改写提示词：明确要求模型只输出改写后的查询，不要解释、不要回答问题。
提示词里要交代业务背景，比如“这是电商商品检索场景，保留品牌名和型号”。
提示词写得越模糊，改写越容易跑偏。

改写结果数量：多数实现支持一次生成多个改写查询，然后分别检索再合并。
数量不是越多越好，通常 2 到 3 个足够，过多会拉高延迟并引入不相关文档。

是否保留原始查询：建议保留，把原始查询和改写查询一起检索。
这样即使改写失败，也不会比不改写更差。

超时与降级：改写依赖模型调用，要设置超时时间，并配置失败时回退到原始查询，避免模型服务抖动导致整个检索不可用。

一个示意性的配置思路如下，字段名请按你实际使用的框架调整：

query_rewrite:
  enabled: true
  model: your-chat-model
  temperature: 0.2
  max_rewrites: 3
  keep_original: true
  timeout_ms: 3000
  fallback_to_original: true

如果是面板类产品，一般在“检索设置”或“查询处理”里能找到改写开关、模型选择和最大改写数量，路径以实际界面为准。

改写后怎么验证效果

配置完不要直接上线，用前面那批测试问题做对比验证，重点看三个指标：

• 相关文档召回率：改写后相关文档是否出现在结果中，尤其关注原来召回为空的问题。
• 结果稳定性：同一条问题连续跑几次，返回结果是否基本一致，波动大说明温度或提示词需要收紧。
• 响应延迟：改写增加了一次模型调用，记录平均耗时，确认在业务可接受范围内。

验证时建议固定测试集和评分标准，人工标注每条问题“命中、部分命中、未命中”，逐条对比改写前后。
只凭一两次感觉判断，很容易得出错误结论。

容易踩的坑

改写过度导致语义漂移：模型把“iPhone 15 电池”改写成“手机配件推荐”，检索自然跑偏。
解决办法是提示词里强调保留实体词，并限制改写结果数量。

对所有查询一律改写：长查询、明确查询没必要改写。
可以按查询长度或是否包含代词做条件判断，只对短查询启用。

忽略改写结果的去重：多个改写查询可能高度相似，检索前做一次去重能减少重复文档。

没有降级方案：模型超时或报错时，检索要能回退到原始查询，否则一次模型故障就会让整个问答不可用。

常见疑问

查询改写和查询扩展是一回事吗？
查询扩展是改写的一种，侧重补充同义词和相关词；
改写范围更广，还包括补全上下文、拆分子问题。
配置时先明确你要解决的是哪类问题。

改写开启后结果反而变差怎么办？
先关掉改写对比原始结果，确认是改写引入的问题；
再检查提示词是否约束了输出格式，以及是否保留了原始查询一起检索。

改写会增加多少成本？
每次检索多一次模型调用，成本取决于模型单价和调用量。
对高频检索场景，可以先对部分查询开启，观察效果和成本再决定是否全量。

总结一下：查询改写配置的重点不在开关本身，而在前置判断、提示词约束、结果数量控制和失败降级这四件事。
按测试集验证通过后再逐步放量，比一次性全量开启更稳妥。