多模態RAG怎麼做？2026 Layout Parsing、Visual Retrieval與Claim-level Citation

多模態RAG的核心，不是把PDF全部轉成文字，而是讓文字、表格、圖表、圖片與版面位置都能被檢索、重排並回到原始證據。可靠系統會把「用來搜尋的表示」和「用來回答的證據」分開：摘要、Embedding與Visual Multi-vector負責召回；完整段落、原始表格、圖片與頁面區域負責回答。

• Layout Parsing先辨識標題、段落、表格、圖片、頁碼與Reading Order。
• Keyword、Dense Vector、Visual Retrieval與Metadata Filter各自處理不同問題。
• 小Chunk適合搜尋，Parent Section與原頁適合回答。
• Citation至少應回到Document Version、Page與Bounding Box。
• 權限必須在Retrieval前套用，不是取回後再叫模型保密。
• Parsing、Retrieval、Answer與Citation需要分開評估。

文章實體化：多模態RAG怎麼做？2026 Layout Parsing、Visual Retrieval與Claim-level Citation

本文以「多模態RAG怎麼做？2026 Layout Parsing、Visual Retrieval與Claim-level Citation」為主線，補回人物、作品／事件、時間、地點、做法與可驗證結果，讓抽象論述重新連到真實情境。

• 對象與場景：指出誰在什麼時間、地點與條件下做了什麼。
• 證據與細節：補上名稱、數據、流程、作品、產品或事件節點，並說明它們如何支撐主張。
• 判讀邊界：分開已確認事實、當事人說法與本文的分析，不用形容詞取代證據。

涉及人物近況、價格、規則、活動或市場資料時，發布前應以第一手公告與可追溯來源核對。

多模態RAG完整流程

1. 建立Document ID、版本、有效日期與權限。
2. 解析Reading Order、段落、表格、圖片與頁面座標。
3. 建立Keyword、Dense、Visual與Metadata索引。
4. 解析Query中的實體、時間、文件類型與權限。
5. 由多個Retriever召回候選並去重。
6. 使用Reranker提高前幾名精度。
7. 取回Parent Section、完整表格或原始頁面。
8. 生成答案並驗證每個重要Claim是否被Citation支持。
9. 保存Query、候選、答案、引用與人工回饋。

資料模型應保存什麼

document_object:
  document_id: policy-2026-04
  version: 4
  page: 18
  object_id: table-18-2
  object_type: table
  parent_section: 付款與退款
  bounding_box: [88, 214, 942, 701]
  source_uri: s3://knowledge/policy-v4.pdf
  valid_from: 2026-04-01
  access_groups: [finance, customer_success]

只保存Chunk文字與Embedding，文件更新後很難確認舊答案引用哪一版，也無法把使用者帶回原始證據。每個物件都應能回到文件、版本、頁面與位置。

四種Retriever如何分工

Hybrid Retrieval的作用是先擴大Recall，再用Reranker判斷真正相關內容。單一向量搜尋很難同時處理概念型問題與精確編號。

ColPali與Visual Retrieval

ColPali類方法把整頁文件影像編成多個向量，再以Late Interaction比較文字Query與頁面區域。它能保留傳統OCR流程容易丟失的圖表、字型、版面與空間關係。找到頁面後，精確數字、權限遮罩與Citation仍需要物件解析或原頁定位。

Parent／Child Retrieval

小Chunk較容易和Query精確匹配，回答時卻可能失去章節、表名與例外條款。較穩定的做法是以短段、表格摘要或Visual Vector搜尋，命中後取回完整段落、完整表格、原圖與鄰近文字。

Claim-level Citation

只寫「來源：公司手冊.pdf」不足以驗證答案。重要Claim應指向Document ID、Version、頁碼、Section或Table ID、Bounding Box、有效日期與Source URI。來源矛盾時，答案應呈現差異，而不是替文件Owner選擇正式版本。

表格、數字與計算

表格適合採「摘要找表、原表回答」。以表名、欄位與自然語言摘要做召回，命中後取回完整Table Object。需要計算時，先轉成結構化資料交給程式，並保存公式、使用列、幣別、單位與年份。

