承昨日把 RAG 拆成檢索與生成兩段、並靠 cross-encoder reranking 把 precision 拉起來,今天往檢索的更上游走一步:reranking 再強也只能重排「已經撈回來」的候選,撈不到的證據它救不了。真正決定 recall 天花板的,是第一層檢索的架構——而 2026 年的共識是,單一向量檢索早已不是最佳解,混合搜尋(hybrid search)才是任何正式 RAG 部署該有的最低標準。
📖 學
單一向量檢索之所以不夠,是因為 dense embedding 與 sparse 關鍵字檢索各有系統性的盲點,而且盲點恰好互補。Dense 向量擅長抓語意——使用者用不同措辭問同一件事,它也能對上;但它對精確字串、專有名詞、產品型號、程式碼片段、罕見縮寫這類「字面就是關鍵」的查詢常常失手,因為這些 token 在通用語意空間裡沒有清楚的鄰居。BM25 這類 sparse 檢索則相反:它對精確關鍵字、代碼、罕用詞極度可靠,卻完全不懂同義改寫,你問「怎麼取消訂閱」它撈不到只寫「退訂流程」的那頁。把兩者並聯,等於同時補上彼此的漏洞,這也是為什麼混合檢索在各種基準上穩定勝過任一單一方法。
問題是,dense 與 sparse 的分數根本不在同一個尺度上——向量的餘弦相似度和 BM25 的詞頻分數不能直接相加,硬加會讓其中一邊的數值淹沒另一邊。2026 年最常見的解法是 Reciprocal Rank Fusion(RRF),它刻意只看「排名」而不看「分數」:每個文件在某一路檢索的貢獻是 1/(k+rank),把各路的貢獻加總後重排。因為只用 rank,RRF 天生迴避了分數尺度不相容這個會拖垮樸素加權管線的老問題,也不需要為每個資料集重新校準權重,所以成了預設首選。若你願意花心力調參,convex combination(例如 α=0.5 等權相加校準後的分數)在某些基準能小勝 RRF——研究裡 Recall@5 約 0.726 對 0.716——但代價是每換一個語料就得重新校準,RRF 的「開箱即用」在工程上往往更划算。
真正該記住的是整條多階段管線疊起來的效果,而不是任何單一環節。把「hybrid 檢索 + RRF 融合 + cross-encoder reranking」串成一條兩級管線後,在金融文件基準上 Recall@5 可以達到 0.816,對照純 dense 的 0.587 是接近四成的提升;即便只跟「hybrid RRF 但不 rerank」的 0.695 相比,加上 reranking 也還有約 17% 的增幅。在 WANDS 電商基準上,調校過的 hybrid 設定拿到 0.7497 的 NDCG,比單用 BM25(0.6983)或純向量(0.6953)各高約 7.4%。這些數字共同指向一個結論:hybrid 負責把「該撈的」撈得更齊(衝 recall),reranking 負責把「撈回來的」排得更準(衝 precision),兩者是分工而非互相取代——這正好接續昨天那句「向量衝 recall、reranker 衝 precision」,只是把 recall 那一端從單路向量升級成了多路融合。
檢索之前的「查詢改寫」是另一個常被低估的槓桿。使用者的實際提問往往是口語、帶代詞、帶省略的——「那它跟上一版差在哪?」裡的「它」和「上一版」要靠對話脈絡才解得開。conversational query rewriting 的工作,就是把這種依賴上下文的句子改寫成一個能獨立檢索的完整查詢,先把指代與省略補齊,再送進檢索。對於跨多份文件才答得出的多跳問題,則可以用 query decomposition 把一個大問題拆成幾個子問題,各自檢索後再綜合。但 2026 年一個 stage-aware 的教訓值得記牢:分解不是免費的,簡單查詢硬拆反而引入雜訊、拖慢延遲,該拆的是那些明顯多條件、多跳的查詢,而不是每一句都拆。
最後是工程上的取捨,別把 hybrid 當成無腦開就好的開關。多路檢索、融合、reranking 每一層都疊加延遲與成本,實務上要靠限制檢索深度、對熱門查詢做快取、以及把 reranker 的候選集控制在合理大小來壓住尾延遲。把 hybrid 視為「最低可行基準」的意思是:先用它建起一條穩定、可評估的檢索底盤,再決定要不要往上疊 GraphRAG、agentic 迴圈這些更重的東西——如果連 hybrid 加 reranking 都還沒做,先別急著追更花俏的架構。
🧠 記
- Dense 與 BM25 的盲點互補:向量懂語意、弱在精確詞/型號/代碼;BM25 懂精確關鍵字、弱在同義改寫。並聯兩者就是 hybrid 的核心價值。
- 融合要用 RRF 而非直接加分:dense 的相似度和 BM25 分數尺度不相容,RRF 只看 rank(貢獻為 1/(k+rank)),迴避校準地雷、開箱即用。
- 記住那條疊加曲線:hybrid + RRF + rerank 在金融基準 Recall@5 約 0.816,對純 dense 的 0.587 提升近四成;WANDS 上 hybrid 的 NDCG 比單一方法高約 7.4%。
- 分工而非取代:hybrid 衝 recall(撈得齊)、cross-encoder reranking 衝 precision(排得準),正好延續昨天的兩段式思路。
- 檢索前先改寫查詢:對話式改寫補齊代詞與省略;多跳問題才做 query decomposition,簡單查詢別亂拆,否則徒增雜訊與延遲。
- hybrid 是最低可行基準,不是終點;先把它與 reranking、評估迴路建穩,再考慮 GraphRAG 或 agentic 這類更重的架構。
✍️ 實踐
替你現有的向量檢索加一路 BM25,並用 RRF 融合,做一次直接對照。多數向量資料庫(如 Weaviate、Qdrant、Elasticsearch/OpenSearch)都內建 BM25 與 hybrid 查詢,不必自己實作;先讓 dense 與 BM25 各自回傳 top-20,再用 RRF(k 取 60 是常見預設)融合成一份候選清單。
接著把這份 hybrid 候選丟進昨天已經建好的那份 30 到 50 題最小評估集,分別跑「純向量」與「hybrid+RRF」兩次,只比 context recall 這一個數字。你要看的訊號是:那些含專有名詞、型號、代碼、罕見詞的題目,recall 應該明顯上升;若整體 recall 沒動,通常代表你的查詢多半是語意型、字面命中不是瓶頸,那就把力氣留給 chunking 或 embedding。最後再把昨天的 cross-encoder reranker 接在 hybrid 之後跑第三次,確認 precision 與 faithfulness 是否如預期再往上——這樣你就親手驗證了「hybrid 衝 recall、rerank 衝 precision」的完整分工。
🔗 延伸學習
- Hybrid Search: BM25, Vector & Reranking Reference 2026 (Digital Applied)
- Hybrid Search and Re-ranking in Production RAG 2026: BM25, Dense, Cross-encoders, Fusion (AppScale)
- From BM25 to Corrective RAG: Benchmarking Retrieval Strategies for Text-and-Table Documents (arXiv)
- RAG in Production 2026: GraphRAG, Hybrid Retrieval, and Evals (AI Learning Guides)
💬 問 AI
我有一套 RAG 系統,目前只用向量檢索,想升級成 hybrid 檢索。請幫我:
1. 說明 dense 向量與 BM25 各自的失敗模式,以及哪些類型的查詢(專有名詞、型號、代碼、同義改寫)適合哪一路;
2. 解釋為什麼要用 Reciprocal Rank Fusion (RRF) 融合而不是直接把兩邊分數相加,並給我 RRF 的公式與常見的 k 值;
3. 給我一個具體步驟:如何在(我的向量庫,例如 Qdrant / Weaviate / OpenSearch)上同時跑 dense 與 BM25、用 RRF 融合成 top-k;
4. 說明什麼時候該在檢索前做 conversational query rewriting 或 query decomposition,什麼時候不該拆(避免對簡單查詢過度分解);
5. 給我一份用既有評估集比較「純向量 vs hybrid vs hybrid+rerank」的實驗設計,只聚焦 context recall 與 faithfulness 兩個指標。
請用我能直接照做的清單形式回答。