所見即所得：多模態RAG正在向我們走來

作者 | 張穎峰

2024 年可以算得上是多模態大模型取得井噴的一年，5 月發佈的 GPT-4o，讓多模態大模型進一步走進了我們的視野，如果說在 2023 年，多模態的應用還停留在傳統的簡單圖像搜索，到 2024 年，則真正開始了對多模態數據的理解。下圖是 24 年涌現的多模態大模型代表，既有商業，也有開源。可以看到，從對圖像的理解角度來看，2024 年已經取得了長足進步。

隨之而來的，就是多模態 RAG，是否也會開始落地併產生價值？我們先來看看多模態 RAG 的都有哪些使用場景。所謂多模態 RAG 的概念並不稀罕 ，在 2023 年 RAG 概念剛火熱起來不久，就有了多模態 RAG 的場景描述，例如針對個人相冊，企業宣傳素材的搜索需求，然而，這種搜索需求更多是把存在很久的向量搜索的使用場景如圖像搜索、以圖搜圖等安插到了多模態 RAG 之上，並沒有真正從業務角度來逐步挖掘多模態 RAG 的場景價值。隨着 RAG 技術在 2024 年快速發展，更多的企業，已經把 RAG 看成是大模型在 B 端應用的標準配置。來自於企業內部的文檔問答，已經解鎖出大量使用需求和場景。在這些文檔中，有相當一部分包含各類複雜的圖表內容，它們本質上就是各種多模態數據，如何對這些數據進行有效問答，成了挖掘企業內部數據金礦的剛性需求來源之一。

針對這類數據，一種解決方案是採用視覺模型，利用廣義上的 OCR 技術，把這些多模態文檔的佈局首先識別出來，再根據不同語義區塊，調用相應的模型來做處理，如下圖所示。

這個流程中，得到的圖片和表格，都屬於典型的多模態數據，因此，採用相應的模型，將它們轉成文本數據，就解決了對多模態數據的理解問題。從原理上來說，這樣的技術也分爲 2 代：

第一代是採用各類視覺模型，針對不同類型的圖表數據分別進行訓練，將它們轉化爲文字。例如針對表格處理的，有表格識別模型，針對流程圖，餅圖柱狀圖等企業圖表，也需要相應的模型來處理。這些視覺模型，本質上是個分類模型。

第二代則採用生成式模型，不同於流行的 LLM 採用的 Decoder Only 架構，基於 Transformer 的多模態生成式模型，通常採用 Encoder-Decoder 架構，Encoder 的輸入端是各種圖表，Decoder 的輸出就是各類文本。

依託於這種廣義的 OCR 技術，可以把一個多模態 RAG 系統變成一個標準的 RAG 系統。在我們的開源和商業版的 RAGFlow 中，分別基於這兩類技術提供了相應的實現。

另一種解決方案，則直接依託於多模態模型本身，簡稱 VLM（Vision Language Model）。輸入文字和圖像，輸出得到基於圖像和文字內容理解得到的答案文字。

如前文所提到，VLM 在 2024 年取得了顯著進展，它們已經大大超越了過去圖像搜索這種簡單的場景。我們先以 Google 在 7 月開源的 PaliGemma 爲例，看看對一個複雜的多模態文檔理解的效果【參考資料 1】。上傳一張包含柱狀圖、餅圖以及各類文本的複雜 PDF 截圖，然後針對圖表進行提問，可以看到，PaliGemma 給出了準確的回答。

而近期阿里開源的 Qwen2-VL-7B【參考資料 2】，也在視覺圖像理解上達到了更好的效果。如何將這些 VLM 應用於針對大量企業內部 PDF 文檔的多模態 RAG，同樣是今年 7 月公開的 ColPali【參考資料 3】，則是一個堪稱里程碑的工作。ColPali，全稱叫 Contextualized Late Interaction over PaliGemma，是一個基於 PaliGemma 的延遲交互模型。PaliGemma 是一個結合了視覺和語言模型的混合模型，它使用 SigLIP 視覺編碼器生成的圖像塊 (Image Patch) Embedding，並將這些 Embedding 輸入到 Gemma 文本語言模型中，以獲得上下文化的語言模型輸出 Embedding。

而 ColPali 則在 PaliGemma 基礎上添加了一個 Col Adaptor，它負責將 PaliGemma 的 Embedding 輸出映射到一個更低維度（128 維）的向量空間，並採用延遲交互模型來計算文本和文檔之間的相似度。所謂 ColPali 的"Col"，跟最知名的用於文本排序的延遲交互模型 ColBERT，是一個含義，它是用來在 RAG 系統中解決文檔排序的一種標準方法的總稱。也就是說，我們可以在任何模型基礎之上來新增一個 Col Adaptor，同時輔之以訓練的正負樣本對數據，就可以得到各種 ColXX 模型，它們都是採用延遲交互模型，可以用來捕獲查詢和文檔之間的上下文相似度。

