Perplexity pplx-embed-v2-late 将多模态搜索拆分为 9B 索引与 0.6B 查询
Perplexity 发布了两款 pplx-embed-v2-late 模型，并采用了显著的分工：9B 模型构建信息更丰富的索引，0.6B 模型则负责更快速的查询。两款模型均可在同一嵌入空间中搜索文本、图像和渲染后的文档页面。
这一配对的重要性超过了参数量本身。检索团队通常会选择一款嵌入模型，并在所有环节接受其质量、延迟和基础设施成本。Perplexity 则提出，在文档进入索引时投入更多算力，再在请求路径上使用较小的编码器。
这些模型也对搜索视觉结构复杂 PDF 的标准流程提出了挑战。开发者无需通过 OCR 提取文本，而是可以对渲染后的页面进行编码，并通过文本查询检索。不过，这一方法以更大的索引和更昂贵的评分取代了部分解析成本。
Perplexity 发布了两款协同工作的检索模型
此次发布的核心并不只是一对检查点，而是一种围绕共享嵌入空间构建的非对称检索设计。
Perplexity 以 MIT 许可证发布了 0.6B 和 9B 两个版本的 pplx-embed-v2-late。其权重可通过独立的 Hugging Face 模型仓库获取，包括 0.6B model 及其更大的 9B 对应版本。
两款模型都是多模态晚期交互检索器。晚期交互意味着文档和查询会被分别编码，但各自的 token 向量会在评分阶段发生交互。这不同于稠密检索，后者通常会将每个输入压缩为一个向量。
每个模型都会为每个 token 输出一个 128 维向量。随后，MaxSim 评分会为每个查询 token 找到最强的文档 token 匹配，并将这些最大相似度相加。因此，不同的查询词可以匹配页面上的不同区域。
Perplexity 基于采用双向注意力机制的 Qwen3.5 主干构建了这一模型系列。根据模型卡，两款已发布模型均从内部的 18B ColBERT 教师模型蒸馏而来。ColBERT 是一种为晚期比较保留 token 级表示的检索架构。
该公司对较小模型进行了全量微调。对于 9B 版本，则全量微调了最后八个 Transformer 层，并通过 LoRA 适配其余层和视觉编码器。
宣传的模型规模也需要结合上下文理解。较小的检查点总计约含 5.94 亿参数，但 Perplexity 报告称其活跃参数为 3.4 亿。文本编码约激活 2.4 亿参数，而图像编码约激活 3.4 亿参数。
Perplexity 通过将 24 层 Qwen3.5-0.8B 塔剪枝为 12 层，构建了较小的文本塔。该公司表示，其 token 嵌入表还占据了另外 2.54 亿参数。
这种构造针对的是查询时的经济性。索引可以离线运行、在并行硬件上执行，并且只在文档发生变化时进行。查询编码则位于实时请求路径上，每增加一毫秒都会影响用户体验。
共享空间将这两类工作负载连接起来。一家公司可以使用 9B 模型编码文档，再使用由 0.6B 模型编码的查询来搜索生成的索引。更换查询编码器无需重建该索引。
Perplexity 还描述了一种本地—云端配置。设备可以使用较小模型编码私密查询或本地文档，再将该表示与云端托管的 9B 索引结果进行比较。
这种灵活性仍属于技术方案，而非托管产品承诺。模型卡称，这些检查点可与近期版本的 Sentence Transformers 和 Transformers 配合使用。它还表示，目前没有推理服务商提供较小检查点的服务。
Perplexity 表示，晚期交互、稠密和上下文嵌入将逐步接入其 API 平台。在此之前，评估 pplx-embed-v2-late 的团队应假定必须自行运营模型和检索基础设施。
Perplexity pplx-embed-v2-late 的机制保留了页面细节
Perplexity 押注于 token 级匹配能够保留那些单一文档向量往往会压缩丢失的证据。
稠密嵌入模型会分别用一个向量表示查询和文档。检索因此变成高效的最近邻搜索，适用于超大规模集合。然而，这个向量必须概括所有潜在相关细节。
随着文档变得更长或包含彼此无关的章节，这种压缩会变得更困难。当页面包含图表、表格、示意图、说明文字以及依赖布局的含义时，难度还会进一步增加。单一表示容纳所有这些信号的空间有限。
分块可以减少每个向量中承载的信息量。但它也可能将表格与其标签、图表与其图例，或某项条款与重要限定条件分离。解析规则也因文档格式而异。
交叉编码器通过同时处理查询和候选项，解决了部分问题。这种联合注意力支持细致比较，但模型必须针对每一个查询—候选项组合再次运行。它通常只适用于对较短的候选列表进行重排序。
晚期交互则处于两者之间。文档仍会在查询到达前获得其表示。检索系统随后进行多次 token 级比较，而不是为每个候选项只计算一次内积。
Perplexity 的 technical explanation 使用 MaxSim 说明了这一方法。每个查询 token 选择与之最佳匹配的文档 token，系统再将这些相似度累加为文档得分。
以一个关于法规、截止日期和例外情况的查询为例。单一查询向量会混合这些概念。MaxSim 则可以让每个概念分别匹配同一页面中的不同段落、标签或视觉区域。
同一机制也适用于图像。渲染后的 PDF 页面会作为图像输入视觉编码器，而不是先经过 OCR。随后，文本查询可以直接检索其视觉表示。
这并不意味着模型无需准备就能“读取”PDF 文件。应用程序必须将每个相关页面渲染为图像并进行编码。区别在于可检索表示的生成方式。
跳过 OCR 可以保留文本提取会丢失的布局和视觉关系。财务表格的行列位置可能承载关键含义。示意图可能传达其说明文字仅能部分描述的关系。
无 OCR 检索还可避免扫描件、特殊字体和复杂页面结构中的识别错误。不过，它不会自动提供用于高亮、引用、访问控制或下游语言模型上下文的提取文本。
因此，许多应用仍会在视觉检索之外保留解析流程。视觉嵌入可以识别出有希望的页面，OCR 或原生 PDF 文本则在之后提供准确段落。两种技术可以互为补充。
Perplexity 使用来自 594 个数据集、涵盖 46 种语言的 1.86 亿个查询—文档对训练了这两款模型。该公司报告称，其中 88.3% 为文本到文本对，8.3% 为文本到图像对，3.4% 为文本到视觉文档对。
采样组合提高了视觉数据的相对占比。Perplexity 表示，其最终采样权重产生了 56.5% 文本到文本、30.9% 文本到图像和 12.6% 文本到视觉文档样本。
这些细节之所以重要，是因为“多模态”涵盖了多种不同问题。检索一张照片并不等同于在密集的年度报告页面中寻找证据。训练数据的平衡会影响哪些使用场景获得最强的表示能力。
发布的模型卡还规定了一项实现限制。纯文本和纯图像项目需要分开调用编码，而混合文本加图像输入不支持作为一个项目处理。应用必须据此设计数据摄入流程。
共享嵌入给单模型检索流水线带来压力
竞争压力落在那些同时使用一种编码器规模进行离线索引和延迟敏感型查询的检索系统上。
大多数嵌入部署都将模型视为统一组件。同一个检查点嵌入语料库和每一个传入查询。这种对称性简化了运维，但忽略了两类任务不同的经济性。
文档编码通常是一项可摊销的成本。一家公司可能只处理一次页面，随后便可针对其存储表示回答数千次搜索。它可以在更强大的硬件上安排索引任务，或对工作进行批处理。
查询编码会在每次搜索时重复进行。它影响响应时间、并发能力和设备端可行性。为每个请求运行大型视觉语言编码器，可能会抵消离线索引所获得的收益。
Perplexity 的共享空间将这些选择分离开来。9B 模型可以投入额外算力以捕捉文档信息，而 0.6B 模型生成兼容的查询。索引保留了部分大型文档编码器带来的优势。
在 Perplexity 对 72 项特定领域检索任务的评估中，非对称设置相比两侧均使用 0.6B，平均提升了 1.6 个百分点。查询编码器保持不变。
在 ViDoRe v3 图像检索中，0.6B 查询与 9B 文档的配置获得了 63.5% 的 nDCG@10。对称的 0.6B 配置得分为 62.3%，相差 1.2 个百分点。
同时使用 9B 模型处理查询和文档，仍获得了最高的报告领域平均分，为 81.3%。Perplexity 表示，非对称配置在不增加查询时编码规模的情况下，弥补了约一半的文本质量差距。
这正是此次发布最务实的论点。较小模型不需要独自匹配每一项 9B 结果。它只需让高质量 9B 索引能够在更严格的服务约束下发挥作用。
这一方法对标准稠密模型构成压力，但它也在与其他多向量检索器竞争。Perplexity 将其模型与 Qwen3-VL-Embedding、EVIE、TopK Embed 以及 Nvidia 的 Nemotron ColEmbed 系列进行比较。
在 ViDoRe v3 的公开图像部分，Perplexity 报告 9B 模型的 nDCG@10 为 65.2%，0.6B 模型为 62.3%。对应的 markdown 得分则为 64.7% 和 61.2%。
Perplexity 表示，0.6B 模型在图像检索上的表现仅比 Nemotron ColEmbed V2 8B 低 1.2 个百分点。该公司还强调，其输出为每个 token 使用 128 维。
这一维度比较直接关系到索引的可行性。Perplexity 列出的 EVIE-4.5B 输出维度为 2,048，而更大的 EVIE 和 Nemotron 模型为 4,096。更少的维度可以减少每个存储 token 向量的大小。
维度本身并不能决定生产成本。保留 token 的数量、数值精度、压缩方法、索引结构和候选生成策略同样重要。Perplexity 尚未公布针对代表性语料库的完整存储计算。
替代方案并未消失。稠密检索在超大规模下仍更易于建立索引和搜索。交叉编码器仍适合用于重排序。混合词法搜索仍能保护精确标识符、名称和罕见技术术语。
因此，Pplx-embed-v2-late 更可能成为检索栈中的一个环节，而非通用替代方案。Perplexity 本身将后期交互描述为：要么用于更丰富的第一阶段检索，要么作为 Web 规模系统中的后续阶段。
对于构建可搜索知识库的团队而言，设计问题也变得更加具体：他们必须决定哪些文档值得采用视觉、多向量索引，哪些文档采用文本检索仍然高效。
基准测试结果很强，但仍由公司自行报告
已公布的分数值得认真测试，但并不能就现实中的延迟、存储或检索质量下定论。
Perplexity 报告称，其 9B 模型在 BrowseComp+ 上的答案准确率为 64.0%。这一结果比排名其后的 ColBERT 模型高出 4.9 个百分点，比排名其后的稠密模型高出 8.7 个百分点。
BrowseComp+ 使用固定语料库，而不是实时 Web 搜索。其基准设计包含 830 个高难度查询，以及约 10 万篇经过筛选的网页文档，并附有人类验证的支持证据。
固定集合提高了可复现性。研究人员可以将检索质量与商业搜索引擎或开放 Web 的变化区分开来。但这也使该基准的范围比运行一个实时、持续变化的 Web 索引更窄。
Perplexity 将其检索器与高推理强度下的 GPT-OSS-120B 配对使用。另一个语言模型负责判断生成答案是否与参考答案一致。因此，报告中的 64.0% 衡量的是一个智能体-检索器系统，而非孤立的嵌入分数。
该公司称，0.6B 模型也超过了 pplx-embed-v2-late 系列之外的所有模型。不过，该公告并未以可搜索文本形式提供所有底层分数。完整技术报告计划稍后发布。
在 MADQA 上，Perplexity 报告其 9B 检索器的答案准确率为 92.4%，0.6B 模型为 90.1%。两者均与 Gemini 3.5 Flash 配对使用。
MADQA 评估跨异构 PDF 的智能体搜索。底层MADQA 论文描述了基于 800 份文档的 2,250 个由人工编写的问题，而报告中的评估使用了其中 500 个问题的子集。
Perplexity 称，该子集涵盖超过 18,000 页内容。这些问题无法依靠通用知识作答，因此智能体必须从文档集合中检索证据。
9B 的结果比使用相同智能体的标准 Mixedbread 检索器高出 3.5 个百分点。Mixedbread Agentic Search 达到 93.4%，Perplexity 称这一成绩落在其置信区间内。
这一区别很重要。Mixedbread Agentic Search 包含一个搜索子智能体，能够在每次外层调用中规划并执行多次搜索。Pplx-embed-v2-late 则作为智能体内部的检索器，而不是完整的智能体搜索服务。
MADQA 的作者还指出了文档智能体更广泛的局限性。他们的研究发现，强大的系统能够接近人类准确率，但成功回答的问题并不相同。智能体往往通过重复搜索来弥补策略薄弱的问题。
更好的检索器可以减少这种浪费，但无法保证出色的搜索规划或证据综合能力。检索准确率、答案准确率、页面级证据质量、延迟和工具调用次数，都应分别进行评估。
Perplexity 还报告了强劲的 ViDoRe v3 结果。这一公开基准让开发者能比答案生成测试更直接地观察页面检索表现。不过，基准集合无法复现每一种企业文档格式。
真实语料库中存在重复内容、访问限制、修订版本、手写标注、低分辨率扫描件，以及布局几乎完全相同的页面。它们还包含通用训练数据混合中可能不存在的领域专用缩写。
内部 PPLX-Q2I 基准带来了另一个验证缺口。Perplexity 基于生产环境中的图像搜索日志构建了该基准，并以 10,000 个查询对 100,000 张图像进行了评估。外部研究人员目前尚无法复现这一私有测试。
Perplexity 称，两款模型在 PPLX-Q2I 上均比 Qwen3-VL-Embedding-8B 高出超过 9 个百分点。它还称，9B 模型比 Gemini Embedding 2 低约 2 个百分点。这些发现应继续归因于该公司。
此次发布值得关注，因为权重和公开基准检查点允许进行独立测试。但它并不应被自动视为适合每个语料库的最佳选项。
开发者应根据自己的文档和真实查询构建评估集。它应包括精确查找、跨页证据、视觉表格、生僻术语，以及刻意设计的困难负例。
他们还应比较条件相当的端到端系统。除非这些差异代表预期的生产设计，否则不应让某个配置获得更好的 OCR、更多轮搜索或更强的重排序器。
多向量搜索转移成本，而不是消除成本
Pplx-embed-v2-late 通过接受更大的表示形式和更复杂的候选评分，绕开了一个压缩瓶颈。
稠密检索会为每份文档或每个分块存储一个向量。后期交互则保留多个向量，通常是每个未被剪枝的 token 一个向量。因此，一张较长页面可能产生许多可搜索的表示。
即使维度只有 128，这些向量也会不断累积。索引存储取决于 token 数量、数值格式、压缩方案、元数据和检索引擎。页面级视觉表示会进一步改变这一计算。
MaxSim 所需的工作量也超过一次查询-文档内积。每个查询 token 都必须在文档 token 中找到最强匹配。高效服务需要专门的索引、剪枝或分阶段检索。
Perplexity 在公告中承认了这一权衡。该公司称，后期交互所需的索引和服务选择不同于单向量近似最近邻检索。文档越长，成本越高。
共享模型空间有助于查询编码，但并不能消除候选评分成本。轻量级查询编码器仍可能生成一个请求，而该请求与数百万 token 向量进行匹配的代价很高。
因此，团队应分别衡量四项延迟组成：查询编码、候选生成、MaxSim 评分，以及下游重排序或生成。只报告模型推理时间会掩盖用户体验中的很大一部分。
内存使用也需要谨慎测量。9B 检查点可能是离线组件，但为频繁变化的语料库建立索引仍可能需要持续的 GPU 容量。重新编码文档修订版本也会增加运维工作。
视觉文档管道需要在模型推理前进行页面渲染。大型 PDF 需要分页、图像归一化、故障处理、元数据映射和删除工作流。OCR 或许会从检索环节消失，但摄取仍然是一个系统问题。
OCR 也仍具备优势。提取出的文本支持关键词搜索、高亮显示、引用、合规审查，以及直接提供给语言模型的上下文。仅靠渲染页面的嵌入无法复现这些功能。
可能的生产设计是混合式的。系统可以为原生文本建立索引以实现精确检索，为对布局敏感的页面保留视觉嵌入，并在受限候选集合上使用重排序器。
访问控制同样值得重视。检索索引必须在结果到达智能体前过滤未获授权的材料。共享的本地-云端嵌入空间并不会自动提供文档权限或隐私保障。
所提出的端侧查询路径还带来了更多问题。Perplexity 称 0.6B 模型适用于边缘设备，但设备类别差异很大。内存限制、加速支持、量化和电池使用情况都会决定实际可行性。
已发布的检查点在其 Hugging Face 页面上使用 F32 张量。开发者可能会测试低精度或平台特定的变体，但这些转换需要进行质量检查。量化可能改变检索排序。
兼容性是另一个早期阶段的问题。模型卡要求 Sentence Transformers 6.0 或更新版本，以及 Transformers 5.4 或更新版本。它还警告称，PyLate 会在不同的位置插入查询和文档标记。
该导出版本使用原生 Sentence Transformers 模块，不需要自定义 Python 代码。这降低了集成摩擦，但并未提供完整的生产索引或托管端点。
许可方面相对直接。MIT 许可证允许广泛使用和修改。不过，采用者仍必须审查模型依赖、训练数据相关考量，以及自身对敏感文档的处理方式。
“开源”也可能掩盖重要区别。Perplexity 发布了开放权重和实现说明，但尚未发布完整训练语料或内部的 18B 教师模型。
该公司称，它在训练中排除了与评估基准相关的数据集。这是一项有用的方法论声明，但独立研究人员仍需等待承诺中的技术报告，以审查污染控制措施和评估细节。
谨慎的结论并非后期交互成本过高，而是成本发生了转移。团队以更丰富的索引、token 级评分和更专门的基础设施，换取对 OCR 的依赖减少以及对单向量压缩的摆脱。
三个信号将显示这一设计能否走出基准测试
下一项考验是，独立部署能否在不引入不可接受的存储、延迟或运维复杂度的前提下复现质量提升。
第一个信号是对已发布权重的独立评估。研究人员和检索供应商现在可以在公开视觉文档任务和私有行业语料库上比较这两款模型。
复现应覆盖非对称配置，而不仅仅是对称的 0.6B 和 9B 测试。核心主张取决于小模型查询在面对大模型索引时是否仍具价值。
如果独立结果能够在法律、金融、技术和扫描文档中保持所报告的提升，Perplexity 的设计将成为一种可信的部署模式。显著的质量下降将削弱共享空间的论点。
第二个信号是包含索引测量结果的完整技术报告。Perplexity 称，该报告将于今年晚些时候发布。它应披露检索设置、压缩方式、硬件、延迟，以及每个文档 token 的存储量。
该报告还应解释置信区间、训练数据过滤和基准配置。这些细节将显示，在可比的资源限制下，报告中的准确率提升是否依然成立。
存储尤为重要，因为输出维度只是一个变量。128 维 token 向量相较于 4,096 维替代方案看似紧凑，但总索引大小取决于保留的 token 数量。
第三个信号是产品支持。Perplexity 表示将逐步把后期交互、稠密和上下文嵌入加入其 API 平台。托管端点将揭示该公司如何封装索引和服务层面的权衡。
API 支持也将扩大测试范围，使其不再局限于能够运营自定义 GPU 基础设施的团队。如果用户必须自行搭建渲染、索引、MaxSim 搜索和扩缩容，采用范围仍将较窄。
此次推出应澄清，客户是否能通过一项托管服务，将 9B 文档索引与 0.6B 查询混合使用。这一配置是本次发布中最具操作价值的构想。
定价目前还不适合作为比较依据，也不应从 Perplexity 早期的嵌入服务中推断任何价格。多向量存储和评分与单向量文本嵌入存在显著差异。
竞争对手的反应同样重要，但它们属于辅助证据，而非主要检验。Qwen、Nvidia、Google、Mixedbread 及其他检索服务商可以提升质量、降低维度，或提供更易于管理的系统。
Perplexity 的优势不会建立在某一次排行榜快照之上，而取决于共享空间能否在保留足够的大型索引器检索质量的同时，降低实时查询成本。
对开发者而言，当务之急是进行范围可控的评估。构建具有代表性的语料库，渲染视觉元素复杂的页面，并保留文本基线。随后在相同的检索预算下，对称式与非对称式配置进行比较。
衡量回答准确率、证据页面召回率、索引大小、摄取吞吐量、查询延迟和失败案例。还应纳入 OCR 和混合管线，因为视觉检索并不能消除所有解析文本的理由。
Perplexity pplx-embed-v2-late 提出了一个明确假设：文档编码和查询编码不应共享同一计算预算。开放权重使这一假设能够得到检验。
剩下的问题不在于概念，而在于运营层面。当存储、评分、更新、权限控制和下游证据提取均被纳入考量后，9B 索引和 0.6B 查询路径能否胜过更简单的检索方案？
