面试题 14：如何利用大模型对用户的原始提问进行改写、拆解或扩展？
2026/6/23大约 4 分钟面试题面试题
一、 痛点分析：为什么需要 Query Transformation？
在 RAG（检索增强生成）系统中，检索的质量直接决定了最终回答的质量。然而，用户的原始输入往往是“劣质”的，直接用于向量检索会导致召回率极低。常见问题包括：
- 指代不明：在多轮对话中，用户常说“那它呢？”、“这个怎么用？”，向量库无法理解代词。
- 语义稀疏：用户只输入一两个关键词（如“报销”），导致向量匹配时缺乏足够的上下文特征。
- 逻辑复杂：用户提出包含对比、多步推理的问题（如“北京和上海谁的常住人口多？”），文档中通常不存在直接对比的句子。
为了解决这些问题，我们需要在检索前，引入一个 LLM 专门对 Query 进行“整形”，这被称为 Query Transformation（提问转换）。
二、 三大核心转换策略
1. 问题重写 (Query Rewrite / Coreference Resolution)
- 解决场景：多轮对话中的指代不明、错别字、口语化表达。
- 实现原理：将“历史对话记录（Chat History）”和“用户当前提问”一起发给 LLM，要求 LLM 生成一个独立、完整、脱离上下文也能看懂的问题。
- Prompt 示例：
给定以下聊天历史和用户的最新提问，请将最新提问重写为一个独立的问题。
历史：User: 苹果15多少钱？ AI: 5999元。
最新提问：那它有什么缺点？
重写后：苹果15有什么缺点？
2. 问题扩展 (Query Expansion / HyDE)
- 解决场景：用户提问过于简短，与长篇专业文档的向量空间距离较远（不对称）。
- 实现原理 (HyDE - Hypothetical Document Embeddings)： 让 LLM 不基于任何外部知识，直接对用户的问题“凭空捏造”一个答案（假设性文档）。虽然这个答案可能包含事实错误（幻觉），但它的词汇分布、句式结构与真实的业务文档高度相似。然后，将这个“假答案”进行向量化，去数据库中检索“真文档”。
- 效果：这是一种“用文档搜文档”的降维打击，能极大提升语义召回率。
3. 问题拆解 (Sub-queries / Query Decomposition)
- 解决场景：多跳推理（Multi-hop reasoning）和对比类问题。
- 实现原理：引导 LLM 将一个复杂的大问题，拆解成多个可以独立检索的小问题。
- 执行流程：
- 用户问：“2023年比亚迪销量比特斯拉高多少？”
- LLM 拆解为：Q1="2023年比亚迪销量"，Q2="2023年特斯拉销量"。
- 系统并发执行两次检索，分别召回比亚迪和特斯拉的文档。
- 将所有文档合并后，喂给最终的 LLM 进行对比计算。
三、 面试高分答题话术（💡 划重点）
- 展现系统架构思维：“在成熟的 RAG 架构中，用户的 Query 绝对不能直接打到向量数据库上。我们在中间一定会加一层 Routing（路由） 或 Transformation（转换） 层，拦截并优化劣质提问。”
- 强调 HyDE 的精妙之处：“面试官，我特别想提一下 HyDE 算法。它巧妙地利用了 LLM 的‘幻觉’特性。我们不怕它瞎编，因为我们只用它瞎编出来的‘语义特征’去空间里寻址，这是解决短文本搜长文本最有效的方法。”
- 主动探讨工程代价（Trade-off）：“当然，Query Transformation 最大的代价是延迟（Latency）。因为它在检索前串行增加了一次 LLM API 调用。为了解决这个问题，我们在工程上通常会部署一个本地的、专门微调过的极小模型（如 7B/8B 级别）专门来做重写和拆解，能在 200 毫秒内完成，从而兼顾了准确率和用户体验。”