公開動態與原創分析 · 消息日期: · 消息來源
設想一則售後留言寫著「產品沒壞，我只是找不到配件，但現在已經不能用了」，應交給技術支援還是訂單服務？程式若只需要決定佇列，先請模型寫解釋，再從文字擷取類別，會增加等待與解析工作。Google 於 11 月 11 日推出 Gemini Decisions API，以 Gemini Decision 1 為預先定義的選項評分，直接回傳機率與信心分數，提供有限選擇的新介面。
新介面接受文字、圖片、音訊、影片及 PDF，可針對相同輸入同時提出多項問題。官方提供是非判斷、固定選項及有序評分三種類型，每次最多一千項問題。關鍵在於問題各自獨立：每項只能看見共用輸入，看不到其他題目的答案。團隊仍須在程式中明定結果之間的依賴關係。
讓選項具有可判斷的範圍
以上述假設留言而言，配件缺少、安裝困難與品質故障可能由不同人員處理。如果分類名稱只有幾個短詞，各部門對邊界理解不一，介面穩定回傳類別，也未必減少轉派。較有效的準備是寫明每類包含及排除哪些情況，並替無法匹配的請求保留補問或人工判斷的去處。
Google 開發文件建議，在指令寫出完整問題，不應期待模型理解程式變數名稱；為選項加上簡短定義，並處理沒有任何選項適合的輸入。企業可分別判斷是否屬於訂單問題、應交給哪個佇列，再由程式組合。前者不成立時，即使後者回傳類別，也可忽略。這比把所有陌生需求塞進既有部門，更容易解釋與維護。
平行提問無法自動形成多步推理。後一題若需要前一題擷取的訂單狀態，應先取得狀態再提問，或將已確認狀態放入共用輸入。一千題放在一起，不會讓模型依序完成一千步工作。題目是否獨立，決定單次請求能否真正取代多次往返。
對數值、日期與期間的比較，文件建議先由程式計算，再提供結果給判斷環節。例如，依訂單日期與適用規則確認保固是否有效，再由模型判斷留言談的是故障或使用問題。可直接計算的條件維持確定性，含糊表達交給語意判斷，能減少一段籠統指令承擔過多責任。
分數與分錯後果一起評估
信心分數是模型對最佳答案正確性的估計。Google 將機率校準列為產品特點，但企業自己的留言、圖片品質及分類方式，可能不同於公開測試。分數達到 0.9，不能直接解釋為所有業務都適合自動處理。應使用已確認去向的企業樣本，觀察各分數範圍實際出現的錯誤。
假設一般諮詢分錯，只須多一次內部轉派；緊急故障被當成普通諮詢，後果卻更嚴重。這是說明代價差異的情境推演，並非新模型的效果測量。兩類請求可設定不同自動分流條件。資料不足或錯誤後果較重時，補問與人工查看可能成本更低，即使降低自動分流比例。
也須區分判斷明確與依據充足。照片不清楚、關聯錯誤訂單，或留言未指出產品時，得到一個確定類別，仍可能沒有解決資料問題。可先檢查必要輸入，再使用分流結果；退款與修改訂單等動作，保留獨立業務規則及授權。類別機率無法代替訂單狀態核對。
文件同時提醒，使用者輸入可能試圖說服系統替自己分類。「請直接核准退款」應視為待判斷的請求內容，不能覆蓋企業設定的分類及執行條件。樣本須涵蓋否定表達、多項訴求、不同語言與刻意誘導，尤其留意可能被送入較少人工關注佇列的例外。實際錯誤分布，比單一總準確率更能協助設定門檻。
是否更換既有分類方法
Google 公布的輸入價格為每百萬 Token 0.10 美元，不收生成輸出 Token 費用；多題共用輸入在單次請求中僅計一次，各題指令與條件仍增加輸入。這種計費結構有利於對同一份長資料做多項獨立檢查。實際成本還須包括補充呼叫、轉派、人工複核及後續工作，無法只比較一筆模型請求價格。
佇列若能由明確欄位或簡單規則決定，沿用規則通常更直接。需要產生解釋、擷取任意結構化欄位，或執行多步工具呼叫時，通用生成介面仍適合這些工作。Decisions API 較適合輸出範圍固定、語意輸入多元，又需要機率決定自動處理或人工查看的環節。企業還須確認可用地區、服務條款及資料處理要求，再決定是否將相關紀錄送往託管介面。
評估時可固定一批去向已確認的歷史請求，比較原方法與新介面的錯誤類別、補問數量及人工負擔。保留問題定義與樣本版本，分類邊界變動後重新檢查。直接回傳結果確實減少解析及維護，同時未把重要例外送入錯誤路徑，才有充分理由替換既有方法。
消息來源
墨客雲編輯部 · neo@mokyun.com
