多模態嵌入與RAG：實用指南

當我們試圖用語言描述一段音樂時，常常會陷入“有點像Billie Eilish，但更柔和，有鋼琴線……算了，你直接聽吧”的困境。這並非語言的失敗，而是提醒我們語言本質上是經驗的壓縮表示，如同任何壓縮都會丟失音調、質感、空間佈局等細節。在AI歷史中，我們曾不得不接受這種壓縮：搜尋和檢索幾乎只處理文本，若非寫成文字，便視為不存在。播客需轉錄，掃描PDF需OCR，白板照片則幾乎無法利用。每次轉換都帶來資訊損失。

多模態嵌入改變了這一局面。它能夠將文本、影像、音訊和影片對映到同一嵌入空間，使一種模態的查詢可以檢索所有其他模態的結果。本文介紹其工作原理、最新模型如何使其更實用，並透過三個實際系統展示如何構建多模態應用。

嵌入簡介

嵌入是輸入（文本/影像/音訊等）的高維數學空間表示。像text-embedding-3-large或nomic-embed-text這樣的模型將句子編碼為向量。語義相近的輸入在嵌入空間中相互靠近（如“狗”和“小狗”的向量近，“Jira工單”和“派對策劃”的遠）。這就是現代檢索系統的核心——透過向量比較實現語義搜尋，而非關鍵詞匹配。但文本嵌入僅理解文本，若資料為其他格式，則需先轉換或放棄。

共享嵌入空間

假設支援工程師搜尋包含客戶通話錄音、掃描手冊、產品演示影片的知識庫。他搜尋“壓力下閥門密封失效的部分”，答案在40分鐘教學影片的第22分鐘。純文本嵌入無法處理：轉錄只捕獲對話，OCR丟失圖表，字幕只描述臺詞。資訊存在，但格式使其不可訪問。解決方案是將每種模態編碼到共享嵌入空間。關鍵在於訓練一個能跨模態一致工作的模型。

模態對齊的學習方法

對比學習是實現此目標的技術：構建配對資料（照片與說明、音訊片段與文本描述），同時訓練兩個編碼器。配對輸入在嵌入空間中靠近，非配對遠離。每批次中，正確配對排名最高，錯誤配對受罰。經過數億對訓練，編碼器收斂到語義主導格式的幾何空間。

CLIP（OpenAI，2021）首次大規模驗證了影像-文本對齊（4億對）。ImageBind（Meta，2023）擴充套件到六種模態（影像/影片、文本、音訊、深度、熱成像、IMU），透過影像作為錨點，無需所有模態配對資料。然而，“Mind the Gap”（NeurIPS 2022）指出問題：每個編碼器的表示在高維空間中自然聚集於狹窄的錐體，且兩個錐體不完全重疊。對比訓練無法縮小這一差距，因為它只關心相對距離，導致模態間隙影響準確性和下游任務偏差。

下一代模型需要從根本上解決：從零開始聯合訓練所有模態，採用統一架構。現代原生多模態嵌入模型正是如此，使下文示例從理論變為現實。

塑造多模態檢索的決策

設計決策對實際準確性的影響大於模型選擇：

• 原生 vs. 橋接嵌入：常見方法是將所有內容轉為文本後使用文本嵌入模型，但這會承受轉換成本。替代方案是使用從開始就聯合訓練的模型（如Gemini Embedding 2）對每種模態進行原生嵌入，保留音訊音調、PDF佈局、影片視覺動作。
• 非文本資料的分塊策略：文本有自然分塊單元（句子、段落），音訊和影片沒有。標準方法是固定時間視窗加重疊，避免有意義內容被分割。太短丟失上下文，太長檢索塊難以傳遞給生成模型。對於文件，轉換為影像並按頁面索引效果良好，佈局保持不變。
• 維度大小與儲存：多模態工作負載會快速生成向量。若索引100萬個15秒影片片段（3072維），向量索引可達數GB。使用Matryoshka表示學習（MRL）訓練的模型允許在無需破壞嵌入的情況下降低維度（例如3072維向量的前768維仍是可用表示）。建議從小維度開始，根據資料基準測試，必要時再擴充套件。
• 檢索-生成，原生媒體：標準RAG迴圈（嵌入語料庫、嵌入查詢、檢索最近鄰、傳遞給LLM）在這裡同樣有效。若生成模型能直接推理音訊、影像或影片，則傳遞原始媒體而非文本摘要，使生成步驟像嵌入步驟一樣受益於原始內容。

