Perplexity 开源 pplx-embed-v2-late 多模态 late-interaction 嵌入模型，含 9B 与 0.6B 两个版本

Perplexity 开源了 pplx-embed-v2-late，这是两个面向文本和图像的 late-interaction 多向量嵌入模型，参数规模分别为 9B 和 0.6B，共享同一嵌入空间，权重已发布在 Hugging Face。官方给出的效果是：9B 可用于索引多模态数据，0.6B 可在设备端查询，无需 OCR 即可检索 PDF 页面；MADQA 得分 92.4%，BrowseComp+ 得分 64%。

此前多模态检索通常需要 OCR 或单独的视觉编码流程，文本与图像往往不在同一嵌入空间。这次开源提供了同一空间内的文本与图像多向量嵌入，并同时覆盖服务端索引与端侧查询两种规模，9B 与 0.6B 的组合让多模态检索的部署选择更明确。

late-interaction 多向量嵌入不再把一段内容压成单个向量，而是保留多个向量并在检索阶段做细粒度匹配，因此对页面版式、图文混排的召回更友好。9B 与 0.6B 共享嵌入空间，意味着索引端和查询端可以用不同规模模型配合，端侧小模型负责查询、服务端大模型负责建库，从而省去 OCR 环节。

对产品而言，PDF 页面和图文混排内容可以直接进入检索链路，不必先做 OCR 再索引，流程更短；研发上可在设备端用 0.6B 做查询、服务端用 9B 建索引，降低端侧算力要求。但 9B 索引的显存与延迟成本、以及无 OCR 检索在复杂版式上的准确率，仍需实际验证。

• 在文档问答或企业知识库产品中，用 pplx-embed-v2-late 替代 OCR 加文本嵌入的流水线，先对 PDF 页面和多模态素材做小规模检索效果对比。
• 针对端侧场景，评估 0.6B 版本在设备上做查询嵌入的延迟与内存占用，验证与服务端 9B 索引共享空间的检索一致性。
• 围绕 MADQA 与 BrowseComp+ 的公开得分，搭建内部评测集复现这两项指标，判断是否达到现有检索链路的替换门槛。

• 模型权重在 Hugging Face 的具体许可条款和商用限制是什么，证据中未说明。
• MADQA 92.4% 与 BrowseComp+ 64% 的评测配置、对比基线和数据集细节尚未披露。
• 无 OCR 检索 PDF 页面在扫描件、手写体和复杂表格上的实际表现尚不明确。
• 9B 模型用于索引时的显存、吞吐和成本数据未在证据中给出。