Microsoft-Decision-1 實作指南：結構化決策、信心分數與 AI Agent 分流怎麼設計？

Microsoft-Decision-1 把 AI 工作中的一個常見步驟獨立出來：依照條件，從預先定義的選項作決定。

客服收到一則訊息，系統可能先要判斷它屬於物流、商品，還是帳號問題，才知道交給誰處理。

這個步驟需要的是明確分類，長篇回答反而會增加後續讀取與轉換的工作。

微軟推出這款決策模型，讓開發者能取得結構化結果與信心資訊，再安排後續流程。

它值得用在規則清楚、選項有限的任務，成效則要用自己的資料確認。

導入的難點往往不在呼叫模型，而在選項怎麼定義，以及何時讓系統停止自動處理。

從這兩個問題出發，才能把模型能力轉成可用的分流設計。

Microsoft-Decision-1 適合哪一種 AI 任務？

Microsoft-Decision-1 是以決策為主要用途的模型，採用固定選項與單次處理方式。它適合資料分類、流程分流與依標準評估輸入，而不是替使用者產生一整篇回覆，詳見微軟發布文章。

可以把一個 AI 客服系統分成兩段。前面決定這則訊息要走哪條路，後面才根據資料與服務規則，整理給客戶的答案。

這樣的分工有助於讓結果容易使用。系統取得指定分類後，可以直接選擇流程，而不用再從一段自然語言中猜模型到底作了什麼決定。

但固定選項也有前提：選項要能涵蓋實際輸入。如果你只提供物流與商品兩類，帳號問題出現時，模型仍可能在不適合的選項中作選擇。

因此，導入前應先問這個任務是否真的有穩定分類。若每件事都需要重新理解與發明做法，通用生成模型或人工判斷可能更適合承擔主流程。

決策模型與生成模型如何分工？

決策模型可以處理「交給哪個流程」，生成模型則處理「如何整理答案」。兩者搭配時，前者應回傳明確結果，後者也應取得完成回答所需的資訊。

例如模型判斷是物流問題後，系統還要查詢物流狀態。分類結果不會自動變成訂單事實，不能只憑標籤就生成「商品已寄出」的答案。

這個區分也能降低除錯成本。答案出錯時，工程師可以先看分類是否正確，再檢查取回的資料與回覆內容，比把所有工作放在同一段對話更容易定位。

這種分工的成效，需要由自己的流程與測試資料確認。把現有方式與新模型放在同一批案例中比較，才看得出分類與後續回覆是否都得到改善。

三種問題型別，分別回答什麼？

Microsoft Learn 文件列出三種問題型別，分別處理是非判斷、單一選擇與有順序的評分。使用前先選對型別，結果才容易被系統解讀。

這裡的型別，可以理解成你期待模型回傳哪一種答案。型別不同，數值代表的意思也不同，不能全部當成相同的準確率。

是非判斷：判斷某個條件是否成立

文件使用 noul 表示是非判斷，回傳介於零與一之間的機率資訊。適合詢問輸入是否滿足明確條件，例如是否包含足以查詢訂單的必要資料。

條件要寫得能被判斷。「這是一則好訊息嗎」太模糊，改成「是否包含訂單編號與問題描述」，模型與人工標註者才比較容易取得一致答案。

若資料完整性是可以直接用程式檢查的格式條件，先用程式通常更簡單。模型比較適合處理語意，例如問題描述是否真的說明需要協助的事項。

單一選擇：從明確選項選出一項

choice 用於選擇一個選項，並提供各選項的機率資訊。客服分流常用這種方式，因為後續流程需要一個明確入口。

但一則訊息可能包含多個問題。若使用者同時詢問延遲到貨與退貨，你要先決定是按主要意圖分類，還是另設多問題處理流程。

這個決定應寫在任務定義中。否則同一則訊息由不同人標註時就會得到不同答案，模型測試再精細，也難以證明是哪一方分類正確。

有序評分：分數跟著等級定義走

score 用於有順序的等級，結果可能是各等級索引的加權平均，所以不一定是整數。四個等級的結果範圍，可以對應零到三的索引。

這種分數必須連同你的等級定義解讀。它不是天然通用的品質尺度，也不能因為得到接近滿分的值，就宣稱內容在所有標準下都很好。

例如你用它評估描述清楚程度，每個等級就應有可辨認的條件。後續更改等級數量或描述時，原本的分數也不宜直接拿來比較。

