多查詢檢索 (Multi-query Retrieval)

3 秒看懂

一句話定義：對同一使用者意圖，用 LLM 生成多個不同表述的檢索查詢，分別召回文件後合併去重，從而提升 RAG 系統的檢索召回率與意圖覆蓋度。

類比：你問圖書館員”有哪些好書”，聰明的館員會同時搜”高分書籍推薦""經典必讀書單""年度暢銷書”——比只搜一次找到的更多。

3 分鐘產業解釋

為什麼需要多查詢？

傳統 RAG 流程是”使用者提問 → 向量檢索 → 餵給 LLM”。但這存在一個根本性問題：使用者的單一表述與文件的表述之間存在語義鴻溝。

痛點	示例
措辭不匹配	使用者問”GPU 怎麼選”，文件寫的是”顯示卡選購指南”
粒度不對齊	使用者問宏觀問題，文件是微觀細節
視角單一	使用者只從一個角度提問，遺漏相關資訊

多查詢檢索的核心邏輯：與其依賴一次檢索命中，不如”多路出擊、彙總戰績”。

在 RAG 產業鏈中的位置

使用者Query → [查詢改寫/擴充套件] → [多查詢生成] → 並行向量檢索 × N
                                                      ↓
                                              合併 + 去重 + 重排
                                                      ↓
                                              Top-K 文件 → LLM 生成

它是 RAG 檢索最佳化層的關鍵技術元件，位於查詢理解（Query Understanding）與文件召回之間。

15 分鐘專家深入

技術本質：檢索召回率與精確率的再平衡

多查詢檢索本質上是一種以召回率換精確率、再通過重排恢復精確率的策略：

擴充套件檢索面：多個查詢變體從不同語義角度檢索，減少遺漏
接受噪聲：召回更多文件，必然引入更多噪聲
後處理消噪：通過去重、重排（Reranking）篩選最終結果

這是一種典型的 Precision-Recall Tradeoff 最佳化策略。

與其他檢索最佳化技術的關係

技術	思路	與多查詢的關係
Query Rewriting	改寫單個查詢使其更清晰	多查詢是其”並行多路”泛化
HyDE（假設文件嵌入）	先生成假設答案，用答案去檢索	與多查詢可疊加使用
Sub-question Decomposition	將複雜問題拆解為子問題	拆解後每個子問題可再做多查詢
Sentence Window Retrieval	擴充套件檢索視窗上下文	解決粒度問題，與多查詢互補
Re-ranking	對檢索結果重排序	多查詢的後處理必經步驟

工程實現的關鍵設計點

查詢變體生成策略（這是技術核心差異點）：

策略	描述	優劣
LLM 直接生成多個表述	讓 LLM 用不同措辭重新表達同一問題	簡單直接，但變體多樣性受限於 prompt
視角拆解	從”是什麼/為什麼/怎麼做”等角度拆	結構化，但不一定適用所有問題
子問題分解 + 各自多查詢	先拆再擴	最全面，但檢索次數指數增長，成本高
歷史查詢融合	結合使用者歷史對話生成上下文感知查詢	適合多輪對話場景

合併策略：

簡單拼接去重：按文件 ID 或內容雜湊去重
互惠排序融合（Reciprocal Rank Fusion, RRF）：對同一文件在不同查詢中的排名取加權平均，是業界較常用的融合方法
向量聚類合併：對召回文件做 embedding 聚類，選擇代表性文件

技術原理（深入機制）

整體流程架構

