大模型外挂知识库频频翻车，症结往往不在生成端不会答，而在检索阶段就把切片喂错了。一段丢失主语的条款、一句缺少前置生效日期的赔付约定，大模型推理能力再强也只能断章取义。
Perplexity 联合 turbopuffer 开源的 pplx-embed-v2 检索模型矩阵，试图在检索的第一公里扭转这种局面。继此前主打证据链压缩的 context-9b-preview 之后，团队进一步放出了支持文本与图文混检的迟交互模型 pplx-embed-v2-late，端侧 0.6B 配合云端 9B，两款权重均以 MIT 协议开源。
把新闻拆开来看，核心事实与受众影响集中在三点：
- 发生了什么.Perplexity 开源了两套检索权重，一套用 Token 级软标签把证据链压进 1KB 密集单向量，另一套用 128 维共享空间让端侧 0.6B 模型无缝检索云端 9B 索引。
- 为什么重要.文档检索终于开始绕过版面分析和 OCR 文字识别，PDF 可以整页渲染为图像直接编码，并在检索阶段同时带回结论与验证依据。
- 谁受影响.自建企业知识库、本地 RAG 系统的架构师。调用外部闭源嵌入 API 的开销能省下来，但本地显存、磁盘存储与离线重索引的压力会成倍激增。
蒸馏 Token：把证据链压进单个向量
长文档切分是向量检索的常态，但粗暴切片会粉碎上下文。以往的 Late Chunking 方案虽然尝试整篇编码再池化，但监督信号依然是非黑即白的二元标注。只要切片不含最终答案，就一律算作负例，导致负责限定范围、给出定义的证据切片全在训练里被压制。
Perplexity 的解决方式是把交互开销锁在训练阶段。模型基于内部的 9B ColBERT 检索底盘开发，开源权重规整为 8B。训练期由自研的上下文压缩模型充当教师模型，通读查询与整篇长文，为每个 Token 打分。切片相关度取分值最高的前 n 个 Token 均值，经由带温度系数的 Softmax 变成软标签概率分布。
学生模型只用拟合这层分布，再补上受 ColBERT MaxSim 启发的文档损失。整套训练用掉了 50 多种语言的 430 个数据集。关键在于推理时不再需要多向量晚期交互的高延迟算子，每个切片输出标准稠密单向量。
原生向量为 2048 维，通过 Matryoshka 嵌套表示降至 1024 维后，配合 INT8 量化，单条切片存储占用收敛到 1 KB 左右。
异构协作：0.6B 端侧与 9B 云端共享空间
单向量方案解决的是轻量存储，但在研报、图表和扫描件面前，多模态迟交互成了另一条必须补全的路线。pplx-embed-v2-late 没有死守单向量形态，而是回到 ColBERT 路线，让每个 Token 保留独立的表征向量。
为了避免硬件门槛失控，Perplexity 拿出了非对称设计。轻量级 0.6B 版本基于 Qwen3.5-0.8B 裁剪，文本激活参数约 240M，图像激活参数约 340M，BF16 显存占用压在 1.2 GB 左右，普通轻薄本就能跑；9B 版本的激活参数为 7.4B，显存占用 16 到 18 GB，专供云端集群制作索引。
通过 18B 教师模型的蒸馏，两款模型被约束进同一个 128 维共享向量空间。端侧 0.6B 发起的查询，可以直接与云端 9B 建立的 Token 索引执行 MaxSim 打分。实测显示，0.6B 查询端检索 9B 底库，在 ViDoRe v3 图像检索拿到 63.5% 的表现，逼近纯 9B 的 65.2%，比两端全用 0.6B 的 62.3% 高出整整一个台阶，端侧计算量却完全没有增加。
更实用的改动在于输入处理。该模型直接把 PDF 页面渲染成图像丢给视觉编码器，彻底避开了容易漏字、错位的 OCR 识别流程。
跑分挤水与横向对照
在 turbopuffer 维护的 context-bench 评测中，针对纯文本切片，pplx-embed-v2 以 1024 维 INT8 规格对抗 2048 维 Float32 的 voyage-context-4，指标微弱领先。
但在多模态战场上，官方宣称的 92.4% MADQA 第一名需要仔细拆解。这项测试背后挂载了 Gemini 3.5 Flash 充当最终答题智能体，比拼的是全流水线成绩。单次检索下它确实领先 Mixedbread 基础检索器的 88.9%，但面对调用了 4.7 次检索的多轮 Agentic Search（93.4%），单次检索依然落后一个百分点。
在通用图像检索基准 ViDoRe v3 上，Perplexity 9B 拿下 65.2 分，胜过英伟达 Nemotron-ColEmbed-8B 的 63.54，却没能越过腾讯 EVIE-8B（66.75）和 EVIE-4.5B（66.02）。
| 方案 / 模型 | 向量表示形式 | 向量维度 | ViDoRe v3 表现 | 开源协议 / 部署形式 |
|---|---|---|---|---|
| pplx-embed-v2-late (0.6B/9B) | 多向量 (Token级) | 128 维 | 62.3 / 65.2 | MIT（完全商用） |
| NVIDIA Nemotron-ColEmbed-8B | 多向量 (Token级) | 4096 维 | 63.54 | CC-BY-NC-4.0（限制商用） |
| 腾讯 EVIE-4.5B (截断配置) | 多向量 (可截断) | 截断至 128 维 | 65.27 | 开源权重 |
| Google Gemini Embedding 2 | 密集单向量 | 128 至 3072 维 | 58.7 (Markdown) | 专有闭源 API |
对比英伟达高达 4096 维的 Token 向量，Perplexity 压到 128 维确实显著减负。但腾讯 EVIE 在截断到 128 维后依旧取得 65.27 分，说明低维多向量并不算不可逾越的护城河。
算力账本：谁在为确定性付钱
《淮南子》有言：察一叶而知秋，窥一斑而见豹。Perplexity 频繁下探底层检索，是在摆脱搜索聚合壳公司的标签，争夺企业级 RAG 的话语权。过去企业面对多模态文档很被动，要么把敏感数据拱手发给闭源 API，要么忍受英伟达非商用协议的枷锁。Perplexity 送出一张 MIT 授权的免检门票，确实切中痛点。
但天下没有免费的确定性。无论是 1KB 的单向量还是 128 维的多向量，账单只是从生成端挪到了存储与索引端。
采用上下文联合编码机制，意味着文档切片间存在隐式依赖。哪怕修改正文里的一个错别字，整篇长文的所有切片都必须重新推理编码。对于频繁变动的企业内部 Wiki 或合同库，这种全量重算是一笔沉重的增量计算税。
迟交互多向量同样如此。维度压缩到 128 维并没有改变一字一向量的物理定律。数万页 PDF 沉淀下来的向量总量极其庞大，对向量数据库的内存驻留与磁盘 IO 提出了硬性指标。
Perplexity 把推理时的检索精度做上去了，但冷启动建库吞吐、动态更新损耗和向量库扩容成本，依然留在原地。用不用这套模型，归根结底是一道算术题：你宁愿为在线调用的大模型幻觉买单，还是宁愿按月为离线建库的显卡和固态硬盘付钱。