檢索增強生成（RAG）是當前構建生成式 AI 應用最熱門的框架。企業機構青睞它，因為它能利用專有數據來回答用戶問題，使大語言模型能夠為用戶提供精準、及時且與問題高度相關的答案。

根據我近兩年構建 RAG 應用的經驗，回答質量很大程度上取決于檢索到的上下文信息。

而提升 RAG 檢索效果的關鍵在于：將數據分割至合適大小的文本塊、選擇合適的嵌入模型，并采用高效的檢索機制。

嵌入模型是大語言模型的支柱。當你要求大語言模型協助調試代碼時，你輸入的文字和詞元會通過嵌入模型轉換成一系列高維空間中的坐標（即向量）。在這個數學空間里，詞語之間含義上的遠近、相似關系，就變成了向量之間距離和角度的計算關系。如果選用了不當的嵌入模型，你的 RAG 應用可能會檢索到不相關的或混亂的數據，從而導致回答質量下降、成本增加，并引發用戶不滿。

本文將闡述嵌入模型的原理、重要性以及選型時應考量的因素。我們還將分析不同嵌入模型的特性及其適用場景。閱讀完畢后，期望各位讀者能夠明確如何選擇最合適的嵌入模型，從而提升回答的準確性，并保障 RAG 應用平穩運行。

一、什么是嵌入？

嵌入是一種能夠捕捉語言含義與規律的數字表征。這些數字能幫助你的系統找到與問題或主題密切相關的信息。

這類嵌入是通過嵌入模型生成的。嵌入模型可以接收文字、圖像、文檔甚至聲音，并將其轉化為一系列稱為“向量”的數字。

什么是嵌入？ — 該圖片由原文作者提供

你可能是在了解大語言模型時接觸到“嵌入”這一概念的，但實際上，嵌入的歷史要悠久得多。

二、這些嵌入是如何被計算出來的？

目前，嵌入主要通過語言模型來生成。

與使用靜態向量表示每個詞元或單詞不同，語言模型會動態地生成上下文關聯的詞嵌入 —— 即根據不同的語境，用不同的向量來表征單詞/句子/文本塊。這些向量隨后可被其他系統用于各類任務。

生成文本嵌入向量的方法有多種。最常見的一種是對模型生成的所有詞元嵌入值取平均值。但高質量的文本嵌入模型往往是專門針對文本嵌入任務訓練的。

我們可以使用 sentence-transformers[1]（一個被廣泛使用的預訓練嵌入模型工具包）來生成文本嵌入。

from sentence_transformers import SentenceTransformer
 
# Load model
model = SentenceTransformer("sentence-transformers/all-mpnet-base-v2")
 
# Convert text to text embeddings
vector = model.encode("Best movie ever!")

嵌入向量所含的數值數量（即維度）取決于底層嵌入模型。可通過 vector.shape 方法獲取嵌入向量的維度信息。

三、為何在 RAG 系統中嵌入非常重要？

嵌入在檢索增強生成（RAG）系統中發揮著非常關鍵的作用，原因如下：

語義理解：嵌入將詞語、句子或文檔轉化為向量（數字序列），并使語義相近的內容在向量空間中彼此靠近。這使系統能夠理解上下文和語義，而非僅僅進行字面匹配。

高效檢索：RAG 需要快速定位最相關的文本段落或文檔。嵌入能通過 k 近鄰（k-NN）等算法實現高效檢索，讓檢索過程更快速便捷。

讓回答更精準且切題：借助嵌入技術，模型能夠識別與問題語義相關的信息，即使表述用語完全不同。這意味著用戶能獲得更精準且切題的回答。

四、嵌入的類型

嵌入具有多種形式，具體取決于系統需要處理的信息類型。

嵌入的類型 —— 由原文作者供圖

1.基于系統需理解的信息類型劃分

1.1詞嵌入

詞嵌入將每個詞語表示為多維空間中的一個點。含義相近的詞語（如“dog”和“cat”）在空間中的位置會彼此靠近。這有助于計算機理解詞語之間的語義關聯，而不僅是拼寫形式。

