Perplexity Decider

我们正式发布 Decider v1.3 和 Decider Flash v1.3，它们是我们早期决策模型 v1、v1.1、v1.2 和 Flash v1.2 的后继版本。

Decider Flash v1.3 是从 Decider v1.3 蒸馏而来的较小模型。两个模型均以 Apache 许可证在 Hugging Face 上提供，也可通过 OpenRouter 和 Perplexity Decisions API 使用。

Perplexity Decider 的灵感源自 Jev，即 TypeSafe AI 的 System One Model。它支持使用有序或无序标签的二分类和多类别分类，返回的概率可供应用用于对输入进行分类、路由、排序和评估。

两个 v1.3 模型通过双向注意力、更精心整理的训练数据和改进的训练方案，在广泛的文本和视觉任务上提升了性能和稳健性。我们还推出了 locate，这是一项新功能，可在命名实体识别、个人信息识别和抽取式问答任务中高亮所选内容。

在本文中，我们将介绍如何训练和评估 Decider，并分享我们在 Perplexity 内部如何使用它。

什么是决策模型？

决策模型是一种通用分类器。你向它提供一个输入和一组问题，每个问题都附有可能的答案。对于每个问题，它会返回答案上的概率分布。它支持 3 种问题类型：

• 是 / 否：二元决策。
• 多项选择：自定义多类别标签。
• 评分：有序等级。

决策模型支持多种分类和评分任务：

• 评判输出：评估忠实度、质量和安全性。
• 路由：根据难度将请求分配给较小或较大的模型。
• 审核与安全：检测工具输出中的有害内容、网络钓鱼和提示词注入。
• 过滤和标记：整理大量内容集合。
• 检索与重排序：按相关性为搜索结果评分。

其中许多任务以前由 LLM 等生成式模型处理，尽管它们并不需要自由形式的文本生成。决策模型介于 LLM 与特定任务分类器之间。它们在单次前向传播中返回针对同一输入的多个问题的概率，避免了逐 token 生成答案，并在多个问题之间共享计算。与特定任务分类器不同，它们能够通过自然语言提示处理新任务，这种灵活性来自以共享问答格式在多样化任务上进行的训练。

训练

将生成式 LLM 转变为决策模型

我们通过改造强大的生成式 LLM 骨干模型来构建 Decider。为解释这一改造过程，我们首先介绍请求的表示方式。如下图所示，一个请求由共享上下文（状态）和若干问题组成。状态将被所有问题复用。

例如，给定一篇文档及其摘要，单个请求可以同时询问摘要是否忠实地反映了文档内容，以及它面向的是专家还是普通读者。在状态之后，每个问题块包含一个问题及其可能的答案，每个答案都分配有一个预定义的标签 token，如 A、B 或 C。特殊的 <|marker|> token 指示从何处读出模型的预测。在该位置，一个学习得到的线性输出层（即决策头）将隐藏状态映射为该问题各答案选项的分数，然后再将其转换为概率。

放大

我们用基础模型来初始化输出层（该层通常会对整个词表中的下一个 token 进行评分），并只保留与 A、B 或 C 等预定义选项 token 对应的行。随后，我们训练这个经过剪枝的层，将 <|marker|> 的隐藏状态转换为答案分数。这种方法覆盖了所有分类问题，因为它们都可以被表述为多项选择题。

在训练中，我们采用数百个涵盖多种任务（情感分析、自然语言推理、意图检测、实体匹配、内容审核、事实核查、评分等）的公开数据集，并将每个样本转换为上文所述的统一格式：一个状态、一个或多个问题、问题的选项以及一个目标。如果有黄金标签，目标可以是唯一正确的选项，也可以是选项上的概率分布。

在 v1.3 中，我们推出了 locate，它从状态中提取文本，而不是从预定义选项中进行选择。locate 问题描述要查找的内容，既可以使用简短标签（如“位置”），也可以使用指令（如“提取该职位所在的城市名称。”）。模型会返回状态中完全匹配的文本，以及其起始和结束字符位置。如果未识别到任何匹配项，则返回空列表。

