十月七日，Perplexity 放出 pplx-embed-v2-late 一族多模态检索模型，分 0.6B 与 9B 两档，以 MIT 协议上了 Hugging Face。它打的不是「一个向量代表整页」那种稠密检索，而是 ColBERT 式的 late-interaction：查询和文档各自保留一串 token 级向量，检索时在 token 之间做最大相似度匹配。更关键的是它的分工——官方让 9B 那个重模型负责给语料建索引，0.6B 那个轻模型负责在线跑查询，小模型去查大模型建好的库。

为什么查询和索引用两个不同大小的模型？

传统 embedding 服务为了对齐，查询侧和索引侧必须是同一个模型，结果就是边缘端也得扛一个大模型。Perplexity 这一族的赌注是：建索引是离线的、批量的、不怕贵，用 9B 把每页 PDF、每张图的细粒度语义压准；查询是在线的、每次请求都要扛延迟，用 0.6B 在边缘就能算。两端不必同构，只要共享同一套 token 相似度空间。这样一来，终端设备上跑一次查询的成本被压到极低，而召回质量仍由离线那个大家伙兜底。官方在 MADQA 上报告 92.4 的分数，Vidore v3 页面图这一栏做到 65.2，压过次优的 late-interaction 模型约 4.9 个百分点。

免 OCR 的 PDF 页图检索，省掉了哪道工序？

做文档检索的老流程是：先 OCR 出文字、再切片、再向量化，OCR 错了后面全错。这一族模型直接把 PDF 页当图像喂进去，视觉编码器连同版式、图表、公式一起编码，文字只是其中一种信号。也就是说，一份扫描件、一张带复杂排版的财报、一个塞满图表的论文页，不需要先变成干净文本，就能被索引和召回。对那些版式即信息的文档，这一刀砍掉的不只是 OCR 这道工序，还有 OCR 错误向检索链路里传染的整条噪声。

小模型查大模型的库，代价和坑是什么？

不对称不是免费的。查询侧的 0.6B 必须学会「用轻量模型的视角」去匹配重型索引里的 token，训练时要刻意对齐两端的表征空间，否则小模型吐出的向量分布和大模型索引对不上，召回就垮。late-interaction 本身还有存储代价：它存的是每文档一串 token 向量，而不是一个定长向量，索引体积远大于稠密方案。Perplexity 给的实践建议是查询与文档的 marker 位置要对齐，用 PyLate 的团队尤其要注意。对自建 RAG 的团队，真正值得抄的不是某个分数，而是这个「离线重、在线轻」的不对称思路。

去论坛讨论

前往 silicon-agi.com 论坛 参与讨论