Microsoft-Decision-1：用数字而非句子作答的微软模型

Microsoft-Decision-1 的模型卡中有一行是其他任何 Microsoft 模型都从未载有的：并非为文本生成而设计。该模型在 Microsoft Foundry 上正式发布于 2026 年 10 月 8 日，它是对语言模型用途的刻意收窄。你向它提供一种情境和一个带有固定答案列表的问题——是/否、多项选择、评分量表、评分标准——它就会为每个选项返回一个经过校准的概率。没有叙述性文字。没有解释。没有理由字段。输出是 JSON 数字，仅此而已。它基于开放权重的 Qwen3.5-9B构建，由 Microsoft 进行后训练，Microsoft 表示之后会将模型重新基于其他骨干模型，并点名了 MAI 和其他合作伙伴模型。

这产品比乍听起来更奇怪。微软在 2026 年的竞争地位，靠的是前沿聊天模型和 Copilot，而 Microsoft-Decision-1 与这两者都截然相反：它是一个中等规模、单一用途的评分器，其全部工作就是告诉应用程序，在你自己的各个选项中哪一个最可能是正确的，以及它有多大的把握。有趣的问题不在于它是否擅长写作——它在这方面明确地很差，而且也没打算做好——而在于，对于企业实际运行的工作负载而言，一个关于各选项的概率分布，是否比另一个带 JSON 模式的通用模型更有用的原语。

它具体做什么

该契约是：一次调用输入，一次分布输出。Microsoft 列出的受支持问题格式包括是/否、多项选择、评分、分类和基于评分标准。每个选项都会获得一个分数。模型在单次调用中运行，处理最多 32K token 的输入——声明的上下文窗口为 32,768——而实际上限是输入加上选项集，并非生成预算，因为这里根本没有生成。

已发布的用例，正是平台团队一眼就能认出的那些：

• AI 输出评估——根据所提供的评分标准对生成的回答进行评分，或判断该回答是否以其所获证据为依据。

• 分类与路由 — 对请求进行分类、判断相关性、对队列进行分诊、选择工作流分支。

• 智能体护栏 — 在集成应用允许其执行之前，对提议的工具调用或智能体动作进行评分。

• 内容安全筛查 — 依据应用程序定义的阈值来标记内容，而非采用固定的供应商策略。

• 搜索与文档相关性 — 判断检索到的文档能否回答所提供的问题。

• 基于置信度的自动化——自动接受高置信度的结果，并将其余的升级交由人工处理。

弃权选项才是值得注意的细节。当所提供的证据不足时，微软明确支持“无法判断”之类的选项，这正是校准良好的评分器与仅仅自信的评分器之间的区别。而且，由于分数会以数字形式返回，升级阈值是一项由你掌控的决策——你可以设定：0.7 会把某件事转交给人工处理，而 0.95 不会。

它不会做什么

Microsoft 对排除项的说明异常明确，而且对于任何要为真实流水线评估此模型的人来说，这些排除项比功能列表更重要。Microsoft-Decision-1并非为文本生成、开放式问答、对话、翻译或摘要而设计。它不适用于没有封闭式问题和一组明确定义的答案选项的任务，也不适用于需要输入中不存在知识的任务。它仅支持文本：不接收图像、音频或视频，也不输出这些内容。它不提供解释或理由。

把这些放在一起读，就会浮现出一条很容易越过的边界。这不是一个你可以要求它顺带做分类的聊天机器人，也不是一个你可以硬给它加一个评分的摘要器。它是一个带有 token 预算的评分函数。团队自己的表述——它不应成为有关人的重大决策中唯一的自动化决策者，也不应成为涉及信贷、就业、住房、保险、教育、医疗保健、法律权利“或具有类似重大影响的领域”的决策的唯一依据——也指向同一方向。它的设计定位是紧挨着决策，而不是成为决策本身。

基准测试的现状是没人愿意刊登的故事

没有任何数字。Microsoft-Decision-1 的 Microsoft Foundry 目录页面有一个“基准测试”选项卡，其中没有任何数据。它取而代之包含的是一段方法学说明和一项定性声明：该模型“在公开及社区决策基准以及未用于训练的留出内部测试集上进行了评估”，Microsoft 报告称其“与领先的决策模型表现相当，并领先于采用相同方法评估的其他开放决策模型”，所用指标包括准确率、校准误差、安全召回率、假阳性率和公平性一致性，同时选项顺序有所变化，并应用了配对统计检验。

