Gemini 多模態 RAG 文件檢索

課程概述

企業文件很少只有一整片文字，常常還混著表格、流程圖、照片、頁首頁尾，甚至一張圖要連前後頁一起看才懂。若前處理時只把 PDF 抽成純文字，後面的 RAG 再厲害，也找不回已經丟掉的版面關係。這篇會帶你把文件解析、檢索、權限與 Gemini 多模態理解串起來。

你將學到

• 解釋 RAG 架構的核心流程：檢索、增強、生成
• 理解多模態 RAG 與傳統文字 RAG 的架構差異
• 運用 Gemini 處理包含圖片與表格的文件問答
• 設計 Agent Search（原 Vertex AI Search）的 Data Store 與索引策略（課程頁的技能說明沒有列這一項，這裡當作延伸內容）

核心概念

RAG 架構回顧

RAG（Retrieval-Augmented Generation）把模型和外部知識庫接在一起：先從已建立的索引找出可能有用的證據（Retrieval），再把證據和問題一起交給模型（Augmentation），最後產生回答（Generation）。它能讓答案有機會引用最新或內部資料，但不會自動消除幻覺；如果撈錯內容、權限過濾失效，或模型沒有被要求忠於證據，答案仍然可能出錯。

多模態 RAG 的挑戰

不少早期 RAG 管線會先把文件壓成純文字，表格的列欄關係、圖片區域與頁面位置也跟著不見。多模態 RAG 要多處理三件事：如何保留非文字元素的結構、如何讓文字查詢找到表格或圖片，以及回答時如何把證據位置交代清楚。真正棘手的通常不是「模型看不看得懂圖」，而是圖在匯入時有沒有被正確切片、描述與索引。

Gemini 的多模態理解能力

Gemini 模型可接受文字、圖片、影片與音訊等多模態輸入，適合用來解讀圖表、頁面截圖或文件片段。在 RAG 管線裡，它可以參與匯入階段，把視覺內容整理成可檢索的描述；也可以放在回答階段，根據取回的文字與圖像證據作答。兩個位置的成本、延遲與可重現性不同，設計時要分開評估。

Agent Search 與 Document AI 的協作

Agent Search 提供代管的搜尋、Data Store、索引與生成式回答能力；Document AI 則專注於 OCR、版面、表格與欄位等文件解析。兩者可以搭配，但不是所有專案都得全部用上。若只有少量、臨時性的文件，而且能直接放進模型上下文，先做原生多模態問答可能更省事；需要反覆查詢、大量資料、權限隔離與來源追蹤時，才更值得建立完整 RAG。官方在 2026 年把 Vertex AI Search 的文件名稱改為 Agent Search，但主控台仍可能看到 Vertex AI Search 或 AI Applications，API 也仍使用 Discovery Engine 端點；可參考官方版本資訊。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 24, "rankSpacing": 32}}}%%
flowchart TB
  subgraph SCOPE["① 先看資料規模與使用方式"]
      direction LR
      START["列出文件數量、更新頻率、<br/>檔案類型與使用者"] --> REPEAT{"會反覆查詢大量文件，<br/>或內容持續更新嗎？"}
      REPEAT -->|"不會"| FIT{"單次需要的文件能放進<br/>模型支援的輸入範圍嗎？"}
  end
  FIT -->|"能"| DIRECT["先用 Gemini 直接讀取文件<br/>保留頁碼並要求引用"]
  FIT -->|"不能"| RAG["建立索引式 RAG"]
  REPEAT -->|"會"| RAG
  subgraph CONTROL["② 判斷是否需要企業級控制"]
      direction LR
      RAG --> ACCESS{"不同使用者能看的<br/>文件範圍不同嗎？"}
      ACCESS -->|"是"| ACL["匯入文件權限與 Metadata<br/>查詢時先過濾再檢索"]
      ACCESS -->|"否"| PARSE["保留頁碼、表格、圖像區域<br/>與跨頁關係後再切片"]
      ACL --> PARSE
  end
  DIRECT --> EVAL["準備文字、表格與圖片問題<br/>檢查答案、引用與拒答"]
  PARSE --> EVAL
  EVAL --> PASS{"證據不足時會拒答，<br/>引用也能回到原頁嗎？"}
  PASS -->|"會"| PILOT["小範圍上線，持續記錄<br/>漏找、誤找與權限問題"]
  PASS -->|"不會"| FIX["回頭修正解析、切片、<br/>檢索、Prompt 或門檻"]
  FIX -.-> EVAL

實作重點

• 準備一組包含圖表與表格的 PDF，記錄解析後是否保留頁碼、表格欄列與圖片位置，再建立 Data Store
• 測試純文字問題與需要圖表理解的問題，比較回答品質的差異
• 調整 Chunking 策略（按頁面、按段落、按語義），觀察對檢索準確度的影響
• 使用 Gemini API 直接傳入文件或圖片，和 RAG 結果比較延遲、引用、成本與權限控制

Lab 導讀

Lab 連結：Inspect Rich Documents with Gemini Multimodality and Multimodal RAG — Google Skills

這個 Lab 的操作不少，會帶你做出一套處理富文件的 RAG 系統。最值得看的其實是文件進索引前發生了什麼：表格有沒有被拆散、圖表是否保留頁碼、中文 OCR 有沒有誤字。建議另外準備幾個「答案只藏在圖或表裡」的問題，才能真的驗證多模態流程，而不是只測文字段落。

延伸學習

• 向量搜尋與嵌入技術 — 回顧 Vector Search 的基礎
• Gemini 開發者指南 — 學習更多 Gemini API 的進階用法
• RAG 架構 — 登雲學院 GenAI Leader 課程的 RAG 全面解析