OpenAI 10 月 6 日把 Decisions API 從封測推進到 public beta，這條新 endpoint 跟 Responses API / Chat Completions / Structured Outputs 都不同——它不產出文字，只回答「是/否」「選哪一個」「給幾分」三種封閉型答案。官方說「比 Responses API 快 10 倍」，The New Stack 實測端到端 p50 約 150 毫秒。底層只跑一個模型：gpt-6-luna，只有 input token 計費、零 output 費用——輸入 $0.10 / 1M token。
編按：本文綜合整理自 OpenAI 官方 Decisions API 文件、The New Stack 報導、Hacker News 討論串（350 分）、anth.us 的可信度分析、generativeai.pub 的 Luna 28.7% 失敗率報告、Hugging Face sora-2 實戰指南 與 OpenAI 社群討論，並加入 Siami 編輯部觀點與分析。
Decisions API 在做什麼
OpenAI 把 Decisions API 定位成「判斷型 endpoint」——不是幫你寫 email、生成圖、跑 function call，而是專門回答有限答案的問題。三種題型：
predicate：回 0-1 的機率值（例：這張產品照有沒有損壞？機率 0.92）choice：從你給的選項中選一個（例：把客服訊息分到 billing / technical / shipping / other）score：對有序等級打分，回傳「機率加權平均」的分數（例：客服案情的嚴重程度 0-2 分，回 1.1）
請求結構只有三個欄位：model（目前只能是 gpt-6-luna）、input（文字或 base64 內嵌圖片）、questions（題目陣列，每題要有獨立 name）。回應只有 answers 陣列，沒有對話歷史、沒有 reasoning trace、沒有 streaming。
OpenAI 在文件裡明說：Decisions API 不支援 外部圖片 URL、也不支援 file_id——圖片必須是 base64 inline。這跟 Responses API 的多元輸入限制完全不同，是刻意收緊的「封閉環境」。
為什麼這件事重要
Decisions API 真正的市場對手不是 OpenAI 自家其他 endpoint，而是 TypeSafe 的 Jev——Jev 在 9 月中發表的時候主打「結構化判斷、可驗證的 schema」，社群一片看好，OpenAI 兩週後直接在同一個市場區隔開打。差別在於：Jev 是 open-source 模型，企業可以自己 host、自己 audit；Decisions API 鎖在 Luna + 專用 endpoint 裡，速度 10 倍、成本 1/100，但放棄了模型透明度。
這背後是 OpenAI 的「任務專用 endpoint」策略收斂——除了 Decisions API 之外，9 月底 DevDay 也發表了 Webhooks、Compaction、Mid-turn steering 等新機制。OpenAI 不再只想當「模型 API」供應商，而是要把每種 AI 任務都做成專用 endpoint：寫作走 Responses、判斷走 Decisions、即時走 Realtime、聲音走 Live。每條 endpoint 都有自己的計價、限制與延遲保證，開發者要選對 endpoint 才能壓成本。
對台灣 / 中文圈開發者而言，這條 endpoint 對客服工單自動分流、電商退貨照片審核、內容審核 pipeline、文件分類這幾類場景會最先受惠——這些都是台灣中小企業最常見的 LLM 應用，但 2025 年之前還在用 GPT-4o + Structured Outputs 硬做，每次決策成本是 Decisions API 的 100 倍以上。
三種題型的實戰差別
predicate 最穩：Luna 在「是/否」這種二元判斷上表現最一致，機率值可以拿來設 threshold（例：probability > 0.85 才自動通過）。圖片分類場景的「瑕疵檢測」就是典型用例。
choice 選項超過 4 個會掉信心：根據 Hugging Face sora-2 團隊的實戰指南，4 個以上選項時 Luna 的 confidence 會掉 15-20%。多選項時的解法：把粗分類拆成兩層——先 3-4 個大類，再用第二個 Decisions API 細分。
score 是最強的「連續評估」工具：當你要評估的是「這個案子有多緊急」這種有序等級，score 會回傳機率加權平均，可以落在等級之間（例：0/1/2 三等級，回 1.1）。這是 Responses API 的 0-100 自由評分做不到的——score 的等級是結構化定義的，不會被 Luna 自由心證。
多題型組合：同一個 input 可以塞多個 questions，每題獨立命名，但有依賴關係的題要分開呼叫——文件明說 Decsion API 不支援「根據上一題答案決定下一題」的 chain-of-thought。
質疑與可靠度紅線
雖然 OpenAI 標榜「速度快、成本低」，但 anth.us 的可信度分析 跟 generativeai.pub 的 Luna 失敗率報告 點出三個關鍵問題：
第一，Luna 本身會「猜測」而不是「報錯」。 OpenAI 自己的 broken-tool 測試裡，gpt-6-luna 在 28.7% 的情況下寧願猜一個答案、不標記任務失敗。Decisions API 跑在 Luna 上，等於把「自動審核」建在「不會主動說我不知道」的引擎上——這對企業級自動分流是硬傷。HN 讀者 chiefstorm 的最高分留言直接點名：「沒有可靠的 confidence 校準之前，企業不能拿來做自動審核。」
第二，$0.10/1M token 的定價模型有陷阱。 表面上比 GPT-4o 便宜 100 倍，但 Decisions API 沒有 output token 計費、卻也沒有「快取讀取」、「prompt cache」這些機制——同一個分類任務每呼叫一次都是新成本。對高 QPS 場景（如電商即時審核），需要自己做 client-side cache 才有辦法壓成本。
第三，150 毫秒的延遲承諾是 p50，不是 p99。 The New Stack 實測 150 毫秒是「黃金時段 + 簡短 prompt + 美國境內」的情境。實際 production 流量、跨太平洋呼叫、加上圖片 base64 編碼，p99 拉到 800 毫秒以上是常態——拿來做即時互動 UI（例：聊天機器人即時意圖判斷）會卡。
配套支援的盲點：Decisions API 雖然支援 ZDR（Zero Data Retention）跟 HIPAA，但沒有 audit log API——企業客戶要知道模型具體「為什麼分錯」是沒辦法的，只能從 choice 跟 confidence 欄位反推。對金融、醫療等需要「可解釋 AI」的行業，這是阻擋採購的硬指標。
跟其他「判斷型」工具怎麼選
| 工具 | 模型 | 速度（p50） | 成本 / 1M 輸入 | 可解釋性 | 適用場景 |
|---|---|---|---|---|---|
| Decisions API | gpt-6-luna | ~150ms | $0.10 | 黑盒（無 reasoning） | 高 QPS 分類、客服分流 |
| Responses API + Structured Outputs | gpt-6 / gpt-6-mini | ~1-2s | $1-5 | 黑盒但有 reasoning trace | 複雜判斷、需要審計 |
| TypeSafe Jev | Jev-1（OSS） | ~200-400ms（自 host） | 自己算 GPU | 完全可解釋（schema 驗證） | 金融、醫療、合規要求高 |
| Cloudflare AutoRAG | 自家 Workers AI | ~80ms | $0.05 | 黑盒 | 簡單 RAG、輕量分類 |
對台灣開發者而言，Decisions API 最直接的競爭對手是 TypeSafe Jev——同樣主打「判斷型 API」，但 Jev 是 open-source，可以自架在 Cloudflare Workers / AWS Bedrock 上，資料不出企業內網。如果客戶是金融業、醫療業，這個差別比 10x 速度重要。
如果企業需要的不是「判斷」而是「判斷 + 解釋」，該走 Responses API + Structured Outputs。Decisions API 的設計哲學是「犧牲解釋換速度」，不要硬把它當成「便宜的 Reasoning 模型」用。
接下來要追蹤的事
- GA 時程：OpenAI 說「未來幾週內」GA，預計 10 月底會有正式 SLA、p99 數據、正式價格表。
- 多模型支援：目前只能跑
gpt-6-luna，但 file_id、外部 URL 限制很可能在 GA 時放寬。Luna 之外的模型（gpt-6-mini？蒸餾版？）會是下一步。 - Audit Log API：企業客戶敲碗的功能，沒做之前金融/醫療採購會卡住。
- 跟 Responses API 的分工：文件明說「該用 Responses + Structured Outputs 的場景不要硬用 Decisions」——但實務上開發者會一直混用，要看 OpenAI 怎麼定價 Responses API 來「推」開發者分流。
- TypeSafe Jev 怎麼回應：Jev 是 OSS，TypeSafe 拿不到 Decisions API 這種「模型 + endpoint + 快取」三合一的 bundle 優勢，但他們可以主打「模型可換」（換 Llama、Qwen、DeepSeek）跟「自架」這兩個差異化。
編按：本文綜合整理自 OpenAI 官方 Decisions API 文件、The New Stack 報導、Hacker News 討論串、anth.us 的可信度分析、generativeai.pub 的 Luna 28.7% 失敗率報告、Hugging Face sora-2 實戰指南 與 OpenAI 社群討論，並加入 Siami 編輯部觀點與分析。
網友熱門留言 (5)