權限與Prompt Injection

• Index保存Tenant、Group與Document ACL。
• Cache、Retriever與Reranker沿用相同Access Filter。
• 外部文件中的指令只能視為資料，不能覆蓋System Policy。
• 撤權、封存與版本更新需同步失效。
• 敏感Query與答案保存受限Audit。

評估多模態RAG

最小導入流程

1. 選一種高價值文件，例如制度或產品手冊。
2. 建立50至100個真實問題與標準Evidence。
3. 先完成解析、版本、權限與Citation。
4. 比較Keyword、Dense、Visual與Hybrid Retrieval。
5. 加入Reranker與Parent Context。
6. 測試拒答、衝突與越權。
7. 達標後再擴大文件類型。

研究與延伸閱讀

• ColPali：Visual Document Retrieval
• ViDoRe V3 Benchmark
• Document AI怎麼驗收
• Context Graph怎麼設計

多模態RAG最重要的資產不是某一套Vector Database，而是能回到原始頁面的證據鏈。Parser、Retriever、Reranker與模型都會更新；Document ID、版本、權限、Bounding Box與測試集讓系統持續可驗證。

更新日期：2026 年 8 月 13 日。多模態 RAG 不是把圖片丟進向量資料庫，再讓模型自由描述。真正可用的系統必須同時保存文字、圖片、頁碼、區塊位置、文件版本、權限與來源關係，並在回答時把每個 claim 連回原始頁面。本文補上 2026 年的實作視角：從 Layout Parsing、圖片描述、Visual Retrieval、Hybrid Search、Claim-level Citation 到 Prompt Injection 與權限驗收，讓多模態 RAG 更容易被工程團隊重跑，也讓搜尋引擎與生成式系統能辨認文章中的固定實體和流程。

多模態 RAG 到底解決什麼問題？

純文字 RAG 會把 PDF、簡報、掃描表格或網頁中的文字抽出後建立索引，但很多關鍵資訊其實留在圖表、流程圖、截圖、座標、顏色、箭頭和表格版面裡。若只做 OCR，文字可能被抽出，卻失去「這個數字屬於哪一列」「這個箭頭連到哪個步驟」「這張圖在第幾頁」等結構關係。

多模態 RAG 的目標不是讓模型看起來更聰明，而是讓檢索階段能找到文字與視覺證據，生成階段能引用正確頁面，使用者還能回到原始檔案核對。Microsoft Azure AI Search 目前的官方多模態文件把流程拆成抽取文字與圖片、產生圖片描述、建立文字／圖片向量、保存原始圖片與 metadata，再以 hybrid query 取回內容。這個拆法可作為任何供應商或自建系統的共同基線。

一條可驗收的多模態 RAG pipeline

1. Ingest：保存原始 PDF、簡報、網頁或圖片檔的 hash、來源 URL、建立時間、文件版本與權限。
2. Layout Parsing：辨認頁面、標題、段落、表格、圖表、圖片、caption、座標與閱讀順序，不只把內容串成一個大字串。
3. 文字抽取：保留原文、OCR 文字、語言、頁碼、區塊 ID 和信心資訊；修正 OCR 時不可刪掉原始證據。
4. 視覺處理：對圖表、流程圖、掃描頁、照片與截圖分流；記錄圖片位置、尺寸、周邊文字與是否需要人工覆核。
5. Embedding：選擇圖片描述後做文字 embedding、直接做 multimodal embedding，或兩條路徑並行；不要假設所有向量可以互換。
6. Retrieval：結合 keyword、BM25、vector、metadata filter、rerank 和權限 filter，保留每個結果的 page／block／image ID。
7. Grounded generation：要求回答只使用取回的證據，對每個可驗證 claim 產生可點回的引用與原始視覺片段。
8. Audit：保存 query、候選結果、最後採用的 evidence、模型版本、prompt、引用與人工修正，讓錯誤可以重播。

Layout Parsing 為什麼是第一個瓶頸

