總覽:為什麼純向量不夠
混合檢索與 Reranking 解決什麼痛、在 RAG 品質調校版圖中的座標——不是「換搜尋引擎」,而是「把候選撈準、排準」。
Chunk 切對、Top-k 設穩之後,下一層品質瓶頸常是召回通道太單一:純向量(Dense Retrieval)擅長語意近義,卻容易漏掉精確字串——型號 SKU-8841、錯誤碼 E_TIMEOUT_42、專有名詞拼寫。關鍵字檢索(BM25 / Sparse)剛好相反:字面對了就高分,換句話說就掉分。
• Search & Analytics Engine:倒排索引、分片、近即時可搜——講的是引擎本身怎麼建、怎麼 scale。
• 本篇:在既有向量庫 + 關鍵字索引之上,做檢索品質調校——Hybrid 融合、RRF、retrieve-then-rerank。
兩者互補:引擎決定「能不能搜、搜多快」;混合與精排決定「搜得準不準」。
Dense 與 Sparse:互補而非取代
向量找「意思像」;BM25 找「字面中」。混合的前提是承認兩路各有盲區。
- 近義、改寫、跨語言語意近鄰強。
- 對稀有 ID、錯誤碼、嚴格拼寫弱。
- 分數多為相似度,跨 query 難直接解讀為「相關機率」。
- 精確 token、專有名詞、條款編號強。
- 同義改寫、語序變化易漏召回。
- 分數依賴詞頻與文件長度歸一,與向量分不可硬加。
| 查詢類型 | Dense 傾向 | Sparse 傾向 | 混合價值 |
|---|---|---|---|
| 「可以退貨嗎、要原包裝嗎」 | 高(語意對上政策段) | 中(看關鍵詞覆蓋) | 穩定召回政策敘述 |
| 「E_TIMEOUT_42 怎麼處理」 | 低~中(易被近義雜訊蓋過) | 高(字面命中) | 關鍵字救場 |
| 「跟上次一樣的鑑賞期」 | 高(指代/改寫) | 低(缺字面錨) | 向量救場 |
實務上兩路各取 Top-N(常 20–100),再融合;不要假設「只加大向量 k」能補精確字串。
Embedding 再強,對罕見 ID 與嚴格字串仍常輸給倒排索引。混合不是過渡方案,而是對兩種資訊需求的長期架構。
分數融合與 RRF
兩路分數尺度不同;用名次融合(尤其 RRF)通常比硬加權原始分更穩。
Weighted sum 需要先把兩路分數正規化(min-max、z-score),再選 α:
α 對語料與查詢分布敏感,離線調參成本高,且正規化窗口一換,排序就漂。
Reciprocal Rank Fusion(RRF) 不看原始分,只看各路名次 rank:
常數 k(常見 60)壓制極端第一名的主導;文件只要在多路都進榜,融合分就會被抬升——這正是「兩路都說它相關」時想要的行為。
- 無需對齊分數尺度。
- 實作簡單,線上行為可解釋(看各路 rank)。
- 對單路偶發高分雜訊較有韌性。
- 單路完全沒命中 → 融合也救不回(先加大各路 N)。
- 兩路都排錯 → RRF 只是「錯得一致」。
- 融合後 Top 仍可能平庸 → 交給 Reranker。
面試與上線第一版優先講 RRF:少超參、少校正地獄。若有穩定標註與足夠流量,再評估 learning-to-rank 或可學 α;不要一開始就上複雜融合模型。
Retrieve then Rerank
第一階段求召回(快、寬);第二階段求精準(慢、貴、只打小集合)。
典型:N≈50–100 進 reranker;最終 k≈3–8 進 LLM Context。
- Query 與文件一起編碼,交互特徵強,精排品質通常優於 bi-encoder。
- 延遲與成本隨候選數線性成長——故不能對全庫跑。
- 適合作為第二階段,不是第一階段召回器。
- 無精排時放大 k,雜訊段稀釋注意力。
- Token 成本上升,Faithfulness 未必升。
- Rerank 把「該讀的」抬到前面,比盲目加長 Context 划算。
| 取捨軸 | 只 Hybrid 融合 | Hybrid + Rerank |
|---|---|---|
| 延遲 | 低(兩路 ANN/倒排 + 融合) | 較高(多一次模型推論) |
| 成本 | 低 | 隨候選數與模型大小上升 |
| 排序品質 | 中~高(看融合) | 通常更高(小集合精排) |
| 適用 | 延遲預算緊、語料乾淨 | 答案敏感、雜訊多、要穩 Top-3 |
精排只能重排已召回的文件。金標若兩路都未進 Top-N,rerank 無效——此時應回頭加寬召回、修 chunk/metadata,或檢查稀疏索引是否覆蓋該欄位。
互動 · 純向量 vs 混合 vs Rerank
同一個問題、同一份語料,三條管線排出三種名次。改問題、標金標、調召回寬度與 rerank 深度,三欄即時重算。
按任一段前面的 ★ 可以把它標成/取消金標——金標是你給的答案定義,右邊每一欄的 Recall 都是照它算出來的。
一條線就是一段文件,縱軸是名次(愈上面愈前面)。線往上走代表那個階段把它抬起來;在第二欄斷掉代表它根本沒進候選池——那種情況 rerank 再強也救不回來。
三欄同題同語料,差別只在排序邏輯:Recall@k 看的是「該讀的有沒有進 Context」,金標最高名次看的是「要翻多少筆才看得到」。
分數拆解:BM25 那欄為 0 代表這段完全沒有任何 query 詞;cosine 那欄高但 BM25 為 0 的,就是純向量會抬起來的語意雜訊。
調校清單與觀測指標
不動生成模型,先把召回寬度、融合與精排預算調穩;用檢索指標而非只看最終答案。
| 旋鈕 | 常見起點 | 觀察訊號 |
|---|---|---|
| 各路 Top-N | 20–100(有 rerank 可偏大) | 金標常在榜外 → 先加寬,不是先換 reranker |
| 融合 | RRF,k=60 | 單路分數主導、正規化敏感 → 改名次融合 |
| Rerank 候選數 | 30–80 | 延遲爆 → 縮小候選或換較小 cross-encoder |
| 最終 Top-k | 3–8 進 Context | Faithfulness 差但檢索指標好 → 查生成;反之查召回 |
| 離線指標 | Recall@N、MRR、nDCG@k | 只看答案分數會掩蓋「根本沒撈到」 |
本篇把「管線旋鈕」講清;是否真的變好,請用 RAG Evaluation 的 Recall/Faithfulness 拆開量。混合與 rerank 的回歸集,務必包含精確 ID/錯誤碼與純語意改寫兩類問句,否則會調歪。
面試折衷與實務清單
能畫出「兩路召回 → 融合 → 精排」,並講清延遲/成本/品質取捨,就比只說「我們有用 hybrid」更有說服力。
| 決策點 | 一端做法 | 另一端做法 | 留意 |
|---|---|---|---|
| 召回策略 | 只 Dense | Dense + BM25 | 有精確字串需求就不要只 Dense |
| 融合 | 加權原始分 | RRF / 名次融合 | 尺度未對齊時加權很脆 |
| 精排 | 融合後直接 Top-k | Cross-encoder rerank | 延遲預算與候選數要一起談 |
| 除錯單位 | 只看最終答案 | 看各路 rank + 融合後序 | 分不清「沒召回」還是「排錯」 |
(1)一組「錯誤碼/SKU/條款編號」金標問句;(2)一組純語意改寫問句;(3)儀表板同時看各路 Recall@N 與 rerank 後 nDCG@k。這三樣能快速定位是稀疏索引、融合,還是精排模型的問題。