一位用户反馈：“每次付款，结账页面都会报错。”客服系统收到这条消息后，需要判断该交给哪个团队、问题有多紧急、是否需要人工介入。团队、优先级和处理方式都已事先定义好，模型要做的，就是根据消息选出合适的结果。
Microsoft-Decision-1 面向的正是这类需求。微软于 2026 年 10 月 9 日发布这款决策评分模型，用于软件工作流中的分类、路由与评估。如果你正在使用或评估 Jev，也可以将它纳入比较。微软公告提到了 JevBench，并在更新中补充了与 Jev 的准确率和概率校准对比。来源：微软发布公告。
本文依据官方文档、厂商公布的测试和独立研究整理。资料核查日期为 2026 年 10 月 15 日。
Microsoft-Decision-1 如何工作
微软在 Qwen3.5-9B 的基础上进行了后训练，让模型通过一次前向计算为候选选项评分。应用只需提供上下文和选项，就可以根据返回结果选择工具或决定下一步操作。来源：Foundry Labs。
这里需要分清“格式正确”和“判断正确”。模型会从给定选项中作答，程序无需再从一段文字里提取类别，但它仍可能选错。因此，测试时既要检查格式，也要看判断是否准确、出错会造成什么影响。
| 问题类型 | 适合问什么 | 返回结果 |
|---|---|---|
noul | 某个条件是否成立 | 答案为“是”的概率，范围为 0 到 1 |
choice | 应选择哪个预设选项 | 选择结果及各选项概率 |
score | 按给定标准应评为多少分 | 评分及各等级的概率 |
三种类型见 Foundry 接入文档。其中，score 的含义取决于你定义的评分标准。例如，“紧急程度 3 分”和“回答质量 3 分”不能直接比较。
适合哪些任务
常见用途可以分为四类，均在 Foundry Labs 的能力介绍中列出：
- 工单分类：根据内容，将问题分配给相应团队。
- 模型路由：先列出可用模型及其适用条件，再为请求选择合适的模型。
- 回答评估：提供参考资料和评分标准，判断回答是否符合要求。
- Agent 控制：在继续、重试、停止和请求复核之间选择下一步动作。
以客服系统为例：可以分别询问“该交给哪个团队”“有多紧急”和“还缺哪些必要信息”。程序根据这些判断将工单分配给相应团队，或请用户补充说明。如果还需要撰写回复，再交给生成模型。
如果一项判断涉及多个独立因素，最好拆成几个具体问题，再由代码汇总结果。例如，问题是否紧急与该由哪个团队处理，可以分开判断。这样既方便调整规则，也容易查明哪一步出了错。
价格与接入方式
微软公告标价为 每百万输入 token 0.042 美元，输出免费，提供 Microsoft Foundry 和 OpenRouter 入口。部署前仍应核对具体渠道的最新计费条款。来源：微软价格公告。
按此输入单价，假设发起 1,000 次请求，每次计费输入平均为 1,000 token，输入费用合计为 0.042 美元。估算整个流程的成本时，主要看三部分：
- 输入费用：包含上下文、提示词和选项描述。
- 其他调用费用：包括重试和后续生成模型的调用。
- 人工费用：处理不确定结果、分类错误和需要复核的案例。
Foundry 使用以下专用接口：
POST <your-foundry-resource-endpoint>/providers/microsoft/v1/systemone下面是按文档改写的工单分类请求。将 model 占位符替换为自己的部署名称，并通过 Microsoft Entra ID 或 API key 完成身份验证。示例展示了工单分类所需的请求格式。
{
"model": "<your-deployment-name>",
"state": "Checkout fails with an error whenever I try to pay.",
"questions": {
"team": {
"type": "choice",
"instructions": "Choose the team that should investigate the primary issue.",
"criteria": {
"billing": "Charges, invoices, or refunds without a software failure",
"engineering": "Software errors, failed integrations, or outages",
"support": "Account access or product usage questions",
"needs_review": "Insufficient information to assign a team"
}
}
}
}执行后续操作前，应检查返回的选项是否有效，并做好超时和限流处理。这个请求应发往专用决策接口。通过 OpenRouter 等网关接入时，接口地址、身份验证方式和模型标识可能有所不同。接入以 Foundry 文档或 OpenRouter 模型页为准。
性能数据应该怎么看
微软公布的基准结果主要包括：
- 测试规模：36 项基准，覆盖近 15 万题。
- 准确率：在此次参与比较的模型中最高。
- 速度：以中位响应时间衡量，约为 GPT-6 Sol 的 35 倍、H2O-Lightning-4B v1.1 的 2.5 倍。
这些数字比较的是指定模型，不能据此推算它比 Jev 快多少。输入长度、部署区域、并发、网络、批处理和重试都会影响用户实际等待时间；多个数据集的平均准确率，也不一定反映模型对某个关键业务类别的识别能力。
独立研究方面，System One Bench公开了测试脚本和评分代码。项目介绍显示，测试覆盖 16 个数据集、3,250 个案例和 4,850 个决策，包含英语、法语、阿拉伯语，并于 10 月 12 日加入了 Microsoft-Decision-1 的测试。它通过同一个网关，向各模型提交相同的上下文和问题。
这些代码可以作为设计测试的参考。不过，各模型的测试日期不同，网关也会影响响应时间，综合成绩还取决于评分规则。阅读时应结合具体任务、模型版本和错误案例，也不宜将其分数与微软自测分数直接放在一起排名。
Microsoft-Decision-1 与 Jev 怎么选
两款模型都能返回程序可以直接使用的判断结果，也支持相近的问题类型，适合放到同一业务场景中比较。比较时要留意文档和测试的日期，确认数据对应哪个版本。
| 对比项目 | Microsoft-Decision-1 | Jev |
|---|---|---|
| 常见问题类型 | noul、choice、score | Noul、Choice、Score |
| 官方 API | Foundry 专用决策接口 | TypeSafe POST /v1/systemone |
| 10 月 15 日核查的输入标价 | 0.042 美元／百万 token | 0.042 美元／百万 token |
| 输出 token | 免费 | 免费 |
| 概率与置信度 | 微软称其返回经过校准的选项概率 | 提供选项概率，并用 confidence 概括模型的确定程度 |
| 数据处理位置 | 支持全球部署，部分地区可限定数据处理区域 | 需根据服务条款确认数据处理要求 |
| 生产延迟 | 从应用所在区域测量实际响应时间 | 使用相同请求和并发条件测量 |
| 版本管理 | 记录部署配置和响应中的模型标识 | 指定版本 ID，并记录实际响应版本 |
来源：微软部署文档、Jev 模型与价格、confidence 说明。
TypeSafe 文档已列出 10 月 14 日发布的 Jev 1.14，与 1.13 同价。文档还区分了预览版别名和稳定版别名。Jev 1.13 的测试结果不能直接代表 1.14；应固定准备上线的版本。来源：当前模型文档。
两款模型的输入单价相同，实际使用成本却未必一样。除了计费 token 数量，还要比较错误处理和人工复核费用。分词方式、一次请求中包含的问题数量不同，也会影响最终账单。
迁移还有一个容易忽略的细节：Jev 的 confidence 概括了概率分布所反映的确定程度，并不等于最高选项的概率。切换厂商后，应重新测试自动处理阈值。来源：confidence 语义。
可以根据现有技术环境，选择更方便的起点：
- 已使用 Azure：先试接 Foundry，看看能否沿用现有的身份验证和部署流程。
- 已接入 Jev：保留现有客户端和业务规则，接入另一款模型做对照测试，再决定是否迁移。
接入是否方便与模型是否准确，需要分别评估。
上线前，先用自己的数据测一测
可以按以下步骤组织测试：
- 准备样本：收集已有正确答案的常见问题，以及有歧义、类别少见或信息不足的案例；中文业务使用真实中文输入。
- 留出测试集：保留一部分样本用于最终评估，不拿来调整提示词。
- 统一比较条件：让两款模型遵循相同的业务规则，回答同一组问题。
- 单独记录优化结果：如果为各模型分别调整了提示词，将结果与最初的比较分开列出。
- 保留测试记录：记下数据版本、模型 ID、部署区域、接口和并发数，方便日后复查。
| 指标 | 需要了解什么 |
|---|---|
| 准确率与各类别错误 | 关键案例是否被误处理 |
| 各概率区间内的实际准确率 | 阈值能否作为自动执行依据 |
| 相同错误率要求下的自动处理比例 | 能减少多少人工复核 |
| 包含重试的端到端 p50/p95 延迟 | 是否满足工作流响应要求 |
| 超时、限流与无效响应 | 有多少请求需要重试或人工介入 |
| 每 1,000 条成功处理任务的总成本 | 整个处理流程能否降低成本 |
正式测试前，先确定通过标准。例如先确定自动分流可接受的错误率，再比较各模型在该错误率下能处理多少任务。遇到歧义会转人工的模型，有时比始终很有把握、却不时判断错误的模型更实用。
常见问题
Microsoft-Decision-1 开源吗？
基础模型 Qwen3.5-9B 开放权重，但微软模型目录描述的是托管产品。本次核查未找到 Microsoft-Decision-1 权重发布；基础模型的 License 并不意味着这款模型也能下载到自己的服务器上运行。
0.9 的概率能保证判断正确吗？
不能。概率校准要看大量相似案例中的表现。例如，所有预测概率在 0.9 左右的案例，实际是否约有九成正确。它不能保证某一次判断正确。更换版本、语言、选项或输入数据后，也需要重新验证。
Jev 客户端只改 URL 就能迁移吗？
两者的请求结构相近，但仍需检查接口地址、凭证、部署名称、返回格式，以及置信度的具体含义。先完成接口适配，用已有案例做回归测试，通过后再切换生产流量。
哪个更好？
根据具体任务与服务要求选择。微软公布的数据值得关注，最终仍要看两款模型在你的业务数据上表现如何。引用已有的 Jev 测试时，也要确认版本与实际部署一致。
下一步
可以先准备一组已有正确答案的分类样本，通过 Microsoft Foundry 或 OpenRouter 进行测试。如果想用同样的任务比较 Jev，可以先在 defapi 体验 Jev API。
背景知识见什么是 System One 模型与 Jev。如果需要在自己的服务器上运行模型，可继续阅读 Jev vs Laya。相关文章的价格和测试数据以各自标注的日期为准，采购前请重新查阅厂商最新文档。