放大

由于状态是共享的，单个请求可以针对同一输入同时提出 locate、分类和评分问题。例如，它可以询问某个职位是否要求高级别经验，同时提取所需技能。

双向注意力：让模型双向阅读

我们的模型以强大的预训练生成式骨干网络为起点，其因果注意力只允许每个 token 关注自身及其之前的 token。我们的消融研究表明，将骨干网络的全注意力层改为双向可以提升性能，因此我们采用这一设计，让每个 token 都能融合整个输入的上下文。

双向注意力带来了另一个设计选择：状态和问题应如何交互？我们考虑了三种注意力模式，它们对性能、答案稳定性和缓存复用有着不同的影响：

• 全部互见（v1.2）：状态和所有问题在完全双向注意力下一起处理。对状态的计算是共享的，但某个问题的答案可能会因同时提出的其他问题而改变。
• 隔离式问题（v1.3）：状态关注所有问题，而每个问题只关注状态及其自身的 token。问题之间仍可通过共享状态间接相互影响，但结果更加稳定。
• 完全可缓存：状态只对自身计算注意力，而每个问题对状态及其自身的 token 计算注意力。状态与问题无关，可在多个请求之间复用，从而利用提示缓存。我们默认不使用这种方式，因为让状态看到问题对若干任务非常重要，但只需少量微调即可将模型切换到这种模式。

鉴于其出色的性能和稳定性，我们最终选择了隔离式问题。

放大

训练方案

两种规模的模型均分三个阶段进行训练。我们首先在大型数据集上使用交叉熵训练基于 Qwen3.8-27B 的较大模型，然后将其蒸馏到较小的 Qwen3.5-4B 模型中。

第一阶段是通用训练，我们在大规模语料上对模型进行全量微调。在这一阶段，我们只接受能全面提升模型能力、且不针对任何特定基准的数据；因此，我们排除了所有基准的训练集划分。

在训练完这个通用模型后，我们使用 LoRA 进行更细粒度的第二阶段训练。此阶段使用的数据面向特定领域和任务。如果我们观察到收益有限，或在其他任务上出现某些退化，就会将数据放在第二阶段而非第一阶段加入。我们使用 LoRA，是为了避免与通用模型偏离过多，以免为了适配这些特定领域而损失性能。目标是在提升性能的同时保留骨干模型的通用知识。在将 LoRA 合并回基础模型时，我们还会使用一个权重，以更精确地控制偏移，并优先考虑留出集指标，而非任何领域内的收益。

最后，我们添加了一个视觉专用步骤。与第二阶段类似，视觉步骤被视为另一个细粒度专精步骤，使用一个 LoRA 适配器，并按一定权重合并回基础模型。某些视觉能力的提升可能会以牺牲文本性能为代价。由于我们观察到模型在文本上的使用量远多于视觉，因此我们优先考虑文本指标而非视觉指标。

在两个文本阶段中，我们都使用三次运行的平均权重，每次运行使用不同的随机种子。我们发现这能提升聚合模型的性能和稳健性。

获得最终的大模型后，我们对较小的模型采用同样的三阶段训练流程。在这里，大模型充当教师：其预测的输出分布取代黄金标签，较小的模型则通过训练来最小化其预测与教师预测之间的 KL 散度。在相同的训练数据上，这一蒸馏目标优于交叉熵。虽然交叉熵在有专门训练数据的基准测试上表现更好，但它在留出数据上的泛化能力较弱。我们推测，蒸馏能更好地迁移教师的输出分布，包括其对非黄金备选答案的置信度，而交叉熵则容易导致对特定基准训练分布的过拟合。因此，我们采用基于 KL 的蒸馏目标。

