训练量仅占 0.35%，竞争力却达到 100%：jina-embeddings-v5-omni 背后的冻结塔架构

作者：来自 Elastic Jon Avezbaki

最新的 jina embeddings 模型可以为文本、图像、视频和音频生成 多模态 嵌入，在向量搜索方面能够与规模接近其 6 倍的模型竞争，而训练的权重仅占 0.35%。

jina-embeddings-v5-omni 是我们最新的多模态嵌入模型。它可以为文本、图像、视频和音频生成嵌入。在支持这些模态的开放权重模型中，它是在 20 亿参数以内性能最好的模型。值得注意的是，我们实际训练的部分非常少。每个编码器塔都保持冻结状态，训练过程中只有大约 0.35% 的模型权重（投影器和少量分隔符 token）被更新过。我们将这种架构模式称为 G eometry-preserving E mbeddings via L ocked A ligned TO wers（GELATO），即通过锁定并对齐的塔实现保持几何结构的嵌入。下面让我们逐一解释这个缩写中的每个字母：

• Geometry-preserving Embeddings：保持几何结构的嵌入。 jina-embeddings-v5-omni 建立在 jina-embeddings-v5-text 奠定的基础之上。原始的文本嵌入空间完全没有改变，其几何结构也被完整保留。

• Locked：锁定。 与 "冻结" 同义。该架构中的所有塔，其权重都处于锁定状态。

• Aligned：对齐。 将其他模态与文本模型的向量空间进行对齐，从而实现跨模态比较。

• TOwers：塔。 将一种类型的原始输入转换为向量的模态组件。

该模型有两个版本：small 和 nano。前者拥有更多参数（15.7 亿），后者拥有 9.5 亿参数，但从功能上看，两者的架构几乎完全相同。为了简洁起见，本文主要聚焦于 jina-embeddings-v5-omni-small。

什么是向量、塔和冻结编码器？

jina-embeddings-v5-omni 依赖于三个核心机器学习（ML）概念：向量、塔和冻结权重。下面分别介绍它们的含义；如果你已经熟悉这些概念，可以直接跳过。

嵌入模型中的向量如何表示数据

AI 如何理解抽象概念？机器能够理解 "冰淇淋（ice cream）" 是什么吗？它是否理解 "巧克力软糖（chocolate fudge）" 和 "洛基路（rocky road）" 彼此之间的共同点比 "雪葩（sorbet）" 更多？令人惊讶的是，答案是肯定的。让这一切成为可能的机制就是向量。

看看这张图。

如果你尝试将所有冰淇淋口味的组织方式可视化，可能会得到类似这样的结果：一个具有三个顶点的单纯形（三角形），每个顶点代表一种基础口味。每种口味距离各个顶点的远近，取决于该口味中相应基础口味所占的比例。巧克力冰淇淋完全由巧克力组成，因此它紧贴顶部的顶点。香草则与左下角的顶点有类似的亲和性。但奥利奥冰淇淋（cookies and cream）大约是 50/50 的混合，因此它与两个顶点的距离大致相等。那不勒斯冰淇淋（Beapolitan）融合了三种口味，因此位于三角形的中心。

这实际上就是向量的工作方式。这些口味会被输入一个 ML 模型（更具体地说，称为_嵌入模型_），然后模型会为这些口味中的每一种在这个单纯形中生成坐标。通过测量坐标之间的距离，软件就可以判断两种口味之间的关联程度。很容易看出，"巧克力（chocolate）" 和 "巧克力布朗尼软糖（chocolate brownie fudge）" 是密切相关的口味，因为它们彼此距离很近；而 "草莓（strawberry）" 和 "奥利奥（cookies and cream）" 相距很远，因此我们可以推断它们并不相似。

不过，实际情况不会这么简单。真实的嵌入不是沿着三个带标签的点运行，而是存在于数百甚至数千个维度中。它们也不会拥有易于人类理解的标签；顶点标记是只有模型才能理解的东西。不过，它的好处是，我们基本上可以用这种方式表示_任何东西_。

为了明确一些术语：这些坐标 = 向量 = 嵌入。在本文的其余部分，我们会交替使用这些术语。

