檢索品質不是模型分數，而是你的語料長什麼樣
OpenRouter 在 2026 年 9 月 23 日發布的 embedding 模型整理，開頭就把問題定義得很清楚：embedding 模型決定你的檢索系統「找得到什麼」。它把輸入轉成向量，讓語意相近的內容彼此靠近，於是應用可以按意思檢索，而不是靠字面比對。
這篇整理的價值不在排行榜，而在它把選型拆成「你要搜什麼材料」。英文知識庫、多語客服紀錄、原始碼倉庫、圖文混合集合，需求各不相同；向量維度、context 長度、是否公開權重、價格，也都會改變決定。
短名單怎麼來的，以及它沒有證明什麼
根據這篇整理，OpenRouter 先用自家目錄確認可用性、context window、輸入型態與 prompt 價格，再查供應商文件中的能力與 benchmark，最後對 19 個模型送出批次請求，共執行 28 項檢查，涵蓋批次輸入、可調維度、圖片輸入、圖文輸入與錯誤處理。
這裡有一條容易被忽略的界線：這些請求確認的是 API 相容性，不是檢索品質。OpenRouter 也明講，他們排除了回應時間，因為每個模型只收到一個小請求，服務條件不同。真正該決定部署哪一個模型的，是你自己的標註檢索結果。
依輸入型態分流的建議
OpenRouter 的短名單按用途給出起點。英文 RAG 從 openai/text-embedding-3-small 開始，理由是 prompt 價格低、8,192 token context，且輸出維度可調。輸入超過 8,192 token 時，可測試 voyageai/voyage-4-large，它有 32,000 token context 與四種可選維度，且與其他 Voyage 4 層級相容。
需要公開權重的多語檢索，短名單指向 qwen/qwen3-embedding-8b：支援超過 100 種語言、32,768 token context、權重公開。程式碼檢索用 voyageai/voyage-code-4；圖文檢索則以 google/gemini-embedding-2 為首選，voyageai/voyage-multimodal-3.5 是第二個經過驗證的選項。
低價與免費路線也各有代表：perplexity/pplx-embed-v1-0.6b 是短名單中付費文字模型裡 prompt 價格最低者；nvidia/nemotron-3-embed-1b:free 是免費文字 embedding 路線，context window 為 32,768 token。
維度與 endpoint 是兩個實際的架構變數
維度直接影響索引大小。OpenRouter 指出，同樣的數值格式下，4,096 維向量使用的原始儲存是 1,024 維向量的四倍；openai/text-embedding-3-small 預設 1,536 維，是 text-embedding-3-large 預設 3,072 維的一半。他們建議第一次評估先保留預設維度，只有在預設已達檢索目標、但儲存或搜尋成本仍是限制時才縮小。
另一個變數是 endpoint。Qwen3 Embedding 8B 的模型頁列出 32,768 token context，但限制是按 endpoint 設定：2026 年 9 月 11 日時，DeepInfra 與 SiliconFlow 的 endpoint 列 32,768 token，Nebius 列 32,000。若輸入超過 32,000 token，就要檢查 endpoint 清單並固定到限制較大的供應商。這類「同一個模型、不同路由」的取捨，和我們在把模型分層寫進架構談過的架構決策是同一類問題：分數相同，落地條件不同。
先做小規模評估，再決定要不要重建索引
OpenRouter 給的操作建議很樸素：至少用兩個候選模型，跑你自己的標註查詢與文件，追蹤每個模型取回相關 chunk 的頻率，然後才建置或重建大型索引。
Voyage 4 系列提供一個降低切換成本的做法：Voyage 表示 4 系列產生的 embedding 彼此相容，因此可以在既有索引上測試另一個層級。但相容的向量空間只移除重建需求，不保證檢索結果相同，仍要在代表性樣本上驗證。
價格與路由會變動。OpenRouter 提醒，供應商可以新增或移除路由，prompt 價格也可能改變；開始大型索引或重建工作前，應以當下的模型頁為準，若模型頁與指南不同，以模型頁為準。這篇整理是選型的起點，不是可以跳過評估的理由。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。