在 RAG 常用的排序模型中，主要有 3 類架構：

雙編碼器（Dual Encoder）。以 BERT 模型爲例，它針對查詢和文檔分別編碼，最後再經過一個 Pooling 層，使得輸出僅包含一個向量。在排序階段，只需要計算兩個向量相似度即可。由於雙編碼器針對查詢和文檔分別編碼，因此無法捕獲查詢和文檔的 Token 之間的複雜交互關係，在語義上會有很多損耗。

交叉編碼器（Cross Encoder）。Cross-Encoder 使用單編碼器模型來同時編碼查詢和文檔，它能夠捕捉查詢和文檔之間的複雜交互關係，因此能夠提供更精準的搜索排序結果。Cross-Encoder 並不輸出查詢和文檔的 Token 所對應的向量，而是再添加一個分類器直接輸出查詢和文檔的相似度得分。它的缺點在於，由於需要在查詢時對每個文檔和查詢共同編碼，這使得排序的速度非常慢，因此 Cross-Encoder 只能用於最終結果的重排序。例如針對初篩結果的 Top 10 做重排序，仍然需要耗時秒級纔可以完成。

延遲交互編碼器（Late Interaction Encoder）。以 ColBERT 爲例，相比於交叉編碼器，ColBERT 仍採用雙編碼器策略，將查詢和文檔分別採用獨立的編碼器編碼，因此查詢的 Token 和文檔的 Token 在編碼時互不影響，這種分離使得文檔編碼可以離線處理，查詢時僅針對 Query 編碼，因此處理的速度大大高於交叉編碼器，這樣帶來的好處就是延遲交互編碼，可以放到數據庫內部執行，不僅可以大大降低成本，更重要在於它可以針對更多的文檔排序（例如 Top 100 甚至 Top 1000），從而大大提升最終的查詢精度；相比於雙編碼器，ColBERT 輸出的是多向量而非單向量，這是從 Transformer 的最後輸出層直接獲得的，而雙編碼器則通過一個 Pooling 層把多個向量轉成一個向量輸出，因此丟失了部分語義。

延遲交互編碼器，是面向未來的 RAG 排序模型，它既有交叉編碼器的排序質量，又具備較高的性能，解決了 RAG 檢索過程中語義損耗的問題。正因爲此，ColPali 算是延遲交互編碼器在多模態 RAG 檢索的應用，它的出現，對於提升多模態 RAG 的檢索精度，具有顯著的價值。下圖是 ColPali 在文章中對比採用傳統視覺模型的廣義 OCR 實現的多模態 RAG，可以看到在查詢精度上，領先優勢很大。甚至在整體的數據寫入速度上，也大大領先。

下圖是 ColPali，對比不採用延遲交互模型的 BiPali（就是採用雙編碼器的 PaliGemma，對查詢和文檔分別用 PaliGemma 編碼），在查詢精度上的領先優勢：平均 nDCG 從 50 多到 80 多，這在產品上幾乎就是可用和不可用之間的差異。

隨着 ColPali 的出現，更多的將延遲交互模型用於多模態 RAG 檢索的模型也出現了，例如將 Col Adaptor 用於 Qwen2-VL-2B 的 ColQwen2，在 ViDoRe Benchmark 榜單上，近期已經跑到了第一名，它的平均 nDCG 指標，比 ColPali 還領先了 5 個百分點。ViDoRe，全稱是 Visual Document Retrieval Benchmark，類似適用於標準 RAG 的 MTEB Benchmark，ViDoRe 可看作是多模態 RAG 的 MTEB。下圖是 ViDoRe 的典型評測樣本：

並且可以看到，在 ViDoRe Benchmark 上，排名前列的模型，全都是延遲交互模型：

那麼如何將 ColPali，應用到企業級的多模態文檔知識庫系統中呢？我們先來看 ColPali 模型，它會把每張圖片，具體來說，就是 PDF 的某一頁，看作是 32*32=1024 個 Image Patches，每個 Patch 都會生成 128 維向量。因此，一頁圖片，就可以用這 1024 個向量來表示。在查詢的時候，查詢的每個 Token，也都會生成一個 128 維向量，根據 ColPali 模型，查詢和一頁圖片的相似度，是查詢每個 Token 的每個向量，跟所有 Patch 的向量之間內積之和的疊加，這就是 MaxSim。因此可以看到，我們需要這樣的基礎組件，來完成基於 ColPali 搜索的產品化：

需要有 Tensor 類型，就是多向量，來表示一頁。

