Perplexity 发布 9B 上下文嵌入预览模型，称在 ConTEB 与 turbopuffer 私有基准上取得最佳成绩

Perplexity 在 9 月 30 日发布了一篇由 Perplexity Research 与 turbopuffer 联合署名的，并在同步公布：公司用一种新方法训练上下文嵌入（contextual embedding）模型，并放出 9B 参数的预览版 pplx-embed-v2-context-9b-preview。模型已在上提供，加载需要 trust_remote_code=True。

Perplexity 称该模型在公开基准 ConTEB 和 turbopuffer 私有持有的 context-bench 上都取得最佳成绩。context-bench 上有一组更具体的数据：K = 10 时，模型取得 45.5% 的 Answer recall、40.6% 的 Evidence recall 和 31.1% 的 All-Evidence@10，比 voyage-context-4 分别高 14.4、5.0 和 3.5 个百分点；每个向量占 1 KB（1024 维 int8），而对手是 8 KB（2048 维 float32）。这些数字由发布方与基准持有方自行报告，context-bench 的语料不对外公开。

分块切断了 chunk 与全文的联系

检索系统把长文档切成可以独立索引的块，但切分同时切断了上下文。按博客的说明，一个 chunk 可能指代前文出现过的实体、依赖章节标题获得含义，或者依赖文档别处的定义；被单独取出后，它可能不再包含足以匹配查询的信息。把整篇文档编码成单个向量也不是解法，博客的说法是一个池化后的表示无法忠实覆盖长文档的每个侧面。

上下文嵌入模型通常用「late chunking」（先整篇编码、再池化出块向量）绕开这一点：文档先一次性编码，之后再池化出各个 chunk 的向量，让每个向量在计算时看到全文。博客引用公开基准 ConTEB（来自 2025 年 5 月发布的，用于评测检索模型利用文档级上下文的能力）和 Perplexity 自家的 pplx-embed-context-v1 说明，这类上下文化的 chunk 表示在长文档上明显优于独立编码的 chunk。后者是 Perplexity 在发布的第一批嵌入模型之一，与 pplx-embed-v1 一起提供 0.6B 和 4B 两档，原生输出 INT8 量化向量。

拿上下文压缩模型当老师

训练这类模型需要知道文档里哪些部分与查询相关，常见做法是给每条查询标注一个「gold chunk」（单个参考答案块）。博客列了这种监督的四个限制：只标注一块相关，文档里提供补充信息的 chunk 会被当作负例；标注粒度粗，一条标签只指向一个块而不是给出相关程度；标注成本随训练集线性增长；标签还绑定当时的切块方式，换切块策略就得重新标注。

Perplexity 换了一个监督来源：让自家查询感知的上下文压缩（context compression）模型当老师，对文档中每个 token 相对查询打分，再把 token 分数聚合成 chunk 级目标——具体取块内分数最高的 n 个 token 的均值，以降低边界 token 的影响。训练目标是两项损失的加权和：文档级对比损失把文档与查询的相似度定义为其最相关 chunk 的相似度，博客称这一打分规则借鉴了 ColBERT 的 MaxSim 操作，只是作用对象从 token 换成了 chunk；chunk 级蒸馏损失则用前向 KL 散度，让学生模型的 chunk 打分分布去拟合老师在同一文档内给出的目标分布，其他文档的 chunk 目标概率置零。

老师只在训练阶段使用。推理时模型每个 chunk 输出一个向量，没有额外的压缩或重排环节，索引存储和检索延迟不会因为老师模型而增加。训练数据约 430 个公开与内部数据集、覆盖 50 多种语言；所有文档内监督都来自压缩模型，没有 chunk 级标注；博客称训练没有用 ConTEB 数据，开发期间也没有拿到 context-bench 数据。模型从一个内部 9B 参数的 ColBERT 检索模型出发，经线性投影输出 2048 维向量，用可学习的 <|chunk_sep|> 标记块边界，块向量由块内 token 表示取均值得到；训练用 Matryoshka（同时训练多档维度）支持 1024 和 2048 两档维度，用量化感知训练原生输出 int8；发布的权重是同一轮训练中若干 checkpoint（检查点）的权重平均（model soup）。

context-bench 的 2,099 条查询与 38,894 篇文档

context-bench 由 turbopuffer 创建并私有持有，博客称其查询、文档和考察的能力来自与 turbopuffer 客户的交流。规模是 2,099 条查询、38,894 篇文档、21 个领域，覆盖企业申报文件、临床研究、旅行、娱乐、教育、政府、法律合同和软件文档等；按句子切块后共 2,458,072 个 chunk。主要目标文档刻意选长：1,197 篇不同的主要目标文档中有 1,061 篇至少 200 句，中位长度约 6,100 token，每条查询在语料中恰有一个正确答案。

