別讓「幻覺」成為交付的遮羞布：在 AI Lab 中建立基於確定性的驗證閉環

在很多 AI Lab 的交付現場，最令人焦慮的時刻不是模型不聰明，而是它「偶爾」會犯錯。當客戶問起「為什麼這次結果錯了」時，很多團隊習慣於用一個模糊的詞來掩蓋：幻覺 (Hallucination)。

但從工程交付的角度來看，「幻覺」這個詞是危險的。因為它暗示了錯誤是不可預測、不可避免且隨機發生的。如果一個交付物被定義為「偶爾會有幻覺」，那麼它在商業邏輯上就是不可用的。

真正的 AI 工程化，應該是將「機率性的生成」包裹在「確定性的驗證」之中。

從「提示詞優化」到「驗證閉環」

大多數團隊在面對錯誤時的路徑是：發現錯誤 $\rightarrow$ 修改 Prompt $\rightarrow$ 測試 $\rightarrow$ 發現新錯誤 $\rightarrow$ 再次修改 Prompt。這是一個典型的死迴圈，因為你試圖用一個機率性的工具（LLM）去修復另一個機率性的結果。

在實際的 AI Lab 交付中，我們推崇的是驗證閉環 (Verification Loop)。其核心邏輯是：不信任 LLM 的自評，只信任可程式化的斷言。

1. 定義「硬性約束」斷言

不要問模型「你剛才生成的答案正確嗎？」，而要編寫程式碼去檢查：
- 格式斷言：輸出是否嚴格符合 JSON Schema？
- 引用斷言：答案中的每一個事實點是否都能在檢索到的 Context 中找到原文索引？（透過計算 Token 重疊度或使用小型 Cross-Encoder 模型）
- 邏輯斷言：如果答案包含數值計算，是否可以透過 Python exec() 或簡單的正則表達式提取並重新計算一遍？

2. 建構「負樣本」回歸集

很多團隊只關注 Positive Case（跑通了沒），而忽略了 Negative Case（怎麼才算錯）。
一個成熟的交付專案需要維護一個 $\text{Error-Bank}$：記錄所有曾經出現過的幻覺案例，將其轉化為測試用例。每次 Prompt 更新後，必須確保這些歷史錯誤不再復現，而不是僅僅看幾個新例子跑得順不順。

實踐案例：知識庫 RAG 的確定性增強

在一個金融文件分析的專案中，我們遇到了典型的「細節幻覺」——模型會把 A 公司的營收數據安在 B 公司頭上。

我們放棄了透過增加 System Prompt（如「請仔細核對公司名稱」）來解決問題，而是引入了一套雙路校驗機制：
1. 提取路：LLM 生成答案的同時，必須強制輸出 {"fact": "...", "source_chunk_id": "..."} 的結構化列表。
2. 校驗路：由一個輕量級的 Python 腳本遍歷所有 source_chunk_id，檢查該 Chunk 中是否真的包含 fact 中的關鍵實體和數值。如果校驗失敗，直接觸發重試或標記為「無法確認」。

這種做法將準確率從 85% 提升到了 98%，且最重要的是，我們能給客戶一個確定的解釋：「這裡沒有關閉是因為校驗路未能在原文中找到證據」，而不是「模型產生了幻覺」。

給 AI 工程團隊的建議

AI Lab 的交付不是在寫詩，而是在建構工業流水線。請記住以下三點：
- 警惕 Prompt 依賴症：當你發現自己連續三天在微調同一個 Prompt 的措辭時，你應該考慮的是增加一層程式碼層面的驗證邏輯。
- 量化錯誤分佈：不要說「感覺好多了」，要說「在 500 個回歸集樣本中，幻覺率從 12% 下降到了 3%」。
- 接受「不知道」：一個敢於承認「根據現有資料無法得出結論」的 Agent，比一個一本正經胡說八道的 Agent 要有價值得多。

真正的鍊金術不是把鉛變成金子，而是透過嚴苛的過濾和純化，剔除掉所有的雜質。