面试题 · RAG
在信息检索或RAG系统中，Query改写技术有哪些常见的创新方法？例如同义扩展、语义重写、对话历史融合等，其各自优势是什么？
将用户原始Query转化为检索友好的形式，解决语义鸿沟、歧义、上下文依赖等问题，提升召回率和相关性。
做法：基于词典、Embedding相似度或生成模型，扩展同义词、近义词、缩写/全称
优势：
：Word2Vec/ fastText相似词、BM25+同义词表、T5生成扩展
学习内容与项目面试，在同一条路上。
做法：用Seq2Seq或LLM直接改写Query，改变句式但保留意图
优势：
典型技术：T5/BART微调、LLM Prompt工程（"请将以下Query改写为适合检索的形式"）
做法：将多轮对话历史编码，解决指代和省略
优势：
典型技术：
| 挑战 | 解决思路 |
|---|---|
| 属性对齐 | "大屏手机"→屏幕尺寸>6.5英寸，需对接知识图谱 |
| 品牌词保护 | 改写时锁定品牌实体，防止"小米"→"大米" |
| 库存感知 | 改写结果过滤无货SKU，或提示"相似款" |
建议系统学习该知识点
场景切入
假设你在做一个电商客服机器人，用户问“有没有红色的连衣裙”，你召回一些商品后，他又说“那个带花的呢？”，这时候你打算怎么改写用户的后一句Query，让它能检索对？
层层追问
RAG系统里用户的原始Query直接去检索，效果往往不好，你会怎么处理？……除了同义词替换，还有哪些改写的思路？……那如果用户说的是“这个多少钱”，你怎么结合上文把它改完整？
直球架构
聊聊Query改写常见的创新方法吧，比如同义扩展、语义重写、对话历史融合，它们各自解决什么问题，优势是什么？你在实际项目中怎么选型？
这道题其实是在问，怎么把用户说的那句人话，翻译成检索系统能听懂的语言。用户说「那个红色的」，系统得知道「红色连衣裙」才能去库里找，对吧？所以Query改写本质上是做一道翻译题，目标就是提升召回和相关性。
我一般把主流方法分成三类，但真正落地的时候往往不是单选，而是组合拳。先说同义扩展，这个最简单，成本低、可解释性强，特别适合高并发场景。比如电商搜「大屏手机」，同义词表里提前配好「大屏幕」「大尺寸」，再结合[[BM25]]就能直接召回。但它的缺点也很明显，就是管不了语义，比如用户说「那个红色的」，同义词表就没辙了。所以我会把它当兜底策略，保证延迟可控，再往上叠其他方法。
然后是语义重写，这个就用上模型了。比如用户说「那个红色的」，用LLM或者T5这种模型改写，变成「红色连衣裙」，或者「苹果」这个词，根据上下文判定是手机还是水果。这个方法的优势是能处理口语化和不完整的Query，劣势是延迟高、成本高。所以我不会所有流量都走语义重写，而是只对长尾Query或者对话场景做重写，或者用个小模型先过滤一遍。
再一个就是对话历史融合，这个在[[RAG]]系统里特别重要。用户多轮对话里经常有指代，比如「它多少钱」，得结合前面的「iPhone 15」才能理解。还有意图漂移，用户先问手机，又问充电器，系统得知道话题变了。做法分两种，一种是显式改写，直接生成一个自包含的Query，比如「iPhone 15多少钱」；另一种是隐式编码，把历史拼接到当前Query里，让模型自己学。这里有个坑：显式改写如果模型改错了，会把「小米手机」改成「大米手机」，所以在电商场景里，品牌词必须锁定，不能动。
说到电商，我举个具体例子。在京东或者淘宝，用户搜「大屏手机」，系统不光要召回屏幕大的手机，还得理解「大屏」对应屏幕尺寸大于6.5英寸，这就要对接[[知识图谱]]。而且改写的时候不能把品牌词改了，比如「小米」不能改成「大米」，否则用户就投诉了。还有库存感知，如果改写结果召回的商品都没货，那不如不召，所以上线前我会特别关注改写结果和库存的联动，避免推荐无货商品。
选型上，我的倾向是：高并发搜索用同义扩展加缓存，保证延迟；对话式导购用语义重写加历史融合，提升体验；冷启动或者长尾Query，可以用LLM生成多视角Query，扩充召回。但前提是成本能扛住，否则就是线上崩。
最后我想提一句，其实还有一种思路是用[[Self-RAG]]让模型自己判断改写是否需要，而不是每次都改写，这样能省不少成本。但这个对模型能力要求比较高，如果模型不够强，反而会引入噪声。
所以我会把Query改写看成一套组合拳，先低成本兜底，再针对性地用模型提升，同时时刻关注延迟和成本，不做一刀切。