OpenAI Decisions API 正式開放：400 題、JSON 與 GPT-Live 如何改變即時分流？
OpenAI Decisions API 正式開放，新增每次最多 400 問、原生 JSON、問內圖片與 GPT-Live 整合。本文解釋機率、選項、評分的差異，整理輸入費用、快取門檻、區域處理與品質評估，協助團隊把即時分流接到可驗證的工作流程。
客服語音或文件分流不一定需要一段長回答，卻常需要很快決定下一步。OpenAI Decisions API 於 2026 年 10 月 22 日正式開放，把 GPT-6 Luna 用在答案範圍明確的判斷任務。API 是應用程式呼叫服務的介面。
它在公開測試期間已能做分類與路由，這次新增的重點是與現有應用更直接銜接。開發者能送入原生 JSON、在個別問題加入圖片，也能一次提出最多 400 個問題。
因此，應用程式可以保留結構化欄位，不必先把資料全部改寫成敘述。語音服務則能接上 GPT-Live，在對話進行時判斷該追問、轉接或做出介面反應。
但回傳機率與選項仍是模型的判斷，沒有自動變成業務規則或授權。把判斷接到寄信、退款或其他動作之前，仍要定義什麼情況應該交回人工。
這次更新適合已經有大量重複分類、而且能提供真實評估樣本的團隊。若任務答案開放，或一次誤判就會造成重大影響，則應保留較完整的推理與驗收流程。
要看清楚正式版的價值，先從問題如何限制答案，再看新輸入方式如何接上原有系統。
OpenAI Decisions API 正式版新增了什麼？
新版本把問題數量與輸入格式擴充，讓既有分類工作更容易直接接入。OpenAI 10 月 22 日公告明確將這次定位為正式開放，因此這篇重點是公開測試後的新功能與整合條件。
Decisions 的用途是讓應用先定義問題與允許的答案，再把資料送入，由模型回傳有限範圍的判斷，因此它較接近工作流程裡的分流器。
例如，客服系統已經知道下一步只能轉帳務、技術支援或物流部門，就可以把這些選項交給模型。系統需要的是選哪一個，而非先取得一大段說明再自行拆解，所以輸出形式會影響等待時間與程式設計。
這次正式版把每次請求的問題上限由兩百提高到四百。這讓開發者能在相同共同資料上安排更多判斷，但上限只是可送入的問題數量，不能直接推算四百題都會在相同時間完成。
JSON 與個別問題圖片解決什麼麻煩？
原生 JSON 輸入讓應用直接送出結構化資料。JSON 是以欄位保存資料的格式，例如訂單狀態、商品類型與客戶訊息，因此開發者可以保留欄位關係，不必先把整筆紀錄改寫成散文。
這能減少資料準備的轉換工作，但模型仍需要知道欄位含義。若同一欄位在不同系統代表不同狀態，就應在問題說明裡解釋，否則資料形式正確，也可能得到不符合業務規則的分類。
個別問題也能加入自己的圖片，搭配共用輸入做比較。例如，共用資料是一張參考圖片，各題放入不同待檢查圖片，模型就能依同一個判斷標準回答，但圖片判讀品質仍要由實際樣本驗證。
開發文件另列出公開圖片網址與直接傳送圖片資料的方式。因此，圖片來源是否能被服務取得，以及內容是否適合送到外部，都應由應用在送出前確認。
正式版新增功能降低的是接入既有資料的阻力，沒有替企業完成自己的標籤定義。可輸入更多資料後，還要選擇能代表業務需求的輸出形式，才能把模型結果轉成可維護的程式邏輯。
機率、選項與評分該如何對應任務？
三種輸出回答的是不同問題，不能把機率數字直接當成真實世界保證。官方提供條件機率、指定選項與分級評分，開發者應依工作本身需要的答案類型選擇，而非全部轉成一個籠統分數。
條件機率用零到一表示某條件成立的模型估計。例如，商品圖片是否有明顯損傷，這個結果可供系統決定要不要送人工複查，但它需要用已標註樣本確認高分與實際問題之間的關係。
指定選項則從開發者提供的值中選一個，也回傳相關機率與信心資訊。若客服選項只有三個部門，開發者仍可以加入其他或人工處理，避免模型被迫把不屬於任何部門的訊息塞進錯誤分類。
評分則依有順序的等級定義，回傳各等級索引的機率加權平均。因此，它的數字和開發者定義的等級順序有關，不能直接把它讀成答對機率，或跨不同評分表任意比較。
門檻要用自己的錯誤成本決定
假設應用只是替內部文件分類，錯一筆可以讓人重新標記。若結果會觸發退款或刪除資料，錯誤代價就大得多。因此，同一個模型信心數字，在不同業務裡不應自動對應相同動作。
實作時可以先把模型結果留作建議，再比較人工標籤。當團隊看得出哪些類型容易混淆，就能調整問題、選項與人工交接條件，而非只一味提高要求模型「更準確」的措辭。
這種評估也能指出資料不足的情況。若同一段客服訊息同時包含帳單與物流問題，單選答案可能無法完整表達任務，因此開發者需要重新定義分流規則，或允許後續再問一題。
OpenAI 宣稱，這個介面做有限答案的判斷，最高可比透過 Responses API 使用 GPT-6 Luna 快十倍。這是指定比較對象與任務類型的官方說法，不代表它在所有題目都同樣快，也不是本文的獨立測試。
原有公開測試版的用途與基本分類方式，可以與這次正式版更新一起閱讀，分清既有能力與新加入的整合。
延伸閱讀：OpenAI Decisions API（應用程式介面）完整解析：用 Luna 做分類、路由與 Agent 下一步決策
把輸出含義說清楚，才有條件在語音途中觸發下一個動作。因為即時對話中的資訊會不斷變動，選項定義與觸發時點同樣影響使用體驗。
GPT-Live 串接為何需要控制觸發條件？
對話尚未結束就能做判斷，能縮短等待，也更需要處理片段訊息反覆變動。這次新增的 GPT-Live 原生整合，可以隨輸入或輸出逐字稿更新執行決策，讓應用在對話進行時回應。
逐字稿是把語音轉成文字的紀錄，增量更新則代表每次只收到新增加的一小段內容。因此，應用可能還沒聽到完整句子，就已經取得足以改變判斷的新詞，適合處理低風險的即時反應。
官方示範用使用者說話的內容選擇虛擬角色表情，應用讀取決策事件後改變畫面。這種用途即使需要修正，也較容易立即回復，因此能說明快速判斷如何改善互動。
但把同樣機制接到高影響動作時，就要考慮語句後半段改變前半段含義的情況。例如，使用者先提到取消，後面又補充只是詢問條件，若系統太早執行，就可能偏離真正需求。
快速判斷與正式授權要分開
因此，對話中途的判斷可以用來準備介面、選擇追問或標記候選路由，正式變更則可以等完整意圖與必要批准到位。這是依輸入會變動的特性設計流程，不是把所有動作都交給同一個機率門檻。
事件觸發次數也會影響成本。一段語音可能產生多次逐字稿更新，若每次都重新判斷完整共同脈絡，呼叫量就會增加，所以應用需要觀察每次對話產生多少請求及哪些結果被實際採用。
原生整合降低的是連接步驟，應用仍要處理事件返回後怎麼使用結果。若網路變慢或決策暫時失敗，介面應保有可理解的行為，避免因一個輔助判斷中斷整段語音服務。
公告提到部分亞洲地區增加容量，這與資料落地在何處是不同問題。官方另列美國與歐盟的區域處理選項，因此企業不能只因回應變快，就認定資料一定留在台灣或亞洲。
對有資料地區要求的團隊，應先核對實際使用的處理位置與服務條件。語音、文字與圖片可能同時出現在流程中，因此每一種輸入都要符合原先的資料政策。
即時性必須連同呼叫量與資料處理地區一起估算。這樣團隊才能知道新增互動帶來的改善，是否值得其延遲、成本與資料處理安排。
價格、快取與評估該如何一起算？
真正的成本取決於輸入長度、快取命中與每次對話觸發幾次判斷。依 2026 年 10 月 24 日查詢的官方公告，每百萬輸入詞元為 0.10 美元，快取輸入為 0.01 美元，沒有輸出詞元費用。
詞元是模型計算文字等內容用量的單位，所以免輸出費不代表每次呼叫完全免費。共同背景很長，或應用頻繁重送資料，仍會增加輸入用量，因此需要觀察實際請求而非只看單價。
官方也提供企業客戶的使用案例，但這些數字需要保留各自的測試範圍。Box 的文件路由比較使用三十件保險證明案例，所以即使客戶表示速度改善，也不能把結果直接套在所有文件類型。
這類案例的用途是幫助開發者找到可測試的任務，而非替自己的資料集先下結論。若公司文件包含不同語言、模糊圖片或缺漏欄位，就應把這些情況加入評估，確認模型在例外情境如何反應。
語音案例也同樣需要區分服務組成。下一個動作變快，可能改善對話互動，但整體體驗仍包含語音辨識、網路與應用執行，因此應用要量測使用者真正等待的時間，才能知道節省發生在哪裡。
快取是把重複輸入保留下來供後續重用的機制。文件指出，共用輸入中可重用的前段至少需要一千零二十四個詞元，個別問題內容不算進這個門檻，因此短提示未必得到預期折扣。
共用前段也要保持一致，才能重用。若團隊每次把時間或不同順序的資料放在開頭，就可能破壞可重用的部分，因此資料排列與應用需求需要一起設計，而非只打開一個選項就預設命中。
快取寫入與讀取不能混算
官方公告把三十分鐘與十二小時的快取寫入另外指向定價說明。因此，0.01 美元是快取輸入的價格，不能把它當成所有快取建立與保存的統一價格，尤其重用次數少時更應核對。
文件提供快取讀取與寫入用量欄位，而且這些數字已包含在輸入總量內。因此，團隊做內部帳單時要分清拆項與合計，避免又把拆出的快取用量加回總數，造成重複計算。
零資料保留也限符合資格的客戶適用，不能從正式開放推定每個帳號自動啟用。若公司要處理敏感紀錄，就應確認自己的合約與專案設定，再送入正式資料。
若要限制快取範圍，開發文件也提供明確標記共用輸入邊界的設定。這讓團隊能把固定背景與每次變動的資料分開，但標記位置有支援限制，因此應以實際快取用量驗證效果。
這項設定屬於共用輸入，不能直接把問題指令當成同樣的快取邊界。因此，程式若把大量固定說明放在每道問題裡，需要先確認資料安排，再估算能重用的比例。
評估則可以先挑一個高頻、答案範圍固定的工作，保存人工標籤與實際輸入。把準確度、錯誤類型、等待時間與單次費用放在一起，才能知道更快的判斷是否改善整個流程。
不同公司的決策模型也可能回傳不同種類的結果，適合依自己的任務與服務條件比較，不能只因介面名稱相近就預設可直接交換。
延伸閱讀：Perplexity 推出 Decisions API：文字與圖片進來，選項機率出去
先以真實案例確認準確度與錯誤成本，再把較低風險的分流接進正式服務。想持續追蹤正式版介面與計價更新，可訂閱 AI 郵報，並以官方開發文件保存自己的導入基準。
常見問題 FAQ
OpenAI Decisions API 可以直接取代一般聊天回答嗎？
它適合答案範圍固定的判斷，例如分類、選項與分級。開放式寫作或需要完整解釋的任務，應選擇符合輸出需求的介面。
四百題是同時處理四百段不同對話嗎？
它是單次請求可定義的問題上限。輸入安排、題型與延遲仍依實際請求而定，不能把上限直接等同固定速度。
快取輸入單價就是所有快取費用嗎？
不是。官方將快取讀取與特定保存時間的寫入費用分開，應依定價與實際用量欄位計算。
