Decisions API 的核心定位与三种决策类型

OpenAI 近期公开了 Decisions API，这被视为过去一个月最热门模型 Jev 的最大竞争对手。与 Chat Completions API 和 Responses API 核心能力是生成文字不同，Decisions API 的职责更为专一。它旨在解决模糊输入与确定性业务动作之间的判断层问题。在使用 Structured Outputs 时，模型可以按 JSON Schema 返回对象以抽取订单号、姓名等字段；而 Decisions API 则专注于处理答案范围明确的问题。它目前支持三种类型：Predicate（判断条件成立概率）、Choice（从固定选项中选择）和 Score（按有序等级打分）。例如，面对一条客服工单，可以同时询问应分给哪个部门（Choice）以及是否需要紧急处理（Predicate）。模型会返回各选项的概率及紧急处理的概率，从而让代码决定最终是否执行或交由人工复核。

“Decisions API 的职责更为专一，你先提供一份文字或图片，再提出几个答案范围明确的问题。”

这种设计使得语言和图片中难以写成固定规则的部分可以交给模型判断。它适合处理如权限检查、状态校验等场景，但最后是否执行仍由代码决定。与 Structured Outputs 和普通代码相比，Decisions API 解决的是三类特定问题：Structured Outputs 侧重结果符合对象结构；普通代码适合规则完全确定的场景（如金额超1000元审核）；而 Decisions API 只处理明确答案范围的问题，并同时返回概率。需要警惕的是，返回格式正确不代表判断正确，高置信度也不代表动作已获授权。

实际调用流程与工程实践建议

在实际集成中，Decisions API 使用独立的 POST 接口 /v1/decisions。当前负责判断的模型仅有 gpt-6-luna 一个。在工单示例中，我们将工单文字放入 input，并在 questions 中包含一个 Choice 类型问题（从 billing, technical, shipping, other 中选择）和一个 Predicate 类型问题（判断是否紧急）。这两个问题互不依赖，因此可在一次请求中共用同一份 input。但如果后一个问题必须知道前一个答案，则应拆分为两次请求。

“应用最好使用名字你的name来查找答案，不要只依赖数组的位置。”

响应中的 answers 按问题顺序返回。在实际工程中，建议将调用封装为轻量级的适配层，统一处理超时、错误、refusal 和返回类型。这样在 public beta 阶段，即使 OpenAI 接口调整，也无需改动所有业务流程。此外，每个问题可能单独返回 refusal，因此需逐个检查。这种软件工程实践能显著提升系统的健壮性。

模型路由的误区与图片输入能力澄清

很多场景提到 Decisions API 用于模型路由，但需特别澄清：OpenAI 并未在 API 层提供候选模型或自动读取用户可调用的模型。请求顶层的 model 仅表示由谁执行决策，目前只能使用 gpt-6-luna。若想做模型路由，候选模型及描述需由开发者提供，本质是借助 Decisions 搭建自己的路由器。这些描述仅影响选择结果，不改变模型真实能力。若描述过时或模糊，会导致错误。

“更稳妥的做法是先由普通的代码来按照账户权限、工具支持、预算数据政策等等过滤模型，然后让 Decisions 在 fast、balanced、deep 这类应用自行定义的路线上选择。”

另一个重要特性是图片输入。截至文档，Jev 的 state 仅接受文字或结构化数据，不支持原生图片输入。而 Decisions API 支持将文字和图片作为判断依据。纯文字直接放入 input；图文混合时，input 需改为只含 user 角色的消息 content，同时包含 input_text 和 input_image。图片必须编码为 base64 data URL，不支持公网 URL 或 file ID。一个请求最多可传 128张图片。演示中，通过 base64 命令读取破损音箱照片并嵌入请求体，成功判断了商品是否破损、损伤类型及程度。

基准测试数据与准确率分析

在演示中，对一张破损音箱图片提问三个问题：Predicate 判断已破损（概率100%）、Choice 判断主要损伤为裂纹（置信度100%）、Score 判断损伤程度中等（值98%）。随后对 12条工单进行验证。结果显示：部门分类 12 条全部正确；紧急度判断使用 0.5 作为阈值，12 条中正确了 11条。唯一误判是“年费被重复扣款”，人工标签为不紧急，API 返回概率 0.58。这说明重复扣款确实可能需要尽快处理。

“真正的问题是 0.5 并不是适合所有业务的默认值。”

此次测试中，12次请求延时在 174-557毫秒 之间，中位数 211毫秒。总消耗 input token 为 4270个，按当前价格估算成本约 $0.000427。需注意，这些数据仅验证接口和集成演示，不能作为准确率的基准。博主也未在相同条件下运行 Responses API，因此官方所称的“约快10倍”不能作为测试结论。评估准确率应使用自有带正确答案的测试集，计算各类别召回率、自动处理覆盖率和人工复核比例。

优化策略与适用场景判断

当前 gpt-6-luna 不支持 fine-tuning，公开文档也无 Decisions 专属训练接口。因此优化主要在应用层面：调整问题选项、描述、上下文或业务阈值，并使用同一份测试集做回归测试。这不同于微调模型权重。

判断任务是否适合 Decisions API，可从三方面考量： 1. 答案能否枚举。 2. 错误成本能否定义。 3. 拿到结果后是否有明确动作。

“模型给概率，代码来做最后的决定。”

内容分类、工单路由、风险评分、视觉质检等通常符合条件。而开放式写作（答案非有限集合）、长链规划（需生成步骤和工具处理中间结果）并不适合。规则完全确定的场景，普通代码可能更可靠。Decisions API 本身不复杂，真正需要长期维护的是问题、选项标注集、阈值和动作策略。它作为判断层，连接模糊输入与确定业务逻辑。

结论

OpenAI Decisions API 通过支持 Predicate、Choice 和 Score 三种决策类型，并引入图片输入能力，填补了从模糊非结构化数据到确定性业务动作之间的空白。它并非替代 Structured Outputs 或普通代码，而是针对答案范围明确、需概率辅助决策的场景。尽管官方声称性能优势，但实测数据仅证明其基础功能可行性及低延迟特性，准确率需依赖自有测试集验证。开发者应将其视为应用层的判断组件，结合代码逻辑处理阈值、路由和异常，而非依赖模型权重微调或全自动决策。