文字嵌入詳解：運作原理 [+範例]

如果您已經熟悉文字嵌入的基本概念，卻不知道該如何實際運用，那您就來對地方了。我們將剖析向量、分詞與相似度計算，深入探討如何評估嵌入模型，並為您介紹實際的應用案例。

什麼是文字嵌入？

文字嵌入是詞語、句子或文件的數值表示法，能捕捉其語意及彼此之間的關係。文字嵌入由嵌入模型產生，這類模型會將文字轉換為向量，也就是機器學習演算法能夠處理與比較的數字陣列。

機器學習工程師運用文字嵌入，協助軟體應用程式辨識詞語與句子之間的關係，讓搜尋、分類及分析大量資料變得更容易。

假設您每天會收到數千張客服工單。客戶回報的問題五花八門，而您需要將這些工單分類並加上標籤。若要自動化這個流程，其中一種方式是使用預先訓練的文字嵌入模型，將每張工單轉換為向量。

舉例來說，兩位客戶提交了以下訊息：

• 「我的訂閱被重複扣款了」：[0.21, -0.47, 0.83, ...]
• 「我的帳戶裡有一筆重複付款」： [0.19, -0.45, 0.80, ...]

以上為簡化的示意向量。

雖然這兩位客戶的用詞不同，但描述的是同一個問題。嵌入模型會在數學空間中將兩者的向量放在相近的位置，藉此捕捉這種關係。於是，這兩張工單都會被歸入同一類別，並轉交帳務團隊處理。

文字嵌入在商業上的應用案例

文字嵌入可用於各種自然語言處理（NLP）任務，包括：

• 語意搜尋：根據含義尋找相關資訊。Delivery Hero 結合產品與查詢嵌入以及關鍵字搜尋，協助生鮮雜貨客戶找到相關商品。例如，搜尋「低脂優格」時，即使用詞並不完全相符，也能找出希臘優格或脂肪含量 0.5% 的優格。
• 文字分類：將文字分門別類，例如辨識垃圾郵件，或依主題整理文件。MindCraft.ai 開發了一套文件分類系統，運用以 Transformer 為基礎的文字嵌入與機器學習來分類企業文件，並找出敏感資訊，以符合 GDPR 規範。
• 分群：將相似的文件或文字片段歸為一組，以找出其中的模式。Doczy.ai 會將合約文字轉換為嵌入，並把語意相關的條款與概念歸為一組，即使不同合約以不同措辭表達類似的義務也不例外。
• 檢索增強生成（RAG）：檢索相關資訊，供 LLM 生成更準確、更貼合上下文的回應。Ring 在多語言 RAG 聊天機器人中使用 Amazon Titan 文字嵌入，先檢索相關的支援文件，再針對各國際市場客戶提出的問題生成解答。
• 推薦系統：根據文字相似度推薦相關文章、產品或其他內容。LinkedIn 的 JUDE 系統使用 LLM 為職缺說明與會員個人檔案產生的文字嵌入，捕捉求職者背景與現有職缺之間的關係，藉此改善職缺推薦。
• 命名實體辨識（NER）：協助辨識並分類文字中的人名、組織名稱與地名。Amazon Health Services 使用 NER 辨識客戶查詢中的醫學概念，例如疾病、症狀、藥物與治療方式，再結合以嵌入為基礎的相似度搜尋，將查詢與相關的醫療保健產品及服務連結起來。
• 機器翻譯：為在不同語言之間翻譯文字的模型提供支援。Transglot 在語意翻譯記憶庫中使用文字嵌入，找出先前已翻譯且含義相近的段落，協助在地化工作流程重複使用既有譯文。

文字嵌入如何運作？

那麼，嵌入模型是如何決定要為一段文字指定哪些數值？我們又為什麼應該信任它？

一切都從訓練開始。嵌入模型會從大量文字中學習，找出詞語搭配使用的模式。舉例來說，Word2Vec 等傳統模型的學習方式，是根據周圍的詞語預測某個詞，或反過來根據某個詞預測周圍的詞語。現代以檢索為主的模型則常採用對比學習，經過訓練後，會給相關的查詢與文件配對較高的相似度分數，給無關的配對則較低的分數。

