Microsoft-Decision-1：速度第一、校准第三，自动放行还缺什么？

微软在 10 月 9 日发布了 Microsoft-Decision-1：一个以 Qwen3.5-9B 为基座、经后训练处理固定选项判断的模型。微软发布文称，在其对比里，它的单次决策中位延迟约比 GPT-6 Sol 快 35 倍，平均准确率也排第一；但翻到同一篇文章的校准图，第一名是 Jev 1.13.0，Decision-1 只排第三。如果你想凭模型给出的概率决定哪些请求自动放行、哪些交给人，官方对比中的校准一栏至少和速度一栏一样重要。这里的排名与速度都来自微软自己公布的测试，我们没有测过 Decision-1。

这不是「新模型会输出概率」的又一次介绍。我们此前在Jev 路由分层一文已经讨论过类型化判断、选项之外的退路和人工复核。真正的新问题是：当另一家大厂把一个 9B 基座后训练成决策模型，并把「快」和「准」放在同一张看板上，这三个指标是否支持同一个上线决定？

假设一支团队用模型分派客服工单。把技术故障错送到账单队列，可能只是多一次转派；把应交人工处理的退款承诺误判为可以自动放行，代价可能大得多。模型越快，这两类判断都可能被调用得越频繁。选择服务时，你至少要分开问三句话：多久回一个判断？在测试题里，最终标签有多少正确？它报出的概率与事后正确频率合不合？前两题的冠军，不必自动成为第三题的冠军。

35 倍快，是 85 毫秒对 3010 毫秒的厂商中位数

微软的官方三轴总览图及同页延迟图给出了可直接核对的行：Decision-1 85 毫秒、H2O-Lightning-4B v1.1 210 毫秒、Jev 1.13.0 240 毫秒、GPT-6 Sol 3010 毫秒，均是图中每次决策的调整后中位延迟（p50）。3010 除以 85 约为 35；210 除以 85 约为 2.5。发布文的 35 倍，比较对象因此是 GPT-6 Sol，不是 Jev，更不是任意生产环境里的大模型。同一图里 Jev 的 240 对 85 毫秒约为 2.8 倍，不能把它偷换成 35 倍。

图例写明，延迟数据取自 JevBench v1.6.1 的 adjusted median（p50），标注检查日是 10 月 7 日；星注说微软模型通过 Foundry 在同一地区测量。图上单独给 Decision-1 标出 p95 为 125 毫秒，却没有给所有对照模型列出对应的 p95。于是我们能说的是「厂商的这一组中位数显示它最快」，而不能把 125 毫秒与别人的 p50 相减，宣布它在尾延迟或你所在地区也获胜。这是两类不同分位数。

为什么特别盯住测量地点？如果一个 agent 连续做二十次判断，每次多 100 毫秒，理论上串行路径就多两秒；微软在发布文里也用这个例子解释速度的意义。但网络往返、地区路由、排队和失败重试都会出现在真实系统里。Foundry 的部署文档明确区分部分地区可用的 DataZoneStandard 与 GlobalStandard：后者可在受支持的全球区域处理，实际延迟可能更高或更不稳定。选择就近的数据区也不保证更低延迟，文档要求按自己的负载测。单次 p50 适合识别候选，不足以给一条多步工作流签性能保证。

微软官网正文写「比第二名 H2O-Lightning-4B v1.1 快 2.5 倍」，对应图中的 85/210 毫秒。这个比值仍解决不了你的 p95 和地区问题。做横向比较时，先在测试表里同时记下发起请求的地区、输入长度、选项数、并发数、超时与重试策略，再按相同任务记录成功率和端到端耗时。少了这些字段，单个 85 毫秒既无法告诉你请求是否从本地机房绕远，也无法说明高峰排队时服务表现如何。如果一个误判还要补上一轮大模型复核，整体耗时应把两次调用和复核率一起算，不能只把第一跳的 p50 当用户等待时间。这是评估设计，不是我们已经测得的结果。

准确率第一、校准第三，究竟是哪两道题

转到同一发布文的平均准确率图，微软报告：在 36 个基准、147,137 个问题上，Decision-1 得 83.5，Jev 1.13.0 得 82.3，Quyet-1.0-Large 得 81.9。这是跨题的平均准确率排序，不是每一道分类都稳赢。图中还有一个容易漏掉的脚注：Strands-Decider 2B 只完成其中 23 个基准，其平均成绩不能直接当作同一套 36 个基准的完整对照。微软没有在这张汇总图里交付你业务标签上的成对错题清单；只凭均值差 1.2 个点，也无法断言特定工单领域或中文文本上必然更准。

