# Microsoft-Decision-1：速度第一、校准第三，自动放行还缺什么？ > 微软自测 Decision-1 在指定基准上的中位决策延迟比 GPT-6 Sol 快约 35 倍，平均准确率最高，但校准得分仅列第三。读懂官方对比图、Jev 对照与人工复核阈值的边界。 - Published: 2026年10月11日 - Author: Linden Kern, Chief Scientist - Tags: models, routing, agents - Canonical: https://pirouter.ai/zh/blog/microsoft-decision-1-speed-calibration --- 微软在 10 月 9 日发布了 **Microsoft-Decision-1**：一个以 Qwen3.5-9B 为基座、经后训练处理固定选项判断的模型。[微软发布文](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/)称，在其对比里，它的单次决策中位延迟约比 GPT-6 Sol 快 **35 倍**，平均准确率也排第一；但翻到同一篇文章的校准图，**第一名是 Jev 1.13.0，Decision-1 只排第三**。如果你想凭模型给出的概率决定哪些请求自动放行、哪些交给人，官方对比中的校准一栏至少和速度一栏一样重要。这里的排名与速度都来自微软自己公布的测试，我们没有测过 Decision-1。 这不是「新模型会输出概率」的又一次介绍。我们此前在[Jev 路由分层一文](/zh/blog/jev-typed-decision-routing-layer)已经讨论过类型化判断、选项之外的退路和人工复核。真正的新问题是：当另一家大厂把一个 9B 基座后训练成决策模型，并把「快」和「准」放在同一张看板上，**这三个指标是否支持同一个上线决定？** 假设一支团队用模型分派客服工单。把技术故障错送到账单队列，可能只是多一次转派；把应交人工处理的退款承诺误判为可以自动放行，代价可能大得多。模型越快，这两类判断都可能被调用得越频繁。选择服务时，你至少要分开问三句话：多久回一个判断？在测试题里，最终标签有多少正确？它报出的概率与事后正确频率合不合？前两题的冠军，不必自动成为第三题的冠军。 ## 35 倍快，是 85 毫秒对 3010 毫秒的厂商中位数 微软的[官方三轴总览图](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/)及同页延迟图给出了可直接核对的行：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 的[部署文档](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-microsoft-decision)明确区分部分地区可用的 `DataZoneStandard` 与 `GlobalStandard`：后者可在受支持的全球区域处理，实际延迟可能更高或更不稳定。选择就近的数据区也**不保证**更低延迟，文档要求按自己的负载测。单次 p50 适合识别候选，不足以给一条多步工作流签性能保证。 微软官网正文写「比第二名 H2O-Lightning-4B v1.1 快 2.5 倍」，对应图中的 85/210 毫秒。这个比值仍解决不了你的 p95 和地区问题。做横向比较时，先在测试表里同时记下发起请求的地区、输入长度、选项数、并发数、超时与重试策略，再按相同任务记录成功率和端到端耗时。少了这些字段，单个 85 毫秒既无法告诉你请求是否从本地机房绕远，也无法说明高峰排队时服务表现如何。如果一个误判还要补上一轮大模型复核，整体耗时应把两次调用和复核率一起算，不能只把第一跳的 p50 当用户等待时间。这是评估设计，不是我们已经测得的结果。 ![微软官方三轴对比图：Decision-1 在图列模型中平均准确率第一、中位延迟最快；校准得分第三，校准轴从 80 起](/blog/images/microsoft-decision-1-speed-calibration-overview.png "微软原厂自测：准确率为 36 个基准的平均分，延迟为指定 JevBench 环境的调整后 p50，校准分数另成一轴；本站从官方原始交互组件离线渲染，非独立复测。来源：[Microsoft Command Line 发布文](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/)") ## 准确率第一、校准第三，究竟是哪两道题 转到同一发布文的[平均准确率图](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/)，微软报告：在 **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 个点，也无法断言特定工单领域或中文文本上必然更准。 再看发布文的[校准得分图](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/)：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 的准确率与校准基准；该注记没有给出修订的具体日期。按早期网页快照写的「微软没有基准」已经不能描述当前公告。反过来也别把现在的图说成独立审计：**提供排行榜、选择对照和呈现图表的仍是模型厂商**。读新闻时纠正旧版，做采购时再要求逐任务验证，这两件事可以同时成立。 ![微软官方校准得分图：Jev 93.7、Quyet 93.1、Decision-1 92.2；校准轴从 80 而非零开始](/blog/images/microsoft-decision-1-speed-calibration-calibration.png "微软原厂自测的 36 个基准校准榜：Decision-1 排第三；横轴从 80 起，分差不等于单次正确率。本站从官方原始交互组件离线渲染，非独立复测。来源：[Microsoft Command Line 发布文](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/)") ## 一个概率要走进人审队列，还缺你的错判账本 「校准更好」也不能自动给出阈值。如果答案是工单部门，错派可以转单；如果答案是「允许 agent 对生产数据执行下一步」，漏拦截与误拦截的代价完全不同。假设阈值设为 0.9：自动处理了多少？被自动处理的一组里错了多少？仍有多少单需要人工？这些数字随任务分布、选项文字、风险承受能力改变。官方的 92.2 校准分数不能替你填这一张表。 实际的验证路径不需要从一个宏大的 benchmark 开始。先挑一项**边界清楚、错了能回退**的判断，取一批有人工真值的历史样本，其中包括模糊、跨类和「给定选项都不适合」的输入。锁定使用的模型版本、问题表述和选项顺序，把每单的选项概率及最终真值留存；按概率分组检查预测和实际，再沿不同阈值计算**自动化覆盖率、自动处理错误率、人工复核量**。先决定哪一种错更不能接受，再选阈值；不是为了让人工队列更短，倒过来降低要求。这里是测试设计，不代表我们已对 Decision-1 跑过这样的样本。 再把**错判成本**拆到类别：挑错低价回复模型也许只多跑一次；放过本应审核的付款承诺却可能不可撤回。漏放风险高的队列可以先只让模型给人工排优先级，不授权自动批准。观察阈值时同时记每天的错单绝对件数：覆盖率上升时，自动组正确率看着不错，错单仍可能变多。人审也不是零错误兜底，须给审核者原始证据和升级路径；跨语言业务则分别看结果，不让占多数的英文短句掩盖中文小样本。没有这些分组数据，就如实留空。 微软的[Foundry 模型卡](https://ai.azure.com/catalog/models/Microsoft-Decision-1)本身提醒：校准在熟悉的任务类型上更可靠；措辞和选项顺序可能改变分数，问题写得不好也会得到一个分数。它建议当证据不足时加入「无法判断」之类的放弃选项，并按实际误报、漏报代价设阈值。官网公告说八种扰动的平均翻转率为 1.3%，有两类选项改写/重排测试未出现翻转；那是**指定扰动集**的报告，不足以推翻模型卡对实际输入的提醒。选择一条退路，总比假设模型永远会知道自己不知道什么可靠。 [Microsoft Learn 的题型文档](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-microsoft-decision)还把接口的三种题区分得很清楚：`choice` 从固定标签中选，并给每个选项的概率；`noul` 给一个条件为真的概率；`score` 把有序等级的概率折成一个加权值。Learn 明说，**score 更适合作相对排序和阈值，不宜当绝对校准等级**。如果旧系统的放行线是按另一种题型、另一种模型的 `confidence` 字段调出来的，把同一个 0.9 原样搬给新模型，就是省掉了最重要的一次验证。我们在[此前的 Jev 对照](/blog/jev-or-open-model-typed-decisions)已经展开过高置信不等于正确以及选择性自动化；这里要记住的是，新模型的图并没有给你的阈值盖章。 对于信贷、就业、医疗或其他会实质影响个人权益的判断，[模型卡的用途限制](https://ai.azure.com/catalog/models/Microsoft-Decision-1)写得更明确：不能让它成为唯一的自动决策者，应用必须落实适当的人为监督。把低分单发给人而高分单全部自动执行，并不能天然解决这条边界；高风险流程要先界定哪些事情根本不授权模型独断。 ![本站编辑流程示意：模型给出概率，应用按自定阈值决定放行、补验或转人工；并非微软披露的内部架构](/blog/images/microsoft-decision-1-speed-calibration-workflow.png "概率先经过应用自己的阈值与风险判断，才可能触发自动处理或人工复核；本站编辑示意，不代表厂商实际实现，也不包含实测曲线。图源：PiRouter Blog 原创") ## 后训练的 9B 基座与三条调用路，不等于三种部署都一样 Decision-1 的技术来源也值得辨清。微软说它是在开源权重的 **Qwen3.5-9B** 基座上做后训练，输出固定答案的概率；[Foundry 模型卡](https://ai.azure.com/catalog/models/Microsoft-Decision-1)说明最大输入窗口为 **32,768 token**，文本输入、JSON 输出，不能把它当成会解释来龙去脉或生成任意答案的聊天模型。这里的「开源权重」说的是**基座**，并非微软公开了 Decision-1 训练后的权重；原厂目前介绍的是托管调用。微软还说将来会考虑换用 MAI 或 OpenAI 等基座，这是一项计划，不是已经更换，也不是现有阈值能永久沿用的承诺。 获得服务有不同入口。微软公告列出 **Microsoft Foundry** 和 **OpenRouter**；[Vercel 10 月 9 日变更记录](https://vercel.com/changelog/microsoft-decision-1-now-available-on-ai-gateway)则确认 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 放进**错了可以回退**的分类或优先级队列，和现有路径并排跑同题样本；若目标是不可逆或直接影响个人的行动，先不让一次概率判断握有放行权。微软这次给出了比一句「更快更准」更有用的材料：速度、平均准确率和校准终于可以分开读。它们能告诉你**值得测什么**，不能替你回答**哪些单据可以不经人手**。能改变这个决定的，不是下一张更漂亮的厂商图，而是你自己数据上随阈值变化的错判与复核账本。 --- ## Sources ### commandline.microsoft.com - [微软发布文](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/) ### learn.microsoft.com - [部署文档](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-microsoft-decision) ### ai.azure.com - [Foundry 模型卡](https://ai.azure.com/catalog/models/Microsoft-Decision-1) ### vercel.com - [Vercel 10 月 9 日变更记录](https://vercel.com/changelog/microsoft-decision-1-now-available-on-ai-gateway)