多模態 RAG：從 OCR/STT 前處理，走向原生跨模態檢索與可查證引用
AI / Multimodal RAG / Vector Search
多模態 RAG：從 OCR/STT 前處理，走向原生跨模態檢索與可查證引用
Threads 貼文主張：RAG 正從純文字檢索邁向原生多模態檢索；透過 Gemini Embedding 與 Claude Code，可把文字、圖像、PDF、影音等非結構化資料封裝進統一向量資料庫。官方 Google 資料可核對到兩個關鍵進展：Gemini Embedding 2 是 natively multimodal embedding model，能把 text、images、video、audio、documents 放進 single embedding space；Gemini API File Search 則新增 multimodal support、custom metadata 與 page-level citations。
保守修正：「30 分鐘建完商業級多模態知識庫」應視為 demo / prototype 敘事，不是 production 承諾。多模態 RAG 真正難的是資料切分、metadata、召回率、引用追溯、權限、成本、更新與評估。
傳統 Text RAG
圖片、影片與音訊通常先經 OCR / STT 轉成文字，再嵌入與檢索。優點是工程簡單；缺點是視覺版面、圖像語意、時間軸與多模態關係容易在轉換中流失。
原生多模態 Embedding
Gemini Embedding 2 官方描述為把文字、圖片、影片、音訊與文件映射到 single embedding space，使跨媒體 retrieval 與 classification 成為同一套相似度問題。
File Search 的產品化方向
Gemini API File Search 的官方更新重點是 multimodal support、custom metadata、page-level citations。這表示多模態 RAG 不只要「找得到」，還要能篩選、驗證與追溯來源。
| 層級 | 工程選擇 | 驗收重點 |
|---|---|---|
| 資料攝取 | 文字、PDF、圖片、影音、metadata 同步進管線。 | 檔案版本、權限、來源 URL、頁碼/時間戳不能丟。 |
| Embedding | 使用多模態 embedding 或分模態 embedding + fusion。 | 跨模態查詢是否真的召回正確圖/段落/時間點。 |
| Vector DB | Pinecone / pgvector / Weaviate / Milvus 等。 | metadata filter、namespace、更新/刪除、成本與延遲。 |
| 生成回答 | LLM 讀回收片段與媒體引用後回答。 | 必須附 citation；沒有可追溯來源就不能算可驗收。 |
| 前端呈現 | 圖文混合、PDF 原圖、圖片放大、影音片段。 | 使用者能回到原圖、原頁或原時間戳核對。 |
實作前檢查：
- 定義 query 類型：以文搜圖、以圖搜文、PDF 問答、影片片段檢索，各自測 recall。
- metadata 先設計：tenant、source、page、timestamp、permission、file version。
- 建立 evaluation set：每種模態至少準備已知答案與應召回來源。
- citation 要到 page-level / timestamp-level；只回文件名不夠。
- Claude Code / vibe coding 可加速 prototype，但 production 仍需 code review、測試、權限與成本監控。