流行的詞嵌入模型包括：

• Word2Vec：從大量文本中學習詞語關系。
• GloVe：重點關注詞語共同出現的頻率。
• FastText：將詞語分解為更小的組成部分，能更有效處理生僻詞或拼寫錯誤的詞語。

向量嵌入空間 —— 由原文作者供圖

1.2句嵌入

有時，需要從整個句子而不僅是單個單詞來理解完整語義。句嵌入將一個句子的整體語義捕獲為一個向量。

知名的生成句嵌入的模型有：

• Universal Sentence Encoder（USE）：適用于各種類型的句子，包括疑問句和陳述句。
• SkipThought：通過學習預測前面和后面可能出現的句子，來理解語境和用戶意圖。

1.3文檔嵌入

文檔可以是一個段落乃至整本書。文檔嵌入將所有文本轉化為單個向量，便于在大型文檔庫中進行搜索，并查找與查詢相關的內容。

主流的文檔嵌入模型包括：

• Doc2Vec：基于 Word2Vec 構建，但專為較長文本設計。
• Paragraph Vectors：與 Doc2Vec 類似，但側重于段落等較短文本。

1.4圖像嵌入

RAG 系統不僅能處理文本，也能處理圖像。圖像嵌入將圖片轉換為描述顏色、形狀和圖案的數字序列。

常用的生成圖像嵌入的模型是卷積神經網絡（CNNs），它特別擅長識別圖像中的模式。

2.基于嵌入的特性劃分

嵌入可以具有不同的特性，這些特性會影響其工作方式和適用場景。以下通過簡單示例說明這些特性：

2.1稠密嵌入

稠密嵌入使用的向量中，幾乎每個位置都填充了有效數值。每個數值都承載著關于詞語、句子、圖像或文檔的一點信息。稠密向量緊湊且高效，能在較小空間內存儲大量細節內容，使計算機能更輕松地進行比對并快速發現相似性。

2.2稀疏嵌入

稀疏嵌入與稠密嵌入相反。向量中大多數數值為零，僅有少數位置有實際數值。零值不攜帶任何信息。稀疏嵌入有助于突出最關鍵的特征，易于識別事物的獨特之處。

稠密嵌入與稀疏嵌入 —— 由原文作者供圖

2.3長上下文嵌入

有時需要理解整個文檔或長對話，而不僅僅是短句。長上下文嵌入就是專為一次性處理大量文本而設計的。

舊模型只能處理短文本。如若輸入長文章，需將它們先切分成小塊，這可能導致舊模型遺漏重要的上下文關聯，或者偏離文章的核心主旨。新模型（如 BGE-M3）可一次性處理數千詞（最高達 8,192 個詞元），有助于計算機把握整體語境。

2.4多向量嵌入

通常，一個項目（如一個單詞或一篇文檔）僅對應一個向量。而多向量嵌入則為每個項目使用多個向量，每個向量可捕獲不同的特征。

通過多個向量，計算機能識別更多的細節和更復雜的關系，從而產生更豐富、更準確的結果。

五、選擇最佳文本嵌入模型需要了解的參數

在選擇模型之前，您需要明確評估標準。以下是幾個關鍵的參數：

如何選擇最佳的文本嵌入模型？ —— 該圖片由原文作者提供，使用 Napkin.ai 制作

5.1上下文窗口

上下文窗口是指模型單次能處理的最大文本長度。例如，若某模型的上下文窗口為 512 個詞元，意味著它一次只能讀取 512 個詞語或詞語片段。更長的文本必須被切分。有些模型（如 OpenAI 的 text-embedding-ada-002，支持一次讀取 8192 個詞元）和 Cohere 的嵌入模型（支持一次讀取 4096 個詞元）則能處理更長的文本。

更大的上下文窗口允許處理更長的文檔而避免信息丟失。這對于檢索長篇文章、研究論文或報告等任務非常有利。

5.2分詞單元

