Multi-query-Retrieval
2167 字约 7 分钟
domain/aiai/rag
2026-07-24
Multi-query Retrieval 是 Advanced RAG 中的检索增强策略，将用户的单一查询扩展为多个语义相关的查询变体，分别检索后合并结果，从而提升召回率和信息覆盖度。其核心洞察是：同一个信息需求可以用多种方式表述，不同表述可能命中不同的文档。
一句话解释
将一个查询扩展为多个角度不同的查询变体，并行检索后合并去重，用"量"换"全"——牺牲一些延迟换取更高的召回率。
核心问题
为什么单查询检索不够？
- 表述偏差：用户的 Query 只是一种表述方式，可能恰好与知识库中的表述不匹配
- 语义盲区：单一 Query 的 embedding 向量只能覆盖语义空间的一个方向，遗漏其他角度的相关文档
- 复合需求：一个 Query 可能隐含多个子需求，单一检索难以全部覆盖
- 检索器的局限：不同检索器（BM25 vs 向量检索）对不同表述的敏感度不同
多查询生成策略
1. LLM 生成（最常用）
原理：使用 LLM 根据原始 Query 生成 3-5 个语义相同但措辞不同的查询变体。
Prompt 模板示例：
你是一个查询扩展助手。请将以下用户问题从 3 个不同角度重新表述，
保持语义一致但使用不同的措辞和侧重点。
原始问题：{query}
请生成 3 个变体查询：优势：变体质量高，语义一致性好，能覆盖真正不同的角度 劣势：每次需要额外 LLM 调用（延迟 200-500ms，成本增加）
2. 模板扩展
原理：预定义一组改写模板，将 Query 填入不同模板生成变体。
模板示例：
- "如何{动作}{对象}" → "怎样实现{对象}的{动作}"
- "{对象}的{属性}是什么" → "请解释{对象}的{属性}"
- "{A}和{B}的区别" → "{A}与{B}有什么不同" / "对比{A}和{B}"
优势：零延迟、零成本、确定性强 劣势：变体多样性有限，依赖模板覆盖度
3. 同义词替换 + 句式变换
原理：对 Query 中的关键词进行同义词替换，或调整句式结构。
实现方式：
- 使用同义词词典（WordNet、中文同义词林）替换核心术语
- 主被动句式转换
- 增减修饰词
优势：轻量、快速 劣势：可能引入语义偏移（同义词不一定在所有上下文中等价）
多查询结果合并算法
多个查询各自返回一组检索结果，如何合并成最终结果集是关键环节。
1. RRF（Reciprocal Rank Fusion）
原理：根据文档在各查询结果中的排名计算融合分数，不依赖原始相似度分数的可比性。
公式：
RRF_score(d) = Σ 1 / (k + rank_i(d))其中 k 是常数（通常取 60），rank_i(d) 是文档 d 在第 i 个查询结果中的排名。
优势：
- 不需要不同检索器的分数归一化
- 对异常分数不敏感
- 被广泛验证为效果稳定的融合方法
示例：文档 A 在 Query1 排第 1、Query2 排第 3 → RRF = 1/(60+1) + 1/(60+3) = 0.0164 + 0.0159 = 0.0323
2. 加权融合
原理：对不同查询的检索结果赋予不同权重，按加权分数排序。
权重分配策略：
- 等权：所有查询权重相同（最简单）
- 原始 Query 加权：原始 Query 的结果权重更高（保证不偏离原始需求）
- 动态权重：根据各查询检索结果的质量（如 Rerank 分数）动态调整
3. 去重排序
原理：先对所有结果去重（基于文档 ID 或内容相似度），然后按综合相关性排序。
去重策略：
- 精确去重：相同文档 ID 只保留最高分的一次
- 语义去重：内容相似度 > 0.95 的文档只保留一篇（避免同一信息的不同片段重复出现）
合并算法对比
| 算法 | 实现复杂度 | 效果 | 适用场景 |
|---|---|---|---|
| RRF | 低 | 稳定优秀 | 通用场景，推荐默认 |
| 加权融合 | 中 | 可调优 | 需要对特定查询倾斜 |
| 去重排序 | 低 | 基础 | 查询变体少、结果重叠低 |
查询多样性保证
Multi-query 的核心价值在于"多样性"——如果生成的变体只是换皮不换骨，检索结果高度重叠，就失去了 Multi-query 的意义。
多样性保证策略：
- 角度约束：在 Prompt 中明确要求不同变体从不同角度切入
- 变体 1：从实现角度
- 变体 2：从原理角度
- 变体 3：从应用场景角度
- 结果重叠检测：如果多个查询的 Top-K 结果重叠率 > 70%，说明变体多样性不足
- 动态调整：重叠率高时，增大变体之间的语义距离
查询数量与延迟的权衡
| 查询数量 | 召回率提升 | 延迟增加 | 成本增加 | 推荐场景 |
|---|---|---|---|---|
| 1（原始） | 基线 | 基线 | 基线 | 简单问题 |
| 2-3 | +5-15% | +100-200ms | +100-200% | 通用场景 |
| 4-5 | +15-25% | +200-400ms | +300-400% | 复杂问题、研究性查询 |
| 6+ | 边际收益递减 | 显著增加 | 显著增加 | 不推荐 |
经验法则：3 个变体是最佳性价比点。超过 5 个后召回率提升有限，但延迟和成本线性增长。
Multi-query vs Query Rewrite 的区别与协同
| 维度 | Multi-query | Query Rewrite |
|---|---|---|
| 目标 | 提升召回率（多角度覆盖） | 提升精确率（对齐语义） |
| 输出 | 多个并行查询 | 一个优化后的查询 |
| 语义 | 变体之间语义相同 | 改写后语义更精确 |
| 成本 | N 倍检索成本 | 1 次改写 + 1 次检索 |
| 触发时机 | 检索结果不足时 | 检索前预处理 |
协同模式：
- 先改写后扩展：先通过 Query Rewrite 规范化 Query，再用 Multi-query 扩展变体
- 按需降级：先尝试单查询检索，结果不足时触发 Multi-query
- 与 Rerank 配合：Multi-query 扩大召回 → Rerank 精确排序 → 取 Top-K 给 LLM
Multi-query 在 Agentic RAG 中的角色
在 Agentic RAG 架构中，Multi-query 不再是一个固定步骤，而是 Agent 可以自主决策的工具：
Agent 接收到用户问题
├─ 评估问题复杂度
├─ 判断是否需要多角度检索
│ ├─ 是 → 生成多个查询 → 并行检索 → 合并结果
│ └─ 否 → 单查询检索
├─ 检查检索结果是否充分
│ ├─ 不充分 → 生成新的查询角度 → 补充检索
│ └─ 充分 → 进入生成阶段
└─ 生成回答Agent 可以根据中间结果动态决定是否追加查询，而非一次性固定生成 N 个变体。
RAG-Fusion
RAG-Fusion 是 Multi-query 的一个著名变体，将 Multi-query Retrieval 与 RRF 融合和 LLM 生成结合成一个完整管道：
- 用户 Query → LLM 生成多个变体查询
- 原始 Query + 变体查询 → 并行检索（向量检索或混合检索）
- 所有结果 → RRF 融合排序
- Top-K 结果 → LLM 生成最终回答
核心优势：RRF 融合消除了不同查询之间分数不可比的问题，使得融合结果更加稳定。
常见误区
- 变体数量越多越好：超过 5 个后边际收益递减，延迟和成本线性增长
- 不检查语义一致性：生成的变体偏离了原始 Query 的语义，引入噪声
- 忽视合并算法：简单拼接不去重会导致同一文档重复出现，浪费上下文窗口
- 所有 Query 都用 Multi-query：简单事实性查询不需要多角度检索，浪费资源
- 不做效果验证：没有对比单查询和 Multi-query 的效果差异，无法判断是否值得
可继续补充的方向
- Multi-query 与 HyDE 的结合策略
- 自适应查询数量（根据问题复杂度动态决定生成几个变体）
- Multi-query 在跨语言检索中的应用
- 基于强化学习优化查询生成策略