← 全部筆記
Series 多模態 AI 核心原理 7 / 10
2026.10.12

多模態 RAG：如何檢索圖片、PDF、表格與影片？

從跨模態檢索、視覺文檔表示到證據融合，理解多模態 RAG 的架構設計、取捨與實務建議。

MultimodalRAGColPaliVisRAGGraphRAGVideoRAGRetrievalDocument Understanding

多模態 RAG：如何檢索圖片、PDF、表格與影片？

上一篇我們追蹤了視覺 token 的成本結構，理解了為什麼一張圖片的推理成本遠高於一段文字。我們討論了 Token Pruning、Token Merging、Dynamic Resolution、KV Cache 優化等加速技術。
但這些技術解決的是「模型看得多快」的問題，它們假設信息已經在模型的上下文裡了。
真實世界的知識並不總是在上下文裡。它散落在 PDF 文件、產品截圖、財務表格、教學影片、監控錄影中。
多數以文字切塊與文字嵌入為主的傳統 RAG，主要檢索文字內容；但若文件中的關鍵資訊存在於圖表、版面或圖片中，單靠文字抽取可能無法完整保留這些資訊。
這一篇，我們要回答一個架構問題：模型看不到的信息，如何透過檢索取得？

Query → Multimodal Retrieval → Evidence Fusion → MLLM → Answer

一、Requirement：傳統 RAG 為什麼不夠？

多數以文字切塊與文字嵌入為主的傳統 RAG，流程是：把文件切成文字塊，用嵌入模型編碼，存入向量資料庫。查詢時，用同樣的嵌入模型編碼查詢，找出最相似的文字塊，把它們餵給 LLM 生成回答。

這個流程有一個隱含的假設：所有有價值的信息都可以用文字表達。

但真實世界的文件不是這樣。

一份 PDF 財報包含：

  • 正文段落（文字）
  • 資產負債表（表格）
  • 營收趨勢圖（圖表）
  • 產品照片（圖片）

一份產品手冊包含：

  • 操作步驟（文字）
  • 介面截圖（圖片）
  • 參數對照表（表格）

一堂教學影片包含：

  • 講師講解（語音轉文字）
  • 投影片內容（視覺）
  • 板書與手勢（視覺）

如果把所有這些內容都轉成純文字，部分結構信息可能會丟失。表格的行列關係、圖表的數據趨勢、截圖的空間佈局，在文字化之後可能變得模糊甚至消失。一篇 2026 年的 ACL 綜述指出，若只抽取純文字而不保留版面與結構資訊，部分關係可能遺失；而原生 MLLM 則面臨長上下文的處理限制。MRAG Survey

多模態 RAG 的需求可以拆解成三個層次：

  1. 第一層：跨模態檢索。 用文字查詢檢索圖片，用圖片查詢檢索文字，用文字查詢檢索表格和影片。
  2. 第二層：保留結構。 表格的行列關係、圖表的數據趨勢、文件的版面佈局，在檢索和生成過程中都應該被保留。
  3. 第三層：證據接地。 檢索到的證據必須真正支撐生成的回答，而不是被模型忽略或誤用。

二、Constraints：多模態檢索的根本挑戰

挑戰一：模態鴻溝

圖像和文字的嵌入向量在空間中天然存在差異。CLIP 的對比學習雖然能讓匹配的圖-文對靠近，但跨模態檢索的表現仍取決於模型、資料分布與相似度校準——不能一概而論地推斷 CLIP 必然產生某種固定的檢索偏差。CLIP 某些模型在特定資料集上可能表現出檢索偏斜，但這不是 CLIP 的普遍結論。

Voyage AI 的 voyage-multimodal-3.5 採用了統一的 Transformer 編碼器，讓文字和圖像通過同一個編碼器在同一個向量空間中編碼，這是其產品的架構選擇。Voyage MM 3.5 這種設計是否優於雙編碼器，仍取決於具體的檢索任務與資料集。

挑戰二：視覺文件的表示

一份 PDF 頁面是一個二維結構。文字、表格、圖表、圖片交織在一起。如何把它編碼成一個可檢索的表示？

multi_vs_single_vector

兩種主流思路：

  • 多向量表示：ColPali 用 late interaction 模型，將每一頁編碼成多個向量。以 ColPali 的特定模型設定為例，一頁 PDF 可能產生約 1030 個 128 維向量。ColPali 精度高，但儲存和檢索成本取決於向量數量、數值精度和是否包含額外 token，不同設定會改變實際成本。
  • 單向量表示：VisRAG 用雙編碼器將整頁編碼成單個向量（以 2304 維為例），儲存效率較高，適合大規模文件檢索。VisRAG-Ret 在多個資料集上的表現不遜於 ColPali，甚至在某些任務上更好。VisRAG

兩種方法的實際儲存成本差異取決於具體的向量維度、精度和模型設定，不能寫成固定規格。

挑戰三：表格的結構化檢索

表格是二維的。一個單元格的含義取決於它的行和列。把表格展平成文字可能會丟失這個結構。

