Microsoft-Decision-1 發表：35 倍快在哪裡？Agent 決策評分解析（2026）

2026 年 10 月 9 日，微軟 Achint Srivastava 在 Command Line 發布了這篇文章〈Introducing Microsoft-Decision-1, our model for fast decision-making〉，宣布 Microsoft-Decision-1。它把「從既定選項中做判斷」獨立成一種模型服務：軟體拿到分數，就能決定把工單送去哪裡、讓 Agent 繼續，或先停下。

吸引人的數字是微軟宣稱的約 35 倍中位延遲差距。但一次評分更快、一次判斷更準、整件工作更早完成，是三種不同的結果。先看模型改變了什麼，再讀測試條件，最後判斷哪一段工作值得交給它。

Microsoft-Decision-1 的核心：把選項交出來，讓模型評分

When given a fixed set of answer options, Microsoft-Decision-1 provides a calibrated probability score for each option.

中文：給定一組固定答案選項時，Microsoft-Decision-1 會替每個選項提供經校準的機率分數。

Achint Srivastava，Microsoft Command Line

想像客服收到「付款兩次，但帳號仍無法登入」。你先定義帳務、技術、帳號和資訊不足等選項，再讓模型評估。它解決的是已定義範圍內的判斷；把候選部門與交接規則寫清楚，仍是系統設計者的工作。

Foundry 模型卡確認，它以 Qwen3.5-9B 為基礎，經微軟後訓練；支援固定選項、評分規準及單次呼叫評分，輸入上限為 32K tokens。模型卡也明確寫出：它只處理文字，不產生解釋或理由，並可加入「無法判定」選項。這些是產品的輸入輸出邊界，不是它在你的工單上必然可靠的證據。

這種分工已有其他供應商探索。Cloudflare 在 10 月 1 日的 Clef 公告也把有界、結構化決策放進工作流。這讓比較的問題更具體：同一組候選答案、相同資料和部署條件下，誰能用較少等待交出可採用的判斷？

Microsoft-Decision-1 的 35 倍：先把三張成績單拆開

原文更新後的總表，把準確率、延遲和校準並列。微軟報告 36 項基準、147,137 道題的平均準確率為 83.5%；Microsoft-Decision-1 的中位延遲為 85 ms，P95 為 125 ms，GPT-6 Sol 的參考值是 3.01 秒，因此提出約 35 倍的比較。這些是微軟公告中的測試與比較結果，本文沒有呼叫模型重測。

最重要的註腳是測量路徑：微軟自己的數字來自同區域 Foundry，其他延遲採用 JevBench v1.6.1 的 adjusted median。它們並非全部由同一端點、同一網路條件重跑。原文還描述輸入擾動與安全測試，但這些廠商測試應各自保留任務範圍，不能合併成所有場景的可靠性保證。

校準也沒有跟準確率一起奪冠：更新後總表中，Microsoft-Decision-1 的校準分數為 92.2，低於 Jev 的 93.7 與 Quyet 的 93.1。讀者若要依機率自動放行，這一欄可能比「平均答對多少題」更接近自己的問題。

外部證據提醒了什麼？測量方法本身會改變比較

JevBench 的資料卡區分原始與調整後的中位延遲，並標示價格是估算或來自何種證據；它也提醒，公開彙總資料不能完整重建密封題目的重跑。這份方法說明支持的是「如何讀測量」，不能替微軟新增一份獨立重測成績。

因此，較合理的讀法是：公告顯示專用評分值得評估，但部署地點、題目、候選答案數量、輸入長度、排隊與重試，都要放回比較。若你現在使用生成模型先寫理由再選答案，換成直接評分會改變輸出契約；省下的是那段工作，而不是證明兩個模型能互相接替所有任務。

