別把「自動化」當成「免檢」：AI 交付中的回歸測試死穴

在 AI Lab 的交付現場，最危險的幻覺之一就是：「我已經寫了自動化腳本，所以這次更新是安全的。」

很多團隊在升級模型版本（比如從 GPT-4o 遷移到某個更輕量但更快的模型）或調整核心 Prompt 後，會運行一套所謂的「自動化測試集」。如果腳本顯示 95% 的 Case 通過了，團隊通常會迅速點擊發布。

但問題在於，LLM 的失效模式（Failure Mode）與傳統軟體完全不同。傳統軟體的 Bug 是確定性的——輸入 A 必然導致錯誤 B；而 AI 的失效是機率性且語義化的。

1. 「通過」不等於「正確」

在傳統的單元測試中，我們比對的是 expected == actual。但在 AI 交付中，我們往往使用 LLM-as-a-Judge 來判定結果是否正確。

這裡隱藏著一個巨大的死穴：評判模型（Judge Model）的偏好漂移。

我曾處理過一個案例：團隊使用 GPT-4 作為 Judge 來驗證一個摘要生成任務。當他們升級了生成模型後，Judge 模型給出的分數反而提高了。團隊欣喜若狂地發布了版本，結果上線後用戶投訴激增——原來新模型學會了用一種「看起來很專業但實際上空洞」的語氣說話，而 Judge 模型恰恰被這種「專業語氣」給欺騙了。

這就是典型的 「形式正確，語義失效」。

2. 回歸測試的三個誤區

在工程實踐中，要避開以下三個坑：

• 過度依賴單一指標（Metric Trap）： 不要只看 BLEU 或 ROUGE 分數。這些指標衡量的是文本重疊度，而不是邏輯正確性。一個關鍵事實的錯誤（例如將「不能」寫成「能」）在指標上可能只降低了 1%，但在業務上是致命的。
• 測試集規模不足（Sample Bias）： 100 個 Case 的通過率不能代表生產環境的穩定性。AI 的長尾效應意味著某些極端的輸入組合才會觸發崩潰。
• 忽略「負向回歸」（Negative Regression）： 我們習慣於檢查新功能是否實現，但很少檢查原有的、已經穩定的邊緣 Case 是否被破壞。

3. 構建真正的 AI 回歸防線

要解決這個問題，我們需要將「自動化」升級為「可審計的驗證體系」：

A. 構建黃金數據集 (Golden Dataset)

不要用隨機生成的樣本做測試。必須由領域專家手動標註一套包含 $\sim$500 個核心場景的 Golden Set，且每個 Case 必須包含：
- 輸入 (Input)
- 必須包含的關鍵點 (Must-have points)
- 絕對禁止出現的詞彙/邏輯 (Forbidden points)
- 理想答案 (Ideal Answer)

B. 實現多維度交叉驗證 (Cross-Verification)

不要只信一個 Judge 模型。採用 $\text{LLM} \rightarrow \text{Rule} \rightarrow \text{Human}$ 的三層過濾：
1. LLM Judge： 初篩語義方向。
2. Deterministic Rules： 使用正則或 JSON Schema 強制校驗格式和關鍵字段是否存在。
3. Human Spot Check： 在發布前，隨機抽取 $5\%$ 的 $\text{Pass}$ 和 $100\%$ 的 $\text{Fail}$ 進行人工審計。

C. 對比分析而非單點評分 (Diff Analysis)

不要看分數是否從 $0.85$ 變成 $0.87$，而要看 $\text{Diff}$ 集：哪些之前通過的現在失敗了？哪些之前失敗的現在通過了？如果一個原本正確的 Case 在升級後變錯了，即使整體分數上升，這個版本也絕對不能發布。

總結

AI 工程化的本質不是追求一個完美的 Prompt，而是構建一套能夠快速發現失效、並能量化風險的基礎設施。記住：自動化腳本是用來提高效率的，而審計流程才是用來保證品質的。 不要讓自動化成為你閉眼發布的理由。