Microsoft-Decision-1：以數字而非句子作答的微軟模型

Microsoft-Decision-1 的模型卡裡有一行字，是其他任何 Microsoft 模型都不曾載明過的：並非為文字生成而設計。該模型於 2026 年 10 月 8 日在 Microsoft Foundry 正式推出，這是刻意限縮語言模型的用途。你給它一個情境，以及一道附有固定答案清單的問題——是／否、一組選擇題、一份評分量表、一套評分規準——它就會為每個選項回傳一個校準過的機率。沒有行文敘述。沒有解釋。沒有理由欄位。輸出就只有 JSON 數字，別無其他。它建構於開放權重的 Qwen3.5-9B之上，並由 Microsoft 進行後訓練，而 Microsoft 表示日後會將該模型改以其他主幹模型為基礎，並點名 MAI 與其他合作夥伴的模型。

這是一個比乍聽之下更奇特的產品。微軟在 2026 年的競爭地位建立在前沿聊天模型與 Copilot 之上，而 Microsoft-Decision-1 卻與兩者相反：它是一個中等規模、單一用途的評分器，全部職責就是告訴應用程式，你自己提供的選項中哪一個最可能正確，以及它有多大信心。有趣的問題不是它是否擅長寫作——它明確不擅長，也不嘗試——而是對於企業實際執行的工作負載而言，選項上的機率分布是否比另一個具備 JSON 模式的通用模型更有用的基本要素。

它確切來說是做什麼的

合約是一次呼叫輸入、一個分佈輸出。Microsoft 將支援的題目格式列為是/否、多選、評分、分類，以及以評分規準為基礎。每個選項都會取得一個分數。模型在一次呼叫中處理最多 32K 個 token 的輸入——32,768 是所聲明的上下文視窗——而實際上限是輸入加上選項集，而不是生成預算，因為沒有生成。

已發佈的使用案例，正是平台團隊會立刻認出的那些：

• AI 輸出評估 — 依據提供的評分規準為生成的回應評分，或判斷該回應是否有其獲授證據的支持。

• 分類與路由 — 將請求分類、判斷相關性、分流佇列、選擇工作流程分支。

• 代理護欄——在整合應用程式允許其執行之前，為擬議的工具呼叫或代理動作評分。

• 內容安全篩選 — 依據應用程式自訂的門檻標記內容，而非依循供應商固定的政策。

• 搜尋與文件相關性 — 判斷檢索到的文件是否回答了所提供的問題。

• 基於信心度的自動化 — 自動接受高信心度的結果，其餘則轉交人工處理。

棄權選項是值得留意的細節。當所提供的證據不足時，Microsoft 明確支援「無法判斷」這類選項，而這正是校準過的評分器與僅僅是自信的評分器之間的差別。而且由於分數是以數字回傳，升級門檻是你自己擁有的決定——由你設定在什麼情況下 0.7 會把某件事轉交給真人，而 0.95 不會。

它不會做的事

Microsoft 對於排除項目的說明異常明確，而對任何要為實際工作流程評估此模型的人來說，這些排除項目的重要性更甚於功能清單。並非專為文字生成、開放式問答、對話、翻譯或摘要而設計。它不適用於沒有封閉式問題與既定答案選項的任務，也不適用於需要輸入內容中未包含之知識的任務。它僅支援文字：輸入不含圖片、音訊或影片，輸出亦然。它不提供任何解釋或理由。

把這些放在一起讀，一條很容易踩線的界線就會浮現。這不是你可以順便要求它一併分類東西的聊天機器人，也不是你能硬掛上一個分數的摘要器。它是一個帶有 token 預算的評分函式。團隊自己的說法——它不該是關於人的重大決定中唯一的自動決策者，也不該是涉及信貸、就業、住房、保險、教育、醫療、法律權利「或類似重大領域」之決定的唯一依據——指向的是同一個方向。它的設計是坐在決策旁邊，而不是成為那個決策。

基準情況是沒有人想刊登的故事。

沒有數字。Microsoft Foundry 上 Microsoft-Decision-1 的目錄頁面有一個 Benchmarks 索引標籤，而其中沒有任何數據。取而代之的是，裡面包含一段方法論說明和一個質性主張：該模型「是依據公開與社群決策基準，以及未用於訓練的留出內部測試集進行評估」；Microsoft 報告指出，它「的表現與領先的決策模型相當，並優於以相同方法評估的其他開放決策模型」；而所使用的指標包括準確率、校準誤差、安全召回率、偽陽性率和公平性一致性，並會變動選項順序及套用配對統計檢定。

