Benchmark 高分，不等於你的產品會變好
每次模型更新，最先出現的通常是漂亮的 benchmark 表格。但產品團隊真正想知道的問題是：客服摘要是否更穩定？程式碼 review 是否少漏掉問題？使用者是否更容易得到可採取的答案？公開測試可以幫你理解模型的能力範圍，卻不能取代自己的 evaluation。
模型升級應該被視為一個需要驗證的變更，而不是一次單純的設定切換。你要比較的不是模型的名氣，而是它對關鍵任務、成本、延遲與失敗模式的整體影響。
先建立自己的任務集合
從真實工作中抽出一組去識別化的 inputs，按任務分成幾類：資訊擷取、分類、摘要、程式生成、工具呼叫或多輪對話。每類都保留成功案例與失敗案例，也要保留那些「看起來答對，但其實不符合規則」的灰色案例。
一個小而有代表性的集合，通常比一大堆沒有明確評分方式的資料更有用。任務集合的目的，是讓團隊在換 model、換 prompt 或換 retrieval strategy 時，都能快速看見差異。
評分不只需要一個分數
對不同任務使用不同的判準。分類可以看 precision、recall 或 confusion matrix；摘要除了涵蓋重點，也要看是否捏造；程式碼除了能否執行，還要看 API 邊界、可讀性與測試；工具呼叫則要看參數是否正確、失敗時是否安全停止。
如果使用 LLM-as-a-judge，請把它當成輔助訊號，而不是唯一裁判。固定 rubric、抽樣人工複核，並定期檢查 judge 是否偏好某種文風或答案長度。可以量化的部分用程式檢查，必須依賴語意的部分才交給人工或 judge。
一定要保留 baseline 與失敗案例
沒有 baseline，就很難知道新模型到底帶來多少改善。baseline 不一定是上一代模型，也可以是現有規則、人工流程，或一個簡單但穩定的 fallback。每次測試都記錄版本、prompt、資料切分與評分規則，否則幾週後很難重現當時的結論。
失敗案例則是最有價值的回饋。將錯誤依原因分類：缺少上下文、指令衝突、格式不穩定、工具選錯、拒答不當，或只是資料本身含糊。這些分類會告訴你下一步該換模型、改 prompt、補資料，還是重新設計 workflow。
把 evaluation 接進發布流程
模型升級不應該只在 playground 裡比較幾次。把固定任務集合接到一個可重跑的 evaluation script，讓 pull request 或 staging 流程能產生簡短報告。當新版本通過基本門檻，再用一小部分流量或內部使用者做 shadow test，觀察真實輸入下的 latency 與失敗率。
這樣的流程不會消除不確定性，但會讓不確定性變得可見。開發者不必宣稱「這個模型全面更強」，只需要說清楚它在哪些任務更好、在哪些案例退步，以及團隊是否接受這個取捨。那才是模型發布真正能被產品使用的形式。
