別在 AI 交付中迷信「端到端測試」：為什麼「中間層斷言 + 邊界取樣」才是品質底線

在 AI Lab 的實際交付過程中，我觀察到一個非常普遍的誤區：很多工程師習慣於將 LLM 應用視為一個「黑盒」，然後試圖透過建構龐大的端到端（E2E）測試集來驗證品質。他們會寫幾百個 Case，輸入 Prompt，然後用另一個 LLM 來判斷輸出是否「看起來正確」。

這種做法在 Demo 階段能快速跑通，但在生產環境下是極其危險的。因為 LLM 的隨機性（Stochastic nature）決定了 E2E 測試的通過率並不代表系統的穩定性，而僅僅是某種「機率上的巧合」。

核心痛點：E2E 的「掩蓋效應」

端到端測試最大的問題在於它掩蓋了中間環節的失效。

假設你的 pipeline 是：`使用者輸入` $\rightarrow$ `意圖識別` $\rightarrow$ `知識庫檢索` $\rightarrow$ `答案生成` $\rightarrow$ `最終輸出`。

如果 E2E 測試結果是「正確」的，可能發生了兩種截然不同的情況：

1. **鏈路全對**：每個步驟都精準執行。

2. **錯誤抵銷**：意圖識別錯了，但檢索恰好搜到了一個能勉強回答該問題的片段，生成模型又透過強大的泛化能力把答案給「圓」回來了。

在這種情況下，你的系統其實處於一個極不穩定的狀態。一旦使用者輸入稍微偏移，或者知識庫更新了一次，整個鏈路會瞬間崩塌。

解決方案：中間層斷言 (Intermediate Assertions)

真正的 AI 工程化交付，必須將「黑盒」拆解為一系列可驗證的「白盒」狀態遷移。我們需要在每個關鍵節點引入**強型別斷言**或**結構化校驗**。

1. 意圖識別層的「硬約束」

不要只檢查 LLM 是否回傳了正確的意圖標籤，而要檢查該標籤是否在預定義的列舉值中，並且其攜帶的參數是否符合 Schema 定義（例如使用 Pydantic 進行校驗）。如果意圖識別失敗，直接觸發 Fallback 機制，而不是讓它帶著錯誤的意圖進入下一步。

2. 檢索層的「相關度閾值」

在 RAG 鏈路中，不要直接把 Top-K 文件餵給模型。必須引入一個相關度分數（Score）的硬閾值斷言。如果最高分低於 $0.7$，則判定為「未找到相關資訊」，直接告知使用者或引導至人工客服。這比讓模型在沒有參考資料的情況下強行「幻覺」出一個答案要專業得多。

3. 生成層的「事實錨點」校驗

利用 LLM 的 Self-Correction 能力進行反向驗證：要求模型在生成答案後，列出答案中每一個事實陳述所對應的原文檔片段 ID。如果某個結論無法追溯到原文檔，則該部分內容被標記為不可信並剔除。

從「全量覆蓋」轉向「邊界取樣」 (Boundary Sampling)

面對海量的潛在輸入空間，試圖覆蓋所有 Case 是不可能的。我們應該將精力從追求 $100\%$ 的 Case 通過率，轉向對**邊界條件**的極端取樣。

- **負樣本壓力測試**：專門構造那些極其接近正確意圖但實際上是錯誤請求的樣本（Adversarial Examples），驗證系統的拒絕能力。

- **長尾分佈取樣**：針對低頻但高風險的業務場景進行深度挖掘，確保這些場景下的中間層斷言依然生效。

- **漂移監控**：在生產環境中即時監控中間層斷言的觸發頻率。如果某個節點的斷言失敗率突然升高，即使 E2E 指標依然好看，也意味著系統出現了潛在的模型漂移或資料污染。

總結

AI 交付不是關於如何寫出完美的 Prompt，而是關於如何建構一套能夠快速定位失效點的**觀測體系**。

當你不再依賴於一個簡單的 `is_correct=True` 的 E2E 判斷，而是能夠清晰地看到 `Intent_Valid -> Retrieval_Score > 0.7 -> Fact_Anchored = True` 這條確定性的鏈路時，你的 AI 應用才真正具備了工業級的魯棒性。