4.12 Embedding model 內部：訓練、選型、in-domain fine-tune
RAG 章節定義了 retrieval + augmentation 的二段式結構、但 retrieval 階段背後的 embedding model 怎麼運作、怎麼選、什麼時候該換、什麼時候該自己 fine-tune、這些決策直接影響 RAG 品質。本章把 embedding model 的訓練機制、評估方法、實務選型展開。
本章目標
讀完本章後、你應該能：
- 解釋 embedding model 跟 base LLM 的訓練差異。
- 看到 MTEB / BEIR 分數時、知道對自己場景的意義。
- 對自己 domain 選對 embedding model（通用 vs code vs multilingual）。
- 判斷「需要 fine-tune 自己的 embedding model」的時機跟方法。
Embedding model vs LLM 的訓練差異
兩者底層架構可能類似（都用 Transformer）、但訓練 objective 完全不同：
| 維度 | LLM（如 Llama / Gemma instruct） | Embedding model（如 bge-large、jina-v3） |
|---|---|---|
| 訓練 objective | Next-token prediction + RLHF | Contrastive learning |
| 輸出形式 | 一連串 token | 一個固定維度的向量（如 768、1024） |
| 訓練資料 | Trillion-token 通用文字 | 億級的 (query, doc) 正向對 |
| 用法 | Prompt → response | Text → vector |
| Pretrained 起點 | 從 scratch 或繼承 base | 通常從 base LLM 抽 hidden state 開始 |
關鍵理解：不能拿任意 LLM 的最後 hidden state 當 embedding — LLM hidden state 是為「預測下一個 token」優化、不為「相似度比較」優化。要再經過 contrastive learning fine-tune 才能當 embedding model 用。
Embedding model 的典型訓練 pipeline：
1Stage 1: 從 base model 開始（如 BERT、RoBERTa、Mistral、Llama）
2 ↓
3Stage 2: Contrastive pre-training
4 用大量 weak supervised pair（如 Reddit title-body、StackExchange QA）
5 InfoNCE loss、batch size 大、hard negative mining
6 ↓
7Stage 3: Supervised fine-tune
8 用標註好的 (query, relevant_doc) pair
9 來源如 MSMARCO、Natural Questions
10 ↓
11Stage 4（可選）: Task-specific instruction tuning
12 讓模型懂「task description」、可針對不同 retrieval 任務切換
13 代表：bge-large、e5-mistral-7b-instructStage 4 的「instruction-tuned embedding」是 2024 後流行的設計：query 前加「Represent this sentence for retrieving relevant passages:」這類前綴、embedding model 學會依任務調整向量。
選型維度
主流 embedding model 的選型維度：
1. Domain 相符
| Domain | 推薦模型 | 為什麼 |
|---|---|---|
| 通用英文 | bge-large-en-v1.5、mxbai-embed-large-v1 | 通用 corpus、MTEB Retrieval 高分 |
| 通用多語 | jina-embeddings-v3、bge-m3、multilingual-e5 | 多語 pretrain、中日韓阿等支援 |
| Code（讀 / 寫 code） | jina-embeddings-v2-base-code、voyage-code-3 | code corpus 訓練、語意（函式名、註解）+ syntax 結合 |
| 中文 | bge-large-zh、Conan-embedding | 中文 corpus 為主 |
| 跨語言（中英混合） | jina-embeddings-v3、multilingual-e5 | 跨語言對齊訓練、中英 query 找對方語言 doc |
2. 大小（模型大小 / 向量維度）
| Tier | 模型大小 | 向量維度 | Latency / 記憶體 | 適合場景 |
|---|---|---|---|---|
| 小（< 200M） | nomic-embed (137M)、all-MiniLM (23M) | 384-768 | 快、本機 CPU 可跑 | 本地 RAG、簡單 retrieval |
| 中（200-500M） | bge-large (335M)、mxbai-embed-large | 1024 | 中、需要 GPU 或 fast CPU | 主力 RAG、品質敏感場景 |
| 大（500M-7B） | e5-mistral-7b、Linq-Embed-Mistral | 4096 | 慢、需要 GPU | 高品質、雲端、Reranking 場景 |
| 雲端 API | OpenAI text-embedding-3、voyage-3 | 1024-3072 | 網路 latency + API 成本 | 雲端 RAG、高 QPS |
3. Context window 上限
不同 embedding model 對單次 embed 的 token 上限不同：
| 模型 | Context limit |
|---|---|
| 早期 sentence-transformers | 256-512 tokens |
| bge-large / mxbai-embed | 512 tokens |
| nomic-embed-text-v1.5 | 8192 tokens |
| jina-embeddings-v3 | 8192 tokens |
| voyage-3 | 32K tokens |
事實查核註：本節所列具體型號（bge-large-en-v1.5、jina-embeddings-v3、nomic-embed-text-v1.5、voyage-3 等）、向量維度、context limit、訓練資料 domain、MTEB / BEIR 排名 — 都是 2026/5 主流版本的估計、各模型升級節奏快、引用前以 MTEB Leaderboard 跟對應 model card 當前狀態為準。
選擇影響 chunking 策略（見 4.1 RAG 的 chunking 段）：短 context embedding 要切細、長 context embedding 可保留更完整段落、但內部 attention 對長段中段仍可能 lost-in-the-middle。
4. Cosine similarity 設計
部分 embedding model 訓練時就 L2-normalized、用 cosine = dot product；部分沒 normalize、要自己處理：
| Model | Normalize 預設 | 推薦 distance metric |
|---|---|---|
| bge-large、mxbai-embed | 已 L2-normalize | Dot product（高效、結果同 cosine） |
| nomic-embed-text | 已 L2-normalize | Dot product |
| OpenAI ada-002 / 3 | 已 L2-normalize | Dot product |
| 自訓練 / 早期模型 | 未 normalize | Cosine similarity |
詳細見 vector-norm 跟 dot-product 卡片。
評估：MTEB 跟自己 domain 的對齊
MTEB 是現在挑選 embedding model 最常用的 leaderboard、但要正確讀：
- 看 Retrieval 子分數、不是 Overall：MTEB 含 8 大類、跟 RAG 最直接相關的是 Retrieval 跟 Reranking
- 跟自己 domain 對齊：MTEB 通用 corpus、自己 domain 可能跟 MTEB 落差大
- In-domain benchmark 才是 final test：用自己工作流的真實 query 跟 expected doc、自建小型評估集（如 100-200 對）、看候選 embedding model 的 hit rate / nDCG
In-domain 評估的最小可行流程：
1# 偽代碼
21. 蒐集 50-100 個 query + expected_doc（已知答案的對）
32. 對 candidate embedding models 各跑：
4 - embed 所有 doc（含 expected 跟 distractor、~1000 個 distractor）
5 - embed 每個 query
6 - 算 query-doc similarity、看 expected 是否在 top-5 / top-10
73. 比較 candidate 的 hit_rate@5 / hit_rate@10跑完這個再決定用哪個 embedding model、比看 MTEB leaderboard 可靠很多。
實務選型的 constraint 優先序
上面四個維度（domain / 大小 / context / cosine 設計）跟 MTEB 評估是「品質軸」— 哪個 embedding model 最能解你的 retrieval 問題。但實際選型時，品質軸之前通常有一組工程 constraint 先砍掉大量選項，剩下的候選才進品質比較。
常見的工程 constraint 依砍選項力度排序：
- Runtime 可用性：推論伺服器支援哪些模型？Ollama 目前原生支援
nomic-embed-text、mxbai-embed-large、snowflake-arctic-embed等，但不支援所有 Hugging Face 模型。用 cloud API（OpenAI / Cohere / Voyage）則受 vendor 綁定跟成本約束。這一條通常砍掉最多選項。 - 體積 / 記憶體預算：個人機器常駐 embedding model 跟 chat model 共用記憶體。137M 的
nomic-embed-text跟 7B 的e5-mistral在記憶體佔用上差一個數量級。 - 已有驗證基線：團隊或前期 demo 已用某個模型跑過、retrieval 品質已確認可用。換模型要重建 index + 重新驗證，成本不只是 MTEB 分數比較。
- 向量維度的 storage 成本：維度影響 index 大小（n × d × 4 bytes）跟 brute-force search 延遲。768 維 vs 1024 維在小規模無感，但 100K+ chunks 時差異開始有意義。詳見 4.22 RAG storage 工程。
實務流程是：先用 constraint 1-3 收窄到 2-3 個候選，再跑 in-domain benchmark（上段的 hit rate 流程）做最終決定。直接從 MTEB leaderboard 挑最高分的模型、到實際場景才發現 runtime 不支援或體積太大，是常見的繞路。
何時該 fine-tune 自己的 embedding model
通常不該 fine-tune embedding model — 用現成的 bge-large、jina-v3 已經很好。但下列情境值得評估：
Domain 跟通用 corpus 差距大：
- 醫療 / 法律 / 金融的專業術語、通用 embedding model 對「同義詞」「同概念不同表述」recall 差
- In-domain term frequency 跟通用 corpus 差距大（如「IRA」在金融 vs 政治語境）
In-domain benchmark hit rate 顯著低於通用 benchmark：
- 用 MTEB 高分模型、in-domain hit rate@5 仍 < 60%
- 換多個候選 embedding model、所有都類似低分
有足夠 in-domain (query, doc) 對：
- Fine-tune 需要至少數千對、最好 1-10 萬對
- 對少於 1000 對的場景、fine-tune 收益通常低於數據增強 / 提升 retrieval pipeline
Fine-tune 流程（詳細）：
Step 1：蒐集 in-domain training data
三種主流形態：
| Format | 結構 | 蒐集難度 |
|---|---|---|
| Positive pair | (query, relevant_doc) | 容易（從 click log、QA pair） |
| Triplet | (anchor, positive, negative) | 中（要明確 negative） |
| Score / label | (query, doc, relevance_score) | 難（要人工標） |
實務多從 positive pair 開始（InfoNCE loss 在 batch 內自動取其他樣本當 negative）、品質提升再進 triplet（hard negative mining）。
Step 2：選 base model
選擇看資料量跟硬體：
| 起始 base model | 適合資料量 | 適合硬體 |
|---|---|---|
| sentence-transformers MiniLM | 1K - 50K 對 | 一般 CPU / 小 GPU |
| BGE-base / bge-small | 10K - 100K 對 | 16GB+ GPU |
| BGE-large / jina-v3 / mxbai | 50K+ 對 | 24GB+ GPU |
| E5-Mistral-7B-instruct | 100K+ 對 | 多卡 / A100 |
選擇原則：base model 在 generic benchmark 越強、fine-tune 後上限越高、但訓練成本越高。
Step 3：Loss 選擇
| Loss | 機制 | 適合 |
|---|---|---|
| MultipleNegativesRankingLoss | InfoNCE 變體、batch 內其他樣本當 negative | Positive pair only、大 batch |
| Triplet loss | 直接比 (anchor, positive, negative) 距離 | 有明確 triplet、傳統選擇 |
| Cosine similarity loss | 預測相似度標籤 | Score / label data |
| Contrastive tension loss | 對比學習變體、效果好 | 大規模 fine-tune |
實務 default：MultipleNegativesRankingLoss + batch size 64-128（越大 negatives 越多、品質越高）。
Step 4：Hard negative mining
純隨機 negative（batch 內其他樣本）容易、但 hard negative（看似相關但實際無關）才能 push 模型品質：
11. 用初版 fine-tuned model 對每個 query 跑 retrieve top-50
22. 對每個 query 的 top-50：
3 - 真正 relevant doc（known positive）→ skip
4 - 其他 → 候選 hard negative
53. 篩 hard negatives（LLM-as-judge 或人工確認真的「看似相關但不對」）
64. 用 (query, positive, hard_negative) 重訓
75. Iterate 2-3 輪Hard negative 是 embedding fine-tune 品質的關鍵差距 — 沒做的 fine-tune 通常 plateau 早、做了的可超越通用 model。
Step 5：LoRA fine-tune 而非 full fine-tune
跟 LLM fine-tune 一樣、embedding model fine-tune 也用 LoRA：
| 方式 | 訓練成本 | 通用能力保留 | 推論方式 |
|---|---|---|---|
| Full fine-tune | 高 | 易 catastrophic forgetting | 部署新權重 |
| LoRA fine-tune | 低 | 保留好 | 載入 base + adapter |
主流 framework：sentence-transformers + PEFT、Hugging Face Transformers + LoRA library。
Step 6：Evaluate
不只看 training loss、要實測：
11. Build in-domain test set（held-out、跟 training 完全分開）
22. 算 [hit_rate@K](/llm/knowledge-cards/retrieval-recall/)（query 的 expected doc 是否在 top-K retrieval result）
33. 跟「base model 未 fine-tune」對比：
4 - Fine-tune 後 hit_rate@5 提升 ≥ 10 percentage point → 成功
5 - 提升 < 5pp → fine-tune 沒效益、不如優化 retrieval pipeline
64. 確認沒崩通用能力：在 MTEB 跑、看主流 retrieval 任務沒大降失敗模式
| 失敗 | 緩解 |
|---|---|
| 資料太少（< 1000 對）、模型沒學到 | 數據增強（用 LLM 生 synthetic pair）、改用 prompt + RAG |
| 訓練 loss 降但 hit_rate 沒升 | Hard negative 不夠、要重 mine |
| In-domain 提升但通用能力崩 | 加 mixed dataset（80% domain + 20% MTEB） |
| Embedding dim 不能改 | Base model 已固定 dim、自己訓 from scratch 才能改 |
| 部署時跟 base model 衝突 | LoRA adapter merge 進 base 後部署、或同時 serve 兩版 |
跟 LLM 的整合：retrieval pipeline
完整 RAG pipeline 裡 embedding model 的位置：
1[Ingestion 階段（離線）]
2 Documents
3 ↓ chunking
4 Chunks
5 ↓ embedding model
6 Chunk vectors → 存進 vector DB
7
8[Query 階段（線上）]
9 User query
10 ↓ embedding model
11 Query vector
12 ↓ vector DB ANN search
13 Top-K chunks
14 ↓ (optional) reranking
15 Top-N chunks
16 ↓ augment LLM prompt
17 LLM response關鍵設計決策：
- Embedding model 一致性：ingestion 跟 query 必須用同個 model（換 model = 整批 re-embed）；chunk vectors 存進 vector DB 之後的 index 結構、維度成本與生命週期見 4.22 RAG storage 工程
- Chunking 策略對齊 embedding context：見 4.1 RAG chunking
- Reranking model 通常用 cross-encoder：embedding model 是 bi-encoder（query 跟 doc 分開 embed）、reranker 是 cross-encoder（query + doc 一起算）、品質更高但慢、適合在 top-50 → top-5 之間做 reranking
- Hybrid retrieval：BM25（字面）+ embedding（語意）混用、用 RRF（Reciprocal Rank Fusion）合併、是 production 常見配置
本地 vs 雲端 embedding
| 維度 | 本地（如 nomic-embed） | 雲端（如 OpenAI text-embedding-3） |
|---|---|---|
| 隱私 | 完全本地、no exfil | API 送 doc、依政策 log |
| 成本 | 一次硬體 + 電費 | 按 token 計費、長期可累積 |
| 品質 | bge-large / jina-v3 已接近雲端旗艦 | 略高（旗艦如 voyage-3 仍領先） |
| Latency | 視硬體、本地 SSD 快 | 網路 latency |
| 多語 / domain | 開源選擇多、可挑 domain-specific | API 是通用、不一定最佳 domain match |
寫 code 場景的判讀：
- codebase 內部 RAG（NDA / 機密 code）：本地 embedding 必選
- 個人開源專案 RAG：本地 embedding 是合理 default、簡單、free
- 公司內部 RAG（需高品質、量大）：評估 voyage-3 / OpenAI v3 vs 本地 bge-large
- 產品級 production RAG：通常雲端 API + 自己 fine-tune 的 embedding（最佳品質）
何時過時 / 何時不過時
不會過時的部分：
- Contrastive learning 是 embedding model 的核心訓練 paradigm
- MTEB 作為通用 embedding 評估的角色
- 「跟自己 domain 對齊」的 in-domain benchmark 必要性
- Bi-encoder vs cross-encoder 的分工（retrieval vs reranking）
- Hybrid retrieval（BM25 + embedding）的設計
會變的部分：
- 具體 embedding model（bge → bge-v2 → …、jina-v3 → v4 → …）
- MTEB leaderboard 排名（每月變）
- Instruction-tuned embedding 的 prompt format（標準化中）
- Embedding model 的 context window 上限（推升中）
- Long-context embedding 的研究（如 ColBERT-style late interaction）
下一章
沒 backend 的靜態場景（個人 blog / docs site）做 embedding 搜尋的 deployment 選擇見 4.16 靜態 / serverless RAG deployment。
下一章：4.13 Eval 設計座標系、看 eval 三軸八象限 meta 框架（先選軸再選工具）、再進 4.14 Benchmarking 與評估方法論 看具體 benchmark 設計。