Embedding 模型介绍：热门模型对比与应用场景

本文是「从零搭建私人 RAG 知识库」专栏的基础篇。搜索"怎么保存登录状态"，也能找到写着"使用 Redis 存储 Session"的文档。它们没有使用相同的关键词，却表达了相近的意思------这正是 Embedding 模型擅长解决的问题。

前言

在语义搜索、RAG 知识库、推荐系统和重复内容检测中，经常会看到一个词：Embedding。

它的核心作用可以概括为一句话：

Embedding 模型把文本、图片等数据转换成向量，让程序可以计算它们之间的相似程度。

市面上的 Embedding 模型很多，有些通过云端 API 调用，有些可以下载到本地运行；有些擅长英文，有些更适合中文或多语言；还有一些专门针对代码、金融和法律资料优化。

本文主要回答四个问题：

Embedding 模型到底是什么；
市面上有哪些具有代表性的热门模型；
不同模型应该怎样比较和选择；
Embedding 可以应用在哪些场景。

本文先建立整体认识，具体的 Ollama 和 LangChain.js 调用方式会放在下一篇介绍。

一、Embedding 模型是什么？

Embedding 通常翻译为"嵌入"或"向量表示"。

它会把一段文本转换成固定长度的数字数组：

text 复制代码

"如何重置密码？"
        ↓ Embedding 模型
[0.12, -0.35, 0.81, ..., 0.27]

这个数字数组就是文本的向量。

向量中的单个数字通常没有适合人类直接阅读的独立含义。我们真正关心的是不同向量之间的整体关系：

语义越相近，向量通常越接近；
语义差异越大，向量通常越远。

例如：

text 复制代码

文本 A：如何修改登录密码？
文本 B：忘记密码后怎样重置？
文本 C：今天天气怎么样？

文本 A 和文本 B 的用词不同，但含义接近，因此它们的向量通常也更接近。文本 C 与前两句主题不同，向量距离通常更远。

需要注意：

Embedding 模型负责生成向量，不负责保存向量，也不负责生成自然语言回答。

向量通常由向量数据库保存和检索；最终回答则由大语言模型生成。

二、为什么需要不同的 Embedding 模型？

Embedding 模型看起来都在做"文本转向量"，但它们的训练数据、模型结构和优化目标并不相同。

这些差异会直接影响实际效果。

1. 支持的语言不同

有些模型主要针对英文训练，有些模型强调中文或多语言能力。

如果知识库主要是中文文档，却选择了中文表现较弱的模型，即使代码和向量数据库都没有问题，检索效果也可能不理想。

2. 擅长的任务不同

常见的优化方向包括：

通用文本检索；
多语言检索；
代码搜索；
金融、法律等垂直领域检索；
短文本相似度；
长文档检索；
图片和文本的跨模态检索。

模型在某个排行榜上表现很好，不代表它一定适合所有业务。

3. 输入长度不同

不同模型能够处理的最大 Token 数不同。

输入长度更长，意味着模型可以一次接收更多内容，但这不代表应该直接把整篇长文档生成一个向量。长文档包含多个主题时，仍然通常需要先分块。

4. 向量维度不同

常见向量维度有 384、768、1024、1536 和 3072 等。

维度越高通常意味着：

单条向量占用更多存储空间；
网络传输量更大；
相似度计算成本更高。

但维度高不等于检索效果一定更好。模型训练质量和业务数据是否匹配通常更重要。

5. 部署方式不同

模型大致可以分为两类：

类型	优点	注意事项
云端 API	接入简单，无需维护推理服务	按量计费，依赖网络，需要关注数据隐私
本地或自托管模型	数据可留在本地，可离线运行	需要计算资源、部署和模型维护

三、具有代表性的热门 Embedding 模型

下面选择一些常见的云端和开源模型作为入门参考。

模型版本、价格和 API 限制可能随时间变化，正式选型前应再次查看官方文档。这里的"热门"表示社区或商业应用中较常见，并不代表固定排名。

