OpenAI Decisions API 开放后适合哪些结构化决策任务

我第一次认真看 Decisions API，是在一个“输入已经有了，但下一步总要先做判断”的场景里：工单要不要转人工、图片是否存在明显问题、请求应该进入哪个队列。这样的任务并不需要模型写一篇长答案，真正需要的是一个可以被程序直接消费的有限结果。

OpenAI 在 2026 年 10 月 22 日宣布 Decisions API 正式开放。它面向有边界的问题，接收文本、图片或原生 JSON，返回概率、固定选项或量表分数。换句话说，它适合把“判断”从一段自由文本里拿出来，变成业务代码可以路由和记录的结构化结果。

官方文档：https://developers.openai.com/api/docs/guides/decisions

判断一个任务是否适合 Decisions API，可以先问三件事：输入证据是否已经准备好，答案是否能限制在固定选项或有序量表内，结果是否会直接触发分类、路由、优先级或复核动作。三项大体都满足时，它通常比让通用模型生成一段文字更合适。

开放后它到底增加了什么选择

GA 版本仍然围绕一个很窄的核心：用问题约束模型输出类型。当前文档给出的请求由 model、input 和 questions 组成，接口是 POST /v1/decisions，目前使用 gpt-6-luna。

最适合的是分类和路由

如果业务动作本来就只有几条路，choice 是最自然的映射。例如把客户工单送到“售前”“售后”或“人工复核”，把一张凭证送进“自动处理”“补充材料”或“人工队列”，或者根据一段对话选择“继续回答”“澄清问题”“转人工”。这里的重点不是让模型写出理由，而是让应用得到一个稳定的下一站。

这类任务要先把选项定义好。选项应该是业务真正能执行的动作，不要把十几个近义标签全部塞进去，也不要让模型临时发明新标签。低置信度时保留人工复核或兜底队列，通常比强行选择一个看起来最像的选项更稳妥。

需要条件判断时用 predicate

predicate 适合把一个可以明确描述的条件转成概率，例如“这张图片里是否有明显破损”“这条内容是否与某个主题相关”“这张工单是否有重复扣款证据”。它不是法律结论，也不是事实真相机器；它只是基于当前输入给出一个可用于分流的概率。

因此，业务侧最好把阈值和复核路径一起设计：高概率进入自动处理，低概率进入另一条路径，中间区域交给人工。阈值应该由真实样本和误判成本决定，不能把某个示例里的 0.8 当成所有业务都通用的标准。

需要有序等级时用 score

score 适合有清楚顺序的量表，比如把问题严重度分为低、中、高，把内容风险分为 1 到 5 级，或者按照一份固定 rubric 给材料完整度打分。官方说明中，score 不是任意自然语言评价，而是对离散等级的概率做加权后得到的分数，所以等级定义必须先写清楚。

一个实用做法是把每个等级对应的行动写在旁边：低分继续自动流转，中间分补充信息，高分暂停并复核。这样分数才是业务信号，而不是报表里一个没人使用的数字。

文本、图片和原生 JSON 都能作为证据

当前文档把输入分成共享证据和问题。共享证据可以是文字，也可以是消息数组；在用户消息中还可以放 input_image 和 input_json。这意味着订单、工单、图片和对话上下文可以先整理成同一份证据，再让多个受限问题分别判断。

下面是一个最小的“工单是否应该进入人工复核”示例。JSON 保持严格有效，字段含义直接写在代码块后；命令注释只说明请求用途，不把示例当作已经执行过的结果。

# 用固定选项把工单分到自动处理、补充材料或人工复核
curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @request.json

{
  "model": "gpt-6-luna",
  "input": [
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "根据工单和订单证据选择处理路径。"
        },
        {
          "type": "input_json",
          "data": {
            "ticket": {"body": "同一订单出现两笔相同扣款"},
            "order": {"charges": [49, 49]}
          }
        }
      ]
    }
  ],
  "questions": [
    {
      "type": "choice",
      "name": "next_route",
      "instructions": "选择下一步处理路径。",
      "choices": [
        {"value": "auto_process"},
        {"value": "request_more_info"},
        {"value": "human_review"}
      ]
    }
  ]
}

input_json.data 放业务证据，questions 定义要判断的问题，name 是应用读取答案时使用的稳定键。返回结果会放在 answers 数组里；选择题除了选项值，还会给出概率和置信度，业务可以据此设置复核阈值。

哪些任务不应该硬塞进 Decisions API

它的优势来自答案空间受限，所以以下任务通常不属于它的主战场：

• 需要长篇解释、改写、摘要或创作内容：继续使用适合生成文本的接口。
• 需要模型按照任意 JSON Schema 写出完整对象：应使用结构化输出，而不是把生成任务拆成一个伪评分题。
• 需要模型提出工具调用参数并请求外部动作：使用函数调用或工具调用链，再把 Decisions API 作为可选的分类或路由器。
• 没有稳定标准、只能依赖临时主观判断的开放问题：先补充 rubric、固定选项或人工规则，否则输出难以复盘。

我会用这张清单做最后判断

在接入前，我会把候选任务写成一行：输入是什么、问题是什么、可能答案有哪些、每个答案会触发什么动作。若答案能压缩为“是/否”“固定选项”或“有序等级”，并且低置信度有明确兜底路径，就值得先做小样本评估。若核心价值仍然是生成一段内容，或者需要临时编造字段和动作，换回更通用的接口更省事。

变更记录：https://developers.openai.com/api/docs/changelog

相关问题

• Decisions API 和 Responses API 的主要区别是什么？前者返回类型化判断，后者更适合生成内容、结构化对象或调用工具。
• choice 和 score 怎么选？没有顺序的类别用 choice，有明确等级和 rubric 的评价用 score。
• 低置信度结果怎么处理？把概率阈值、人工复核和失败兜底一起设计，不要只取最高选项。
• 多个问题能否共享同一份输入？可以把共享证据放进 input，再用 questions 表达不同的受限判断。