一个请求 400 道判断题：OpenAI Decisions API 上线，规则引擎该退休了吗

【摘要】10 月 22 日，OpenAI 的 Decisions API 正式上线。跑在 GPT-6 Luna 上，一次最多问 400 题，只收输入费用，每百万 token 0.10 美元。它专门干一件事：回答有范围的问题——是非题、选择题、分数。Datadog 说 p95 快 40 倍，Sierra 说每次调用成本降 90%。很多企业的流程本质就是大量小判断，这篇讲这个 API 到底改变了什么，以及哪些场景它替代不了规则引擎。

目录

一、它是什么：一个只有"有界答案"的 API
二、三种答案类型，藏着三种不同的用法
三、真实的客户数据
四、为什么这件事值得认真看
五、但它替代不了规则引擎
六、怎么评估：拿你人工判过的数据对
七、最后一件事：判断结果影响人的决定时

一、它是什么：一个只有"有界答案"的 API

10 月 22 日，OpenAI 宣布 Decisions API 正式上线（10 月 6 日起公开测试）。

官方描述很克制，但信息量不小：

Built with GPT-6 Luna, the Decisions API focuses Luna’s intelligence on questions with bounded answers, helping applications and agents make near real-time decisions from text, images, and structured inputs up to 10x faster than GPT-6 Luna through the Responses API.

拆开看：

• 底层是 GPT-6 Luna，但不是那个走 Responses API 的完整模型
• 只处理"有界答案"的问题 —— 是非题、选择题、分数
• 输入可以是文本、图片、原生 JSON
• 比走 Responses API 快最多 10 倍
• 单请求最多 400 题（测试期是 200 题的两倍）
• 只收输入费用：$0.10 / 百万 token，缓存输入 $0.01 / 百万 token，没有输出 token 费用

公有测试以来还加了：原生 GPT-Live 集成、复用上下文的提示缓存、美国和欧盟的推理驻留。

"只收输入费用"这一条值得单独拎出来。 对分类、判断、评分这类任务，你本来就不需要模型生成一大段文字——你只需要一个结论。省掉输出费用，等于把这类任务的成本结构整个换掉了。

二、三种答案类型，藏着三种不同的用法

API 支持三种返回类型，它们对应三种不同的判断语义：

这三个类型看起来只是技术细节，但它们的用法差别很大。

predicate 是"软判断" —— 比如"这张商品图有没有可见的损坏"。返回概率，阈值由你定。

choice 是"分支决策" —— 比如"Agent 该继续、重试、还是要求澄清"。这个特别适合放在 Agent 的编排层，因为它输出的正好是"下一步该干嘛"。

score 是"分级评估" —— 比如"损坏严重度"。注意它返回的是概率加权平均，不是硬分类。这意味着 0.5 分可能来自"全是 1 分"也可能来自"一半 0 分一半 1 分"，而这两种情况的处理方式应该不一样。

搞错这三种的语义，用法就会拧巴。 比如拿 score 的输出去做二元判断，你会丢掉"置信度低"这个信息——而那恰恰是最该转人工的信号。

三、真实的客户数据

官方放出来的几个案例，比任何形容词都实在：

Box（Biswaroop Palit, VP, Product Management Platform and Integrations）：

在我们的评测中，Decisions API 在 30 份保险凭证案例上把路由选择提速约 5 倍，准确率与 Responses API 相同——常规工作自动化，低置信度案例转人工复核。

Datadog（AJ Stuyvenberg, Staff Engineer）：

Decisions API 帮我们在执行之前给 Agent 生成的 shell 命令打风险分，以便自主修复问题。与可用的前沿模型相比，p95 快 40 倍，准确率相当——这让 Decisions 能放进修复动作的热点路径里。

Ramp（René Sultan, Research Engineer）：

与 GPT-6 Luna 相比，Decisions API 让 AI 成本归因快 4 倍、便宜 30%，准确率没有损失。

Sierra（Ajeet Grewal, Engineer）：

在我们线上客户对话的编排中，用 Decisions API 选择下一步动作。p95 在 280ms 以下，比我们之前的方法快约 3 倍、每次调用成本低 90%，客户结果没有下降。

Speak（Andrew Hsu, CTO）：

对语言学习者来说，时机很重要。在我们的测试中，GPT-Live 里的 Decisions API 集成把"距离下一次动作的时间"降低了 90% 以上，从 1.4 秒到 0.13 秒。

OpenAI 内部也在用：dots 团队用它降低响应时间、改善交互性；个人财务团队用它给交易描述分类；传播团队用它按主题分类内容并评分是否强化或挑战关键叙事，用来识别哪些值得进一步审查。

我特别留意了 Sierra 那条——“客户结果没有下降”。这比"快 3 倍"更重要，因为快是容易的，不掉质量才是难。

而 Box 那条里"低置信度案例转人工复核"，其实是这个 API 最正确的用法：它不是来替人做决定的，是来替人筛的。

四、为什么这件事值得认真看

把这个 API 放到时间线上看，它不是孤立的产品发布。