文件中的版面不是裝飾。表格的欄列、圖表的圖例、流程圖的箭頭、頁首頁尾、腳註和跨頁段落，都可能改變答案。切 chunk 前應先保存區塊的父子關係與 page coordinates，再依任務決定如何切分。對表格，最好同時保留原始畫面、結構化欄列和純文字表示；對流程圖，則要保留節點、連線和方向，而不是只做一段圖片 caption。

一個可追溯的 chunk 至少要有：document_id、version、page、block_id、bbox、parent_id、source_url、access_policy、text、image_uri 與 content_hash。這些欄位會讓生成式引擎得到比「一堆相似片段」更穩定的實體關係，也讓工程團隊可以判斷引用是否真的來自同一頁。

圖片描述與直接 Multimodal Embedding 怎麼選

圖片描述（image verbalization）先把圖表或截圖轉成自然語言，再用文字向量檢索。優點是容易和文字 chunk、keyword search、reranker 及引用模板整合；缺點是描述可能漏掉數字、空間關係或視覺細節，而且每張圖片都會增加一次模型處理成本。

直接 multimodal embedding 則把文字和圖片映射到可比較的向量空間，適合視覺相似度與「找一張像這張的圖」等任務，但向量本身不會告訴生成模型為什麼相似，也不會自動提供可讀的 citation。若答案需要解釋圖表，直接向量通常還要搭配原始圖片、OCR、caption 或視覺模型回讀。

2026 年較務實的做法不是二選一，而是依內容類型分流：流程圖、架構圖、統計圖表和表單優先做描述與結構化抽取；照片、商品圖、視覺比對和截圖搜尋可加直接 multimodal embedding；高價值文件則兩條路徑並存，讓檢索結果保留文字證據與圖片證據。

Visual Retrieval、Hybrid Search 與 Rerank 的分工

Visual Retrieval 回答「哪個頁面或圖片的視覺內容與問題相關」；keyword／BM25 回答精確詞、編號和型號；vector search 回答語意相近；metadata filter 回答日期、部門、產品、語言和權限；rerank 則在候選集合內重新排序。多模態 RAG 不應讓單一向量分數負責所有判斷。

查詢也要分型。文字問題可做 keyword＋text vector＋visual description 的 hybrid query；圖片問題需要支援 image-to-vector 的 multimodal embedding 路徑；限定某份文件或某個版本時，先套 metadata filter 再檢索。Azure AI Search 官方文件特別區分了圖片 verbalization 與直接 multimodal embedding，也指出只有相應的 multimodal vectorizer 才能支援圖片作為 query；這是設計 API 時不能略過的邊界。

Claim-level Citation 怎麼做才不是貼一個文件連結

一個回答可能包含數字、時間、因果、比較和建議，每一種 claim 的證據位置不同。citation 應該連到最小可核對單位，而不是只把整份 PDF 的首頁 URL 貼在段末。建議每個 claim 保存：

• claim ID 與回答中的文字範圍；
• 支持它的 document、version、page、block 或 image ID；
• 原始來源 URL、hash、擷取時間與權限狀態；
• 是直接證據、模型摘要、跨文件推論，還是尚未驗證的建議；
• 若多個來源衝突，採用的版本與未採用原因。

對生成式引擎而言，這種「實體—欄位—來源」結構也比一段沒有日期的長文更容易被正確摘要。對人類讀者而言，引用可點回頁面或圖片，才能辨認模型是否把圖表數字看錯。

表格、數字與圖表要特別驗收

表格是多模態 RAG 最容易產生高信心錯誤的地方。OCR 可能把欄列錯位，圖表 caption 可能忽略座標軸，視覺模型可能讀錯小數點、負號或單位。驗收時不要只問「答案像不像」，應逐欄比對 ground truth，並測試跨頁表格、合併儲存格、旋轉頁面、低解析度掃描和同名欄位。

對數字型問題至少保存原始裁切圖、OCR 文字、結構化數值與模型最終引用。若數值只從圖片描述而來，標示為圖片解讀；若來自表格原始欄位，標示為結構化證據。這能降低摘要系統把推測數字當成文件原文的風險。

