


今天我们发布了 jina-embeddings-v4,这是我们新的 38 亿参数通用向量模型 (Embedding),适用于文本和图像。它包括一组特定于任务的 LoRA 适配器,可优化最受欢迎的检索任务的性能,包括查询文档检索、语义匹配和代码搜索。jina-embeddings-v4 在 MTEB、MMTEB、CoIR、LongEmbed、STS、Jina-VDR、CLIP 和 ViDoRe 基准测试中,在多模态和多语言任务上实现了最先进的检索性能,尤其是在处理视觉上丰富的内容(如图表、图表和它们的混合)方面。该模型支持单向量和多向量向量模型 (Embeddings)。

jina-embeddings-v4 是我们迄今为止最雄心勃勃的向量模型 (Embedding) 。作为一款开源模型,jina-embeddings-v4 的性能优于主要供应商的领先的闭源向量模型 (Embedding),在多语言检索方面比 OpenAI 的 text-embedding-3-large
提高了 12%(66.49 对 59.27),在长文档任务方面提高了 28%(67.11 对 52.42),比 voyage-3
在代码检索方面提高了 15%(71.59 对 67.23),并且与 Google 的 gemini-embedding-001
性能相匹配。这使得 v4 成为当今可用的功能最强大的开源通用向量模型 (Embedding),通过 我们全面的技术报告,为研究人员和开发人员提供了企业级多模态向量模型 (Embedding) 功能,并可完全透明地了解训练过程、架构决策和模型权重。

