Perplexity 把 pplx-embed-v2-late 的权重放上了 Hugging Face，两个尺寸：9B 和 0.6B。这不是一次例行的模型更新。它是 late-interaction 多向量嵌入，文本和图像落在同一个语义空间里，大模型负责啃索引，小模型负责在你的设备上发起查询。更值得琢磨的是那个附带的能力描述：检索 PDF 页面时不需要跑 OCR。
两个模型，一个语义空间
9B 是给索引端准备的
索引这活又脏又重。海量文档、扫描件、图表、截图，全都要转成向量存下来，一次处理、长期复用。Perplexity 把 9B 放在这个位置，逻辑很直白：离线批处理最不缺的就是算力预算，缺的是表征能力。文档里的版式、表格结构、图和文字的对应关系，越大的模型越能咬住不放。
0.6B 要解决的是"数据别出门"
查询端完全相反。用户敲一行字、拍一张图，模型得在毫秒级给出向量，还得跑在笔记本、手机或者边缘盒子上。0.6B 就是为这种约束设计的。企业最在意的往往不是零点几个百分点的召回率，而是这段查询文本有没有离开自己的内网。
共享空间才是省事的地方
两个模型如果各说各话，整套系统就得再搭一层对齐。共享嵌入空间的含义是：9B 编出来的索引向量，0.6B 可以直接拿来算相似度，中间不需要翻译层。对工程团队来说，这砍掉的是一整块胶水代码和它带来的误差。
Late interaction 到底把什么拆开了
单向量嵌入的老毛病
传统做法把一整页文档压成一个稠密向量。压缩比惊人，代价也明显：一页纸里同时有免责声明、数据表格和结论段，压完之后谁占主导全看池化那一步的运气。查询词只命中角落里的一句话，也可能被整体语义稀释掉。
多向量意味着更细的判决
Late interaction 换了个思路。文档不是压成一个点，而是保留一组向量，查询也保留一组，相似度在两组向量之间逐对计算再聚合。检索系统因此能看见"这一句对上了"，而不是"整体感觉差不多"。ColBERT 系那一脉的方法，本质都在这条线上。
贵，所以分工才成立
多向量检索的存储开销和计算开销都远高于单向量。索引端要存 N 倍的向量，查询端要算 N×M 次点积。9B 做索引、0.6B 做查询这套组合，其实是被这个成本逼出来的答案，而不是先有参数规模再去找场景。
不 OCR 就能翻 PDF
OCR 流水线的麻烦不在慢
识别慢只是表象。真正的麻烦是错误会固化：扫描件识别错一个数字、一个符号，这个错误就永久写进索引，之后无论换多强的检索模型都救不回来。合同编号、药品剂量、财报里的千分位，恰恰是 OCR 最容易翻车的地方。
页面直接当图像来处理
pplx-embed-v2-late 提供的路径是跳过文字提取这一步，把 PDF 页面作为图像直接编码。版式、印章、手写批注、图表里的刻度，全部保留在原始形态里。少了中间环节，也就少了一类失败模式。
企业搜索的成本账要重算
过去一套文档检索系统的预算，很大一块花在 OCR 集群和它下游的清洗、纠错、重跑上。这条链路一旦被绕开，省下的不只是钱，还有数据接入的周期——新扫描的档案能当天进索引，而不是排队等识别任务跑完。
92.4% 和 64%，这两个数字怎么读
MADQA:偏文档理解的战场
官方口径下，这个模型在 MADQA 上拿到 92.4%。文档问答的难点从来不在找到页面，而在页面找到了之后能不能定位到那一行。多向量机制在这里的优势最明显，因为它保留了句子级的对应关系。
BrowseComp+ 是另一道坎
64% 出自 BrowseComp+，一个更贴近真实网页检索的评测。这个分数低得多，也更真实。开放网络里充斥着噪声、时效冲突和互相矛盾的来源，任何嵌入模型都不可能在这里拿到漂亮的高分。把两个数字放在一起看，比单看任何一个都更有信息量。
权重开源才是那个变量
分数会被超越，权重放出来则是结构性动作。团队可以自己微调、自己量化、自己决定部署在哪。对做垂直检索的创业公司而言，这意味着不必再把最核心的召回层托付给一个随时可能涨价或改条款的 API。
现在动手,还是先等等
这几类团队值得马上试
手上堆着大量扫描件、图纸、票据、历史档案的团队，优先级最高。其次是做终端侧检索产品的：0.6B 这个尺寸让本地语义搜索第一次有了可用的精度。还有一类是已经在用单向量方案、被召回质量卡住很久的团队，换一条技术路线的边际收益可能比调参大得多。
观望的理由同样成立
多向量索引不是免费午餐。存储成本、向量数据库的支持程度、冷启动时的重建开销，都得先算清楚。9B 也不是消费级显卡能轻松带着跑的规模。如果现有单向量方案已经够用，硬切过去只是在给自己找活干。
真正值得注意的是这套组合透露的思路：把重活压在索引侧做一次，把轻活留给每一次查询。检索系统的竞争，正在从"模型多大"转向"算力放在链路的哪一段"。