为减轻训练集与测试集之间的污染，我们会移除任何可能与我们所用评估存在重叠的训练样本。这一点很重要，因为某些公开训练数据集包含部分评估数据集的大量内容。我们还进行了广泛的偏差审计与消除，以确保我们的提升真实可靠，而不只是由习得的偏差所驱动。

新增信息抽取能力

locate 功能 可从文本中提取命名实体等信息，同时不会改变模型回答普通请求的方式。为此，我们引入了一个额外的训练阶段：为 Decider 添加一个新的特殊 token <|locate|>、一个跨度头（span head）和 LoRA 适配器。

<|locate|> 的嵌入由先前训练阶段学到的 <|marker|> 初始化。我们只训练这个新嵌入、跨度头和 LoRA 适配器，同时冻结原始骨干网络权重和决策头。每个请求的字段都有各自的 <|locate|> token。

跨度头（span head）将 <|locate|> 的表示与状态 token 的表示结合起来，对匹配跨度的起止位置以及哪些起止位置属于同一跨度进行评分。它还使用 <|locate|> token 的表示来预测这些分数的字段特定阈值。选中的跨度以原始文本中的字符位置形式返回。

我们使用改进的 InfoNCE 损失训练跨度头，使每个黄金跨度的分数都高于阈值，并使阈值高于所有其他跨度。该损失包含两项：第一项将正确跨度的分数推高到阈值和错误跨度之上；第二项将阈值推高到错误跨度的分数之上。没有答案的字段只计算第二项，从而让模型学会返回空列表。

我们在多种跨度抽取任务的混合数据上进行训练，包括命名实体识别、PII 检测和抽取式问答。我们让字段描述从简短标签到详细指令不等，使模型学会遵循请求，而不是记住一个固定的标签集。

Locate 教给模型的是一种结构上截然不同的任务，我们希望在添加这一能力的同时不丢失模型已有的优势。将 locate 适配器合并到骨干模型中会导致决策请求出现一定退化。为限制这种影响，我们正在开展多项研究，例如使用更多来自早期阶段的回放数据，以及引入辅助目标，使模型在决策请求上的输出接近原始模型。然而，我们发现合并目前仍无法做到无损，因此我们不合并适配器，仅在处理 locate 请求时激活它们。

评估

我们在来自 Hugging Face Decision Index、Vals AI 的 ClaimBench 以及 Artificial Analysis Decision Index 的外部基准上评估了 Decider v1.3 和 Decider Flash v1.3。

在这些评估中，我们的模型均表现出色。尽管这些排行榜包含非公开任务，但仍可能通过反复提交以及根据排行榜反馈进行迭代调优来刷分。为补充这些排行榜，我们还在一套内部评估集上评估模型，该评估集结合了非公开的生产任务和取自公开非基准数据集的留出评估。这些评估为超越公开基准的泛化能力提供了额外检验，帮助我们区分更广泛的改进与仅针对熟悉评估套件的提升。

我们在内部构建了一套包含超过 200 项任务的评测集，涵盖多个领域以及分类、评分、重排序和实体抽取等任务。为了如实评估 Decider 在真实场景中的表现，所有评测均以零样本方式进行，不做针对特定任务的微调，从而清楚地指明模型需要改进的方向。

查询分类

在 Perplexity，我们使用多头分类系统来处理每个用户查询。每个查询首先经过一个充当特征提取器的嵌入模型。生成的嵌入随后被输入多个独立的分类头，其中包括二分类器和多标签分类器。例如，其中一个分类头负责判断某个用户查询是否应触发网页搜索。

在 63 项由前沿 LLM 独立重新标注参考答案的分类任务中，Decider v1.3 的平均准确率达到 91.6%，比我们的生产分类器高 6.54 个百分点。Decider Flash v1.3 同样优于生产基线，而 Decider v1.3 则优于 Jev 1.14。

放大

特定领域分类

