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

在 AI 實驗室（AI Lab）從 Demo 走向生產交付的過程中，最令工程師頭疼的不是模型不夠強，而是模型不可控。很多團隊在交付初期會陷入一個循環：發現 Bug $\rightarrow$ 修改 Prompt $\rightarrow$ 測試通過 $\rightarrow$ 發現另一個 Bug $\rightarrow$ 修改 Prompt $\rightarrow$ 原本通過的 Case 又掛了。

這種「打地鼠」式的開發模式，本質上是因為缺乏一套可驗證的工程閉環。

從「感覺不錯」到「量化通過」

大多數 AI 交付的失敗始於對品質的模糊定義。當產品經理說「這個回答感覺有點生硬」或者「偶爾會胡說八道」時，這在工程上是不可執行的指令。

要打破這個局面，第一步是將「體感」轉化為「資料集」。我們建立了一套名為 Golden Dataset (金標集) 的機制：
1. Case 萃取：將所有線上報錯、使用者投訴、以及預期中的邊界情況，全部轉化為 (Input, Expected_Output, Evaluation_Criteria) 的三元組。
2. 評測維度拆解：不再使用單一的「正確/錯誤」，而是將維度拆解為：
- 事實準確性 (Factuality)：是否包含虛假資訊？
- 指令遵循度 (Instruction Following)：是否滿足了所有格式要求？
- 安全性 (Safety)：是否觸發了敏感詞或違規輸出？

建構自動化評測流水線 (Eval Pipeline)

手動測試是不可持續的。在實際交付中，我們引入了 LLM-as-a-Judge 的架構，利用更高能力的模型（如 GPT-4o 或 Claude 3.5 Sonnet）作為裁判來審計輕量級模型的輸出。

我們的流水線邏輯如下：
Prompt 修改 $\rightarrow$ 全量 Golden Set 推理 $\rightarrow$ Judge 模型打分 $\rightarrow$ 回歸報告。

在這個過程中，最關鍵的是 Judge Prompt 的穩定性。為了防止裁判模型本身產生幻覺，我們採用了「少樣本引導 (Few-shot)」和「思維鏈 (CoT)」要求裁判模型先給出理由，再給出分數。例如：

「請先分析輸出內容與參考答案在事實點上的差異，列出具體不一致的地方，最後根據差異程度給出 1-5 分。」

處理「長尾幻覺」的工程手段

即便有了評測集，AI 依然會在某些極端 Case 上翻車。此時，單純靠調優 Prompt 已經觸及天花板，我們需要引入工程化的約束手段：

1. RAG 的強制錨定

為了解決知識性幻覺，我們實施了 Citation Enforcement (引用強制)。要求模型在生成每一段結論時，必須標註來源片段的 ID（如 [Source 1]）。如果模型無法在上下文中找到支撐點，則必須回答「無法從現有資料中得出結論」。這直接將生成問題轉化為了檢索匹配問題。

2. 輸出格式的硬約束

對於需要對接下游系統的 API 呼叫或結構化資料，我們棄用了純文字生成，全面轉向 JSON Schema 強制校驗。透過 Pydantic 等庫在執行階段攔截不合規的輸出並觸發自動重試（Self-Correction），確保系統不會因為一個多餘的逗號而崩潰。

小結：AI 工程化的本質是回歸傳統軟體工程

AI Lab 的交付過程看似是在與隨機性搏鬥，但其核心依然是軟體工程的基本功：定義輸入輸出 $\rightarrow$ 建構測試用例 $\rightarrow$ 實現自動化回歸 $\rightarrow$ 持續迭代優化。

當你不再依賴於「這次運氣好通過了」，而是能夠自信地說出「這次修改讓 Golden Set 的通過率從 82% 提升到了 91%，且沒有引起任何回歸錯誤」時，你的 AI 專案才真正具備了交付能力。