RAG 模型的“靈魂伴侶”:如何挑選最適合的嵌入方法? 原創
在當今信息爆炸的時代,如何從海量數據中快速、準確地獲取所需信息,成為了一個亟待解決的問題。而 Retrieval-Augmented Generation(RAG)模型的出現,就像為信息檢索和生成插上了翅膀。它就像一位記者,在撰寫報道時不僅依賴記憶,還會深入檔案庫查找資料、核實事實,從而讓內容更加準確、有說服力。而在這個過程中,選擇合適的嵌入方法(embedding)就如同為記者配備了強大的“搜索引擎”,能夠幫助模型更高效地檢索和排序相關信息。今天,就讓我們一起深入探討如何為 RAG 模型挑選出最合適的嵌入方法,讓模型的輸出更加精準、高效!
一、選擇合適文本嵌入模型的關鍵參數
RAG 模型對文本嵌入的質量有著極高的要求。文本嵌入的作用是將文本轉換為數值向量,讓模型能夠對文本數據進行處理和比較。一個優質的嵌入模型可以顯著提升檢索的準確性、響應的相關性以及系統的整體性能。那么,在眾多的嵌入模型中,我們該如何做出選擇呢?以下這些關鍵參數將幫助我們做出明智的決策。
(一)上下文窗口(Context Window)
上下文窗口是指模型在一次輸入中能夠處理的最大標記(單詞或子詞)數量。例如,如果一個模型的上下文窗口為 512 個標記,那么它一次只能處理 512 個標記的內容。如果文本更長,就需要將其截斷或分割成更小的片段。有些嵌入模型,比如 OpenAI 的 text-embedding-ada-002(支持 8192 個標記)和 Cohere 的嵌入模型(支持 4096 個標記),擁有更長的上下文窗口,這使得它們在處理 RAG 應用中的長篇文檔時表現出色。
為什么它很重要?
- 更寬的上下文窗口可以讓模型處理更長的文檔或文本字符串,而不會被截斷。
- 對于像語義搜索長文本(例如科學論文)這樣的操作,需要較大的上下文窗口(例如 8192 個標記)。
(二)標記化單元(Tokenization Unit)
標記化是將文本分解成模型可以處理的更小單元(標記)的過程。標記化單元指的是用于將文本分割成標記的方法。
常見的標記化方法如下:
- 子詞標記化(Subword Tokenization,例如字節對編碼 BPE):它將單詞分割成更小的子詞單元,例如將“unhappiness”分割成“un”和“happiness”。這種方法可以有效處理罕見或詞匯表外的單詞,提高文本表示的魯棒性。
- WordPiece:這種方法與字節對編碼類似,但針對像 BERT 這樣的模型進行了優化。它根據頻率將單詞分割成更小的單元,確保高效的標記化和更好的罕見詞處理能力。
- 單詞級標記化(Word-Level Tokenization):它將文本分割成單獨的單詞,對于處理罕見詞或大詞匯表的效率較低,因為它缺乏子詞分割。
為什么它很重要?
- 標記化技術會影響模型處理文本的質量,尤其是對于不常見的或特定領域的單詞。
- 當代大多數模型傾向于使用子詞標記化,因為它既能滿足詞匯表大小的需求,又能保持靈活性。
(三)維度(Dimensionality)
維度指的是模型生成的嵌入向量的大小。例如,一個具有 768 維嵌入的模型會為每個輸入文本輸出一個包含 768 個數字的向量。
為什么它很重要?
- 更高維度的嵌入可以捕捉更細微的語義信息,但需要更多的計算資源。
- 更低維度的嵌入速度更快、效率更高,但可能會丟失一些語義豐富性。
- 例如,OpenAI 的 text-embedding-3-large 生成 3072 維的嵌入,而 Jina Embeddings v3 生成 1024 維的嵌入。
(四)詞匯表大小(Vocabulary Size)
詞匯表大小是指分詞器能夠識別的獨特標記(單詞或子詞)的數量。
為什么它很重要?
- 更大的詞匯表大小可以讓模型處理更廣泛的單詞和語言,但會增加內存使用量。
- 更小的詞匯表大小更高效,但可能難以處理罕見的或特定領域的術語。
- 例如,大多數現代模型(如 BERT、OpenAI)的詞匯表大小為 30000-50000 個標記。
(五)訓練數據(Training Data)
訓練數據是指用于訓練模型的數據集。它決定了模型的知識和能力。
不同類型的訓練數據如下:
- 通用數據(General-Purpose Data):這些模型在多種數據源上進行訓練,例如網頁、書籍和維基百科。它們在廣泛的任務中表現出色,如語義搜索和文本分類。
- 特定領域數據(Domain-Specific Data):這些模型基于特定領域的數據集構建,例如法律文件、生物醫學文本或科學論文。它們在特定應用中表現更好。
為什么它很重要?
- 訓練數據的質量和多樣性會影響模型的性能。
- 特定領域的模型(例如 LegalBERT、BioBERT)在特定任務中表現更好,但在通用任務中可能會遇到困難。
(六)成本(Cost)
成本指的是使用嵌入模型所需的財務和計算資源,包括與基礎設施、API 使用和硬件加速相關的費用。
模型分為以下兩種類型:
- 基于 API 的模型(API-Based Models):像 OpenAI、Cohere 和 Gemini 這樣的按使用付費服務,根據 API 調用和輸入/輸出大小收費。
- 開源模型(Open-Source Models):免費使用,但需要計算資源(如 GPU 或 TPU)進行訓練或推理,并且如果自行托管,可能會產生基礎設施成本。
為什么它很重要?
- 基于 API 的模型使用方便,但對于大規模應用可能會變得昂貴。
- 開源模型具有成本效益,但需要技術專長和基礎設施。
(七)質量(MTEB 分數)
MTEB(大規模文本嵌入基準)分數衡量嵌入模型在廣泛任務中的性能,包括語義搜索、分類和聚類。
為什么它很重要?
- 更高的 MTEB 分數表示更好的整體性能。
- MTEB 分數較高的模型更有可能在你的特定任務中表現良好。
- 例如,OpenAI 的 text-embedding-3-large 的 MTEB 分數約為 64.6,而 Jina Embeddings v3 的分數約為 59.5。
二、構建 RAG 模型的熱門文本嵌入
現在,讓我們來了解一下構建 RAG 系統的熱門文本嵌入模型。以下是一些常見的模型及其關鍵參數對比:
模型名稱 | 上下文窗口 | 每百萬標記成本 | MTEB 分數 | 詞匯表大小 | 標記化單元 | 維度 | 訓練數據 |
OpenAI text-embedding-ada-002 | 8192 個標記 | 0.10 美元 | 約 61.0 | 未公開 | 子詞(BPE) | 1536 | 未公開 |
NVIDIA NV-Embed-v2 | 32768 個標記 | 開源 | 72.31 | 50000+ | 子詞(BPE) | 4096 | 硬負樣本挖掘、合成數據生成、公開數據集 |
OpenAI text-embedding-3-large | 8192 個標記 | 0.13 美元 | 約 64.6 | 未公開 | 子詞(BPE) | 3072 | 未公開 |
OpenAI text-embedding-3-small | 8192 個標記 | 0.02 美元 | 約 62.3 | 50257 | 子詞(BPE) | 1536 | 未公開 |
Gemini text-embedding-004 | 2048 個標記 | 不適用 | 約 60.8 | 50000+ | 子詞(BPE) | 768 | 未公開 |
Jina Embeddings v3 | 8192 個標記 | 開源 | 約 59.5 | 50000+ | 子詞(BPE) | 1024 | 大規模網絡數據、書籍等 |
Cohere embed-english-v3.0 | 512 個標記 | 0.10 美元 | 約 64.5 | 50000+ | 子詞(BPE) | 1024 | 大規模網絡數據、書籍等 |
voyage-3-large | 32000 個標記 | 0.06 美元 | 約 60.5 | 50000+ | 子詞(BPE) | 2048 | 多領域數據集,包括大規模網絡數據、書籍等 |
voyage-3-lite | 32000 個標記 | 0.02 美元 | 約 59.0 | 50000+ | 子詞(BPE) | 512 | 多領域數據集,包括大規模網絡數據、書籍等 |
Stella 400M v5 | 512 個標記 | 開源 | 約 58.5 | 50000+ | 子詞(BPE) | 1024 | 大規模網絡數據、書籍等 |
Stella 1.5B v5 | 512 個標記 | 開源 | 約 59.8 | 50000+ | 子詞(BPE) | 1024 | 大規模網絡數據、書籍等 |
ModernBERT Embed Base | 512 個標記 | 開源 | 約 57.5 | 30000 | WordPiece | 768 | 大規模網絡數據、書籍等 |
ModernBERT Embed Large | 512 個標記 | 開源 | 約 58.2 | 30000 | WordPiece | 1024 | 大規模網絡數據、書籍等 |
BAAI/bge-base-en-v1.5 | 512 個標記 | 開源 | 約 60.0 | 30000 | WordPiece | 768 | 大規模網絡數據、書籍等 |
law-ai/LegalBERT | 512 個標記 | 開源 | 約 55.0 | 30000 | WordPiece | 768 | 法律文件、案例法等 |
GanjinZero/biobert-base | 512 個標記 | 開源 | 約 54.5 | 30000 | WordPiece | 768 | 生物醫學和臨床文本 |
allenai/specter | 512 個標記 | 開源 | 約 56.0 | 30000 | WordPiece | 768 | 科學論文和引文圖 |
m3e-base | 512 個標記 | 開源 | 約 57.0 | 30000 | WordPiece | 768 | 中英文文本 |
三、如何選擇嵌入方法:案例研究
接下來,我們將通過一個具體的案例來展示如何根據需求選擇合適的嵌入模型。假設我們需要為一個基于文本的檢索系統選擇最佳的嵌入模型,該系統將在一個包含大量科學論文的大型數據集上執行語義搜索。這個系統必須能夠處理長篇文檔(2000 到 8000 個單詞),并且要實現高準確率的檢索,通過強大的大規模文本嵌入基準(MTEB)分數來衡量,以確保搜索結果具有意義和相關性。同時,它還需要在成本效益和可擴展性方面表現出色,每月預算在 300 到 500 美元之間。
(一)特定領域需求
科學論文中充滿了技術術語和復雜的語言,因此需要一個在學術、科學或技術文本上訓練過的模型。因此,我們需要排除那些主要針對法律或生物醫學領域定制的模型,因為它們可能無法有效地推廣到更廣泛的科學文獻中。
被排除的模型:
- law-ai/LegalBERT(專門處理法律文本)
- GanjinZero/biobert-base(專注于生物醫學文本)
(二)上下文窗口大小
一篇典型的科研論文包含 2000 到 8000 個單詞,這相當于 2660 到 10640 個標記(假設每 1.33 個標記對應一個單詞)。將系統的容量設置為 8192 個標記,可以處理長達約 6156 個單詞的論文(8192 ÷ 1.33)。這將涵蓋大多數研究論文,無需截斷,能夠捕捉研究論文的完整上下文,包括摘要、引言、方法、結果和結論。
對于我們的用例來說,上下文窗口小于或等于 512 個標記的模型是不足夠的。因此,我們需要排除上下文窗口為 512 個標記或更小的模型。
被排除的模型:
- Stella 400M v5(512 個標記)
- Stella 1.5B v5(512 個標記)
- ModernBERT Embed Base(512 個標記)
- ModernBERT Embed Large(512 個標記)
- BAAI/bge-base-en-v1.5(512 個標記)
- allenai/specter(512 個標記)
- m3e-base(512 個標記)
(三)成本與托管偏好
考慮到每月 300 到 500 美元的預算,并且更傾向于自行托管以避免重復的 API 費用,我們需要評估每個模型的成本效益。讓我們來看看剩下列表中的模型。
OpenAI 模型:
- text-embedding-3-large:每 1000 個標記收費 0.13 美元
- text-embedding-3-small:每 1000 個標記收費 0.02 美元
Jina Embeddings v3:
開源且可以自行托管,消除了按標記收費的成本。
成本分析:假設平均每篇文檔有 8000 個標記,每月處理 10000 篇文檔,那么上述嵌入的成本如下:
- OpenAI text-embedding-3-large:
- 8000 個標記/文檔 × 10000 篇文檔 = 80000000 個標記
- 80000 × 0.13 = 10400 美元(超出預算)
- OpenAI text-embedding-3-small:
- 80000 × 0.02 = 1600 美元(超出預算)
- Jina Embeddings v3:
- 沒有按標記收費,只有基礎設施費用。
被排除的模型(超出預算):
- OpenAI text-embedding-3-large
- OpenAI text-embedding-3-small
(四)基于 MTEB 分數的最終評估
大規模文本嵌入基準(MTEB)會在各種任務中評估嵌入模型,提供一個全面的性能指標。
性能洞察:
讓我們比較一下剩下幾個模型的性能。
- Jina Embeddings v3:
- 在 MTEB 框架內的英語任務中,其表現優于 OpenAI 的專有嵌入。
- Voyage-3-large:
- MTEB 分數約為 60.5,具有 32000 個標記的上下文窗口,使其適合長文檔檢索,并且成本效益高。
- NVIDIA NV-Embed-v2:
- MTEB 分數達到 72.31,顯著優于許多其他選擇。
- 32768 個標記的上下文窗口使其非常適合長文檔。
- 自行托管且開源,消除了按標記 API 成本。
(五)做出最終決定
現在,讓我們綜合評估這些模型的各個方面,做出最終選擇。
- NVIDIA NV-Embed-v2:推薦選擇,因為它具有較高的 MTEB 分數(72.31)、長上下文窗口(32768 個標記)以及自行托管的能力。
- Jina Embeddings v3:一個具有成本效益的替代方案,沒有 API 成本,并且性能具有競爭力。
- Voyage-3-large:一個預算友好的選擇,具有較大的上下文窗口(32000 個標記),但 MTEB 分數略低。
如果對基礎設施成本有顧慮,Jina Embeddings v3 和 Voyage-3-large 是不錯的選擇。但如果追求高性能、成本效益和長上下文的語義搜索,NVIDIA NV-Embed-v2 是科學論文檢索系統中的最佳選擇。
四、進階技巧:微調嵌入模型
微調嵌入模型并不總是必要的。在許多情況下,現成的模型已經足夠好。然而,如果你需要為特定數據集優化結果,微調可能會幫助你榨取出最后一點性能提升。當然,微調會帶來大量的計算成本和費用,這需要謹慎考慮。
如何微調嵌入模型
- 收集特定領域的數據:整理與你的應用相關的數據集。例如,如果你的任務涉及法律文件,就收集案例法和法律文本。
- 預處理數據:清理、分詞并格式化文本,確保在訓練前保持一致性。
- 選擇基礎模型:選擇一個與你的領域最接近的預訓練嵌入模型(例如,SBERT 適用于基于文本的應用)。
- 使用對比學習進行訓練:使用監督對比學習或三元組損失技術,根據語義相似性細化嵌入。
- 評估性能:將微調后的嵌入與原始模型進行比較,確保檢索準確性有所提高。
五、總結
為你的檢索增強生成(RAG)模型選擇合適的嵌入方法,是實現有效、準確檢索相關文檔的重要過程。這個決策基于多種因素,如數據模態、檢索復雜性、計算能力和可用預算。雖然基于 API 的模型通常提供高質量的嵌入,但開源替代方案為自行托管的解決方案提供了更大的靈活性和成本效益。
通過仔細評估嵌入模型的上下文窗口大小、語義搜索能力和基準性能,你可以為你的特定用例優化 RAG 系統。此外,微調嵌入可以在特定領域應用中進一步提升性能,但這需要仔細考慮計算成本。最終,一個精心選擇的嵌入模型為有效的 RAG 流程奠定了基礎,提高了響應準確性和系統的整體效率。
希望這篇文章能幫助你在選擇嵌入模型時更加得心應手,讓你的 RAG 模型在信息檢索的戰場上所向披靡!
本文轉載自公眾號Halo咯咯 作者:基咯咯
原文鏈接:??https://mp.weixin.qq.com/s/JqQKIn9kd0Ys5DsnuZGtsg??