我们利用公开数据集构建了一套特定领域评测集，用于评估决策模型在七个领域的分类性能：声明核查（6 项任务）、医疗健康（7 项）、网络安全（8 项）、编程（16 项）、政务（7 项）、法律（9 项）和金融（9 项）。

例如，“判断一个 Python 程序的时间复杂度”，或“根据年度财务报告，判断一家公司的非限制性现金是否足以偿还未来十二个月内到期的债务本金”。Decider v1.3 在全部七个领域中均处于领先地位，在金融领域领先 Jev 1.14 多达 12.9 个百分点，在法律领域领先 9.3 个百分点。Decider Flash v1.3 在金融、编程和法律领域落后于 Jev 1.14，在其他领域表现相近。

放大

检索与重排序

搜索是 Perplexity 的核心。我们维护着一套广泛的检索任务，用于评估模型的重排序性能。对于每项任务，我们首先使用一组嵌入模型从每个语料库中检索出前 50 篇候选文档。然后，我们使用 Decider 对这些候选文档进行重排序，并将其性能与一个强大的重排序基线 Qwen3-Reranker-8B 进行比较。

我们在零样本、逐点（pointwise）设置下评估 Decider：使用模型独立地为每个查询–文档对直接评分，并按相关性对文档排序。在 72 项检索任务中，Decider v1.3 的平均 nDCG@10 达到 83.99，比 Qwen3-Reranker-8B 高 1.81 分，比 Jev 1.14 高 2.24 分。

在 BEIR 基准上，两个模型的 nDCG@10 分别比 Qwen3-Reranker-8B 高 8.78 和 7.05。与 Jev 1.14 相比，Decider v1.3 高 1.33 分，而 Flash 版本低 0.4 分。

放大

多语言分类

为了评估决策模型在英语之外的表现，我们构建了一个多语言分类基准，包含来自 8 个公开数据集的 19 项特定语言任务，共 46,484 个样本，涵盖八种语言：德语、西班牙语、法语、意大利语、俄语、日语、韩语和中文。该基准涵盖意图检测、主题分类、情感分析、自然语言推理、复述检测、冒犯性语言检测和语法可接受性判断。

我们报告每种语言内各任务的平均准确率，每项任务权重相同。Decider v1.3 在全部八种语言上均优于 Jev 1.14，Decider Flash v1.3 则在其中六种语言上优于 Jev 1.14；Decider v1.3 和 Decider Flash v1.3 的平均任务准确率分别为 88.16% 和 86.50%，而 Jev 1.14 为 85.41%。

放大

NER、PII 与抽取式问答

我们在 17 项域外任务上评估 locate 功能，测试其在不同领域、输入格式（文本、表格、结构化文档）和指令（简短标签、问题和详细描述）下的抽取能力。领域涵盖维基百科、科学论文、网络威胁报告、技术支持、隐私政策、简历和法律合同。请求范围从“人物”或“电子邮件地址”等简短标签名称，到关于表格或支持工单的问题，再到用于结构化抽取的详细字段描述，例如 NDA 的签约各方或发票上的总金额。

我们使用精确跨度 F1 评估 NER 和 PII，它要求预测的跨度与参考边界完全一致。抽取式问答使用字符级 F1，对重叠的答案文本给予部分得分；结构化抽取则使用字段准确率，即被正确抽取的字段所占比例。对于简历解析，我们取 NER 和 PII 精确跨度 F1 分数的平均值。

我们将自己的模型与不同规模的通用抽取模型进行比较：GLiNER large v2.5（0.5B）、Liquid d1（2B）和 Cloudflare 的 Clairic（未披露）。Decider v1.3 的平均得分达到 69.0（采用各任务的主要指标），Decider Flash v1.3 达到 63.6，而 Liquid d1 为 43.3，Clairic 为 41.5，GLiNER large v2.5 为 33.6。两个 Decider 模型在每个类别中均处于领先地位。

