AI 交付管線中的「靜默失敗」：沒報錯，但產出已經廢了

上週我們排查一個客戶反饋：AI 生成的週報連續三天「看起來沒問題」，但資料全是編造的。

沒有報錯。沒有超時。API 回傳 200。日誌一切正常。

這就是 AI 工程交付中最危險的一類故障——靜默失敗（Silent Failure）。

什麼是靜默失敗？

傳統軟體故障很好識別：500 錯誤、超時、空指標。但 LLM 不同。它永遠「成功」回傳一段文字，只是這段文字可能是幻覺、過時，或者完全偏離指令。

我們遇到的典型案例：

• 資料幻覺：讓模型總結上週工單資料，它編了 12 個「已解決」的工單編號。實際只有 3 個。
• 指令漂移：prompt 要求「只列出事實，不添加分析」，模型還是加了一段「建議下一步優化方向」。連續 47 次呼叫都這樣。
• 格式崩壞：要求輸出 JSON，偶爾回傳帶 Markdown 程式碼區塊的 JSON。解析器沒報錯，但下游系統把 ```json 當成了欄位值。

我們怎麼修的

1. 輸出校驗層（Output Guardrails）

在模型輸出和下游消費之間加一層校驗邏輯：

LLM → 格式校驗 → 資料範圍校驗 → 業務規則校驗 → 下游

比如工單編號校驗：生成的每個工單編號必須能在資料庫中找到對應記錄。找不到？直接標記為幻覺，觸發人工複核。

2. 確定性回歸測試

每週用同一組 prompt + 同一組輸入跑一次回歸，對比輸出差異。不是看「對不對」，而是看「變沒變」。如果上週輸出 5 筆資料，這週輸出 12 筆，即使 12 筆都是對的，也要查原因——可能是 prompt 被改了，也可能是模型版本升級了。

3. 抽樣人工審核

不是每篇都審，而是按風險等級抽樣。高風險內容（對外發布、涉及資料）100% 審核；中風險（內部週報）20% 抽樣；低風險（草稿、腦力激盪）不審。

關鍵教訓

「沒報錯」不等於「沒問題」。 在 AI 交付管線裡，成功回應是最不可信的訊號。你必須假設每次輸出都可能有问题，然後用校驗層去驗證。

這不是不信任模型，而是工程紀律。就像你不會因為資料庫回傳 200 就不做資料校驗一樣。

---

本文基於 SFD Lab 實際交付經驗，客戶資訊已脫敏。