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

在很多 AI 實驗室或新創團隊的交付流程中，最令人頭痛的並非模型能力不足，而是「不可預測性」。當你向老闆或客戶展示一個 Agent 流程時，它可能在 9 次中表現完美，但在第 10 次時突然陷入無窮迴圈，或者一本正經地胡說八道。

這種現象在工程上被稱為「隨機性漂移」。如果你的交付物僅僅是「一個 Prompt + 一個 LLM」，那麼你交付的不是產品，而是一個機率分佈。

從「微調 Prompt」到「構建閉環」

很多開發者習慣於透過不斷修改 Prompt 來修復 Bug。例如：發現模型在處理日期時出錯 $\rightarrow$ 在 Prompt 中加入「請注意日期格式必須為 YYYY-MM-DD」 $\rightarrow$ 測試通過 $\rightarrow$ 發布。

這種「打補丁」模式在複雜系統中會迅速崩潰，因為每一個新補丁都可能在另一個邊緣情境觸發新的幻覺。真正的工程化交付需要從「微調」轉向「閉環」。

1. 定義可量化的「黃金資料集」（Golden Dataset）

不要依賴隨機的對話測試。你需要為每個核心功能構建一個包含 50-100 個典型用例的黃金資料集。
- 輸入：具體的使用者請求。
- 預期輸出：不僅是文字，而是關鍵欄位（如 JSON key）或狀態轉移（如：呼叫了哪個 Tool）。
- 判定標準：定義什麼是「正確」。是語意一致？還是正規表示式匹配？還是通過了下游程式碼的校驗？

2. 實現「影子測試」與回歸流水線

在每次修改 Prompt 或升級模型版本後，必須強制執行全量回歸測試。
- 自動化比對：使用 LLM-as-a-Judge（用更強的模型如 GPT-4o 或 Claude 3.5）來比對新舊版本的輸出差異。
- 差異分析：重點關注那些從「正確」變為「錯誤」的案例，而不是關注整體得分的微小提升。

3. 將約束下沉到程式碼層（Guardrails）

不要試圖用自然語言命令模型「絕對不要做某事」。要把約束寫在程式碼裡：
- Schema 強制校驗：使用 Pydantic 或 JSON Schema 對模型輸出進行強型別校驗。如果校驗失敗，直接觸發重試機制或回退到安全模式，而不是將錯誤傳遞給使用者。
- 狀態機控制：Agent 的跳轉邏輯應由確定性的狀態機驅動，LLM 只負責決定當前狀態下的動作（Action），而不負責決定整個流程的拓撲結構。

實戰教訓：一次關於 API 呼叫失敗的處理

我們在一個自動化報告生成專案中曾遇到過這樣的問題：模型在呼叫外部 API 失敗時，會嘗試偽造一個看起來很真實的 API 回傳結果來維持對話流暢度。這導致最終生成的報告中出現了大量虛假資料。

解決方案：
我們引入了一個簡單的中介軟體層。所有 Tool 的回傳結果在交給 LLM 之前會被打上 [SYSTEM_VERIFIED] 標籤；同時，我們在 System Prompt 中明確規定：「如果你看到的上下文沒有 [SYSTEM_VERIFIED] 標籤且 API 回傳錯誤，你必須直接告知使用者『資料獲取失敗』，嚴禁基於常識推測結果。」

透過將「真實性」的判定權從 LLM 的自覺性轉移到系統標籤上，我們將該場景的幻覺率從 15% 降低到了接近 0%。

總結

AI 工程化的本質是用確定性的工程手段去包裹不確定性的機率模型。當你不再追求一個「完美的 Prompt」，而是開始構建一套能夠快速發現錯誤、量化品質並強制執行約束的流水線時，你的 AI 應用才真正具備了生產環境的可交付性。