超越黄金段落的上下文嵌入
用于检索答案及其支撑上下文的新训练方法、模型和基准。
简介
上下文嵌入在整个文档的上下文中捕获每个段落或块的含义。它们的训练和评估通常假设每个查询有一个相关的块,称为“黄金段落”。然而,在实践中,黄金段落通常是不够的。它可能包含答案,但缺乏理解或验证它所需的支撑上下文,从而使其在孤立状态下含糊不清。
我们正在推出 pplx-embed-v2-context-9b-preview,这是我们的新上下文嵌入模型。该模型采用了一种新颖的方法进行训练,该方法使用 Perplexity 的上下文压缩模型作为教师。我们将其实际词元级的预测聚合到块级的相关性得分中,教导嵌入模型检索答案块和支撑上下文,而不是单个黄金块。该模型每个块产生一个嵌入,没有额外的推理成本,并支持 1024 维和 int8 嵌入。
它在 context-bench(由 turbopuffer 创建并私有持有的用于上下文感知检索的新基准)以及广泛使用的公共基准 ConTEB 上取得了先进的结果。我们的模型是在独立于 context-bench 的情况下开发的,并作为盲测提交进行评估。
Context-bench 包含跨越 21 个领域的 38,894 个长文档的 2,099 个查询,并评估了上下文嵌入的三种能力:在几乎重复的文档中进行文档消歧、检索其含义取决于远处上下文的黄金块,以及召回验证答案所需的佐证证据。
该模型的预览版已在 Hugging Face 上公开发布。该基准测试由 turbopuffer 非公开保存,以降低训练数据污染的风险,并保持其衡量进展的价值。如需申请评估,请发送电子邮件至 contextbench@turbopuffer.com 联系 turbopuffer。
有关方法和评估结果的更多详情,请参阅我们的技术报告。
为什么上下文对检索很重要
检索系统通常将长文档划分为较小的块,以便可以独立建立索引和搜索。分块在实践中很方便,但它删除了每个块最初出现的上下文,从而在信息压缩的粒度和编码期间使用的上下文之间产生权衡。块可能指代前面引入的实体,从章节标题中继承其含义,或者依赖于文档中其他地方的定义。一旦提取,它可能不再包含足够的信息来与查询进行可靠匹配。将整个文档编码为单个向量并不能解决这个问题,因为一个池化表征无法忠实地捕获长文档的每一个方面。
上下文嵌入模型通过在其周围内容的上下文中表征每个块来解决此局限性,最常见的是通过后期分块(late chunking):文档在单次传递中编码,并且块表征在事后进行池化,以便在查看整个文档的情况下计算每个块向量。先前的研究(例如 ConTEB 和我们自己的 pplx-embed-context-v1)表明,上下文感知的块表征显着改善了对独立编码的块的检索,特别是在长文档上。
黄金块监督的局限性
训练上下文嵌入模型需要识别文档的哪些部分与给定查询相关的监督。常见的方法是黄金块注释:对于每个查询,注释者(通常是大语言模型 (LLM))识别回答该查询的文档块。
训练通常结合了两个对比损失:将黄金块与来自其他文档的块进行对比的跨文档损失,以及将其与同一文档中的其他块进行对比的文档内损失。
此方法具有一些局限性:
- 只有一个块是相关的。它将文档中的每个其他块视为负样本,包括那些具有有用支撑信息的块。文档级监督则在另一个极端运作。它将文档识别为相关,而未指定其中哪些块重要。在实践中,相关性通常介于这些极端之间。带答案的块可能取决于引入实体、解析引用或提供补充事实的几个支撑块,而文档的其余部分则不相关。因此,模型必须学习适当的选择级别:比单个黄金块更广泛,但比整个文档更专注。
- 粗粒度监督。由于每个注释识别的是单个黄金块,而不是捕获整个文档的相关性程度,因此它为用于生成它的计算量提供了有限的训练信号。
- 扩展成本高。每个训练对都需要 LLM 阅读文档并选择相关的块,因此注释成本随训练集的大小线性增长,并限制了训练数据可以有多少以及多么多样化。
- 对块边界敏感。标签也与注释期间使用的块边界绑定。分配给固定词元大小窗口的黄金标签并未指定哪些较短的句子或较长的段落是相关的。因此,更改分块策略,或跨多个分块进行训练以提高对索引时文档分割方式的鲁棒性,可能需要重新注释语料库。
上下文学习的新方法
我们通过从查询感知的上下文压缩模型中提取相关性判断,来解决黄金块监督的局限性。该模型充当教师:它联合读取查询和文档,并为每个文档词元分配相关性得分。其预测为训练上下文嵌入提供了几个优势:
- 灵活的块边界。可以在任何选定的块边界上聚合词元级的相关性得分,从而允许相同的教师预测监督不同的分块,而无需重新注释。
- 连续相关性。与二元黄金块标签不同,教师提供了连续的得分,捕获了自然地区分带答案块、支撑上下文和不相关内容的相关性程度。
- 更低的注释成本。教师体积小巧且专门用于相关性评分,这使得大规模监督的成本远低于通用 LLM。
我们使用查询-文档对批次上的文档级对比损失和块级蒸馏损失的加权和来训练我们的模型。对于每个查询,配对的文档用作正样本,而同一批次中的其余文档用作负样本。
对于每个批次,我们随机选择一个分块策略,相应地分割文档,并在块之间插入分隔符。然后,我们在单次前向传递中处理每个文档,并对每个块内的词元表征进行均值池化,以获得上下文块嵌入。查询被单独编码,对其词元表征进行均值池化。最后,我们计算批次中每个查询嵌入与每个块嵌入之间的余弦相似度。
损失函数
文档级对比损失
虽然我们的嵌入模型只产生块级相似度,但我们可以自然地从中推导出文档级相似度。我们认为文档 d 与查询 q 的相关性与其最相关的块一样高。此评分规则灵感来自 ColBERT 的 MaxSim 操作,此处应用于块而不是词元。
具体来说,给定带有嵌入 q 的查询 q 和作为带有嵌入 c 的块 c 的有序列表的文档 d,我们将文档级相似度定义为:
给定这些文档级相似度,我们可以在批次内负样本上公式化文档级 InfoNCE 目标。
对于查询 q,让 d⁺ 表示其相关文档,𝒟 表示批次中的文档。对比损失如下,为提高可读性省略了温度:
块级蒸馏损失
对比损失教会模型哪个文档与查询相关。蒸馏损失教会它相关性在该文档的什么位置,这对于上下文模型至关重要。
在训练期间,我们将每个正查询-文档对传递给我们的上下文压缩模型,该模型为文档中的每个词元分配相关性得分。与文档级评分一样,我们从其最相关的内容中推导出每个块的相关性。为了减少对异常词元(包括块边界处的词元)的敏感度,我们将块级相关性定义为块内得分最高的 n 个词元得分的平均值。
对于每个查询,我们将温度缩放的 softmax 应用于正文档中教师的块级相关性得分,以获得目标分布。批次中其他文档中的块获得零目标概率。我们通过最小化目标与批次中所有块的预测分布之间的前向 KL 散度,来训练嵌入模型以匹配此目标:
在这里,上标 T 和 S 分别表示教师和学生,rⱼ 是教师对正文档 d⁺ 中块 cⱼ 的相关性得分。教师的目标分布为批次中所有其他文档中的块分配零概率。
与单个黄金块标签不同,此目标捕获了相关性程度。支撑块根据教师的得分获得权重,而不是被视为负样本,从而教导模型检索支撑上下文以及答案。
组合损失
我们的组合训练目标是文档级对比损失和块级蒸馏损失的加权和。我们在查询-文档对批次上对该加权损失求平均值。
图 2 说明了我们的训练方法。上下文压缩器仅在训练期间充当教师。在推理时,嵌入模型每个块产生一个上下文嵌入,没有额外的压缩或重排阶段。该方法改进了上下文嵌入的学习方式,而无需增加索引存储或在检索时增加教师模型的延迟。
训练数据
训练数据包含大约 430 个公开和内部的查询-文档数据集,涵盖 50 多种语言。
我们通过经过 PII 过滤的生产数据以及在长文档上合成相关查询来构建内部配对数据集。对于每个前向传递,我们选择一个数据集并从中抽样整个批次,以增加批次内负样本的难度并避免捷径学习。我们的训练数据集都不带有块级注释:所有文档内监督都来自压缩模型,并且没有使用任何 ConTEB 数据进行训练。此外,在模型开发期间,没有任何 context-bench 数据可供使用。
训练设置
该模型基于内部的 9B 参数 ColBERT 检索模型,并通过线性投影层生成 2048 维嵌入。我们用一个学得的 <|chunk_sep|> 标记来标记块边界,并通过对其标记嵌入求平均来形成每个块的嵌入。查询由同一个模型编码,其标记嵌入被平均为一个单一向量。
我们使用 Matryoshka 训练来支持 1024 维和 2048 维嵌入,并使用感知量化训练来支持 原生 int8 嵌入。在训练期间,我们逐渐提高学习率,保持恒定,然后降低学习率。
发布的模型是一个模型融合(model soup),它对来自同一训练运行的多个检查点的权重进行了平均。
用于块级检索的新基准
诸如 ConTEB 之类的公共上下文检索基准共享了黄金块监督背后的假设:每个查询都有一个相关的块,并且模型只有在将该块排在第一位时才会获得奖励。它们还继承了其局限性。
首先,ConTEB 测试了在没有周围上下文的情况下块会产生歧义的任务上的检索能力。在这些任务中,上下文模型表现优于独立编码每个块的模型。然而,它并未询问模型是否还浮现出了文档中使该块易于理解的其他部分。
其次,当同一语料库中几乎相同的文档仅在包围原本相同的句子的上下文上有所不同时,它没有系统地测试是否能找到正确的文档。
当搜索智能体或用户必须从几个检索到的句子而不是整个文档中理解和验证答案时,这两种能力都很重要。因此,我们构建了 context-bench,这是一个用于长文档检索的受控基准,旨在区分文档上下文的使用与通用检索质量。它测试上下文嵌入是否使用来自文档其他部分的信息来支持三项能力:
- 文档消歧:在几乎相同的替代方案中识别出正确的文档。
- 答案检索:检索其含义取决于文档中其他细节的含答案文本块。
- 证据检索:检索阐明或证实答案的支撑文本块。
Context-bench 包含 2,099 个查询和 38,894 个文档。使用句子长度的文本块,总共产生 2,458,072 个文本块。这些查询涵盖 21 个领域,包括企业申报文件、临床研究、旅游、娱乐、教育、政府、法律合同和软件文档。
每个查询都旨在测试十二种上下文能力之一。主要目标文档刻意设计得很长:1,197 个不同的主要目标文档中有 1,061 个至少有 200 个句子,中位长度约为 6,100 个词元。语料库中每个查询都有且仅有一个正确的答案。如果在黄金文档中多次陈述相同的事实(例如在总结句和表格行中),则这些句子中的任何一句都被接受为答案。
答案路径是答案块与解释或验证它所需的支撑证据的有效组合。在 2,099 个查询中,主要目标文档答案路径在 964 个查询中有一个证据组,735 个查询中有两个,332 个查询中有三个或更多,68 个查询中没有。替代的有效答案路径可能需要不同的证据组。
表 1:基准统计数据。
统计数据 | 值 |
查询 | 2,099 |
文档 | 38,894 |
句子块 | 2,458,072 |
中位主要目标文档长度 | 6,100 个词元 |
领域 | 21 |
每个查询的证据组(主要目标文档答案路径) | 1:964;2:735;3+:332;无:68 |
表 2:context-bench 测试的十二项上下文能力及说明示例。
能力 | 示例查询 | 答案片段 | 所需的文档上下文 |
1. 实体身份 | Northlake 在股票回购上花费了多少? | 该公司回购了 128 亿美元的股票。 | 导言将 Northlake 确定为“该公司”。类似的 Southlake 报告则不相关。 |
2. 期间或版本 | 哪种墨盒适合 M40 修订版 B? | 安装 KC-42 墨盒。 | 适用性部分说明这些说明涵盖修订版 B,而不涵盖修订版 C。 |
3. 定义和别名 | 15 毫克组的退出率是多少? | Zeta 组的退出率为 12.7%。 | 报告将 Zeta 定义为 15 毫克组。如果没有该定义,该片段将无法识别所请求的组。 |
4. 表格结构 | Max 型号的电池容量是多少? | 典型容量:4,250 | 4,700 | 5,150。 | 表头确立了 Mini | Base | Max,以毫安时 (mAh) 为单位计量。因此答案为 5,150 mAh。 |
5. 条件和例外 | 商业用途的电池保修期是多久? | 电池保修期为 18 个月。 | 某节引言将此保修限制在商业安装;家用安装则采用不同的保修条款。 |
6. 引用和代词 | 玛拉(Mara)是什么时候担任副市长的? | 她在 2021 年上任。 | 前面的叙述确立了“她”指的是玛拉,而不是同被讨论的埃林(Elin)。 |
7. 列表顺序和位置 | 哪首歌是安可曲的开场曲? | 14. Lantern Road。 | 别处的注释指出第 14–16 首歌曲组成了安可曲。因此第 14 首曲目是其开场曲。 |
8. 章节范围 | 该电影的摄影使用了哪个镜头? | 全程使用 35 毫米定焦镜头。 | 这段文字属于“主要摄影”,而非关于宣传照片的独立章节。 |
9. 发言者归属 | 市长承诺了什么重新开放日期? | 我们将在 6 月 12 日重新开放。 | 文字记录将市长识别为发言者。如果承包商说同样的话,则无法确立市长的承诺。 |
10. 随时间的变化 | 5 月份修正案生效后适用什么通知期? | 通知期现为 45 天。 | 修正历史确立了这一变化于 5 月生效,取代了之前的 30 天规定。 |
11. 因果关系 | 西侧泵为什么停止工作? | 该故障导致了停机。 | 调查将“该故障”确定为西侧泵中卡住的轴承,并将其与不相关的进气口阻塞区分开来。 |
12. 比喻或跨语言含义 | 比喻: 诗中的“冬日房间”象征着什么? 跨语言: 法语说明指示技术人员移除哪个组件? | 比喻: 它代表流亡,而不是一个物理房间。 跨语言: Retirez le capot.(移除盖子。) | 比喻: 评论将“它”确定为诗中反复出现的“冬日房间”意象。 跨语言: 指南的词汇表明确指出,“capot”指的是保护性马达罩,而不是运输盖。 |
文档和查询
正在测试的查询、文档和能力受 turbopuffer 客户对话的启发。
举个例子,考虑物业管理公司的搜索需求。这些公司有数百个甚至数千个租赁协议,它们仅在租户姓名、日期和其他一些关键细节上有所不同。针对该数据集的一个常见查询可能是“5 park avenue 的租赁什么时候到期,当前租金是多少?”。租赁协议也很长,可以确认你已检索到正确文档的关键消歧组件(如日期、地址、租户姓名等)通常可以距离包含每月租金额的关键答案句子非常遥远。在实践中,诸如“每月租金为 $X,XXX。”之类相同的句子可能会出现在语料库的许多文档中。
一个好的上下文嵌入模型应该使用整个文档的上下文来识别正确的文档,并检索答案及其支撑句子。这可以让用户或搜索智能体快速验证答案并确认它来自正确的文档。
答案和证据标签
对于每个查询,我们在目标文档中标记“答案”和“证据”句子。如果模型检索到一个答案句子以及来自每个证据组的至少一个句子,则它通过了我们的“阅读器充分性”测试。这些句子共同为读者提供了足够的上下文,以便用佐证证据验证答案。
当上下文嵌入模型在这方面表现出色时,它们可以显着减少搜索智能体需要审查的词元数量,并使个人能够更容易地快速确认他们已经找到了原始查询的正确答案,而不必阅读整个文档。
必须恢复每个证据组,但组内的任何一个替代方案都足以将其恢复。在这类长文档的多个地方看到陈述相同的事实是很常见的。从每个证据组中检索仅仅一个句子即满足阅读器充分性标准,因此将被接受为完美的证据召回。
指标
每个文档都被分块为句子,并且所有模型都使用相同的边界。为非上下文嵌入模型测试了两种条件:一种是将每个句子独立嵌入,另一种是将整个文档作为一个单独的块进行嵌入。
我们使用句子级条件来测量答案召回率和证据召回率。它测试了当每个句子在无法访问周围文档的情况下进行嵌入时,非上下文模型是否能够识别正确的答案和支撑证据。这刻意具有挑战性。在许多查询中,单独的答案句子缺乏将其与语料库中其他类似句子区分开来所需的细节。
我们使用文档级条件作为文档召回基线。它测试了细粒度句子嵌入是否提供了足够的检索优势,以证明相对于每个文档存储一个向量而言其额外的存储成本是合理的。句子级索引产生的向量明显多于文档级索引,因此它应该优于每个文档一个向量的基线,以证明该成本是值得的。
所有评估都对全部 2,458,072 个块使用详尽的排名。因此,模型之间的差异反映了表征,而不是索引配置。我们专注于三个关键指标:
Document@K 的定义为:
其中 是 中排名最高的文档。
Answer@K 的定义为:
其中 是整个语料库中排名前 的文本块, 是被接受的答案文本块集合。
Evidence Recall@K 在 内的测量方式如下:按相似度对 的句子进行排名,移除排名最高的答案句子,并设 为剩余的前 个。对于证据组 ,组 在某个替代方案 满足 时被恢复,并且
Document@K 询问上下文感知是否能让正确的文档击败与其共享词汇的同胞文档和干扰项。
Answer@K 询问答案句子本身是否排在顶端块之中。
Evidence Recall@K 询问在排除最高排名的答案块后,在正确文档的前 K 个块中恢复了多少支撑上下文。移除答案可以防止证据召回重复计算 Answer@K 已经测量的部分,并为支撑上下文留出所有 个槽位。要求黄金文档在检索到的前 10 个文档中,意味着没有任何模型会为其不会浮现的文档获得证据积分。我们还报告了 All-Evidence@K,即每个组都得到恢复的查询的比例。
这些指标共同剖析了上下文嵌入模型面临的挑战:找到正确的文档,找到正确的答案,并恢复显示答案为什么正确的最小上下文。
图 3 用物业管理的例子说明了这些指标。
评估结果
我们从四个方面评估我们的模型与上下文和非上下文嵌入模型的对比。
我们的上下文基线是 pplx-embed-context-v1-4B 和 voyage-context-4。我们的非上下文基线是独立编码块的 voyage-4-large 和 NVIDIA 的 Nemotron-3-Embed-8B-BF16。基线集因实验而异,如每个图所示。
我们从直接测试激发这项工作的能力的 context-bench 开始,然后报告关于 ConTEB(上下文嵌入的标准公开基准)的结果。为了检查这些收益是否以牺牲通用检索质量为代价,我们还评估了我们从公共数据集构建的特定领域文档和块检索基准。最后,我们检查了部署的两个实际属性:检索质量与每个向量的存储成本,以及对索引时使用的块大小的敏感度。所有评估都在单次传递中对最多 32,768 个词元的文档进行编码。
Context-bench
正如引言中的图 1 所示,我们的预览版在所有报告的截断值下的 Answer@K 和 Evidence Recall@K 以及 All-Evidence@10 上均处于领先地位。在 K = 10 时,它实现了 45.5% 的答案召回率、40.6% 的证据召回率和 31.1% 的全证据召回率。它在 Document@1 和 Document@10 上也处于领先地位,分别达到 15.2% 和 61.6%。在 K = 10 时,我们的预览版在答案召回率上比 voyage-context-4 高出 14.4 个百分点,在证据召回率上高出 5.0 个百分点。
ConTEB
我们的预览模型在图 4 所示的 ConTEB 上的模型中实现了最高的平均 nDCG@10。它并非在每个任务上都领先:pplx-context-v1-4B 在 NarrativeQA 上得分更高,而 Nemotron-3-8B 在 COVID-QA 上得分最高。正如主要作者在 ConTEB 论文中所指出的那样,COVID-QA 主要包括高度提取式的查询-块配对,可以通过对医学技术术语进行简单的表面词汇匹配来满足。因此,上下文理解对该任务的用处较小,并且非上下文模型通常优于上下文模型。
跨领域的通用检索质量
除了为上下文嵌入设计的基准之外,我们还评估了我们模型的特定领域性能。
我们的查询到块 (Q2C) 套件使用 MTEB 任务(如 LegalBench 和 FinanceBench)以及我们从公共数据集策划的其他检索任务。在每个相关文档中,如果任务提供了一个确切的答案跨度,则将块标记为相关,否则通过 LLM 判断其与查询的相关性来标记。查询到文档 (Q2D) 套件使用相同的任务,并对是否检索到相关文档进行评分。
我们的模型在图 5 中的块检索上实现了最高平均分,并在法律、技术和健康领域处于领先地位。它并非在每个领域都领先:voyage-context-4 在金融和多语言检索中得分更高,而 Nemotron-3-8B 在对话检索中得分最高。在图 6 的文档检索中,我们的模型的平均得分略低于 voyage-context-4,同时在技术领域处于领先地位。pplx-context-v1-4B 基线的两套套件的平均得分较低,这与它仅在 ConTEB 训练集上进行过训练这一事实相符,表明与一个基准的黄金块绑定的监督很难迁移到其他领域。
检索质量和存储成本
上下文嵌入模型每个块产生一个向量,因此使用我们的模型构建的索引包含与具有相同分块策略的传统块级索引完全相同数量的向量。上下文感知改变了每个向量编码的内容,而不是存储多少向量。因此,存储占用的空间由每个向量的大小决定。该模型提供了两种减少存储的方法:将嵌入从 2048 维截断到 1024 维,以及将其量化为 int8。
图 7 显示了检索质量与向量存储之间的良好权衡。在 1024 维下,我们的 int8 嵌入每个向量使用 1 KB,同时略微超过了 float32 中 2048 维的 voyage-context-4 的块检索得分(每个向量使用 8 KB)。将我们的嵌入大小增加到 2048 维可以在每个向量 2 KB 的情况下进一步提高检索质量。这些存储数字仅指向量本身,而不指索引的其余部分。
块大小敏感度
图 8 显示随着块大小从 64 个词元增加到 512 个词元,检索质量只有适度的变化:平均得分从 81.0% 下降到 79.9%,降幅为 1.1 个百分点。这表明该模型在测试的块大小范围内保持有效,为索引管道在文档分割方式上提供了灵活性。
发布
turbopuffer 会对 context-bench 的完整语料库、查询和标签保密,并报告提交模型的评估结果。这种公开基准测试会引来针对其查询和文档的直接训练,这会逐渐使其饱和,并削弱其随时间追踪进展的价值。如果您希望您的模型在该基准测试上进行评估,请通过 contextbench@turbopuffer.com 联系 turbopuffer。
我们的模型的预览版可在 Hugging Face 上获取,本文中的所有结果均针对此预览版报告。我们正致力于通过 Perplexity API 提供该模型,并与 turbopuffer 一起进一步改进对长文档的检索。
引用
@online{perplexity2026ContextualEmbeddingBeyondTheGoldPassage,
author = {{Perplexity} and Sarah Eslami and William Barber and Markus Krimmel and Antoine Chaffin and Bo Wang and Louis Milliken and Jarrod Bryan and Claire Beamer and Jeremy Yang},
title = {{Contextual embedding beyond the gold passage}},
date = {2026-09-30},
url = {https://perplexity.coolkeypoint.com/hub/blog/contextual-embedding-beyond-the-gold-passage}
}