┌─────────────────────────────────────────────────────────────┐
│                    Multi-Query Retrieval Pipeline            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  User Query ────────────────────────────────────────┐      │
│       │                                              │      │
│       ▼                                              │      │
│  ┌─────────────────────┐                            │      │
│  │   Query Generator   │                            │      │
│  │   (LLM-based)       │                            │      │
│  └─────┬───┬───┬───┬───┘                            │      │
│        │   │   │   │                                │      │
│        Q1  Q2  Q3  Q4  (N 個變體查詢)               │      │
│        │   │   │   │                                │      │
│        ▼   ▼   ▼   ▼                                │      │
│  ┌─────────────────────┐                            │      │
│  │  Vector Search × N  │                            │      │
│  │  (並行/序列檢索)     │                            │      │
│  └─────┬───┬───┬───┬───┘                            │      │
│        │   │   │   │                                │      │
│        D1  D2  D3  D4  (各路召回文件集)             │      │
│        │   │   │   │                                │      │
│        ▼   ▼   ▼   ▼                                │      │
│  ┌─────────────────────┐                            │      │
│  │    Merge & Dedup    │                            │      │
│  │  (RRF / 去重 / 聚合) │                            │      │
│  └─────────┬───────────┘                            │      │
│            │                                         │      │
│            ▼                                         │      │
│  ┌─────────────────────┐                            │      │
│  │    Re-Ranker        │                            │      │
│  │  (Cross-Encoder等)  │                            │      │
│  └─────────┬───────────┘                            │      │
│            │                                         │      │
│            ▼                                         │      │
│  Top-K Documents ──────────────────────────────────►│      │
│                                                   LLM生成  │
│                                                     │      │
│  最終 Response ◄───────────────────────────────────┘      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

關鍵機制詳解

1. 查詢變體生成的 Prompt 工程

典型的 Prompt 模板結構（定性描述，具體實現因架構而異）：

System: 你是一個查詢最佳化助手。請將使用者問題改寫為 {N} 個不同的檢索查詢。
        要求：保持語義一致，但使用不同的措辭、角度或粒度。

User: {original_query}

Output: 
- 變體1: ...
- 變體2: ...
- 變體3: ...

生成變體數量的選擇是關鍵權衡：

變體太少 → 檢索面擴充套件不夠
變體太多 → 檢索成本線性增長、引入過多噪聲
業界常見範圍：3-5 個變體 [定性認知，未檢索驗證]

2. Reciprocal Rank Fusion (RRF) 演算法

這是多查詢檢索中最常用的文件融合方法：

RRF_Score(d) = Σ  1 / (k + rank_i(d))

其中：
- d: 某個文件
- rank_i(d): 文件 d 在第 i 個查詢結果中的排名
- k: 平滑常數（常見取值 60，原始論文建議值）
- 求和範圍: 所有查詢的結果

核心思想：一個文件如果在多個查詢中都排名靠前，其綜合得分就高。這天然支援跨查詢一致性的獎勵。

3. 與向量資料庫互動的技術細節

多查詢檢索對向量資料庫的要求：

要求	原因
支援併發查詢	N 個變體需要並行檢索以控制延遲
批次查詢介面	減少網路開銷
返回距離/分數	用於後續融合計算
Metadata 過濾	部分變體可能需要帶條件過濾

延遲影響估算 [定性]：

序列 N 次檢索：延遲 ≈ N × 單次檢索延遲
並行 N 次檢索：延遲 ≈ 單次檢索延遲 + 併發排程開銷
實際工程中通常選擇並行執行

技術演進史

階段	時間區間 [定性]	特徵
樸素檢索	早期	BM25 關鍵詞匹配，單一查詢
語義檢索興起	Embedding 模型成熟後	向量相似度檢索，仍是單一查詢
查詢改寫	RAG 概念普及後	單一查詢的改寫最佳化
多查詢檢索	LLM 應用爆發期	LLM 生成多變體，並行檢索融合
高階 RAG	當前前沿	多查詢 + 自適應檢索 + 迭代檢索 + Agent 化

關鍵推動力：

LLM 的普及使得”生成多個查詢變體”變得廉價且高質量
RAG 應用的落地暴露了單一查詢召回不足的工程問題
向量資料庫效能提升支援了多次檢索的延遲要求

技術路線對比

維度	單一查詢檢索	多查詢檢索	知識圖譜檢索	混合檢索(BM25+向量)
召回率	低-中	高	高（結構化）	中-高
精確率	中	中（需重排提升）	高	中
延遲	低	中（N倍檢索）	中	中
實現複雜度	低	中	高（需建置圖譜）	中
對 LLM 依賴	無/低	高（查詢生成）	低	無/低
適用場景	簡單問答	複雜/模糊意圖	結構化知識	通用場景
成本	低	中-高	高（建置成本）	中

上下游