tag全新架构
Qwen2.5-VL-3B-Instruct
骨干网络(38 亿个参数)之上。文本和图像输入通过共享路径处理:图像首先通过视觉编码器转换为词元 (Token) 序列,然后两种模态都由具有上下文注意力层的语言模型解码器联合处理。三个特定于任务的 LoRA 适配器(每个 6000 万个参数)为检索、文本匹配和代码任务提供专门的优化,而无需修改冻结的骨干权重。该架构支持双重输出模式:(1) 通过平均池化生成的单向量向量模型 (Embedding) (2048 维度,可截断为 128),用于高效的相似性搜索,以及 (2) 通过投影层生成的多向量向量模型 (Embedding) (每个词元 (Token) 128 维度),用于后期交互检索策略。从 jina-embeddings-v3 升级到jina-embeddings-v4 代表了从纯文本到多模态向量模型 (Embeddings)的范式转变。 v3 专注于使用特定于任务的 LoRA 适配器优化文本向量模型 (Embeddings),而 v4 则解决了对统一表示中嵌入文本和视觉内容日益增长的需求。
方面 | <strong>jina-embeddings-v3</strong> | <strong>jina-embeddings-v4</strong> |
---|---|---|
Backbone 模型 | jina-XLM-RoBERTa | Qwen2.5-VL-3B-Instruct |
参数(基础) | 559M | 3.8B |
参数(带适配器) | 572M | 3.8B + 每个适配器 60M |
模态 | 仅文本 | 文本 + 图像(多模态) |
最大输入长度 | 8,192 个词元 (Tokens) | 32,768 个词元 (Tokens) |
图像处理 | 无 | 高达 20 兆像素,视觉上丰富的文档 |
多语言支持 | 89 种语言 | 29+ 种语言 |
向量类型 | 仅单向量 | 单向量 + 多向量(后期交互) |
单向量维度 | 1024(MRL 可截断为 32) | 2048(MRL 可截断为 128) |
多向量维度 | 不可用 | 每个词元 (Token) 128 |
任务 LoRA 专业化 | • 非对称检索 • 语义相似性 • 分类 • 分离 |
• 非对称检索 • 语义相似性 • 代码检索 |
训练阶段 | 3 阶段:预训练 → 向量模型 (Embedding) 微调 → 适配器训练 | 2 阶段:联合对训练 → 特定于任务的适配器训练 |
损失函数 | InfoNCE、CoSent、扩展的三元组损失 | 单/多向量的联合 InfoNCE + KL 散度 |
位置编码 | RoPE(旋转基频调整) | M-RoPE(多模态旋转位置嵌入) |
跨模态处理 | 不适用 | 统一编码器(减少模态差距) |
MRL 支持 | 是 | 是 |
注意力实现 | FlashAttention2 | FlashAttention2 |
tagBackbone
v4 中最显著的架构变化是从 XLM-RoBERTa
到 Qwen2.5-VL-3B-Instruct
的backbone 变化。 这一决定是由 v4 的核心目标驱动的,即创建一个通用的向量模型 (Embedding)模型,该模型能够实现“真正的多模态处理”,其中图像被转换为词元 (Token)序列并与文本一起处理,从而消除了双编码器架构中存在的模态差距。
Backbone 的选择符合几个关键的设计目标:Qwen2.5-VL 在文档理解方面的卓越表现直接支持了 v4 在处理视觉上丰富的内容(如表格、图表和屏幕截图)方面的优势。 动态分辨率功能使 v4 能够处理调整为架构中指定的 20 兆像素的图像。 先进的位置编码为 v4 实现卓越的跨模态对齐奠定了基础,其对齐分数为 0.71,而 OpenAI CLIP 的对齐分数为 0.15。
tagLoRA 适配器
V4 从 v3 的五个任务简化为三个重点任务,反映了从有效性和用户采用方面获得的经验教训:
- 非对称检索(整合了 v3 的查询/段落适配器)
- 对称相似性(v3 的文本匹配等效于 STS 任务)
- 代码检索(从 v2-code 中学习,v3 中缺失)
这种整合消除了 v3 的分类和分离适配器,使 v4 专注于最具影响力的向量模型 (Embedding)用例 - 检索和 STS。
tag输出向量模型 (Embeddings)
V4 引入了支持单向量和多向量向量模型 (Embeddings)的双输出系统,而 v3 仅提供单向量输出。 这解决了不同的检索场景:
- 单向量模式:2048 维向量模型 (Embeddings)(可通过 MRL 截断为 128)用于高效的相似性搜索
- 多向量模式:每个词元 (Token) 128 维,用于后期交互检索
这种双重方法通过多向量表示提供了更高的效率,尤其是在视觉上丰富的文档检索中,同时保持了标准相似性任务的效率。 在视觉任务中,多向量相对于单向量模式始终如一的 7-10% 的性能优势表明,对于多模态内容,后期交互提供了从根本上更好的语义匹配。
tag参数大小
虽然 v4 比 v3 大 6.7 倍(3.8B 对 570M 参数),但纯文本性能的改进实际上是适度的,这表明参数缩放主要是由多模态需求驱动的,而不是文本增强。 在核心文本基准测试中,v4 在 MMTEB 上达到 66.49,而 v3 为 58.58(改进 14%),在 MTEB-EN 上为 55.97,而 v3 为 54.33(改进 3%)。 对于代码检索,v4 在 CoIR 上得分为 71.59,而 v3 为 55.07(改进 30%),而长文档性能显示 v4 在 LongEmbed 上为 67.11,而 v3 为 55.66(改进 21%)。 当考虑 v4 的多模态功能时,这种大幅扩展是合理的:在视觉文档检索 (Jina-VDR) 上实现 84.11 nDCG@5,在 ViDoRe 基准测试上实现 90.17 - v3 中完全没有的功能。 因此,参数增加代表了我们对多模态功能的投资,同时保持了具有竞争力的文本性能,统一的架构消除了对单独的文本和视觉模型的需求,同时实现了 0.71 的跨模态对齐,而传统双编码器方法的跨模态对齐为 0.15。
tag开始使用
要快速进行氛围检查,请在 Search Foundation 工具箱中尝试我们的文本到图像演示。 我们准备了我们网站上的一系列文档图像,您还可以添加自己的图像 URL。 只需键入您的查询并按 Enter 键即可查看排名结果。 您可以像 OCR 或基于内容的图像检索一样撤退它 - 也可以尝试使用非英语的查询。
该演示可在以下网址找到:https://jina.ai/api-dashboard/m0-image-rerank请注意,使用此演示将消耗您的主 API 密钥的词元 (Tokens)。 此外,由于它需要从这些 URL 下载服务器上的所有图像,并且没有为图像实现缓存,因此演示可能看起来有点慢。
tag通过 API
下面的代码显示了如何使用 jina-embeddings-v4。 您可以传递文本字符串、base64 编码的图像或图像 URL。 新用户可以获得一个 Jina API 密钥,其中包含 1000 万个免费词元 (Tokens)。
curl https://api.jina.ai/v1/embeddings \
-H "Content-Type: application/json" \
-H "Authorization: Bearer JINA_API_KEY" \
-d @- <<EOFEOF
{
"model": "jina-embeddings-v4",
"task": "text-matching",
"input": [
{
"text": "A beautiful sunset over the beach"
},
{
"text": "Un beau coucher de soleil sur la plage"
},
{
"text": "海滩上美丽的日落"
},
{
"text": "浜辺に沈む美しい夕日"
},
{
"image": "https://i.ibb.co/nQNGqL0/beach1.jpg"
},
{
"image": "https://i.ibb.co/r5w8hG8/beach2.jpg"
},
{
"image": "iVBORw0KGgoAAAANSUhEUgAAABwAAAA4CAIAAABhUg/jAAAAMklEQVR4nO3MQREAMAgAoLkoFreTiSzhy4MARGe9bX99lEqlUqlUKpVKpVKpVCqVHksHaBwCA2cPf0cAAAAASUVORK5CYII="
}
]
}
EOFEOF
由于 GPU 资源有限,尽管 jina-embeddings-v4 原生支持处理高达 32K 个词元 (Tokens),但我们的向量模型 (Embeddings) API 目前仅支持长度不超过 8K 个词元 (Tokens) 的文档。对于需要超过 8K 个词元 (Tokens) 的更长上下文的应用(例如 Late Chunking),我们建议通过 CSP 部署我们的模型或自行托管模型。
tag通过 CSP 市场
jina-embeddings-v4 将很快在 AWS、Azure 和 GCP 上直接提供,价格以这些平台上的标价为准。
tag通过 HuggingFace
出于研究和实验目的,您可以从我们的 Hugging Face 页面在本地使用该模型。我们准备了一个 Google Colab notebook,演示了它的工作原理。