放大

模型完成訓練後，當您輸入一段新文字時，會經過以下過程：

1. 分詞。模型首先會將文字拆分成較小的片段，稱為詞元（token）。這些片段可能是完整的詞、詞的一部分或標點符號。每個詞元都會從模型的詞彙表中取得一個數值 ID，而這個 ID 本身並不帶有任何含義。
2. 編碼與池化。模型會運用訓練期間學到的模式處理這些詞元，並產生一個向量。向量中的每個數字都是一個座標或分量，而維度則是該數字據以界定向量位置的座標軸。每個數值都會影響文字在數學空間中的位置，這個空間稱為嵌入空間。
3. 相似度計算。為了找出相關文字，檢索系統會使用餘弦相似度或內積等相似度量測方法，比較查詢嵌入與文件嵌入

舉例來說，線上商店就是透過這種方式，針對使用者的查詢傳回相符的商品。

詞嵌入、句子嵌入與文件嵌入有何不同？

放大

主要差異在於每個嵌入以單一向量代表多少文字。您可以依據想要捕捉的資訊，為個別詞語、完整句子或整份文件建立嵌入。

• 詞嵌入能捕捉個別詞語之間的關係，例如辨識出「服務中斷」與「停機」是相關概念。
• 句子嵌入能理解整個句子的含義，即使不同句子以不同措辭表達相同的想法也不例外。
• 文件嵌入會以一個向量代表整份文件，而不是為每個句子分別建立向量。這有助於保留整體主題，並找出涵蓋相同主題的其他文件；不過，細節可能較難（甚至無法）檢索。

該細分到什麼程度？合適的層級取決於您的資料，以及您想達成的目標。

對於較大型的文件，常見的做法是將文字拆分成較小的區塊，並為每個區塊分別產生嵌入。如此一來，您既能掌握文件的整體含義，「同時」也能保留文件嵌入過程中可能遺失的具體細節。

區塊大小對嵌入品質的影響有多大？

影響相當大。Rahul Kumar 是 Xenoss 的 AI 工程副總裁，他指出，挑戰在於找到一個既能涵蓋一個完整概念、又不會遺失重要脈絡的區塊大小。他如此解釋其中的取捨：

「區塊大小決定了一個嵌入承載多少語意脈絡。區塊越大，向量獲得的脈絡就越多，但也會將更多主題平均到同一個向量中。涵蓋三個主題的區塊會落在三者中間，與任何一個主題都不太相符。區塊越小，含義就越精確，但可能會失去讓它能被找到的脈絡。」

因此，Kumar 建議根據內容選擇分塊策略，而不是死守單一的固定大小。正如他所說：「固定大小加上重疊的做法，只適用於電子郵件或擷取的網頁這類格式統一的文字。」

對於合約或政策等結構化文件，遞迴式、能感知結構的拆分方式更為合適。另一方面，語意分塊則很適合逐字稿，因為它會在主題或含義轉換之處拆分文字。

文字嵌入與關鍵字搜尋的比較

既然可以直接搜尋關鍵字，為什麼還要使用文字嵌入？因為關鍵字搜尋仰賴字詞比對，而以嵌入為基礎的語意搜尋即使在查詢與文件用詞不同時，也能檢索到相關資訊。

但語意相似並不一定代表相關。AI Builder Academy 創辦人 Shaw Talebi 以一套履歷搜尋系統示範了這項限制。在 Talebi 的案例中，搜尋「具備 Apache Airflow 經驗的資料工程師」時，前五筆結果中只有一筆提到 Apache Airflow，而且排名第三，但資料集中其實還有另外三份履歷列出了這項技能。

這表示語意搜尋雖然有助於找出概念上相關的資訊，但可能會遺漏技術技能、產品識別碼或錯誤代碼等精確條件。

為了解決這個問題，Rahul Kumar 建議根據檢索系統的不足之處來選擇檢索方法：