近期業界在工程落地時，常採用混合策略來處理表格檢索——結合文字 RAG、多模態 RAG 與結構化查詢，根據表格的類型和查詢的需求動態選擇路徑。具體的提升幅度取決於資料集、指標和基線設定，需要參照原始論文才能確認。

挑戰四：影片的時序檢索

影片是圖片的序列。相鄰幀之間高度重複，但關鍵事件可能只發生在幾秒之內。

VRAG 採用兩階段檢索：先檢索最相關的影片片段，再對片段進行切塊與細化，找出關鍵子片段，從而只將最相關的內容送入 MLLM 處理。VRAG 這是一個明確的兩階段設計，而非「無限長度」的通用能力——其效果仍受索引規模、儲存與檢索成本約束。

另一類方法則採用雙通道架構：一邊用圖結構做跨影片的語義關係建模，另一邊用多模態編碼保留視覺特徵。這類方法支援長影片的分段檢索與跨片段關係建模——這是其設計目標，但仍受限於索引規模、儲存、檢索成本、上下文長度與時序資訊保留。

三、Design：多模態 RAG 的架構

統一的多模態 RAG 流水線

一條 2025 年 MAGMaR Workshop 的論文提出了一個統一的 mRAG 系統，同時處理文字、表格、圖片和影片四種模態。它的流水線是：mRAG

1. 資料攝取（Ingest）：
   從 PDF 和影片中提取內容

2. 結構化提取（Structured Extraction）：
   用 Amazon Textract 提取表格，
   用 Transcribe 提取語音，
   用多模態 LLM 做語義豐富

3. 索引（Index）：
   把不同模態的內容編碼成向量，存入向量資料庫

4. 檢索（Retrieve）：
   根據查詢模態，從對應的索引中檢索

5. 生成（Generate）：
   把檢索到的多模態證據餵給多模態 LLM

這個系統的評估顯示，在結構化文字和表格上的檢索準確率提升較明顯，圖片和影片查詢的表現稍低，但整體框架是穩健的。mRAG

證據融合：多模態 RAG 的核心挑戰

multimodal_evidence_fusion

檢索到多個模態的證據之後，如何把它們融合成一個連貫的上下文？

近期研究提出了一種輕量級的 MLLM 驅動多模態 RAG 框架，遵循「Input-Retrieve-Fuse-Reason-Output」流水線。視覺、文本與 OCR 檢索器先收集各模態候選，再通過一個輕量證據融合模塊對檢索分數進行正規化、考慮查詢相關性與跨模態對齊、降低冗餘，並選擇緊湊的多模態上下文供 MLLM 推理。Lightweight MRAG

在 WebQA 和 MultiModalQA 上，該框架報告的 F1 分數分別為 68.9 和 79.3（評估指標為 EM/Acc./F1/ER 中的 F1）。Lightweight MRAG 在 WebQA 上，F1 達到 68.9；在 MultiModalQA 上，F1 達到 79.3，均優於其設定的多個基線，包括直接 MLLM 回答、純文字 RAG、無融合的多模態檢索等。這些數字對應的是該論文的特定評估設定與資料切分，引用時需保留這一限定。

另一個值得注意的方向是文件跨頁連續性的處理。一份文件的上下文往往跨越多個頁面，證據融合時需要考慮到這種連續性。CA-MuRAG 提出了一個連續性感知的多模態 RAG 框架，從 PDF 中提取頁面級文字與圖像，生成視覺摘要，並在檢索階段通過 CLIP 相似度評分與文件視覺問答驗證來確保圖文對齊。CA-MuRAG 其目標是保留文字與視覺資訊之間的上下文關係，從而提升複雜文件問答的準確率。

GraphRAG：從向量檢索到關係推理

傳統的向量檢索找的是「相似的內容」。但有些問題需要「關聯的內容」。

多模態 GraphRAG 把文字和插圖整合到一個統一的知識圖譜中，進一步聚合成社區級別的知識。檢索時先在模態特定的索引中找直接匹配，再通過知識圖譜擴展到語義相關的實體。

這種架構的潛在優勢在於：它支持跨模態的推理鏈。 如果查詢問的是「這張圖裡的設備在哪個文件裡被提到過？」，向量檢索可能找不到直接匹配，但知識圖譜可以沿著「設備 → 文件」的關係找到答案。這是一個架構示例，並非所有 GraphRAG 都能直接支援跨模態關係推理。

影片 RAG 的專門架構

hierarchical_video_retrieval

影片 RAG 有兩個獨特的挑戰：時序性和長度。

部分研究採用兩階段檢索：先找到相關的影片片段，再在片段內細化。另一類方法則用雙通道架構同時處理跨影片的語義關係和影片內的視覺特徵。

Voyage Multimodal 3.5 會將影片視為有序的影格序列進行嵌入，並依影片像素量計算 token 預算；單一輸入的上限為 32,000 tokens。處理長影片時，應依場景與語音轉錄的時間邊界切分。Voyage MM 3.5

四、Trade-offs：多模態 RAG 的取捨

多向量 vs 單向量

面向多向量（ColPali）單向量（VisRAG）
表示大小取決於向量數與精度單向量，較緊湊
檢索精度在特定設定下較高在特定設定下接近
儲存成本較高較低
檢索速度較慢（MaxSim）較快（內積）
適合場景小規模高精度大規模可擴展

