超越单一向量的多模态嵌入

自今年 2 月发布 pplx-embed-v1 以来，我们一直在研发新一代嵌入模型。上周，我们推出了新的上下文嵌入模型 pplx-embed-v2-context。今天，我们通过 pplx-embed-v2-late 扩展这一系列，它是一组后期交互模型。除更强的检索能力外，这些模型还是首批结合三项核心特性的模型：

• 多向量表示。这些模型不会将每个输入压缩为单个向量，而是保留 token 级向量，以便更细粒度地比较查询与文档。这使查询的不同部分可以匹配文档的不同部分，并保留在多模态检索中特别有价值的细节。
• 同时支持文本和图像模态。除我们之前模型的文本到文本检索能力外，这些新模型还支持文本到图像检索，使其能够直接搜索渲染后的 PDF 页面，而无需 OCR 或解析文本。
• 共享的嵌入空间。我们发布了 0.6B 和 9B 两种模型规模，以支持不同的质量、延迟和计算需求。两者可以独立使用，但共享的嵌入空间也允许较小模型查询由较大模型创建的索引，将更高质量的文档嵌入与低成本、快速的查询时推理结合起来。

这些新模型在一系列视觉与文本检索基准测试以及智能体问答任务中均取得了最先进的成绩。值得注意的是，在领先的视觉文档检索基准 ViDoRe (V3) 上，我们的 0.6B 模型性能可比肩激活参数量为其五倍的模型。两款模型均已在 Hugging Face 上公开发布。我们的技术报告提供了有关方法和评估结果的更多细节。

从单向量到后期交互

检索系统必须在效率与查询和文档之间交互深度之间取得平衡。稠密嵌入模型将每个查询和文档分别编码，从而可以通过代价较低的内积进行比较。这使得在数十亿文档上进行近似最近邻（ANN）搜索成为可行。在另一个极端，交叉编码器将查询和文档一起处理，能够实现更丰富的交互，但需要对每个候选项单独进行一次前向传播。将这种计算应用于大规模文档语料的每次搜索代价极高，因此交叉编码器通常只用于对少量检索候选进行重排序。

稠密嵌入的局限性

用一个固定大小的向量表示整篇文档会形成信息瓶颈。随着文档变长、涵盖更多主题，模型必须将更多内容压缩进同一个向量，使得保留与查询相关的全部信息更加困难。分块可以减轻这种压力，但也会将文档切碎，并可能把只有合在一起才有意义的信息拆散，我们的上下文嵌入模型也在处理这一问题。在多模态场景中，这个瓶颈会进一步恶化，因为图像的信息密度需要更强的压缩。

单向量稠密检索还会将每次比较都简化为两个向量之间的内积，从而限制评分函数的表达能力。对于固定的嵌入维度和足够大的语料，某些查询-文档对上的分数模式无论如何训练都无法产生。LIMIT 基准将这一理论问题转化为针对单向量检索的具体压力测试。

后期交互检索

后期交互模型介于更便宜的稠密嵌入模型与表达能力更强的交叉编码器之间。与稠密模型类似，它们对文档的编码独立于查询，因此可以离线计算文档表示。不过，它们不会将每个输入缩减为单个向量，而是保留多个向量，并在比较查询与文档时使用更丰富的评分函数。

我们的 pplx-embed-v2-late 模型采用 ColBERT 风格架构，为输入中的每个 token 输出 128 维嵌入。我们使用 MaxSim 为查询-文档对打分；对于查询中的每个 token，模型会选择得分最高的文档 token，并将各 token 的最大相似度求和，得到最终得分。这使查询的不同部分能够匹配文档的不同部分，而且更强的 token 匹配会对得分贡献更大。

放大

这种额外的表达能力伴随着更高的存储和候选评分成本。稠密检索为每篇文档存储一个向量，并通过一次内积为候选项打分；后期交互则为文档 token 存储向量，并评估大量 token 之间的相似度。成本会随着文档长度增长，因此后期交互需要不同于单向量 ANN 检索的索引与服务权衡。作为回报，它为质量敏感的语料提供更丰富的第一阶段检索能力，也可以作为更大规模网络检索管道中的后续阶段。

一个模型，多种模态

这种更强的交互深度已被证明对多种任务非常有用，包括长上下文、智能体和领域外检索。这种差异在多模态检索中尤为明显，ColPali 模型在 ViDoRe(V3) 排行榜上的巨大领先就说明了这一点。

真实世界的语料并不只由干净文本构成。它们可能来自 PDF、演示文稿、截图、扫描页、图表和表格。传统流程会解析这些文档，应用 OCR 或生成描述，然后搜索得到的文本，这一过程既昂贵又有损：它可能引入 OCR 错误，并丢失版面、表格结构、图形和空间关系。视觉文档搜索跳过这一步，直接将渲染后的页面投射到表示空间中，让文本查询可以对其进行搜索。

