超级管理员
楼主
Perplexity 发布了 pplx-embed-v2-late，一对迟交互（late-interaction）嵌入模型，提供 0.6B 和 9B 两种规格。
核心思路
两个模型共享同一个嵌入空间，支持文本、图像和视觉文档检索。真正的看点是：可以用小模型去查询由大模型构建的索引。
这个设计解决的是一个很现实的成本问题。
为什么这件事重要
做视觉文档检索时，离线建索引是一次性的、可以慢慢跑、可以用大模型；在线查询是实时的、高频的、必须快。
传统做法要么两头都用大模型（在线扛不住），要么两头都用小模型（召回质量上不去）。共享嵌入空间 + 迟交互，让两端可以解耦：建索引用 9B，在线查询用 0.6B。
效果
官方称在 ViDoRe v3 等基准上取得了 state-of-the-art 结果。两个模型都已上架 Hugging Face。
迟交互的含义
迟交互模型不像传统双编码器那样把整个文档压成一个向量，而是保留更细粒度的 token 级表示，在查询时才做交互匹配。代价是存储和计算开销更大，收益是匹配精度更高。
所以这套方案并不是免费的午餐——索引体积会比单向量方案大。做架构决策时要权衡存储成本和召回质量。
适用场景
- 扫描件、报表、合同这类视觉文档为主的检索。
- 建索引可离线、查询需在线的业务。
- 对召回精度要求高、能接受更大索引体积的场景。
不太适合的场景
- 纯短文本、语义简单的匹配，双编码器就够了。
- 存储预算极其紧张的边缘部署。
- 需要极低延迟且无法接受索引膨胀的在线服务。
验证建议
先用一个小样本集对比单向量方案和迟交互方案的召回率差异。如果提升不明显，就没必要承担索引膨胀的成本。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。