先看证据
把机制串起来
稠密检索把整段文档压成一个向量，省存储、易检索，但细节匹配会被压缩掉；ColBERT 式后期交互则保留每个 token 的向量，查询时再逐 token 比对。它更擅长对齐文档里的局部实体、短语和细节，代价是索引随 token 数增长，查询还要对候选文档做更多计算。多模态检索则要求不同模态的表示能在同一向量空间里比较；共享空间不等于单次输入就能混合文字和图片。
模型为每个 token 生成 128 维向量；对查询中的每个 token，MaxSim 找到文档中最匹配的 token，再把这些最佳匹配分数汇总，因此不用先把整篇文档压成一个向量。图像和渲染后的 PDF 页面也作为视觉输入编码，目标是直接检索页面内容、避免必须先 OCR；文本与图像表示共享嵌入空间，但单次输入不能混合文字和图像。两款模型基于 Qwen3.5，并使用双向注意力；它们从内部 18B ColBERT 教师进行 token 级、LEAF 风格蒸馏。关键的系统设计是尺寸
['适合需要检索扫描件、PDF 页面或细粒度文本证据的场景。', '可用 9B 建索引、0.6B 编码查询；两者共享向量空间。', '文档极长、索引预算紧时，优先评估单向量方案的成本。', '单次输入不能混合文本与图像；上线前核对输入流程。']
一套检索模型，两个不同的成本位置
Perplexity发布了pplx-embed-v2-late，一组面向文本、图像和渲染后PDF页面检索的多模态嵌入模型。它有0.6B和9B两种尺寸，试图解决一个实际矛盾：检索需要足够细地匹配问题与文档内容，但把更强的模型用于每次在线查询，又会增加延迟和算力成本。
这次发布值得技术负责人看的地方，是Perplexity没有把“更大模型”直接等同于“每次查询都用更大模型”。它建议用9B模型建立高质量索引，再用0.6B模型编码实时查询。两者共享嵌入空间，使这类分工在设计上可行；代价则从查询时的模型计算，部分转移到了建库和索引存储上。
保留词元级匹配，放弃单向量的紧凑
常见的稠密嵌入会把整篇文档压成一个向量，索引紧凑、检索计算也相对直接，但压缩可能抹掉局部对应关系。pplx-embed-v2-late为每个词元生成一个128维向量，检索时用MaxSim：每个查询词元先找到文档中最匹配的词元，再把这些匹配分数汇总。这样，“问题中的某个概念”可以直接对上文档里的局部表达，而不必先要求整篇文档与查询在一个向量上整体相似。
细粒度不是免费的。每个词元都要在索引中留下表示，文档越长，存储的向量通常越多，候选文档评分也要处理更多词元。128维确实比材料所列竞品的2048至4096维窄得多，但这并不意味着索引自然变小：单向量模型和词元级模型保存的信息单元不同，不能只比较每个向量的维数。真正需要估算的是语料长度、切分方式、索引实现与候选规模共同造成的总成本。
视觉页面绕过OCR，仍要接受输入边界
模型把页面渲染成图像后参与检索，因此目标场景不只包括可复制文本，也包括扫描件、PDF页面和演示文稿等视觉文档。相较于先解析页面或OCR再检索，这种路径有机会保留版面、图表和页面视觉结构中的信息。Perplexity将其作为多模态检索的设计方向，但材料没有提供足以判断不同文档类型分别能提高多少的独立评测。
使用时还有一个明确限制：单次输入不能把文本和图像混在一起。也就是说，“页面可作为图像被检索”不等于一个请求可以任意融合文字与图像输入。对于工程团队，接入前应确认文档如何渲染、文本问题与图像页面如何分别编码，以及应用层是否需要协调两种输入路径；不能仅凭多模态标签推断接口已经提供任意形式的联合查询。
92.4%是强结果，不是通用质量证明
Perplexity报告称，9B模型在MADQA上达到92.4%准确率，0.6B为90.1%。该测试据官方描述包含800份PDF、超过18,000页和500个人工编写问题，由Gemini 3.5 Flash智能体使用待测检索器搜索；同一比较中，Gemini 3.5 Flash搭配Mixedbread检索器为88.9%，搭配Mixedbread Agentic Search则为93.4%。因此，92.4%说明它在这一套PDF问答评测中表现突出，却没有证明它在所有检索任务上领先。
其他指标呈现出更复杂的轮廓。模型卡列出的ViDoRe v3图像检索nDCG@10为0.6B的62.3%、9B的65.2%；ViDoRe v3 Markdown则为61.2%和64.7%，其中0.6B是材料所述比较中的第二名。材料同时指出，图像检索仍有对手得分更高，BrowseComp+和领域文本任务也各有不同排名。现有数字来自Perplexity的公告或模型卡，而技术报告尚未提供；阅读时应把它们当作发布方报告的基准成绩，而不是独立复现后的结论。
混合尺寸改变的是系统分工，不是免费午餐
共享向量空间带来的实际选项，是让索引端和查询端使用不同尺寸。材料给出的一个例子是：用9B建索引、0.6B查询，在ViDoRe v3图像检索上达到63.5%，高于两端都用0.6B时的62.3%，而查询侧仍使用小模型。Perplexity还称，这种组合在文本任务上可以追回9B模型与轻量方案之间约一半的质量差距，但所给材料没有列出对应的具体分数，不能把它扩展成普遍保证。
部署负担也需要按真实口径理解。0.6B总参数约5.94亿，文本和图像部分的活跃参数分别约2.4亿和3.4亿；9B模型卡列出约7.4B活跃参数，同时Hugging Face页面把模型规模列为8B，发布名称则为9B。材料估算bf16权重内存约为小模型1.2GB、大模型16至18GB，这只是权重估算，不包括运行时开销；发布的F32权重下载体积约为其两倍。两款模型以MIT许可开放，可自托管，但Perplexity托管API在材料中仍是计划而非已上线服务。
先算长文档索引，再决定是否换架构
对包含大量PDF、扫描报告或演示文稿的团队，pplx-embed-v2-late值得进入试验名单，尤其当页面视觉信息难以通过普通文本解析保留时。低成本查询模型配合高质量索引，也提供了把在线推理留在本地、把重计算放到离线建库阶段的可能。不过，模型能自托管不等于完整系统已经轻量：索引生成、存储、更新和候选评分仍是架构账单的一部分。
合理的决策顺序，是先取一批代表性文档与真实查询，测量索引体积、建库速度、检索延迟和任务质量，再与现有稠密检索或OCR流程比较。特别要覆盖长文档和图表密集页面，因为词元级存储成本会随内容规模变化。若测试中局部匹配和视觉页面召回带来的收益足以抵消索引开销，这种设计就有实际价值；若主要瓶颈是存储、更新或简单文本搜索，92.4%的单项成绩本身不足以成为迁移理由。