構建多模態系統（三個示例）

Weaviate最近增加了對Gemini Embedding 2（Google首個原生多模態嵌入模型）的支援，可直接在資料庫接入管道中處理。只需宣告哪些欄位是文本、影像、音訊或影片，匯入資料後嵌入自動生成和索引。

我們使用的技術棧：Weaviate（帶multi2vec-google模組）、Gemini Embedding 2（支援MRL的多模態嵌入模型）、Gemini 3 Flash（多模態LLM用於生成步驟）。

1. 無需轉錄的音訊搜尋 問題：有長音訊檔案（播客、訪談、講座），希望基於語義而非轉錄進行RAG。 方法：將音訊分割為短重疊塊並原生嵌入。可用文本或音訊查詢，檢索匹配的音訊片段。示例中使用Robert Frost的詩《Birches》的錄音。 檢索到的音訊位元組直接傳遞給Gemini 3 Flash進行生成。模型基於聽到的內容回答，這與基於文本轉錄的體驗截然不同——詩歌不僅是文字，還包括行間的呼吸、重音和沉默。

2. 將PDF作為複雜視覺文件閱讀 問題：PDF文本提取不僅偶爾出錯，且圖表、註釋、複雜表格和多列格式在純文本中無法清晰表示。 方法：將PDF視為視覺頁面序列，每頁轉換為影像後以image_fields配置索引。嵌入模型接收包含佈局、排版、圖表和表格的頁面。文本查詢按視覺相似性檢索最相關頁面，這些頁面作為影像傳遞給LLM，LLM像人類一樣閱讀它們。預處理管道也因此更簡單。

3. 在影片中找到正確時刻 影片是最難搜尋的媒介，因為影片中最易檢索的對話往往不是最重要的視覺資訊。例如，教程影片中配置面板的操作是視覺答案，而旁白可能只含糊帶過。基於字幕的搜尋找到說了正確詞語的影片，而視覺搜尋找到發生了正確動作的片段。 方法：將MP4檔案用ffmpeg分割為15秒重疊段，保留每塊的影片和音訊流。將每塊編入索引，查詢按語義內容檢索最近塊。生成模型基於原始影片內容推理給出最佳答案。也可用影片片段查詢實現影片到影片搜尋。

何時使用多模態嵌入（以及何時不用）

多模態嵌入並非萬能升級。關鍵判斷：資料中是否存在文本無法承載的訊號？使用時滿足以下條件：

• 音訊包含重要的情感或語調內容。
• PDF有佈局相關資訊（表格、註釋、圖表）且OCR易出錯。
• 影片搜尋需要找到視覺動作/線索，而非僅口語。
• 使用者可能透過示例搜尋：“給我看一些像這樣的東西……”。

若實際資料是純文本，仍應使用文本嵌入，它們在文本檢索任務上效能良好且更便宜、更快。若語料庫是1000萬篇文章，無視覺或音訊成分，新增多模態會增加成本和複雜性而不提高準確性。同時注意儲存成本，建議從較小向量維度（768通常足夠）開始，在擴充套件前進行基準測試。

總結

三個示例共享相同結構：以資料實際到達的形式處理它。無需轉錄步驟丟失音調，無需OCR破壞佈局，無需字幕生成將視覺場景壓扁成單句。這就是“多模態”的實際含義——不僅可跨格式查詢，而且表示本身基於完整訊號，而非僅適合文本形狀的資訊。構建此類系統的工程難度已降至歷史低點。本文附帶的筆記本是真實起點，選擇最接近自己資料的一個（或組合幾個）開始構建吧！