放大

图像分类

Decider 自 v1 起就原生支持视觉任务。为了评估其在文本之外的表现，我们构建了一个包含五项任务的基准套件，尤其侧重于文档分类，包括发票、信函和简历。该套件还涵盖卫星图像分类、纹理分类、宠物品种分类和动物计数。

Decider v1.3 在五项视觉任务上的平均准确率达到 76.99%，比 Jev 1.14 高 1.47 个百分点。Decider Flash v1.3 达到 72.77%，展示了较小模型同样具备视觉分类能力。

放大

真实场景中的决策请求

我们从 Perplexity Decision API 上线后前 18 天提交的请求中，抽样了一百万条经过去重和 PII 脱敏的请求。由于每个请求可以包含关于同一状态的多个问题，该样本共包含 2,318,887 个独立问题。所有请求均在获得用户明确许可后纳入研究。

生产环境中的请求没有真实标签，因此我们使用前沿 LLM 评判模型生成参考答案，并衡量每个模型与参考答案的一致性。我们还将这些请求分为 10 个任务类别，包括信息抽取、领域分类、情感分析、意图与路由、相关性排序、内容审核、质量与合规审查、实体匹配、业务分析，以及“其他”类别。这一细分展示了模型性能在不同真实用例中的差异。

任务分布并不均衡：信息抽取占 425,402 个问题，领域分类占 409,564 个，情感分析占 344,158 个。这三个类别合计占抽样问题的 50.8%。

Decider v1.3 与评判模型的一致性最高，达到 93.98%，而 Decider v1.2 为 93.68%，Jev 1.14 为 93.35%。Decider v1.3 与 Jev 1.14 在领域分类和情感分析上表现接近，差距分别为 0.34 和 0.07 个百分点。Jev 在相关性排序上领先 0.69 个百分点，而 Decider v1.3 在信息抽取（样本中最常见的任务）上领先 0.93 个百分点，在意图与路由上领先 1.21 个百分点。

放大

下图比较了运行同样一百万条生产请求所报告的成本。每个请求可以包含多个问题，因此这里的单位是请求，而非单个问题。

放大

稳健性

我们在 372 道多项选择题上评估了标签敏感性，每个模型发出 4,788 次请求。我们在保持每道题含义不变的前提下，调整选项顺序、将标签重新分配给不同的答案文本并重命名标签，然后检查模型的语义答案是否发生变化。翻转率越低，表示稳定性越高。

在每种变换下，Decider v1.3 仅在 0.27% 的问题上改变了答案，而 Jev 1.14 为 2.69%–4.84%。我们还重复输入完全相同的内容来衡量服务的波动性：Decider v1.3 没有出现任何变化，而 Jev 1.14 在 1.88% 的问题上发生了变化。

放大

我们如何使用 Decider

Decider 专为需要快速、结构化决策的工作流而打造。在本节中，我们将探讨如何利用它对我们的工作方式产生切实影响。以下是一些表现突出的用例。

自我改进的安全规则

在内部，我们已经在使用 Decider 改进我们的安全策略。

我们会记录智能体的活动，并执行一系列基于规则的检查，以识别任何有问题的行为。采用基于规则的方法，我们可以实时监控智能体，且增加的延迟可以忽略不计。在离线环境中，我们使用 Decider 查看这些已记录的智能体日志样本。如果没有标记出任何有问题的行为，Decider 会检查是否存在我们的规则集遗漏的情况；如果触发了警报，Decider 会检查这是否为误报。在上述任一情况下，凡是规则集判断出错的记录都会发送给一个智能体进行分诊，并由其提出规则修复方案，再交由安全团队成员审批。

在一天之内，Decider 读取了 7,000 个智能体会话中的 10 亿个 token，并发现了多处缺陷，促成了 14 项规则修复，其中 6 项在两天内获批并上线。在一周的日志上回放后，这些修复使我们最繁忙规则的触发量减少了 52%，而放宽后的规则多捕获了约 40% 确实值得调查的操作。

