Embedding 是什麼？用人話解釋 AI 怎麼「讀懂」你的知識庫

AI 2026-05-12 · Satsuma Creative · 閱讀 11 分鐘

Embedding 把文字轉成座標，意思相近的句子靠在一起。這就是為什麼問「我要退貨」，AI 能找到「退換貨政策」——即使兩個詞一個字都不一樣。

如果你看過 RAG 那篇，你大概知道：AI 客服的知識庫，不是用「搜尋關鍵字」的方式在找答案。

那它用什麼？

Embedding。

這個詞看起來很技術。但它背後的邏輯，比你想的直觀。

TL;DR

Embedding 是把文字轉成「數字座標」的技術
意思相近的文字，在座標空間裡會靠在一起
RAG 用 Embedding 找「意思最接近」的資料，不是找「關鍵字一樣」的資料
這就是為什麼問「我要退貨」，AI 能找到「退換貨政策」——即使這兩個詞一個字都不一樣
Embedding 的品質，直接決定你的 AI 客服能不能找到對的答案
薩摩用的是 HuggingFace 開源多語言模型，本地跑，零 API 費用，資料不出機器
Claude Sonnet 4.6 和 GPT-5.5 本身不是 Embedding 模型——它們是 RAG 架構的最後一步（生成回答），不是找資料那一步
選 Claude 還是 GPT，影響的是回答的語氣和遵守指令的穩定性，不是 Embedding 的品質

從一個你用過的東西開始說

你用 Spotify 或是 YouTube 的時候，它會推薦「你可能也喜歡」。

這個推薦，不是靠關鍵字。它不是說「這首歌也叫做流行音樂，所以推給你」。

它是靠某種「這首歌和你聽的那首，在某個空間裡距離很近」的判斷。

Embedding 就是在做這件事。只是對象從歌，換成了文字。

文字怎麼變成座標？

想像一個空間。不是你看得到的三維空間，是一個有很多維度的抽象空間。

每一段文字，都可以被轉換成這個空間裡的一個點——一組數字，代表它的位置。

例如： - 「退貨怎麼辦」這句話，轉換後在某個位置 - 「換貨流程是什麼」這句話，轉換後在附近的位置 - 「你們有沒有黑色款」這句話，轉換後在很遠的另一個位置

AI 不需要看到一模一樣的字，它只需要看到「距離夠近的點」。

這就是 Embedding 的核心邏輯：把語意轉成距離。

這和 RAG 有什麼關係？

上一篇解釋過，RAG 是「先找資料，再讓 AI 回答」的架構。

找資料的那一步，就是靠 Embedding。

流程是這樣：

你的知識庫（退換貨政策、FAQ、產品說明）事先被轉換成 Embedding，存進向量資料庫
客戶問了一個問題，這個問題也被轉換成 Embedding
系統找出知識庫裡「距離最近」的幾段內容
把這些內容交給 AI，讓 AI 根據這些內容來回答

關鍵在第三步。 找的不是「有沒有同樣的字」，找的是「意思有沒有接近」。

為什麼這件事很重要？

傳統的搜尋，靠的是關鍵字比對。

客戶說「我要退貨」，系統去找有沒有「退貨」這個詞。有，找到了。

但客戶如果說「我不想要了，可以送回去嗎」？

傳統搜尋：找不到（因為沒有「退貨」這個詞）。 Embedding 搜尋：找到了（因為「不想要了送回去」跟「退貨」在語意空間裡距離很近）。

這就是為什麼 RAG 做得好的 AI 客服，比傳統搜尋型客服聰明得多。

不是 AI 本身更聰明，是它找答案的方式更接近「人怎麼理解問題」。

Embedding 的品質會影響什麼？

不是所有 Embedding 都一樣。

把「我要退貨」轉成座標，轉得好不好，取決於用哪個 Embedding 模型。

好的 Embedding 模型：中文語意理解準確，「想退」跟「要換」距離近，「問顏色」跟「問尺寸」也歸在類似的區塊。

差的 Embedding 模型：中文語意一團糟，「我很滿意」跟「我不滿意」可能靠很近（因為字面相似），「退款」跟「退貨」可能被當成完全不同的事。

台灣品牌在建 AI 客服時，這個環節最常被忽略。

大家比較功能表、比較費用，但沒有測試這家服務用的 Embedding 模型，對繁體中文的語意理解是否準確。

然後上線後一直出包，以為是 AI 不夠強。

其實是這一層就歪了。

薩摩怎麼做 Embedding？

說清楚我們自己在用什麼，比較誠實。

目前薩摩自己的 AI 客服（也就是你在這個網站右下角看到的那個），Embedding 這一層用的是 HuggingFace 的開源多語言模型 paraphrase-multilingual-MiniLM-L12-v2，跑在本地的 Mac Mini 上。

不是 OpenAI，不是雲端，是開源的、本機的。

為什麼這樣選？

資料不出機器。 知識庫的內容、客戶的問題，都在本地處理，不會傳出去。對資料敏感的客戶，這是很實際的考量。

多語言覆蓋夠用。 這個模型設計上就是多語言的，繁體中文、簡體中文、英文混在一起問，都能正確做語意比對。台灣客服場景的日常問題，召回率夠。