需要有效的支撐 MaxSim 算法。MaxSim 的計算並不是難事，但由於 Tensor 類型的引入，它帶來 2 個問題：其一是 MaxSim 的查詢複雜度較高；其二是 Tensor 的空間複雜度很高。一頁 PDF 的 Tensor 需要 1024*128 = 128KB，對於大量的 PDF 來說，這是很高的空間開銷。

在實際使用中，我們發現，單純採用 ColPali，確實可以解讀圖表，但對於一些文本內容，仍然無法有效召回。因此，標準 RAG 所必備的能力：全文搜索和多路召回，仍然不可或缺。

在我們的開源 AI 原生數據庫 Infinity 中，就已經提供了以上支持，針對第二點，主要優化在於：

我們首先試驗了 Tensor Index 的必要性。在實現了 SOTA 的 Tensor Index 後，我們在文本排序上做了對比，發現 Tensor 類型，MaxSim 計算僅放在 Reranker 即可。下圖是在一個基於文本的排序評測上，分別對比了採用 Tensor Index，普通搜索 +Tensor Reranker，以及基於 Tensor 的暴搜，可以看到，基於 Tensor Reranker 的結果，甚至高於採用 Tensor Index。

基於以上結論，採用 Tensor Reranker 即可達到效果，而 Tensor Reranker 可以採用更多的優化空間，例如採用二值量化，也就是把向量的每個維度的浮點數，用一個 bit 來表示，這樣存儲空間可以降低爲原來的 1/32，同時計算複雜度也大大降低。

基於以上結論，採用 Tensor Reranker 來實現 MaxSim，那我們在前邊的粗篩，同樣離不開向量搜索。只是不同之處在於，我們需要這種向量搜索，也具備多向量的能力，意思是，向量搜索是以 Patch Embedding 爲單元，但我們期望返回的結果，是以 PDF Page 爲單元。

因此，採用 Infinity 數據庫，將可以很好的支持多模態 RAG。

以上我們提到了 2 種技術路線，一個是基於廣義 OCR，另一個是基於 VLM，分別用於實現多模態 RAG。那麼這兩種技術路線，哪種更有前景呢？在 ColPali 的論文中，已經給出了針對前者的比較，只是這種比較，主要是針對採用簡易的 OCR 技術。在【參考資料 4】中，也針對這兩種方法進行了對比，結論如下圖所示：

看起來似乎採用 ColPali 這樣的延遲交互模型，已經具備足夠的領先優勢。然而，在前文已經提到，即使是廣義的 OCR，也已經演進到了下一代基於 Transformer 的生成式模型架構，這在本質上跟 VLM 沒有區別，所不同的是，前者直接輸出文字，後者則輸出 Embedding，而對於網絡結構來說，都是 Encoder-Decoder 架構。面對企業級的多樣化需求，在查全和查準都要兼顧的前提下，我們很難說哪種一定會佔據優勢，因此，最佳的選擇是，兩者都要有：

在文字更容易表達，或者精確處理更加重要的場景，例如表格，我們可以採用更加準確的圖像直接生成文字的做法，把整個表格精準的還原，然後讓大模型準確回答問題。

在文字表達不容易，如其他圖表類場景，我們交給 VLM 來處理，這樣效率更高。

多模態 RAG 系統，需要考慮各種情況，需要有個統一的任務管理模塊，來針對用戶數據的不同類型，分別調用相應的模塊來進行處理。

隨着 Encoder-Decoder 架構在工程上的漸趨成熟，Image Patch 的語義表達更加精細，多模態模型已經不再是未來，而是當下，以它爲基礎的多模態 RAG，也早已擺脫了圖片搜索等上一代 AI，它們已經或者即將解鎖企業內部的大量非結構化文檔數據的深度理解，這將大大擴充 RAG 的使用場景，也大大增加大模型在企業端的應用價值。作爲同時開發端到端 RAG 產品和下一代 RAG 配套數據庫的我們，也在密切跟進相關領域的發展，不論是產品側，還是模型以及 Infra 側。歡迎大家關注我們的端到端開源 RAG 產品 RAGFlow（https://github.com/infiniflow/ragflow），也歡迎關注我們面向未來 RAG 需求的開源數據庫產品 Infinity（https://github.com/infiniflow/infinity）

參考資料

1. https://huggingface.co/spaces/big-vision/paligemma-hf

2. https://huggingface.co/spaces/GanymedeNil/Qwen2-VL-7B

3. ColPali: Efficient Document Retrieval with Vision Language Models. https://arxiv.org/abs/2407.01449

4. MMLongBench-Doc: Benchmarking Long-context Document Understanding with Visualizations. https://arxiv.org/abs/2407.01523