查询改写与 HyDE

状态：✅ 已补齐（2026-09-12）
一句话定义：用户原话往往不适合直接检索；通过改写、扩写、多查询或 HyDE（先假想答案再嵌入）提升召回。

大纲

1. 为什么原话不能直接检索
2. 改写四型与路由
3. HyDE：假想答案再嵌入
4. 多查询与融合
5. 端到端落地示例：四周迭代

已有相关文档（先读这些）

• Chunking 策略 · 本系列
• Embedding 选型 · 本系列
• RAG
• Memory-Recall
• RAG 核心概念

学习要点（读后应能回答）

• 短查询与长会话追问各用什么改写？→ 见 2.3 路由表
• HyDE 何时会引入更大噪声？→ 见 3.3

一、为什么原话不能直接检索

改写的前提是：文档块的语言形态与用户提问的语言形态存在系统性错配。嵌入模型把两者映射到同一空间，但「问法」与「写法」的向量天然不靠近。小北日志里的三类典型错配：

三类病占小北检索 bad case 的 41%——切分与选型做完（hit@5 = 86.2%）之后的剩余误差，大头在查询侧，这正是本章的地盘。

1.1 改写的位置

改写发生在检索之前、理解之后：

flowchart LR
    Q[用户原话] --> H{有无历史会话}
    H -->|有| RC[指代消解<br/>并入历史]
    H -->|无| R{路由判定}
    RC --> R
    R -->|简单| V[直接嵌入检索]
    R -->|需改写| RW[纠错 / 扩写 / 子查询]
    R -->|问法差异大| HY[HyDE]
    RW --> V
    HY --> V

二、改写四型与路由

2.1 四种改写类型

落地示例：多轮指代消解（Node.js + TS，OpenAI 协议）：

import OpenAI from "openai";

const client = new OpenAI();

interface Turn { role: "user" | "assistant"; content: string; }

// 只取最近 3 轮，压缩成本；温度 0 保证改写稳定
export async function resolveCoreference(
  history: Turn[], query: string,
): Promise<string> {
  const resp = await client.chat.completions.create({
    model: "gpt-4o-mini",
    temperature: 0,
    messages: [
      {
        role: "system",
        content:
          "把用户最新发言改写成一个不依赖上下文、可独立检索的完整问题。" +
          "保留原意，补全指代与省略，只输出改写后的问题。若本就完整，原样输出。",
      },
      ...history.slice(-6),
      { role: "user", content: query },
    ],
  });
  return resp.choices[0].message.content ?? query;
}
// 「那北京呢？」+ 前轮「报销标准是什么」
//   → 「北京地区的差旅住宿报销标准是多少」

2.2 子查询拆分

复合问题是召回黑洞：拆开后每个子问题独立检索、结果合并（合并算法见 四）。

落地示例：结构化子查询输出（Node.js + TS）：

export interface SubQuery { text: string; }

export async function decompose(query: string): Promise<SubQuery[]> {
  const resp = await client.chat.completions.create({
    model: "gpt-4o-mini",
    temperature: 0,
    response_format: { type: "json_object" }, // 强制 JSON，便于解析
    messages: [
      {
        role: "system",
        content:
          '把问题拆成 1~3 个可独立检索的子问题，输出 JSON：' +
          '{"sub_queries": [{"text": "..."}]}。简单问题不必拆。',
      },
      { role: "user", content: query },
    ],
  });
  const parsed = JSON.parse(resp.choices[0].message.content ?? "{}");
  return parsed.sub_queries?.length ? parsed.sub_queries : [{ text: query }];
}

2.3 路由表：什么查询做什么

改写全是 LLM 调用——每次 +300~800ms 延迟与成本。不是每个查询都值得改写，路由规则按查询特征分级：

路由的意义：小北线上 63% 的查询走直通，改写成本只花在 37% 的查询上。

三、HyDE：假想答案再嵌入

HyDE /ˈhaɪd/ （Hypothetical Document Embeddings，假设性文档嵌入）的思路反直觉：检索前先让 LLM 凭空写一个假答案，用假答案的向量去检索——因为「假答案」与库里「真答案」同为文档形态，向量距离远比「问题 ↔ 答案」近。

