決策模型井噴：智能體講嘅 0.8，到底有幾可信？
一個月內十家廠商跟進決策模型，智能體架構多咗一層專用決策層。但獨立評測顯示幾乎所有模型都過度自信，唔同模型畀出嘅 0.8 含義並唔一樣。定標呢門工夫，最終落喺企業自己嘅數據同語義層上面。
智能體架構喺 10 月多咗一層專用「決策層」，但獨立評測顯示：幾乎所有決策模型都過度自信，一家廠商嘅 0.8 同另一家嘅 0.8 唔係同一回事。真正貴嘅唔係嗰幾毫秒嘅推理，而係將置信度閾值定準呢件事——佢依賴嘅標註數據、業務口徑同歷史案例，全部都喺企業自己手上。
一個月，由 1 家到 10 家
先畀未跟開呢個賽道嘅讀者一個定義：決策模型（decision model）係一種唔做文本生成、只從固定答案集合入面揀一個並返回概率嘅 AI 模型。應用將狀態（state）同一組有固定選項嘅問題傳畀佢，佢對每個選項返回一個概率，唔會自由發揮寫任何嘢。
佢解決嘅係智能體運行時嗰類高頻小決定：呢張工單應該路由畀邊個、下一步調用邊個工具、呢個輸出過唔過得到護欄、使唔使轉人工。呢類決定以前由大模型逐 token 生成答案，又慢又貴；決策模型將生成環節成個斬走——AWS Strands 團隊直接移除咗模型嘅詞元輸出頭，Liquid AI 嘅 d1 系列「唔生成 token，一次前向傳播就出答案」。
9 月 15 日 TypeSafe 發布 Jev 開創呢個品類之後，一個月內跟進嘅廠商排到咗十家（據 Tech AI Wire 10 月 15 日統計同至頂網 10 月 17 日報道）：
| 日期 | 發布 | 形態 |
|---|---|---|
| 9 月 15 日 | TypeSafe Jev（品類開創者） | 託管 API |
| 9 月 29 日 | OpenAI Decisions API（GPT-6 Luna 驅動） | 公測，DevDay 發布 |
| 10 月 1 日 | Cloudflare Clef / Clef-flash | 開源權重，Apache 2.0 |
| 10 月 1 日 | AWS Strands Decider 2B | 開源，1.9B 參數 |
| 10 月 1 日 | Perplexity pplx-decider | 開源，Apache 2.0 |
| 10 月 7 日 | Liquid AI d1-3B / d1-omni-600M | 開源 |
| 10 月 9 日 | Cloudflare Clef-omni；Microsoft-Decision-1 上架 Foundry | 開源 / 託管 |
題型高度收斂為三種：是非判斷（返回「係」嘅概率）、單選（每個選項一個概率）、評分（按概率加權落喺有序刻度上面）。託管嘅輸入價格由每百萬 token 0.02 美元到 0.24 美元唔等，相差 12 倍；InfoWorld 按 Microsoft 嘅口徑計過，1 美元可以覆蓋超過 27.5 萬次同類短決定。
喺智能體堆疊入面，佢嘅位置大概係咁：
榜單潑嘅冷水：幾乎人人都過度自信
速度同價格係廠商自己測嘅，咁獨立評測呢？評測機構 Artificial Analysis 將 13 個決策模型放喺同一張榜單上面（SystemOne Models 10 月 16 日收錄），結論唔算客氣：喺幾乎每一個概率區間上面，每個決策模型嘅實際正確率都低過佢自己聲稱嘅概率。
更刺眼嘅係置信度校準誤差（ECE）隨任務類型大幅波動：Jev 喺工具調用類任務上面校準誤差只有 0.05，喺知識推理類測試 Humanity's Last Exam 上面卻高達 0.40——同一個模型，同一句「我 80% 肯定」，喺兩種任務上面完全唔係同一回事。
Laya 嘅案例最能說明問題：佢哋嘅團隊自己喺測試入面發現，模型對高棉文文本嘅正確率係 0%，卻報出 95.2% 嘅平均置信度。一個「睇落好精確」嘅概率，會畀唔確定嘅決定鍍上一層唔應該有嘅權威感——Kanerika 嘅 AI 開發經理 Amit Kumar Jena 對 InfoWorld 嘅呢句提醒，值得貼喺每個置信度消費方嘅監控面板上面。
需要說明：上面係按公開評測數據整理嘅示意曲線，具體讀數請以 Artificial Analysis 原始分箱圖為準。另外榜單頭位 d1-ultra（65.2 分）同 Jev 1.13（57.5 分）喺「邊個第一」上面同另一張 Jev Decision Index 榜單結論相反——決策模型領域嘅基準之爭，本身都仲打緊。
0.8 嘅含義，換一家就變
HFS Research 執行研究主管阿希什·查圖爾維迪接受至頂網訪問時嘅警告，係呢波井噴入面最值得截圖保存嘅一段話：「每個模型嘅置信度分數都有佢自身嘅含義。Clef、Decider 同 Luna 畀出嘅 0.8 概率值並唔代表相同嘅可靠程度，所以針對某一個模型調優嘅閾值冇辦法直接套用落另一個模型上面。」
佢指出嘅蔓延位置都好精準：唔喺推理層，而係喺「評估同校準環節」。企業切換供應商、或者同時跑幾家方案嗰陣，必須按自己嘅數據重新校準每一個閾值。
超市巨頭 H-E-B 嘅高級數據工程師阿迪蒂亞·蘭詹補上咗另一半數：錯誤決策嘅成本。一個錯誤決策可能引發下游連鎖行動，最後嘅糾正成本可能超過推理本身慳返嚟嘅錢。佢嘅建議係唔好淨係睇推理支出，要按端到端工作流時延、單次成功決策成本、決策準確率、營運開銷、故障恢復成本五個維度嚟評估架構。
查圖爾維迪仲有一句更面向治理嘅話：每一個問題、答案集合同閾值都承載住一部分業務策略——幾時批准退款、咩先算重大事故。團隊儲起幾百個咁樣嘅「決策方案」之後，佢哋會形成一套新邏輯體系，需要好似提示詞咁樣做版本管理、責任歸屬同審查。
校準呢門工夫，最後落喺邊個頭上
到呢度邏輯閉環咗：廠商唔會替你定標。OpenAI 嘅 Decisions API 文件冇公佈任何校準數字，明確要開發者用自己嘅標註數據定閾值；AWS 嘅 Strands Decider 2B 發布說明都直接寫明「喺你自己嘅工作負載上面重新驗證」。TypeSafe 嘅 Jev 係託管服務，你連模型內部都睇唔到。
於是一個務實嘅校準閉環係咁樣嘅（綜合 OpenAI 開發者指南同多家廠商建議）：
- 每類問題收集幾百個歷史案例，由領域專家標註正確答案；
- 掃描閾值，畫出「錯放」同「轉人工比例」嘅權衡曲線；
- 喺邊際人工成本唔再換到明顯準確率提升嘅位置定 cutoff；
- 留一份從來冇參與過調參嘅驗收集，上線之前複測；
- 新方案先以影子模式跑真實流量、唔實際執行，達標之後先切換，並且保留舊路由隨時回退。
留意呢套流程用嘅所有原料：歷史案例、專家標註、業務口徑、「咩先算重大事故」嘅定義。冇一樣喺模型廠商手上。呢正正係我哋喺可核查問數同語義層衰減入面一而再撞到嗰幅牆：智能體入咗企業核心流程，撞上嘅從來唔係模型能力，而係組織知識——定義、口徑、標註、責任。
決策模型將呢幅牆又推前咗一寸：而家連「0.8 即係咩」都變成咗企業要自己回答嘅問題。
寫喺最後
決策模型本身係好事——將智能體入面高頻、可枚舉嘅小決定剝離出嚟，慳錢慳時延，方向冇問題。問題在於佢將最後一公里交返畀企業：閾值要喺你嘅數據上面調，口徑要喺你嘅組織入面定，幾百個決策方案要有人管。
如果你嘅團隊正在將呢類組件接入工作流，最好將三樣嘢備齊：按問題類型分好嘅歷史標註案例、一份寫清楚業務口徑嘅定義表、仲有令呢啲資產可以持續維護嘅語義層。呢個亦都係 OntiCards 喺做嘅嘢——用本體同卡片將企業嘅定義、口徑、數據質素收攏成一層嘅產品能力，令上層無論換邊家模型，校準嘅地基都唔使推倒重來。
有類似困境歡迎電郵 hello@onticards.com 傾下你嘅場景。
參考來源
- 至頂網：《AI智能体决策层独立化，科技巨头竞相布局专用模型》（2026-10-17）—— https://www.zhiding.cn/ai-infrastructure/2026/1017/3202554.shtml
- Tech AI Wire: "AI decision models, explained"（2026-10-15）—— https://dev.to/techaiwire/ai-decision-models-explained-59mh
- Artificial Analysis 榜單轉載（SystemOne Models）: "Jev benchmarks: every public evaluation in one place"（2026-10-16 讀數）—— https://systemonemodels.org/guides/jev-benchmarks
- Agor: "Whose Eighty Percent" —— https://agor.me/blog/whose-eighty-percent
- AiCybr: "AWS Strands Decider 2B: Open Decision Model for Local AI Agents" —— https://aicybr.com/blog/aws-strands-decider-2b-local-agent-decision-model
- World Programming: "OpenAI Decisions API: A Practical Developer's Guide" —— https://www.worldprogramming.org/posts/openai-decisions-api-a-practical-developers-guide-6wfccn
