【RAG技术从小白到深入理解】RAG 查询优化策略：从多查询到 HyDE 的完整指南

检索增强生成（RAG）系统的核心瓶颈往往不在模型，而在检索质量。本文将深入探讨五种关键的查询优化策略，帮助你构建更智能、更精准的 RAG 系统。

前言

在构建 RAG（Retrieval-Augmented Generation）应用时，我们常常遇到一个尴尬的场景：知识库里有答案，但系统就是检索不出来。问题往往不在于向量模型不够好，而在于用户的原始查询和知识库中的文档之间存在语义鸿沟。

用户提问的方式千差万别：有人问得过于简短，有人问得过于宽泛，有人用的术语和文档中的不完全一致。如果我们只是简单地把原始问题向量化然后做相似度检索，检索效果往往会大打折扣。

查询优化（Query Optimization） 就是在检索发生之前，对用户的原始查询进行改造、扩展和优化，从而大幅提升检索命中率的一套方法论。本文将系统讲解五种主流且经实战验证的查询优化策略。

1.5 Multi Query — 多查询策略

核心思想

不要让一个查询承担所有责任。

Multi Query 的核心思想非常直观：用户的原始问题往往只有一个视角，但同一个问题可以从多个角度去理解和检索。通过 LLM 自动生成多个不同表述的查询语句，分别检索后再合并结果，可以显著提高召回率。

工作流程

优势分析

实际案例

假设用户问："怎么提高系统性能？"

LLM 可能生成如下多查询：

每个查询从不同角度切入，大幅提高了命中相关文档的概率。

注意事项

• 查询数量控制：通常 3-5 个衍生查询即可，过多会增加延迟和噪声

• 并行检索：多个查询的检索可以完全并行，不会线性增加延迟

• 去重策略：需要合理的去重和融合策略（可结合 RRF）

• LLM 成本：需要额外调用一次 LLM 生成多个查询

架构图

1.6 RAG-Fusion — 多查询结果融合

核心思想

RAG-Fusion 是 Multi Query 的进阶版，它不仅生成多个查询，还引入了一套精密的结果融合机制。核心在于：生成多个查询 → 分别检索 → 使用 RRF 算法融合排序 → 输出最终结果。

什么是 RRF？

RRF（Reciprocal Rank Fusion，倒数排名融合） 是一种经典的多路召回融合算法，来自信息检索领域。其公式为：

$$RRF(d) = \\sum_{q \\in Q} \\frac{1}{k + rank_q(d)}$$

其中：

• $d$ 是某个文档

• $Q$ 是所有查询的集合

• $rank_q(d)$ 是文档 $d$ 在查询 $q$ 的结果中的排名

• $k$ 是平滑常数（通常取 60）

直觉理解：一个文档在多个查询结果中排名越靠前，它的 RRF 得分就越高。排名的倒数意味着排名 1 的贡献远大于排名 10，这符合"头部结果更可靠"的直觉。

RAG-Fusion 工作流程

代码示例

from typing import List, Dict, Tuple
​
def reciprocal_rank_fusion(
   search_results: List[List[Tuple[str, float]]],
   k: int = 60
) -> List[Tuple[str, float]]:
   """
  RRF 融合多路检索结果
   
  Args:
      search_results: 每个查询的检索结果列表，
                      每项为 (doc_id, similarity_score)
      k: RRF 平滑常数
   
  Returns:
      融合后的排序结果
  """
   doc_scores = {}
   
   for results in search_results:
       for rank, (doc_id, _) in enumerate(results):
           # RRF 公式: 1 / (k + rank)
           rrf_score = 1.0 / (k + rank + 1)
           doc_scores[doc_id] = doc_scores.get(doc_id, 0) + rrf_score
   
   # 按 RRF 总分降序排列
   sorted_docs = sorted(
       doc_scores.items(),
       key=lambda x: x[1],
       reverse=True
  )
   
   return sorted_docs

为什么 RRF 这么有效？

实际效果对比

注意事项

• 查询多样性是关键：如果 LLM 生成的多个查询高度同质化，RRF 的增益会大打折扣

• k 值调优：k 值越小，高排名的影响越大；建议在 0-100 范围内调试

• 检索深度：每个查询需要检索足够多的文档（建议 top-20 到 top-50），给 RRF 足够的候选池

1.7 Decomposition — 问题分解

核心思想

复杂问题不是一个问题，而是一组子问题的组合。

Decomposition 策略的核心是：将用户提出的复杂、多层次的复合问题，分解为多个独立的原子性子问题，分别检索后整合上下文，再交给 LLM 综合回答。

为什么需要问题分解？

考虑这个用户问题：

"比较一下 Transformer 和 Mamba 架构在长序列建模上的性能差异，并说明各自的适用场景。"

这个问题实际上包含了：

如果直接用原问题检索，很难一次性命中所有这些维度的文档。而分解后，每个子问题都能精准命中对应的知识片段。

工作流程

实际案例

原始问题："RAG 系统如何同时保证低延迟和高召回率？"

LLM 分解结果：

代码实现

