RAG 查询重写四种策略：让检索精准命中

2026-06-11RAG查询重写HyDE检索优化

为什么需要查询重写

用户输入的查询往往是简短、口语化的，与知识库中文档的语言风格差距巨大。例如用户问"怎么让 AI 不瞎编？"，但知识库文档中写的是"大语言模型的幻觉问题及缓解策略"。直接拿用户原话做向量检索，相似度很低，结果质量也差。

查询重写就是在检索前，把用户的口语化问题转换成更适合检索的形式。

四种策略全景

策略方法额外 LLM 调用适用场景
HyDE先让 LLM 生成假设答案，用假设答案做向量检索1 次短查询、模糊查询、需要语义扩展
Multi-Query生成 3-5 个不同角度的变体查询，合并去重结果1 次提高召回覆盖率、探索性搜索
Step-Back将具体问题抽象为更通用的高层问题1 次需要背景知识的复杂问题
Query Decomposition拆解为多个子问题，逐一检索后融合1-N 次多跳推理、复合问题

HyDE（Hypothetical Document Embeddings）

核心洞察：假设答案和真实文档的语言风格更接近，用假设答案做向量检索，能跨越"用户问法"和"文档写法"之间的鸿沟。

# HyDE 流程
用户问："怎么提升 RAG 检索精度？"
    ↓
LLM 生成假设答案（不用真实数据，只是假设）：
  "提升 RAG 检索精度可以从文档处理优化、检索策略改进和结果重排序
   三个维度入手。首先采用语义分块替代固定长度切分，
   然后使用混合检索（BM25 + 向量检索）并通过 RRF 算法融合结果，
   最后用 Cross-Encoder 对召回结果重新排序..."
    ↓
用假设答案做 Embedding → 向量检索
    ↓
检索结果与用户原始问题的"语义距离"被大幅缩短

使用建议：HyDE 增加 1 次 LLM 调用（约 1-2s 延迟），适合检索精度要求高、用户容忍 2-3s 延迟的场景。简单问题直接用原问题检索即可。

Multi-Query（多角度查询变体）

同一个问题从不同角度提问，可能匹配到不同的文档片段，合并后提高召回覆盖率：

用户问："Agent 的记忆系统怎么设计？"
    ↓
LLM 生成 4 个变体：
  1. "Agent 记忆系统的三层架构是什么？"
  2. "如何在 Agent 中实现长期记忆和短期记忆？"
  3. "Agent 会话状态管理的最佳实践"
  4. "LLM Agent 的记忆窗口优化方案"
    ↓
4 个查询分别检索 → 合并 → MMR 去重 → 返回唯一结果

关键参数：变体数量 3-5 个最佳。太少达不到覆盖效果，太多检索结果重复严重且增加延迟。

Step-Back（抽象回溯）

当用户问了一个很具体但需要背景知识的问题时，先把问题抽象化，检索高层知识，再结合具体问题回答：

用户问："为什么我的 Pinecone 索引在 10 万向量后查询变慢了？"
    ↓
Step-Back："向量数据库的索引性能优化原理是什么？"
    ↓
先检索高层原理（HNSW 图结构、ef_search 参数等）
再结合用户具体问题（Pinecone、10万向量、p1 pod）
    ↓
给出有针对性的答案

Query Decomposition（问题拆解）

复杂问题拆成子问题逐个检索，最后汇总回答——这本质上是把"一步到位"变成"多跳推理"：

用户问："OpenAI 最新嵌入模型和 Cohere 的相比，哪个适合我的中文法律文档？"
    ↓
拆解为：
  1. "OpenAI 最新嵌入模型是什么？性能指标如何？"
  2. "Cohere 嵌入模型的中文表现如何？"
  3. "法律文档的语义匹配对嵌入模型有什么特殊要求？"
    ↓
3 个子问题分别检索 → 汇总信息 → 生成比较答案

选型总结

  • 大多数场景：HyDE 优先，性价比最高
  • 检索结果太少 / 太窄：加 Multi-Query
  • 用户问题"跳跃"且需要背景知识：用 Step-Back
  • 多步推理的复合问题：用 Query Decomposition
  • 不要叠加使用：HyDE + Multi-Query 叠加会让延迟翻倍但收益递减
未标记