用户问题太短太口语化，RAG 的 Query 改写怎么做？
面试怎么回答
用户问题常见的毛病是太短模糊、口语和术语不一致、依赖上下文、多意图、错别字缩写。我的改写方式有：结合对话历史做指代消解，生成独立完整的问题；用业务术语表或模型做同义扩展，多路检索合并；多意图拆成子查询；必要时用假设答案做向量检索；从问题里提取时间、部门等转成元数据过滤；实在太模糊就反问澄清。改写可能改错，所以原问题和改写后的问题一起检索再合并，用小模型降低成本，记录改写前后的内容便于排查，并在检索评测集上对比召回率。术语表可以从搜索和对话日志里持续挖掘维护。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
用户在知识库助手里输入：「那个报销咋弄」「上次说的那个表」「还是不行」。这样的问题直接拿去检索，基本找不到有用的东西。面试官问 Query 改写，想看你怎么把用户的真实意图转换成适合检索的查询。
常见的问题类型
- 太短、太模糊：「报销」—— 是差旅报销、招待费报销，还是报销进度查询？
- 口语和术语不一致：用户说「跑数」，文档写「离线任务调度」；
- 依赖上下文：「它的负责人是谁」，「它」指的是上一轮提到的表；
- 一个问题包含多个意图：「XX 表的口径是什么，最近为什么延迟」；
- 有错别字或缩写：「dws 层」「GVM」。
改写的几种方式
- 指代消解和补全：结合对话历史，把「它」「那个」替换成具体对象，生成一个独立完整的问题。这是多轮对话里最重要的一步；
- 同义扩展：维护业务术语表（口语 → 规范术语，缩写 → 全称），或者让模型生成几个同义说法，多路检索后合并；
- 问题拆分：多个意图拆成多个子查询，分别检索；
- 假设答案检索（HyDE）：让模型先写一个「假设的答案」，用这个答案去做向量检索。因为答案和文档的表达方式更接近，有时召回更好；
- 提取过滤条件：从问题里识别时间、部门、产品等，转成元数据过滤；
- 澄清：确实太模糊时，反问用户而不是硬猜，比如「你是想了解差旅报销的流程，还是查询报销进度？」
注意事项
- 改写会改错：模型可能误解意图，改写后反而偏离。可以同时用原问题和改写后的问题检索，合并结果；
- 延迟和成本：每次改写多一次模型调用，可以用小模型做；
- 可观测：记录原问题和改写结果，排查时能看到是不是改写出了问题；
- 评测：在检索评测集上对比改写前后的召回率。
术语表是数据团队的资产
数据团队可以从搜索日志、对话日志中挖掘高频的口语表达，和规范术语建立映射，持续维护。这比单纯依赖模型改写更稳定。