把整篇文件壓成一顆向量,再拿一顆查詢向量去比對——這是過去五年 RAG 檢索的預設做法,也是很多系統召回率上不去的根源。多向量檢索(multi-vector retrieval)與它背後的「後期互動」(late interaction)機制,提供了另一條路:不把資訊硬擠進單一向量,而是保留每個 token 的細節,在查詢時才做細粒度比對。這條路一直因為又慢又佔空間而被擋在生產環境門外,直到 MUVERA 這類技術把它的延遲壓下來,2026 年才真正開始被主流檢索堆疊採用。
📖 學(核心)
單向量檢索的天花板
主流的稠密檢索(dense retrieval)用的是「雙編碼器」(bi-encoder)架構:把整篇文件丟進編碼器,取一個彙總後的向量(常是 CLS token 或平均池化)代表整篇文件;查詢也編成一顆向量,兩者算餘弦相似度。這種做法的最大優點是可以離線預先算好所有文件向量,查詢時只要做一次近似最近鄰(ANN)搜尋就好,速度快、規模好擴展,也是所有向量資料庫的基礎。
問題在於「資訊壓縮」。把一整段動輒數百 token 的文字塞進一顆 768 或 1024 維的向量,細節必然被抹平。當查詢的關鍵詞只對應到文件裡某一小段落、某個專有名詞時,這個訊號在池化過程中會被稀釋掉,導致該召回的文件排不上來。學界稱這是單向量表示的「資訊瓶頸」——你不可能用固定容量的向量,無損地表示任意長度、任意主題密度的文件。
後期互動(late interaction)與 ColBERT
ColBERT(Contextualized Late Interaction over BERT)由 Khattab 與 Zaharia 提出,換了一個完全不同的思路:不要一篇文件一顆向量,而是「一個 token 一顆向量」。文件經過編碼後,保留每個 token 的上下文化向量;查詢也一樣,每個查詢 token 都有自己的向量。
相似度的算法叫 MaxSim:對每一個查詢 token,去文件所有 token 向量裡找出跟它最相似的那一顆,取這個最大相似度值;再把所有查詢 token 的最大相似度加總,就是查詢與文件的分數。直覺上,這是在問「我這個查詢裡的每一個概念,在文件裡都能不能找到最貼近的對應點?」——這比「兩顆彙總向量像不像」細緻太多,尤其擅長處理專有名詞、長尾詞彙、以及需要精確詞對應的情境。
之所以叫「後期」互動,是相對於交叉編碼器(cross-encoder)的「早期」互動。交叉編碼器把查詢和文件拼在一起同時進 Transformer,讓兩者從第一層就互相注意,精度最高,但因為要為每個「查詢×文件」組合重新跑一次模型,完全無法預先計算,只能用在最後對少數候選重排。ColBERT 的巧妙之處是把互動延後到最後那一步 MaxSim:文件的 token 向量可以離線算好、存起來重複使用,查詢時只做便宜的向量比對,於是同時拿到了「接近交叉編碼器的精度」與「接近雙編碼器的可預算性」。
代價:儲存與延遲
後期互動的帳單很現實。一篇文件不再是一顆向量,而是幾百顆 token 向量,即使做了量化壓縮,索引體積仍比單向量方案大上一個數量級。查詢時的 MaxSim 也不是一次 ANN 就能搞定——它是集合對集合的比對,傳統向量資料庫的單向量最近鄰索引沒辦法直接加速這種運算,天真的實作等於要把候選文件的所有 token 向量都拉出來算,延遲高到難以接受。這正是為什麼 ColBERT 概念從 2020 年就有,卻長期停留在論文和研究原型階段,遲遲進不了大規模生產系統。
MUVERA:把多向量搜尋還原成單向量搜尋
MUVERA(Multi-Vector Retrieval via Fixed Dimensional Encodings)是 Google 團隊提出、並在 2026 年持續更新的關鍵突破。它的核心點子是「固定維度編碼」(Fixed Dimensional Encoding, FDE):用一種資料無關的隨機空間分割(靈感來自局部敏感雜湊 LSH),把一篇文件那一整組 token 向量,轉換成單一一顆固定長度的向量,而且這顆向量的內積可以近似原本 MaxSim 的多向量相似度。
意義非常大:一旦文件和查詢都能各自被壓成一顆 FDE 向量,多向量檢索的第一階段召回就退化成「單向量最近鄰搜尋」——也就是說,可以直接沿用現成的 ANN 索引(如 FAISS)與現有的向量資料庫基礎設施,不必為多向量重新造輪子。實作上是兩階段:先用 FDE 做單向量 ANN 快速撈出候選,再對這批數量少很多的候選跑完整的 MaxSim 後期互動做精排。論文回報在 BEIR 系列基準上,平均召回率提升約 10%、延遲降低約 90%,而且要達到同樣召回,只需檢索 2 到 5 倍更少的候選。這是把後期互動從「研究玩具」推向「生產可用」的臨門一腳。
2026 年的落地版圖
模型端這幾年也成熟了不少。Jina 的 jina-colbert-v2 支援 89 種語言、可控輸出維度、8192 token 的長文件,把後期互動帶進多語與長文場景;BGE-M3 則走「一次前向就同時輸出稠密、稀疏、與 ColBERT 式 token 向量」的混合路線,讓你不必額外掛一顆 ColBERT 編碼器就能拿到多向量分數;Mixedbread 等廠商也把 ColBERT 風格的重排包成產品化服務。基礎設施端,主流向量資料庫陸續原生支援多向量欄位與 MaxSim/FDE 檢索,不再需要自己在應用層拼湊。
更值得注意的是多模態的延伸:ColPali、ColSmol 這類「視覺後期互動」模型,直接把文件頁面的截圖切成影像 patch、每個 patch 一顆向量,搭配 MUVERA 的 FDE 做 ANN、再用 MaxSim 精排,能在不做 OCR、不拆版面的情況下,對 PDF、投影片、表格這類「看得懂但難解析」的文件做次秒級檢索。這對企業內部大量存在的掃描件、報表、簡報,是傳統文字 RAG 一直啃不動的硬骨頭。
該怎麼選:三種互動的取捨
實務上不必二選一,而是分層。第一階段召回用單向量雙編碼器或 FDE,追求速度與規模;第二階段精排,如果精度要求高、候選量已縮小,就上後期互動(ColBERT/MaxSim)或直接用交叉編碼器重排。一個常見誤解是「有了多向量就不需要重排器」——其實後期互動本身就是一種輕量的重排機制,它填補的正是「單向量召回不夠準」與「交叉編碼器太貴」之間的空檔。真正要問的是:你的失敗案例是「該找的文件根本沒被召回」(召回問題,考慮多向量),還是「召回了但排序不對」(排序問題,考慮重排器),對症下藥比盲目換架構重要得多。
🧠 記
- 單向量稠密檢索把整篇文件壓成一顆向量,查詢快、易擴展,但有「資訊瓶頸」,細節與長尾詞訊號會被池化抹平。
- 後期互動(late interaction)保留每個 token 一顆向量,用 MaxSim(逐查詢 token 取最大相似度再加總)算分,細粒度遠勝單向量。
- ColBERT 是後期互動的代表,兼顧「接近交叉編碼器的精度」與「文件向量可離線預算」的效率,關鍵在把互動延後到最後一步。
- 交叉編碼器(早期互動)精度最高但無法預算,只能對少量候選重排;三種互動是速度與精度的光譜,不是互斥選項。
- 後期互動的代價是儲存暴增(一篇文件變幾百顆向量)與延遲高(集合對集合比對,傳統 ANN 無法直接加速)。
- MUVERA 用固定維度編碼(FDE)把多向量相似度近似成單向量內積,讓第一階段召回退化成普通 ANN,可直接沿用 FAISS 等既有設施。
- 2026 年落地成熟:jina-colbert-v2(多語長文)、BGE-M3(單次前向輸出多種向量)、ColPali/ColSmol(視覺後期互動,免 OCR 檢索 PDF/簡報)。
- 選型要分層診斷:召回不足才考慮多向量,排序不準才考慮重排器;後期互動本身就是介於稠密召回與交叉編碼器之間的輕量重排。
✍️ 實踐
- 找一批你手上 RAG 系統召回失敗的真實查詢(該找到卻沒找到的),標出失敗的是「沒召回」還是「排序錯」,先確認問題屬於召回還是排序。
- 用 jina-colbert-v2 或 BGE-M3 對同一組查詢與文件,分別跑「單向量稠密檢索」與「ColBERT 後期互動」,比較兩者在你的資料上的召回率差異。
- 動手算一次 MaxSim:拿一個查詢的幾個 token 向量與一篇文件的 token 向量,手動(或用幾行 numpy)找每個查詢 token 的最大相似度並加總,把後期互動的機制內化成直覺。
- 建一條兩階段管線:第一階段用單向量 ANN 撈 top-100 候選,第二階段用 ColBERT MaxSim 或交叉編碼器重排到 top-5,量測端到端延遲與答案品質。
- 若資料裡有大量 PDF、簡報、掃描件,試裝一個 ColPali/ColSmol 視覺後期互動模型,對「頁面截圖」直接檢索,對照傳統「OCR 後切塊」流程的召回差異。
- 讀 MUVERA 論文中 FDE 的兩階段流程圖,寫下「為什麼把多向量壓成單向量後,就能重用既有向量資料庫」這句話的完整因果,確認自己真的理解而非背名詞。
🔗 延伸學習
- MUVERA: Multi-Vector Retrieval via Fixed Dimensional Encodings(arXiv 論文)
- ColBERT:Token 級嵌入與排序模型解析(Zilliz Learn)
- jina-colbert-v2:多語後期互動檢索模型(Jina AI)
- ColBERT 後期互動實作文件(Mixedbread)
💬 問 AI
我正在改進一套 RAG 檢索系統,目前用的是單向量稠密檢索,遇到的問題是:{描述你的召回或排序問題,例如「專有名詞查詢常常找不到對的文件」}。
我的資料特性是:{文件類型/語言/平均長度/資料量,例如「繁體中文法規條文,數萬篇,每篇約 800 字」}。
請幫我判斷:
1. 這個問題比較可能是「召回不足」還是「排序不準」?依據是什麼?
2. 針對我的情況,後期互動(ColBERT/多向量)與加一顆重排器(reranker),哪個更該先試?為什麼?
3. 如果要導入後期互動,MUVERA 的 FDE 兩階段管線該怎麼設計?第一階段撈幾個候選、第二階段用什麼精排?
4. 儲存與延遲成本會如何變化?有沒有量化或壓縮的折衷做法?
請用我的資料規模給出具體的參數建議,而不是通則。