今天在語言模型上做開發的團隊，拿到的原始能力大同小異。一把 API key 不構成競爭優勢。真正把「撐得過頭一千個真實用戶」的系統區分出來的東西，遠比選哪個模型無聊得多：一套枯燥、但持續維護的評估集。
Demo 陷阱
原型一個下午就做好了。在工程師試過的那六個例子上運作正常。展示很成功，項目被判定為可行。
然後它遇上生產流量：輸入更長、更亂、有一半不是英文、偶爾帶有惡意，而且經常涉及沒有人寫下來的邊緣情況。原本感覺「基本上不會錯」的失敗率，實際上是百分之四 —— 而每日一萬次請求的百分之四，就是每天四百次糟糕體驗。
問題不在於原型做錯了。問題在於沒有人講得出它的準確率到底是多少，因為根本沒有量度過。
評估集到底是什麼
它不是 benchmark。公開 benchmark 量的是通用能力；你要量的是你自己那個任務。
一套能用的評估集有四個部分：
- 案例。 來自真實使用或貼近真實的模擬輸入，包括難看的那些。一百條足以起步，一千條就相當舒服。
- 預期行為。 未必是精確的預期輸出，往往是一種性質：有引用、有禮貌地拒絕、回傳符合 schema 的合法 JSON、不會憑空生成一個保單號碼。
- 評分器。 能用確定性斷言就用斷言，不能才用模型評分。模型評分器本身也要抽查，因為一個會漂移的評分器比沒有評分器更糟。
- 紀錄。 每次執行都保存，連同模型版本、提示版本與分數。這是團隊最常跳過的一環，也是回報最大的一環。
為什麼值得
三個時刻會讓這筆投資的價值一目了然。
升級的時候。 新模型版本發佈了。它對你的任務更好，還是只在供應商的圖表上更好？沒有評估，你會從用戶那裡知道答案。有評估，十五分鐘內就知道。
回歸的時候。 有人為了省 token 把提示縮短。延遲改善了、成本下降了，而某一類輸出悄悄變差。評估在合併之前就抓到；人手看三個例子抓不到。
爭論的時候。 當持份者說 AI「這星期感覺變差了」，你手上不是有個數字，就是要開一場辯論。數字會結束辯論 —— 包括那些他們其實是對的時候。
怎樣做而不拖慢項目
反對意見永遠是時間。實際上，評估工作愈早、愈小規模開始，複利效應愈快：
- 動手做功能之前，先寫下二十條案例以及「好答案長什麼樣」。單是這一步，就會提前暴露原本要到第六週才浮現的範圍分歧。
- 把機械可判的部分自動化 —— schema 合法性、必填欄位、拒答行為、延遲、成本。
- 每發現一次生產失敗，就把它加進評估集。一張 bug 單就是一條免費測試案例。
- 全部放進 CI。不自動執行的東西，就等於不會被執行。
這些都不需要一個平台。一個測試案例資料夾、一個腳本、一份保存下來的結果檔，已經可以帶團隊走很遠。
不舒服的那一部分
有時候評估會告訴你：這條路走不通。檢索找到正確段落的頻率不夠高、模型無法穩定遵守約束、這個任務真的需要人在迴路中。
在第二週知道，是好結果。上線之後才知道，是事故。評估集就是把後者換成前者的東西 —— 所以我們先建它，也所以我們把它視為交接時最重要的交付物。
文章反映撰寫當時的工程實踐，僅供一般參考。