上游（多查詢檢索依賴什麼）

環節	具體技術/產品
LLM 服務	用於生成查詢變體（GPT系列/Claude/開源LLM等）
Embedding 模型	將查詢和文件編碼為向量（各廠商Embedding API）
向量資料庫	儲存和檢索文件向量（Pinecone/Weaviate/Milvus/Chroma等）
Reranker	對合並後結果重排序（Cross-Encoder模型/各廠商Rerank API）

下游（多查詢檢索服務什麼）

環節	具體應用
RAG 應用	企業知識問答、客服系統、文件助手
Agent 架構	LangChain/LlamaIndex 等架構的檢索元件
搜尋增強	傳統搜尋系統的語義增強
多模態檢索	文本查詢檢索圖片/影片/程式碼等

關鍵指標

指標	定義	最佳化方向
Recall@K	Top-K 結果中包含相關文件的比例	多查詢的核心最佳化目標
MRR (Mean Reciprocal Rank)	第一個相關文件排名的倒數均值	重排後應顯著提升
NDCG	考慮位置權重的排序質量	綜合評估檢索+排序
查詢變體多樣性	變體之間語義距離	太相似則擴充套件效果有限
端到端延遲	從使用者輸入到返回結果的時間	並行化是關鍵
檢索成本	LLM 呼叫次數 + 向量資料庫查詢次數	變體數量直接決定
答案准確率	最終LLM生成答案的正確性	端到端評估

供需與市場資料

需求側

定性判斷 [基於技術趨勢推斷，未檢索驗證]：

RAG 已成為 LLM 企業應用的標配架構
企業級 RAG 系統對檢索質量要求高，單一查詢難以滿足
多查詢檢索是 RAG 最佳化的”低垂果實”，實現門檻相對低

供給側

層面	供給方	定位
架構內建	LangChain / LlamaIndex	已內建 MultiQueryRetriever 等元件
雲端服務	各大雲端廠商的 RAG 服務	作為檢索最佳化選項提供
專項工具	未充分揭露	獨立的查詢擴充套件SaaS產品尚不明確

市場規模

多查詢檢索本身不是一個獨立市場，而是 RAG/檢索最佳化市場的一個技術元件。

相關市場參考 [行業報告推斷，具體數字未充分揭露]：

全球 RAG 工具/平台市場正在快速增長
向量資料庫市場預計在幾年內達到數十億美元規模
多查詢檢索作為最佳化技術，其價值體現在上層 RAG 應用中

代表公司與資本對映

技術方案提供方

公司/專案	角色	與多查詢檢索的關係
LangChain	開源架構	提供 MultiQueryRetriever 元件
LlamaIndex	開源架構	提供多種查詢擴充套件和融合策略
各大雲端廠商	雲端服務	在其 RAG 服務中整合檢索最佳化

受益生態

環節	受益邏輯
LLM 服務商	多查詢 = N 倍 LLM 呼叫，直接增加推論需求
向量資料庫	多查詢 = N 倍檢索請求，增加讀取負載
Embedding/Reranker 服務商	更多編碼和重排請求
企業 RAG 應用方	檢索質量提升 → 應用效果更好 → 付費意願增強

資本對映邏輯：多查詢檢索的普及，本質上是用更多計算資源換取更好的檢索質量，這對上游算力/模型服務是正向需求拉動。

投資邏輯

核心判斷

多查詢檢索是 RAG 最佳化的”標配化”趨勢
- 技術門檻不高，但效果顯著
- 已被主流架構內建，採用成本低
- 預期將從”高階最佳化”變為”基礎配置”
對 LLM 推論需求的乘數效應
- 每次使用者查詢 → N 次 LLM 呼叫（生成變體）+ 1 次最終生成
- 直接拉動推論 token 消耗
- 利好：推論晶片、推論最佳化、LLM API 服務商
RAG 技術棧的”軍備競賽”
- 企業 RAG 應用競爭 → 檢索質量成為差異化要素
- 多查詢 + 重排 + 迭代檢索等技術疊加使用
- 利好：整個 RAG 工具鏈生態

關注點

