Perplexity Decider V1.2决策模型上线AI Gateway

AI 应用正从单纯的"生成内容"走向"做出判断"。Perplexity 最新发布的 Decider V1.2 系列模型，正是瞄准了后一种需求。据 AI Gateway 官方公告，Decider V1.2 27B 与 Decider Flash V1.2 4B 两款多模态决策模型已正式上线，开发者可以用同一个 API 密钥完成内容分类、请求路由和文本评分等任务。

决策模型和生成模型有什么不同

传统大模型输出的是自由文本，你需要自己解析结果、判断对错、再写逻辑分支。Decider 系列换了一个思路：它不负责"写"，只负责"判断"，并且以概率的形式给出答案。

开发者用类型化问题（typed questions）提问，模型返回概率值。Boolean 问题返回"是"的可能性，Choice 问题从你预设的类别中选一个，Score 问题则按照有序评分标准给内容打分。应用拿到这些结果后，就可以决定把工单路由到哪个队列、标记一件受损商品，或者把拿不准的判断转交给人工审核。

这种做法把"分类决策"从应用代码里抽离出来，交给模型处理。对于需要处理大量非结构化输入（文本、结构化记录、图片）的团队来说，省去了维护一套规则引擎的成本。

类型化问题（Typed Questions） 是 Decider 的核心交互方式。与传统的自由文本提示词不同，类型化问题要求开发者在调用时显式声明期望的答案结构：Boolean 问题返回一个 0 到 1 之间的概率值，表示该判断为"是"的置信度；Choice 问题要求提供一组预定义类别，模型输出各类别的概率分布；Score 问题则需要给出一套有序的评分标准（例如 1-5 分），模型返回各分值的概率。这种约束机制从根本上消除了输出格式的歧义——应用层不需要正则解析或二次校验，直接读取概率值即可。同时，概率而非硬性布尔值的输出保留了不确定性信息，开发者可以设置置信度阈值，把低置信度的判断自动转交给人工处理。

两个版本，两种场景

Decider V1.2 提供两个规格，针对不同的使用场景。

Decider V1.2 27B（模型标识 perplexity/pplx-decider-v1.2）是较大的版本，适合需要细致判断和复杂评分标准的任务。参数量更大意味着它在模糊边界、多重条件的判断上表现更稳。

Decider Flash V1.2 4B（模型标识 perplexity/pplx-decider-flash-v1.2）是较小的版本，面向高并发的标注、过滤和路由任务。当判断标准足够清晰时，用 Flash 版本可以显著降低推理成本。

这种"大模型做难判断、小模型做批量处理"的分层策略，在实际工程中比单一模型更实用。很多团队的真实需求并不是所有请求都需要深度推理，大量简单分类完全可以用小模型消化。

一次请求，多个问题

Decider 的一个设计细节值得注意：多个问题可以共享同一次输入。也就是说，你可以针对一条输入同时问"是否报告了损坏""严重程度如何""应该路由到哪个部门"，模型在一次请求里返回全部答案。

官方给出的示例用一条配送报告来演示：输入"平板电脑到货时屏幕碎裂，无法开机"，然后通过 Boolean 问题询问"这份报告是否涉及损坏配送"。代码层面通过 AI SDK 的 experimental_decide 接口调用，返回的是概率值而非布尔值。

import { experimental_decide as decide } from 'ai';

const result = await decide({
  model: 'perplexity/pplx-decider-v1.2',
  state: 'The tablet arrived with a shattered display and will not turn on.',
  questions: {
    damaged: {
      type: 'boolean',
      instructions: 'Does this report a damaged delivery?',
    },
  },
});

console.log(result.answers.damaged);

对于图片输入，需要把 base64 编码的 image_url 对象嵌入 JSON 的 state 字段中，通过 AI SDK 或 TypeSafe 兼容 API 提交。这意味着模型不仅能判断文本，还能对图片内容做出分类决策，比如识别商品图片是否显示损坏。

experimental_decide 接口 是 Vercel AI SDK 中为决策模型提供的实验性调用入口。与标准的 generateText 或 generateObject 不同，它的入参设计围绕"一次输入、多个问题"展开：state 字段承载待判断的原始输入（可以是纯文本，也可以是嵌入 base64 image_url 对象的 JSON），questions 字段则是一个键值对集合，每个键对应一个问题名称，值中声明问题类型和判断指令。返回值中的 answers 对象按问题名称索引，每个答案都包含概率信息。由于该接口仍标记为 experimental，API 签名可能在后续版本中调整，生产环境使用时建议锁定 SDK 版本并关注迁移公告。

三种调用方式，覆盖不同技术栈

Decider V1.2 提供了三种接入路径：AI SDK、Decisions API，以及 TypeSafe 兼容 API。

AI SDK 适合已经在用 Vercel AI 工具链的前端或全栈项目，调用方式与现有的模型调用保持一致。Decisions API 是更底层的 HTTP 接口，适合需要精细控制请求格式的场景。TypeSafe 兼容 API 则面向对类型安全有要求的团队。

三种方式的共存降低了接入门槛——你不需要为了用决策模型而重构现有的技术栈。

BYOK（Bring Your Own Key，自带密钥） 是指开发者使用自己在模型提供商处申请的 API 密钥，而非通过平台方中转调用。在 AI Gateway 的场景下，BYOK 意味着推理请求仍然经过 Gateway 的路由和日志层，但计费直接发生在开发者与提供商之间。Decider V1.2 明确支持这种模式且不加收平台费，这对已经与特定提供商有合同或折扣的企业用户尤为重要——他们可以在享受统一网关的可观测性和路由能力的同时，保留原有的商务条款。对于尚未与提供商建立直接关系的团队，则可以使用 Gateway 的默认计费通道，按提供商公开定价付费。

成本与可观测性

AI Gateway 在这个产品上的一个明确卖点是计费透明。推理按提供商定价收费，不加价、不收平台费。即使用户通过 BYOK（自带密钥）方式接入自己的提供商凭证，也同样适用这一规则。

决策请求会被记录在请求日志中，并纳入支出预算的统计范围。对于需要控制 AI 成本的团队来说，把决策调用和生成调用放在同一个面板里监控，比分散在多个平台要省事得多。

开发者可以在模型 playground 中直接体验 Decider V1.2 27B 和 Decider Flash V1.2 4B，也可以浏览决策模型目录了解完整选项。

这类模型解决的是什么问题

把 Decider 放到更大的背景里看，它回应的是一个实际痛点：很多 AI 应用的瓶颈不在生成质量，而在判断的一致性。用提示词让生成模型"顺便判断一下"，结果往往不稳定，格式也难保证。Decider 用类型化问题强制约束输出结构，用概率值保留不确定性，让应用层可以根据置信度设置阈值。

这种"决策即服务"的思路是否能成为主流还有待观察，但对于工单路由、内容审核、质量评分这类高频判断场景，它提供了一个比"提示词工程 + 正则解析"更工程化的选择。