OpenAI决策API的隐忧：换个选项顺序，概率就变了13个点

一位开发者针对OpenAI全新的Decisions API跑了一千次实验。先是一枚偏向70%正面的灌铅硬币，API表现几乎完美——采样到正面的比例恰好接近70%。

接着他换了一个装着弹珠的罐子：五颗红色、三颗蓝色、两颗白色。抽到红色的真实概率是50%，可API却有86%的概率选了红色。

他把答案选项重新排序，把"红色"从第一位挪到最后一位。这个数字降到了73%。

同一个问题，同一个罐子，同一个模型。唯一的区别只是选项顺序。

这正是人们狂热追捧了一整周的API。OpenAI在DevDay发布，底层由专门的gpt-6-luna驱动，矛头直指TypeSafe旗下Jev刚刚引爆的快速决策市场。而在所有喧嚣之下，这个因为重新排列列表就让概率发生漂移的安静实验，几乎没人注意。

如果你打算把路由逻辑交给一个模型，最好先了解这个弹珠罐。

Decisions API到底是什么

它的思路很简单，坦率得让人希望更多发布会都能这样。模型不再逐token生成文本，而是返回三种类型化答案之一：

• predicates：是或否，附带一个概率
• choices：从你定义的固定列表中选一个
• scores：按评分标准打分

没有长篇大论，没有废话，只有一个快速的判断。

OpenAI声称可达到最高10倍的加速，因为省去了长文本生成环节。理论上每次调用约150毫秒，而不是生成文本所需的1.6秒。对于高并发路由场景，这笔账很有吸引力。

代价在于：模型无法解释自己，无法展示推理过程。你拿到的是一个裁决和一个数字。

这类"结构化输出"设计并非OpenAI首创。早在函数调用（Function Calling）和JSON Mode出现时，社区就在用受限解码（constrained decoding）技术让模型只能输出符合特定schema的token序列。受限解码的原理是在推理时屏蔽所有非法token的概率，强制输出落在预定义的词汇空间内。Decisions API的速度优势很大程度上来自这里：当输出空间从整个词表压缩到「yes/no」或一个短列表时，模型不需要逐步展开完整的推理链，键值缓存（KV cache）的复用率也更高，首token延迟因此大幅下降。代价同样明显：Chain-of-Thought研究反复证明，让模型先"说出"推理步骤会显著提升最终答案的准确率；跳过这一步换速度，等于主动放弃了一部分准确率的上限。

与Jev的正面交锋

关于这次发布，人们总会问一个问题：这是抄袭吗？

TypeSafe的Jev在感觉上只用了几周时间，就从一个爆红的新奇玩意儿冲到75亿美元估值、年化收入超过1亿美元。它定义了这个品类。

随后OpenAI几乎立刻推出了直接对标的产品。r/singularity上的讨论概括了当时的情绪："这抢走了TypeSafe瞄准的一大块市场。"而Reddit上票数最高的回复则不以为然：

等等，这不就是抄Jev，本质上只是个超轻量版Luna？

基准测试的数字落在两者之间。LangWatch在"LLM作为裁判"的任务上同时跑了两者：

	OpenAI Decisions	TypeSafe Jev
准确率	75.2%	63.7%
中位延迟	243 ms	429 ms
每千次决策成本	$1.09	$0.42

OpenAI更快也更准，Jev价格却不到一半。数据派把它称为"统计上的平手，但有价格差"。

没人发推的"慢"

真正有意思的抱怨几天后才出现。r/LLMDevs一个名为"Jev替代品"的帖子把Decisions API形容为"慢得令人失望"。这可不是一个主打10倍速度的发布会该有的结果。

还是老套路。基准测试是个玩具，真实流量不是。

有人尝试用它路由客服工单，发现中位延迟还行，但长尾令人恼火——那几秒的等待足以让人觉得系统坏了。

我认为更深层的问题在于OpenAI的参照系。相比它自家的生成端点，这确实快；但相比一个做同样分类任务的小模型，差距会迅速缩小。

还有一点发布说明里没写：两个模型在需要真正做数学时都会崩溃。累加发票行项目？两者都是硬伤。模型做的是判断，不是计算。