權限與 Prompt Injection：圖片也可能是攻擊面

圖片、PDF 註解、隱藏文字、QR code、截圖中的指令，都可能包含 prompt injection。抽取器不應把文件內的指令直接升級成系統指令；生成模型也不應因為圖片寫著「忽略所有規則」就改變權限或工具行為。對每個 chunk 先標記 untrusted content，將資料內容和系統規則分層，再在輸出前做 citation、權限與敏感資料檢查。

權限必須在索引和查詢兩層都驗證。只在生成後把敏感段落刪掉不夠，因為模型可能已經從不可見文件推導出答案。測試案例要包含：同一份文件的不同角色、圖片與文字權限不一致、刪除後仍殘留的向量、版本撤回、跨租戶檢索和越權引用。

多模態 RAG 的驗收指標

常見問題：多模態 RAG 與 Visual Retrieval

多模態 RAG 是否等於讓模型直接看 PDF？

不等於。直接看 PDF 是一種輸入方式；多模態 RAG 還包括抽取、切分、索引、檢索、權限、引用與監控。若沒有來源 metadata，回答即使正確也難以驗證。

圖片一定要先轉成文字嗎？

不一定。圖表和流程圖通常需要描述與結構化資訊；照片或視覺相似搜尋可使用直接 multimodal embedding。高價值資料可以兩者並行，再比較成本、召回和引用品質。

向量相似度高，代表 citation 一定正確嗎？

不代表。相似度只協助排序，不能證明來源支持答案。仍要保存 page／block／image ID，並做 claim-level citation 與人工抽查。

多模態 RAG 最先應該測哪個案例？

先選一個有明確 ground truth、包含文字與視覺證據、且錯誤成本可量化的案例，例如政策流程圖、產品規格表或財務圖表，再逐步擴大到跨文件與權限情境。

官方資料與圖片來源

本文的 2026 現在式更新以 Microsoft Azure AI Search 多模態搜尋與 Portal quickstart、Google Cloud multimodal embeddings API，以及 ColPali 研究論文為主。這些來源支持的是架構、API 與評估方法，不代表本文已替任何供應商完成獨立 benchmark，也不代表圖片向量一定能提高搜尋排名或生成式引擎引用率。

• Azure AI Search 多模態搜尋官方概念：文字、圖片、抽取、embedding、hybrid query 與 citation
• Azure AI Search Portal quickstart：文件抽取、圖片向量與多模態索引
• ColPali 研究論文：視覺文件檢索與 page-level retrieval
• Google Cloud Multimodal Embeddings API：文字、圖片與影片 embedding API
• 本文圖片原始來源：Google Cloud 官方 multimodal embedding sample image

增量閱讀｜多模態 RAG 的難點是證據對齊

多模態 RAG 不只是把圖片轉成文字再丟進向量資料庫，而是要保留版面、表格、圖表、欄位關係與來源位置。Layout Parsing 先回答內容在頁面哪裡，Visual Retrieval 再找出與問題相關的視覺證據，claim-level citation 則把回答中的每個主張接回可核對片段。真正可用的系統需要處理解析錯誤、檢索遺漏、跨頁上下文與引用粒度，否則多模態只會讓錯誤看起來更有說服力。

延伸分析｜多模態 RAG 的難點，不只是把圖片接進檢索流程

多模態 RAG 怎麼做，真正的難點不只在 Layout Parsing、Visual Retrieval 或 Claim-level Citation 各自能不能運作，而在於它們如何共同維持一條可追溯的證據鏈。圖片被切成區塊、文字被抽取、檢索結果被組合後，系統仍要能回答「這個結論來自哪裡」。

好的架構會把解析、檢索、生成與引用拆成可檢查的階段，而不是把所有步驟交給一個黑盒。實作時也要留意模型、套件與 API 版本會持續變動；具體設定應以當前官方文件與測試結果為準。以下補充聚焦於可驗證性與系統設計。

• 解析：版面、圖片與文字需要保留來源座標
• 檢索：視覺相似不等於語意證據，兩者要分開評估
• 引用：Claim-level citation 需要可回到原始片段