我们的新模型系列建立在多向量模型在多模态搜索中的强劲表现之上，并在最广泛使用的文档搜索基准 ViDoRe(V3) 上，推动了小型模型的帕累托前沿。虽然我们预计文档渲染会是最常见的视觉输入形式，但我们的模型也支持对自然图像进行语义图像搜索，例如风景照片。

训练一组可互操作的模型

搜索本质上是不对称的：索引和查询编码有不同的运行约束。索引离线执行且可以并行化，因此其计算成本会摊销到许多未来的搜索中。查询编码则对每次请求在线执行，因此对延迟敏感，有时还会受到服务端或边缘设备限制。我们的模型系列利用了这种不对称性，为检索管道的两侧提供了量身定制的模型规模。

我们先对一个 18B 教师模型进行对比学习训练，然后分别将其蒸馏为 9B 和 0.6B 学生模型。我们并不只是训练每个学生去复现教师的排序分布，而是使用 LEAF 风格的表示蒸馏：对每个输入 token，将学生的输出嵌入与教师的输出嵌入对齐。虽然表示空间蒸馏此前已用于稠密的单向量模型，但我们将其扩展到了后期交互场景，在这里对齐目标是每个保留 token 的向量。

因此，两个发布的检查点共享同一个多向量嵌入空间。这使跨模型检索成为可能，也带来了更多部署选项。

• 最高质量：使用 9B 模型对文档和查询进行编码。
• 最高效率：使用 0.6B 模型对文档和查询进行编码，实现 100% 本地推理
• 低延迟检索：使用 9B 模型构建语料索引，然后用 0.6B 模型编码实时查询，从而利用索引时计算，同时保持查询快速。
• 本地–云端检索：在设备上用 0.6B 模型编码私有本地文档或实时查询，并将这些表示与云端托管的 9B 索引结果进行比较或合并。

针对对延迟敏感的场景，我们将 0.6B 模型设计为轻量级查询编码器，也可在边缘设备上运行。我们以 Qwen3.5-0.8B 为起点，将其 24 层文本塔裁剪为 12 层，把该塔的非嵌入参数从 4.98 亿降至 2.4 亿。最终模型总参数为 5.94 亿，但其标称规模高估了服务成本：其中 1 亿用于图像编码，2.54 亿位于 token 嵌入表中，对运行时影响很小。只有约 2.4 亿参数用于文本编码、3.4 亿参数用于图像编码，因此该模型具有远小于其实际规模的服务成本，同时仍兼容 9B 索引。

我们采用相同流程，用 27B 骨干构建了 18B 教师模型，这让教师模型在不削弱其提供的信号质量的前提下，蒸馏成本显著降低。

多语言、多模态、未污染的训练数据

我们在一个由 46 种语言中 594 个数据集抽取的 1.86 亿个查询-文档对组成的数据集上训练这两个模型。其中 88.3% 为文本到文本，8.3% 为文本到图像，3.4% 为文本到视觉文档。我们没有按数据集大小成比例采样，而是为每个数据集分配采样权重，从而得到更均衡的训练混合比例，分别为 56.5%、30.9% 和 12.6%。

在构建训练数据时，我们排除了任何与我们评估所用基准相关联的数据集，以忠实呈现结果而不抬高基准分数。这样做的取舍是，我们选择排除的一些数据集包含高质量数据，可能会提升模型在这些基准之外任务上的表现。最终，我们选择接受这一代价：在开发过程中，可信的数字对我们更有用；在用户比较模型时也是如此。

评估

我们在文本、视觉文档、混合图像和智能体检索上评估两款模型。两款模型在 Q2D-Web 和 BrowseComp+ 上都优于所评估的基线，并在视觉文档检索和 MADQA 上取得了强劲结果。

文本检索

我们在三个基准上评估文本到文本检索：

• 领域特定基准：共 72 项 MTEB 风格任务，其中 55 项来自五个领域（金融、法律、医疗、对话、技术），另有 17 项杂项多语言任务。该集合包含 FinQA、AILACasedocs 和 XLSum 等任务。正如上文所述，这些数据集都不在我们的训练数据中。
• Q2D-Web：我们的网络规模检索基准，包含约 70,000 个由智能体改写的搜索查询，来源于生产搜索流量，语料为 1.9 亿个网页文档。由于其生产式查询和大规模语料，这一基准在设置上比其他可用检索基准更接近真实世界的网页检索。
• ViDoRe(V3) Markdown：ViDoRe(V3) 通常是一项文本到视觉文档检索任务，但也可以使用已解析为 Markdown 的语料版本将其评估为文本任务，从而使我们能够在图像和文本两种模态下评估信息丰富的文档检索。

