RAG 的第一哩路是把文字變成向量。這篇整理 embedding 在檢索中的位置、三個真正的旋鈕（維度／精度／領域），以及 Mistral 與 Voyage AI（by MongoDB）兩條路線的取捨與選型時機。
做 RAG 時，大家把最多注意力放在 prompt 和選哪個 LLM，但決定「到底找不找得到對的資料」的，是更前面那一步：把文字變成向量的 embedding。模型選錯、維度開太滿、或忘了還有 rerank，後面接什麼大模型都補不回來。這篇把 embedding 在 RAG 的位置講清楚，再比較 Mistral 與 Voyage AI 兩條路線。
先想清楚 embedding 在 RAG 的位置
embedding 做的事只有一件：把 query 和每一段文件 chunk把長文件切成的小段落，通常數百 token，是檢索與 embedding 的基本單位。 放進同一個高維向量空間，讓「語意相近」變成「距離相近」。檢索時算 query 向量和庫裡每個向量的相似度，取最近的 top-k相似度最高的前 k 筆結果，例如 top-20。 幾筆送給 LLM。
關鍵是分清兩件事：embedding 決定「找得到什麼」，rerank檢索的第二段：用更重的模型把粗篩出的候選重新精排，把最相關的排到最前面。 決定「排得對不對」。很多人只做了第一段就說 RAG 不準——其實是少了第二段。
三個真正的旋鈕
選 embedding 不是「挑一個最強的模型」這麼簡單。真正會影響成本與品質的是這三個旋鈕，而且它們常常比「換一家模型」更關鍵。
1. 維度（Matryoshka）
向量的維度越高，能塞進去的語意細節越多、檢索品質通常越好——但每筆向量的儲存、記憶體與比對成本也線性上升。近年的模型支援 Matryoshka一種訓練法，讓向量的前段維度就已濃縮最重要的資訊，因此可以直接截斷到較短維度而只損失少量品質。 表示法：同一個模型輸出的向量，你可以只保留前 256／512／1024／2048 維，品質只掉一點點。Voyage 的 4 系列支援這四段；Mistral 的 codestral-embed 甚至能截到任意整數維度。
2. 精度（量化）
除了「幾維」，還有「每一維用幾個位元存」。量化把 32-bit 浮點數壓成更小的表示（如 8-bit 整數或 1-bit 二元），大幅降低儲存與比對成本，換取少量品質。把預設的 float32 換成 int8（省 3/4）甚至 binary（1 bit，省 31/32），儲存與比對速度都大降，品質只微降。這是壓低向量庫成本最有效的槓桿，卻最常被忽略。
下面這個互動可以親手拖：把維度與精度往下調，看儲存怎麼崩塌式地變小。
3. 領域
通用模型對一般文章夠用，但程式碼、金融、法律這類語料有自己的詞彙與結構，領域專用模型的檢索命中率會明顯較高。Voyage 有 voyage-code-3、voyage-finance-2、voyage-law-2；Mistral 則用 codestral-embed 專攻程式碼。選錯領域，維度開再高也救不回來。
Mistral 路線
線上 API 通用 + 程式碼 歐洲公司
法國 Mistral 提供兩個 embedding 模型，走「簡單、少旋鈕」的路線：
| 模型 | 維度 | Context | 精度選項 | 價格 | 定位 |
|---|---|---|---|---|---|
mistral-embed | 1024（固定） | 8,192 token | float32 | 約 $0.10 / 1M token | 通用文字 |
codestral-embed | 1536 預設，最高 3072，可截任意維 | 8,192 token | float32 / int8 / uint8 / binary | 約 $0.15 / 1M token | 程式碼專用 |
mistral-embed 的向量是 norm 1（單位長度），所以 cosine similarity、dot product、Euclidean distance 三者等價，比對邏輯怎麼寫都不會錯。codestral-embed 則把維度與精度的旋鈕開好開滿，適合要壓儲存的大型程式碼庫。
import { Mistral } from "@mistralai/mistralai";const client = new Mistral({ apiKey: process.env.MISTRAL_API_KEY });const res = await client.embeddings.create({ model: "mistral-embed", inputs: ["把這段話變成向量。", "還有這一段。"],});// res.data[i].embedding 是 1024 維的 number[]const vectors = res.data.map((d) => d.embedding);選 Mistral 的常見理由是資料落地：歐洲公司、有 EU 資料處理選項，對受 GDPR 或資料主權要求的專案較好交代。旋鈕少也意味著決策負擔小。
Voyage AI 路線（by MongoDB）
線上 API 全系列 + 領域模型 綁 Atlas
Voyage AI 專做檢索模型，產品線最完整：通用、程式碼、金融、法律、多模態，外加 reranker。
| 模型 | 維度 | Context | 定位 |
|---|---|---|---|
voyage-4 / voyage-4-large / voyage-4-lite | 256 / 512 / 1024 / 2048 | 32,000 token | 通用（large 品質最高、lite 便宜快） |
voyage-4-nano | 128 / 256 / 512 | 32,000 token | 開放權重、極輕量 |
voyage-code-3 | 256 / 512 / 1024 / 2048 | 32,000 token | 程式碼 |
voyage-finance-2 | 1024 | 32,000 token | 金融 |
voyage-law-2 | 1024 | 16,000 token | 法律 |
rerank-2.5 | —（輸出相關性分數） | — | 精排用的 reranker |
4 系列與 voyage-code-3 都支援 Matryoshka 維度截斷與 int8 / binary 量化，把前面講的兩個旋鈕開好；32,000 token 的 context 也比 Mistral 的 8,192 寬鬆，長文件切 chunk 的彈性更大。
身世與綁定
MongoDB 於 2025 年 2 月 24 日以約 2.2 億美元收購 Voyage AI，現為「Voyage AI by MongoDB」，深度整合進 MongoDB Atlas Vector Search。多數模型有 200M token 免費額度（領域模型 50M），計費綁定你的 Atlas 帳戶。如果你的向量庫本來就打算放 Atlas，這個整合是實打實的順路；反過來說，也是一種生態綁定。
Voyage 最被低估的一塊其實是
rerank-2.5。embedding 負責把候選撈出來，reranker 負責把對的排到最前面——兩段一起用，檢索品質常常比換更貴的 embedding 模型還有感。
什麼時候選哪個
判斷點通常不是「哪家分數高」，而是這幾件事：語料領域、資料要放哪、要不要壓成本。下面把常見情境收成一張互動選型卡。
建議的落地順序
先用預設維度跑一版能檢索的 POC
挑一個通用模型（
voyage-4或mistral-embed）、用預設維度與float32，先把「query 進來、撈得到相關 chunk」這條路打通，不要一開始就糾結量化。用你自己的資料評估領域模型
拿真實語料做小規模 A/B：通用 vs 領域模型（程式碼／金融／法律）。因為換模型要整庫重算，這個評估越早做越省。
上線前補上 rerank
在 embedding 粗篩之後接一個 reranker（如
rerank-2.5）做精排。這一步對「答得準不準」的提升，往往比升級 embedding 模型更有感。要降成本時，才動維度與量化
知識庫規模上來、儲存或延遲吃緊時，再用 Matryoshka 降維 +
int8／binary量化把成本壓下來——這時你已經有真實資料可以量測品質掉多少。
回到開頭：embedding 決定 RAG 找得到什麼，rerank 決定排得對不對，維度與精度決定你付多少成本。Mistral 走「少旋鈕、歐洲落地」，Voyage 走「全系列 + 領域模型 + rerank + 綁 Atlas」。先問你的語料是什麼領域、資料要放哪，答案通常就浮出來了。
延伸閱讀
- Mistral — Embeddings 概覽
- Mistral — Code Embeddings（
codestral-embed） - Voyage AI — 官方文件
- Voyage AI by MongoDB — 文字 embedding 模型清單
- MongoDB — 宣布收購 Voyage AI（2025/02/24）
內容整理於 2026 年 7 月 · 模型、維度、額度與價格隨時異動，請以各官方文件為準