放大

监控 RL rollout

当我们使用强化学习对模型进行后训练时，终局奖励等聚合指标无法解释某个 rollout（即对任务的单次尝试）为何成功或失败。它可能因为工具服务或沙盒故障而被不公平地扣除奖励，也可能因为评估器忽略了无依据的声明（例如任何工具都未返回过的编造数值）而获得不应得的奖励。

我们使用 Decider 监控 rollout 中的这些情况。首先由代码识别 rollout 中值得仔细检查的部分：失败的工具调用及其前后的推理、运行无误的代码，或最终答案。随后，Decider 针对每个部分回答多项选择题，例如某一步中是哪个环节失败了（工具服务、外部网站、沙盒、harness 还是智能体自身的代码），以及智能体是否正确理解了结果。我们将关于某个部分的所有问题打包成一个请求，并存储概率而非结论，这样以后无需再次查询 Decider 即可调整阈值。该监控器只负责观察和诊断：它从不更改奖励，也不会停止运行。

放大

页面质量过滤

在抓取网页以建立索引并提供给用户时，许多页面质量过低，毫无用处。这包括反机器人拦截页、验证码（CAPTCHA）和错误页面，也包括虽然加载正常但不含任何有用信息的网页，例如垃圾内容、SEO 填充页面或仅含导航的页面。这些低质量页面需要被识别出来，并从我们的索引中过滤掉。

借助 Decider，我们可以在抓取网页的同时判断其质量。在同一次前向传播中，我们还会执行一系列其他分类任务，例如识别内容所属领域和目标受众，以及内容是否包含有害、非法或个人身份信息。与使用 LLM 评判模型相比，Decider 速度明显更快，成本也更低。

放大

除了这些内部用途，Decider 还适用于以下工作流。

视觉问答

由于 Decider 能够读取图像，它也可以充当视觉检查工具，审查网页或应用的样式更改并识别缺陷。它可以在更改上线前检查页面截图中是否存在文本被截断、元素重叠或布局错乱等问题，也可以标记出设计可能误导读者或违反品牌规范的图表。

放大

浏览器导航

智能体可以使用 Decider 处理大型任务中的细小决策。浏览器智能体可以在每一步发送截图，并获取有关页面状态以及每个可能操作预期结果的详细信息。

放大

规划研究任务

用户问题的复杂程度可能差异很大，找到答案所需的搜索深度也是如此。Decider 可以在搜索开始前对此进行估计，从而在简单问题上投入更少资源。

放大

快速入门

Decider 返回的是概率。合适的决策阈值取决于具体应用。标签频率以及误报和漏报的相对代价因用例而异。因此，我们建议用户在一个小型、有代表性的带标签开发集上调整阈值，而不是假设某个固定阈值能在各类任务中同样有效。

对于需要细致判断、详细评分标准以及出错代价高昂的工作流，我们推荐使用 Decider v1.3。对于以延迟和成本为主要约束的大规模路由、标注和过滤任务，请选择 Decider Flash v1.3。请使用来自您工作负载的代表性示例评估这两个模型，然后选择满足您质量、延迟和预算要求的模型。

两个模型均以 Apache 许可证在 Hugging Face 上提供可下载的权重，也可通过 OpenRouter 和 Perplexity Decisions API 使用。

引用

@online{perplexity2026PerplexityDecider,
  author = {{Perplexity} and Antoine Chaffin and Jonas Golde and Louis Milliken and Sarah Eslami and Markus Krimmel and Nandor Licker and Aleksandr Nikolenko and Ron Heichman and Bo Wang and Jarrod Bryan and Jeremy Yang and Denis Yarats},
  title = {{Perplexity Decider}},
  date = {2026-11-12},
  url = {https://www.perplexity.ai/hub/blog/perplexity-decider}
}