Embedding（向量嵌入）是把文字、圖片或其他資料轉成一串數字，讓系統能計算兩份內容有多相近。搜尋「如何辦理退款」時，即使文件寫的是「退貨與款項返還規則」，語意向量仍有機會把它找出來。
它本身不會回答問題。Embedding 負責表示與檢索，語言模型才負責閱讀取回的內容並產生答案。這也是 RAG 系統中最常被混淆的分工。第一次做知識庫時，先拿 50 題真實查詢比較 BM25 與單一 Embedding baseline，再依漏查案例決定是否加入 hybrid search 或 reranker。
Embedding 如何運作？
假設模型把每段文字轉成 1,536 維向量：
「如何申請退款」 -> [0.018, -0.041, 0.006, ...]
「退貨款項多久入帳」 -> [0.021, -0.038, 0.009, ...]系統用 cosine similarity、dot product 或其他距離函數比較向量。分數只在同一模型、相同處理流程與同一索引設定下有意義，不能把不同模型的 0.8 當成相同品質。
完整的文件搜尋分成兩條路徑：
- 建立索引：清理文件、切成 chunks、產生每段 Embedding，連同原文與 metadata 寫入向量資料庫。
- 處理查詢：用同一模型產生查詢向量，搜尋最接近的 top-k 段落，視需要重新排序，再交給 LLM。
向量搜尋、關鍵字搜尋怎麼選？
關鍵字或 BM25 擅長產品編號、姓名、法條、錯誤碼與精確片語，卻容易漏掉同義詞和改寫後的自然語言問題。Dense vector 剛好相反：它能依意圖與概念找近似內容，罕見代碼、拼字和極短關鍵詞可能排得不理想。
客服知識庫常同時包含「取消訂閱」這種自然語言，以及 E1042 這種錯誤碼。只用向量會犧牲精確匹配，只用關鍵字又可能漏掉同義問法。較穩健的起點是各取一批 BM25 與向量候選，合併去重後再 rerank。
這種 Hybrid search 能保留兩種信號，但權重需要用真實資料調整。Reranker 可對第一階段候選做更精細的排序，也會增加一次模型呼叫與延遲。資料量小時先做 BM25 與 dense baseline，確認錯誤類型後再增加元件，比一開始堆滿流程更容易找出改善是否有效。
推薦系統也常從向量相似度開始，但大規模平台正把長期點擊與購買序列改寫成 next-item prediction。HSTU 與 Semantic ID 的生成式推薦選型說明何時這種後端值得測，以及為什麼中小型資料量通常先維持向量召回。
向量資料庫也要保存 metadata，例如語言、產品、版本、生效日期與權限群組。搜尋前先過濾使用者不能看的文件，不能等 LLM 產生答案後才遮掉敏感文字。可搭配 AI 隱私與資安指南建立資料分級。
2026 年 Embedding 模型與成本怎麼選？
模型表適合用來縮小候選，不適合直接宣布冠軍。下表數字依 2026 年 8 月 12 日官方文件整理：
| 模型 | 輸出與輸入重點 | 適合先測的情境 |
|---|---|---|
OpenAI text-embedding-3-small | 預設 1,536 維；每百萬 input tokens 0.02 美元 | 已用 OpenAI API、重視成本與整合速度 |
OpenAI text-embedding-3-large | 預設 3,072 維；每百萬 input tokens 0.13 美元 | 願意用成本與儲存換取候選品質 |
Cohere embed-v4.0 | 256–1,536 維；128k context；支援文字、圖片與混合輸入 | PDF 圖文、多語與可調維度 |
Voyage voyage-4 系列 | 預設 1,024 維；可選 256–2,048 維；32k context | 多語檢索、需要 query/document input type |
BAAI bge-m3 | 1,024 維；最長 8,192 tokens；支援 100 多種語言與 dense／sparse／multi-vector | 需自行部署、繁中與混合搜尋實驗 |
中文網站至少要準備繁中查詢。除了正式用語，也加入台灣口語、英文產品名、中英混寫、縮寫與常見錯字。公開 benchmark 的語料與你的客服、法務或技術文件不同，排名無法代替這一步。
選型時還要看資料是否能傳到外部 API、輸入上限、每秒吞吐、批次功能、向量維度與資料庫支援。BGE-M3 模型卡標示約 568M 參數並採 MIT 授權；自架可控制資料位置，但參數規模仍會影響記憶體、吞吐與硬體需求，也要自行負擔更新、監控和安全修補。正式使用前仍應核對模型卡與相依元件的授權條款。
Embedding 成本至少有四部分：初次建立索引、文件更新、每次查詢，以及向量資料庫的儲存與讀取。API 費用可用「總 input tokens ÷ 1,000,000 × 單價」估算。例如 1,000 萬 tokens 用 text-embedding-3-small 建索引，依每百萬 tokens 0.02 美元計算，模型費約 0.20 美元。這不含資料清理、重試、向量資料庫與網路成本。
儲存也受維度影響。10 萬筆 1,536 維 float32 向量的原始數值約占 586 MiB；實際索引還會加入 ID、metadata、圖索引與備援。把維度砍半可能降低儲存與搜尋負擔，但要先測 Recall 是否仍可接受。
更換模型時，舊模型與新模型產生的向量空間通常不能直接比較。穩健做法是建立新版索引、批次重算文件、讓測試流量雙讀比較，確認後再切換；不要把兩種模型的向量寫進同一個 index 當成可互搜資料。
Python 最小實作
先安裝官方 SDK，並把 OPENAI_API_KEY 放在環境變數：
pip install openai numpy下面範例一次產生文件向量，再用 cosine similarity 找出最相關的兩段。OpenAI v3 Embedding 預設已做 L2 normalization，因此 cosine similarity 與 dot product 會得到相同排序；範例仍保留明確的 cosine 計算，方便日後替換模型。
import os
import numpy as np
from openai import OpenAI
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
model = "text-embedding-3-small"
documents = [
"商品到貨七天內可以申請退貨。",
"退款會在審核完成後五個工作天退回原付款方式。",
"客服時間為週一到週五 09:00 至 18:00。",
]
def embed(texts):
response = client.embeddings.create(model=model, input=texts)
return np.array([item.embedding for item in response.data])
document_vectors = embed(documents)
query_vector = embed(["退貨後多久收到錢？"])[0]
scores = document_vectors @ query_vector
top_indices = np.argsort(scores)[::-1][:2]
for index in top_indices:
print(float(scores[index]), documents[index])正式系統不應在每次查詢時重算所有文件。文件向量要預先寫入 向量資料庫，查詢只產生一個向量，再從索引取回候選。若文件更新，應用穩定的 chunk ID 做 upsert 或刪除，避免新舊版本同時被檢索。
Chunking 與評測怎麼做？
Chunk 太大，取回一段會夾帶大量無關內容；太小則可能把條件與例外拆開。實務上可以先從 300–800 tokens、10–20% overlap 建立 baseline，再依文件結構與評測結果調整。這是起始區間，不是所有資料的標準答案。
切割時優先保留標題、段落、表格與清單的語意邊界。每個 chunk 可附上文件標題、章節、版本與 URL；查詢時回傳來源位置，讓使用者能打開原文。遇到長表格、程式碼或法條，不要硬用固定字數從中間切斷。
常見失敗還包括：索引了頁首頁尾與導覽文字、同一內容有多個版本、chunk 沒保留文件權限，以及 query 和 document 忘了使用模型要求的不同 input type。這些資料管線問題常比換一個模型更影響品質。
先從真實搜尋紀錄整理 50–200 題，每題標出至少一個應該找到的 chunk。測試集要包含繁中、縮寫、口語、錯字、精確代碼，以及「資料庫沒有答案」的問題。
- Recall@k：正確 chunk 是否出現在前 k 筆，適合檢查第一階段有沒有漏資料。
- MRR 或 nDCG：正確結果排得夠不夠前面，適合比較排序品質。
- Answer faithfulness：LLM 的回答是否由取回內容支持，屬於生成階段評測。
- P95 latency 與單次成本：品質相同時，決定哪個方案適合上線。
每次改模型、chunk、top-k、metadata filter 或 reranker 都跑同一套測試。完整設計可參考 LLM 評測指南。如果只挑幾個看起來成功的查詢，很容易把偶然好結果當成系統品質。
常見問題
Embedding 和 Token 有什麼不同？
Token 是模型處理文字時切出的單位，也常用來計價；Embedding 是模型根據一段 token 輸出的一個向量。字數、token 數與向量維度是三個不同概念。
Embedding 可以還原成原文嗎？
一般無法直接把向量精確解碼回原文，但向量仍可能洩漏語意或被用來推測資料特徵。它不等於匿名化，敏感資料仍需權限、加密、保存與刪除政策。
向量維度越高越準嗎？
沒有固定答案。較高維度會增加儲存、記憶體與索引負擔，實際品質還受模型、資料與查詢影響。應在同一測試集上比較 Recall、排序、延遲與成本。
RAG 一定要向量資料庫嗎？
不一定。資料量小時可用記憶體或一般資料庫的向量擴充；精確代碼與固定欄位也可能用 SQL 或全文搜尋更好。需要大規模近鄰搜尋、metadata filter 與穩定延遲時，專門向量索引才更有價值。
為什麼換了 Embedding 模型後搜尋變差？
常見原因是只重算查詢向量，文件仍保留舊模型向量；也可能是維度、距離函數、input type 或 normalization 不一致。更換模型時應重建整份索引並用同一測試集比較。