原文列出的內部用途包括 Xbox 意見分類、Copilot 品質檢查、事故知識檢索，以及 Microsoft Discovery 的實驗重規劃。這些案例說明它想進入哪些流程；成效仍是微軟對自家部署的報告，不能直接拿來替你的團隊估算節省比例。原文的訴求，是依工作選模型，讓決策評分成為 Agent 的控制零件。

價格很低，接入條件仍要逐項讀

截至 2026 年 10 月 11 日，OpenRouter 模型頁及其 公開端點資料列出 Azure 提供者，輸入價格為每百萬 tokens 0.042 美元，輸出價格為零。這確認了目錄與報價，不代表本文已驗證付費呼叫。長輸入、多個判斷、重試與其他工具費用，仍要算入整件工作。

Foundry 的狀態文字則有差異：10 月 9 日發布文寫 public preview，模型目錄的 Lifecycle 標示 GA。這裡保留兩者差異；評估採用時，應核對自己訂閱中可部署的版本、區域與服務條款。

Foundry 接入文件把問題分成二元機率、固定選項與有序尺度，並建議在自己的標記資料上調整門檻。它也明示措辭、問題和選項順序會影響分數。因此，公告中的穩定性測試不能替代你對實際選項的檢查。

AlphaLab 的判讀：快判斷的價值，要跟錯判代價一起算

一、我同意把窄判斷獨立出來，但要保留完整候選集合

把「選部門」與「寫回覆」分開，讓兩段各自有驗收標準，是有價值的設計。前段可看轉交是否正確，後段可看資訊是否完整。但如果付款與登入問題同時出現，固定選項只有一個部門，最高分也可能只是最接近的選項。先決定跨部門、資訊不足與未知情境怎麼走，再評估模型。

二、我存疑的是把中位延遲當成整件工作的倍率

做一個純算式例子：假設判斷只占原工作時間的 10%，其餘 90% 是查資料、工具或交付；即使這 10% 真的縮短成原本的 1／35，總時間仍是原本的 90.29%，整體約快 1.11 倍。這不是模型實測，只是在說：你得先知道等待在哪裡。

若瓶頸恰好是連續多輪的選擇，收益可能明顯；若瓶頸在工具或錯判後重做，省下單次延遲的價值便有限。相鄰的 Ultrafast 服務層分析也提出同一個評估問題：加速最後省到哪一段交付時間？

三、機率是可以驗的承諾，不是放行證書

「這一類分數約 0.9 的判斷，實際有多少正確？」與「哪個選項排名最高？」不同。Guo 等人的 2017 年校準研究研究的正是信心與正確機率的對應；它沒有測試 Microsoft-Decision-1，卻提供了讀機率的基本問題。

對你的客服資料，應把高信心但選錯的案例獨立列出。繁體中文、混合語言、缺欄位與罕見問題，都可能改變門檻適用性。門檻也應依錯誤代價設計：分錯文章標籤可重新分類，錯誤退款或刪資料則需要更嚴格的執行規則。

四、把模型分數與動作權限分開，才有可追查的控制

模型卡明確排除以它作為信用、就業、住房或醫療等重大個人決策的唯一依據。對一般 Agent，分數同樣應進入既有的權限與停止規則，再決定是否執行。即使安全評分很高，也不該讓原本沒有刪檔或付款權限的流程取得那些權限。這是控制系統的設計要求，不是對模型安全成績的反向推測。

現在可以做的一件事：先挑一個可回復的分類點

先挑一個既有流程，例如把工單送入待辦佇列，保留現行方法作對照。整理一批已有標記的代表案例，另列多意圖、資訊不足和未知類別；凍結選項、版本與門檻，讓新模型先只記錄判斷，不直接改正式工單。

比較時一起記正確率、高信心錯判、需要升級處理的比例、P50／P95、總費用與重試。再把改寫措辭、重排選項和尖峰流量加入測試。你要找的結果是「在可以接受的錯判代價內，完成同一批工作的等待或成本下降」，而不是讓供應商的最高倍率出現在自己的簡報。