正如嵌入有许多不同的名称一样，创建这些嵌入的模型也有许多不同的名称。

多模态嵌入模型中的塔是什么？

"塔"（tower）这个术语源自对比语言-图像 预训练 （Contrastive Language-Image Pre-training，CLIP），这是 OpenAI 于 2021 年发布的一个模型，也是最早学习文本和图像共享嵌入空间的模型之一。在 CLIP 中，每种模态都由一个完全独立的模型处理。在架构示意图中，这些模型看起来就像并排矗立的塔，每个塔接收一种类型的输入，并在共享空间中生成向量。这个名称就这样沿用了下来，现在你会在多模态 ML 中广泛看到它。

在 jina-embeddings-v5-omni 的语境中，这个词的使用稍微宽泛一些。它的架构并没有 CLIP 意义上真正并行的塔。所有模态最终都会汇入一个中央文本模型，而不是与文本模型处于平等地位并列存在。

在明确这一点之后：塔（或_模态组件_）是一条将一种类型的原始输入转换为向量的处理流水线。_文本塔_将字符串转换为向量，_视觉塔_生成图像嵌入。_音频塔_则对声音执行相同的操作。

为什么要冻结一个塔，而不是训练它？

如果我们想要多模态能力，能不能把多个分别处理这些输入的塔像 "弗兰肯斯坦（Frankenstein）" 一样拼接到一起，组成一个模型？这种方法的问题在于，不同模型生成的向量彼此无法理解。例如，图像存在于一个向量空间中，而音频存在于另一个向量空间中。这意味着我们无法跨不同模态进行比较。可以把一个模型输出的向量想象成存在于它们自己的语言中。假设我们的音频塔输出的是西班牙语，而图像塔输出的是英语。从概念上来说，这些向量可能描述的是相同的事物，但尝试使用这些嵌入的下游工具都是 "单语" 的，所以我们就无能为力了。

CLIP 风格的方法是将多个塔放在一起进行训练，让它们相互调整，直到它们的输出达成一致。这有点像让说西班牙语的人和说英语的人持续交流足够长的时间，最终大家都开始说 "西班牙式英语"。

这种方法确实有效，但它有一个副作用：你原本已经正常工作的塔会在这个过程中被重新调整。它们之前生成的任何嵌入，现在都与新版塔生成的嵌入不兼容。如果你有一个文本塔，并且已经用它生成了 1 亿个嵌入，那么现在你就需要重新为所有这些字符串生成嵌入。

为了解决这个问题，你可以冻结某些塔。这会锁定它们的权重，也就是影响它们行为的各种旋钮和调节参数。这样一来，训练过程就永远不会改变它们。你训练的则是一个小型投影器，它负责将一个塔的输出_翻译_成另一个塔的语言。许多不同的模型都会训练部分投影器和塔，同时让其他部分保持冻结。jina-embeddings-v5-omni 的独特之处在于，我们冻结了_所有_编码器，只训练投影器和分隔符 token。读完本文，你就会确切理解这是如何工作的。

你可以把这些冻结和可训练的组件想象成神经元簇或大脑中相互隔离的区域，而整个嵌入模型（jina-embeddings-v5-omni）则是完整的大脑。在这些具备学习能力的组件之间，存在一些固定的数学运算，例如在数字从一个塔传递到另一个塔的过程中，对数字进行合并、压缩、选择和重新缩放。这些运算没有权重，因此没有任何东西需要冻结或训练。

有了这些基础知识，下面就是完整的架构。

jina embeddings 多模态架构如何工作

该架构将所有模态通过冻结的编码器和小型可训练投影器，路由到一个统一的共享文本嵌入空间中。

为什么文本塔是骨干

这里首先需要注意的是这张图中数据流动的整体方向。图像、视频和音频输入最终都会进入与文本输入相同的空间。为什么架构要这样设计？

jina-embeddings-v5-omni 构建于 jina-embeddings-v5-text 之上：它保留了文本处理骨干，并通过预训练的视觉和音频组件对其进行扩展。

这主要有两个优势：

1. 文本模型对于其规模和所执行的任务而言已经达到了业界领先水平，而且它完全不会被修改。没有必要修复没有问题的东西。我们也不需要重新为已经使用 jina-embeddings-v5-text 生成嵌入的数据生成嵌入。