from typing import List
import asyncio
​
class QueryDecomposer:
   def __init__(self, llm, retriever):
       self.llm = llm
       self.retriever = retriever
   
   def decompose(self, query: str) -> List[str]:
       """使用 LLM 将复杂问题分解为子问题"""
       prompt = f"""将以下复杂问题分解为多个简单的子问题。
每个子问题应该是独立的、可以直接检索回答的。
​
原始问题: {query}
​
要求：
1. 每个子问题覆盖原始问题的一个维度
2. 子问题之间不要有重叠
3. 按逻辑顺序排列
​
请返回 JSON 格式的子问题列表。"""
​
       response = self.llm.invoke(prompt)
       return self._parse_sub_queries(response)
   
   async def retrieve_for_sub_queries(
       self,
       sub_queries: List[str],
       top_k: int = 5
  ) -> List[str]:
       """并行检索所有子问题"""
       tasks = [
           self.retriever.aretrieve(q, top_k)
           for q in sub_queries
      ]
       all_results = await asyncio.gather(*tasks)
       
       # 去重合并
       seen = set()
       merged = []
       for results in all_results:
           for doc in results:
               if doc.id not in seen:
                   seen.add(doc.id)
                   merged.append(doc)
       return merged
   
   def synthesize(self, query: str, contexts: List[str]) -> str:
       """基于检索结果综合回答"""
       prompt = f"""基于以下检索到的上下文信息，回答用户问题。
​
用户问题: {query}
​
相关上下文:
{'—'.join(contexts)}
​
请综合以上信息，给出完整的回答。"""
       return self.llm.invoke(prompt)

三种常见的分解策略

优势分析

• ✅ 精准检索：每个子问题小而聚焦，检索精度高

• ✅ 全面覆盖：不易遗漏原始问题的某个维度

• ✅ 并行处理：子问题检索可以完全并行

• ✅ 答案质量：基于更完整的上下文，LLM 回答更全面

注意事项

• 分解粒度：过细会导致碎片化，过粗则效果不彰；2-5 个子问题为佳

• 子问题质量：依赖 LLM 的分解能力，建议做 prompt 工程优化

• 上下文长度：合并后的上下文可能很长，注意 token 限制

• 额外延迟：需要一次额外的 LLM 调用来分解问题

1.8 Step Back — 问答回退策略

什么是 Step Back？

Step Back（后退一步）策略的核心思想是：在回答具体问题之前，先生成一个更抽象、更通用、更宏观的"回退问题"，通过回答这个高层问题获取背景知识，再结合原始检索结果给出最终答案。

这是一种"自上而下"的推理方式——先建立大局观，再处理细节。

工作原理

代码实现

class StepBackRAG:
   def __init__(self, llm, retriever):
       self.llm = llm
       self.retriever = retriever
   
   def generate_step_back_query(self, original_query: str) -> str:
       """生成回退问题"""
       prompt = f"""针对以下具体问题，请生成一个更抽象、更通用的"回退问题"。
回退问题应该关注更高层次的概念和原理，而不是具体细节。
​
具体问题: {original_query}
​
要求：
1. 回退问题应比原始问题更宏观
2. 回退问题的答案应能为回答原始问题提供有用的背景知识
3. 回退问题本身应该是可独立回答的
​
回退问题："""
       
       return self.llm.invoke(prompt).strip()
   
   def retrieve_with_step_back(
       self,
       query: str,
       top_k: int = 5,
       step_back_top_k: int = 3
  ) -> tuple:
       """执行带 Step Back 的检索"""
       # 1. 原始检索
       original_docs = self.retriever.retrieve(query, top_k)
       
       # 2. 生成回退问题并检索
       step_back_query = self.generate_step_back_query(query)
       step_back_docs = self.retriever.retrieve(
           step_back_query,
           step_back_top_k
      )
       
       # 3. 合并上下文（回退知识放前面，建立全局认知）
       all_contexts = step_back_docs + original_docs
       
       return all_contexts, step_back_query

实际效果对比

实验场景：技术问答数据集，1000 个多跳推理问题

适用场景

Step Back 策略特别适合以下场景：

1.9 HyDE（假设性文档嵌入）

核心思想

HyDE（Hypothetical Document Embeddings，假设性文档嵌入）是近年来最具创新性的查询优化策略之一。其核心思想出奇地简单但极为有效：

不要让问题和文档直接匹配。先让 LLM 生成一个假设性的"理想答案"，然后用这个假设答案去检索。

工作流程图

问题的本质

在传统 RAG 中，我们面临的核心挑战是 查询-文档不对称性：

• 查询：通常是简短的、口语化的、缺乏上下文的

• 文档：通常是详尽的、结构化的、包含丰富上下文的

这两种文本处于不同的"语义空间"。直接把一个短问题向量化然后在文档向量空间中搜索，就像用照片去匹配草图——虽然可能找到，但精度不会很高。

HyDE 如何解决？

HyDE 巧妙地将查询 → 文档的匹配问题转换为了文档 → 文档的匹配问题：

