別讓「Prompt 調優」成為 AI 交付的遮羞布：為什麼你需要一套可量化的「回歸基準線」

在 AI Lab 的實際交付過程中，我經常聽到一種聲音：「這個效果還沒達到預期，我再調一下 Prompt。」

這句話聽起來很專業，但實際上，它是 AI 工程化中最危險的陷阱之一。很多團隊將 LLM 應用的迭代簡化為一個「玄學循環」：修改 Prompt $\rightarrow$ 運行幾個 Case $\rightarrow$ 感覺好了一點 $\rightarrow$ 上線 $\rightarrow$ 用戶反饋崩了 $\rightarrow$ 繼續修改 Prompt。

這種缺乏量化基準的「體感調優」，本質上是在用隨機碰撞代替工程管理。

「體感調優」的三個致命缺陷

1. **回歸失效（Regression Blindness）**：當你為了修復 Case A 的錯誤而修改 Prompt 時，你可能在無意中破壞了之前已經跑通的 Case B 和 C。由於沒有全量回歸，這種破壞在上線前是不可見的。

2. **邊際效用遞減**：在沒有基準線的情況下，你很難判斷當前的 Prompt 優化是否已經觸及模型能力的上限，還是僅僅在進行低效的文字遊戲。

3. **無法量化交付進度**：面對老闆或客戶時，「感覺好多了」不是一個合格的進度匯報。一個合格的工程匯報應該是：「當前版本在核心鏈路的準確率從 65% 提升至 82%，Bad Case 主要集中在 XX 場景。」

建構「回歸基準線」的三步走策略

要擺脫這種困境，你需要將「調優」轉化為「實驗」。

第一步：建構最小可行性資料集（Golden Set）

不要試圖覆蓋所有場景，而是挑選出 50-100 個最具代表性的 Case。這個資料集應包含：

- **Happy Path**：最核心、必須正確的標準路徑。

- **Edge Cases**：已知的邊界條件和歷史 Bad Cases。

- **Negative Cases**：明確要求模型拒絕或處理異常的輸入。

每個 Case 必須包含：`Input` $\rightarrow$ `Expected Output (or Key Constraints)` $\rightarrow$ `Reasoning`.

第二步：定義多維度的評測指標（Evaluation Metrics）

放棄單一的「LLM-as-a-Judge」（雖然它很有用），引入組合指標：

- **硬指標（Hard Match）**：對於結構化輸出（JSON/XML），使用 Schema 校驗和關鍵字欄位匹配。

- **軟指標（Semantic Similarity）**：使用 BERTScore 或特定領域的關鍵詞覆蓋率。

- **邏輯斷言（Logic Assertions）**：檢查輸出中是否包含必須出現的步驟或禁詞。

第三步：建立「版本 $\rightarrow$ 分數」映射表

每次修改 Prompt 後，強制運行全量 Golden Set，生成一份對比報告：

- **Pass Rate**: 總通過率的變化。

- **Regression Count**: 新引入的錯誤數量。

- **Improvement Count**: 修復的舊錯誤數量。

只有當 `Improvement > Regression` 且 `Pass Rate` 提升時，該版本才具備上線資格。

寫在最後

AI 工程化的核心不在於尋找那個「完美的 Prompt」，而在於建構一套能夠快速發現錯誤、量化改進並防止退化的系統。

當你不再說「我再試一次」，而是說「這次迭代提升了 4% 的召回率」時，你才真正從一個 Prompt 工程師變成了 AI 系統工程師。