為 AI 系統進行回歸測試：LLM 評估的工程實踐

傳統系統修改了一個函式，執行一遍單元測試，全部通過就提交。在 LLM 應用中，這套方法失效了：輸出具有隨機性，同一個問題，這次回傳「好的」，下次可能回傳「好的沒錯」。修改了一版 prompt 後，如何確定沒有破壞其他功能？答案與軟體工程一致：建立一套回歸測試集。

先將「輸出」壓縮為「評分」

評估的關鍵不在於比較誰的輸出更體面，而是將輸出壓縮成一個「判定」。評分方式分為兩類：

- **確定性規則**：JSON 可解析、必填欄位非空、必須包含或不包含某些關鍵字、SQL 語法合法、答案命中參考答案。能寫成程式碼的一律寫成程式碼，零成本、零波動。

- **LLM 擔任裁判**：開放式品質（語氣是否合適、是否遺漏潛在風險、解釋是否完整）交給另一個模型按 1-5 分打分，要求它必須給出理由，並將評分標準（rubric）逐條寫入 prompt。

一條經驗法則：能用規則判斷的，不要請裁判模型。裁判本身也會產生波動，每多套用一層模型就多一層雜訊，而且需按 token 付費。

舉一個具體例子：保險條款問答機器人，規則層撰寫三條——輸出必須包含「免賠額、等待期、報銷比例」三個短語，總字數不超過 300，必須是 JSON 且欄位非空；裁判層 rubric 只寫兩條——是否有引用錯誤的條款編號（5 分制），解釋是否有超過三句話的段落（5 分制）。兩層結合後的輸出是一對分數加上一份錯誤明細，而非回覆本身。審查人員關注的是「哪條失敗、失敗原因」，無需重讀一遍模型輸出。

測試集要固定，並納入版本控制

- **30-100 條足夠**，再多邊際效益很低。測試案例從線上真實日誌中挑選，必須包含：線上真實詢問過的、被用戶投訴過的、邊界值、出現頻率最高的 Top 10 請求。

- **存入 git**：題目、參考答案、rubric 一起進行版本控制。測試集是資產，不是臨時檔案。下次更換模型時，你依靠它進行對比。

- **鎖定變數**：固定採樣溫度，鎖定模型版本、prompt 版本。一次只變動一個變數，否則測試集告訴你「有變化」，你卻不知道問題出在哪裡。

為 CI 設定門禁

改動前執行一遍完整測試集，記錄每個案例的通過與否作為基線；改完後再執行一遍，進行對照。紅綠燈標準建議如下三條：

1. 總通過率不低於基線；

2. 單一案例不允許從「通過」變為「失敗」（新增「失敗」可以討論，但要有解釋）；

3. 規則類硬錯誤（JSON 解析失敗、必填欄位缺失）直接 fail，零容忍。

將這套流程整合進 CI：prompt 變更、模型升級、依賴版本變化，先執行 eval job，未全綠不允許合併。這就是為機率系統做的「提交前檢查」。

每次執行完是否需要保留一份報告？需要。報告格式固定為四部分：總分、分類別通過率、新增失敗案例的逐條原因、新轉為通過的案例列表。目標是讓一个人在三十秒內回答「這次改動破壞了什麼」。若做不到這一點，eval 就是黑盒積分，沒人會長期關注，門禁也就形同虛設。

三個常見陷阱

1. **測試集污染**：題目混入了模型訓練數據，或出現在 few-shot 示例中，導致分數虛高，你看不到真實變化。更換新模型後，先人工抽查 10 條，再相信聚合數字。

2. **過擬合測試集**：對著 50 個案例反覆調整 prompt 直到全綠，上線後又開始犯老毛病。定期淘汰舊案例、補充新案例，讓測試集跟上線上分佈。

3. **單一案例定生死**：一條失敗不代表改動是壞的，一條通過也不代表是好的。只看聚合數字和回退名單，別盯著單一輸出糾結。

評估究竟解決什麼問題

評估不追求高分，追求「不退步」。改動前在 100 分制下得 85 分，改動後掉到 72 分，你必須找出是哪類案例下降、為什麼，改回 86 分再上線。對 AI 系統來說，回歸測試的價值不在於保證模型正確，而是當你弄壞東西時，團隊不用等用戶投訴才知道。