別讓「Prompt 調優」成為交付的黑盒：建立 AI 交付的版本基準線

在 AI Lab 的實際交付現場，最容易陷入的陷阱之一就是所謂的「Prompt 調優迴圈」。

很多團隊在交付初期會經歷這樣一個場景：工程師發現模型輸出不符合預期 $\rightarrow$ 修改 Prompt $\rightarrow$ 測試幾個 Case $\rightarrow$ 覺得 OK 了 $\rightarrow$ 上線 $\rightarrow$ 客戶反饋某個之前正常的 Case 現在掛了 $\rightarrow$ 再次修改 Prompt。

這種「打補丁」式的迭代方式，本質上是在用一個不可控的變數（自然語言）去修補另一個不可控的變數（機率模型）。如果沒有一套嚴格的版本基準線（Baseline），Prompt 的每一次微調都像是在玩一場沒有地圖的掃雷遊戲。

從「感覺 OK」到「量化 OK」

在工程化交付中，我們需要將 Prompt 從「文學創作」轉變為「設定管理」。

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

不要依賴於隨機抽取的測試集。一個合格的交付專案必須擁有一套由業務專家審核過的黃金資料集。它應該包含：
- 邊界 Case：那些最容易觸發模型幻覺或拒絕回答的極端輸入。
- 回歸 Case：歷史上出現過且被修復的問題點。
- 基準 Case：定義什麼是「正確」的標準答案。

2. 實現 Prompt 的版本化管理

嚴禁直接在程式碼或資料庫中硬編碼 Prompt。建議採用以下結構：
prompts/{category}/{version}/system_prompt.txt
每次修改 Prompt 時，必須增加版本號（如 v1.0.1 $\rightarrow$ v1.0.2），並記錄修改的具體原因（例如：「修復了在處理多輪對話時遺失上下文的問題」）。

3. 建立自動化評測流水線 (Eval Pipeline)

每次 Prompt 更新後，必須強制執行全量黃金資料集評測。評測指標不能僅靠 LLM-as-a-Judge，而應結合：
- 確定性校驗：檢查輸出是否包含必須的 JSON 欄位、是否符合正規表示式格式。
- 語意相似度：計算與標準答案的 Cosine Similarity 或使用 BERTScore。
- 負向指標：統計出現特定違禁詞或錯誤模式的頻率。

實戰教訓：一次關於「禮貌」的翻車

我們在一個金融類 AI 助手專案中曾遇到過這種情況：為了讓模型顯得更專業、更有禮貌，我們將 System Prompt 中的語氣詞進行了微調。結果在通過了小規模抽檢後上線，卻發現模型在處理某些緊急報錯請求時，因為過於冗長的禮貌開場白，導致關鍵的錯誤代碼被截斷或被使用者忽略，嚴重影響了除錯效率。

這次事故告訴我們：任何對 Prompt 的微調，都可能在機率分佈上產生非線性的偏移。

給交付團隊的建議

如果你現在正處於 AI 專案的交付壓力中，請立即停止那種「試一次 $\rightarrow$ 改一次」的低效迴圈。

嘗試建立一個簡單的表格：
| 版本 | 修改點 | 通過率 (Golden Set) | 回歸失敗數 | 結論 |
| :--- | :--- | :--- | :--- | :--- |
| v1.2 | 增加約束條件 A | 92% $\rightarrow$ 95% | 2 | PASS (可上線) |
| v1.3 | 修改語氣為專業風 | 95% $\rightarrow$ 91% | 8 | FAIL (回滾) |

只有當你的 Prompt 修改能夠通過量化的數據證明其「淨收益」為正時，它才具備進入生產環境的資格。AI 的交付不是藝術創作，而是嚴謹的工程實驗。