RAG 過去常被簡化成「把文字切 chunk、丟進向量資料庫、問問題時取回相關段落」。
但現實文件不是只有純文字。企業文件常常混著 PDF、表格、截圖、流程圖、產品照片、設計稿、掃描頁面。若檢索系統只懂文字，很多真正有用的資訊會被漏掉。
Google 在 ５ 月 ５ 日更新 Gemini API File Search，加入 multimodal retrieval、custom metadata filtering 與 page-level citations。這讓 File Search 從一般文件檢索工具，往 multimodal RAG 基礎設施靠近。
這次更新的重點
| 功能 | 解決問題 |
|---|---|
| Multimodal retrieval | 圖片與文字能一起被理解與檢索 |
| Custom metadata filtering | 可用部門、產品、日期、權限等欄位過濾資料 |
| Page-level citations | 回答可指回來源頁面，方便查證 |
對開發者來說，這不是多一個漂亮功能，而是 RAG 系統可以處理更接近真實世界的資料。
Multimodal RAG 和傳統 RAG 差在哪？
傳統 RAG 最擅長的是文字知識庫：
- FAQ。
- Markdown 文件。
- 客服紀錄。
- 技術文件。
- 法規條文。
Multimodal RAG 則要處理：
- PDF 中的表格。
- 商品照片與規格文字。
- UI 截圖。
- 簡報圖表。
- 掃描合約。
- 工程圖與流程圖。
差別不只在「能不能上傳圖片」，而是 retrieval 本身是否能理解圖像訊號。
例如使用者問：「這份機器維修手冊裡，紅色警示燈連續閃三次代表什麼？」
若答案在一張圖旁邊的標註裡，純文字 chunk 可能抓不到。Multimodal File Search 有機會把圖像、頁面結構與文字一起納入檢索。
Page-level citations 為什麼重要？
RAG 最大的價值不是讓模型看起來更懂，而是讓使用者知道答案從哪裡來。
Page-level citation 可以讓回答指回 PDF 或文件的具體頁面。對以下場景很關鍵：
| 場景 | citation 價值 |
|---|---|
| 法務合約問答 | 律師要回原文確認 |
| 醫療或保險文件 | 需要精準頁面作為依據 |
| 產品手冊搜尋 | 維修人員要看圖與步驟 |
| 企業 SOP | 稽核需要查來源 |
| 教育資料庫 | 學生與老師可回到教材頁 |
沒有 citation 的 RAG，很容易變成「模型說得很像真的」。有 citation 才能進入可驗證工作。
Metadata filtering 要怎麼設計？
很多 RAG 專案不是死在模型，而是死在 metadata。
如果所有文件都只丟進同一個資料池，回答時就會混到錯誤版本、錯誤部門、錯誤地區、錯誤權限。
建議至少設計這些欄位：
| 欄位 | 用途 |
|---|---|
| department | 區分法務、客服、工程、業務 |
| product | 避免 A 產品答案套到 B 產品 |
| region | 法規、價格、保固常常因地區不同 |
| language | 中文、英文、日文文件分流 |
| version | 避免舊版 SOP 影響新版回答 |
| access_level | 控制機密文件可見範圍 |
| published_at | 過濾過期文件 |
Metadata filtering 的價值，是讓模型先少看錯資料，再開始推理。
適合做哪些應用？
產品手冊搜尋
硬體、家電、工業設備、醫療器材的手冊常含圖片、表格與警示圖示。Multimodal File Search 可以讓使用者用自然語言問問題，再回到相關頁面查看圖示與步驟。
設計與品牌資料庫
品牌規範、UI guideline、設計稿、簡報模板都不是純文字。若檢索能看圖，設計團隊可以問：「哪一頁定義了按鈕 hover 狀態？」或「這個 icon 風格在哪個規範裡？」
合約與法規文件
合約通常有表格、附件、掃描頁與修訂紀錄。Page-level citations 對法務團隊很重要，因為模型回答不能取代原文查核。
教育內容與研究資料
教材、論文、講義、圖表混在一起時，multimodal retrieval 能讓學生用更自然的方式查找概念。
企業內部知識庫
IT、HR、財務、客服 SOP 常常以 PDF 或簡報存在。若 metadata 設計得好，File Search 可以成為內部 Copilot 的資料層。
還需要向量資料庫嗎？
需要，但不是每個專案都需要一開始就上向量資料庫。
| 需求 | File Search 較適合 | Vector database 較適合 |
|---|---|---|
| 快速做 Gemini app 原型 | 是 | 不一定 |
| 圖文混合 PDF 問答 | 是 | 需額外管線 |
| 跨模型 embeddings | 否 | 是 |
| 自訂 ranking pipeline | 有限 | 是 |
| 大量權限分層 | 視情況 | 是 |
| 混合 BM25、向量、reranker | 有限 | 是 |
| 完全掌控資料儲存 | 否 | 是 |
如果團隊已經深度使用 Gemini API，且資料型態主要是文件與 PDF，File Search 可以降低第一版 RAG 的工程成本。
如果你要做大型 SaaS 搜尋、複雜 tenant 權限、跨模型策略、hybrid search 或自訂 reranking，傳統向量資料庫仍然比較彈性。
導入時最容易忽略的問題
１．PDF 頁面不等於語意單位
Page-level citation 很有用，但一頁可能包含多個主題。若文件排版複雜，仍然需要測試 retrieval 是否抓到正確段落。
２．圖片文字要驗證
圖中的小字、表格、標註可能會被誤讀。高風險場景要加入人工確認或 OCR 對照。
３．Metadata 要在上傳前整理好
不要等資料進去後才想權限與版本。RAG 最怕舊文件和新文件混在一起，最後模型回答過期政策。
４．Citation 不等於答案正確
模型可能引用對的頁面，卻解讀錯。citation 是查證入口，不是保證書。
５．測試題要包含反例
不要只測「文件裡有答案」的題，也要測：
- 文件裡沒有答案時是否拒答。
- 舊版文件是否被排除。
- 權限不足時是否不回。
- 圖片訊息是否被誤解。
- 多文件衝突時是否提示不確定。
建議的最小可行架構
一個穩妥的第一版可以這樣做：
- 選一組明確資料，例如產品手冊或內部 SOP。
- 為每個文件補上 product、version、department、access_level。
- 使用 Gemini API File Search 建立檢索。
- 回答必須附 citation。
- 若 citation 信心不足，要求使用者回原文。
- 記錄查詢、引用頁面、使用者回饋。
- 用錯誤案例反推 metadata 與文件整理方式。
不要一開始就把全公司文件倒進去。知識庫越髒，RAG 看起來越聰明，錯起來也越難抓。
結論
Gemini API File Search 的 multimodal 更新，讓 RAG 更接近企業文件的真實樣貌。
它的價值不只是能看圖片，而是把圖文混合文件、metadata filtering、page-level citations 放進同一個開發者體驗裡。對想快速做文件問答、產品手冊搜尋、內部知識助理的團隊，這會比自建一整套 multimodal pipeline 更快。
但 RAG 的基本功沒有消失：資料版本、權限、citation 查核、測試反例，仍然決定系統能不能進 production。