我们使用 nDCG@10 衡量性能，但 Q2D-Web 例外，该基准侧重于第一阶段网页检索场景，因此我们报告 Recall@1000。在整个评估过程中，我们将不同规模类别中的业界领先嵌入模型作为对比对象。对于文本检索，nemotron-embed-8b、gemini-embedding-2、voyage-large-4 和 qwen3-embed-8b 代表最强且使用最广泛的稠密竞争模型，而 voyage-4-nano 和 qwen3-embed-0.6b 则作为十亿参数以下的稠密基线。我们还在 TopK 已发布结果的基准上，将其最近发布的 topk-embed-v1 后期交互模型纳入比较。ViDoRe(V3) 的分数取自其模型卡中 128 维配置的结果，与我们的 token 嵌入宽度一致；Q2D-Web 的分数取自我们的排行榜。

在领域特定基准上，我们的 9B 和 0.6B 模型平均分别达到 81.3% 和 78.0%。我们的 9B 模型在所有评估模型中得分最高，比次优模型高出 1.6 个百分点。我们的 0.6B 模型与其他高分模型相比也具有竞争力，仅比 gemini-embedding-2 低 0.3 个百分点。重要的是，由于我们没有在这些基准任务的任何数据上训练，因此领域特定基准表明我们的嵌入模型能够泛化到新领域。

放大

我们的 0.6B 模型在 ViDoRe(V3) Markdown 任务上的相对优势更大；其 61.2% 的得分击败了除我们 9B 模型之外的所有其他模型，而 9B 模型得分为 64.7%。次优外部模型得分为 60.6%，而次优的 1B 以下模型 topk-embed-v1-0.8b 比我们的 0.6B 模型低 4.3 个百分点。

放大

在 Q2D-Web 上，相关性来自三组判定结果：智能体引用的文档（Citation）、由我们的生产检索系统排名的文档（Web），以及二者的并集再加上对未标注文档的 LLM 判定（Combined）。pplx-embed-v2-late 的两款模型在这三组判定中都领先所有基线。我们重点关注 Combined 判定，因为 Citation 和 Web 集合来源于我们自身系统已经展示过的内容，因此更偏向于和这些系统排序方式一致的模型；而 Combined 中加入的 LLM 判定覆盖了这两个系统都未检索到的文档。在该集合上，我们的 9B 和 0.6B 模型都击败了所有竞争对手，分别达到 74.8% 和 73.6%，而之前的最佳成绩为 69.3%。

放大

视觉检索

我们的主要视觉检索基准是 ViDoRe（V3）的标准公开子集，其中语料由渲染后的页面图片组成，而不是 Markdown 转换结果。我们将其与两款领先的稠密视觉语言模型 qwen3-vl-embed-8b 和 gemini-embedding-2，以及 topk-embed-v1 的后期交互模型进行比较。此外，腾讯的 EVIE 模型和 NVIDIA 的 Nemotron ColEmbed V2 模型是“仅视觉”的多向量基线，专为图像检索任务训练。

我们的两款模型在视觉语言模型中都达到了业界领先水平。我们的 9B 模型平均得分为 65.2%，仅次于 EVIE。我们的 0.6B 模型得分为 62.3%，领先于 topk-embed-v1-2b，在外部基线中仅落后于体量大得多的 EVIE 和 nemotron-colembed-v2-8b。

放大

从模型规模的角度看，我们的 0.6B 模型尤其具有竞争力。它领先所有可比规模的模型，并且仅以激活 3.4 亿个参数处理图像输入的代价，便与 nemotron-colembed-v2-8b 相差 1.2 个百分点。我们的模型按每个 token 生成 128 维嵌入，而 EVIE-4.5B 为 2,048 维，EVIE-8B 和 nemotron-colembed-v2-8b 为 4,096 维。这种存储成本上的差异会极大影响这些模型实际可用的场景。

放大

我们还在 MIRACL-Vision 上评估视觉检索，该基准的语料由维基百科文章截图组成；以及 PPLX-Q2I，这是一个涵盖视觉文档和自然图像的内部基准。PPLX-Q2I 基于 Perplexity 的生产级图像搜索日志构建，旨在反映图像搜索用例的多样性。我们使用一个 10,000 查询的样本，按语言和领域分层，对 100,000 张图像的语料进行评估；每个查询的相关文档就是为其提供的那些图像。我们没有评估 EVIE-8B 或 Nemotron ColEmbed 在 PPLX-Q2I 上的表现，因为以其默认输出维度（Nemotron ColEmbed 4B 为 2,560 维，Nemotron ColEmbed 8B 和 EVIE-8B 为 4,096 维）对如此规模的语料进行索引并不现实。