第一，它切出了一个新的档位。 过去两年，AI 应用的选择只有两个极端：完整的生成式 API（强但贵且慢），或者自己写的规则引擎（快且便宜但没有理解力）。中间这块——低延迟、有理解力、便宜——一直由规则引擎和提示链勉强分担。

Decisions API 就是把这一档做成了一个正式产品。

第二，它把"决策"从"生成"里拆了出来。 这和上一轮那个趋势是一致的——Google 把护栏拆成 skills（建议）和 IAM（强制）两层，Cloudflare 把站点能力开放成工具，AWS 把工具发现做成 Registry。整个行业都在把一件事拆成几层，各层用最合适的机制。

生成和决策被拆开，就是这个趋势的一个具体体现。

第三，它让"大量小判断"这件事第一次在成本上可行。

想象一个场景：每个工单进来要做 8 个判断——是否重复、类型、优先级、该转哪个组、是否需要人工、紧急程度、是否合规、是否要补材料。

以前你要么写规则，要么调 8 次完整 API。现在是一次请求 400 题。

第四，这跟上一轮讲的主动式 Agent 直接接上了。 Duet 那类产品每天要处理大量"下一个动作是什么"的判断。Sierra 那个案例——在客户对话的编排里选下一步动作——就是主动式 Agent 的核心循环。

一个可以传播的观点句：Agent 从"能对话"到"能干活"，中间隔着成百上千个小判断。这些判断过去是规则引擎的地盘，现在正在被一个便宜十倍的 API 接管。

五、但它替代不了规则引擎

说了这么多，得泼点冷水——这个 API 有一类场景明确不该用。

第一，确定性要求极高的地方别用。 如果你的判断必须 100% 可复现、有明确的合规审计要求、或者出错代价是法律责任（比如医疗诊断结论、信贷审批的最终拒绝），那必须是确定性逻辑。模型输出的是概率，不是保证。

第二，能用规则表达的就别用模型。 "字符串以 _test 结尾"这种判断，写成正则是纳秒级、零成本、百分百准确的。用 Decisions API 是拿一个概率模型去换一个确定的布尔值。

判断标准很简单：这个判断需要"理解"吗？ "这封邮件是不是在推销"需要理解；"这个 IP 是不是在黑名单里"不需要。

第三，输出长度有要求的场景。 只收输入费用、返回选项——但如果你需要模型同时输出理由，这个 API 就不合适。它的设计前提就是"你不需要解释，只要结论"。

第四，别忘了它仍然是模型。 Datadog 那条说"与可用的前沿模型相比，准确率相当"——注意是"相当"，不是"更好"。它比前沿模型快，代价是能力被收窄到有界答案上。

六、怎么评估：拿你人工判过的数据对

OpenAI 官方给的建议路径很朴素，但很对：

从你的应用经常做的一个重复判断开始。定义问题、可选答案、区分它们所需的上下文。用反映真实用法的样例测试。

我要补一条更实际的：评估必须用人工判过的数据。

具体做法：

第一步，收集一批你已经人工判断过的历史数据。 比如过去三个月人工审核过的工单、标注过的简历、分类过的图片。

第二步，在这批数据上同时跑三个方案：规则引擎、原 API、Decisions API。

第三步，比的不是"准确率"这一个数。 要看四个维度：

第四步，特别关注"哪些案例从人工审核变成了自动处理"。 这里有个容易被忽略的风险：规则引擎错得很"整齐"（同类错误一起错），模型错得很"随机"（散在各个角落）。后者更危险，因为人工抽检很难发现。

Box 那句"低置信度案例转人工复核"就是这个问题的答案——用 confidence 决定哪些走自动、哪些转人工，而不是用一个总准确率决定整批。

七、最后一件事：判断结果影响人的决定时

最后这条是硬要求，不是建议。

当判断结果会影响人的决定时，必须保留人工复核。

比如筛简历——Decisions API 说"不通过"，这个人就拿不到面试机会。这个判断如果错了，代价不是多花一次 API 调用，是有人被系统性地挡在了门外。

这不是模型能力问题，是责任归属问题。一个 API 可以做判断，但不能承担"这个决定是我做的"。

Sierra 的用法就是正确的范式：API 选下一步动作，但那是"路由"，不是"结论"。转人工、转 escalation、还是要继续执行——最终影响客户的那一步，由人或明确的策略决定。

还有一条务实的提醒：评估样本里的"正确答案"本身可能有噪声。 人工标注的工单里，有多少是标错的？如果基线本身不干净，你的准确率数字就不可信。

这周我把 API 文档翻了三遍，最打动我的不是"快 40 倍"，而是它对置信度的原生支持。

choice 类型直接返回概率和置信度，score 返回概率加权平均——这意味着它从设计上就承认了"我可能会错"，并且把"我有多确定"一起交出来。

这一点比快更重要。快只是让你敢用，准只是让你能信，知道自己不确定，才是让你敢放进自动流程的前提。

你们业务里，有哪些判断是"大量、小、而且有标准答案"的？ 评论区聊聊，我特别想知道有没有人已经在试这种用法了。