再看发布文的校准得分图：Jev 1.13.0 93.7，Quyet-1.0-Large 93.1，Decision-1 92.2。它们在微软列出的可评分模型里分居第一、第二、第三。图的解释是「100 代表模型置信度恰好匹配它实际正确的频率」；微软落后 Jev 1.5 分，落后 Quyet 0.9 分。92.2 不是单次判断有 92.2% 的正确率，也不是“正确答案占 92.2%”。校准图的轴从 80 起，视觉间隔会被放大；同样不能把 1.5 分差写成校准模型在业务上的必胜幅度。知道方向和大小即可，不从图形面积猜生产收益。

可以用一个假设来分清两个量。模型甲在 100 单里判对 85 单，模型乙判对 83 单；甲的整体准确率高。若甲给一批错单也报 0.95，而乙在这些难单上报低概率，乙更可能帮助应用把错单捞出来交给人。这里的 100、85、83 和 0.95 仅是解释概念的假设，不是对两家模型的复测。要知道这次的微软模型到底是哪种情况，必须拿自己已标注的请求，在相同选项、相同语言下画可靠性分桶，观察预测概率与实际对错的对应关系。

这还解释了为什么微软的两个「第一」与一个「第三」并不自相矛盾。准确率只看选中的那个标签最后对不对；校准看的是许多次判断中，报相近概率的一组实际对了多少。例如一批被判作「工程故障」且报 0.9 的工单，过后大约九成确属该类，才是「这一档概率得到校准」的意思。它不能保证眼前这一单真有可核验的九成正确率，也不能把「报 0.9」自动翻译成「无需复核」。单个看起来很稳的判断与一组长期观测的性质，分属不同层次。

准确率和校准是 36 个基准上的汇总分；85 毫秒则来自另一套延迟测量。三轴并排只方便辨方向，不能据此给自家工单算出「每次省 2925 毫秒、准确率多 1.2 点」。短句二分类与长上下文多选的错题和耗时分布，得在各自的任务里找。

还有一个时间陷阱。微软页面带有 Editor’s note，说明它从初版更新，补上 Jev 的准确率与校准基准；该注记没有给出修订的具体日期。按早期网页快照写的「微软没有基准」已经不能描述当前公告。反过来也别把现在的图说成独立审计：提供排行榜、选择对照和呈现图表的仍是模型厂商。读新闻时纠正旧版，做采购时再要求逐任务验证，这两件事可以同时成立。

一个概率要走进人审队列，还缺你的错判账本

「校准更好」也不能自动给出阈值。如果答案是工单部门，错派可以转单；如果答案是「允许 agent 对生产数据执行下一步」，漏拦截与误拦截的代价完全不同。假设阈值设为 0.9：自动处理了多少？被自动处理的一组里错了多少？仍有多少单需要人工？这些数字随任务分布、选项文字、风险承受能力改变。官方的 92.2 校准分数不能替你填这一张表。

实际的验证路径不需要从一个宏大的 benchmark 开始。先挑一项边界清楚、错了能回退的判断，取一批有人工真值的历史样本，其中包括模糊、跨类和「给定选项都不适合」的输入。锁定使用的模型版本、问题表述和选项顺序，把每单的选项概率及最终真值留存；按概率分组检查预测和实际，再沿不同阈值计算自动化覆盖率、自动处理错误率、人工复核量。先决定哪一种错更不能接受，再选阈值；不是为了让人工队列更短，倒过来降低要求。这里是测试设计，不代表我们已对 Decision-1 跑过这样的样本。

再把错判成本拆到类别：挑错低价回复模型也许只多跑一次；放过本应审核的付款承诺却可能不可撤回。漏放风险高的队列可以先只让模型给人工排优先级，不授权自动批准。观察阈值时同时记每天的错单绝对件数：覆盖率上升时，自动组正确率看着不错，错单仍可能变多。人审也不是零错误兜底，须给审核者原始证据和升级路径；跨语言业务则分别看结果，不让占多数的英文短句掩盖中文小样本。没有这些分组数据，就如实留空。