在 Foundry 部署前，先把問題規格寫好

Microsoft Foundry 是微軟提供模型部署與使用的服務環境。依官方文件，開發者需要適用的 Azure 帳號、專案與部署權限，再從模型目錄建立部署。

當前官方發布頁同時提供 Foundry 與 OpenRouter 入口。選擇使用管道前，應核對各自目前的可用範圍與計費條件，而不是沿用早期介紹中的開放時間，詳見官方取得方式。

若走 Foundry，文件提醒請求中的 model 要填部署名稱。這與模型產品名稱可能不同，填錯時應先查部署設定，不要直接推論模型服務不可用。

請求中的狀態與問題怎麼分開？

狀態是待判斷的材料，問題則定義要根據這份材料作什麼決定。狀態可以是文字或結構化資料，問題中則應有明確選項與判斷條件。

以下用假設的客服情境說明：狀態包含客戶訊息與已知訂單資料，問題要求選擇物流、商品、帳號或需要人工釐清。這是設計範例，不是本文實際呼叫模型的結果。

把材料與問題分開，能讓同一份資料接受不同判斷。例如一個問題判斷應交給哪個部門，另一個問題判斷資料是否足夠開始處理。

不過，問題放在同一份請求中，仍應確認每項結果的用途。分類正確但資料不足時，下一步可能是補問資訊，而不是立即進入自動回覆。

一份最小請求可以長什麼樣子？

以下是依官方欄位設計的請求範例，使用假設的客服訊息。送出前需填入自己的部署名稱，並依官方文件設定端點與驗證方式。

Foundry 使用 POST <resource-endpoint>/providers/microsoft/v1/systemone 接收請求，其中資源端點需換成你的部署服務地址。

{
  "model": "<your-deployment-name>",
  "state": "商品還沒送到，我想知道目前配送進度。",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "依主要需求選擇處理流程；資訊不足時交回人工。",
      "criteria": {
        "delivery": "配送進度、到貨時間或物流異常",
        "product": "商品規格、使用方式或尺寸問題",
        "account": "登入或帳號存取問題",
        "review": "多個需求無法確定主次，或需要補問資訊"
      }
    }
  }
}

接收端應確認答案型別與選項都符合預期，再進入對應流程。逾時、空回應或不認得的選項，應按系統的例外方式處理，不能直接當成正常分類。

這個範例示範請求結構，沒有假造模型回傳的分數。真正的分類與信心資訊，仍要由你部署後的結果與標註資料比較。

哪些資料不應靠模型補猜？

訂單狀態、帳號資格與服務期限，應由可靠資料來源提供。模型可以分類使用者的需求，卻不應因為訊息語氣像急件，就替系統編出不存在的狀態。

同樣地，缺少關鍵資料時，選項應保留無法判斷的出口。這會讓自動處理比例看起來較低，但能避免系統在資訊不足時仍給出肯定分類。

任務定義寫好後，才適合設計信心分數的用途。否則再漂亮的數字，也只是對不清楚問題的回答。

信心分數不是自動通行證，門檻要跟錯誤成本一起設計

信心分數可以幫你安排自動處理與人工覆核，但不能被當成每筆結果一定正確的保證。它是否可靠，必須在代表你的實際資料中檢查。

假設模型把一批訊息都判成九成信心，接著比較其中實際正確的比例。若正確率明顯較低，系統就不宜直接依表面數值擴大自動處理。

這種檢查叫校準，可以理解成確認模型有多把握的說法，是否符合結果。發布文章提供的模型表現，是研究起點，不能代替你自己的校準資料。

不同流程可以採用不同門檻

把一般問題送到錯誤部門，可能只是多一次轉交。誤把需要人工確認的操作送進自動流程，則可能造成更大影響，兩者不必使用相同門檻。

因此，門檻應由具體後果決定。先列出錯分時會發生什麼，再測試不同門檻下的正確率與轉人工比例，才能做出合理取捨。

本文不提供通用百分比，因為每個流程的資料與後果不同。若沒有自己的驗證集，直接照抄別人的門檻，容易把數字當成設計已經完成。

最後執行動作，還要檢查業務規則

即使分類很有信心，變更訂單或帳號時仍應由既有系統檢查權限。模型結果可以決定交給哪條流程，不應直接取代所有操作條件。