1. OpenAI `text-embedding-3-small` / `text-embedding-3-large`

OpenAI 提供的通用文本向量模型，通过 API 调用。

模型	默认维度	主要特点
`text-embedding-3-small`	1536	成本和效果较均衡，适合一般语义搜索与 RAG
`text-embedding-3-large`	3072	更强调检索质量，存储和调用成本也更高

text-embedding-3 系列支持通过参数缩短输出向量维度，便于在效果、存储和检索成本之间取舍。

适合：

希望快速接入云端 API；
不想维护本地推理服务；
通用语义搜索和 RAG；
已经在使用 OpenAI API 的应用。

需要考虑：

数据需要发送到外部服务；
调用成本会随数据量增加；
网络和服务可用性会影响系统。

2. Cohere Embed 多语言系列

Cohere Embed 系列强调搜索、分类和多语言语义理解，并区分查询与文档的输入类型。

具有代表性的模型包括：

embed-multilingual-v3.0：面向多语言检索；
embed-multilingual-light-v3.0：使用更低维度，在成本和速度上更轻量。

适合：

中文、英文等多语言资料混合检索；
跨语言搜索，例如用中文问题搜索英文资料；
希望直接使用成熟云端服务；
搜索、分类和聚类任务。

Cohere 的调用接口通常要求明确区分 search_query 和 search_document 等输入类型。正确设置输入类型会影响检索效果。

3. Voyage AI Embedding 系列

Voyage AI 提供通用、多语言以及领域优化的 Embedding 模型，一些模型专门面向代码、金融和法律文本。

适合：

代码语义搜索；
金融或法律等专业资料检索；
长上下文文档；
希望根据具体领域选择云端模型。

与通用模型相比，领域模型的优势通常来自更贴近目标数据的训练方式。但是否真的更好，仍然需要使用自己的问题和文档进行评估。

4. BGE-M3

BAAI/bge-m3 是开源多语言 Embedding 模型，常用于本地或自托管检索系统。

它的主要特点包括：

支持多语言；
向量维度为 1024；
支持最长 8192 Token 的输入；
支持稠密检索、稀疏检索和多向量检索等方式；
可以在本地部署。

适合：

中文或中英混合知识库；
不能把数据发送到第三方 API 的场景；
希望尝试混合检索；
有能力维护本地模型服务的团队。

BGE-M3 的功能比较丰富，但完整使用稀疏和多向量能力时，接入复杂度也会高于只生成单个稠密向量的基础模型。

5. `jina-embeddings-v3`

jina-embeddings-v3 是一个面向多语言和多任务检索的开源模型。

主要特点包括：

默认输出 1024 维向量；
支持最长 8192 Token 的输入；
支持多语言；
可以根据检索、相似度、分类等任务选择不同适配方式；
支持缩短向量维度，降低存储成本。

适合：

多语言语义搜索；
需要本地部署；
希望根据任务选择不同编码方式；
需要在向量效果和存储成本之间做取舍。

使用这类支持任务参数的模型时，索引文档和查询文本需要按照模型文档选择正确的任务配置。

6. `nomic-embed-text`

nomic-embed-text 是一个常见的开源文本向量模型，也可以通过 Ollama 很方便地在本地运行。

以 nomic-embed-text-v1.5 为例：

输出维度为 768；
支持较长文本输入；
可以在本地运行；
与 Ollama、LangChain 等工具集成方便。

适合：

初学者完成第一个本地 Embedding 示例；
本地 RAG 和语义搜索实验；
数据不方便发送到云端；
对部署简单程度要求较高的个人项目。

它并不一定在所有语言和领域中都是最佳选择，但很适合用于理解"文本 → 向量 → 相似度搜索"这条基础链路。

四、热门模型横向对比

下面的表格用于建立整体认识，不应替代真实业务评测。