tag结论
jina-embeddings-v4 代表了我们迄今为止最显著的飞跃——一个 38 亿参数的通用向量模型 (Embedding),它通过统一的路径处理文本和图像,支持密集和后期交互检索,同时在视觉丰富的文档检索方面优于 Google、OpenAI 和 Voyage AI 的专有模型。但这种能力并非凭空出现;它是解决根本局限性的四代产品的结晶。
早在 2022 年初,当我们开始使用 jina-embeddings-v1
时,每个人都认为更多的数据意味着更好的性能。我们证明了恰恰相反——将 15 亿个配对过滤到 3.85 亿个高质量的示例,其性能优于更大的数据集。教训是:整理胜于收集。

但用户一直受 BERT 的 512 个词元 (Tokens) 限制。在更长的序列上进行训练似乎成本很高,直到 jina-embeddings-v2
揭示了一个优雅的解决方案:训练短序列,部署长序列。ALiBi 的线性注意力偏差使在 512 个词元 (Tokens) 上训练的模型能够在推理时无缝处理 8,192 个词元 (Tokens)。我们以更少的计算获得了更多的能力。

jina-embeddings-v2
的成功暴露了另一个限制——不同的任务需要不同的优化。jina-embeddings-v3 没有构建单独的模型,而是使用微小的 60M LoRA 适配器来为任何任务定制 570M 的基础模型。一个模型变成了五个专用模型。

即使进行了任务专业化,我们仍然只关注文本,而用户需要视觉理解。像 jina-clip-v1 和 jina-clip-v2 这样的标准 CLIP 模型使用单独的编码器,从而产生“模态差距”,即不同格式的相似内容最终相距甚远。与我们最近发布的 jina-reranker-m0 一样,jina-embeddings-v4 完全消除了这一点——一个统一的路径处理所有内容,消除差距而不是弥合差距。

jina-embeddings-v4 和 jina-reranker-m0 都具有一个根本性的转变:使用大模型 (LLM) 作为骨干,而不是仅使用编码器的模型。这并非巧合——它反映了一个大多数人错过的深刻优势:仅使用编码器的模型会产生“模态差距”,即图像与文本分开聚集。仅使用解码器的模型开辟了仅使用编码器的架构无法实现的可能性,包括真正的混合模态表示和可解释性。
我们的核心观点是:向量模型 (embeddings) 和生成都与理解语义有关。擅长生成的大模型 (LLM) 自然也擅长表征。我们认为,未来在于统一的架构,其中向量模型 (embedding) 和重排器 (reranking) 都来自同一个搜索基础模型——而这正是 Jina AI 努力构建的方向。