2. 一个统一的共享向量空间是跨模态搜索能够实现的根本原因。由于图像、音频和文本最终都会解析为处于相同几何空间中的向量，因此你可以使用文本查询图像或音频，并直接通过_余弦相似度_（一种基于两个向量之间夹角的相似度度量）对它们进行比较。如果每种模态都存在于各自独立的空间中，那么这些比较就没有意义。

视觉和音频编码器如何输入文本模型

在 [jina-embeddings-v5-text](https://huggingface.co/collections/jinaai/jina-embeddings-v5-text "jina-embeddings-v5-text") 奠定的基础上构建模型的第一步，是将视觉和音频编码器集成到这一架构中。在这里，我们使用现有的 [Qwen3.5](https://qwen.ai/blog?id=qwen3.5 "Qwen3.5") 视觉编码器和 [Qwen2.5-Omni](https://qwen.ai/blog?id=qwen2.5-omni "Qwen2.5-Omni") 音频编码器，它们本身分别改编自 [SigLIP2](https://huggingface.co/docs/transformers/model_doc/siglip2 "SigLIP2") 和Whisper-large-v3。这些编码器最终负责为所有基于视觉和音频的数据生成原始向量。这里强调的是_原始_，因为之后仍然需要进行大量转换。

视觉编码器如何处理图像

对于图像，我们借鉴 Qwen 的部分不仅仅是编码器。编码器的输出还连接了从 Qwen 继承而来的额外处理组件。下面让我们看看编码器输出的是什么，以及继承而来的下游组件如何转换这些输出。

视觉编码器（冻结）

让我们以图像作为主要示例，因为视频中的视觉组件基本上完全相同。看看这张香蕉船冰淇淋的图片。

视觉编码器并不会为这张 图像生成 一个单一、干净的向量嵌入，而是将图像分割成 14 像素 × 14 像素的区域，并为每个区域生成一个微小的 patch token（基本上就是一个迷你向量）。

在视觉编码器内部，每个 token 都会查看组成图像的其他所有 tokens，并从与自己相关的 token 中获取信息，然后根据这些上下文更新自己的向量。这个过程使我们能够保留细粒度的细节。现在，我们不再只有一个代表整张图像的单一向量，而是拥有多个更小的向量，用来表示整道甜点中的各种细节。

LayerNorm（冻结）

LayerNorm 会重新缩放每个 patch 中的数值，使它们在进入后续处理之前处于一致的范围内。它可以防止某些 patch 的数值远大于其他 patch，从而淹没其他 patch 的信息。

2x2 合并

在视觉编码器部分我们看到，图像会被分割成许多 14 像素 × 14 像素的小方块。不过，在下游处理如此多的 patch token 会变得非常昂贵。因此，2x2 合并操作会将四个 patch token 合并成一个。此时，每个方块变成 28 像素 × 28 像素。相应的 patch token 也会以类似的方式进行合并。

fc_vision_1（冻结）

fc_vision_1 是两个矩阵乘法中的第一个；它将合并后的 patch 数值混合成一组新的数值。该层继承自 Qwen，并保持不变。

GELU

Gaussian Error Linear Unit（GELU，高斯误差线性单元） 是应用于每个数值的一个门控机制。它让有用的信号通过，并将其余信号压缩到接近零。它是唯一的非线性步骤，最终使两个 fc_vision 层能够共同学习出单独的简单乘法无法表示的形状。

fc_vision_2（可训练）

正如前面提到的，试图直接将 Qwen 图像嵌入放入与 Jina 文本嵌入相同的向量空间，就像试图将一句西班牙语放进一本英语小说中一样。在其原生上下文之外，它的含义会完全丢失。

这正是可训练投影器 fc_vision_2 要解决的问题。它学习将图像嵌入转换成 jina-embeddings-v5-text 能够理解的形式。因此，你可以把可训练投影器理解为一个翻译器。

这里需要强调的是_可训练_：这是我们目前在整个流程中遇到的第一个没有被冻结的组件。这个架构中的许多组件都是冻结的，这意味着它们的权重被锁定，在训练过程中永远不会改变；但 fc_vision_2 是少数几个真正会被更新的部分之一，因为它必须_学习_如何将 Qwen 的图像维度转换成一种能够有意义地进入 Jina 文本空间的形式。

× 4

到这里，你可能已经注意到，fc_vision_2 底部标有"× 4"，fc_audio、两个编码器以及 jina-embeddings-v5-text 中的"嵌入文本"部分也都有这个标记。在这里，它表示 fc_vision_2 有四个不同的实例，每个实例都针对下面介绍的四种略有不同的任务进行了优化和调优。

任务	功能	用户输入示例	最终结果示例	备注
检索	为输入找到相似的匹配项（即标准的 Google 搜索）	字符串/文本 "melting ice cream"	一张掉落在沥青路面上的冰淇淋甜筒图片
文本匹配	判断输入之间的相似程度	文本字符串"melting ice cream"和一张掉落在沥青路面上的冰淇淋甜筒图片	判断两个输入有多相似的分数	这个任务的名称有点名不副实。它被称为文本匹配，但实际上适用于任何模态，而不仅仅是文本。
聚类	将数据分组成不同的集群	大量冰淇淋图片	让用户发现自然形成的群组，例如"圣代"和"冰棒"
分类	将数据放入预定义的类别	两个字符串标签："melting"和"intact"，以及大量冰淇淋图片	根据冰淇淋图片在向量空间中与标签嵌入的距离，将图片数组分到所提供的两个类别中

需要说明的是，"最终结果"这一列指的是：在生成输出向量之后，还会经过一些额外的数学运算和处理，最终得到的结果。关键在于，jina-embeddings-v5-omni 只负责生成向量。这些向量会呈现略有不同的形式，以针对所选择的任务类型进行优化。

这些任务类型也在架构图的低秩适配（Low-Rank Adaptation， LoRA ）组件中进行了明确说明，我们稍后会介绍。

音频编码器如何处理声音

在进一步深入模型架构的细节之前，让我们先退一步，看看面向音频的路径有哪些不同，以及哪些地方保持不变。如果你能够理解前面的视觉部分，那么音频部分就会非常容易。 这一次，我们没有从 Qwen 继承任何额外的处理组件，只有音频编码器和一个可训练的投影器。

音频编码器（冻结）

在音频进入编码器之前，需要先将其转换成编码器可以处理的形式。原始音频是一维波形，本身对 神经网络 来说并不是特别有用。因此，音频首先会被转换成_梅尔频谱图_（mel spectrogram）：一种二维表示形式，将频率映射到时间，并对人耳最敏感的频率范围进行加权。你可以把它想象成声音的视觉指纹。下面是一张梅尔频谱图，展示了一个人说 "I scream, you scream, we all scream for ice cream." 时的声音。

然后，这张频谱图会被切分成固定长度为 40 毫秒的片段，这类似于视觉编码器将图像切分成 14×14 像素的图块。随后，编码器会为每个片段生成一个 token。

这之所以重要，与视觉处理流程中的原因相同：否则细粒度的细节会丢失。对于完整的短语"I scream, you scream, we all scream for ice cream"，如果只生成一个嵌入，就会把所有内容混合成一个模糊的向量。将其切分成较短的片段，可以保持每个声音片段的完整性，这样模型之后就能够区分"scream"和"cream"，而不是将它们压缩成一个平均值。音乐、动物叫声、环境声音等也同样如此。

fc_audio（可训练）

编码器生成 token 后，fc_audio 会执行与图像处理中的 fc_vision_2 相同的转换作用：它将每个音频 token 从编码器的 1280 维输出空间投影到 jina-embeddings-v5-text 的隐藏维度（small 为 1024，nano 为 768）。与 fc_vision_2 一样，它在架构图中标有"× 4"，意味着存在四个实例，每个实例都针对一种特定的任务类型进行了优化（检索、文本匹配、聚类和分类）。

分隔符（可训练）

我们需要向 jina-embeddings-v5-text 传达，这个嵌入代表的是一种非预期的模态。使用分隔符就可以很容易地做到这一点。在 HTML 世界中，它看起来是这样的：

`<p> Your text here </p>` AI写代码

开头和结尾的 <p> 标签表示其中的所有内容都是一个段落元素。

在我们的场景中，情况稍微复杂一些。架构图中将音频的分隔符显示为 <aud_start> 和 <aud_end>，但这并不完全准确。分隔符本身实际上是向量，而不是硬编码的字符串。

每种任务类型都有自己的一对分隔符向量（因此是"4 × 特殊 token"）。这些向量每次都是相同的，而不会针对每个音频嵌入而变化。因此，对于音频输入类型的检索任务，总是会获得起始分隔符向量 X 和结束分隔符向量 Y；对于音频输入的文本匹配任务，则总是会获得起始分隔符向量 A 和结束分隔符向量 B，依此类推。

这是必要的，因为 Transformer layers 组件只能理解向量。因此，当音频嵌入传递到这里时，它看起来是这样的：

`<aud_start_vector_delimiter>` AI写代码

<aud_patch_token_1>

<aud_patch_token_2>

<aud_patch_token_3>

...

<aud_end_vector_delimiter>

相同的模式也适用于图像：

`<vis_start_vector_delimiter>` AI写代码

<vis_patch_token_1>

<vis_patch_token_2>

<vis_patch_token_3>

...

<vis_end_vector_delimiter>

视频则是其中比较有趣的部分。视频中最多会抽取 32 个均匀间隔的帧，并将它们输入视觉编码器。

它不会生成一个由分隔符包裹的单一片段，而是为每个采样帧分别添加自己的 <vis_start> / <vis_end> 包装，然后将这些逐帧片段拼接成一个长序列：

`<vis_start> [frame 1 patch tokens] <vis_end>` AI写代码

<vis_start> [frame 2 patch tokens] <vis_end>

...

<vis_start> [frame 32 patch tokens] <vis_end>

这正是多帧视频能够工作的原因：它不是对帧进行平均，也不是将它们分别处理，而是让 Transformer 接收整个视频作为一个 token 流，从而允许其注意力机制在不同帧之间建立 token 之间的关联。这意味着较早的帧可以影响对后续帧的理解。如果视频还包含音频，则会将音频提取出来，输入音频编码器，并最终添加到帧序列的前面。

`<aud_start> [audio patch tokens] <aud_end>` AI写代码

<vis_start> [frame 1 patch tokens] <vis_end>

<vis_start> [frame 2 patch tokens] <vis_end>

...

然后，Transformer layers 组件会将整个拼接后的序列作为一个输入进行处理。

Jina 文本 Transformer 层（冻结）

我们已经为图像、视频和音频文件生成了 patch token。我们还用向量分隔符将它们包裹起来，目的都是让这些层能够理解它们。这些层会让每个 patch token 查看其他 patch token，并判断自己是否需要根据周围的上下文进行更新。我知道你可能会想：

我们不是已经在编码器内部做过这件事了吗？我们将图像分割成 14 像素 × 14 像素的区域，为每个区域生成 patch token，然后编码器根据同一张图像中的周围上下文更新每个 patch token。

你说得对！我们确实做过。但现在有一个关键区别。

最开始，这种重新建立上下文的过程依赖的是 Qwen 视觉编码器中的注意力机制。而 Transformer layers 中的操作运行的是冻结的 Jina 文本 Transformer 的注意力机制。它们执行的是相同的操作，但使用的是不同的学习参数，因此会以不同的方式转换 token。

可以把它想象成搬家：投影器就是飞机和搬家卡车。它会把你从视觉之地实际搬到文本之地，并让你落在正确的城市，甚至正确的街区。Transformer 的注意力则发生在你把行李拆完之后。你已经到家了；接下来的几周，你会逐渐弄清楚自己究竟适合哪里，认识邻居，熟悉周围环境，并根据实际身边的人调整自己的确切位置。宏观层面的搬迁已经完成了。这里进行的是微观层面的微调。

最后，<vis_end_vector_delimiter> 会吸收它所包裹的 patch token 中的所有信息。

LoRA（冻结）

LoRA 是一种在不完全重新训练现有模型的情况下对其进行微调的方法。它是一小组附加的调整参数，附加在 Transformer 上，用于轻微调整其行为，使其针对某个特定任务（例如检索或分类）进行优化。

最后一个 token 池化

由于 <vis_end_vector_delimiter> 已经将其他所有 patch token 的信息吸收到了自身中，因此我们不再需要考虑其他 token，可以将它们全部丢弃。它会作为一个独立的嵌入，代表整体内容的摘要。

L2 归一化

现在，<vis_end_vector_delimiter> 的长度可能是任意的，这并不好。这一步会对它进行缩放，使其长度恰好为 1，同时不改变它所指向的方向。这是为了进行整理，使得之后将它与其他向量进行比较时，可以进行公平、干净的角度比较。它只改变向量的尺度，而不会改变向量的含义。

冰淇淋就讲到这里

在我们一路深入了解 jina-embeddings-v5-omni 的过程中，我们一直仔细说明哪些组件被冻结，哪些组件是可训练的。到现在你可能已经注意到，每一个塔都被冻结了。实际上，只有小型投影器（翻译器）和分隔符 token 是可训练的。我们将这种架构模式称为 GELATO。这使整个训练过程的成本大幅降低。

需要明确的是，冻结塔这一概念并不是我们发明的。此前的 Locked-image Tuning（LiT）、VISTA 和 Multi-modAl Retrieval model via Visual modulE pLugin（MARVEL） 等工作，都曾冻结其中一侧。GELATO 之前从未有人将这一理念推向极致：在一个模型中同时支持文本、图像、视频和音频，并冻结每一个编码器。唯一经过训练的部分，是每种模态对应的一个投影器层，以及少量分隔符 token。

但它真的好吗？

基准测试结果：jina embeddings 与其他多模态嵌入模型的对比

如果你甚至不知道一个模型是否足够好，尤其是不知道它与竞争对手相比表现如何，那么构建并发布这个模型就没有意义。这就是我们需要基准测试和评估框架的原因。jina-embeddings-v5-omni 参与测试的基准包括 Massive Image Embedding Benchmark（MIEB，大规模图像嵌入基准）、Massive Audio Embedding Benchmark（MAEB，大规模音频嵌入基准）、Massive Multimodal Embedding Benchmark--Video（MMEB-Video，大规模多模态嵌入基准------视频）以及 Massive Multilingual Text Embedding Benchmark（MMTEB，大规模多语言文本嵌入基准）。

至于我们用来进行比较的模型，需要注意避免不具可比性的比较。因此，我们专门选择了采用 omni 风格、具有开放权重，并且支持相同媒体类型的模型：

• LanguageBind

• Omni-Embed-Nemotron-3B

• LCO-Embedding-Omni-3B

• LCO-Embedding-Omni-7B

上面的表格按照参数量排序。参数量最少的模型集中在顶部，参数量最多的模型则位于底部。这个背景信息很重要，因为性能并不是最终需要考虑的变量。如果一加仑售价 100 美元、撒有金箔并使用最优质乳制品制成的冰淇淋，味道与当地杂货店可以买到的普通一加仑冰淇淋相同，甚至更差，那么购买它就很荒谬，因为你只是为没有额外价值的东西支付了巨额溢价。

这里也出现了类似的情况。jina-embeddings-v5-omni-small 和 nano 在文本方面的表现超过了其他所有模型，尽管它们的参数量排名处于较低到中等水平。

音频方面的表现同样很强。jina-embeddings-v5-omni-small 和 nano 击败了其他所有模型，只有 LCO 的模型除外；它们的得分比 LCO 的模型低大约 2 到 3 分。

考虑图像性能时，差距有所缩小，尤其是 jina-embeddings-v5-omni-small。它击败了 LanguageBind 和 Omni-Embed-Nemotron-3B。尽管 LCO 的两个模型分别拥有 47 亿和 89.3 亿参数，而 Jina 只有 15.7 亿参数，但 jina-embeddings-v5-omni-small 与这两个 LCO 模型的差距都不到 1 分。

视频是我们模型表现最弱的部分，不过即使如此，jina-embeddings-v5-omni-small 仍然击败了参数量是其三倍的 Omni-Embed-Nemotron-3B。最终，将这些得分取平均后，可以得到以下排名：

模型	参数量（十亿）	平均得分
LCO-Embedding-Omni-7B	8.93	54.43
jina-embeddings-v5-omni-small	1.57	54.04
LCO-Embedding-Omni-3B	4.70	53.83
jina-embeddings-v5-omni-nano	0.95	47.49
Omni-Embed-Nemotron-3B	4.70	41.21
LanguageBind	1.14	35.82

LCO-Embedding-Omni-7B 的参数量几乎是 jina-embeddings-v5-omni-small 的 6 倍，但平均性能却仅仅略胜于它。

对于任何正在构建搜索或检索增强生成（RAG）系统的人来说，有一个基准测试尤其值得关注：视觉文档检索，其性能通过 ViDoRe 基准测试 进行评估。

在这里，jina-embeddings-v5-omni-small 仅使用 9.2 亿个活跃的文本和图像参数，就取得了 79.25 的得分，领先于 LCO-Embedding-Omni-3B（78.24），并且与 LCO-Embedding-Omni-7B（80.32）非常接近，而后者在这条处理路径上的模型规模接近它的 10 倍。nano 仅使用 3.1 亿个活跃参数，也取得了完全相同的 79.25 分。规模更大的 Omni-Embed-Nemotron-3B 确实以 85.64 分位居第一，但它携带的活跃参数量大约是 jina-embeddings-v5-omni-small 的 5 倍，因此我们的模型仍然是这一组模型中参数效率最高的。如果你的工作负载是根据文档的布局和文本来检索文档页面，那么这个数字值得重点关注。

冻结塔多模态嵌入的局限性

GELATO 的冻结塔设计以较低的训练成本取得了很强的效果，但它也伴随着一些值得明确指出的权衡。正如前面提到的，最明显且最一致的弱点是视频。jina-embeddings-v5-omni-small 在视频方面落后于 LCO 的模型，而_时刻检索_（定位视频片段中的特定事件）是所有子任务中表现最弱的。部分原因在于其结构：每一帧都会生成自己的一组 token，然后所有 token 被拼接并池化成一个最终的嵌入。将如此大量的信息压缩到一个嵌入中，意味着前面的维度承担了更重的负担，因此当视频嵌入被截断到更小的尺寸时，其性能下降速度会比图像嵌入更快。

音频也存在自身的差距。虽然检索和分类得分具有竞争力，但音频聚类是音频子任务中表现最弱的部分（jina-embeddings-v5-omni-small 为 6.13）。

跨模态音频-文本检索比 LCO-Omni-7B 低 11--15 个百分点，这一差距大于图像-文本（I-T）组合中 6--7 个百分点的差距。fc_audio 投影器自然成为增加可训练参数的下一个目标，这表明音频-文本（A-T）对齐路径相比多层视觉处理流程，还有更大的提升空间。

多模态嵌入如何分布在向量空间中

我们已经通过基准测试讨论了性能，但实际的嵌入是如何分布的呢？

在上面的图示中，视频片段中的数据被输入到每个模型中，并在向量空间中绘制出来。随后，通过Uniform Manifold Approximation and Projection（UMAP，统一流形近似与投影）方法将其压缩到二维空间，以便进行可视化。每种模态对应视频中的一个不同组成部分：

模态	视频的组成部分
图像	视频中间的一帧
视频	完整视频
音频	视频中的音频轨道
文本	视频的描述

马上就能看到一些有趣的规律。

我们的模型和 LCO 的模型似乎将不同模态混合在一起，而 LanguageBind 和 Omni-Embed-Nemotron-3B 的嵌入则似乎更倾向于按照模态彼此分离。

我们的模型和 LCO 的模型在这些向量中呈现出_交错几何结构_（interleaved geometry）。这意味着不同模态在向量空间中并没有明确分开，而是交织在相似的区域中。Omni-Embed-Nemotron-3B 的这种现象不那么明显，因为看起来只有图像和视频占据相似的空间。

LanguageBind 则是完全分离的，不同模态占据完全不同的空间。这被称为_模态间隙模式_（modality-gap pattern）。

那么哪一种更好？在实践中，交错几何结构往往更有用，而且值得注意的是，我们基准测试中表现最强的模型（我们的模型和 LCO 的模型）都呈现出了这种结构。不过，这其中也存在权衡。

交错几何结构非常适合跨模态检索，因为所有内容都混杂在向量空间中，因此彼此之间的距离更近。当文本和图像嵌入在向量空间中如此接近时，根据"草莓冰淇淋"这段文本找到匹配的图片会更加容易。

不过，当你尝试执行同模态任务时，那张原本非常方便找到的图片现在反而碍事了。然而，在实践中，可以很容易地通过类似"modality"字段的元数据过滤来缓解这个问题。

对于呈现模态间隙模式的模型所固有的问题，则不存在这样的解决方法。由于所有视频都彼此隔离地聚集在一起，因此很容易找到另一段冰淇淋上浇糖浆的视频。但将不同模态限制在这样的独立集群中，会让寻找与之匹配的图片变得困难得多。

为什么采用这种架构？

GELATO 以极少的训练获得了很高的性能。你可以保留所有塔的原样，只训练小型投影器和分隔符 token，这比其他方案的成本低得多。为了给 "更便宜" 一个具体的数字：对于 jina-embeddings-v5-omni-small，仅训练视觉投影器只需要更新 420 万个参数，而完整微调则需要更新 9.206 亿个参数。在相同的 15,000 步训练预算下，仅训练投影器的运行速度大约快 1.8 倍，GPU 内存峰值为 7.52 GiB，而完整训练则达到 12.96 GiB。音频路径的差距更加明显，仅训练投影器的速度比完整训练快 3.2 到 3.9 倍。但我们是如何得出这种架构更合适的结论的？我们使用了一种称为_消融实验_（ablation）的过程。

消融实验是指移除或改变系统中的某个部分，以观察它究竟有多重要。想象一下，你一直在研究一种冰淇淋配方。每次进行调整，比如将牛奶加倍、用白糖替换红糖、使用香草豆荚而不是香草精，或者去掉巧克力块，这些都属于消融实验。

机器学习中的消融实验也是类似的。它会研究移除、重新排列、冻结或解冻某些组件，是否会让整个系统的性能变得更好、更差或保持不变。在这里，我们尤其关注解冻某些组件，以及以什么顺序解冻，是否会影响性能。我们针对 Qwen3.5 视觉处理栈进行了五项消融实验。实验结果使用平均 nDCG@10（归一化折损累计增益，Normalized Discounted Cumulative Gain）进行衡量，这是一种用于评估排序质量的标准指标，得分越高越好。

总体而言，几乎每项消融实验的结果都基本相同，只有案例 #3 的表现非常糟糕。在解释原因之前，让我们先看看音频对应的消融实验图。

在这个案例中，消融实验案例 #2 的表现最差。你能看出这里表现最差的案例与视觉消融实验中表现最差的案例之间有什么共同点吗？在两种模态中，都遵循同一条规则：如果在投影器完成训练之前就解冻编码器，就会看到更差的性能。

对于这两种模态，我们最终都选择了消融实验案例 #1 作为最终架构。两者的得分都相对较高。在视觉模态中，那些略胜案例 #1 的配置，领先幅度太小，不足以证明增加训练阶段和额外的每任务产物是合理的。音频模态也有类似的情况，案例 #3 以小幅优势击败案例 #1，但需要更多的每任务产物。

消融实验验证了 GELATO 方法：训练一个专门的翻译器（而不是训练说话者）的成本更低，而且质量几乎相同。

总结：为什么冻结编码器能让多模态嵌入更便宜

与其耗费大量成本重新训练多个塔来实现多模态能力，GELATO 通过冻结已经正常工作的塔，只训练小型投影器来转换嵌入，从而将成本降到最低。这些嵌入会被输入 jina-embeddings-v5-text，最终让所有输出向量都存在于相同的交错几何空间中。现在，我们可以用远低于竞争对手的成本，对文本、音频、图像和视频进行比较。

jina-embeddings-v5-omni-small 和 jina-embeddings-v5-omni-nano 都采用开放权重，可供个人使用，并且现在已经可以使用。你可以从 Jina AI 在 Hugging Face 上的集合 下载它们，并立即开始生成多模态嵌入；也可以阅读完整技术报告，了解完整的基准测试和消融实验结果。

原文：www.elastic.co/search-labs...