模型	调用方式	默认维度	多语言	主要特点	更适合
`text-embedding-3-small`	OpenAI API	1536	支持	接入简单，成本与效果较均衡	通用 RAG、语义搜索
`text-embedding-3-large`	OpenAI API	3072	支持	更强调检索质量，可缩短维度	对效果要求较高的云端应用
Cohere Embed Multilingual	Cohere API	依模型而定	强	查询与文档类型明确，跨语言能力突出	多语言和跨语言检索
Voyage Embedding	Voyage API	依模型而定	依模型而定	提供代码、金融、法律等领域模型	垂直领域和代码检索
`BAAI/bge-m3`	本地或自托管	1024	强	稠密、稀疏和多向量能力	中文、多语言、混合检索
`jina-embeddings-v3`	本地或 API	1024	强	多任务适配，可缩短向量	多语言和多任务检索
`nomic-embed-text-v1.5`	本地、Ollama 或 API	768	以模型说明为准	本地运行方便，上手简单	学习、本地 RAG 实验

不能只根据这个表格直接得出"哪个模型最好"。真正的答案取决于：

文档使用什么语言；
用户会怎样提问；
文档属于什么领域；
是否允许使用云端 API；
可以接受多少延迟和成本；
向量数据库可以承受多少存储量。

五、Embedding 的常见应用场景

1. 语义搜索

传统关键词搜索依赖相同词语，语义搜索则关注意思是否接近。

text 复制代码

用户搜索：怎么保存登录状态？
文档内容：使用 Redis 存储 Session

即使两段文本没有大量重复关键词，Embedding 仍可能判断它们高度相关。

适合：

帮助中心；
企业文档搜索；
商品搜索；
FAQ 匹配；
代码搜索。

2. RAG 知识库

RAG 会先使用 Embedding 找到与问题相关的文档片段，再把这些片段交给大语言模型生成答案。

text 复制代码

用户问题
   ↓ Embedding
查询向量
   ↓ 向量数据库
相关文档片段
   ↓ 大语言模型
最终回答

Embedding 决定了系统能否找到正确资料，是 RAG 检索阶段的重要组成部分。

3. 相似问题匹配

可以把用户新问题与历史问题进行比较：

text 复制代码

"忘记密码怎么办？"
"无法登录，如何重置密码？"

如果相似度较高，可以直接推荐已有答案，减少重复处理。

4. 文本聚类

把大量文本转换成向量后，可以根据距离自动分组。

例如：

将用户反馈分为性能、价格和功能问题；
将新闻按主题聚类；
将知识库文档按内容自动归类；
发现暂时没有标签的新主题。

5. 推荐系统

可以分别计算用户兴趣和内容的向量，再推荐距离较近的内容。

例如：

相似文章推荐；
相似商品推荐；
职位与简历匹配；
课程推荐。

实际推荐系统通常还会结合点击率、时间、热度和业务规则，而不是只依赖向量相似度。

6. 重复内容检测

文本表达方式不同，但内容可能高度重复。

Embedding 可以用于发现：

重复工单；
重复新闻；
相似需求；
相似知识库文档；
内容搬运或改写。

7. 分类与异常发现

将文本向量作为特征，可以用于分类或发现偏离常见分布的数据。

例如：

邮件分类；
用户意图识别；
评论主题判断；
异常反馈发现。

六、应该如何选择 Embedding 模型？

第一步：明确数据和查询语言

先确认：

文档主要是中文、英文还是多语言；
用户问题与文档是否使用同一种语言；
文档中是否包含大量代码、表格或专业术语。

中文或跨语言场景应优先测试多语言模型，而不是只看英文排行榜。

第二步：明确部署边界

如果数据不能离开本地，可以优先考虑 BGE-M3、Jina 或 Nomic 等可本地部署的模型。

如果更关注接入速度，不希望维护推理服务，可以考虑 OpenAI、Cohere 或 Voyage 等云端 API。

第三步：评估成本和性能

需要综合考虑：

API 调用成本；
本地 CPU、GPU 和内存成本；
向量维度带来的存储成本；
单条请求延迟；
批量索引速度；
并发能力。

