做RAG系统或者语义搜索的时候，嵌入模型的选择往往决定了整个系统的上限。Ollama平台上现在有十多款嵌入模型可供选择，功能定位各异，性能差距也不小。这篇文章把平台上所有的嵌入模型都梳理一遍，希望能帮你找到最合适的那一款。

先说结论

如果你赶时间，可以直接看这个快速选型表：

下面进入详细分析。

模型概览：参数、体积、上下文

先看一张总表，把所有模型的关键参数列出来：

从这个表里能看出几个关键信息：

一是模型体积差异巨大，最小的all-minilm只有46MB，最大的qwen3-embedding(8B)接近5GB。如果你的部署环境资源有限，这一点要特别注意。

二是上下文长度差别也很大，从512到40K不等。处理短文本比如问答匹配，512够用了；但如果要处理长文档或者代码文件，就要考虑bge-m3或者qwen3-embedding这类支持长上下文的模型。

三是语言支持，有些模型主打英语(比如snowflake-arctic-embed的部分版本)，有些则覆盖100多种语言。做国际化产品的话，语言支持范围要仔细看。

逐个模型分析

nomic-embed-text

这是Nomic AI开源的一款模型，特点是比较均衡。274MB的体积不算大，但支持2K的上下文长度，这在同等规模的模型里算是比较长的。

实际使用下来，这款模型在处理中等长度文档时表现不错，比如技术文档、博客文章这类内容。它完全开源，训练代码和数据都能拿到，如果你需要深入理解或者改进模型，这点很有价值。

nomic-embed-text-v2-moe

这是Nomic的新版本，用了混合专家架构(MoE)。总参数量475M，但推理时只激活305M，效率更高。

这款模型主打多语言检索，官方说支持100种语言。还有个实用功能：支持Matryoshka嵌入技术，可以把768维的向量压缩到256维，存储空间能省不少。

不过上下文长度只有512，这是一个限制。如果你的文档普遍较长，需要先分段处理。

mxbai-embed-large

mixedbread.ai出品，2024年3月的时候在MTEB基准测试上表现很抢眼，达到了Bert-large级别的最佳效果，甚至超过了OpenAI的text-embedding-3-large。

这款模型的特点是泛化能力强，训练数据和MTEB测试集没有重叠，但在测试集上表现依然很好。这意味着它在实际业务场景中大概率也能保持不错的表现。

bge-m3

北京智源研究院的模型，在国内开发者圈子里用得很多。它的卖点有三个：多功能、多语言、多粒度。

多功能指的是它同时支持三种检索方式：稠密检索、多向量检索、稀疏检索。多语言是支持100多种语言。多粒度是说它可以处理不同长度的文本，从短句到8K的长文档都行。

如果你的系统需要混合检索策略，或者要处理超长文档，bge-m3是个不错的选择。唯一的问题是模型体积有1.2GB，部署成本要考虑。

bge-large

BGE系列的经典款，在中文检索任务上效果很好。相比bge-m3，它更轻量一些，671MB的体积更容易部署。

如果你的场景以中文为主，不需要超长上下文，这款模型的性价比很高。社区资源也丰富，遇到问题容易找到解决方案。

all-minilm

这是所有模型里最小的，22M参数版本只有46MB。别看体积小，在标准基准测试上表现并不差。

它的优势在于速度和资源占用。在普通CPU上都能流畅运行，延迟非常低。如果你的场景对响应速度要求高，或者要部署在边缘设备上，all-minilm值得考虑。

当然，小模型的局限性也要认识：在复杂语义理解任务上，效果比大模型差一些。

snowflake-arctic-embed系列

Snowflake出品，定位是企业级检索。这个系列提供了从22M到335M的多个版本，可以根据你的性能需求和资源预算来选择。

从设计理念看，Snowflake强调高吞吐量和生产环境稳定性。如果你的检索系统要处理大量并发请求，这个系列值得看看。

snowflake-arctic-embed2

第二代的改进主要在两方面：一是增加了多语言支持，二是上下文长度提升到8K。

它还支持Matryoshka表示学习，可以把向量压缩得很小，官方说能压缩到128字节。如果你的向量数据库存储成本高，这个功能能帮你省不少钱。

qwen3-embedding

