用于更好片段的查询感知上下文压缩

每一份答案都始于证据。在搜索系统中，此类证据通常来自文档：标题、摘要、片段以及作为上下文传递给答案模型或代理的摘录。

这些原始上下文包含杂质。例如，一个网页可能包含用户请求所需的信息，但也可能包含干扰项。这些干扰项可能出现在正文主体和辅助元素中，如导航文本元素、不相关的广告、元数据等。将这些干扰项传递给下游代理会引发三个问题。

首先，它会影响准确性。即使是最强大的模型也具有有限的容量。大量无关信息的涌入会浪费模型容量，导致“上下文腐烂”，进而损害模型响应实际用户请求的能力。结果就是，最终生成的回复更容易遗漏关键事实、过分强调低质量信息，或生成难以在原始来源中找到依据的主张。

其次，它会增加延迟。更长的上下文意味着下游模型需要处理更多的标记，特别是当查询需要来自多个候选页面的证据时。尽管部分延迟成本是在预填充阶段产生的，但更显著的成本出现在推理阶段，因为模型需要更多推理标记来处理无关的上下文。

第三，它会增加成本。传递给模型的每一个不必要的标记都会增加响应用户请求的成本，因为随着上下文噪音的增加，输入标记和推理标记的使用量都会随之增加。干扰项不仅降低了质量，最终还会迫使您为这种低质量的服务支付更高的费用。

放大

为了同时提升 Perplexity 各项应用及 API 平台 的准确性、速度和成本效益，我们投入了大量资源来提高上下文精度。实现这一目标的方法之一是改进我们的片段生成算法。我们将片段生成视为一个上下文压缩问题。寻找特定信息的模型无法从文档的通用摘要或节选中获益。相反，它们需要最小、最精确提取的原始信息片段来响应用户的请求。其他一切都可以且必须被移除。

因此，一个好的片段应该做到以下三点：

通过呈现 grounding 模型回复所需的精确证据来提升准确性。

通过在调用 LLM 之前移除不相关的上下文来减少延迟和成本。

通过保留引文的保真度和原始来源的措辞，确保可追溯性。

本月，我们在我们的应用程序和 API 平台 中部署了一个全新的、最先进的片段生成器。该模块的核心是一个查询感知上下文压缩模型，它能为每个查询和候选结果决定应保留的片段子集。本文介绍了我们构建和训练该模型的方法，旨在在此关键任务上实现一流的性能。

作为查询感知压缩的片段

首要任务是定义任务本身。我们希望该模型做什么，以及应该如何定义输入和输出模式？

片段方法分为两大类。第一类是基于选择的方法：找到一个相关的窗口、块、句子或段落，并将其传递到下游。第二类是基于生成的方法：让模型根据页面编写一个以查询为中心的摘要。

我们对准确性、延迟和成本的关注使设计选择变得显而易见。我们可以排除生成法，因为为每个页面创建新的摘要会损害这三个方面的性能。总结法并不适合我们所关心的证据层。它可能会改写原始来源，从而增加引文对齐的难度。它还可能引入页面中不存在的措辞，当片段被用作证据而非最终答案时，这存在风险。涉及的延迟和成本使生成法更加令人难以接受。

相反，我们将我们的任务定义为查询感知提取压缩：将检索到的上下文中不仅有用的部分与干扰部分分离。具体而言，我们的模型必须接受一个查询和候选结果，并决定保留哪些片段（那些最能支持查询的片段），以及丢弃哪些（其余部分）。模型输出保留了原始文本而不是重写它。这使得结果更容易引用、更容易验证，且传递到下游的成本更低。

例如，考虑此查询和检索结果：

放大

一个合理的模型输出是选择加粗的句子：“在 Comet 中，助手可以...”。

我们的方法遵循与先前上下文压缩工作（如 FliCo、Provence 和 LooComp）相同的总体思路，并针对生产搜索系统中的片段生成进行了调整。重要的是，该模型在我们原始检索阶段之后作为一个精度阶段运行。正如我们在之前的 Perplexity 研究文章 Introducing the Perplexity Search API 中所讨论的那样，我们构建检索系统以在子文档或片段级别原生运行，这已经使我们能够很好地平衡精度和召回率。引入查询感知上下文压缩模型将精度-召回率帕累托前沿进一步向外推移。

构建和训练上下文压缩模型

我们在开发模型时考虑了三个主要因素：对查询和上下文的联合理解、细粒度的句子级选择，以及能够适应极其严格的延迟预算的效率。

模型架构

我们使用 pplx-diffusion 模型作为骨干网络。这是 pplx-embed-v1 背后的同一模型系列，我们之前的学术工作 Diffusion-Pretrained Dense and Contextual Embeddings 以及我们的生产基准测试都证实它是查询-上下文对的强力双向编码器。该模型系列的关键特性之一是双向上下文：每个标记表示在模型决定保留什么之前，都可以关注完整的查询和完整的候选上下文。