你可以讓決策結果進入服務端的檢查函式，再依帳號與資料狀態允許操作。這樣即使模型誤判，也不會因此自然取得原本沒有的權限。

這種分工把可調整的語意判斷，與應穩定執行的服務規則分開。團隊就能改善模型，而不必每次都重新設計全部業務流程。

如何測試：先看錯在哪裡，再看快多少

測試資料應包含日常訊息與容易混淆的例外，並由熟悉業務的人確認標準答案。只挑用字清楚的示範案例，容易高估實際表現。

例如物流與退貨分類，可能在「還沒收到，想取消」這類訊息上重疊。把這種邊界案例納入，才能知道任務定義是否足夠清楚。

先用同一份資料測試現有流程與新模型，再比較分類品質、處理時間與完整成本。資料相同，結果才比較容易解讀，也比較少把需求改變誤當成模型進步。

品質應按類別拆開看

整體準確率高，不代表每個部門都能使用。資料中若大多數是物流訊息，模型只擅長物流，也可能掩蓋帳號問題的錯分。

因此應列出每類的正確與錯誤去向，確認哪些問題最常被混淆。這比單一平均值更能告訴你該修改選項、補資料，還是暫時保留人工處理。

標註者本身也可能有不同看法。若人工答案不一致，先討論分類規則，再測模型。否則錯誤報告可能只是把業務定義的歧義算到模型頭上。

檢查用字、順序與資料變動

同一意思改成不同說法，結果應盡量一致。可以用自己資料的同義改寫做測試，觀察模型是否只對熟悉句型表現良好。

也可以調整選項順序、補充常見縮寫，觀察結果變化。若小改動就造成重要分類翻轉，應先檢查提示與選項，再考慮提高自動處理比例。

正式導入後還要追蹤資料變化。新商品、新服務或新的客戶用語，都可能使原本良好的分類失效，因此評估不應停在首次上線報告。

成本要包含後續修正

模型呼叫費用只是成本的一部分。若分流錯誤讓客服重看資料、重新轉交，這些工時也應納入，才能判斷新流程是否真的節省資源。

速度同樣要看完整路徑。模型很快，但後面需要重試、補資料或等待人工，使用者感受到的完成時間未必跟模型延遲成比例。

當品質符合需求，再把省下的時間與費用轉成導入理由，會比先用官方倍數設定承諾更可靠。官方測試可用來決定值得試什麼，不能保證所有場景相同。

Microsoft-Decision-1 常見問題

可以用它寫客服長篇回答嗎？

它的定位是結構化決策，適合分類與選擇流程。若要生成自然語言回覆，應另外安排生成模型或既有模板，並提供已查核的服務資料。

分數九成就可以全部自動處理嗎？

應先用自己的資料檢查分數與正確率，再考慮錯誤後果。高信心可以是分流依據，但不能代替帳號權限與業務規則，也不能保證每筆判斷都正確。

程式規則能做的分類也需要模型嗎？

不一定。固定格式、必填欄位與精確比對，通常可以先用程式處理。需要理解多種自然語言說法的部分，再評估模型是否能降低維護與標註負擔。

什麼情況值得開始試點？

已有明確選項、可用的標註資料與後續處理流程時，最容易測出價值。若分類定義還在變動，先整理需求通常比直接擴大模型使用更有效。

把決策做成能檢查的服務步驟

Microsoft-Decision-1 提供了一種更直接的方式，把選擇流程與文字生成分開。它對客服、資料標註與代理控制的價值，在於結果可以被系統明確讀取。

真正決定導入成效的，是選項是否清楚、信心是否可靠，以及錯誤能否被攔住。先完成一個可比較的試點，再擴大使用，才能把模型能力轉成穩定的服務改善。

想持續追蹤 AI 科技新聞與開發工具解析，歡迎免費註冊 AI 郵報會員，訂閱後續文章。

延伸閱讀：Microsoft-Decision-1 公開預覽：AI 客服分流，為什麼不必先寫一段答案？

延伸閱讀：LangChain 模型分流實驗：Open SWE 成本中位數降低 64%，怎麼做到的？

資料來源

• Microsoft：Introducing Microsoft-Decision-1
• Microsoft Learn：使用 Microsoft-Decision-1 決策模型
• Microsoft Foundry 模型目錄

資料查核日期：2026年10月12日。本文客服流程為說明用情境，並非模型實測結果。