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