What are the pros and cons of query transformation techniques
1️⃣ 考察意图
面试官想考察的不是你能否背诵“查询重写、分解、扩展”这几个名词，而是你是否理解每种变换技术背后的工程取舍：为什么用、什么时候用、代价是什么。这是典型的系统设计 + 工程取舍类问题，刁钻点在于：候选人往往只讲优点，忽略延迟、噪声、LLM 依赖等实际落地问题。答好了能展示你对 RAG 整条链路（检索→生成）的端到端理解，以及根据场景做技术选型的决策能力。
2️⃣ 标准答
查询变换（Query Transformation）是 RAG 系统中提升检索召回率的关键手段，但每种技术都有明确的 trade-off。下面从四种主流技术展开，重点讲原理、收益、代价、落地坑。
- **查询重写（Query Rewriting）**原理：用 LLM 将用户原始查询改写为更清晰、更符合检索系统偏好的形式。例如“苹果的股价” → “Apple Inc. 当前股票价格”。优点：消除歧义、补全缺失实体，明显提升 Recall@k（实测可提升 10-20%）。代价：每次改写需 1 次 LLM 调用，增加 200-500ms 延迟（取决于模型大小）。落地坑：改写可能过度泛化，如“Python 的用途”被改写为“编程语言 Python 的应用场景”，丢失了用户可能隐含的“爬虫”意图。解法：对改写结果做置信度过滤，或保留原始查询作为 fallback。
- **查询分解（Query Decomposition）**原理：将复杂多跳问题拆成多个子查询，分别检索后合并结果。例如“2023 年诺贝尔物理学奖得主毕业于哪所大学？” → 子查询 1：“2023 年诺贝尔物理学奖得主是谁”，子查询 2：“[得主姓名] 的毕业院校”。优点：覆盖多角度，解决单次检索无法命中的问题，对多跳 QA 场景 Recall@k 可提升 30%+。代价：子查询数量增加导致检索次数线性增长（2-5 次），延迟翻倍；合并结果时需去重和排序。落地坑：子查询之间可能产生冗余或冲突，例如“苹果”和“水果”同时检索导致结果混杂。解法：对子查询结果做交叉编码器 rerank（如 Cohere rerank v3），或使用 ColBERT 的后期交互（late interaction）直接打分。
- **查询扩展（Query Expansion）**原理：用同义词、相关词或 LLM 生成的伪相关反馈（Pseudo-Relevance Feedback）扩充查询。例如“机器学习” → “机器学习 深度学习 神经网络 监督学习”。优点：缓解词汇不匹配（vocabulary mismatch），对稀疏检索（BM25）效果显著，Recall@100 可提升 15-25%。代价：扩展词可能引入噪声，降低精确率（Precision）。例如“苹果”扩展出“水果”后，检索结果混入大量无关文档。落地坑：扩展词数量需要调参——太少无效，太多噪声。经验值：BM25 默认 k1=1.5, b=0.75 时，扩展 3-5 个词效果最优；稠密检索（DPR）对扩展更敏感，建议用 LLM 生成而非静态同义词表。
- **假设文档嵌入（HyDE）**原理：先用 LLM 根据查询生成一个“假设文档”（即理想答案的草稿），再用该文档的 embedding 去检索。优点：将查询和文档映射到同一语义空间，缓解 embedding 模型对短查询的偏差。在零样本场景下 Recall@20 可提升 10-15%。代价：依赖 LLM 生成质量，若生成内容偏离真实答案，检索结果完全跑偏；且每次检索需 2 次 LLM 调用（生成 + 改写）。落地坑：生成假设文档时，LLM 可能“编造”事实，导致检索结果偏向虚构内容。解法：对假设文档做长度截断（如 50-100 tokens），避免过度生成；或结合 query-side 的 embedding 做加权融合。
工程取舍总结：
- 实时系统（如客服对话）：优先用查询重写（单次 LLM 调用，延迟可控），避免分解和 HyDE。
- 离线批量处理（如知识库索引）：可用查询分解 + 扩展，牺牲延迟换召回率。
- 评估指标：必须同时监控 Recall@k 和 P99 延迟，不能只看召回率。例如，查询重写让 Recall@5 从 0.6 升到 0.7，但 P99 延迟从 200ms 升到 800ms，对用户体验可能是灾难。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从四种主流查询变换技术来回答：查询重写、分解、扩展和 HyDE。每种技术都有明确的收益和代价：重写提升相关性但增加延迟，分解覆盖多跳但导致检索次数线性增长，扩展缓解词汇不匹配但可能引入噪声，HyDE 缓解短查询偏差但依赖 LLM 生成质量。总结一句：没有银弹，需要根据场景的延迟预算和召回率目标做技术选型，并配合评估指标（Recall@k + P99 延迟）量化 trade-off。”
4️⃣ 高频追问 & 应对
追问 1：你在实际项目中如何选择用哪种变换技术？
应对策略：给出决策树。先看延迟预算：如果 P99 延迟 < 500ms，只用查询重写（单次 LLM 调用）；如果 > 1s，可加查询分解。再看检索类型：稀疏检索（BM25）优先用查询扩展，稠密检索（DPR）优先用 HyDE。最后看场景：多跳 QA 必用分解，单轮问答用重写即可。举例：在电商客服场景，我们只用重写 + 扩展，因为用户查询短且意图明确，分解反而增加延迟和噪声。
追问 2：如果 LLM 改写质量很差，你怎么兜底？
应对策略：两个兜底策略。第一，保留原始查询作为 fallback，将改写后的查询和原始查询分别检索，结果做加权融合（如 0.7 改写 + 0.3 原始）。第二，对改写结果做置信度打分：用一个小模型（如 BERT 分类器）判断改写是否偏离原意，低于阈值则丢弃改写结果。实测中，这种兜底能将改写带来的噪声降低 30-50%，同时保持召回率提升。
追问 3：查询分解后，子查询结果如何合并？
应对策略：两种主流方法。方法一：直接拼接所有子查询的检索结果，去重后按相关性分数排序（适合 BM25 等分数可比的检索器）。方法二：用交叉编码器 rerank，将子查询和候选文档对输入 BERT 模型打分，但延迟高（每对 10-50ms）。工程上常用折中方案：先用方法一快速召回 Top-100，再用方法二对 Top-20 做 rerank。注意：子查询之间可能有重叠，去重时需用文档 ID 或 SimHash 做近似去重。
5️⃣ 避坑 · 常见错误答法
- ❌ 只讲优点，不提代价：“查询分解能提升召回率，非常好用。”→ ✅ 必须同时给出 trade-off：“查询分解能提升多跳场景的 Recall@k 30%+，但代价是检索次数线性增长，延迟翻倍，且子查询结果合并需要额外 rerank。”
- ❌ 混淆技术适用场景：“HyDE 适用于所有场景，因为它能缓解词汇不匹配。”→ ✅ 明确边界：“HyDE 对短查询有效，但依赖 LLM 生成质量，在事实性要求高的场景（如医疗、金融）风险大，因为 LLM 可能编造假设文档。”
- ❌ 忽略评估指标：“用了查询重写后，效果变好了。”→ ✅ 必须量化：“查询重写让 Recall@5 从 0.6 升到 0.7，但 P99 延迟从 200ms 升到 800ms，需要根据业务容忍度决定是否上线。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在项目中实现了查询重写和分解，对比了 Recall@5 和 P99 延迟，发现重写对单轮问答提升 15%，但分解在多跳场景提升 30% 且延迟可控”切入，展示你做过量化评估。
- 如果你只做过传统 NLP：用“查询变换类似于传统信息检索中的查询扩展（如 Rocchio 算法），但 LLM 让重写和分解更灵活，代价是延迟和噪声”类比迁移，体现你对新旧技术的理解。
- 如果你是校招无项目：聚焦“我复现了 HyDE 论文，在 NQ 数据集上发现 Recall@20 提升 12%，但生成假设文档时 LLM 编造事实导致 5% 的检索偏差，我通过截断和加权融合缓解了这个问题”，展示论文复现和问题解决能力。
- 论文：Query Rewriting for Retrieval-Augmented Large Language Models (2023)
- 论文：HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels (2022)
- 论文：Query Expansion by Prompting Large Language Models (2023)
- 工具：LangChain 的 QueryTransformer 模块（支持重写、分解、扩展）
- 博客：RAG 中的查询变换：从理论到工程实践（知乎/Medium 搜索）