阿里巴巴的通义系列，提供0.6B、4B、8B三个版本。这是目前Ollama平台上参数量最大的嵌入模型。

8B版本在MTEB多语言榜单上排名第一，检索精度是目前最高的。它的上下文长度也很夸张，最大支持40K tokens，处理整个代码文件或者长篇技术文档都不成问题。

还有个亮点：嵌入维度可以自定义，从32到4096都行。你可以根据存储成本和检索精度的平衡来选择。

缺点是模型大，8B版本接近5GB，对部署环境有要求。如果你的机器资源充足，而且追求最高检索质量，选它准没错。

embeddinggemma

Google基于Gemma架构做的嵌入模型，300M参数，622MB体积。Google的技术背书加上Apache 2.0开源协议，对合规要求高的企业比较友好。

从性能看，它在同类规模的模型里算是不错的。支持100多种语言，上下文长度2K，各方面都比较均衡。

granite-embedding

IBM的模型，有两个版本：30M的英文版和278M的多语言版。Apache 2.0协议，商业使用没有顾虑。

这款模型的特点是企业定位清晰。IBM提供了完整的技术支持路线，对于金融、医疗这类合规要求高的行业，选择有明确企业支持的模型会更安心。

paraphrase-multilingual

Sentence-Transformers的多语言版本，算是这个领域的经典模型了。虽然是老牌模型，但在语义相似度计算上效果依然稳定。

它的优势在于社区成熟，文档和教程都很丰富。如果你刚接触嵌入模型，用它来入门学习比较合适。

根据场景选模型

光看参数不够，实际选型还要结合具体场景。这里整理了几个典型场景的建议。

做中文知识库

BGE系列是首选，bge-large性价比高，bge-m3功能全面。国内很多企业的知识库系统都是用BGE，实践检验过，坑都踩完了。

做国际化产品

qwen3-embedding或者bge-m3。两者都支持100多种语言，检索效果也都顶尖。qwen3-embedding的优势是上下文更长，bge-m3的优势是模型更小一些。

部署在边缘设备

all-minilm是唯一的选择。46MB的体积，CPU就能跑，延迟极低。当然效果会比大模型差一些，但边缘场景往往是效率和效果之间的权衡。

处理长文档

看文档有多长。几K的文档，bge-m3和snowflake-arctic-embed2都够用；如果是几万字的技术文档或者代码文件，得上qwen3-embedding，它的40K上下文才能覆盖。

追求检索精度

qwen3-embedding(8B)是目前最强的选择，MTEB榜单第一。前提是你的机器能跑起来。

快速验证想法

nomic-embed-text体积适中，效果不错，上手快。用它做个原型，验证可行后再考虑换更专业的模型。

安装和使用

安装很简单，一行命令：

ollama pull nomic-embed-text
ollama pull qwen3-embedding:8b

Python调用也几行代码：

import ollama

response = ollama.embed(
    model='nomic-embed-text',
    input='你的文本内容'
)
print(response.embeddings)

最后的建议

选嵌入模型没有标准答案，关键看你的具体需求。总结几个要点：

性能和资源要平衡。不是模型越大越好，要考虑部署成本和响应速度。all-minilm虽然小，在很多场景下已经够用了。

语言支持要看清。中文为主的场景选BGE，多语言选Qwen或者BGE-M3，纯英文的场景选择更多。

上下文长度很重要。处理长文档的话，512的上下文肯定不够，至少要2K以上。

最好用自己的数据测试。不同模型在不同数据上的表现可能有差异，建议在正式部署前用你的业务数据做个对比测试。

最后，模型选择只是第一步，后续的调优同样重要。嵌入向量质量只是检索系统的一部分，向量数据库的选择、检索策略的设计、Reranker的使用，都会影响最终效果。这些内容有机会再展开讲。

预览时标签不可点

Close

更多

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

¥

最低赞赏 ¥0

OK

Back

Other Amount

更多

赞赏金额

¥

最低赞赏 ¥0

1

2

3

4

5

6

7

8

9

0

.

大语言模型 · 目录

大语言模型

上一篇MoXing 和 Ollama 对比：从omnicoder-9b到更多模型下一篇超强的本地大模型 OmniCoder-9B 简测：MoXing vs Ollama 对比

Close

更多

搜索「」网络结果

Close

调整当前正文文字大小

更多

100%