多模態嵌入與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破壞佈局，無需字幕生成將視覺場景壓扁成單句。這就是“多模態”的實際含義——不僅可跨格式查詢，而且表示本身基於完整信號，而非僅適合文本形狀的信息。構建此類系統的工程難度已降至歷史低點。本文附帶的筆記本是真實起點，選擇最接近自己數據的一個（或組合幾個）開始構建吧！