传统检索:   问题向量 ←→ 文档向量   （跨空间匹配，精度低）
HyDE检索:   假设文档向量 ←→ 文档向量 （同空间匹配，精度高）

完整的 HyDE 实现（从零开始）

import numpy as np
from typing import List, Optional

class HyDERetriever:
def __init__(
self,
llm,
embedder,
vector_store,
hyde_prompt: Optional[str] = None
):
self.llm = llm
self.embedder = embedder
self.vector_store = vector_store
self.hyde_prompt = hyde_prompt or self._default_prompt()

@staticmethod
def _default_prompt() -> str:
return """请根据以下问题，生成一份假设性的文档段落。

要求：
1. 假装你是一份真实的技术文档或百科条目
2. 内容要丰富、专业、详实，包含具体细节
3. 不要说你不知道或不确定——生成一个"理想情况下的答案"
4. 不要提及这是假设性的

问题: {query}

假设性文档："""

def generate_hypothetical_doc(self, query: str) -> str:
"""LLM 生成假设性文档"""
prompt = self.hyde_prompt.format(query=query)
return self.llm.invoke(prompt).strip()

async def retrieve(
self,
query: str,
top_k: int = 10,
use_hyde: bool = True
) -> List[dict]:
"""
HyDE 检索

Args:
query: 用户原始问题
top_k: 返回文档数量
use_hyde: 是否使用 HyDE（False 时退化为普通检索）
"""
if use_hyde:
# 1. 生成假设性文档
hypo_doc = self.generate_hypothetical_doc(query)

# 2. 向量化假设文档
hypo_embedding = self.embedder.embed(hypo_doc)

# 3. 用假设文档向量检索
results = await self.vector_store.search(
hypo_embedding,
top_k=top_k
)
else:
# 普通检索
query_embedding = self.embedder.embed(query)
results = await self.vector_store.search(
query_embedding,
top_k=top_k
)

return results

async def retrieve_hybrid(
self,
query: str,
top_k: int = 10,
hyde_weight: float = 0.7
) -> List[dict]:
"""
混合检索：结合 HyDE 和原始查询

Args:
hyde_weight: HyDE 结果的权重，0-1 之间
"""
# HyDE 检索
hyde_results = await self.retrieve(query, top_k * 2, use_hyde=True)
# 普通检索
vanilla_results = await self.retrieve(query, top_k * 2, use_hyde=False)

# 使用 RRF 融合两种检索结果
return self._rrf_fusion(
[hyde_results, vanilla_results],
weights=[hyde_weight, 1 – hyde_weight]
)

def _rrf_fusion(
self,
result_lists: List[List[dict]],
weights: List[float],
k: int = 60
) -> List[dict]:
"""带权重的 RRF 融合"""
doc_scores = {}
doc_map = {}

for results, weight in zip(result_lists, weights):
for rank, doc in enumerate(results):
doc_id = doc['id']
rrf_score = weight / (k + rank + 1)
doc_scores[doc_id] = doc_scores.get(doc_id, 0) + rrf_score
doc_map[doc_id] = doc

sorted_ids = sorted(
doc_scores.keys(),
key=lambda x: doc_scores[x],
reverse=True
)

return [doc_map[doc_id] for doc_id in sorted_ids[:len(sorted_ids)]]

性能对比实验

数据集：Natural Questions (NQ)、TriviaQA、技术文档 Q&A

实际效果数据

在内部测试集（500 个真实用户问题）上的对比：

              Recall@5   Recall@10   MRR
─────────────────────────────────────────
Baseline       0.52       0.64     0.47
Multi Query     0.59       0.70     0.52
HyDE           0.67       0.79     0.61
HyDE+RRF       0.72       0.84     0.66

优缺点分析ji

优点 ✅

• 检索精度极高：文档→文档匹配远优于问题→文档匹配

• 实现简单：核心逻辑只需要一次额外的 LLM 调用

• 与模型无关：可以与任何向量数据库和嵌入模型配合使用

• 处理模糊查询：即使原始问题表述不清，LLM 也能填充细节

• 零样本：不需要训练数据或微调

缺点 ❌

• 增加延迟：额外的 LLM 调用会增加 1-3 秒延迟

• 幻觉风险：在 LLM 完全不了解的领域，生成的假设文档可能完全偏离

• 成本增加：每次查询增加一次 LLM 调用的 token 消耗

• 不适合事实核查：如果用户的目的就是验证某个事实，假设性文档可能产生误导

最佳实践建议

策略对比总览

结语

RAG 查询优化不是"银弹"，而是一套需要因地制宜的工具箱。在实际应用中，这些策略往往不是互斥的——你可以组合使用：

• Multi Query + RRF = RAG-Fusion（已内置）

• Decomposition + HyDE = 每个子问题都用 HyDE 优化检索

• Step Back + Decomposition = 先后退建立全局认知，再分解处理细节

选择哪种策略，取决于你的延迟预算、成本预算和精度要求。建议从 Multi Query 开始，逐步尝试更高级的策略，找到最适合你业务场景的组合。

如有问题或建议，欢迎在评论区交流讨论！