查询改写与扩展

检索假定查询是一个好的搜索关键词。真实的查询经常不是。

它们太短。它们用代词指代前几轮的内容。它们一次问两件事。它们以问句的形式提出，而文档是陈述句写的——这种不对称造成了无声的漏检。

在检索之前改写查询，能解决一整类再怎么调检索器也够不到的失败。

对话式改写

最重要的一种，也是最常缺失的一种。

用户：怎么配置缓存？
助手：（解释缓存配置）
用户：那超时呢？

把「那超时呢？」拿去算 embedding，检索到的是泛泛讲超时的文档。缓存那层上下文——让这个问题可回答的那个东西——完全不在查询里。

解法是结合对话历史，把查询改写成一句自足的问题：What is the timeout setting for the cache?

任何多轮 RAG 系统都需要这一步。不做的话，每一个追问的检索都很糟，而且症状看起来像检索质量问题，而不是查询问题。

多查询扩展

对同一个问题生成几种不同说法，各检索一遍，再合并结果。

How do I speed up my queries? 变成：

• query performance optimization
• slow database queries troubleshooting
• indexing for faster reads

不同的说法会落在 embedding 空间的不同区域，合起来覆盖的范围比任何单独一句都大。用倒数排名融合合并，然后去重。

代价是多一次便宜的模型调用，加上几次检索。通常划算。

拆解

复合问题检索效果差，因为没有任何一份文档能回答它们。

How does our pricing compare to competitors and what did we change last quarter? 是两个问题。合在一起算 embedding，向量会落在两个话题中间，两边都匹配不好。

拆开，分别检索，再合并上下文。这也是通往 Agentic RAG 的入口——在那里，由模型自己决定怎么拆。

假设性文档 embedding

一个反直觉但很好用的技术。

不把问题拿去算 embedding，而是让模型写一个假设性的答案，再对这个答案算 embedding。生成的答案可能有事实错误——没关系，因为它只是被当作搜索关键词用。

它有用的原因是：假设性答案的措辞像文档，所以在 embedding 空间里会比一个问句更靠近真实文档。它正面攻击了「问句 vs 陈述句」这个不对称。

代价是检索之前多跑一次生成，而那个答案完全不需要准确。

退一步提问

对又窄又具体的问题，额外用一个更笼统的版本来检索。

Does the v2.3 API support batch uploads? 同时用 API upload capabilities 再检索一遍。具体的版本可能没被单独写进文档，而笼统的能力有。

文档是按概念组织、而不是按版本或变体组织时，这一招很有用。

抽取过滤条件

查询里经常用自然语言夹带着元数据约束。

What did the Q3 report say about margins? 隐含了一个日期过滤和一个文档类型过滤。把它们抽成结构化的元数据过滤条件，只在过滤后的集合里检索，比指望语义相似度能抓住「Q3」可靠得多。

任何数值或时间相关的东西都适用，而向量检索处理这些东西很差。

代价

每一种改写都会在检索还没开始之前就增加延迟和 token。有的还要多跑一整次生成。

按单位成本的收益排序：

1. 对话式改写——多轮场景必需，便宜，解决一大类失败
2. 过滤条件抽取——便宜，而且向量检索根本做不到
3. 多查询扩展——召回提升明显，成本中等
4. HyDE 与拆解——看情况用，各需一次生成

改写用一个又小又快的模型。这正是模型路由的典型场景：便宜的模型负责改写，贵的模型负责回答。

怎么衡量

改写很容易加，却很难靠感觉判断好坏。真正要看的指标没有变：对一批已知答案的真实问题，正确的文本块被检索到了吗？

每种改写都做开/关两组。有些在你的语料上有效，有些没有，而直觉在这件事上很不靠谱。

要点回顾

• 真实查询短、没有上下文、复合，措辞也不像文档——改写解决的是再调检索器也够不到的失败。
• 对话式改写：把追问改写成自足的问题，多轮系统必须做。
• 多查询扩展覆盖更多 embedding 空间；HyDE 通过给假设性答案算 embedding，修正「问句 vs 陈述句」的不对称。
• 从自然语言里抽出元数据过滤条件，因为向量检索处理不了日期和数字。
• 改动用便宜模型，并测量开关前后的检索命中率。

下一篇： 上下文检索