OpenAI Decisions API：把 AI 分類與評分接進實際工作流程

AI 應用愈來愈會生成文字、程式碼與解釋，但生產系統常常需要的是更窄的判斷：這則訊息應該交給帳務還是技術支援？圖片裡是否有損壞？這個問題屬於哪一個嚴重程度？OpenAI 的 Decisions API 已正式推出，正是針對這類有邊界的問題，而不是開放式寫作。

這個差異很重要。通用回答可能很精彩，卻不容易驗證。決策介面在應用需要類型化答案、機率分布，或可以驅動下一步流程的分數時更有價值。根據 官方 Decisions 指南 與 建立決策的參考文件，它能評估文字、圖片和 JSON，並支援謂詞、選項及評分問題。

真正的變化是加入類型化判斷層

許多團隊早已有「請把這則請求分類」的提示詞。問題不一定在模型，而在模型周邊的契約。如果提示詞可以回傳任意段落，下游程式就得解析散文、猜測信心程度，還要決定如何處理例外。

Decisions API 會把問題寫得更明確。謂詞用來判斷條件是否成立並回傳機率；選項用來從自訂值中選擇，例如 billing、technical 或 other；評分則按照有順序的等級評估輸入，例如「只有外觀問題」、「有替代方案」和「完全受阻」。結果仍然帶有機率，但應用程式可以在採取行動前檢查其形狀。

這使 AI 從孤立的模型呼叫變成一個小型策略邊界。應用程式定義允許的結果、區分結果的說明，以及什麼時候應該轉交人工審查。

它能回答哪些問題

最直接的用途是路由。客服訊息可以搭配選項問題送出，應用程式再把它導向對應佇列，同時保留 other 作為分類系統之外的後備選項。審核或信任流程可以使用謂詞問題判斷可見特徵。營運團隊則能用評分問題衡量問題嚴重程度，再把高風險案例排到前面。

圖片能力也很重要，因為每個問題都能附上自己的證據。共享輸入可以放參考資料，不同問題再個別比較候選圖片。這適合商品檢查、目錄清理、文件審核與視覺品質控管。介面也支援 JSON，因此不必先把所有結構化資料壓成長字串。

目前指南還提到一些實用改善：共享輸入可以快取，單次請求最多可包含 400 個問題，也能使用公開 HTTP/HTTPS 圖片網址或內嵌資料 URL。這些功能不會取代評測，但會讓批次決策服務更容易設計。

它在生產技術堆疊中的位置

Decisions API 不是每一種模型呼叫的替代方案。OpenAI 的建議可以分成三類：答案是謂詞、固定選項或有序分數時使用 Decisions；需要符合自訂 JSON Schema 的複雜物件時，使用 Responses API 的 Structured Outputs；模型需要要求帶參數的工具時，使用函式呼叫。

開發者可以採用這樣的流程：

1. 收集證據，整理成穩定的輸入格式。
2. 以清楚且互不重疊的定義提出一個或多個窄問題。
3. 在應用程式程式碼中套用校準後的門檻。
4. 把不確定案例交給人工或更廣泛的推理流程。
5. 保存問題版本、答案機率與最終動作，供日後評估。

第四步是安全閥。信心值不是保證，分類不完整或證據模糊時，高機率仍可能錯。介面應該幫助團隊更一致地判斷，而不是用看似有把握的句子掩蓋不確定性。

開發者可以如何落地

先從真實流程中建立一小組有標籤的資料，並寫清楚誤報和漏報的成本。接著根據可觀察標準定義問題，不要只描述模糊意圖。如果兩個類別重疊，先改善類別說明，再增加模型複雜度。

客服路由可以從四到五個佇列和明確的後備選項開始。視覺檢查應該為每個獨立條件設定謂詞，而不是用一個巨大問題同時混合損壞、類別和嚴重程度。優先排序可以定義二到十個有序等級，並具體寫出相鄰等級的差別。

最後要監控漂移。產品名稱、客服政策和圖片分布都會改變。保留審查樣本，把模型答案與人工標籤比較，並在錯誤成本改變時調整門檻。想探索更多軟體工具的團隊，也可以瀏覽 BTTC 軟體目錄，或回到 BTTC 科技部落格。

限制與安全措施

類型化答案不等於事實已經驗證。不要只憑機率就授權不可逆的操作。憑證應留在伺服器端；應用程式要驗證每個回傳值，記錄模型與問題版本，並依隱私要求保護圖片和客戶資料。

也不要讓評分標準變成沒有人審查的商業政策。送給模型的描述應讓流程負責人可以閱讀和複核。如果業務無法解釋某個輸入為何屬於某個類別，模型不會自動讓政策變得清楚。

常見問題整理

Decisions API 和 Structured Outputs 一樣嗎？

不一樣。Decisions 適合謂詞、固定選項和有序分數；Structured Outputs 適合需要符合自訂 Schema 的複雜物件。

它可以分析圖片嗎？

可以。圖片可以放在共享輸入中，也可以附加到單一問題的指令中。

每一個答案都應該自動執行嗎？

不應該。應使用有標籤的樣本設定門檻，並保留後備或人工審查流程。

它對小型軟體團隊有什麼幫助？

它減少了把模型判斷轉換成可預測分支時所需的膠水程式碼。團隊可以先從一個窄的路由或檢查流程開始，再依據資料擴展。

結語

Decisions API 縮短了多模態 AI 與一般應用邏輯之間的距離。開發者可以定義少量類型化問題，並讓不確定性在流程中保持可見。這對客服路由、視覺檢查和問題分流都很實用，因為真正重要的是下一步動作，而不是漂亮的段落。