本地模型并不等于"没有成本"，只是成本从 API 费用转移到了计算资源和运维上。

第四步：建立自己的测试集

最可靠的选型方式不是只看排行榜，而是准备真实测试数据。

例如准备 50～200 组：

text 复制代码

用户问题 → 应该召回的正确文档

然后分别使用候选模型建立索引，比较：

正确文档是否出现在 Top-K 中；
正确结果是否排在前面；
中文、英文和专业术语表现；
索引速度与查询延迟；
存储量和调用成本。

常见检索评估指标包括 Recall@K、MRR 和 NDCG。初学阶段也可以先人工检查 Top-3 或 Top-5 的结果。

第五步：从最简单的方案开始

如果只是学习，可以先选择容易运行的模型完成完整流程：

text 复制代码

文本 → Embedding → 向量 → 相似度比较

如果准备上线，再根据真实数据进行模型对比。不要在还没有测试集时，仅凭参数和排行榜反复更换模型。

七、模型选型中的常见误区

1. 参数越大，效果一定越好

不一定。Embedding 效果与训练数据、训练目标、语言和业务领域都有关系。

2. 向量维度越高，效果一定越好

不一定。更高维度会增加存储和计算成本，但不保证业务检索效果同步提升。

3. 排行榜第一就是业务最佳模型

排行榜只能作为参考。公开测试集与实际文档、查询习惯和语言分布可能完全不同。

4. 支持长文本，就不需要分块

不正确。即使模型可以接收很长的文本，把多个主题压缩成一个向量仍可能导致具体信息被稀释。

5. 更换模型后可以继续使用旧向量

不可以直接这样做。

不同模型的向量维度和语义空间通常不同。即使维度相同，也不代表它们可以直接比较。

更换 Embedding 模型后，通常需要重新生成所有文档向量。

八、一个简单的选型建议

如果暂时不知道怎样选择，可以从下面的方向开始：

需求	可以优先测试
第一次学习本地 Embedding	`nomic-embed-text` + Ollama
中文或中英混合知识库	BGE-M3、Jina 多语言模型、Cohere Multilingual
快速接入云端通用检索	OpenAI `text-embedding-3-small`
更关注云端检索效果	OpenAI `text-embedding-3-large`、Voyage 通用模型
跨语言搜索	Cohere Multilingual、BGE-M3、Jina 多语言模型
代码搜索	Voyage 代码模型，或经过代码数据验证的开源模型
数据必须保留在本地	BGE-M3、Jina、Nomic 等可自托管模型

这不是固定答案，只是一组候选起点。最终仍应以自己的测试结果为准。

Embedding 模型介绍：热门模型对比与应用场景

前言

一、Embedding 模型是什么？

二、为什么需要不同的 Embedding 模型？

1. 支持的语言不同

2. 擅长的任务不同

3. 输入长度不同

4. 向量维度不同

5. 部署方式不同

三、具有代表性的热门 Embedding 模型

1. OpenAI text-embedding-3-small / text-embedding-3-large

2. Cohere Embed 多语言系列

3. Voyage AI Embedding 系列

4. BGE-M3

5. jina-embeddings-v3

6. nomic-embed-text

四、热门模型横向对比

五、Embedding 的常见应用场景

1. 语义搜索

2. RAG 知识库

3. 相似问题匹配

4. 文本聚类

5. 推荐系统

6. 重复内容检测

7. 分类与异常发现

六、应该如何选择 Embedding 模型？

第一步：明确数据和查询语言

第二步：明确部署边界

第三步：评估成本和性能

第四步：建立自己的测试集

第五步：从最简单的方案开始

七、模型选型中的常见误区

1. 参数越大，效果一定越好

2. 向量维度越高，效果一定越好

3. 排行榜第一就是业务最佳模型

4. 支持长文本，就不需要分块

5. 更换模型后可以继续使用旧向量

八、一个简单的选型建议

1. OpenAI `text-embedding-3-small` / `text-embedding-3-large`

5. `jina-embeddings-v3`

6. `nomic-embed-text`