OpenAI 据称推出低延迟结构化决策接口

如果 AI 调用只是为了给工单选个分类，让模型先生成一段文字，再从中提取标签，确实多绕了一圈。原文介绍的 OpenAI Decisions API，就是把这类任务单独拆出来：输入证据和判断标准，直接返回概率、选项或评分。

按原文披露，它只支持 gpt-6-luna，宣称把响应时间从 1–3 秒压到 100–180 毫秒，且只收输入费用。值得读的地方是这种接口分工：哪些工作需要模型生成内容，哪些只需要一个判断。至于速度、准确率和成本优势，必须拆开看。

它解决的是判断任务，不是所有结构化输出

客服工单分流、内容审核、交易分类，看起来业务不同，接口需求却很接近：程序已经知道允许哪些答案，只需要模型判断输入落在哪一类。

原文给出的专用端点是 POST /v1/decisions。每次请求包含三部分：

• model：当前只能填写 gpt-6-luna。
• input：共享证据，支持文本、包含图片的消息，以及原生 JSON。
• questions：问题列表，每个问题声明类型、名称、指令和允许的答案。

响应通过 answers 数组按问题顺序返回，并带回问题名称，便于程序匹配。

这里的区别在于输出契约。Decisions 只处理概率、选项和评分；如果需要提取订单字段、生成回复，或返回自定义 JSON Schema 对象，原文建议使用 Responses API，必要时配合 Structured Outputs。

输出格式受约束，不代表判断一定正确。

另外，原文把传统方案描述成「生成文字后再解析」，有些简化。已经使用 Structured Outputs 的团队，并不一定还在手工修补 JSON。Decisions 对这类团队的价值，更需要靠延迟、费用和任务质量来证明。

三种问题类型，决定程序怎样接住结果

第一种是 predicate，判断某个条件成立的概率，范围为 0 到 1。

例如检查商品图片是否破损，返回 0.92。业务代码再决定是否拦截、放行或转人工。原文强调，阈值要用自己的标注样本确定，还要考虑误报和漏报各自的代价，不能直接把 0.9 当成通用上线标准。

第二种是 choice，从预设列表中选择一项，同时返回各选项概率和整体置信度。

原文用重复扣款工单举例：候选项是 billing、technical、shipping、other，示例概率分别为 0.95、0.02、0.01、0.02，整体置信度为 0.93。它说明各选项概率和整体置信度是两个字段，原文没有交代后者的计算方式。

分类时应保留 other。否则遇到范围之外的请求，模型仍可能被迫选一个错误类别。如果两个分类经常出现 0.51/0.49 的分布，也应该检查分类定义是否重叠，不能只怪模型。

第三种是 score，按有序量表评分。量表支持 2–10 档，返回档位索引的概率加权平均值。

原文把缺陷分成 Cosmetic、Workaround available、Fully blocked，索引依次是 0、1、2。对于「Safari 导出失败，但 Chrome 正常」，假设概率为 0.1、0.7、0.2，得分就是：

0 × 0.1 + 1 × 0.7 + 2 × 0.2 = 0 + 0.7 + 0.4 = 1.1

这个结果接近「有替代方案」，略偏向更严重。要留意，1.1 是量表索引的期望值，不是独立定义的故障等级。原文说响应还包含各档概率和置信度，分布比较分散的案例可以进入复核队列。

100 毫秒和低价，都有适用条件

原文称，该接口于 2026 年 9 月 29 日在 DevDay 首次亮相，10 月 6 日进入公测，10 月 22 日全面开放。正式版单次最多支持 400 个问题。

批量能力适合共享证据上的独立判断：同一张商品图，可以同时检查破损、判断类别、评估上架质量。同一段客服对话，也可以同时分流、判断情绪和评估紧急程度。

但如果第二个问题必须使用第一个问题的答案，就需要再发请求。把依赖链硬塞进同一次调用，并不符合原文描述的执行方式。

速度方面，原文转述 OpenAI 的说法：相比同一 gpt-6-luna 通过 Responses API 调用，最高快 10 倍，Nikunj Handa 给出的响应区间是从 1–3 秒降到 100–180 毫秒。这些是厂商数字，没有可审计的测试方法，也没有说明装满 400 个问题时是否仍能达到这个区间。输入长度、图片载荷、区域和串行调用次数，都需要实测。

费用可以直接验算。原文报价为每百万输入 token $0.10，缓存命中输入 $0.01，输出不收费。每次判断使用 500 个输入 token，每月调用 1,000 万次：

10,000,000 × 500 = 5B tokens

输入费用为 $500，单次 $0.00005。若全部按缓存命中价计算，理论费用为 $50。但不断变化的工单正文不能直接假定全部命中缓存，缓存写入也要收费，区域处理和长上下文还可能产生加价。

原文给出的 Luna 普通调用价格是每百万输入 token $0.10、输出 token $0.50。若每次生成 25 个 token，1,000 万次增加 250M 输出 token，费用为 $125。这个例子里，省掉输出费有用，但没有形成数量级差距。

与 TypeSafe 的 Jev 相比，Decisions 也不是最低价。按原文引用的每百万输入 token $0.042，100 万次、每次 500 token 的分类，Jev 为 $21，Decisions 为 $50。后者的吸引力在已有 OpenAI 接入、多模态输入、缓存价格，以及原生 GPT-Live 语音集成等配套能力。

我的判断

把高频判断从内容生成中拆出来，是合理的工程分工。特别是工单分流、缺陷定级、Agent 工具选择，答案空间原本就有限，专用接口更容易接进业务分支。

但原文没有提供作者团队的实测，也没有准确率、概率校准、吞吐或尾延迟的对照数据。文中的概率分布是示例，不能当成实验结果。产品发布日期、模型支持和报价也都来自所给材料，此处未作独立核验。

接口返回 0.9，不足以证明同类案例有九成判断正确。

选型时还应把规则和现有分类器放进比较。如果条件能用字段匹配或明确规则表达，先执行规则通常更容易解释。涉及语义歧义时，再评估 Decisions、Jev 或现有生成模型，比较误判率、人工复核比例和整体响应时间。

它的局限也很明确：只支持一个模型，不返回解释，复杂依赖需要多次调用。需要审计理由的业务，增加一次生成调用也不能自动证明原判断的依据。原文提到的 Zero Data Retention、HIPAA 资格及美国、欧洲区域处理，同样附带客户资格和协议前提，不能理解为所有账户默认具备。

能拿来做什么

• 在客服或内容审核系统里，先整理已有标注案例，分别统计误报和漏报，再确定自动通过、人工复核、自动拦截的阈值。
• 在 Node 服务中，把同一输入上的独立问题合并调用，例如同时判断工单类别和紧急程度；确实依赖前一步答案的判断再拆开执行。
• 给前端缺陷分流建立明确量表，用「是否阻塞核心流程」「是否存在替代方案」定义档位，并保留各档概率供复核，避免只按平均分排队。
• 在日常 AI Agent 中，优先评估耗时明显的工具选择分支，并设置低置信度时的升级路径。用真实输入比较完整链路的成本和延迟，再决定是否迁移。