Perplexity Decisions API 打過 FireRed 四天王：592 毫秒示範能說明什麼？
Perplexity 創辦人分享 Decisions API 的 Pokémon FireRed 對戰示範，報告 592 毫秒中位延遲與 137 次呼叫。本文區分單次執行數據、決策機率與完整遊戲代理的能力範圍。
Perplexity Decisions API 是回傳結構化判斷與機率的模型介面，讓程式依結果選擇動作。共同創辦人 Aravind Srinivas 在 X 分享 Pokémon FireRed 示範，表示系統一次完成四天王與冠軍戰。
查詢時，貼文已有超過 3 萬次瀏覽。遊戲對戰提供了容易理解的決策場景，但這段成果需要和整款遊戲通關、其他遊戲能力，以及普遍延遲保證分開看。
示範公布了哪些數字
依原始示範貼文，這次執行包含 137 次即時 API 呼叫，回應時間中位數為 592 毫秒，p95 為 987 毫秒，96.4% 回應低於一秒。
中位數表示一半觀測值較快、一半較慢。p95 則表示約 95% 回應落在這個時間以內。兩者一起看，才比較容易理解多數呼叫與較慢呼叫的差異。
| 指標 | 作者報告的單次執行結果 |
|---|---|
| API 呼叫數 | 137 次 |
| 中位回應時間 | 592 毫秒 |
| p95 回應時間 | 987 毫秒 |
| 低於一秒的比例 | 96.4% |
| 預估推論成本 | 0.028 美元 |
費用是該次示範的預估推論成本，不包含所有開發與執行資源，也不應當成任何工作流程的固定價格。
Decisions API 在流程裡做什麼
依官方文件，開發者傳入狀態，再附上命名問題。模型可以回傳是非機率、選項的機率分布，或依有順序的評分規準得到的分數。
狀態可以是文字、JSON 資料或圖片。它讓模型理解目前情境，程式則根據回傳數值安排下一步。這類介面適合分類、路由與選擇，無須先解析一段長文字回答。
模型的機率仍需要評估。數值高不代表每次都正確，產品應用自己的資料測試門檻與錯誤成本。
對戰示範還需要哪些周邊程式
遊戲代理除了決策模型，還需要取得畫面或狀態、整理可用動作，再把選擇送回遊戲。API 回應時間只描述模型介面的一段，整個操作循環還包含這些前後步驟。
FireRed 的回合制對戰，也不同於需要連續即時控制的遊戲。一次完成指定戰鬥，是具體案例，尚不能直接推論模型能處理任意操作或所有策略任務。
完整評估可以增加不同隊伍、起始狀態與重複執行，觀察成功率與失敗原因，讓示範逐步變成可比較的證據。
一般產品可以學到什麼
客服分流、內容分類或流程下一步，也常需要從有限選項中選擇。這類工作可以把選項、規則與狀態寫清楚，再由決策模型提供機率。
當機率接近或條件不完整時，可以交給人確認，或改用能力更完整的代理。這是產品設計上的分流方式，具體效果仍需要自己的任務資料。
我的判斷是，這次遊戲示範讓決策介面的用途更直觀。真正可移植的是清楚的狀態與選項設計，而單次速度和費用仍應保留在原本執行條件中。
常見問題
這是完整 FireRed 從頭通關嗎？
貼文描述四天王與冠軍戰。不能把指定戰鬥的成果擴大成全遊戲通關。
592 毫秒是服務保證嗎？
它是該次執行的中位數，其他輸入、負載與網路條件可能不同。
機率最高的選項一定正確嗎？
仍可能誤判。應用需要實際評估，也應保留處理不確定結果的方式。
結語：從示範走向可重複的決策評估
Perplexity 的 FireRed 示範提供了具體數據與畫面。將場景、狀態和動作界線寫清楚，再用多次執行檢查結果，才能知道決策模型在產品中是否可靠。
延伸閱讀：Perplexity 推出 Decisions API：文字與圖片進來，選項機率出去
