別把 AI 交付當成「寫程式」：為什麼 AI 工程化需要一套完整的「回歸測試集」

在 AI Lab 的交付現場，很多團隊習慣於用「調優 Prompt」來解決 Bug。當使用者回饋某個 Case 報錯時，工程師迅速修改 Prompt，驗證該 Case 通過，然後宣布 Bug 修復。

但這種做法在 AI 工程化中極其危險。因為 LLM 的非確定性意味著：你修復了 Case A，極大機率在不經意間破壞了已經通過的 Case B、C 和 D。

1. 「打地鼠」式交付的死迴圈

我們曾經歷過一個典型的場景：為一個法律文件分析系統優化擷取精度。
- 第一天：修復了「合約金額擷取錯誤」，結果導致「簽署日期擷取」開始出現幻覺。
- 第二天：修復了日期問題，結果導致原本正常的「違約條款判定」變得過於保守。
- 第三天：試圖透過增加 Few-Shot 來統一兩者，結果導致模型輸出格式偶爾崩潰。

這種「打地鼠」式的開發模式讓交付週期無限拉長，且團隊對系統的信心降至冰點。

2. 建構 AI 時代的「黃金資料集 (Golden Dataset)」

要打破這個迴圈，唯一的路徑是建立一套不可妥協的回歸測試集。這不再是簡單的單元測試，而是一套包含 $\text{Input} \rightarrow \text{Expected Output}$ 的黃金樣本庫。

工程化實施路徑：

• 樣本分級 (Tiering)：將樣本分為 P0（核心功能，必須 100% 通過）、P1（邊緣場景，允許少量波動）、P2（探索性場景）。
• 自動化評測流水線 (Eval Pipeline)：每次修改 Prompt 或模型版本後，強制執行全量 P0 測試集。使用 LLM-as-a-Judge 或精確匹配來判定通過率。
• 回歸報告 (Regression Report)：不僅報告通過率，更要列出 Previously Pass $\rightarrow$ Now Fail 的具體樣本。這才是決定是否允許發布的核心指標。

3. 從「感覺不錯」到「數據證明」

AI 工程化的本質是將「玄學調優」轉化為「量化迭代」。當你能自信地說出「這次 Prompt 修改提升了 P0 集的準確率從 88% 到 92%，且沒有引入任何 P0 回歸」時，交付才真正進入可控狀態。

結論是： 在 AI Lab 中，一個完善的評測集比一個強大的模型更重要。沒有回歸測試的 AI 交付，本質上是在進行一場豪賭。