維度	關注
成本效率	多查詢的 token 成本與質量提升是否成正比？
替代方案	更好的 Embedding 模型是否會減少對多查詢的依賴？
Agent 化趨勢	Agent 自主規劃檢索是否替代固定多查詢模式？

常見誤讀糾偏

❌ 誤讀一：多查詢檢索 = 簡單地把問題重複問 N 遍

糾偏：

多查詢的核心是語義多樣性，不是機械重複
好的變體應該從不同角度、不同粒度、不同措辭切入
如果 N 個變體高度相似，檢索結果也高度重疊，等於白做
判斷標準：變體之間在向量空間中的距離應有顯著差異

❌ 誤讀二：變體越多越好

糾偏：

變體數量與效果並非線性正相關
存在收益遞減：前 3-5 個變體通常覆蓋大部分增益 [定性認知]
過多變體的副作用：
- 檢索成本線性增長
- 引入更多噪聲文件
- 增加端到端延遲
- 重排壓力增大
需要在具體場景中做 A/B 測試確定最優變體數

❌ 誤讀三：多查詢檢索可以替代好的 Embedding 模型

糾偏：

多查詢是”檢索策略層”最佳化，Embedding 是”表示層”基礎
兩者是互補關係，不是替代關係
差的 Embedding + 多查詢 < 好的 Embedding + 多查詢
優先順序建議：先選好 Embedding 模型，再疊加多查詢策略

❌ 誤讀四：多查詢只適用於向量檢索

糾偏：

多查詢是一種通用的檢索增強策略，不限於向量檢索
可應用於：
- BM25 關鍵詞檢索（生成不同關鍵詞組合）
- 知識圖譜查詢（生成不同的 SPARQL/Cypher 查詢）
- SQL 資料庫查詢（生成不同的查詢語句）
- API 呼叫（生成不同的搜尋引數）
向量檢索是當前最常見的應用場景，但不是唯一場景

學習路徑

入門（理解概念）

先理解基礎 RAG
- 瞭解 RAG 的基本流程：Query → Retrieve → Generate
- 動手實現一個最簡單的 RAG Demo
體驗單一查詢的侷限性
- 用同一問題的不同措辭測試檢索結果
- 觀察”使用者問法”與”文件表述”之間的 gap
瞭解多查詢的思想
- LangChain / LlamaIndex 官方文件中的 Multi-Query 相關章節

進階（動手實踐）

實現基礎多查詢檢索
- 使用架構提供的 MultiQueryRetriever
- 對比單一查詢 vs 多查詢的 Recall 指標
調優查詢生成策略
- 實驗不同的 Prompt 模板
- 調整變體數量
- 測試不同的融合方法（簡單去重 vs RRF）
整合 Reranker
- 在多查詢後加入 Cross-Encoder 重排
- 觀察對精確率和最終答案質量的提升

高階（深度理解）

研究 RRF 等融合演算法的數學原理
- 閱讀原始論文
- 理解引數 k 的影響
探索自適應檢索
- 研究何時需要多查詢、何時不需要
- 瞭解 Self-RAG、CRAG 等自適應檢索範式
端到端評估體系建置
- 設計評估資料集
- 建立 Recall/MRR/NDCG + 答案准確率的完整評估流程

一句話總結

多查詢檢索是用”冗餘換覆蓋”的檢索策略——讓 LLM 幫使用者多問幾個角度的問題，再把所有答案彙總篩選，是當前 RAG 系統提升檢索召回率最實用且易落地的最佳化手段。

延伸閱讀與來源

技術文件

LangChain 官方文件 — MultiQueryRetriever 相關章節
LlamaIndex 官方文件 — 查詢擴充套件與融合策略
各向量資料庫文件中的 RAG 最佳實踐指南

架構與工具

LangChain / LlamaIndex 的 MultiQuery 示例程式碼
各主流 RAG 架構的檢索最佳化模組文件

免責宣告

⚠️ 本頁技術描述基於概念性理解和行業通用認知，未獲取到聯網檢索結果進行事實驗證。具體的產品實現、效能資料、市場數字等請以各廠商官方文件和最新行業報告為準。投資決策請基於獨立研究。

最後更新：基於技術概念理解編寫，檢索來源：未成功獲取（HTTP 403）