微软的Foundry 模型卡本身提醒：校准在熟悉的任务类型上更可靠；措辞和选项顺序可能改变分数，问题写得不好也会得到一个分数。它建议当证据不足时加入「无法判断」之类的放弃选项，并按实际误报、漏报代价设阈值。官网公告说八种扰动的平均翻转率为 1.3%，有两类选项改写/重排测试未出现翻转；那是指定扰动集的报告，不足以推翻模型卡对实际输入的提醒。选择一条退路，总比假设模型永远会知道自己不知道什么可靠。

Microsoft Learn 的题型文档还把接口的三种题区分得很清楚：choice 从固定标签中选，并给每个选项的概率；noul 给一个条件为真的概率；score 把有序等级的概率折成一个加权值。Learn 明说，score 更适合作相对排序和阈值，不宜当绝对校准等级。如果旧系统的放行线是按另一种题型、另一种模型的 confidence 字段调出来的，把同一个 0.9 原样搬给新模型，就是省掉了最重要的一次验证。我们在此前的 Jev 对照已经展开过高置信不等于正确以及选择性自动化；这里要记住的是，新模型的图并没有给你的阈值盖章。

对于信贷、就业、医疗或其他会实质影响个人权益的判断，模型卡的用途限制写得更明确：不能让它成为唯一的自动决策者，应用必须落实适当的人为监督。把低分单发给人而高分单全部自动执行，并不能天然解决这条边界；高风险流程要先界定哪些事情根本不授权模型独断。

后训练的 9B 基座与三条调用路，不等于三种部署都一样

Decision-1 的技术来源也值得辨清。微软说它是在开源权重的 Qwen3.5-9B 基座上做后训练，输出固定答案的概率；Foundry 模型卡说明最大输入窗口为 32,768 token，文本输入、JSON 输出，不能把它当成会解释来龙去脉或生成任意答案的聊天模型。这里的「开源权重」说的是基座，并非微软公开了 Decision-1 训练后的权重；原厂目前介绍的是托管调用。微软还说将来会考虑换用 MAI 或 OpenAI 等基座，这是一项计划，不是已经更换，也不是现有阈值能永久沿用的承诺。

获得服务有不同入口。微软公告列出 Microsoft Foundry 和 OpenRouter；Vercel 10 月 9 日变更记录则确认 AI Gateway 也提供 microsoft/microsoft-decision-1，并列出 AI SDK decision API、OpenAI-compatible Decisions API 和 TypeSafe-compatible API 三类接法。它说明通过 Vercel 网关只需该网关的 API key，不必另有 Azure 账号或部署。Foundry 的部署步骤却确实要求 Azure 订阅、项目和相应权限；两种说法针对不同入口，并不矛盾。

不同入口的耗时要测完整路径：客户端、网关、部署排队与回程。Foundry 同地区的 85 毫秒不能代替其他地区经第三方网关的体验；多步 agent 还会累积每次等待。超时后停下、送人还是回退规则层，也须事先写明。本文未实测三种渠道，不为它们排延迟名次。

TypeSafe-compatible 解决的是请求能否沿既有协议入口进入，不是新模型和 Jev 会在同一请求上给出同样的概率，更不是从 Jev 的审查阈值无条件继承到 Decision-1。评估替换时把一个标注集分别送到目标入口，记录各类别错单和复核占比，并测实际地区的 p50/p95，才能知道兼容带来了多少省工，又在哪里可能返工。微软公告列出 每百万输入 token 0.042 美元、输出 token 免费。如果一次请求实际计入 N 个输入 token，按这项原厂标价，其理论输入费用是 N / 1,000,000 × 0.042 美元；这不含目标渠道的附加费用、税费或其他费用，输入长度和题目描述会改变 N。Vercel 的变更页没有给出该渠道最终账单、地区路由或与 Foundry 一致的性能保证；地区、配额与服务条件也须在真正使用的渠道复核，不能拿微软标价替别家的发票算总成本。

我会先把 Decision-1 放进错了可以回退的分类或优先级队列，和现有路径并排跑同题样本；若目标是不可逆或直接影响个人的行动，先不让一次概率判断握有放行权。微软这次给出了比一句「更快更准」更有用的材料：速度、平均准确率和校准终于可以分开读。它们能告诉你值得测什么，不能替你回答哪些单据可以不经人手。能改变这个决定的，不是下一张更漂亮的厂商图，而是你自己数据上随阈值变化的错判与复核账本。