Microsoft-Decision-1 已在 Foundry 上线。其基准测试选项卡为空。

本周微软这次发布最有趣的地方，不在于Microsoft-Decision-1能做什么，而在于微软选择不在它的说明里印出什么。该模型已上线：它于2026年10月8日在 Microsoft Foundry 上正式全面可用，比本文撰写早两天。这是一个决策评分模型——你给它一个状态和一个答案集固定的问题，它会为每个答案返回一个经过校准的概率——由微软在开放权重的 Qwen3.5-9B上进行后训练，对最多 32,768 个 token 只运行一次前向计算，并输出 零个输出 token，因为它根本不生成任何内容。目录页面上有一个 Benchmarks 标签页。里面只有一段方法说明，没有任何数字。

这个缺口本身就是故事，而且它比又一条“微软发布了一款模型”的新闻更有价值。关于评分器的每一个严肃问题，归根结底都是校准问题——返回的 0.8 是否真的意味着 0.8——而一次发布若连一个 Brier 分数或期望校准误差的数字都没有附带，就等于把唯一真正重要的那个数值留给采用它的人去测量。接下来要说的是：Foundry 页面实际记录了什么、它明显遗漏了什么，以及评估团队本周可以为此做些什么。

具体发布了什么

Microsoft-Decision-1 是一个托管 API。其约定是：一次调用输入，一个分布输出，路径中任何地方都没有解码循环：请求携带待评判的材料，以及一个答案集有界的问题，响应则携带每个选项的概率。Microsoft 列出的受支持问题形式包括是/否、多项选择、评分、分类和基于评分标准，全部都在单次调用内完成，最多支持 32K tokens。它仅支持文本——没有图像、音频或视频输入，并且输出只有数字。

排除项与功能一样直白地列出，而且值得放在最前面阅读：它并非为文本生成、开放式问答、对话、翻译或摘要而设计，也不适用于需要依赖输入中未包含的知识的任务。它不会给出推理依据。官方公布的用例，都是平台团队本就需要做出带标签决策的场景——依据评分标准为生成的答案打分、判断检索相关性、对队列进行分诊、对提议的智能体工具调用进行把关、按照应用自定义而非厂商固定策略的阈值筛查内容，以及自动接受高置信度的结果、同时将其余结果升级处理。

部署清单中有两个操作细节很突出。第一，当提供的证据不足时，Microsoft 明确支持诸如“无法判断”这样的弃权选项——这就是经过校准的评分器与仅仅自信的评分器之间的区别，也正是它让阈值处理得以奏效。第二，批量推理被禁用。你无法像使用生成式模型那样，通过批量通道来分摊大规模评分运行的成本，因此单次调用的延迟是你管道的延迟，而不是离线作业的问题。

仅通过 Foundry 分发，归属“Direct from Azure”产品组合，以标准 SKU 上的无服务器或统一端点部署形式提供——按用量付费或预留预配吞吐量。模型权重不予分发。没有 Hugging Face 仓库，没有下载，没有微调路径，也没有自托管选项。应用程序通过 HTTPS 与标准 Azure 身份验证进行集成。训练披露信息显示，该数据集首次使用于 2026 年 9 月，且数据收集仍在进行中，这是训练数据与 GA 日期之间可能的最短距离，对于在他人已发布的基座模型上做后训练而言属于正常情况。

基准测试标签页，全文引用

以下是微软发布的有关该模型表现情况的全部内容。该评估使用了“公共和社区决策基准，以及未用于训练的留出内部测试集”。指标包括准确率、校准误差、安全召回率、假阳性率和公平性一致性。选项顺序有所变化。应用了配对统计检验。该说法是定性的：Microsoft-Decision-1“的表现与领先的决策模型相当，并优于用相同方法评估的其他开放决策模型”。

这是一个扎实的评估设计，但只描述了设计，没有给出结果。指出这一点并非指控——一个没有表格的方法论段落是一个具体、可核查的选择，而且它与这一小类中其他成员所做的选择不同。微软隐含比较的那些开放决策模型会公布自己的数字：InternLM 的 Intern-Decision 系列在其模型卡上印出 Brier 和期望校准误差数值，TypeSafe 的 Jev 两者都发布，Liquid AI 的 d1 系列则随权重一起附上准确率表格。微软是这组公司中最大的一家，也是唯一一家要求别人凭信任接受它的。

该公司确实说明了它认为该模型在哪些方面强、哪些方面弱，这比一个概览性分数更具可操作性。最强：推理、规则应用以及对提示格式的稳健性。有竞争力：分类、检索、公平性、工具使用以及大多数多语言任务。最弱：专业领域知识。其自我报告的局限也同样坦诚——分数会随措辞和选项顺序而变化，一个表述不佳的问题仍然会返回分数，校准在熟悉的任务类型上最强，而且当答案看起来有误时，没有任何解释可供审查。

