PLAY AI 筆記挑 AI 模型，比起跑分我更在意的其實是「穩定度」
榜單上高兩分的模型，如果二三十次就有一次格式失控，放進自動流程後可能比能力稍低但穩定的模型更難用。
本篇內容
一開始我也是看榜單挑的
剛開始接不同模型的時候，我的做法很單純：哪個分數高就先試哪個。榜單很適合縮小候選範圍，但真的把模型放進產品或自動化流程後，我在意的東西很快就變了。
自動化不是只問「它最好的一次能多好」，而是問「同樣條件重跑很多次，最差的一次會發生什麼」。一個偶爾多講一句話的模型，對聊天可能無傷大雅；對要求固定 JSON 的 API 流程，卻可能直接讓解析中斷。
真正讓我改觀的是一次回傳格式
有一條流程要求模型回傳固定格式的 JSON。能力很強的模型大部分時候寫得又快又好，但偶爾會在 JSON 前面補一句說明，或把原本該是陣列的欄位換成另一種形狀。單看回答內容沒有很嚴重，對程式卻是完全不同的輸入。
後來我才意識到，「幾乎總是符合契約」和「每一次都符合契約」之間的差距，會直接變成工程成本：重試、容錯、schema 驗證、告警、人工介入，全部都是那幾次例外衍生出來的。
穩定度其實不只一種
我現在會分開看的四種穩定度
| 面向 | 我要觀察什麼 | 失敗時的影響 |
|---|---|---|
| 格式穩定 | JSON、欄位、工具呼叫是否符合契約 | 解析失敗，後續流程直接停 |
| 語意穩定 | 相同任務是否突然偏題或漏掉核心要求 | 內容品質波動，需要人工重看 |
| 延遲穩定 | 不是只看平均速度，而是尾端延遲是否常暴增 | 排程塞車、使用者以為服務壞掉 |
| 服務穩定 | 限流、暫時不可用、串流中斷是否頻繁 | 需要 fallback、重試與狀態管理 |
這些問題不一定能從一般 benchmark 看出來。Benchmark 很擅長回答「這個模型會不會做某件事」，但產品更常遇到的是「它能不能在我的契約、流量和輸入分布下持續做到」。
所以我現在怎麼測
現在我不會只跑一個漂亮 prompt 看一次結果，而是準備一組接近真實流量的固定案例：短問題、長上下文、邊界格式、容易誤解的輸入，以及明確的 schema。然後重跑多次，記錄失敗類型，而不是只挑最好看的回答。
- 先固定測試集合與判定規則，不要看到結果後才決定什麼叫成功。
- 能力與穩定分開記：內容答得好，不代表輸出契約也穩。
- 把 transient error 與模型語意錯誤分開，兩者的處理方式完全不同。
- 最後才比較成本與速度，避免用便宜或快掩蓋根本不可控的失敗。
Benchmark 還是有用，只是位置不同
我不是覺得 benchmark 沒用。它非常適合第一輪篩選：例如需要程式能力，就先從相關評測較強的模型開始。但進入產品前，我一定還會補一輪自己的 workload 測試。公開榜單告訴你能力上限，自家測試才告訴你能不能放心接進流程。