Embeddings 與向量資料庫實務：模型選型、ANN 索引與生產考量¶

整理自公開評測與廠商技術文件（見文末），2026-06-20。RAG 系列一直在用「把文字變向量、丟進向量庫、做相似度檢索」，本頁把這層補滿：embedding 怎麼選、向量庫怎麼比、ANN 索引在 trade 什麼、上生產要顧什麼。

實證標記：〔評測〕= 出自 MTEB 等公開評測；〔廠商〕= 出自廠商自報基準（利益相關，當參考非定論）；〔實務〕= 業界慣例或本人整理。預設 under-claim。

Embedding：把語意壓成向量¶

Embedding 模型把文字轉成定長向量，語意相近的文字在向量空間中距離相近。RAG 的檢索品質上限很大程度由 embedding 決定——撈不到對的東西，後面 rerank、生成再強都救不回。〔實務〕

怎麼選 embedding 模型¶

考量	說明
檢索品質	對你自己的語料測 recall@K，別只看排行榜
語言	中文/多語要選有對應訓練的模型（看 C-MTEB 等）
維度	維度高通常更準但更吃儲存與計算；部分模型支援 Matryoshka 可截短維度換取效率
長度	長文檢索看 LongEmbed 類評測；context 長度要夠
部署	API（Voyage/OpenAI/Cohere）省事但資料外送；開源自託管可控但要維運
成本	embedding 要對全語料算一次、更新還要重算，量大時成本顯著

〔評測〕MTEB（及 C-MTEB / LongEmbed / SEB / AIRBench 等變體）是現在主流的 embedding 公開評測，涵蓋多任務多領域。選型先看排行榜縮小範圍，再對自家語料實測。

〔廠商〕廠商基準要當「參考」而非定論：例如 Voyage 自報 voyage-3-large 在其評估領域上勝過 OpenAI text-embedding-3-large、Cohere embed-v3——但這是利益相關方的數字，換你的語料未必成立。底線：排行榜挑候選、自家資料定勝負。

向量資料庫：存向量 + 快速找最近鄰¶

向量庫的核心工作是：存大量向量，並在查詢時快速找出最相近的 K 個。市場逐漸收斂到幾家主流：〔廠商〕〔實務〕

向量庫	定位	備註
Pinecone	全託管 SaaS	省維運、按量計費
Weaviate	開源 + 託管	內建混合檢索、模組化
Milvus	開源、衝規模	為生產級大規模設計
Qdrant	開源、輕量	Rust、過濾能力強

〔廠商〕延遲量級（廠商自報、特定設定）：Milvus 在百萬級向量可達 p95 < 30ms；Weaviate 多數 RAG 工作負載 sub-100ms。當「這個量級辦得到」看，不要當你環境的保證值——延遲高度取決於資料量、維度、索引參數與硬體。

〔實務〕選型口訣：只有你自己用、量不大 → 嵌入式（如 Qdrant/SQLite-vec 類）或現有 DB 的向量擴充就夠；要團隊共用、衝規模、要 SLA → 託管 SaaS 或 Milvus。別為了「看起來專業」一開始就上重型叢集。

ANN：用「近似」換速度¶

精確找最近鄰（暴力比對所有向量）在大規模下太慢。向量庫用 ANN（Approximate Nearest Neighbor）——犧牲一點點準確率，換取數量級的速度提升。兩大主流索引：〔實務〕

索引	原理	取捨
HNSW（階層可導航小世界圖）	建多層圖、從稀疏層往密集層逐步逼近	recall 高、查詢快；吃記憶體、建索引較慢
IVF（倒排檔）	先把向量分群，查詢只比對相關群	省記憶體、建得快；recall 與 `nprobe`（查幾群）成本權衡

常見再疊 量化（quantization） 壓縮向量（如 PQ 乘積量化、二值量化）進一步省記憶體，代價是再損一點精度。〔實務〕

〔實務〕關鍵心法：ANN 的參數（HNSW 的 ef、IVF 的 nprobe）是 recall ↔ 延遲 的旋鈕。調這些前，先確定你量得到 recall（要有標準答案集），否則是在沒有儀表板的情況下盲調。見 LLM Evaluation 實務。

Metadata 過濾：別只靠向量¶

生產級檢索很少純靠向量相似度。把 source、date、authority、region、PII flag 等 metadata 一起存進向量庫，查詢時先過濾再比相似度，能同時顧到時效、合規與信任。這也是 RAG 進階系列 freshness 一節的基礎。〔實務〕

上生產要顧的事〔實務〕¶

Embedding drift：換 embedding 模型／模型版本更新 → 舊向量與新向量不可混用，要全量重嵌。把「重嵌成本」當常態維運。
索引更新：文件變動要 re-embed delta 並更新索引；監控「文件更新 → 進索引」的延遲並給 SLA。
多租戶：多用戶/多專案共用時的隔離（namespace、metadata 過濾、權限）。
延遲預算：sub-50ms 級需求會反過來決定索引型別與參數；先定延遲目標再調 ANN。
成本：embedding 計算（全語料 + 更新）＋向量庫儲存/查詢，量大時都是真錢，選型時就要算。

落地順序〔實務〕¶

先定檢索評估（recall@K 標準集）——沒有它後面全在盲調。
用 MTEB 縮小 embedding 候選 → 對自家語料實測選定。
向量庫按「規模 + 是否共用 + SLA」選，別過度工程。
ANN 參數對著 recall↔延遲旋鈕調；必要時加量化省記憶體。
把 metadata 過濾與 re-embed 維運從第一天就設計進去。

延伸閱讀（本站）¶

RAG 完整指南：原理、架構與實作 — embedding/向量庫在整體流程的位置
RAG 進階系列 — hybrid search、reranking、freshness
LLM Evaluation 實務 — recall@K 與檢索評估