在此骨干网络之上，我们训练了一个轻量级压缩头，用于预测应保留上下文的哪些部分。由于不涉及生成，这些预测是在整个上下文中并行完成的。在服务时，片段引擎在句子级别聚合这些预测，应用阈值，并将结果修剪到请求的标记预算内。

监督流程

训练此压缩器需要正确的粒度监督。文档级的相关性标签显然不适合我们的提取压缩任务。为了生成足够细粒度的数据用于监督学习，我们构建了一个跨度标注流程，标记查询相关的证据跨度，以及应移除的干扰跨度。

我们的流程使用了 LLM-as-a-judge 设置。给定用户查询和带有链接、标题和摘要的候选网页，评判模型首先执行查询理解，分析查询并生成一系列可能的用户意图。基于这些意图，评判模型处理候选上下文并返回从文本中逐字复制的跨度，并为每个跨度分类以便于检查标签。

然后我们将返回的跨度匹配回原始文本。不出所料，大多数评判模型的输出已经是精确副本：朴素字符串匹配恢复了 98% 的跨度。添加一个简单的基于正则表达式的匹配步骤将跨度恢复率提升到了 100%。这为我们提供了可靠、细粒度的跨度，可以转换为标记级的保留/丢弃监督。

我们使用一个小型的策划数据集以及手动标记的跨度评估了该监督流程，比较了较小的评判模型、不同的提示词和不同的步骤配置。表现最好的设置是一个两阶段流程：先进行查询理解，然后进行分类跨度标注。我们还通过下游的可验证评估（如 BrowseComp 和 SimpleQA）验证了提取的跨度集，其中仅使用保留的证据跨度保持了很高的分数，同时显著减少了输入标记。

使用此流程，我们标注了 75 万对查询-文档对，并使用生成的跨度通过二元交叉熵训练压缩头。此过程允许我们的查询感知压缩模型在保留原始文本的同时，移除不太可能帮助下游模型服务于用户请求的上下文。

确保实时延迟

上下文压缩位于下游模型之前，使其成为阻塞操作。此外，每次压缩都与查询相关。因此，在线路径必须在严格的延迟范围内为每个候选文档评估查询-上下文对。缓慢的压缩模型适得其反，因为更高精度带来的延迟优势被压缩延迟本身抵消了。同时，智能程度较低的压缩模型在切割和保留内容时会做出更差的决定。

实际问题是在压缩质量开始下降之前，我们可以安全地移除多少模型容量。我们比较了完整的 28 层 pplx-diffusion 骨干网络与通过层剪枝产生并针对搜索路径优化的 11 层和 17 层变体。对于每一个，我们都扫描压缩阈值并测量两个量：每个查询发送到下游的平均上下文标记数量，以及压缩后保留的有益证据比例。

图 2 显示了质量-效率前沿。当模型向左上方移动时，表现更好：更少的下游标记，同时保留更多有用的证据。28 层模型提供了质量参考。11 层模型展示了过于激进地压缩模型的风险。剪枝后的 17 层模型代表了一个中间地带：它在饱和状态下紧跟 28 层模型，但在大多数生产流量运行的曲线陡峭部分，出现了一个小的差距。

为了缩小该差距，我们采用了标记级知识蒸馏。我们的方法是常规的：我们通过教师模型预测上的软交叉熵项来增强标准损失，并由蒸馏系数进行加权。这足以使学生模型达到同等水平，使我们能够在生产中完全切换到蒸馏后的 17 层模型。这种新的生产模型使推理延迟降低了 35-40%，总 GPU 计算量降低了 40-45%，且相对于 28 层教师模型质量没有下降。生产延迟低于 20 毫秒（p99）：小到足以添加到服务路径，同时大大减少了传递给答案模型的总标记数量。

放大

质量与标记效率

我们使用 Perplexity 的 Agent API 作为测试平台来分析上下文压缩的有效性。我们评估了三种 Agent API 预设：

一种“低”上下文预设，将每个结果集的标记预算限制为 1000 个标记。

一种“中”上下文预设，将每个结果集的标记预算限制为 4000 个标记。

一种“高”上下文预设，将每个结果集的标记预算限制为 10000 个标记。

标准设置、无压缩设置和压缩设置都配置为遵循这些标记预算。

智能体多步搜索 (BrowseComp)

我们首先检查压缩对 BrowseComp 基准测试上智能体多步搜索工作流的影响。我们使用我们的开源 search_evals 工具进行此评估。所有运行的评分都是相同的，使用 OpenAI 的规范 BrowseComp LLM judge prompt。

