AREXOpen in interactive Feed

AREX Feed Article

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

October 1, 2026

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 则继续接受其他模型提交评测。

参考链接