面经策

RAG 中的查询重写 Query Rewriting 是什么？如何优化检索效果？ ​

  • 标签：RAG、查询重写

🏛 业务架构师 ​

查询重写（Query Rewriting）指在检索前用 LLM 把用户的原始提问改写为"更适合检索的形态"。它优化检索效果的机理与做法：

为什么有效：真实 query 与知识库文档之间存在"表达鸿沟"——用户输入口语化、带指代、缺上下文（"那个政策还能报吗？"），而文档是书面语、完整表述；直接拿原始 query 做向量检索，匹配度天然打折。改写就是在两边架桥。

常见重写形态：

  1. 指代消解与补全：结合多轮历史把代词还原成实体（"它"→"差旅报销政策"）——多轮对话 RAG 的必备；
  2. 口语转书面："咋退货"→"商品退货流程与条件"——对齐文档语言风格；
  3. 查询扩展：一个 query 生成 3~5 个变体并行检索融合——覆盖多种表述角度；
  4. 查询分解：复杂问题拆成子问题分别检索（"对比 A 和 B 的优劣"→分别查 A、B 的特点）；
  5. HyDE：让模型先生成"假设性答案"再用它检索——答案与文档的语义空间比问题与文档更近，专业领域效果显著。

实现：LangChain 的 MultiQueryRetriever、ConversationalRetrievalChain 里的 condense question 环节，或自定义 LCEL 改写链（小模型干这活就够，控制延迟与成本）。

业务取舍：多一次 LLM 调用（+200~500ms、少量成本）——多轮对话场景必须上（不做指代消解检索基本不可用）；单轮精确查询场景按 badcase 决定。优化顺序：先改写（治本）再调 K（治标）。

🏗 系统架构师 ​

查询重写 = 用 LLM 把原始 query 改写成"更适合检索"的形式。优化检索的机理与做法：

为什么要重写（三类失配）：

  • 指代缺失：多轮对话里"那它多少钱"——裸检索必失败，要补全成"iPhone 17 Pro 多少钱"（会话改写）；
  • 口语化与文档语体差：用户说"登不上了"文档写"认证失败处理"——词汇失配拉低召回；
  • 复合问题："对比 A 和 B 的价格与售后"——一次检索混多个意图，拆解后分别检索（子查询分解）效果倍增。

重写策略谱系：

  • 会话改写（指代消解 + 省略补全）——多轮 RAG 必配；
  • 同义/术语规范化（领域词典辅助）；
  • 子查询分解（复合 → 并行子查询 → 结果合并）；
  • HyDE（假设性文档）：让 LLM 先生成"假想答案"，用假答案的向量去检索——答案与文档的语体比问题更近，召回常提升（适合长尾专业查询）；
  • 失败驱动重写：检索置信度低时自动触发第二轮改写（自适应）。

工程权衡（架构师账本）：

  • 延迟成本：重写是一次额外 LLM 调用（小模型 300~500ms）——对延迟敏感场景：用小模型/规则改写、缓存高频改写、或仅多轮对话第一类必做；
  • 质量风险：重写引入语义漂移（改错方向更糟）——重写前后 query 双路检索融合（RRF）是稳妥折中；
  • 度量：改写命中率（改写后召回提升比例）与漂移率（改写改变意图的比例）分开监控——上线不是终点。

💻 全栈开发专家 ​

Query Rewriting（查询重写）：检索前用 LLM 把原始 query 改写成「检索器更友好」的形式。为什么有效：用户口语化、带指代、口语歧义，与文档的书面语存在词表鸿沟；复合问题一次检索召不全。

常用重写策略（按场景选）：

  1. 指代消解 + 补全（多轮对话必做）： 「它多少钱」→「iPhone 17 Pro 的价格是多少」——把历史里的指代解掉再检索；

  2. 口语转书面/关键词化： 「咋退货啊」→「电商订单退货流程 退款政策」；

  3. HyDE（假设文档）：让 LLM 先写一段「假想答案」，用答案向量检索——答案与文档在同一语义空间，召回常优于原 query；

  4. 子问题分解：「对比 A 和 B 的价格和性能」→ 4 个单维度子查询分别检索再融合；

  5. 多查询扩展（Multi-Query）：生成 3~5 个不同表述，RRF 融合结果。

实现骨架：

python
rewrite_prompt = "将用户问题改写为适合检索的独立、具体的查询，直接输出去除指代后的完整问题：\n历史：{history}\n问题：{q}"
rewritten = llm.invoke(rewrite_prompt.format(...)).content
docs = retriever.invoke(rewritten)

优化与坑（实战）：

  • 改写用小模型（延迟成本敏感），temperature 0~0.3 保证稳定；
  • 保留原 query 双路检索（改写可能跑偏，原始+改写 RRF 融合更稳）；
  • 简单事实型 query 别改写（白加延迟）——入口按 query 类型路由；
  • 改写效果用「改写后 recall@10 vs 改写前」评测，别凭感觉。