什麼是 embedding?把語意變成數字

Embedding 是一串數字 — 通常 256 到 3,072 個 — 用來代表一段文字的「意思」。神奇之處不在任何單一數字,而是意思相近的文字會產生相近的數字串。一旦能把「意思」當成數字比對,你就能做語意搜尋、RAG、推薦、去重、分群 — 所有「需要 AI 但不到要 LLM」的功能。

具體上,embedding 長什麼樣

餵一句話進 embedding 模型,它回一個向量。例如 OpenAI 的 text-embedding-3-small 會回 1,536 個數字,像:

[0.012, -0.041, 0.087, -0.003, ..., 0.022]

單一數字對人類沒意義。重點是:兩句意思相近的話,embedding 出來的向量會指向相近方向。「How do I reset my password?」跟「I forgot my login」會有高 cosine similarity(接近 1.0)。「How do I reset my password?」跟「What's the weather in Tokyo?」相似度低(接近 0)。

之所以能做到,是因為 embedding 模型被訓練(在巨大文字資料集上)把相近意思 map 到高維空間相近的區域。訓練目標就是把相關文字推近、無關推遠。

Embedding 實際在做什麼用途

**語意搜尋。**把所有文件切塊、每塊 embed、存進向量資料庫。使用者搜尋時,把查詢 embed,找最接近的塊。即使查詢用不同字眼,也能找到相關文件。RAG 的核心引擎。

**推薦系統。**把使用者行為 embed(讀過的文章、看過的商品)。找 embedding 相近的使用者或商品。輕量「more like this」,不必複雜 ML。

**去重。**把資料庫每筆 embed,找相似度 > 0.95 的配對,大概是重複。清客戶名單、客服單、商品列表很好用。

**分類。**把每個類別的標註範例 embed,新項目用「最接近哪個類別的 embedding」分類。比 fine-tune 分類器便宜的替代。

**Clustering。**對一批 embedding 跑 k-means 或 DBSCAN 把相關項目分組。客服單分流、內容主題探勘很好用。

該用哪個 embedding 模型

2026 年實用選項:

OpenAI text-embedding-3-small — 便宜(每百萬 tokens 約 $0.02)、1,536 維、品質不錯、英文強。預設可選。
OpenAI text-embedding-3-large — 品質更好、3,072 維、約 3 倍價錢。要準確時用。
Voyage AI voyage-3 / voyage-3-large — 前沿等級品質,稍貴於 OpenAI,檢索常常是最好。
Cohere embed-english-v3 / embed-multilingual-v3 — 多語言強;非英文內容選 multilingual 版。
BGE(智源研究院)M3 / BGE-large — 開放權重、可自架、頂級品質。中文最強的選項之一。
gte-large、e5-large — 其他開放權重,比 BGE 輕。

如果是中文為主的內容:BGE-M3 跟 Cohere multilingual v3 明顯贏 OpenAI。非英文不要傻傻預設 OpenAI。

Embedding 怎麼存怎麼搜

1,536 維向量約 6KB。一百萬個 chunk 就是 6GB 加 overhead。暴力比相似度(每查詢 O(n))在 ~10 萬向量以上就會慢爆。

這正是 vector database 解決的問題:索引結構(HNSW、IVF)用 O(log n) 之類的複雜度找近似最近鄰。2026 年選項:

pgvector — Postgres extension,在一般 Postgres(包括 Supabase)就能用。大多數 app 的最佳預設,因為資料都在同一個 DB。
Pinecone — 託管、容易 scale、稍貴。需要超高吞吐量或不想 ops 時用。
Qdrant — 開源、Rust、效能好,可自架或用雲。
Weaviate、Chroma、Milvus — 同個賽道其他選項。
DuckDB / SQLite 向量擴充 — 小資料(< 1000 萬筆)。

剛起步的 app 90% 用 pgvector 就對。

常見錯誤

**Embed 錯的單位。**整份 50 頁文件 embed 出來是糊的 — 意思太密無法壓縮。先切塊(通常每塊 250-500 tokens),每塊各自 embed。檢索是 per-chunk 不是 per-document。

**混用 embedding 模型。**你 store 裡所有 embedding 必須來自同一個模型。換模型等於要全部重 embed。請事先規劃。

**忘記正規化。**很多相似度公式假設單位長度向量。現代 API 多半回傳已正規化;沒有的話,存之前正規化。

**把相似度分數當準確度。**0.85 cosine similarity 不等於「85% 相關」。經驗式 review 結果定門檻,不要憑感覺。

什麼時候不要用 embedding

完全比對的查詢。「找 product_id = 12345 的列」應該是 SQL WHERE,不是向量搜尋。Embedding 是給模糊語意比對。
**小語料。**如果只有 50 份文件,全塞進 context window 讓 LLM 讀就好。Embedding 有 setup 成本(切塊、embed、索引),少於 ~1,000 個 chunk 划不來。
**高度結構化資料。**SQL 或 JSON 查詢在有明確 schema 的資料(財務、庫存、user metadata)上贏 embedding。
**要關鍵字也要語意的場合。**純向量搜尋會漏掉關鍵字精確比對(產品代號、名字)。用 hybrid search(BM25 + 向量)效果最好。