分詞是模型將文本切分為更小單元（稱為詞元）的方式。不同模型采用不同的方法：

• Subword Tokenization（例如字節對編碼 BPE）：將詞語拆分成更小的部分。例如，“unhappiness”會被拆為“un”和“happiness”。這有助于處理生僻詞或新詞。
• WordPiece：與 BPE 類似，但常用于 BERT 等模型。
• Word-Level Tokenization：將文本按完整單詞進行切分。對生僻詞處理效果不佳。

模型的分詞方式影響其理解不同詞語（尤其是非常用詞）的能力。大多數現代模型為了提升靈活性而采用 subword tokenization 方法。

5.3向量維度

向量維度是指模型為每段文本生成的數字序列（向量）的長度。例如，有些模型生成 768 維的向量，有些則生成 1024 維甚至 3072 維的向量。

更高維度的向量能存儲更詳細的信息，但需要更強的計算能力。較低維度的向量處理速度更快，但可能丟失部分細節信息。

5.4詞表大小

這是模型所能識別的唯一詞元的數量。更大的詞表能處理更多詞匯和語言，但會占用更多內存。較小的詞表處理速度更快，但可能無法理解生僻詞或專業術語。

例如：大多數現代模型的詞表大小在 3 萬到 5 萬個詞元之間。

5.5訓練數據

訓練數據是模型學習時所使用的數據源。

• 通用型訓練數據：當模型基于多種類型文本（如網頁、書籍）訓練時，它適用于通用場景。這類模型廣泛適用于多種任務。
• 特定領域型訓練數據：當模型使用專業文本（如醫學或法律文檔）訓練時，它會成為特定領域的專家。這類模型非常適合特定垂直領域的任務。

基于特定領域數據訓練的模型在其專業領域表現更佳，但在通用任務上可能表現平平。

5.6成本

成本包括使用模型所需的經濟支出和計算資源。根據我們訪問 LLM 模型方式的不同，成本結構也會有所差異。

• 基于 API 的模型：按使用量付費，例如 OpenAI 或 Cohere 的模型。
• 開源模型：可免費使用，但需要自有硬件（如 GPU）和相關技術能力來部署運行。

API 易于使用，但處理大量數據時可能成本高昂。開源模型能節省費用，但需要更多的部署工作和專業技術知識。

六、選擇嵌入模型的關鍵考量因素

1. 明確數據領域特性

根據實戰經驗，設計 RAG 系統時我首先會思考：“系統需要處理什么類型的數據？”

若涉及通用知識或常見問題，OpenAI 的 text-embedding-3-small 這類通用嵌入模型通常足夠勝任。但在醫療、法律、金融等專業領域，BioBERT、SciBERT 或 Legal-BERT 等專用領域模型表現更佳，這些模型經過特定領域語料訓練，能精準理解專業語境。

若需處理商品圖片或語音查詢，則應選擇多模態嵌入方案。CLIP 模型能同時處理文本與圖像，是可靠選擇。

2. 嵌入維度與模型復雜度

接著需要評估查詢與文檔的特征：篇幅長短、結構是否規整。某些模型擅長處理簡短片段，另一些則專精于非結構化的長文本內容。

選擇一個合適的嵌入維度非常重要。高維向量（1536 或 4096 維）能捕捉更細微的差異和上下文信息，它們通常能提升檢索精度，但會消耗更多計算資源與存儲空間。

低維向量（384 或 768 維）響應更快、資源消耗更少，特別適合處理百萬級文檔的場景。權衡標準很明確：高維意味著精度優先但成本更高，低維則側重效率但可能犧牲部分準確性。

建議從 384-768 維起步，能在性能與資源消耗間取得最佳平衡。

Pinecone、Weaviate、FAISS 等現代向量數據庫支持通過量化或降維技術壓縮嵌入，可在控制成本的前提下使用高維嵌入。

3. 計算效率

響應速度是實時應用中的一個關鍵考量指標。

