怎样为你的 RAG 应用选择合适的嵌入模型?
编者按: 在构建检索增强生成(RAG)系统时,为何有些应用能精准回答用户问题,而另一些却频频"答非所问"?问题的关键,往往不在于大语言模型本身,而在于你是否选对了嵌入模型。
我们今天为大家带来的这篇文章明确指出:选择合适的嵌入模型,是提升 RAG 系统回答质量与运行效率的关键所在。
文章从嵌入的基本原理讲起,系统解析了词嵌入、句嵌入、文档嵌入等不同类型及其适用场景,并深入探讨了上下文窗口、分词方式、维度、训练数据、成本等关键参数的影响。作者还通过医疗论文检索的实例,演示了如何逐步筛选嵌入模型。
作者 | Vivedha Elango
编译 | 岳扬
检索增强生成(RAG)是当前构建生成式 AI 应用最热门的框架。企业机构青睐它,因为它能利用专有数据来回答用户问题,使大语言模型能够为用户提供精准、及时且与问题高度相关的答案。
根据我近两年构建 RAG 应用的经验,回答质量很大程度上取决于检索到的上下文信息。
而提升 RAG 检索效果的关键在于:将数据分割至合适大小的文本块、选择合适的嵌入模型,并采用高效的检索机制。
嵌入模型是大语言模型的支柱。当你要求大语言模型协助调试代码时,你输入的文字和词元会通过嵌入模型转换成一系列高维空间中的坐标(即向量)。在这个数学空间里,词语之间含义上的远近、相似关系,就变成了向量之间距离和角度的计算关系。如果选用了不当的嵌入模型,你的 RAG 应用可能会检索到不相关的或混乱的数据,从而导致回答质量下降、成本增加,并引发用户不满。
本文将阐述嵌入模型的原理、重要性以及选型时应考量的因素。我们还将分析不同嵌入模型的特性及其适用场景。阅读完毕后,期望各位读者能够明确如何选择最合适的嵌入模型,从而提升回答的准确性,并保障 RAG 应用平稳运行。
01 什么是嵌入?
嵌入是一种能够捕捉语言含义与规律的数字表征。这些数字能帮助你的系统找到与问题或主题密切相关的信息。
这类嵌入是通过嵌入模型生成的。嵌入模型可以接收文字、图像、文档甚至声音,并将其转化为一系列称为"向量"的数字。
什么是嵌入? --- 该图片由原文作者提供
你可能是在了解大语言模型时接触到"嵌入"这一概念的,但实际上,嵌入的历史要悠久得多。
02 这些嵌入是如何被计算出来的?
目前,嵌入主要通过语言模型来生成。
与使用静态向量表示每个词元或单词不同,语言模型会动态地生成上下文关联的词嵌入 ------ 即根据不同的语境,用不同的向量来表征单词/句子/文本块。这些向量随后可被其他系统用于各类任务。
生成文本嵌入向量的方法有多种。最常见的一种是对模型生成的所有词元嵌入值取平均值。但高质量的文本嵌入模型往往是专门针对文本嵌入任务训练的。
我们可以使用 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 方法获取嵌入向量的维度信息。
03 为何在 RAG 系统中嵌入非常重要?
嵌入在检索增强生成(RAG)系统中发挥着非常关键的作用,原因如下:
语义理解:嵌入将词语、句子或文档转化为向量(数字序列),并使语义相近的内容在向量空间中彼此靠近。这使系统能够理解上下文和语义,而非仅仅进行字面匹配。
高效检索:RAG 需要快速定位最相关的文本段落或文档。嵌入能通过 k 近邻(k-NN)等算法实现高效检索,让检索过程更快速便捷。
让回答更精准且切题:借助嵌入技术,模型能够识别与问题语义相关的信息,即使表述用语完全不同。这意味着用户能获得更精准且切题的回答。
04 嵌入的类型
嵌入具有多种形式,具体取决于系统需要处理的信息类型。
嵌入的类型 ------ 由原文作者供图
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 多向量嵌入
通常,一个项目(如一个单词或一篇文档)仅对应一个向量。而多向量嵌入则为每个项目使用多个向量,每个向量可捕获不同的特征。
通过多个向量,计算机能识别更多的细节和更复杂的关系,从而产生更丰富、更准确的结果。
05 选择最佳文本嵌入模型需要了解的参数
在选择模型之前,您需要明确评估标准。以下是几个关键的参数:
如何选择最佳的文本嵌入模型? ------ 该图片由原文作者提供,使用 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 易于使用,但处理大量数据时可能成本高昂。开源模型能节省费用,但需要更多的部署工作和专业技术知识。
06 选择嵌入模型的关键考量因素
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 应用可直接使用现成模型。
大型模型的训练与运行成本更为高昂。开源方案通常经济性更佳,但可能需要额外的配置与运维;商用方案性能更优、支持更完善,但价格较高。
07 示例场景:为医疗科研论文选择嵌入模型
假设你需要构建一个医疗科研论文的语义检索系统,要求用户能快速精准定位相关研究。该系统的数据集规模庞大,单篇文档长度在 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 评分和超大上下文窗口,成为医疗科研内容语义检索的优选方案。
选择嵌入模型需综合考量:明确需求边界、横向对比、选出与项目目标最匹配的模型。
08 帮助选择正确嵌入模型的基准测试
新的嵌入模型不断涌现,如何持续追踪它们的性能?幸运的是,现在有一些大规模基准测试,可以帮助我们及时了解各模型的表现。
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)
09 应该在什么时候使用 MTEB 基准测试?以及如何使用它?
MTEB 能直观展示各模型在不同任务中的表现差异,帮助我们根据具体需求缩小选择范围。
但请注意:切勿盲目迷信 MTEB 的评分。
MTEB 分数并不能反映全貌。顶级模型间的分数差往往十分微小,MTEB 总分来自于许多不同任务的得分汇总,但你无法看出模型在不同任务之间的表现波动有多大。有时榜首模型仅具微弱优势,统计层面多个顶级模型可能实际表现相当。研究者发现,当模型差距极小时,平均分数往往失去参考意义。
更务实的做法是:重点关注与您应用场景相似任务的模型表现。这比追逐总分排名更有意义。无需深究每个数据集,但了解其文本类型(如新闻、科研论文或社交媒体内容)很有帮助,通过数据集描述或浏览样例即可获取此类信息。
MTEB 虽有用,但需批判性使用。不要盲目选择最高分模型,而应深入挖掘最适合您任务的方案。
核心原则:没有万能的模型。MTEB 的存在正是为了帮我们找到某一场景的最优解。浏览排行榜时请思考以下问题:
- 目标语言是否被支持?
- 是否涉及金融/法律等专业术语?
- 模型体积是否适配您的硬件(如笔记本电脑)?
- 硬件内存能否承载模型?
- 输入长度限制是否匹配文本特征?
明确核心需求后,即可在 MTEB 排行榜中按特征筛选模型,从而找出既性能优异又符合实际条件的模型。
10 总结建议
为 RAG 应用选择合适的嵌入模型时,不应仅以基准测试分数为唯一标准。MTEB等工具固然能提供参考,但无法展现全貌。关键在于要超越数字评分的表象,综合考虑语言支持度、专业词汇处理能力、内存限制及文本长度等实际需求。
建议深入分析自身应用场景,基于最相关的任务来对比模型表现。需注意,适用于他人使用场景的模型未必符合您的特定需求。
归根结底,通过深思熟虑平衡模型性能与实际需求,才能找到最合适的模型。通过充分调研与审慎评估,您终将找到最契合的模型,为 RAG 应用的成功奠定坚实基础。
END
本期互动内容 🍻
❓在您过去的 RAG 项目实践中,在"嵌入模型选择"这一步,踩过最大的坑是什么?
文中链接
[2]https://huggingface.co/spaces/mteb/leaderboard
[3]https://arxiv.org/abs/2502.13595
本文经原作者授权,由 Baihai IDP 编译。如需转载译文,请联系获取授权。
原文链接:
关注公众号
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
使用数据库工具进行高效数据查询的 10 大 IntelliJ IDEA 快捷方式
使用数据库工具进行高效数据查询的 10 大 IntelliJ IDEA 快捷方式 引言 在现代软件开发中,数据库操作是不可或缺的一部分。作为Java开发者,我们经常需要与各种数据库进行交互,编写和执行SQL查询。IntelliJ IDEA Ultimate版本内置了强大的Database Tools,它提供了一个专用的SQL查询控制台,允许开发者在不离开IDE的情况下,轻松修改和提取连接到Java应用程序的任何数据库中的数据。 查询控制台配备了SQL语句特定的代码片段库、代码补全、实时错误检测和各种实用快捷方式,所有这些功能都旨在帮助开发者保持高效的工作流程。本文将重点介绍10个最实用的快捷方式,它们能够显著提升您在IntelliJ IDEA中使用数据库工具进行数据查询时的效率。 正文内容 1. 打开新控制台:⌘⇧L | Ctrl+Shift+Q 当您需要在数据库工具窗口打开一个新的查询控制台时,只需选择一个数据源,然后按下这三个键:⌘⇧L(macOS)或Ctrl+Shift+Q(Windows/Linux)。这个快捷方式可以快速创建一个新的查询环境,让您立即开始编写SQL语句。 需要...
-
下一篇
真实迁移案例:从 Azkaban 到 DolphinScheduler 的选型与实践
一、为什么我们放弃了Azkaban? 我们最早选择用 LinkedIn 开源的 Azkaban 做调度,主要是看中它两个特点:一是界面清爽,操作简单;二是它用“项目”来管理任务,非常直观。那时候团队刚开始搭建数据平台,这种轻量又清晰的工具,正好符合我们的需要。其他还有其他原因: 社区活跃(当时) 部署简单,依赖少(仅需 MySQL + Web Server + Executor) 支持 job 文件定义依赖,适合 DAG 场景 但随着业务规模扩大,Azkaban 的短板逐渐暴露: 缺乏任务失败自动重试机制 Azkaban 的重试策略极其原始:要么手动点击重跑,要么通过外部脚本轮询状态后触发。我们曾因一个 Hive 任务因临时资源不足失败,导致下游 20+ 个任务全部阻塞,运维不得不半夜手动干预。 权限粒度粗糙 Azkaban 的权限模型只有“项目级别”的读写权限,无法做到“用户A只能编辑任务X,不能动任务Y”。在多团队共用一个调度平台时,权限混乱导致误操作频发。 缺乏任务版本管理 每次修改 job 文件都会覆盖历史版本,无法回滚。我们曾因一次错误的参数修改,导致整个 ETL 流水线跑出...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Crontab安装和使用
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Red5直播服务器,属于Java语言的直播服务器
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- MySQL数据库中FOR UPDATE的使用
- CentOS6,CentOS7官方镜像安装Oracle11G







微信收款码
支付宝收款码