Decisions API正式可用：同样1分，为什么可能需要不同处置？

10月22日的官方公告宣布Decisions API进入正式可用阶段。10月24日核验的官方OpenAI文档介绍三类结果：predicate估计条件是否成立，choice选择预设类别，score按有序等级评分。当前指南列出的支持模型为gpt-6-luna。

本文不把公告中的速度或成本描述换算成你的项目收益。接入前仍需核对账号与支持范围、资料能否发送到该服务，以及本地预算。这里重点讨论输出含义，未调用真实模型或执行业务路由。

官方指南说明：score把每个等级的索引与对应概率相乘后求和，等级索引从0开始，因此结果可以落在两个等级之间。要从一组无序类别里选一个类别，应考虑choice；部门名称不能因为排在数组第2位就解释为比第1位更严重。

教学量表采用三个有序等级：低=0，表示仅文案或外观问题；中=1，表示单项功能受影响但有替代办法；高=2，表示任务被阻断且没有可用替代办法。实际标准应由业务负责人确认，本文不提供通用工单优先级政策。

A的权重集中在中等级，B则分在低和高两端。把它们都四舍五入为“中”，会丢失这项差异。这里的0.5是教学构造的权重；即便真实API返回相同数值，也不能未经业务验证就解释成“事故发生率50%”。

这不意味着A与B必须进入不同队列。某项经确认的业务规则可能允许相同处置；也可能要求对高等级仍有明显估计值、或分布分散的结果补证据。该判断需要任务样本与误分代价支持，不能由本文给出一个通用概率阈值。

将量表内容与顺序一起保存为版本，例如severity-v1。结果关联原始输入版本、实际模型、问题name、返回type、score及完整等级分布。记录实际返回的confidence，但不要自行把它与最高等级的probability或真实正确率画等号。

API参考还说明，同一请求中某题可以返回refusal，其他题仍有答案。例如“部门”有结果、“严重程度”拒绝时，保留前者，但不要把后者算成低等级。是否能仅根据部门先流转，取决于你的应用是否要求严重程度为必备信息。

不要从传输成功推断每题都形成了可用业务结论。反过来，一题拒绝也不要求抹掉其他题的合法结果。重试是否必要、重试哪题，应受任务期限与预算限制。

从“低、中、高”改为“低、中、较高、高”，等级索引与分布的解释需要重新核对。新旧结果不应只凭裸score直接用于趋势比较；只改显示标签却改变业务定义时，也需要新量表版本。

重排等级会改变索引与业务等级的对应关系，但标签和概率若正确一同重排，语义分布未必改变。本例A/B关于中点对称，即使翻转索引，均值仍可能是1；这不能证明其他输入下的新旧分数可比。实际配置应保持从低到高的有序关系，比较时先按等级定义对齐分布，再核对处置规则。部门等无序类别仍适合类别选择，不硬设严重度。

发布新的量表或路由规则时，先在同一组保留输入上分别得到新旧结果，核对真实处置差异；不能简单把历史score按比例缩放。已进入队列的任务继续引用其当时版本，是否改派由明确的业务变更流程决定。

演练记录应能还原“哪份输入、哪版量表、哪题结果、哪条处置规则”。A/B的数学关系可直接复算；真实模型的分布与实际误分情况需要另行采样验证。这个流程不承诺某个样本数、通过比例或业务收益。

适合从有明确等级、能观察最终处置、误分后可由负责人纠正的任务开始。先让新接口只提供建议，保存量表与分布，比较它对实际分流造成的差异。未经验证时，保留现有处理路径与核对负责人。

如果现有系统只存裸score，先补齐量表版本和结果状态，再谈是否更换模型或接口。产品的正式可用阶段不代替你的任务验收，也不自动授予业务执行权限。