• 當查詢包含 SKU、錯誤代碼或法律條文出處等精確字詞時，混合搜尋（結合關鍵字比對與語意搜尋）是預設的選擇。
• 當只有前幾筆結果重要時（例如根據檢索到的脈絡生成答案），重新排序模型就值回票價。
• 當答案橫跨多個相互連結的資料來源時，圖譜檢索就能派上用場。

Kumar 也分享了他的團隊如何將這些方法付諸實行。在其中一個專案中，他們同時執行 BM25 關鍵字搜尋與向量搜尋，使用倒數排名融合（RRF）合併結果，再利用 LLM 將前 124 筆結果重新排序，篩選至 6 筆。

「改採以圖譜為優先的檢索方式，先以向量搜尋找出相似的潛在空間，再進行兩跳圖譜遍歷，讓排序品質（nDCG）從 0.58 提升至 0.67，並將 p90 檢索時間從 19 秒縮短到 3 秒以內。」Kumar 補充道。

文字嵌入模型的類型

大致而言，所有嵌入模型做的事情都相同，也就是學習文字中的關係。然而，它們在訓練目標、考量的資訊，以及設計用來處理的任務上各有不同。

靜態詞嵌入模型

傳統的詞嵌入模型會根據大量文字中的詞語使用模式，學習詞語的稠密數值表示法。這些嵌入是靜態的，也就是說，無論某個詞在特定上下文中的含義為何，都會得到相同的向量。

兩種廣為人知的方法如下：

• Word2Vec：由 Google 於 2013 年開發，透過兩種架構從相鄰詞語中學習表示法：連續詞袋模型（CBOW）會根據相鄰詞語預測某個詞，而 skip-gram 則會根據指定的詞預測其相鄰詞語。
• GloVe（Global Vectors for Word Representation）：於 2014 年由史丹佛大學開發，利用詞語共現統計資料來學習詞語之間的關係。

情境化語言模型

與靜態嵌入不同，通用語言模型會產生隨周圍文字而變化的情境化表示法，有助於模型區分同一個詞的不同含義。

• BERT（2018 年，Google）：使用雙向自注意力機制，同時考量詞元兩側的詞語。例如，它會為「I deposited money at the bank」（我把錢存進銀行）與「I sat on the bank of a river」（我坐在河岸上）中的「bank」產生不同的表示法。
• GPT（2018 年，OpenAI）：使用以 Transformer 為基礎的表示法，在預測下一個詞元時考量前文。GPT 模型主要是為語言生成而設計。

句子與文件嵌入模型

將較長的文字片段（從單一句子到段落，乃至整份文件）表示為向量。

• Doc2Vec：將 Word2Vec 式的學習方式延伸至句子、段落與文件，有助於將相關文章歸為一組，或依主題分類文件。
• Universal Sentence Encoder（USE）：由 Google 於 2018 年開發，可為句子與短段落產生固定長度的表示法，用於語意相似度與文字分類。
• Sentence-BERT（SBERT，2019 年）：由達姆施塔特工業大學的 Nils Reimers 與 Iryna Gurevych 開發，以 Google 的 BERT 模型為基礎，常用於語意搜尋、改述偵測與分群。
• pplx-embed-v1（2026 年，Perplexity）：這是專為真實世界、網路規模檢索打造的頂尖文字嵌入模型系列，採用以擴散為基礎的預訓練，將因果語言模型轉化為雙向編碼器。它會為獨立編碼的查詢與文件產生稠密嵌入，並透過量化感知訓練降低儲存成本。我們的 4B INT8 模型在多語言 MTEB 檢索基準測試中達到 69.66 nDCG@10，而 Google 的 gemini-embedding-001 則為 67.71。
• pplx-embed-context-v1（2026 年，Perplexity）：解決了文件分塊的一個常見問題：段落一旦脫離周圍文字，就可能失去原有的含義。此模型採用延遲分塊技術，先處理整份文件，再將情境化的詞元表示法池化為個別的區塊嵌入。我們的 4B 模型在 ConTEB 上達到 81.96 nDCG@10，而 voyage-context-3 則為 79.45。
• pplx-embed-v2-context（2026 年，Perplexity）：將情境化檢索推向更高層次。它不只學習找出包含答案的段落，還能辨識有助於解釋或驗證該答案的佐證段落。此模型在訓練期間使用從脈絡壓縮模型蒸餾而來的相關性訊號，推論時則不需要該教師模型。我們的 9B 預覽版在 context-bench 上，前 10 筆結果的答案召回率達 45.5%，證據召回率達 40.6%。

