核心概念： 嵌入模型（Embedding Model）決定了「檢索是否找得到正確東西」。在企業級 RAG 中，嵌入模型的選擇會同時影響 檢索精度、延遲與成本，並牽動向量維度、記憶體占用、索引形態與部署合規。

學習內容：

• 開源與商用嵌入模型的功能特性與差異
• 多語言、跨語言（cross-lingual）檢索要點
• 成本模型（API/自建）、維度/儲存估算與效能優化
• 實務評估矩陣、決策樹與一鍵測試框架

一、選型維度與評估矩陣

請用下表做第一輪篩選（打勾或 1–5 分制），針對你的業務建立可量化決策：

建議在你的資料上做 A/B 小樣本比武：同一批 query + 標注答案，統計上述指標。

二、模型族譜與典型特性（舉例）

不追求「最新名單」，而是讓你知道 該挑哪一類。下面每一欄都可替換成你團隊考慮的候選。

維度僅作落點參考：常見分佈在 384–1536–3072。你只需記住：維度越大，儲存與檢索成本越高。

三、成本與資源估算（實務公式）

• 向量儲存估算： Size ≈ N_chunks × D × bytes_per_dim

  • 以 float32 = 4 bytes，float16 = 2 bytes 計
  • 例：300 萬 chunks × 768D × 2 bytes ≈ 4.6 GB（純向量，不含 metadata/HNSW 圖）

• 索引額外開銷：HNSW 需額外圖結構記憶體（常與 N 成正比）；IVF-PQ 需訓練碼本但可大幅壓縮。

• 生成成本：若 embedding 用 API 計價，每次增量索引 與 線上查詢改寫/擴展 都會燒錢。可將離線產生與線上查詢分離以控管成本。

• 延遲管控：上線 SLA 常看 P95/P99；批次化編碼 與 async pipeline 可顯著降低均攤延遲。

四、多語言與跨語言實務

• 同語言（zh→zh）：通用向量模型已足夠，搭配中文斷詞、NFKC 正規化、數字格式統一。
• 跨語言（zh→en）：優先選 多語言嵌入；若語言混雜嚴重，加入 關鍵字/規則 與 翻譯或查詢擴展。
• 專有名詞/代碼/條文號：純語義模型易漏；用 Hybrid Retrieval（BM25 + Vector） 或 稀疏稠密融合（RRF/加權）。
• 拼寫/異體字/轉寫：加前處理（標準化、同義詞詞庫、繁簡轉換），或在查詢側做 Query Expansion。

五、決策樹（落地思路）

是否必須私有化/不外流？
  ├─ 是 → 優先開源自建（BGE/E5/GTE 等）+ 量化/蒸餾 + HNSW/IVF-PQ
  └─ 否 → 商用 API/雲端優先（上線快），仍保留遷移路徑

是否需要跨語言檢索？
  ├─ 是 → 多語言模型 + Hybrid 檢索 + 查詢改寫
  └─ 否 → 單語最佳模型（延遲與成本更優）

文檔是否長且結構化（法律/手冊/規範）？
  ├─ 是 → 長文本友好模型 + Parent/Chunking 優化 + Rerank
  └─ 否 → 通用模型 + 適中維度即可

SLA 與成本哪個更硬？
  ├─ SLA 嚴格 → 維度小/吞吐高的模型 + 索引壓縮 + Cache
  └─ 成本敏感 → 開源 + 量化（FP16/INT8/IVF-PQ）+ 批次化編碼

六、與 Rerank、Hybrid 的搭配策略

• 若你已導入 Cross-Encoder Rerank，可以選擇 較便宜/較低維度 的嵌入模型做粗排，讓重排負責精度。
• 若你的資料含大量 代碼/編號/條文號，務必加入 BM25 或稀疏特徵，再用 RRF/加權融合 合併。
• 查詢端可加 Query Expansion/Rewrite（同義詞、關鍵詞補全），顯著提升 Recall@k。

七、常見坑與校驗清單

• 相似度度量不一致：模型預設 cosine，但你的向量庫用 L2 → 先做單位向量歸一化。
• 向量維度錯配：切換模型忘了重建索引 → 維度要與索引一致。
• 長文截斷：輸入超長未切分 → 先做合理 Chunking + Parent Retriever。
• 多語言混雜：只用單語模型 → 改多語或做查詢改寫。
• 評估失真：只看平均不看 P95 → 線上要盯 P95/P99 與 QPS。
• 成本超標：批量上線重編嵌入用 API → 優先離線批處理，或 自建 + 量化。

考考你

1. 若你已經導入 Rerank，在不降精度的前提下，嵌入模型是否可以 降階（更低維/更便宜）？

2. 你的業務是 跨語言 嗎？若是，混合檢索與查詢改寫要怎麼搭配，才能保持低延遲？