別讓「模型能力」掩蓋了「工程缺陷」：AI 交付中的穩健性陷阱

在 AI Lab 的實際交付過程中，最危險的時刻往往不是模型表現不佳的時候，而是模型表現「看起來很完美」的時候。

很多團隊在 Demo 階段會陷入一個典型的認知誤區：只要透過精心挑選的幾個 Test Case 證明模型能跑通，就認為交付已經完成了 80%。但事實上，在 AI 工程化領域，從 Demo 到 Production 的距離，不是 20% 的程式碼量，而是 100% 的穩健性重構。

「Demo 成功」的幻象

我曾接手過一個企業級知識庫專案。在驗收演示時，模型對所有預設問題的回答都精準得令人驚嘆。但上線第一週，系統就因為大量「非預期輸入」而崩潰——使用者輸入的不是標準問題，而是包含大量口語碎屑、錯別字，甚至是完全無關的情緒化表達。

這就是典型的「穩健性陷阱」。當開發者在受控環境下測試時，潛意識裡會給模型提供「高品質」的輸入。而真實世界的使用者輸入是混沌的。如果你的交付邏輯依賴於模型在特定 Prompt 下的某種「靈光一現」，那麼這種成功就是脆弱的。

從「煉金術」轉向「工程化」

要打破這個陷阱，AI Lab 需要將關注點從單純的 Prompt Tuning（煉金術）轉向工程化的防禦體系：

1. 輸入端的「強力過濾」與標準化

不要試圖用一個巨大的 Prompt 讓模型處理所有異常。在進入 LLM 之前，必須建立一套前置處理流水線：
- 意圖識別（Intent Classification）：先判斷使用者是在提問、在抱怨還是在嘗試攻擊（Prompt Injection）。
- 輸入清洗：利用輕量級模型或正規表示式對雜訊進行剔除。
- 格式強制化：透過 Few-shot 或結構化指令，將模糊輸入轉化為模型易於理解的標準格式。

2. 輸出端的「確定性校驗」

永遠不要信任 LLM 直接輸出的結果。對於關鍵業務邏輯，必須引入校驗層：
- Schema 驗證：如果要求輸出 JSON，必須使用 Pydantic 或類似工具進行強型別校驗，失敗則觸發自動重試或降級方案。
- 幻覺檢測：針對 RAG 場景，引入 NLI（自然語言推論）檢查答案是否真的由檢索到的文件支撐，而非模型自創。
- 邊界攔截：建立敏感詞和合規性攔截庫，確保輸出不越界。

3. 建構「負樣本」測試集

大多數團隊只關注 Positive Cases（正確案例），但決定交付質量的是 Negative Cases（失敗案例）。
我們需要刻意建構一個測試集：
- 對抗性輸入：故意誘導模型產生幻覺或跳出角色設定。
- 極端邊界值：超長文本、空輸入、亂碼輸入。
- 歧義表達：同一個詞在不同語境下的多種含義。

寫在最後

AI 的能力上限決定了產品的潛力，但工程的下限決定了產品的生死。一個能夠穩定處理 95% 普通請求且對 5% 異常請求有優雅降級方案的系統，遠比一個能處理 100% 精選案例但偶爾會徹底崩潰的系統更有價值。

真正的 AI 工程化交付，就是承認模型的不可預測性，並用確定性的工程手段將其包裹起來。