那是一份嚴謹的方法論說明，卻沒有任何已發表的結果作為佐證。這意味著如今關於 Microsoft-Decision-1 的每一項效能宣稱，都是廠商自行報告且未經重現的，而對任何評估它的人來說，誠實的立場是：校準——這個唯一能讓機率真正有用的特性——在微軟之外尚未獲得驗證。該公司確實指出了它認為該模型最強與最弱之處，這比單一的頭條分數更有用：在推理、規則應用以及對提示格式的穩健性方面最強；在分類、檢索、公平性、工具使用及大多數多語言任務上具競爭力；在專業領域知識任務上則較弱。

在功能列表之前，值得先讀一讀自我報告的侷限性。分數會隨措辭與選項排序而變動，而一個框架不佳的問題依然會回傳分數。校準在熟悉的工作類型上最為可靠。它可能依賴過時的知識，而且不提供任何解釋。關於多語言涵蓋範圍：列出支援 25 種語言，包括日語、韓語、阿拉伯語、越南語、泰語、土耳其語、印地語、孟加拉語、史瓦希里語、希伯來語、波斯語和烏克蘭語，但 Microsoft 表示涵蓋範圍、品質與校準「可能因語言而異」，並將非英語——尤其是資源較少的語言——列為表現不佳的領域。底層的 Qwen3.5-9B 支援超過 200 種語言；經後訓練的模型則支援其中四分之一。

你如何取得它，以及它的費用是多少

Microsoft-Decision-1 在 Microsoft Foundry 中以「Direct from Azure」產品組合下的託管 API 形式發佈。模型權重並未發佈——這不是開放權重發佈，且沒有可供下載的 Hugging Face 儲存庫。任何能發出 HTTPS 要求的應用程式，都可使用 Foundry 端點和標準 Azure 驗證進行整合。部署清單顯示，在隨用隨付或保留的佈建輸送量上提供無伺服器與統一端點選項，標準 SKU，且已停用批次推論；訓練揭露報告指出，訓練資料集首次使用於 2026 年 9 月，且收集仍在進行中。

模型頁面上並未公布定價。型錄的定價欄位會連到 Microsoft 的模型定價頁面，而不是直接列出輸入與輸出費率，因此 Decision-1 呼叫的每 token 成本，必須到 Azure 定價介面查詢，或從帳單上讀取。對於任何想在大量規模下推估每次決策成本的人來說，這是一個實實在在的缺口，值得直接講明，而不是用估算帶過。當你真的要計算價格時，有兩件事值得知道：成本的 0% 是輸出 token，因為根本沒有輸出 token；批次推論是關閉的，所以你無法像使用生成式模型那樣，透過批次通道來攤平大量評分作業的成本。

它在此中的定位，是在呼叫的另一端。我們不託管 Microsoft-Decision-1，而且它不是一個會傳回機率而非文字的模型——那不是你會把聊天補全導向的模型。我們確實提供的是這個模式中會生成的那一半：那些撰寫評分標準、草擬候選回覆，或產生 Decision-1 隨後評分的工具呼叫的模型。這些模型位於一把與 OpenAI 相容的金鑰之後，該金鑰上有超過 200 個模型，價格為 供應商定價原樣傳遞、0% 加價，因此評審模型若供應商降價，我們這邊同日就會生效。如果你正在建構一個由一個模型撰寫、另一個模型評分的評估迴圈，評分呼叫會送到 Microsoft，而生成呼叫可以送到任何地方——包括透過路由 DSL；當你想要的是評審小組而不是單一評審時，它會將多個模型組合成單一呼叫。

為什麼評分器與更好的聊天機器人是不同的押注

微軟在此販售的模式，其實在開源領域早已存在。InternLM 的 Intern-Decision-4B、Liquid AI 的 d1-3B、Convai Innovations 的 Laya，以及 Jared Palmer 的 Kev 系列，都能在不生成文字的情況下，針對提供的選項回傳經過校準的分布，而且其中大多數都是 Apache-2.0 授權的權重，你可以免費在自己的硬體上執行。微軟的產品則有三個差異點，而這些差異與基準測試無關：它是受管理的 API，附帶 Azure 驗證、計費與治理功能，因此符合企業採購流程，而這是從 Hugging Face 下載做不到的；它的基礎模型是 9B 模型，比該領域大多數模型都大；而且它附有負責任 AI 評估與有文件記錄的評估方法，這往往是受監管部署真正的把關要求。

它所沒有附帶的，是一個數字。面對會公布 Brier 分數與期望校準誤差——這兩個數字能告訴你 0.8 是否真的代表 0.8——的公開競爭對手，Microsoft 只公布了一套方法論，卻沒有公布任何結果。在獨立的校準測試出現之前，使用 Microsoft-Decision-1 時站得住腳的做法，就是它自家文件所建議的方式：用能代表你使用情境的資料進行驗證、依你的錯誤成本設定閾值、一律納入棄權選項、在選項順序可能使答案產生偏差時隨機排列選項順序，並對任何後果重大的事保留人類監督。這對任何評分器來說都是好建議。對於一個公司外沒有人測量過其校準的評分器來說，這尤其是好建議。