告別「幻覺」：在 AI Lab 交付中建立可驗證的工程閉環

在很多 AI 實驗室或新創團隊的交付流程中，最令人頭痛的並非模型能力不足，而是「不可預測性」。

一個典型的場景是：工程師在本機 Notebook 裡透過幾個精心挑選的案例（Case）證明了提示詞（Prompt）的有效性，信心滿滿地推向生產環境。結果上線一小時後，使用者回饋大量奇怪的輸出——模型開始胡言亂語，或者在某些邊緣情境下完全失效。

這種現象我們稱之為「交付幻覺」：誤以為局部驗證的成功等同於系統級的穩健性（Robustness）。要打破這個循環，我們需要將 AI 的交付從「文學創作」轉向「工程驗證」。

從 Case-by-Case 到 Eval-Driven

大多數團隊的迭代路徑是：修改 Prompt $\rightarrow$ 手動測試 3 個 Case $\rightarrow$ 覺得 OK $\rightarrow$ 部署。

這種路徑最大的問題在於缺乏迴歸測試。當你為了修復 Case A 而修改 Prompt 時，你可能在無意中破壞了原本正常的 Case B。

工程化方案：建構最小可行評估集 (Golden Dataset)
不要試圖覆蓋所有情境，但必須建立一個包含 50-100 個核心情境的 Golden Set。每個 Case 包含：
1. Input: 標準輸入。
2. Expected Output/Constraint: 並非要求字對字一致（這在 LLM 中不可能），而是定義「通過」的標準（例如：必須包含某個關鍵字、JSON 格式必須正確、不能出現特定禁詞）。
3. Failure Reason: 當該 Case 失敗時，預期的失敗模式是什麼。

每次 Prompt 修改後，必須執行全量 Eval。只有當 New_Pass_Rate >= Old_Pass_Rate 且 Critical_Cases 全部通過時，才允許合併程式碼。

處理「非確定性」的三個技巧

LLM 的隨機性是工程化的天敵。在交付過程中，我建議採取以下三種策略來降低不確定性：

1. 結構化輸出的強約束

不要依賴模型「盡量輸出 JSON」。使用 Pydantic 或 JSON Schema 進行強制校驗。如果模型輸出格式錯誤，直接觸發一次自動重試（Retry Loop），並在日誌中記錄重試次數。如果連續三次失敗，則判定為系統級故障而非隨機波動。

2. 少樣本 (Few-Shot) 的動態注入

靜態的 Few-Shot 往往覆蓋面不足。更高效的做法是建立一個向量資料庫（Vector DB），儲存高品質的 $\text{Input} \rightarrow \text{Output}$ 對。根據當前使用者的輸入，動態檢索最相似的 3 個例子注入到 Prompt 中。這能顯著提升模型在特定領域任務中的穩定性。

3. 分解複雜鏈路 (Chain of Thought $\rightarrow$ Pipeline)

不要試圖用一個巨大的 Prompt 完成所有事情。將任務分解為：意圖識別 $\rightarrow$ 參數提取 $\rightarrow$ 知識檢索 $\rightarrow$ 最終生成。
每一個環節都可以獨立進行單元測試和評估。當結果出錯時，你可以迅速定位是哪個環節出了問題，而不是對著一個 2000 字的 Prompt 發呆猜測哪裡寫錯了。

給交付團隊的 Checklist

如果你正處於 AI 專案的交付階段，請檢查你的流程是否包含以下項目：
- [ ] 是否有一個版本化的 Golden Dataset？
- [ ] 是否實現了自動化 Eval 腳本（而非手動抽檢）？
- [ ] 是否對所有 LLM 呼叫設定了逾時和重試機制？
- [ ] 是否有針對結構化輸出的 Schema 校驗？
- [ ] 是否記錄了生產環境中的 Bad Cases 並將其反饋到評估集中？

AI 工程化的本質就是用確定性的流程去管理不確定性的模型。當你不再依賴「感覺」，而是依賴「指標」時，交付才真正開始變得可控。