提供明確結果的意圖分類 API

載入真正需要判斷的請求

連結中的試用區起初是客服範例。執行前，請先用下方的意圖規則替換文字、指令與標籤。「不要取消我的帳戶；我只需要一張發票」是值得測試的邊界案例：雖然出現「取消」，實際請求卻是發票。

若流程無法安全地從「取消我的方案，並寄出最後一張發票」選出單一主要意圖，請保留要求釐清的結果。分類器提供的是建議，後續仍須檢查所有權與操作權限。

{
  "text": "不要取消我的帳戶；我只需要一張發票。",
  "instructions": "尊重否定語意，選擇訊息請求的下一步。若有多個互相衝突的請求，選擇 clarify。",
  "labels": [
    "invoice",
    "cancellation",
    "account help",
    "clarify"
  ],
  "threshold": 0.9
}

用具代表性的證據驗收分派規則

建立並標記獨立測試集，涵蓋簡短回覆、引用的指令、多重需求、否定語句與範圍外訊息。量測會導向不同動作的意圖之間有多少混淆；單一整體正確率可能掩蓋代價很高的誤取消。

先讓團隊看到建議佇列。每筆結果保留原始紀錄連結和請求識別碼，追蹤人工修正，等證據足夠後才自動化可逆的分派。模型分數再高，也不能確認發出請求者的身分。

分類評估指南 · API 入門

選擇會改變後續動作的標籤

有用的意圖對應實際工作，例如取消訂閱、索取發票、修改帳戶資料或詢問產品。若兩個標籤總是導向相同動作，可能不必分開。

為包含多項請求的訊息加入需要釐清的結果，並定義主要意圖是第一項請求、最緊急的問題，還是阻礙客戶繼續操作的事項。

在試用區測試意圖分類

讓實際動作留在分類之外

意圖不等於授權。應用程式仍須驗證使用者身分、確認所有權，並在敏感操作前取得確認。不能只因分類器預測出取消意圖，就取消一個帳戶。

請求與回應契約

測試邊界，不只測試簡單案例

評估否定語句、引用文字、簡短回覆，以及夾在客戶訊息裡的指令。這些文字是等待分類的證據，不是能重新定義任務的指示。對模糊或超出允許標籤範圍的結果進行覆核。