向量存成 .npy 檔（numpy 陣列），直接放在本地。沒有另外搭向量資料庫，查詢時用 cosine similarity 做比對。知識庫不大的情況下，速度完全夠用。

知識庫更新後，在後台按一下「重建」，系統自動重算向量並熱載入，不需要重啟服務。

這樣的架構，不是「最強的」，是「夠用又省事的」。

如果知識庫有幾千篇文件、查詢量很高、需要更精準的召回，才需要考慮換 OpenAI embedding + pgvector 的組合。那是不同的需求，不是這個架構不夠好。

Claude Sonnet 4.6 和 GPT-5.5，它們怎麼做 Embedding？

這裡要說清楚一件常被搞混的事。

Claude Sonnet 4.6 和 GPT-5.5，它們本身不是 Embedding 模型。

這兩個是「大語言模型」——你問它問題，它回答你。它在 RAG 架構裡的角色是最後那一步：讀了找到的資料，生成答案。

Embedding——把文字轉成向量、找最近的資料——是另一層，用的是獨立的 Embedding 模型。

畫成流程：

客戶問題
  ↓
[Embedding 模型] ← 開源多語言模型（本地）或 text-embedding-3-large（OpenAI）
  ↓
向量比對搜尋
  ↓
找到最相關的知識庫段落
  ↓
[大語言模型] ← Claude Sonnet 4.6 或 GPT-5.5 在這裡
  ↓
生成回答

所以當你在問「要用 Claude 還是 GPT 做 AI 客服」，你其實在問的是最後那一步用誰。Embedding 那一層是另外一個選擇。

那 Claude 和 GPT，這一步有什麼差？

Context window（上下文視窗大小）

Claude Sonnet 4.6 支援 100 萬 token 的上下文視窗，GPT-5.5 也在類似的量級。

這對知識庫來說意味著什麼？理論上可以把更多資料直接塞給 AI，不用 Embedding 也能找到答案。

但實務上，塞太多資料給 AI，它的「注意力」會分散，在長文件裡找答案的準確率會下降。加上 token 費用是按量計費，每次問答都要付很多錢。

所以就算 context window 很大，RAG 還是比「全部塞進去」便宜、準。

繁體中文的回答品質

Claude 和 GPT-5.5 在繁體中文的表現都不錯，但語氣有差。

Claude 的中文比較書面、稍微有點翻譯腔（這是它中文骨頭裡有英文的關係，我在另一篇說過）。GPT-5.5 的中文比較口語、比較接近台灣的說話方式。

做客服時，這個差異可以靠 Prompt 設計去補，但原始的語感確實不一樣。

遵守指令的穩定性

你告訴 AI「只能根據知識庫回答，不知道就說不知道」，它真的會照做嗎？

這個每個版本、每個模型都在改進，沒有一個永遠最好的答案。薩摩的做法是兩個都測，在同一組問題上跑，看哪個在當下的版本比較穩。

一個容易測試的方式

如果你想快速測試你的 AI 客服的 Embedding 品質，可以這樣做：

準備幾組「換個說法問同一件事」的問題： - 「退貨怎麼辦」vs「我不想要了」vs「可以寄回去嗎」 - 「運費多少」vs「寄到台北要多少錢」vs「免運條件是什麼」 - 「有沒有黑色」vs「顏色選擇」vs「深色款式」

同一組的三個問題，都應該找到同樣的答案。

如果找不到，問題很可能在 Embedding，不在 AI 本身。

小結

傳統關鍵字搜尋	Embedding 語意搜尋
找「字一樣」的資料	找「意思接近」的資料
客戶措辭要精確	客戶怎麼說都能找到
建置簡單	需要選對模型
繁體中文通常夠用	模型品質差異很大

RAG + 好的 Embedding = AI 客服的基礎建設。

這兩件事做好了，後面才有得談。

做不好，上面加什麼功能都是在沙堆上蓋房子。

這篇是「AI 客服技術科普系列」的一部分： - RAG 是什麼？ - Embedding 是什麼？← 你在這裡 - AI Memory 是什麼？ - GPT vs Claude vs Gemini 當客服底層

FAQ

Q：Embedding 和「AI 訓練」是同一件事嗎？

不一樣。訓練是讓 AI 學會語言、學會回答問題。Embedding 是用已經訓練好的模型，把文字轉成數字。你不需要自己訓練 Embedding 模型，用現有的就行——但要選對。

Q：向量資料庫是什麼？跟一般資料庫有什麼差？

一般資料庫存的是結構化資料（姓名、訂單號、金額）。向量資料庫存的是 Embedding 之後的數字組，而且專門優化了「找最近的點」這個操作。常見的有 Pinecone、Qdrant、pgvector（PostgreSQL 的擴充）。

規模小的時候，不一定需要向量資料庫——存成檔案、查詢時直接比對，也跑得起來。規模大了，才需要向量資料庫來維持速度。

Q：知識庫更新了，Embedding 要重新跑嗎？

更新的部分要重跑。怎麼觸發看系統設計——有的是後台按鈕手動觸發，有的是偵測到檔案變化自動跑。不管哪種，重跑完要確認新內容確實進了向量索引，不然 AI 還是在用舊的資料回答。