Perplexity 的模型也支援大規模儲存嵌入。這些模型可產生 INT8 與二進位嵌入，與 FP32 相比，儲存需求分別降至四分之一與三十二分之一。

pplx-embed 模型的維度、上下文長度、量化與池化設定

稠密、稀疏與多向量嵌入

還有一項值得了解的區別，對語意搜尋而言尤其重要：嵌入模型在如何表示文字與計算相關性上可能有所不同。

• 稠密嵌入：使用精簡的向量來表示文字，其中大多數數值都不為零。
• 稀疏嵌入：使用大部分數值為零的向量，並為重要字詞賦予學習而得的權重。SPLADE（2021 年）等模型會學習哪些字詞對檢索相關文件最為重要。
• 多向量嵌入：為一段文字保留多個向量，讓查詢與文件之間能進行更細緻的比較。ColBERT（2020 年）等模型會運用這類表示法，進行更細緻的查詢與文件比較。
• 結合多種方法的模型：BGE-M3（2024 年）由 BAAI 開發，可在同一個模型中支援稠密、稀疏與多向量檢索。

如何選擇及評估文字嵌入模型

MTEB 等公開基準測試是很好的起點。您可以利用這些基準測試，篩選出兩到三個支援您所需語言、輸入長度與部署需求的模型。但先別急著選出贏家。我們必須再三強調，用您自己的資料測試這些模型非常重要。

以下是一套實用的評估工作流程：

1. 建立測試資料集。收集 50 到 100 個具代表性的搜尋查詢作為初步評估集（您可能需要更多），其中應包含改述、技術術語與精確錯誤代碼等棘手案例。針對每個查詢，找出哪些文件或段落含有相關答案。這些相關性標籤就會成為您的標準答案（ground truth）。
2. 衡量檢索品質。使用相同的評估資料集測試每個模型，讓文件準備方式與檢索條件維持可比性，同時遵循各模型在查詢格式、正規化與相似度評分方面的特定要求。接著使用 Sentence Transformers 的 InformationRetrievalEvaluator 計算下列指標：
   • Recall@k：表示相關段落出現在前 k 筆結果中的比例。
   • MRR：衡量第一個相關結果在排名中的位置有多靠前。
   • nDCG@k：根據相關性，衡量前 k 筆結果的排序品質。
3. 對延遲與輸送量進行基準測試。測量每個模型嵌入一個查詢所需的時間，最好能列出在貼近實際的負載下，中位數（p50）與第 95 百分位數（p95）的延遲。
4. 計算儲存與營運成本。向量儲存空間取決於嵌入的數量、維度與數值精度。舉例來說，一百萬個 768 維的 FP32 嵌入，在不計索引額外負擔的情況下，大約需要 3.1 GB 的原始向量儲存空間。若要降低儲存需求，可以將向量量化為較低的數值精度。例如從 FP32 改為 INT8，原始向量儲存空間大約可縮減至原本的四分之一。不過，壓縮可能會影響檢索品質，因此請重新執行評估，確認其中的取捨。

最後，將各項結果並列比較：檢索指標、p95 延遲、輸送量、儲存空間與成本。選擇能在正式環境的限制下符合品質要求的模型。

什麼時候該使用嵌入，而不是 LLM？

如今 LLM 從文件分析到複雜推理無所不包，很容易讓人想把所有文字一股腦丟給模型，讓它自行處理。但你大概不會樂於為此買單。

此外，LLM 雖然更擅長判斷與撰寫，卻受限於單一提示詞所能容納的資訊量。相較之下，嵌入成本低、速度快、結果一致，而且能處理數百萬個項目。

「嵌入在搜尋、推薦（『更多類似內容』）、找出重複項目（例如重複的客服工單），以及依主題將大量內容分組等方面表現較佳，在跨語言處理上也很強。而當任務需要推理時，例如摘要、比較選項或撰寫答案，LLM 則更勝一籌。大多數實際系統兩者都需要，讓各自負責擅長的部分。」Kumar 總結道。