若應用對延遲極度敏感，應選擇推理時長較短的模型。DistilBERT 或 MiniLM 等輕量模型在保證多數任務精度的同時，能提供極速響應。

4. 上下文理解能力

需要系統評估 RAG 系統待處理的查詢類型，以及知識庫文檔的結構特征與篇幅長度。文檔必須根據應用場景進行智能分塊，確定最佳片段尺寸。

影響答案準確性的關鍵因素在于模型的上下文窗口 —— 即單次能處理的文本總量。面對冗長復雜的文檔時，更大的上下文窗口能顯著提升效果。單次處理文本量越大的模型，針對長查詢的應答精準度越高。

5. 系統兼容性

優先選擇能與現有技術設施無縫集成的模型。

TensorFlow、PyTorch 及 Hugging Face 提供的預訓練模型通常具備更便捷的部署流程，并擁有完善的文檔體系與活躍的社區支持。

6. 成本控制

項目評估時需統籌考慮訓練與部署成本（若計劃微調模型并自主部署）。不過多數 RAG 應用可直接使用現成模型。

大型模型的訓練與運行成本更為高昂。開源方案通常經濟性更佳，但可能需要額外的配置與運維；商用方案性能更優、支持更完善，但價格較高。

七、示例場景：為醫療科研論文選擇嵌入模型

假設你需要構建一個醫療科研論文的語義檢索系統，要求用戶能快速精準定位相關研究。該系統的數據集規模龐大，單篇文檔長度在 2000 至 8000 詞之間。所需模型需能處理長文本、保證檢索質量，且月預算控制在 300-500 美元。

如何選擇最合適的嵌入模型？我們將逐步拆解決策流程。

第一步：重點關注領域相關性

醫療科研論文包含復雜醫學術語與技術表述。所選模型需經過科研類或學術類文本訓練，而非僅適用于法律或通用領域。

因此，主要為法律或生物醫學設計的模型并不適用于更廣泛的科研場景。

第二步：驗證上下文窗口尺寸

科研論文篇幅較長，需要具備大上下文窗口的模型。大多數論文含 2000-8000 詞（約 2660-10640 個 token，按 1 詞 ≈ 1.33 token 計算）。

擁有 8192 token 上下文窗口的模型可一次性覆蓋約 6156 詞。

若模型僅支持 512 token，將無法完整處理整篇論文。

因此，建議此處跳過以下模型：

• Stella 400M v5
• Stella 1.5B v5
• ModernBERT Embed Base
• ModernBERT Embed Large
• BAAI/bge-base-en-v1.5
• allenai/specter
• m3e-base

第三步：評估成本與部署方案

預算有限時，按 token 計費可能導致費用激增（尤其針對長文檔的高頻檢索場景）。

對比以下模型：

• OpenAI text-embedding-3-large：0.00013 美元/千 token
• OpenAI text-embedding-3-small：0.00002 美元/千 token
• Jina Embeddings v3：開源，可自托管，不按 token 計費

成本測算（按每月處理 1 萬篇 8000 token 的文檔計算）：

• OpenAI text-embedding-3-large：10.4 美元/月（符合預算）
• OpenAI text-embedding-3-small：1.6 美元/月（遠低于預算）
• Jina Embeddings v3：沒有按 token 計費的費用，但需承擔模型部署成本（根據服務器配置以及是否混合部署其他模型而異）

第四步：比對性能指標（MTEB）

接下來評估候選模型的實際性能，通過 Massive Text Embedding Benchmark (MTEB) 的評估分數量化模型性能：

• OpenAI text-embedding-3-large：性能強勁（MTEB 評分約為 71.6），支持一次讀取 8191 個 token，成本效益佳
• OpenAI text-embedding-3-small：性能良好（MTEB 評分約為 69.42），支持一次讀取 8191 個 token，成本效益突出
• Voyage-3-large：MTEB 評分約為 60.5，支持一次讀取 32000 個 token，性價比較高
• NVIDIA NV-Embed-v2：MTEB 評分約為 72.31，支持一次性讀取 32768 個 token，開源可自托管