延迟的"长尾问题"在分布式推理系统中有专门的描述方式：P50（中位数）、P95、P99延迟。一个P50只有243毫秒的系统，P99可能轻松超过2秒——意味着每100次请求里有1次会让用户明显感到卡顿。对于客服工单路由这类场景，这1%的慢响应恰好集中在高负载时刻，因为此时推理服务器排队最长。OpenAI的共享API端点在流量峰值时会出现明显的排队延迟，这与自托管小模型的行为截然不同。真正需要稳定低延迟的生产场景，通常要购买Provisioned Throughput（预置吞吐量）来绕过共享队列，这会让成本计算彻底改变。

微软三天后入场

接着，最诡异的事发生了。OpenAI公测三天后，微软推出了自己的决策评分模型Microsoft-Decision-1。

转折在于：它是通过对阿里巴巴开源的Qwen3.5-9B进行后训练构建的。不是基于OpenAI模型。微软——OpenAI最大的合作伙伴——用一个中国开源模型打造了自己的快速判断层。

它还更便宜：每百万输入token只要0.042美元，输出不收费，纯文本，32k上下文。

微软声称它在一套包含近15万道盲测题的36项基准测试中胜出，运行速度比GPT-6 Sol这类旗舰模型快35倍。他们还计划将其迁移到自家的MAI模型上。

我把这读作一种表态：微软不想在廉价、枯燥、高并发的判断层上依赖OpenAI。

于是现在有三个玩家在争抢同一份工作：快速、廉价地判断一件事。赢家将成为每个路由系统里默认的"大脑"。

Qwen3.5是阿里巴巴通义千问^广告系列的开源模型，以Apache 2.0协议发布，允许商业使用和后训练修改。微软选择在其基础上做监督微调（SFT）和强化学习对齐，而非使用OpenAI模型，这在商业逻辑上有多重动因：开源基座的推理成本远低于API调用费；避免核心基础设施对单一供应商的技术依赖；同时也是Azure AI平台差异化的一步棋——Azure既卖OpenAI服务，也需要自己的护城河。这一动作与谷歌、Meta近年来的策略一脉相承：在标准化、商品化的推理任务上，开源微调模型的性价比已经可以与闭源旗舰模型正面竞争，而"判断层"恰好是最容易被标准化的环节之一。

从基准测试里抽身

我桌面上有个文件夹叫"发布周"。每当一家公司宣布"史上最快模型"，我就截个图扔进去。现在里面有四十个文件了，没有一个还是"史上最快"。

gpt-6-luna、Jev、Decision-1、Dots。每个名字都当了整整一周的未来。

我跟朋友提过这个文件夹，她说真正的规律是公司们快把名词用光了。每次发布我都会想起这句话。

这就是这个品类的现状：一个新东西出现，一个月内就变成一张带着权衡取舍的电子表格里的商品。

还有命名。你的基础设施如今依赖着一堆名字像独立乐队的模型。Jev像奇幻小说里的角色，Luna像香水，Decision-1像星际迷航里的机器人。

诚实的部分

大多数人其实用不上这个。这点要说清楚。

如果你每天只路由几千个决策，一个带JSON schema的普通模型就能干同样的活。是慢一些，但免费，因为那模型你本来就在付费。

这个品类只在规模化时才有意义：百万级内容审核、企业级工单路由、那些本来要烧掉数千token才能在两个选项间抉择的agent循环。

而如果你真要用它，别信那些原始概率。弹珠实验就摆在那儿。一个因为你重排列表就让置信度漂移13个点的模型，给你的是一种"感觉"，不是一次"测量"。

把分数当作提示，自己建阈值，上线前测试一下答案选项的顺序。

还有一点诚实话：10倍提速只在"你本来就生成了不需要的文本"时成立。如果你的工作流需要写一段话，这个API毫无用处。它是一个开关，不是写手。

我总是忍不住回到那个弹珠罐。硬币很完美，罐子一团糟。这个实验恰好讲完了这个API的全部故事：问题干净时它很棒，当现实带着混乱、顺序和偏见出现时，它就变得诡异。

我会用它做分流，但不会向它寻求真相。

也许真正的教训更简单：炒作周期跑得比校准快。所有人都急着争论"谁杀死了Jev"，几乎没人问过——当你打乱答案顺序时，这些概率还站得住脚吗？这个问题比所有发布会的热评都更有价值，而我至今没找到一个好答案。