🔍 Multi-Query Retriever RAG：如何显著提升您的 AI 文档检索准确性

Source: Dev.to

问题所在：标准 RAG 为什么失效

词汇不匹配问题

想象一下，你已经构建了一个漂亮的 RAG 系统。你已经为成千上万的文档建立了索引、生成了嵌入，并部署了聊天机器人。但用户不断抱怨：“AI 找不到相关信息！”

标准 RAG 依赖 单一查询嵌入 来寻找相似文档。问题在于：用户提问的方式与文档的写法不同。

真实案例：词汇鸿沟

示例 1：IT 支持噩梦

👤 用户提问:      "How do I fix a slow computer?"
📄 文档内容:  "Performance optimization techniques for system latency"
❌ 结果:         未命中！嵌入差异太大。

示例 2：销售问题

👤 用户提问:      "Show me deals closing this month"
📄 文档内容:  "Opportunity pipeline with close date in current period"
❌ 结果:         未命中！"deals" ≠ "Opportunity"，"closing" ≠ "close date"

示例 3：医疗查询

👤 用户提问:      "What are the side effects of this drug?"
📄 文档内容:  "Adverse reactions and contraindications for pharmaceutical compound"
❌ 结果:         未命中！口语化语言 vs. 医学术语

示例 4：开发者的困惑

👤 用户提问:      "Why is my API call failing?"
📄 文档内容:  "HTTP request error handling and exception management"
❌ 结果:         未命中！"failing" ≠ "error handling"

示例 5：高管仪表盘

👤 用户提问:      "How's the team doing?"
📄 文档内容:  "Quarterly performance metrics and KPI analysis"
❌ 结果:         未命中！随意提问 vs. 正式报告语言

示例 6：困惑的客户

👤 用户提问:      "My thing isn't working"
📄 文档内容:  "Troubleshooting device malfunction procedures"
❌ 结果:         未命中！模糊的用户语言 vs. 技术文档

顿悟时刻

“文档里有完美答案……但我的用户提错了问题！”

不，用户并没有提错——他们是以 人类 的方式提问。简单的 RAG 期待用户像文档作者一样思考，这本质上是倒置的。

这种 词汇差距 严重削弱了 RAG 的准确性。

单一视角的局限

标准 RAG 只从 一个角度 看待你的问题：

用户问题: "How do agents work?"
        │
        ▼
单一查询嵌入 → 向量检索 → 受限结果

使用不同术语讨论相同概念的文档会被完全遗漏。

测试得到的真实统计

最高可达 40 % 的相关文档对简单 RAG 来说是不可见的。

什么是多查询 RAG？

定义

多查询 RAG（Retrieval‑Augmented Generation）利用 LLM 生成用户查询的多个变体，随后使用 所有 变体进行检索并合并结果。它不是只用单一查询，而是用 3‑5 种不同表述来搜索同一个问题。

核心洞见

“如果你用五种不同的方式提问，你会发现单次提问根本找不到的答案。”

多查询 RAG 通过 LLM 自动改写问题，捕获：

• 不同词汇（同义词、专业术语）
• 不同视角（用户 vs. 专家）
• 不同细粒度（宽泛 vs. 具体）
• 不同结构（疑问句 vs. 陈述句）

多查询 RAG 的工作原理

步骤详解

步骤 1：接收用户查询

步骤 2：生成查询变体（LLM）

步骤 3：使用所有变体在向量数据库中检索
每个生成的查询都会被嵌入，并用于从向量存储中检索候选文档。

步骤 4：合并并排序结果
将所有查询的检索结果合并、去重，然后重新排序（例如使用 reciprocal rank fusion 或 cross‑encoder）。

步骤 5：将检索到的上下文传递给生成模型
最终的相关段落集合会喂给 LLM，生成答案。