最終候選名單：

經過多輪篩選，入圍模型包括：OpenAI text-embedding-3-small/large、Voyage-3-large、NVIDIA NV-Embed-v2。

這些模型均能處理長篇醫療論文，精度可靠且符合預算要求。其中 NVIDIA NV-Embed-v2 憑借最高的 MTEB 評分和超大上下文窗口，成為醫療科研內容語義檢索的優選方案。

選擇嵌入模型需綜合考量：明確需求邊界、橫向對比、選出與項目目標最匹配的模型。

八、幫助選擇正確嵌入模型的基準測試

新的嵌入模型不斷涌現，如何持續追蹤它們的性能？幸運的是，現在有一些大規模基準測試，可以幫助我們及時了解各模型的表現。

8.1 Massive Text Embedding Benchmark (MTEB)

MTEB 是一個由社區運營的排行榜。它比較了超過 100 個文本和圖像嵌入模型在 1000 多種語言上的性能。該平臺整合了模型評估指標、測試模型能力的各種場景和各種跨領域的數據，是一種高效且可靠的初步篩選方法。

鏈接：MTEB Dashboard（https://huggingface.co/spaces/mteb/leaderboard）

Massive Text Embedding Benchmark (MTEB) Dashboard

8.2 Massive Multilingual Text Embedding Benchmark (MMTEB)

傳統基準測試通常僅覆蓋少數語言或垂直領域，而 MMTEB 作為 MTEB 的擴展版本，涵蓋了 250 多種語言中的 500 多項評估任務，同時還包含指令遵循、長文檔檢索、代碼檢索等高難度挑戰，是當前最全面的多語言嵌入基準測試。

鏈接：研究論文（https://arxiv.org/abs/2502.13595）

九、應該在什么時候使用 MTEB 基準測試？以及如何使用它？

MTEB 能直觀展示各模型在不同任務中的表現差異，幫助我們根據具體需求縮小選擇范圍。

但請注意：切勿盲目迷信 MTEB 的評分。

MTEB 分數并不能反映全貌。頂級模型間的分數差往往十分微小，MTEB 總分來自于許多不同任務的得分匯總，但你無法看出模型在不同任務之間的表現波動有多大。有時榜首模型僅具微弱優勢，統計層面多個頂級模型可能實際表現相當。研究者發現，當模型差距極小時，平均分數往往失去參考意義。

更務實的做法是：重點關注與您應用場景相似任務的模型表現。這比追逐總分排名更有意義。無需深究每個數據集，但了解其文本類型（如新聞、科研論文或社交媒體內容）很有幫助，通過數據集描述或瀏覽樣例即可獲取此類信息。

MTEB 雖有用，但需批判性使用。不要盲目選擇最高分模型，而應深入挖掘最適合您任務的方案。

核心原則：沒有萬能的模型。MTEB 的存在正是為了幫我們找到某一場景的最優解。瀏覽排行榜時請思考以下問題：

• 目標語言是否被支持？
• 是否涉及金融/法律等專業術語？
• 模型體積是否適配您的硬件（如筆記本電腦）？
• 硬件內存能否承載模型？
• 輸入長度限制是否匹配文本特征？

明確核心需求后，即可在 MTEB 排行榜中按特征篩選模型，從而找出既性能優異又符合實際條件的模型。

十、總結建議

為 RAG 應用選擇合適的嵌入模型時，不應僅以基準測試分數為唯一標準。MTEB等工具固然能提供參考，但無法展現全貌。關鍵在于要超越數字評分的表象，綜合考慮語言支持度、專業詞匯處理能力、內存限制及文本長度等實際需求。

建議深入分析自身應用場景，基于最相關的任務來對比模型表現。需注意，適用于他人使用場景的模型未必符合您的特定需求。

歸根結底，通過深思熟慮平衡模型性能與實際需求，才能找到最合適的模型。通過充分調研與審慎評估，您終將找到最契合的模型，為 RAG 應用的成功奠定堅實基礎。