實際表現會受到資料集、模型版本、索引實作、硬體、量化方式與查詢類型影響。近期有工作提出了兩階段檢索的折中方案：用 tile-level 空間池化生成緊湊的候選表示做快速粗篩，再用完整的多向量表示做精確 MaxSim 重排。Visual RAG Toolkit 在 ViDoRe v2 基準上，這種兩階段檢索能維持 NDCG 與 Recall@5/10 的表現，同時將吞吐提升約 4 倍 QPS——該結果的原文限定為 “over the limited (size) ViDoRe v2 benchmark corpus”，且敏感度主要出現在極大的 k 值。Visual RAG Toolkit

文字化 vs 原生視覺

文字化路徑：用 OCR 提取文字，用圖像描述模型生成圖片的文字描述，然後把所有文字內容餵給純文字 LLM。優點是兼容現有的文字 RAG 基礎設施，缺點是若未保留版面與結構信息，部分關係可能遺失。

原生視覺路徑：直接把圖片和文字一起餵給多模態 LLM。優點是可保留更多視覺與版面資訊，缺點是推理成本高，而且如前一篇所述，視覺 token 的上下文開銷很大。

混合路徑：根據查詢類型動態路由。文字查詢走文字路徑；當表格已被可靠地轉成可查詢的結構化資料時，可考慮 Text-to-SQL；對圖片中的圖表或非結構化表格，仍可能需要視覺理解與表格解析。部分企業級框架採用三路架構，用 soft probability scoring 動態路由查詢，檢索結果通過 Reciprocal Rank Fusion 合併。

早融合 vs 晚融合

早融合（Early Fusion）：在較早的處理階段整合不同模態的表示或特徵，再進行後續檢索或推理。

晚融合（Late Fusion）：各模態先獨立產生表示、分數或候選結果，再於後續階段合併。

早融合的優點是證據之間的一致性更好，缺點是融合模塊的複雜度高。晚融合的優點是靈活，缺點是可能產生模態之間的不一致。如果討論的是不同檢索器的結果何時合併，直接稱為檢索結果融合（retrieval-result fusion），再說明它是在排序階段或生成前進行，會比單純使用早融合、晚融合更清楚。

五、Decision：多模態 RAG 的實務建議

建議一：從混合檢索開始

不要試圖用單一模態的檢索器覆蓋所有場景。文字查詢用文字嵌入，結構化表格查詢在條件允許時用結構化查詢，圖片查詢用多模態嵌入，然後用 Reciprocal Rank Fusion 合併結果。

建議二：根據規模選擇表示策略

若資料規模較小，且更重視頁面局部細節的匹配，可以評估 ColPali 類多向量方法。ColPali 若資料規模較大，且儲存與檢索成本是主要限制，可以評估 VisRAG 類單向量方法。VisRAG 最終選擇應以目標資料集的 Recall@K、nDCG、延遲與成本測試為準。

建議三：證據融合是關鍵

檢索到多個模態的證據之後，不要簡單拼接。要做分數正規化、跨模態對齊檢查、降低冗餘。最終送入 MLLM 的上下文應該是精簡且互補的。

建議四：影片檢索要分層

先檢索相關片段，再細化到關鍵子片段。不要把整部影片的幀都編碼成向量，那只會製造噪音。VRAG

建議五：用指標驅動架構選擇

混合檢索、證據融合和影片分層檢索是工程建議，不應被視為適用所有資料集和場景的固定解法。建議搭配評估指標——Recall@K、nDCG、答案正確率、延遲和成本——再決定採用哪種架構。

六、小結

多模態 RAG 的核心問題是：模型看不到的資訊，如何透過檢索取得？

它的架構可以拆解成四個環節：

  1. 檢索：用文字查圖片、用圖片查文字、用文字查表格和影片。多模態嵌入用統一的 Transformer 編碼器可能有助於緩解模態鴻溝。Voyage MM 3.5
  2. 表示：視覺文件用多向量（ColPali）或單向量（VisRAG）表示。ColPali VisRAG 結構化表格在條件允許時用結構化查詢，影片用場景分割和時序嵌入。
  3. 融合：把不同模態的證據正規化、對齊、降低冗餘，選擇最緊湊的上下文。Lightweight MRAG CA-MuRAG
  4. 生成：把融合後的證據餵給多模態 LLM，生成有證據支撐的回答。

多模態 RAG 讓系統更有能力檢索與利用不同模態的證據。但看到之後呢？

下一篇，我們會進入多模態 Agent：AI 如何從理解資訊進一步採取行動？ 從 Observe → Understand → Reason → Plan → Tool → Action → Observe 的完整循環。

下一篇預告

《多模態 Agent：AI 如何從理解資訊進一步採取行動？》

我們會討論多模態 Agent 的設計：感知層如何處理視覺輸入、推理層如何根據視覺內容規劃動作、行動層如何調用工具操作介面，以及安全機制如何確保 Agent 的行動不會造成不可逆的傷害。

參考文獻

◆ END
← 回到筆記列表