面经策

什么查询扩展？为什么在 RAG 应用中需要查询扩展？ ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

查询扩展（Query Expansion）是在用户原始提问送去检索之前，用 LLM 或规则把它改写、扩充成多个更利于召回的变体，例如"Q3 销量咋样"扩展为"2026 年第三季度销售额、销售量统计报告"。

为什么需要：真实用户的提问是"口语化、缺上下文、带代词"的——"那个政策还能报吗？"检索引擎根本无从下手。而企业知识库的文档标题是书面语，两边存在语义鸿沟。查询扩展本质是在"人怎么问"和"文档怎么写"之间架桥，同时多个变体并行检索再融合，能显著提高召回覆盖率，尤其对短 query、行话缩写、跨语言提问效果明显。

业务取舍：它多一次 LLM 调用，增加 200~500ms 延迟和少量成本。我的落地经验：知识库问答这类准确率优先的场景值得上；且扩展要控制在 3~5 个变体，避免延迟翻倍。反过来说，如果日志显示用户提问本身已经很规范（如内部运维平台），就不必急着上，先看召回 badcase 再决定——优化永远跟着 badcase 走，而不是跟着技术清单走。

🏗 系统架构师 ​

查询扩展（Query Expansion）是在检索前把用户的原始 query 改写、扩充成多个语义变体，多路召回后合并，解决"用户表达与文档用语不匹配"的检索断层。

为什么需要：用户 query 通常短、口语化、有指代（"它怎么收费"），而文档用语规范、书面。Embedding 缩短了这个鸿沟但没有消除——尤其是同义术语（"登出/注销/log out"）和缩写场景。单条 query 是单点，扩展成多条 query 就是空间换召回率。

常见做法：

  • LLM 生成 3~5 个同义改写（成本约几百 token，延迟 500ms~1s，可用小模型做）；
  • 领域同义词表 + 缩写展开（规则层，零延迟）；
  • 结合对话历史补全指代（改写与扩展经常一起做）；
  • 多路结果用 RRF 融合去重。

权衡：扩展增加检索延迟（LLM 改写可以和后续检索流水线并行部分掩盖）、增加向量库 QPS 压力（1 query 变 5 query），以及可能引入语义漂移。我的实践：先确认"query 与文档词汇失配"确实是瓶颈（对比检索命中日志），再上扩展；延迟敏感场景用规则同义词表先行，LLM 改写做异步缓存。

💻 全栈开发专家 ​

查询扩展是检索前的 query 改写增强：用 LLM 把原始 query 变成多个视角的查询再检索融合。为什么需要？因为用户 query 和文档用词天然不一致（vocabulary mismatch），而且复合问题一次检索召不全。

常用三种：

  • Multi-Query 多查询：让 LLM 生成 3~5 个不同表述，各自检索后 RRF 融合。
  • 子问题分解：「对比 A 和 B 的优劣」拆成「A 的优势」「B 的优势」分别检索。
  • HyDE：让 LLM 先假想一份答案，用答案的向量去检索（答案和文档的语义空间更近）。
python
from langchain.retrievers.multi_query import MultiQueryRetriever
retriever = MultiQueryRetriever.from_retriever(
    base_retriever=vs.as_retriever(), llm=llm)  # 自动生成多查询并融合

我踩过的坑：一是扩展会放大延迟（多次 LLM 调用），生产上我们把扩展 query 做成异步预生成或用小模型；二是扩展偏了反而引入噪声，必须配合 rerank 兜底；三是简单事实型 query（查订单号）不要扩展，白花钱——所以入口先做意图分类，只对语义模糊型 query 走扩展。这套组合拳上线后，多跳问题的回答完整率提升了约 20%。