開發人員在文字嵌入上常犯的錯誤

為了瞭解開發人員常忽略哪些事，我訪問了 Rahul Kumar 與 Xibeijia Guan（Ahrefs 資料科學家）。他們點出了六個值得留意的錯誤：

• 略過文字前處理。如果輸入資料包含 HTML、導覽選單、廣告或其他無關內容，移除樣板內容等前處理步驟可以去除不必要的資訊，有助於提升嵌入品質。
• 忽略模型的最大輸入長度。不同模型有不同的 token 上限與截斷行為。超過上限的文字可能會被截斷，導致重要資訊遺失。
• 未遵循模型的特定要求。有些嵌入模型需要特定前綴，例如 query: 與 passage:，或針對不同任務使用不同的指令。未遵循這些要求可能會降低檢索效能。
• 使用不相容的相似度量測方式。餘弦相似度與內積不一定能互換使用。請確認嵌入是否已正規化，並採用模型與向量索引建議的評分方法。
• 誤把主題相似當成相關。在領域範圍狹窄的文件集合中，許多文件在語意上可能很相似，卻不見得回答同一個問題。請檢查失敗的查詢與排名分布。當使用者需要精確資訊時，可測試詞彙檢索或混合檢索、重新排序及中繼資料篩選器。
• 忽略嵌入正規化。不同的嵌入模型可能輸出已正規化或未正規化的向量。請根據你使用的相似度指標，確認嵌入是否已正規化，以及是否需要額外進行正規化。

文字嵌入常見問題

1. 如何產生文字嵌入？

最簡單的做法是使用預先訓練的嵌入模型。舉例來說，透過 Python 的 Sentence Transformers 程式庫，你可以載入 all-MiniLM-L6-v2 等模型，將文字傳入 model.encode()，即可取得一個數值向量。你也可以改用 API 來產生嵌入。

若用於語意搜尋或 RAG，通常會將文件切分成多個區塊，為每個區塊產生嵌入，再將向量儲存在可搜尋的索引中。

2. 最適合文字的嵌入模型有哪些？

視你要打造的應用而定，有幾個模型值得考慮：

• Perplexity 的 pplx-embed-v1：專為大規模密集檢索打造，提供 INT8 與二進位嵌入，可降低向量儲存需求。
• Perplexity 的 pplx-embed-context-v1：適合從長篇文件中檢索段落，尤其是個別區塊一旦脫離上下文就會失去意義的情況。
• all-MiniLM-L6-v2：適合輕量的本機語意搜尋、分群與句子相似度任務。可產生精簡的 384 維向量，但超過 256 個詞片段（word piece）的輸入會被截斷。
• BGE-M3：適合多語言 RAG 與混合檢索。支援超過 100 種語言，並結合密集、稀疏與多向量表示。
• Qwen3-Embedding：多語言搜尋、程式碼檢索與特定任務嵌入的有力選擇。提供 0.6B、4B 與 8B 的開放權重模型，並支援指令。
• OpenAI 的 text-embedding-3-large：透過 API 提供的選項，適合不想自行託管模型時用於語意搜尋與文件檢索。最高支援 3,072 維，也可降低維度以節省儲存空間。
• Google 的 Gemini Embedding 模型：適合託管式檢索應用。Gemini Embedding 2 也支援在共用的嵌入空間中跨文字、圖片、音訊、影片與 PDF 進行搜尋。

3. 可以把 LLM 當作嵌入模型使用嗎？

可以，但通用型 LLM 與針對嵌入最佳化的 LLM 之間有所差異。LLM 會產生文字的內部向量表示，你可以將其擷取出來並池化為單一嵌入。然而，若未經額外訓練，這些向量不一定適用於語意搜尋。

例如，Qwen3-Embedding 採用 LLM 骨幹，並針對嵌入與檢索任務進一步訓練。因此，雖然你可以調整 LLM 來產生嵌入，但專用的嵌入模型通常是比較實際的起點。