我们感兴趣的两个维度是基准准确性和标记使用情况。重要的是，我们在查询级别而不是单个步骤级别测量标记使用情况，以便测量在请求生命周期中产生的实际标记负载。图 3 显示了“分数-标记”前沿，即准确性得分与标记使用情况的对比。

放大

压缩在各个方面都带来了新的帕累托前沿。对于每个设置，引入压缩可将查询级别的标记使用量减少 10% 到 70%，准确性提升 4 到 4.81 个百分点。引入压缩使得即使是我们的“低”预设也能超越无压缩的“高”预设，同时将标记使用量减少了三倍以上。

我们观察到，正如我们预期的那样，通过压缩，“高”预设比“中”预设产生了更高的准确性。然而，有趣的是，它是在更低的标记使用量下实现的。这揭示了压缩的一个微妙但重要的效果：通过压缩，即使增加每步上下文大小也可能使模型以更少的步骤获得正确结果。探索这种非单调性是未来工作的有希望的方向。

SimpleQA：单步事实性

BrowseComp 强调多步研究，但许多生产工作流涉及单步事实查找。为了确定压缩在单步场景下是否也有帮助，我们还检查了 SimpleQA 上的性能，这是一个包含 4,326 个问题的基准测试，这些问题需在单次搜索步骤中回答，而不是智能体循环。

如前所述，我们使用规范的评判模型提示词绘制了准确性与每个任务平均总标记数的关系图。图 4 显示了此单步设置中的分数-标记前沿。尽管单步设置中的效果幅度更压缩，但我们再次观察到，压缩同时改善了所有预设的准确性和效率，从而引入了新的帕累托前沿。启用压缩后，中等预设实现了 95% 的准确性，每个文档平均仅需 200 个标记。鉴于平均文档长度超过 10,000 个标记，这代表了在压缩比超过 50 的情况下前沿级别的性能。

放大

片段中最终包含了什么？

4.1 和 4.2 节中的下游收益是端到端的。为了理解压缩如何改变单个片段，我们进行了单独的评估，使用 LLM 评判模型将每个检索到的片段的每个标记分类为六个类别之一：

重要：回答用户查询所必需的证据。

偏题：可能对其他用途有用但与手头查询无关的信息。

广告：分散用户查询答案注意力的无关广告。

元数据：关于文档内容的元数据。

UI 和导航：用于前端显示和导航的元素。

重复：先前已包含信息的重复。

我们的评估运行在来自验证集的 1,000 个混合域查询上，比较了生产堆栈与禁用了压缩的完全相同的基线。如图 5 所示，压缩使每个片段的重要标记比例比无压缩基线平均增加了 63%。我们观察到无关标记相应减少了 29%，其中 UI/导航 (-58%)、元数据 (-46%) 和广告 (-43%) 的下降尤为陡峭。这些结果证实了上述质量-效率改进的机制：压缩通过大幅提高每个片段的信噪比，改善了两个维度的性能。

放大

图 6 说明了单个查询的这种变化。对于查询“6 天大新生儿每次喂奶的摄奶量”，我们展示了未压缩基线片段和压缩片段。压缩消除了非重要内容类别，仅保留了与新生儿喂养相关的信息。重要的是，压缩成功消除了那些对于页面来说可能通常属于主题内，但对于这个特定关注新生儿的查询来说属于偏题的内容。

放大

结论

AI 系统依赖高信号信息来智能且高效地服务用户请求。必须尽可能精准地呈现这些信息，以最大化与每个请求的相关性。我们新的查询感知压缩模型通过最大化每个片段的专题证据并积极剔除无关干扰项，精确地做到了这一点。

通过在我们的搜索堆栈中部署这些新模型，我们能够为那些依赖我们产品和 API 的用户提供更快、更好的响应。我们的方法创建了一个简单的控制平面，允许我们的系统和 API 客户调整压缩程度，以平衡召回率、延迟和成本。

上下文管理是一个发展中的领域，在优化当今前沿智能系统内使用的每个标记的价值方面，还有很多工作要做。我们正积极通过模型改进和系统架构，使我们的上下文管理技术更上一层楼，从而更广泛地利用这些模型。

参考文献

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Accepted to ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, and D. Kim. LooComp: Leverage Leave-One-Out Strategy to Encoder-only Transformer for Efficient Query-Aware Context Compression, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, and D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, and G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

引用

@online{perplexity2026QueryAwareContextCompressionForBetterSnippets,
  author = {{Perplexity} and Bo Wang and Hao Zhang and Ismail Gadzhiev and Kirill Priemko and Markus Krimmel and Nandor Licker and Vitalii Polshkov and Sarah Eslami and Louis Milliken and Maksim Gaiduk and Nikita Kireev and Jerry Ma},
  title = {{Query-aware context compression for better snippets}},
  date = {2026-05-14},
  url = {https://www.perplexity.ai/hub/blog/query-aware-context-compression-for-better-snippets}
}