Cascading Retrieval：用多向量中間層平衡 RAG 搜尋的速度與準確率

RAG Retrieval Architecture · Pinecone / ConstBERT

Cascading Retrieval：用多階段檢索把速度、成本與準確率拆開最佳化

Pinecone 這篇文章的核心不是「多向量一定比較強」，而是把 retrieval pipeline 拆成可控的瀑布式架構：第一階段用稀疏/密集檢索快速撈高召回候選，第二階段用多向量 late interaction 精煉排序，最後才把少量高品質候選交給昂貴的 cross-encoder reranker。這是大規模 RAG 系統很實用的成本/品質折衷模型。

問題

單向量 dense retrieval 速度快、成本低，但容易把文件壓縮得太粗；cross-encoder reranker 準確但昂貴，不能直接吃大量候選。

中間層

多向量模型保留 token / phrase 級互動，透過 late interaction 做更細的相關性評分，成為單向量檢索與 cross-encoder 之間的 missing middle layer。

ConstBERT

ConstBERT 用固定數量向量表示每份文件，例如 32、64、128 vectors，而不是像傳統 ColBERT 依 token 數產生可變長向量，讓儲存、cache locality 與批次處理更容易。

Pinecone 實作路線

文章示範把 ConstBERT embeddings 以 metadata 存在既有 Pinecone index，先用一般向量查 top-k，再取 metadata 做 MaxSim rerank。

架構重點：不要把 retrieval 想成一個模型一次決勝負，而是讓每一層只做自己最擅長的事：便宜模型擴大召回、較貴模型縮小候選、更貴模型只處理最後少量候選。這比單純「向量搜尋 + rerank」更可控。

階段	典型模型 / 方法	目標	候選數示例
Stage 1：快速召回	BM25 / sparse retrieval / dense single-vector	從大 corpus 找出可能相關文件，優先 recall 與速度	約 1,000 筆
Stage 2：多向量精煉	ColBERT、ConstBERT、ColPali 類 late interaction	用更細粒度 query-document interaction 過濾低品質候選	約 100 筆
Stage 3：高精度 rerank	Cross-encoder reranker	對少量候選做完整 query-document attention，產生最終排序	約 top 10
Stage 4：生成	LLM / RAG answer synthesis	只把最相關內容交給模型生成答案	依 context budget 決定

為什麼傳統 ColBERT 難 scale

每份文件有 T 個 token 就可能產生 T 個向量；文件長度不同會造成儲存不可預測、記憶體隨機存取、query-time 計算量增加，對大型 corpus 特別不友善。

ConstBERT 的固定空間優勢

固定向量數讓所有文件 storage size 更一致，可改善 index 管理、cache-friendly memory layout、SIMD/AVX 類硬體最佳化與 batch processing。

metadata reranking 的實務性

把 multi-vector embedding 存成 metadata 可避免另建一套 multi-vector index，也減少額外 API round trip；缺點是 metadata 不是為高速多向量查找設計，會增加儲存與查詢開銷。

MaxSim

文章示範用 MaxSim scoring：計算 query vectors 與 document vectors 的 dot product，對每個 query vector 取最大匹配，再加總成多向量相關分數。

方法	可預先計算	大規模效率	準確率	適合位置
Sparse / BM25	高	高	中	第一階段召回，尤其保留關鍵字精準匹配
Dense single-vector	高	高	中到高	第一階段語意召回
Multi-vector late interaction	文件端可預算	中到高	高	第二階段 rerank / candidate refinement
Cross-encoder	低	低	最高	最後階段，只處理少量候選

Benchmark takeaway：Pinecone 文中評估顯示 ConstBERT 作為 reranker 最有價值。在 MSMARCO TREC DL19/DL20 上，ConstBERT reranking 接近 ColBERT end-to-end；在 BEIR 12 平均 nDCG@10 中，ConstBERT reranking 也高於 ConstBERT end-to-end。重點不是拿 multi-vector 當唯一 retrieval engine，而是把它放在瀑布式 pipeline 的第二層。

導入到 RAG / 搜尋系統時的設計清單

先定義 latency budget：使用者能接受 100ms、500ms，還是數秒？每一層候選數要反推。
第一階段不要只依賴 dense retrieval；很多企業文件、程式碼、產品資料仍需要 sparse / keyword signal。
第二階段 multi-vector rerank 適合拿來融合 sparse + dense 候選，降低交給 cross-encoder 的候選量。
metadata-based multi-vector 是簡化架構的方式，但要測 storage cost、response payload、metadata decode 與 query-time rerank 成本。
如果文件很長或 noise 很多，多向量比單向量更有機會抓到局部相關段落；如果文件短且 query 簡單，收益可能有限。
不要只看 nDCG；也要量 P95/P99 latency、索引大小、更新成本、冷 cache 行為與 reranker failure mode。

對 agent / RAG 產品的實用判斷：當 RAG 答案品質卡在「撈到的 chunk 不夠準」時，通常不要直接把更多 chunk 丟給 LLM。更好的方向是把 retrieval pipeline 分層，讓 multi-vector rerank 在 LLM 前先做 candidate purification，最後才讓 LLM 處理更小、更乾淨的 context set。

Sources
Pinecone Blog: Cascading retrieval with multi-vector representations: balancing efficiency and effectiveness
Authors: Cesare Campagnano、Antonio Mallia、Jack Pertschuk；published 2025-05-28。
Key terms checked from source: multi-vector retrieval, ConstBERT, fixed-size document representations, metadata-based reranking, MaxSim, ColBERT, cross-encoder reranking, MSMARCO, BEIR 12。