embedding 模型怎麼選?中英文企業知識庫的向量模型評測與挑選指南

上個月我們幫一家保險公司做知識庫問答,測試時發現一個怪現象:同一個問題,用「保單借款」問得到正確條款,用「保單質借」卻撈出一堆不相干的段落。兩個詞在業務上是同義,向量卻把它們放得很遠。

問題不在 RAG 架構,在最底層那一步——embedding 模型選擇。模型沒讀懂繁體中文保險術語的語義,召回自然歪。

這是 RAG 系統最容易被低估的一環。大家花時間調 prompt、換 LLM,卻很少認真評測「把文字變成向量」的那顆模型。但如果向量本身就錯,後面再貴的生成模型也只是把錯的段落講得很流暢。

為什麼繁中與中英混合特別難

三個坑,踩過才知道痛。

第一是繁簡落差。多數開源與商用模型的中文語料以簡體為主,繁中詞彙(如「資料/數據」「網路/網絡」「品質/質量」)在向量空間裡可能對不齊。純繁中語料如果不處理,召回率我們實測過會掉 5 到 15 個百分點。

第二是中英混排。台灣企業文件常是「這個 pipeline 的 SLA 要 99.9%」這種句子。模型要能在同一段落裡同時理解中文語義與英文技術詞,而不是把英文當成雜訊。

第三是領域術語。金融、醫療、製造各有一套黑話,通用模型沒見過,近義詞就散開。

三類主流模型怎麼比

我們把常用選項分成三類:OpenAI、Cohere、開源 BGE/e5,用同一份繁中加中英混合的企業語料跑召回測試(Recall@10)。

幾個實測心得。OpenAI 勝在省心,一行 API 就能上,英文與程式碼場景很強,但純繁中的細粒度語義比不過專精模型。Cohere 的多語言穩定度最好,而且它的 int8 與 binary 向量能把儲存與檢索成本壓到原本的四分之一以下,大語料很有感。BGE-m3 是我們近期最常推的開源選擇——它同時輸出 dense、sparse、ColBERT 三種表示,天生適合做 hybrid 檢索,繁簡都吃得下,而且能留在客戶內網,金融醫療客戶特別在意這點。

「先用哪一個」的決策路徑

不要一開始就糾結。按這條路走:

資料不能出境,或語料超過百萬級、想長期自控成本——直接上 BGE-m3 自架,搭配 hybrid 檢索。資料可以走 API、又要多語言且在意召回品質——選 Cohere embed-multilingual-v3,開 int8 壓縮。只是想先驗證 RAG 值不值得做、語料不大——用 OpenAI text-embedding-3-large 最快,兩天就能跑出 demo。純繁中、術語密集(法律、醫療病歷)——用 bge-large-zh 或 bge-m3 微調,拿幾千組正負樣本 fine-tune,召回還能再拉一截。

但講句實話:換模型帶來的召回提升,往往不如把 chunking 切好、加一顆 reranker 來得大。我們的順序永遠是先把切塊策略和 hybrid 檢索做對,再上 bge-reranker 或 Cohere rerank 重排,最後才回頭微調 embedding。順序反了,你會在錯的地方花冤枉錢。

回到開頭那家保險公司:我們換上 bge-m3 加 hybrid 檢索,再補一層 reranker,「保單借款」與「保單質借」終於撈到同一批條款,Recall@10 從 71% 上到 92%。模型選對只是起點,真正讓它在客服現場被天天使用,才是我們在意的那條線。這也是我們做 RAG 知識系統時,習慣先花一週把檢索評測跑扎實,再談上線——因為 demo 撈得準不算數,值班人員願意信任它、天天用它,才算數。