与其在 ViDoRe(V3) 上的表现类似，我们的 0.6B 模型在 MIRACL-Vision 上也具有竞争力，仅比 qwen3-vl-embed-8b 低 1 个百分点。我们的 9B 模型除了 gemini-embedding-2 之外，优于所有其他模型。

在 PPLX-Q2I 上，我们的两款模型都以超过 9 个百分点的优势击败了 qwen3-vl-embedding-8b，而我们的 9B 模型仅比 gemini-embedding-2 低 2 个百分点。我们的结果在同时包含自然图像和视觉文档的语料上仍保持竞争力，因此在 ViDoRe(V3) 上见效的多向量表示并没有以牺牲通用图像搜索为代价。

放大

跨模型检索

前文各部分的结果都是在模型自行嵌入的语料上评估每个模型。共享的嵌入空间意味着这并非必要：可以用 9B 模型建立索引，再用 0.6B 模型嵌入的查询进行搜索。这正是我们预期大多数生产部署会采用的配置，因为索引是一笔一次性成本，会在语料的整个生命周期内摊销，而查询嵌入则运行在每次请求的低延迟关键路径上。

无法在查询时运行 9B 模型的部署否则也会使用 0.6B 模型来建立索引，因此这种对称的 0.6B 配置才是相关的比较点。我们在上述 72 项领域特定基准以及 ViDoRe v3 图像检索上进行评估。查询由 pplx-embed-v2-late-0.6b 嵌入，我们只改变语料由谁来嵌入。

用 9B 模型进行索引是一个严格改进。在领域特定基准上，这种非对称配置平均提升 1.6 个百分点。在 ViDoRe v3 图像检索上，其得分为 63.5%，高于两端都使用 0.6B 模型时的 62.3%，提升了 1.2 个百分点。查询编码成本在对称 0.6B 配置和非对称配置之间保持不变，因为两者都由同一个 0.6B 模型对查询进行编码；额外的文档编码成本在索引阶段产生。

两端都使用 9B 模型仍然更好，在领域特定基准上的平均得分为 81.3%。因此，非对称配置在无需额外查询编码成本的情况下，大约恢复了文本任务上两款模型之间质量差距的一半。选择哪种配置取决于查询时是否负担得起 9B 模型；如果负担不起，非对称方案就能捕获其相当一部分收益。

放大

智能体检索

智能体检索也是多向量嵌入尤其强大的另一种场景。在 BrowseComp+ 中，一个 LLM（本例中为 GPT-OSS-120B）使用嵌入模型在语料中搜索与复杂用户查询相关的信息，另一个 LLM 判断生成的答案是否与真实答案一致。我们的 9B 模型达到 64.0% 的准确率，比次优的 ColBERT 模型高 4.9 个百分点，比次优的稠密模型高 8.7 个百分点，同时发起的搜索次数少于除我们的 0.6B 模型之外的所有其他模型。0.6B 模型也领先于我们系列之外的所有模型。

放大

MADQA 测试的是在超过 18,000 页的 800 份异构真实世界 PDF 上进行的智能体问答，包含 500 个无法依靠常识回答的人工编写问题。一个智能体（本例中为 Gemini 3.5 Flash）使用受测检索器搜索整个集合，并根据标注的证据页面在答案准确率和页面 F1 上进行评分。我们的 9B 模型以 92.4% 的准确率在检索器中创下新的业界领先，比使用 Mixedbread 检索器的同一智能体高 3.5 个百分点；我们的 0.6B 模型达到 90.1%。我们还指出，我们的检索器相较于 Mixedbread Agentic Search 也取得了有竞争力的结果；后者在其搜索系统中使用一个搜索子智能体，由主智能体在每次调用中规划并执行多次搜索（93.4%，在我们的置信区间内）。

放大

快速开始

我们的 0.6B 和 9B 模型均可在 Hugging Face 上获取，并可与 sentence-transformers >= 6.0.0 和 transformers >= 5.4.0. 开箱即用兼容。更多技术细节和完整评估结果将于今年晚些时候在技术报告中发布。

我们目前正在训练下一代稠密嵌入模型，并将在 Perplexity API Platform 上逐步推出对后期交互嵌入、稠密嵌入和上下文嵌入的支持。

引用

@online{perplexity2026MultimodalEmbeddingsBeyondASingleVector,
  author = {{Perplexity} and Markus Krimmel and Louis Milliken and Antoine Chaffin and Sarah Eslami and Ekaterina Glazkova and Maximilian Schall and Bo Wang and Denis Bykov and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Multimodal embeddings beyond a single vector}},
  date = {2026-10-07},
  url = {https://perplexity.coolkeypoint.com/hub/blog/multimodal-embeddings-beyond-a-single-vector}
}