3.1 原理与流程

flowchart LR
    Q[用户问题] --> G[LLM 生成假设性答案<br/>不含真实知识，只求形态像]
    G --> E[嵌入假答案]
    E --> S[用该向量检索知识库]
    S --> R[真文档块召回]

关键认知：假答案的内容对不对不重要，形态像才重要。它只是把「问句」翻译成「文档腔」的桥梁，检索命中的仍是库里的真文档。

3.2 落地示例

export async function hydeSearch(
  query: string, search: (q: string) => Promise<{ chunkId: string }[]>,
): Promise<{ chunkId: string }[]> {
  const resp = await client.chat.completions.create({
    model: "gpt-4o-mini",
    temperature: 0.7, // 略高温度换形态多样性，内容不需正确
    messages: [
      {
        role: "system",
        content:
          "写一段 100 字以内的文档片段，直接回答下面的问题。" +
          "写成公司制度/技术文档的口吻，不要任何开场白。",
      },
      { role: "user", content: query },
    ],
  });
  const hypothetical = resp.choices[0].message.content ?? query;
  return search(hypothetical); // 用假答案的向量检索真文档
}

小北实测：问法与写法差异最大的场景（口语化的制度咨询），HyDE 让 hit@5 从 83% 升到 89%；但对代码库查询是灾难（见 3.3）。

3.3 HyDE 的失效边界

这是文首第二个学习问题。HyDE 在三种情况下引入的噪声大于收益：

1. 专名 / 符号精确匹配场景：查 calcRefund 函数，假答案会生成一个名字对不上的伪函数——嵌入后反而把语义相近但符号不同的块拉进 top-k，符号查询靠关键词精确命中（见 04 篇 混合检索），HyDE 属于帮倒忙；
2. 知识库不覆盖的问题：假答案写得头头是道，库里根本没有对应文档，召回的全是「语义擦边」的块，且假答案的自信口吻还会污染生成端，诱导模型编造；
3. 事实密集型短问题：「年假几天」这类 5 个字就能问清的事，假答案 100 字里 95 字是编造细节，嵌入向量被这些细节带偏。

判定口诀：HyDE 救「问法不像写法」，毁「答案靠精确词」。上 HyDE 前先看 bad case 归因：错配型占比高才值得开。

四、多查询与融合

子查询 / 扩写 / HyDE 各产出一路查询，各检索一次，得到多份排序列表——融合把它们合成一份。小北用最简单的 RRF（Reciprocal Rank Fusion 的默认特例，详见 04 篇）：

落地示例：多路结果融合去重（Node.js + TS）：

export function mergeMultiQuery(
  lists: { chunkId: string }[][], maxResults = 10,
): { chunkId: string }[] {
  const score = new Map<string, number>();
  for (const list of lists) {
    for (let i = 0; i < list.length; i++) {
      const id = list[i].chunkId;
      score.set(id, (score.get(id) ?? 0) + 1 / (60 + i)); // 简易 RRF：k=60
    }
  }
  return [...score.entries()]
    .sort((a, b) => b[1] - a[1])
    .slice(0, maxResults)
    .map(([chunkId]) => ({ chunkId }));
}

融合的隐含收益：同一块被多路同时命中会累积分数——「扩写查询」和「HyDE 查询」都指向它时，它几乎必然是正确答案。小北数据：双路同时命中的块，最终被引用率 91%，单路命中仅 62%。

五、端到端落地示例：四周迭代

把「小北」的查询侧改造排进四周（衔接 02 篇 之后的 86.2% 基线）：

工具速查：

自检清单

• 有查询错配归因数据，改写策略由数据驱动而非全量开启；
• 路由先行：直通查询不走改写，延迟与成本可控；
• 多轮会话必做指代消解，改写模型与温度固定可复现；
• HyDE 只用于问法-写法错配场景，符号/专名查询已明确禁用；
• 多路结果有统一融合与去重，多路命中加权可观测。

本文缩写

参考资料

• Precise Zero-Shot Dense Retrieval without Relevance Labels (HyDE)（Gao 等，2022）
• Query Transformations · LlamaIndex 文档
• RAG-Fusion（Raudaschl，2024，多查询融合）
• Memory-Recall · 本仓库