延遲交互模型，為什麼是下一代RAG的標配？
- WBOY原創
- 2024-08-05 20:15:221182瀏覽
AIxiv專欄是本站發布學術、技術內容的欄位。過去數年，本站AIxiv專欄接收通報了2,000多篇內容，涵蓋全球各大專院校與企業的頂尖實驗室，有效促進了學術交流與傳播。如果您有優秀的工作想要分享，歡迎投稿或聯絡報道。投稿信箱：liyazhou@jiqizhixin.com；zhaoyunfeng@jiqizhixin.com
張穎峰：英飛流聯合創始人，多年搜尋、AI、Infra基礎設施開發經歷，目前基礎設施開發，目前正致力於下一代RAG 核心產品建置。
在RAG 系統開發中，良好的Reranker 模型處於必不可少的環節，也總是被拿來放到各類評測當中，這是因為以向量搜尋為代表的查詢，會面臨命中率低的問題，因此需要高階的Reranker 模型來補救，這樣就構成了以向量搜尋為粗篩，以Reranker 模型作精排的兩階段排序架構。
目前排序模型的架構主要有兩類：
1. 雙編碼器。以 BERT 模型為例，它針對查詢和文件分別編碼，最後經過一個 Pooling 層，使得輸出只包含一個向量。在查詢時的 Ranking 階段，只需要計算兩個向量相似度即可，如下圖所示。雙編碼器既可以用於 Ranking 也可以用於 Reranking 階段，向量搜尋其實就是這種排序模型。由於雙編碼器針對查詢和文件分別編碼，因此無法捕獲查詢和文件的Token 之間的複雜交互關係，在語義上會有很多損耗，但由於只需要向量搜尋即可完成排序打分計算，因此執行效率非常高。
2. 交叉編碼器（Cross Encoder）。 Cross-Encoder 使用單一編碼器模型來同時編碼查詢和文檔，它能夠捕捉查詢和文檔之間的複雜交互關係，因此能夠提供更精準的搜尋排序結果。 Cross-Encoder 不會輸出查詢和文件的 Token 所對應的向量，而是再增加一個分類器直接輸出查詢和文件的相似度分數。它的缺點在於，由於需要在查詢時對每個文件和查詢共同編碼，這使得排序的速度非常慢，因此 Cross-Encoder 只能用於最終結果的重新排序。例如針對初篩結果的 Top 10 做重排序，仍然需要耗時秒級才可以完成。
今年以來，另一類以ColBERT【參考文獻1】 為代表的工作，在RAG 開發社區引起了廣泛關注，如下圖所示，它具備一些顯著區分於上述兩類排序模型的特點：
其一是相比於Cross Encoder，ColBERT 仍採用雙編碼器策略，將查詢和文件分別採用獨立的編碼器編碼，因此查詢的Token和文件的Token 在編碼時互不影響，這種分離使得文檔編碼可以離線處理，查詢時僅針對Query 編碼，因此處理的速度大大高於Cross Encoder；
其二是相比於雙編碼器，ColBERT 輸出的是多向量而非單向量，這是從Transformer 的最後輸出層直接獲得的，而雙編碼器則透過一個Pooling 層把多個向量轉成一個向量輸出，因此丟失了部分語義。
在排序計算時，ColBERT 引入了延遲交互計算相似度函數，並將其命名為最大相似性（MaxSim），計算方法如下：對於每個查詢Token 的向量都要與所有文檔Token對應的向量進行相似度計算，並追蹤每個查詢Token 的最大得分。查詢和文件的總分就是這些最大餘弦分數的總和。例如對於一個有 32 個 Token 向量的查詢（最大查詢長度為 32）和一個有 128 個 Token 的文檔，需要執行 32*128 次相似性操作，如下圖所示。
因此相較之下， Cross Encoder 可以稱作早期交互模型（Early Interaction Model），而以ColBERT 為代表的工作可稱為延遲交互模型（Late Interaction Model）。
為此，我們需要考慮ColBERT 工程化的一些問題：
1. ColBERT 的MaxSim 延遲交互相似度函數，計算效率大大高於Cross Encoder，但相比普通向量搜索，計算開銷仍然很大：因為查詢和文檔之間的相似度，是多向量計算，因此MaxSim 的開銷是普通向量相似度計算的M * N 倍（ M 為查詢的Token 數， N 為文檔的Token 數）。針對這些，ColBERT 作者在2021 年推出了ColBERT v2 【參考文獻2】，透過Cross Encoder 和模型蒸餾，改進了生成的Embedding 質量，並且採用壓縮技術，對生成的文檔向量進行量化，從而改善MaxSim 的計算性能。基於 ColBERT v2 包裝的專案 RAGatouille 【參考文獻 3】成為高品質 RAG 排序的解決方案。然而，ColBERT v2 只是一個演算法庫，端到端的讓它在企業級 RAG 系統使用，仍然是一件困難的事情。
2. 由於ColBERT 是預訓練模型，而訓練資料來自於搜尋引擎的查詢和返回結果，這些文字資料並不大，例如查詢Token 數32 ， 文檔Token 數128 是典型的長度限制。因此將 ColBERT 用於真實資料時， 超過限制的長度會被截斷，這對於長文檔檢索並不友善。
基於上述問題， 開源 AI 原生資料庫 Infinity 在最新版本中提供了 Tensor 資料類型，並原生地提供端到端的 ColBERT 方案。當 Tensor 作為一種資料類型，ColBERT 編碼輸出的多個向量，就可以直接用一個 Tensor 來存放，因此 Tensor 之間的相似度就可以直接得到 MaxSim 評分。針對MaxSim 計算量大的問題，Infinity 給了2 個方案來優化：其一種是binary 量化，它可以讓原始Tensor 的空間只需原始尺寸的1/32 ， 但並不會改變MaxSim 計算的相對排序結果。此方案主要用於 Reranker，因為需要根據前一階段粗篩的結果取出對應的 Tensor 。另一種是Tensor Index，ColBERTv2 其實就是ColBERT 作者推出的Tensor Index 實現，Infinity 採用的則是EMVB【參考文獻4】，它可以看作是ColBERT v2 的改進，主要透過量化和預過濾技術，並在關鍵操作上引入SIMD 指令來加速實現。 Tensor Index 只能用來服務 Ranker 而非 Reranker。此外，針對超過Token 限制的長文本，Infinity 引入了Tensor Array 類型：
一篇超過ColBERT 限制的文檔，會被切分成多個段落，分別編碼產生Tensor 後，都跟著原始文檔保存在一行中。計算 MaxSim 的時候，查詢跟著這些段落分別計算，然後取最大值作為整個文件的評分。如下圖所示：
因此，採用 Infinity，可以端到端地引入延遲交互模型高品質地服務 RAG。那麼，應該是採用 ColBERT 作為 Ranker ，還是 Reranker 呢？下邊我們採用 Infinity 來在真實資料集上進行評測。由於Infinity 的最新版本實現了有史以來最全的混合搜索方案，召回手段包含向量搜索、全文搜索、稀疏向量搜索，上文所述的Tensor ，以及這些手段的任意組合，並且提供了多種Reranker 手段，如RRF，以及ColBERT Reranker 等，因此我們在評測中包含了各種混合搜尋和Reranker 的組合。
我們採用 MLDR 資料集進行評測。 MLDR 是 MTEB 【參考文獻 5】用來評測 Embedding 模型品質的 benchmark 集，其中 MLDR 是其中一個資料集，全稱為 Multi Long Document Retrieval，一共包含 20 萬長篇文字資料。評測採用 BGE-M3【參考文獻 6】作為 Embedding 模型，採用 Jina-ColBERT 【參考文獻 7】來產生 Tensor，評測腳本也放到了 Infinity 倉庫【參考文獻 8】。
評測一：ColBERT 作為 Reranker 是否有效。 將20 萬MLDR 資料分別以BGE-M3 產生稠密向量和稀疏向量，並插入到Infinity 資料庫中，資料庫包含4 列，分別保存原始文本，向量，稀疏向量，以及Tensor，並分別建立對應全文索引、向量索引、稀疏向量索引。評測包含所有的召回組合，包含單路召回、雙路召回，以及三路召回，如下圖所示：
評測指標採用 nDCG@10。其他參數：採用 RRF Reranker 時粗篩回傳的 Top N = 1000 ，查詢累計共有 800 條，平均每個查詢長度在 10 個 token 左右。
從圖中看到，所有的召回方案，在採用了 ColBERT Reranker 之後，都有明顯的效果提升。 ColBERT 作為一種延遲交互模型，它可以提供跟在 MTEB 的 Reranker 排行榜上位居前列相提並論的排序質量，但是性能卻是它們的 100 倍，所以可以在更大的範圍內進行重排序。圖中給出的結果是針對 Top 100 進行 Reranker，而採用 Top 1000 進行 ColBERT 重排序，數值沒有明顯變化，效能還有明顯下降，因此不建議採用。傳統上採用基於Cross Encoder 的外部Reranker ，Top 10 就會有秒級的延遲，而Infinity 內部實現了高效能的ColBERT Reranker，即使針對Top 100 甚至Top 1000 做重排序，也不會影響用戶體驗，而召回的範圍卻大大增加，因此可以顯著改善最終的排序效果。此外，這種 ColBERT Reranker 運算只需在純 CPU 架構上即可運行，這也大大降低了部署的成本。
評測二：對比基於 ColBERT 作為 Ranker 而不是 Reranker。 因此，這時需要針對 Tensor 這列資料建構 Tensor Index。同時，為了評估 Tensor Index 引入的精確度損耗，也進行了暴力搜索。
因此，很顯然，ColBERT 作為 Reranker 的收益比作為 Ranker 要高得多。目前最佳的 RAG 檢索方案，是在 3 路混合搜尋（全文搜尋 + 向量 + 稀疏向量）的基礎上加 ColBERT Reranker。有夥伴可能會問了，為了採用 ColBERT Reranker，就需要增加單獨的 Tensor 列，並且該列會相比原始資料集膨脹 2 個數量級，這樣做是否值得？首先：Infinity 針對 Tensor 提供了 Binary 量化手段，作為 Reranker，它不會影響排序結果很多，但卻可以讓最終的數據僅有原始 Tensor 大小的 1/32。其次，即便如此，還是會有人認為這樣的開銷過高。然而站在使用者的視角，用更多的存儲，來換取更高的排序品質和更廉價的成本（排序過程無需 GPU），這樣做仍然是非常值得的。最後，相信很快就可以推出效果上略有下降，但存儲開銷大大降低的 Late Interaction 模型，作為一款 Data Infra 基礎設施， 對這些變化保持透明，把這些 Trade Off 交給用戶是明智的選擇。
以上是基於Infinity 在MLDR 資料集上的多路回溯評測，在其他資料集的評測結果，可能會有所不同，但整體上結論不會改變－ 3 路混合搜尋+ 基於Tensor 的重排序，是目前搜尋結果品質最高的召回手段。
由此可以看到，ColBERT 及其延遲交互模型，在RAG 場景具有很大的應用價值，以上是在文本對話內容生成的相關工作，近期，延遲交互模型在多模態場景，也得到了SOTA 的結果。這就是 ColPali【參考文獻 9】，它改變了 RAG 的工作流程，如下圖所示：
RAG 在面臨複雜格式文件時，當下的SOTA ，是採用文檔識別模型，對文檔的佈局做識別，並針對識別出的部分結構，例如圖表，圖片等，再分別調用相應的模型，將它們轉換為對應的文字，再用各種格式儲存到RAG 配套的資料庫中。而 ColPali 則省掉了這些步驟，它直接採用多模態模型產生 Embedding 內容。提問的時候，可以直接針對文檔中的圖表進行回答：
ColPali 模型的訓練跟ColBERT 類似，也是採用查詢- 文件頁對的形式，從而捕獲查詢和文檔多模態資料之間的語意關聯，只是採用PaliGemma 【參考文獻10】用來產生多模態Embedding 。相較於沒有採用 Late Interaction 機制但同樣採用 PaliGemma 產生 Embedding 的方案 BiPali，在 nDCG@5 的評測指標對比是 81.3 vs 58.8，這種差距是就是 “極好” 和 “壓根不能工作” 的區別。
因此，儘管ColBERT 出現至今已有4 年時間，可是Late Interaction 模型在RAG 的應用才剛開始，它必將擴大RAG 的使用場景，在包含多模態在內的複雜RAG 場景提供高品質的語義召回。而 Infinity 已經為它的端到端應用程式做好了準備，歡迎關注和 Star Infinity，https://github.com/infiniflow/infinity， 致力於成為最好的 AI 原生資料庫！
參考文獻
1. Colbert: Efficient and effective passage search via contextized 1. Colbert: Efficient and effective 密碼.
2. Colbertv2: Effective and efficient retrieval via lightweight late interaction, arXiv:2112.01488, 2021. 3. RAGatouille https://github.com/bclavie/RAGatouille
4. Efficient Multi-vector D:valprie ECIR 2024.
5. https://huggingface.co/mteb
6. https://huggingface.co/BAAI/bge-m3
7. https://huggingface.co/jinaai/jina-colbert-v1 -en
8. https://github.com/infiniflow/infinity/tree/main/python/benchmark/mldr_benchmark
9. ColPali: Efficient Document Retrieval with Vision Language Models, arXiv:2407.01449, 2024.
以上是延遲交互模型，為什麼是下一代RAG的標配？的詳細內容。更多資訊請關注PHP中文網其他相關文章！