Embedding 是什麼:讓電腦理解「相似性」的方法

問你一個簡單問題：

「貓」跟「狗」哪個比較像？

人類直覺答：貓跟狗都是寵物，當然像。「貓」跟「手機」差很多。

但對電腦，「貓」、「狗」、「手機」都是字串。它不能讀懂語義——它只懂數字。

Embedding 的角色：把語義變成數字。

Embedding 是把文字 / 圖片 / 音訊轉成「一串數字」(向量)的技術。語義相似的東西，在這個數字空間裡的距離也相近。

這個聽起來抽象的概念，其實是 2026 年所有 AI infra 的隱形基礎：RAG、推薦系統、語意搜尋、聚類分析、duplicate 偵測——都靠它。

直覺解釋

把每個字想成空間中的一個點。

「貓」可能在座標 (0.7, 0.2, -0.5, ...)(假設 3 維，實際是 768 / 1536 / 3072 等高維)。

「狗」可能在 (0.65, 0.25, -0.48, ...)——跟「貓」很接近。

「手機」可能在 (-0.3, 0.8, 0.4, ...)——離得遠。

距離近 = 語義相似。

電腦不需要「懂」貓跟狗都是寵物。它只需要算兩個向量的距離(常用 cosine similarity 餘弦相似度)。距離近的就是相似。

把這個方法套到整個句子、整個段落、整篇文件——你就能用數學方式找「最相似的內容」。

為什麼 RAG 全靠 embedding

RAG 的核心動作是「給定 query，找出最相關的 chunk」。

「最相關」怎麼定義？

不是字面比對(那是 keyword search，常常失準)。是語義比對——用 embedding。

流程：

1. 索引時：每個 chunk 算一個 embedding，存進 vector database
2. 查詢時：query 算一個 embedding
3. 比對：在 vector DB 找跟 query embedding 距離最近的 top-K chunks

使用者問「我們去年滿意度多少」——即使文件裡用「客戶評分」「NPS 結果」「服務評價」等不同詞，只要語義接近，embedding 都能撈出來。

這是 RAG 跟傳統 keyword search 的關鍵差別。

繁中 embedding 的特殊坑

英文中心的 embedding 模型(像 OpenAI text-embedding-3-large)在繁中場景常常效果打折。原因類似 tokens 那篇講的：訓練資料裡英文佔絕大多數，繁中佔比小，模型對繁中語義細節掌握不夠。

具體問題：

• 同義詞辨識弱——「客戶滿意度」跟「顧客評價」在繁中模型裡距離應該很近，但通用模型可能拉得遠
• 詞序敏感——繁中跟英文語序不同，通用模型可能 over-fit 到英文語序
• 領域詞效果差——台灣專業領域(健保、稅法、特定產業術語)在通用 embedding 上常常變得「面目全非」

實務建議：繁中 RAG 一定要實測 embedding 模型，不要假設「英文最強的就是繁中最強的」。

2026 年繁中場景常見的選擇：

模型	強項	註解
bge-m3(BAAI)	多語言、開源、可自架	繁中表現公認不錯，可在 GPU 上跑
Cohere embed-multilingual-v3	API 易用、多語言 SOTA 級	商業 API，繁中質量高
聯發科 / TAIDE 自家 embedding	繁中 + 台灣領域	在地化最強，但生態小
OpenAI text-embedding-3-large	容易整合、英文強	繁中可用但非最佳
Voyage AI multilingual	強多語言、長文件友善	商業 API

維度跟成本的取捨

Embedding 的「維度」是向量長度。常見從 384 到 3072。

維度高：

• ✅ 表達力強、retrieval 精度高
• ❌ 儲存成本高(每個 chunk 多花空間)
• ❌ 計算成本高(每次比對更貴)

維度低：

• ✅ 便宜、快速
• ❌ 細節 capture 不到位

實務經驗：

• 一般企業 RAG:768-1536 維足夠
• 高精度 retrieval(法律、醫療):2048-3072
• 大規模(百萬筆 chunks):用較低維度 + 好的 reranker 通常更划算

OpenAI text-embedding-3 系列支援 dimensions 參數，可以動態降維(從 3072 砍到 256 都行)，這是個常用 trick。

Instruction-tuned embedding(2026 年的進階用法)

新一代 embedding 模型支援「給不同任務不同 instruction」。

例子：

Instruction: "Represent this query for retrieval"
Text: "我們去年的客戶滿意度?"

vs.

Instruction: "Represent this document for retrieval"
Text: "2024 Q3 NPS 分數為 67,較前季提升 5 分..."

這讓 query 跟 document 用「不一樣的 embedding 空間」，但兩個空間是 aligned。實測 retrieval 精度提升明顯。

bge-m3、e5-mistral、nomic-embed 都支援這個。

對 builder 的實務建議

第一，先用 baseline 模型跑通，再優化。 一開始用 OpenAI text-embedding-3 跑通流程，先驗證 RAG 邏輯對。再換更適合繁中的模型優化精度。

第二，評估 embedding 一定要拿真實 query 測。 不要只測 demo 句子。蒐集 100-500 條真實使用者 query，人工標 relevant docs，計算 recall@k。換 embedding 模型時用同一個 eval set 對照。

第三，別忘了 reranker。 Embedding 撈 top-50，再用 reranker(像 Cohere rerank-3 或 bge-reranker)挑出真正相關的 top-5。這個 two-stage 在繁中場景特別有效。

第四，監控 embedding drift。 你索引文件用的 embedding 模型升級了，舊 vector DB 跟新 query embedding 不在同一個空間。換模型要重新 embed 整個 corpus。

收尾

Embedding 是「電腦理解相似性」的數學基礎。

它本身不是 sexy 的技術——沒有 emergent abilities、沒有 viral demo——但它是 RAG、推薦、搜尋整個 stack 的底層。

下一篇 chronicle:Fine-tuning 是什麼——什麼時候該客製化模型、什麼時候 prompt + RAG 就夠。

周詠晴（編輯：廖玄同），《Embedding 是什麼:讓電腦理解「相似性」的方法》，矽基前沿 [Si]gnals，2026-04-25。https://signals.tw/articles/what-is-embedding/