OpenAI Decisions API：让 AI 分类与评分真正进入业务流程

AI 应用越来越擅长生成文字、代码和解释，但生产系统经常需要的是更窄的问题：这条消息应该交给账单团队还是技术支持？图片里是否有损坏？这个问题属于哪个严重程度等级？OpenAI 的 Decisions API 已正式可用，专门面向这类有边界的判断，而不是开放式写作。

区别很重要。通用回答可能很精彩，却不容易验证。决策接口在应用需要类型化答案、概率分布或可以驱动下一步流程的分数时更有价值。根据 官方 Decisions 指南 和 创建决策接口参考，它可以评估文本、图片和 JSON，并支持谓词、选项和评分问题。

真正的变化是增加了类型化判断层

很多团队已经有“请把这条请求分类”的提示词。薄弱环节不一定是模型，而是模型周围的契约。如果提示词可以返回任意段落，下游代码就必须解析散文、猜测置信度，并决定如何处理边界情况。

Decisions API 会把问题明确化。谓词用于判断一个条件是否成立，并返回概率；选项用于从你定义的值中选择，例如 billing、technical 或 other；评分用于按照有顺序的等级评估输入，例如“仅外观问题”“有替代方案”和“完全阻塞”。结果仍然带有概率性质，但应用可以在采取行动前检查它的结构。

这让 AI 从孤立的模型调用变成一个小型策略边界。应用负责定义允许的结果、区分各结果的说明，以及什么时候应该把任务交给人工复核队列。

它可以回答哪些问题

最直接的场景是路由。客服消息可以配合选项问题发送，应用随后把它交给对应队列，同时保留 other 作为分类体系之外的后备选项。审核或信任流程可以用谓词问题判断可见属性。运营团队可以用评分问题衡量问题严重程度，再把高风险案例排到前面。

图片能力也很关键，因为每个问题都可以附带自己的证据。共享输入可以放参考资料，不同问题再分别比较候选图片。这适合商品检查、目录清理、文档审核和视觉质量控制。接口还支持 JSON，因此应用不必在提问前把每条结构化记录压扁成很长的字符串。

当前指南还列出了一些实用改进：共享输入可以缓存，单次请求最多可以包含 400 个问题，也可以使用公开的 HTTP/HTTPS 图片地址或内联数据 URL。这些能力不会替代评测，但会让批量决策服务更容易设计。

它在生产技术栈中的位置

Decisions API 不是所有模型调用的替代品。OpenAI 的建议可以分成三类：当答案是谓词、固定选项或有序分数时使用 Decisions；当模型需要生成符合自定义 JSON Schema 的较复杂对象时使用 Responses API 的 Structured Outputs；当模型需要请求带参数的工具时使用函数调用。

对开发者来说，一个实用架构可以是：

1. 收集证据，并整理成稳定的输入格式。
2. 用清晰、互不重叠的定义提出一个或多个窄问题。
3. 在应用代码中应用经过校准的阈值。
4. 把不确定案例交给人工或更宽泛的推理路径。
5. 保存问题版本、答案概率和最终动作，方便后续评测。

第四步是安全阀。置信度不是保证；当分类体系不完整或证据含糊时，高概率也可能错误。接口应该帮助团队更一致地做判断，而不是用看起来自信的句子掩盖不确定性。

开发者可以怎样落地

先从真实流程中取一小组带标签的数据，写清楚误报和漏报的代价。然后围绕可观察标准定义问题，而不是围绕模糊意图。如果两个类别重叠，先改进类别说明，再增加模型复杂度。

客服路由可以从四到五个队列和一个明确的兜底选项开始。视觉检查应该为每个独立条件设置谓词，而不是用一个巨大的问题同时混合损坏、品类和严重程度。优先级评估可以定义二到十个有序等级，并把相邻等级的区别写具体。

最后要监控漂移。产品名称、客服政策和图片分布都会变化。保留复核样本，把模型答案与人工标签比较，并在错误成本变化时调整阈值。需要更多工具发现思路的团队，也可以浏览 BTTC 软件目录，或回到 BTTC 科技博客 阅读相关的 AI 与开发者工具文章。

限制与安全措施

类型化答案不等于事实已经验证。不要仅凭概率就授权不可逆操作。凭证应留在服务端；应用要校验每个返回值，记录模型和问题版本，并按照隐私要求保护图片与客户数据。

也不要把评分标准变成无人审查的商业政策。发给模型的描述应当能被流程负责人阅读和复核。如果业务无法解释某条输入为什么属于某个类别，模型本身不会让政策变得更清晰。

常见问题解答

Decisions API 和 Structured Outputs 一样吗？

不一样。Decisions 适合谓词、固定选项和有序分数；Structured Outputs 更适合需要遵循自定义 Schema 的复杂对象。

它可以分析图片吗？

可以。图片可以放在共享输入中，也可以附加到单个问题的指令里。接口支持公开的 HTTP/HTTPS 图片 URL 和内联 base64 数据 URL，但仍受平台输入限制约束。

每个答案都应该自动执行吗？

不应该。应使用带标签样本设置阈值，保留兜底或人工复核路径，并把概率和置信度当作策略信号，而不是证明。

它对小型软件团队有什么帮助？

它减少了把模型判断转换为可预测分支时所需的胶水代码。团队可以先从一个窄的路由或检查流程开始，测量效果，再根据数据扩展。

结语

Decisions API 的价值在于缩短多模态 AI 与普通应用逻辑之间的距离。开发者不必先让模型写一段回答，再反向解析成分支，而是可以定义少量类型化问题，并让不确定性显式存在。这是客服路由、视觉检查、问题分流等流程中的实用模式，因为这些场景真正重要的是下一步动作，而不是一段漂亮的文字。