Microsoft-Decision-1 已在 Foundry 上線。其 Benchmarks 索引標籤是空的。

本週 Microsoft 發布最有趣的地方，不在於 Microsoft-Decision-1 能做什麼，而在於 Microsoft 選擇不披露哪些相關資訊。該模型已上線：於 2026 年 10 月 8 日在 Microsoft Foundry 正式推出，比本文撰寫時間早兩天。它是一個決策評分模型——你給它一個狀態和一個附有固定答案選項的問題，它會針對每個答案回傳一個經校準的機率——由 Microsoft 在開放權重 Qwen3.5-9B上進行後訓練，對最多 32,768 個詞元執行一次前向傳遞，並輸出 零個輸出詞元，因為它根本不生成任何內容。其目錄頁面有一個 Benchmarks 分頁。裡面只有一段方法論說明，沒有任何數字。

那個落差才是重點，而且它比又一則「Microsoft 推出某個模型」的消息更有用。關於評分器的每一個認真問題，本質上都是校準問題——回傳的 0.8 是否真的代表 0.8——而一場發表若連一個 Brier 分數或期望校準誤差數字都沒有，就等於把唯一真正重要的數字留給採用它的人自己去衡量。接下來要談的是 Foundry 頁面實際上記錄了什麼、它明顯略過了什麼，以及評估團隊本週能對此做些什麼。

具體來說，發布了什麼

Microsoft-Decision-1 是託管式 API。其契約是：一次呼叫進、一個機率分布出，整條路徑中沒有任何解碼迴圈：要求會帶上要判斷的素材，以及一個答案集有限的問題，而回應則帶有每個選項的機率。Microsoft 列出支援的問題形式包括是/否、選擇題、評分、分類與以評分規準為基礎，全都包含在單次最多 32K token 的呼叫內。它是純文字的——不接受影像、音訊或視訊輸入，輸出也僅有數字。

排除項目和功能說明一樣直白，而且值得優先閱讀：並非為文字生成、開放式問答、對話、翻譯或摘要而設計，也不適用於需要輸入內容以外知識的任務。它不會產生理由說明。官方公布的應用情境，都是平台團隊已有標記決策可做的場合——依據評分標準為生成的答案評分、判斷檢索相關性、分流佇列、把關代理程式提議的工具呼叫、依應用程式自訂（而非供應商固定政策）的門檻篩選內容，以及自動接受高信心的結果，其餘則向上呈報。

從部署清單中有兩項作業細節格外突出。第一，Microsoft 明確支援在所提供的證據不足時採用棄權選項，例如「無法判斷」——這正是經過校準的評分器與僅有自信的評分器之間的差異，也是讓閾值化得以奏效的關鍵。第二，批次推論已停用。你無法像使用生成式模型那樣，透過批次通道來攤銷大規模的評分執行，因此每次呼叫的延遲是你管線的延遲，而不是離線作業要處理的問題。

散布僅限於 Foundry，屬於「Direct from Azure」產品組合，以標準 SKU 上的無伺服器或統一端點部署形式提供——隨用隨付或保留的佈建輸送量。權重並未散布。沒有 Hugging Face 儲存庫、沒有下載、沒有微調途徑，也沒有自架選項。應用程式透過 HTTPS 搭配標準 Azure 驗證進行整合。訓練揭露資訊回報，該資料集首次使用於2026 年 9 月，且蒐集仍在持續進行；這是訓練資料與 GA 日期之間可能的最短距離，對於在他人已發布的基礎模型上進行後訓練而言實屬正常。

「基準測試」分頁，全文引用。

以下是 Microsoft 所發布關於該模型表現如何的全部內容。評估使用了「公開與社群決策基準，以及未用於訓練的保留內部測試集」。指標包括準確率、校準誤差、安全召回率、假陽性率與公平性一致性。選項順序經過變動。使用了配對統計檢定。該主張是定性的：Microsoft-Decision-1「表現與領先的決策模型相當，並優於以相同方法評估的其他開放決策模型。」

那是一套稱職的評估設計，卻只描述了設計、沒有附上結果。指出這一點並不是指控——一段沒有表格的方法論段落，是一個具體且可查核的選擇，而且它不同於這個小型類別中其他成員所做的選擇。微軟隱含拿來比較的開放決策模型都會公布自己的數字：InternLM 的 Intern-Decision 系列在其模型卡上印出 Brier 與期望校準誤差數值，TypeSafe 的 Jev 兩者都公布，而 Liquid AI 的 d1 系列則隨權重一併附上準確率表。微軟是這個群體中最大的公司，也是唯一要求別人憑信任接受它的那一家。

該公司確實會說明它認為模型在哪些方面強、哪些方面弱，這比單一頭條分數更具可操作性。最強：推理、規則應用，以及對提示格式的穩健性。具競爭力：分類、檢索、公平性、工具使用，以及大多數多語言任務。最弱：專業領域知識。自我報告的限制也同樣坦白——分數會隨措辭與選項排序而變動，問題框架不佳仍會回傳分數，校準在熟悉的任務類型上最強，而當答案看起來有誤時，沒有任何解釋可供稽核。

語言涵蓋範圍也帶著同樣形式的但書。25 種語言被列為支援語言，涵蓋日語、韓語、阿拉伯語、越南語、泰語、土耳其語、印地語、孟加拉語、斯瓦希里語、希伯來語、波斯語與烏克蘭語等，並明確警告涵蓋範圍、品質與校準「可能因語言而異」，而非英語、尤其是資源較少的語言，則是表現欠佳的領域。Qwen3.5-9B 基礎模型支援遠超過 200 種語言。後訓練保留了其中約四分之一，而校準正是在這四分之一上擬合的。

頁面上也沒有價格

型錄的定價欄位不會印出費率。它會連結到 Microsoft 自家的模型定價介面，因此每次決策的成本是要從 Azure 或帳單上讀取，而不是從模型卡上讀取。對於任何要大規模估算每次決策成本的人來說，這是一個實實在在的缺口，值得直接說明，而不是用猜測帶過。有兩件事確實源自其架構，也值得納入該估算中：呼叫成本的 0% 是輸出 token，因為根本沒有輸出 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 正式全面推出，是一款純文字、32,768 個詞元的決策評分器，建構於 Qwen3.5-9B 之上，可針對你自己的選項集傳回經校準的機率，輸出詞元數為零，且無需下載任何權重。其強項在於乾淨的單次執行契約、設計內建的棄權路徑，以及隨附的 Azure 驗證、計費與治理；其弱點是，除了 Microsoft 之外，沒有人——包括 Microsoft 自己——公布過它校準得有多好的數字。請把這次發布視為一項 API 開始可用，而不是一項能力已被確立，並在任何下游事物依賴某個門檻之前，先用你自己標註過的案例實際測試它。