別把「Prompt 調優」當成工程交付：為什麼 AI 專案需要一套可量化的「回歸測試集」

在 AI Lab 的實際交付過程中，很多團隊最容易陷入的誤區就是：把 Prompt 的反覆迭代（Tuning）等同於產品的工程化交付。

很多開發者在交付前會經歷這樣一個循環：發現一個 Case 報錯 $\rightarrow$ 修改 Prompt $\rightarrow$ 測試該 Case 通過 $\rightarrow$ 發現另一個 Case 報錯 $\rightarrow$ 再次修改 Prompt。這種「打地鼠」式的開發模式，在專案初期能快速出 Demo，但在面對複雜業務邏輯和大規模用戶輸入時，會導致系統穩健性極差。

「打地鼠」陷阱與回歸失效

當你為了修復 Case B 而修改 Prompt 時，你很難在沒有自動化驗證的情況下確認：這次修改是否破壞了之前已經修復的 Case A。

在傳統的軟體工程中，我們透過單元測試（Unit Test）和整合測試來保證功能的穩定性。但在 AI 交付中，由於 LLM 輸出的隨機性和非確定性，很多團隊習慣於「肉眼觀察」或「抽樣檢查」。這種做法在面對數百個邊緣情境（Edge Cases）時完全失效。

建構「原子級」回歸測試集 (Regression Test Set)

要擺脫 Prompt 調優的泥淖，必須建立一套可量化的回歸測試集。這套集合不應該是隨機的樣本，而應該是基於業務邏輯拆解的「原子能力驗證點」。

1. 定義原子能力 (Atomic Capabilities)

不要測試「整個流程是否正確」，而要將流程拆解為原子能力。例如一個法律文件分析助手：
- 能力 A： 能否準確提取合約中的主體名稱？
- 能力 B： 能否識別出違約條款中的時間期限？
- 能力 C： 能否在文件缺失關鍵資訊時給出明確提示而非幻覺？

2. 建構黃金資料集 (Golden Dataset)

為每個原子能力準備 10-20 個典型 Case，包含：
- 正向樣本： 標準輸入 $\rightarrow$ 標準預期輸出。
- 負向樣本： 異常輸入/干擾資訊 $\rightarrow$ 預期的拒絕回應或錯誤處理。
- 邊界樣本： 極長文本、極端格式、多語言混合輸入 $\rightarrow$ 系統不崩潰且維持核心邏輯。

3. 實現自動化評分機制 (Evaluation Pipeline)

不要依賴人工打分，建立三層驗證體系：
- 硬匹配 (Exact Match)： 用於提取類任務（如 JSON Key 是否存在）。
- LLM-as-a-Judge： 使用更高能力的模型（如 GPT-4o 或 Claude 3.5）作為裁判，根據預設的評分量表（Rubric）對輸出品質進行打分（1-5 分）。
- 語意相似度 (Semantic Similarity)： 透過 Embedding 計算輸出與標準答案的餘弦相似度。

工程實踐建議

在實際操作中，建議將這套流程整合到 CI/CD 中。每次修改 Prompt 或更換模型版本後，自動觸發全量回歸測試。如果某個原子能力的得分下降超過 5%，則禁止合併程式碼。

結論： AI 專案的成熟標誌不是 Prompt 寫得多麼精妙，而是你擁有一套能夠告訴你「這次修改破壞了什麼」的量化指標體系。只有將「玄學調優」轉化為「工程驗證」，AI 應用才能真正從 Lab Walkthrough 進入生產環境。