那是一份严肃的方法论描述，却附带着零个已发布结果。这意味着，如今关于 Microsoft-Decision-1 的每一项性能声明都是由厂商报告且未经复现的，而对于任何评估它的人来说，诚实的立场是：校准——那个让概率真正有用的属性——在微软之外尚未得到验证。该公司确实指出了它认为该模型最强和最弱的地方，这比一个头条式总分更有用：在推理、规则应用以及对提示格式的鲁棒性方面最强；在分类、检索、公平性、工具使用和大多数多语言任务上具有竞争力；在专业领域知识任务上较弱。

模型自述的局限值得在功能列表之前一读。分数可能随措辞和选项顺序而变化，而一个表述不佳的问题仍会返回分数。校准在熟悉的任务类型上最为可靠。它可能依赖过时的知识，而且不提供解释。在多语言覆盖方面：列出了 25 种受支持的语言，包括日语、韩语、阿拉伯语、越南语、泰语、土耳其语、印地语、孟加拉语、斯瓦希里语、希伯来语、波斯语和乌克兰语，但微软表示覆盖范围、质量和校准“可能因语言而异”，并将非英语——尤其是低资源语言——列为表现不佳的领域。底层的 Qwen3.5-9B 支持 200 多种语言；经过后训练的模型仅支持其中四分之一。

你如何获得它，以及它的费用是多少

Microsoft-Decision-1 以托管 API 的形式在 Microsoft Foundry 中分发，隶属于“Direct from Azure”产品组合。模型权重不分发——这不是开放权重版本，也没有可供下载的 Hugging Face 仓库。任何能够发出 HTTPS 请求的应用程序都可以使用 Foundry 终结点和标准 Azure 身份验证进行集成。部署列表显示了无服务器和统一终结点选项，采用即用即付或预留预配吞吐量、标准 SKU，批处理推理已禁用，并且训练披露报告称该训练数据集首次使用于 2026 年 9 月，且收集仍在进行中。

定价并未发布在模型页面上。目录中的定价字段会外链到 Microsoft 的模型定价，而不是直接列出输入和输出费率，因此 Decision-1 调用的每 token 成本必须去 Azure 定价界面查询，或从账单上读取。对于任何想按规模建模每次决策成本的人来说，这都是一个实实在在的缺口，值得直接说明，而不是靠估算。当你真的去定价时，有两点值得了解：成本的 0% 是输出 token，因为根本没有输出 token；而且批量推理已关闭，所以你无法像使用生成式模型那样，通过批量通道来分摊大批量评分运行。

OrcaRouter 在其中所处的位置，是这次调用的另一端。我们不托管 Microsoft-Decision-1，它也不在我们的目录中——一个返回概率而非文本的模型，并不是你会把聊天补全请求路由过去的模型。我们真正承载的，是这个模式中确实负责生成的那一半：那些编写评分标准、起草候选回复，或生成随后由 Decision-1 打分的工具调用的模型。它们都位于一个兼容 OpenAI 的密钥之后，该密钥下有 200 多个模型，按供应商标价原样传递，0% 加价，因此评判模型上的厂商降价当天就会在我们这边生效。如果你正在构建一个评估循环，其中一个模型负责写作、另一个负责打分，那么打分调用会发往 Microsoft，而生成调用可以去任何地方——包括通过路由 DSL，当你想要一个评审团而非单一评判者时，它能把多个模型组合成一次调用。

为什么评分器是一种不同于更优者的押注{{0}}

微软在此推销的模式在公开领域早已存在。InternLM 的 Intern-Decision-4B、Liquid AI 的 d1-3B、Convai Innovations 的 Laya 以及 Jared Palmer 的 Kev 系列，都能在不生成文本的情况下，针对给定选项返回经过校准的分布，而且其中大多数都是 Apache-2.0 权重，你可以免费在自己的硬件上运行。微软的这一产品在三个方面有所不同，而这些方面并不取决于基准测试：它是一个托管 API，附带 Azure 身份验证、计费和治理，因此适合企业采购流程，而这是 Hugging Face 下载所不具备的；其基础是 9B 模型，比该领域的大多数模型都大；并且它附带 Responsible AI 评估和一套有文档记录的评估方法，这往往是受监管部署的实际准入门槛。

它没有附带的是一个数字。面对那些公开 Brier 分数和预期校准误差——这两个指标能告诉你 0.8 是否真的意味着 0.8——的开放竞争对手，微软发布了一套方法论，却没有公布结果。在独立校准测试出现之前，使用 Microsoft-Decision-1 的合理方式是其自身文档所推荐的方式：在能代表你用例的数据上进行验证，根据错误的代价设定阈值，始终包含弃权选项，在顺序可能使答案产生偏差时随机化选项顺序，并对任何有重大后果的事情保持人工介入。这对任何评分器来说都是好建议。对于校准从未被公司外部任何人测量过的评分器来说，这尤其是好建议。