怎么考「用户 query 很口语很含糊，怎么做查询改写？HyDE 的思路是什么？」
谁在问：二面；做过多轮对话产品的面试官必问
开场怎么问
用户问得很随意，甚至带指代，你们怎么处理？
换个问法
- 多轮对话的时候第二轮往后检索质量会下降吗？怎么解决的？
- 听说过 HyDE 吗？为什么用一段假答案去检索反而更准？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
改写用什么模型？每次都调大模型不贵吗？
- 期望
- 改写是简单任务，用小模型/快模型即可，不必用主模型；可以按需触发（检测到指代词、代词、省略句式才改写）；也可以把改写和意图分类合并成一次调用，省一趟往返。
- 信号
- 说「就用主模型改」而完全不考虑成本的，没做过成本治理。
改写会不会把关键信息改丢？
- 期望
- 会，且是高频坑——专有名词、型号、编号最容易被改写成泛称（「SK-3200」→「该型号设备」），改完就检索不到了。解法是在改写 prompt 里明确要求保留原文中的专有名词/型号/编号；并且保留原 query 一起检索（原始 + 改写双路，用 RRF 融合），防止改写失手导致全盘失败。
- 信号
- 能主动想到「原 query 也要保留」这个兜底的，是踩过坑的。
HyDE 什么时候不该用？
- 期望
- 模型对该领域一无所知时，编出的假答案方向可能完全错误，反而把检索带偏（比如内部业务概念、公司特有流程）；成本敏感或延迟敏感场景不划算；简单事实型查询收益很小。它属于「知道原理很加分，但不必默认开启」的技术。
- 信号
- 把 HyDE 当万能提升、说不出任何反例的，是背来的。
查询扩展生成的几个变体，怎么保证它们不是互相重复？
- 期望
- prompt 里明确要求「从不同角度改写」并给出角度维度（换同义词 / 换提问视角 / 拆成子问题）；生成后可用向量相似度去重，太像的丢掉；否则等于花三倍成本做一次检索。
- 信号
- 意识到「变体太像等于白花钱」的，是实际跑过的。
加了改写和扩展后首字延迟到了 3 秒，产品要求 1.5 秒内，怎么砍？
- 期望
- 按收益成本比排序砍——先砍多路扩展（成本最高收益最不确定），保留改写（多轮场景收益最确定）；改写换小模型或规则前置触发；HyDE 直接下掉；rerank 减候选数或换轻量模型；用流式输出把首字提前，掩盖部分感知延迟；最后做分级策略（简单 query 走轻管线）。要能给出每一刀损失多少精度的量化对比。
- 信号
- 能说出「先砍哪个、为什么」的优先级判断，比列出一堆手段更重要。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 能按症状分类给出对应手段（改写/扩展/HyDE/路由）
- 明确指出多轮场景下改写几乎是必需的
- 能解释 HyDE 的机制并说出「问题与答案在向量空间不相似」这个根因
- 知道每项技术都增加延迟和成本
- 加分：改写要保留专有名词，并保留原 query 双路兜底
- 加分：能说出 HyDE 的失效场景
- 加分：有分级管线（简单 query 走轻路径）的意识
参考答案与考察意图面试中途别看这一段
考察意图
两个观察点：① 有没有做过多轮对话产品——多轮指代是绕不过的坎，做过的人一定会主动提查询改写；② 能不能讲透 HyDE 的反直觉逻辑——这题背答案很容易露馅，因为「为什么假答案更好用」必须触及「问题和答案在向量空间本来就不相似」这个根因。
参考答案
60 分答案（及格线）
主要靠三类手段。查询改写：用 LLM 把用户的口语化、带指代的问法改成自包含的书面检索 query，比如结合对话历史把「那它多少钱」改成「Pro 版的价格是多少」。查询扩展：一个问题生成多个不同角度的变体分别检索，再用 RRF 合并，多撒几张网提高召回。HyDE：先让 LLM 凭空生成一段「看起来像答案」的假文本，用这段假答案去检索，而不是用问题去检索。
90 分答案（有生产经验的回答）
补三层：
先把问题分类，再对应手段（这个框架本身就显专业）：
| 症状 | 根因 | 手段 |
|---|---|---|
| 多轮第二问开始变差 | 指代、省略 | 查询改写 |
| 单轮但表述对不上 | 用户口语 vs 文档书面语 | 查询扩展 / HyDE |
| 问了知识库里没有的东西 | 数据源不对 | 路由（见 Q2-14） |
讲透 HyDE 的根因：问题和答案在向量空间里本来就不相似。「保修期多久？」和「本产品自购买之日起提供 24 个月质保……」——一个疑问句一个陈述句，句式、词汇分布都不同。而 LLM 编的假答案，句式和词汇分布跟真答案高度接近，用它去匹配真文档，等于让「答案找答案」，天然更近。编的内容是错的没关系——我们要的不是它的事实，是它的表述形态。
给出成本纪律：这些技术每一个都增加一次 LLM 调用。正确做法是按 badcase 类型决定上哪一项，而不是一次性全开。一个「改写 + 三路扩展 + rerank」的重型管线首字延迟很容易多出 1–2 秒。优化手段：用小模型专门做改写；只在检测到指代词时才触发改写；对高频简单 query 走轻管线。