開源 vs 商用 embedding 模型:中文企業知識庫該選哪一個?

上個月我們幫一家券商調一個 RAG 知識庫。他們的法遵文件、內部函令、客戶問答全塞進了向量資料庫,用的是一顆很有名的商用 embedding API,Demo 當天檢索命中率漂亮。上線兩週後,前線人員開始抱怨:「查『受益憑證』它給我一堆基金申購的東西。」我們把 query log 拉出來看,發現問題不在 RAG 架構,在最底層那顆 embedding。它是用簡體語料為主訓練的,對台灣金融的繁中專有名詞、全形標點、以及「函令 vs 令函」這種語序,理解得很粗。

這就是為什麼「中文 embedding 模型選擇」不能照抄英文世界的排行榜。在中文企業知識庫這件事上,榜上分數高的模型,不一定是你該用的那顆。

先講結論:三個變數決定你的選型

Embedding 模型是把一段文字轉成向量、讓語意相近的內容在向量空間裡靠得近的模型;它是整個 RAG 檢索品質的地基,選錯了,後面再強的 LLM 也救不回來。而在中文企業場景裡,真正要權衡的只有三件事:繁中/簡中的實際檢索表現、能不能地端部署、以及成本結構。把這三軸想清楚,選型就不再是玄學。

第一個是很多人忽略的坑:繁簡不對稱。大多數開源中文 embedding 是以簡體為主體訓練的,丟繁中進去雖然能跑,但在專有名詞、異體字、台港用語上的召回會掉一截。若你的知識庫是純繁中(台灣的金融、醫療、法遵最常見),務必用自己的真實文件做過離線評測,不要信官方的 C-MTEB 平均分。

第二個是資料能不能出境。金融與醫療的資料,多半連「呼叫外部 API」這一步都過不了資安。這時商用 API 模型直接出局,不管它多準,你只能在地端可部署的開源模型裡選。

第三個才是成本,而且成本的形狀不一樣:商用 API 是按 token 計費、零維運;開源自建是一次性 GPU 成本加上工程維運。量小選 API,量大且長期,自建反而便宜。

中文 embedding 模型選擇:一張表看懂取捨

以下是我們實際導入時最常評估的幾顆,依中文場景整理:

這張表要搭配一句話讀:表裡的「繁中檢索」是相對評級,不是絕對真理。同一顆模型,在你家法律合約上的表現,和在你家客服對話上的表現可能差很多。所以我們從不憑表決定,只用表來篩掉明顯不合的選項,剩下兩三顆一定要用客戶自己的資料跑一輪。

開源真正的隱藏成本,是維運不是授權

工程師常有個錯覺:開源=免費。授權確實免費,但一顆 BGE-M3 要在地端穩定服務,你得處理 GPU 採購或租用、推論服務(vLLM、TEI 之類)的部署、batch 吞吐調校、版本升級時的向量重算。這些都是隱藏在「免費」後面的人力。

反過來,商用 API 的隱藏成本是「重算焦慮」。當你有幾百萬筆文件已經用某顆 API 模型建好索引,哪天要換模型,整個向量庫得重新 embedding 一遍,量大時這是一筆可觀的 token 費用與停機風險。所以選 API 時,長期綁定成本要先算進去。

我們的經驗法則是這樣:文件量在數十萬筆以下、且允許資料出境,先用商用 API 把系統跑起來,別急著自建,把工程力花在檢索策略和資料清洗上更划算。一旦資料不能出境,或文件量往百萬、千萬走,自建開源加上一張到數張 GPU,兩三個月就能把 API 費用攤平,而且模型握在自己手上,能針對繁中專業語料做微調——這是商用 API 給不了的。

別忽略的兩個中文專屬細節

一是切塊(chunking)比換模型更常是元凶。中文沒有空格斷詞,若你沿用英文那套「按 token 數硬切」,常把一個完整語意從中間剖開,再強的 embedding 也救不回。先確認切塊有貼合中文的句讀與段落結構。

二是繁簡正規化。如果你的知識庫同時混有繁體文件與簡體來源,查詢端最好做一層繁簡對照或同義擴展,否則「軟體」查不到「软件」,使用者會以為系統壞了。這一步幾行程式就能補,效益卻很大。

說到底,中文企業知識庫的 embedding 選型,沒有標準答案,只有「拿你自己的資料驗過」的答案。我們在客戶現場做 RAG 導入時,標準動作就是先建一個幾十題的繁中評測集,把兩三顆候選模型跑出真實召回數字,再決定地端還是 API——因為 Demo 分數漂亮不算數,前線人員每天查得到、查得準,才算真的上線。