Query 改写有哪些创新方法?

这道题其实是在问，怎么把用户说的那句人话，翻译成检索系统能听懂的语言。用户说「那个红色的」，系统得知道「红色连衣裙」才能去库里找，对吧？所以Query改写本质上是做一道翻译题，目标就是提升召回和相关性。

我一般把主流方法分成三类，但真正落地的时候往往不是单选，而是组合拳。先说同义扩展，这个最简单，成本低、可解释性强，特别适合高并发场景。比如电商搜「大屏手机」，同义词表里提前配好「大屏幕」「大尺寸」，再结合[[BM25]]就能直接召回。但它的缺点也很明显，就是管不了语义，比如用户说「那个红色的」，同义词表就没辙了。所以我会把它当兜底策略，保证延迟可控，再往上叠其他方法。

然后是语义重写，这个就用上模型了。比如用户说「那个红色的」，用LLM或者T5这种模型改写，变成「红色连衣裙」，或者「苹果」这个词，根据上下文判定是手机还是水果。这个方法的优势是能处理口语化和不完整的Query，劣势是延迟高、成本高。所以我不会所有流量都走语义重写，而是只对长尾Query或者对话场景做重写，或者用个小模型先过滤一遍。

再一个就是对话历史融合，这个在[[RAG]]系统里特别重要。用户多轮对话里经常有指代，比如「它多少钱」，得结合前面的「iPhone 15」才能理解。还有意图漂移，用户先问手机，又问充电器，系统得知道话题变了。做法分两种，一种是显式改写，直接生成一个自包含的Query，比如「iPhone 15多少钱」；另一种是隐式编码，把历史拼接到当前Query里，让模型自己学。这里有个坑：显式改写如果模型改错了，会把「小米手机」改成「大米手机」，所以在电商场景里，品牌词必须锁定，不能动。

说到电商，我举个具体例子。在京东或者淘宝，用户搜「大屏手机」，系统不光要召回屏幕大的手机，还得理解「大屏」对应屏幕尺寸大于6.5英寸，这就要对接[[知识图谱]]。而且改写的时候不能把品牌词改了，比如「小米」不能改成「大米」，否则用户就投诉了。还有库存感知，如果改写结果召回的商品都没货，那不如不召，所以上线前我会特别关注改写结果和库存的联动，避免推荐无货商品。

选型上，我的倾向是：高并发搜索用同义扩展加缓存，保证延迟；对话式导购用语义重写加历史融合，提升体验；冷启动或者长尾Query，可以用LLM生成多视角Query，扩充召回。但前提是成本能扛住，否则就是线上崩。

最后我想提一句，其实还有一种思路是用[[Self-RAG]]让模型自己判断改写是否需要，而不是每次都改写，这样能省不少成本。但这个对模型能力要求比较高，如果模型不够强，反而会引入噪声。