考察点
「如何润色 query，目的是什么」是面经原题。面试官想看你是否意识到：用户说的话和文档里写的话之间有鸿沟，检索前处理是性价比最高的优化点之一。追问常走「改写引入噪声怎么办」「多轮对话怎么处理」。
参考答案
为什么要改写
用户 query 和知识库文档之间存在系统性错位：用户说口语（「不想要了能退吗」），文档写书面语（「七天无理由退货政策」）；用户在多轮对话里说指代（「那这个呢」「怎么收费」），检索时丢掉上下文就是个废 query；用户问复杂问题（「对比 A 和 B 的保修」），单个向量无法同时表达两个子意图。Query 改写就是检索前的翻译层，把「用户的话」翻成「检索系统好找的话」。
四种改写技术
1. 上下文补全（多轮指代消解）
多轮对话场景必做。把最近几轮对话和当前 query 一起给一个 LLM，让它输出一条独立的、自包含的检索 query。比如用户先问「你们云服务器怎么卖」，再问「带宽呢」，改写成「云服务器带宽怎么收费」。这是所有改写里收益最确定的一种，不做的话多轮场景检索直接崩。
2. 同义/术语扩展
把口语词映射到领域术语：「不想要了」→「退货、七天无理由」。做法两种：离线维护同义词词典（BM25 检索侧用），或者让 LLM 生成 2-3 个语义变体，多路并行检索后融合。
3. HyDE（假设性文档嵌入）
思路很巧：不直接检索 query，而是先让 LLM 根据 query「瞎编」一段理想答案，拿这段假答案的向量去检索。因为答案和文档在同一语言空间（都是陈述句），比疑问句形态的原始 query 更接近真实文档。对短 query、跨语言检索有提升，代价是多一次 LLM 调用的延迟，且假设答案编歪了会把检索带沟里——知识缺口大的 query 慎用。
4. 子问题分解
复杂多意图 query（「A 产品和 B 产品的保修政策有什么区别，过保了怎么办」）拆成 2-3 个独立子 query 分别检索，结果合并去重。这是 Agentic RAG 的雏形，对对比类、多实体类问题效果显著。
工程实现要点
- 用小模型：改写不需要 GPT-4，1.5B-7B 的本地模型（Qwen2.5-7B 级别）加个清晰的 Prompt 就够，延迟控制在 100-300ms。改写是高频调用，成本敏感。
- 并行不串行：改写和可以预取的操作并行；多 query 变体并行检索，总延迟不超过最慢一路。
- 保留原始 query：改写结果和原始 query 一起多路检索，融合时原始路权重不低于改写路。改写是增强不是替代——改写模型理解错了，原始 query 还能兜底。
- 加护栏：改写的 Prompt 里明确「不得添加原 query 没有的事实，不得回答用户问题」，并设长度上限。没有护栏的改写会幻觉出不存在的需求，把检索带到不存在的内容上。
效果验证
改写是典型的「可能帮也可能害」的优化，必须 A/B：评测集上对比「原始 query 直检」vs「改写后检索」的 Recall@K。我的项目里多轮补全带来约 20 个点的召回提升（基数低），HyDE 提升 3-5 个点但延迟涨 200ms，最后只在短 query（少于 10 字）时触发 HyDE——按 query 特征路由不同改写策略，而不是全量堆。
可能的追问
Q：改写模型自己幻觉怎么办？ 三道防线：Prompt 约束「只重写不回答」；输出做事实校验（改写结果里的实体必须在原 query 或对话历史里出现过）；原始 query 始终作为一路保留。
Q：多轮对话历史带多少？ 最近 3-5 轮足够，更早的指代极少见。别带完整会话——改写模型的输入越长，它「自由发挥」的空间越大。
Q：什么 query 不该改写？ 已经很精确的信息型 query（「SK-8848 保修多久」）改写的期望收益为负，任何改写都是在给确定性引入噪声。按 query 长度和实体密度做路由判断。