前言

前處理 Pipeline 準備好之後，今天正式進入 Indexing 階段的核心：Embedding——把文字轉換成能夠計算語意相似度的向量。

什麼是 Embedding？

Embedding 是把一段文字映射成一組固定維度的數值向量（例如 1536 維），語意相近的文字，在向量空間中的距離也會相近。

"貓咪很可愛"     → [0.12, -0.45, 0.88, ...]
"小貓非常討喜"    → [0.15, -0.42, 0.85, ...]  ← 與上面向量距離很近
"今天股市大跌"    → [-0.67, 0.31, -0.02, ...] ← 與上面向量距離很遠

這就是 RAG 檢索能夠「理解語意」而不只是「比對關鍵字」的關鍵技術。

常見 Embedding 模型比較

選型考量因素

1. 多語言支援：如果知識庫是中文為主，需確認模型在中文語料上的表現
2. 成本：API 型 Embedding 通常按 token 計費，知識庫量大時成本不容忽視
3. 維度大小：維度越高通常表達力越強，但儲存與計算成本也越高
4. 是否需要本地部署：涉及敏感資料時，可能需要選擇能離線運行的開源模型
5. 與檢索任務的契合度：部分模型（如 Voyage）專門針對檢索場景做過優化，效果通常優於通用型 Embedding

實作：呼叫 Embedding API

import openai

def get_embedding(text, model="text-embedding-3-small"):
    response = openai.embeddings.create(
        input=text,
        model=model
    )
    return response.data[0].embedding

# 批次處理多個 chunk
def embed_chunks(chunks):
    for chunk in chunks:
        chunk["embedding"] = get_embedding(chunk["content"])
    return chunks

實務上建議做**批次處理（batch）**而非逐筆呼叫，可以大幅降低 API 呼叫次數與延遲。

如何評估 Embedding 模型的好壞？

不要只看模型的名氣或維度大小，建議實際用自己的資料做小規模測試：

1. 準備一組「問題—正確答案段落」的配對
2. 分別用不同 Embedding 模型建立索引
3. 比較各模型檢索出的 Top-K 結果中，包含正確答案段落的比例（Context Recall）

這個評估方式我們會在 Day 23-24 更深入介紹，這裡先建立一個概念：Embedding 模型的選擇也應該用資料驗證，而不是憑直覺。

小結

Embedding 是把「文字」轉換成「可計算語意相似度的向量」的關鍵一步，選型時要綜合考量語言支援、成本、部署方式與實際檢索效果。明天我們要接著討論向量資料庫的選型與建置，把這些向量真正存起來、建立可以快速查詢的索引。

備註：以上文章為範本內容，建議實際發文前依你們實驗室真正使用的技術棧（LLM、Embedding 模型、向量資料庫）替換範例程式碼與選型說明，並適度加入實際跑出來的截圖、實驗數據，會讓系列文章更有說服力與原創性。