语言覆盖范围也带有同样形式的注意事项。25 种语言被列为受支持，涵盖日语、韩语、阿拉伯语、越南语、泰语、土耳其语、印地语、孟加拉语、斯瓦希里语、希伯来语、波斯语和乌克兰语等，并明确警告称，覆盖范围、质量和校准“可能因语言而异”，且非英语、尤其是低资源语言，是表现欠佳的领域。Qwen3.5-9B 基础模型支持远超 200 种语言。后训练大约保留了其中的四分之一，而校准正是在这四分之一上拟合的。

页面上也没有价格

该目录的定价字段并不印出费率。它外链到微软自家的模型定价界面，因此单次决策的成本得从 Azure 或账单上读，而不是从模型卡片上读。对于任何要按规模对单次决策成本建模的人来说，这是一个实实在在的缺口，值得直白说明，而不是靠估算。架构确实带来两点结果，值得纳入这一估算：一次调用成本中有 0% 是输出 token，因为根本没有输出，而选项集属于输入的一部分，所以一个带有六十二个描述性选项的问题，单次调用成本高于一个是/否问题——你花钱买的是自己写的那套评分标准，而不是答案。

为什么这种发布形式才是有趣的部分

决策评分器押的是一个赌注：企业真正需要的原语不是更好的写手，而是一个更便宜、更可靠的裁判。这个赌注只有在概率值得信赖时才会有回报，因为评分器下游的一切都是阈值：0.7 升级给人工，0.95 自动接受，而这条线划错的代价是以糟糕的自动化决策来偿付，而不是以 token 来偿付。厂商交付评分器却不附上校准表，等于要求每个客户在自己的数据上重新把它推导一遍。

微软自己的文档推荐的恰恰就是这一点，这既缓和了批评，同时也让实际结论更加鲜明。用能代表你自己使用场景的数据进行验证。根据你出错的代价来设定阈值，而不是沿用默认值。始终提供弃权选项。在排序可能使答案产生偏差的地方，随机化选项顺序。对任何有重大影响的环节，都要保留人工介入。这对任何评分器来说都是中肯的建议。而对这一个来说，这是唯一可用的建议。

这周试试，但不做承诺

成本最低的评估方式，是选一个你已经在手工做的决策，凑出两百个带标签的案例，配上你的应用实际会提供的答案集，然后让它们跑一遍 Foundry 部署。计算输出上的期望校准误差，你对 Microsoft-Decision-1 的了解就会超过微软就此发布过的任何内容，因为你是在自己的数据分布上测量它，而不是在一个内部留出的测试集上测量它。这只是一个下午的工作量，却能让整个基准测试问题从此作古。

OrcaRouter 所处的位置，是评分回路中的另一半，而且是负责生成的那一半。我们不托管 Microsoft-Decision-1，它也不在我们的目录中——一个返回概率而非文本的模型，不是你会把聊天补全路由过去的东西，这里任何内容都不应被解读为可用性声明。我们那一把兼容 OpenAI 的密钥背后，是超过 200 个模型构成的模型池，负责写作：起草评分标准的模型、生成候选答案的两个模型、发出工具调用 Decision-1 然后在其运行前进行评分的那一个。提供商标价按 0% 加价透传，因此生成器一侧的降价当天就会体现在我们这里；当单个提供商性能下降时，自动故障转移能让生成这一环保持存活——在一个对所见一切都要评分的流水线里，这比在偶尔回答用户的流水线里更重要。如果你不想只选一个评判者，路由 DSL 可以把多个模型组合成一次调用，而模型融合会把它们的一致性报告为一个评分字段，而不是一段你必须阅读的文字。

能改变这篇文章的，会是一张表格。把 Brier 分数和 ECE 公布出来，或者让一次独立运行登上某个排行榜，那么上述评估就会变成一种佐证，而不是现存的唯一证据。在此之前，对 Microsoft-Decision-1 的准确描述是有限的：权重是真实的，契约的文档化程度胜过大多数托管版本所能做到的，弃权选项是设计之初就内置的，而非事后加装的，而性能声明只是一句话——一句写得很好的话，却完全没有附上任何数字。

最重要的一点

Microsoft-Decision-1 于 2026 年 10 月 8 日在 Microsoft Foundry 上正式发布（general availability），它是一个仅文本、32,768 token 的决策评分器，基于 Qwen3.5-9B 构建，能够针对你自己的选项集返回经过校准的概率，输出 token 为零，也无需下载权重。它的优势在于一份简洁的单遍契约、一条设计上就内建的弃权路径，以及附带的 Azure 身份验证、计费和治理；它的弱点在于，Microsoft 之外没有人——包括 Microsoft 自己——公布过它校准得有多好的数字。把这次发布当作一个 API 开始可用，而不是一项能力已经确立，并且在下游任何东西依赖某个阈值之前，先用你自己标注的案例让它跑一遍。