这个基准考察三件事：在近乎相同的文档中辨认出正确的那一篇；检索含义依赖文档别处信息的答案块；召回用于验证答案的支撑证据。博客列了 12 类上下文能力，例如实体身份（开头把「公司」定义为 Northlake，一份措辞相似的 Southlake 报告则不相关）、定义与别名（报告把「15 mg 组」定义为 Zeta）、表格结构（表头规定 Mini | Base | Max 与 mAh 单位，答案才能确定），以及指代消解、章节范围、说话人归属和跨语言含义等。它举的客户例子来自物业公司：几百上千份租约只在租户名、日期等细节上不同，问「5 Park Avenue 的租约何时到期、当前租金多少」时，能确认命中文档的地址和租期信息常常离答案句很远。

评分上，每条查询的答案句与证据组都有标注，模型要同时召回答案句和每个证据组中至少一句，才算通过博客所说的「读者充分性」检验。2,099 条查询的主要答案路径中，964 条只有 1 个证据组，735 条有 2 个，332 条有 3 个及以上，68 条没有。所有评测都对全部 2,458,072 个 chunk 做穷举排序，模型之间的差异因此来自表示本身。Perplexity 称其模型独立于 context-bench 开发，并以盲评方式提交；想提交评测的团队需要发邮件到向 turbopuffer 申请。

自述成绩里的领先项与落后项

Perplexity 在博客中报告：在 context-bench 的所有 cutoff 上，预览模型在 Answer 与 Evidence 检索上领先，也领先 All-Evidence@10；Document 检索的差距更小，Document@1 为 15.2%、Document@10 为 61.6%。在 Document@3 和 Document@5 两个截断上，Perplexity 自家的 pplx-embed-context-v1-4B 反而略高，分别为 29.9% 对 29.7%、40.5% 对 40.3%。对照模型包括 voyage-context-4、voyage-4-large 和 NVIDIA 的 Nemotron-3-Embed-8B-BF16。

据同一篇博客，ConTEB 上预览模型的平均 nDCG@10 在对比模型中最高，但并非每项任务最高：NarrativeQA 上是 pplx-embed-context-v1-4B 更高，COVID-QA 上 Nemotron-3-8B 最高。博客称 ConTEB 论文作者也指出，COVID-QA 大多是能用医学术语表层词法匹配解决的抽取式样本，上下文理解在这类任务上帮助有限，非上下文模型通常更强。

在 ConTEB 之外，Perplexity 还用一批 MTEB 任务（LegalBench、FinanceBench 等）自建了 query-to-chunk 和 query-to-document 测试：预览模型的 chunk 检索平均分最高，在法律、技术、健康领域领先；金融与多语种检索更高的是 voyage-context-4，对话检索最高的是 Nemotron-3-8B；文档检索的平均分略低于 voyage-context-4，技术领域领先。博客认为 pplx-embed-context-v1-4B 在这两套测试上平均分偏低，与它只用 ConTEB 训练集训练相符，并指出绑定单一基准的 gold chunk 监督迁移性差。

每向量 1 KB 与 1024 维 int8

上下文嵌入模型每个 chunk 一个向量，索引里的向量数量与同样切块方式的普通 chunk 索引一样；博客的表述是：上下文化改变的是每个向量编码的内容，向量个数不变，存储开销因此取决于单个向量的大小。这个模型提供两条缩减路径：把向量从 2048 维截断到 1024 维，以及量化到 int8。1024 维 int8 下每向量 1 KB，chunk 检索分数略高于用 2048 维 float32（每向量 8 KB）的 voyage-context-4；升到 2048 维则每向量 2 KB，检索质量更高。博客强调这些数字只算向量本身，不含索引的其余部分。

模型卡给出的规格与博客一致：原生 2048 维、Matryoshka 支持 1024 和 2048、INT8、均值池化、固定的 query 与 document 前缀，需要 transformers>=5.4.0。模型卡还标了使用边界：查询和文档要用不同方法编码，查询走 encode_queries、文档 chunk 走 encode，用 encode 编码查询会悄悄降低检索质量；输出是非归一化的 int8，比较时用余弦相似度，或设 normalize_embeddings=True 后用点积；预览版不是最终模型，权重、向量和接口都可能在后续版本中不保证向后兼容地变化，这一版产出的向量不应与未来版本的向量混用。

博客还报告，在 74 个 MTEB 任务上把索引切块从 64 token 加到 512 token，平均 nDCG@10 从 81.0% 降到 79.9%，相差 1.1 个百分点。所有评测都在单次前向中编码最多 32,768 token 的文档。

turbopuffer 报告的成绩与尚未开放的 API

turbopuffer 在自家上转述了这组成绩：它说公司维护着几个内部基准来为客户指引更好的搜索相关性，Perplexity 的新模型「在 context-bench，我们内部的上下文嵌入基准上排名第一」，并把相对传统 SOTA 嵌入模型的 Document recall@10 提升「50% 以上」。这个方向与博客的对照表一致：非上下文的 voyage-4-large 在 Document@10 上是 40.2%，预览模型是 61.6%。context-bench 的语料、查询和标签由 turbopuffer 私有持有，评测结果由基准持有方报告；按博客的说明，这样做是为了降低训练污染的风险。

Perplexity 表示正在准备把该模型接入自家 API，并与 turbopuffer 继续改进长文档检索；目前开放的是 Hugging Face 上的预览权重，turbopuffer 则继续接受其他模型提交评测。