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

在 AI Lab 的實際交付過程中，很多團隊在面對模型輸出不確定性時，最容易採取的策略是建立一個巨大的「端到端 (E2E) 測試集」。

他們會準備 500 個典型的使用者輸入 $\rightarrow$ 預期輸出對，每次更新 Prompt 後跑一遍全量回歸，如果通過率從 85% 提升到 87%，就認為模型「進化」了。但在生產環境下，這種依賴 E2E 指標的品質管理方式極其危險。

「端到端測試」的工程陷阱

AI 的輸出具有天然的隨機性和多樣性。當你依賴 E2E 測試時，你會遇到以下三個死穴：

1. **語意漂移與「偽通過」 (Semantic Drift)**：模型可能給出了一個與預期答案語意完全不同但格式正確、語氣禮貌的回答。如果你的驗證邏輯是簡單的字串比對或弱語意相似度，你會得到大量「偽通過」，而使用者在實際使用時卻覺得回答毫無用處。

2. **覆蓋率黑洞 (Coverage Black Hole)**：AI 的輸入空間是無限的。無論你準備多少個測試案例，都無法覆蓋長尾場景中的邊界情況（Edge Cases）。一旦進入生產環境，使用者總能找到一種奇怪的組合讓你的模型產生嚴重的幻覺或邏輯崩潰。

3. **除錯成本指數級增長**：當一個 E2E 測試失敗時，你面對的是一個巨大的黑盒。錯誤發生在意圖識別階段？檢索階段？還是最後的生成階段？你無法快速定位故障點，只能透過不斷微調 Prompt 來嘗試修復，這本質上是在進行「隨機搜尋」。

為了保證交付的穩定性，我們採取的核心策略是將品質控制**下沉到中間層**，並引入**邊界取樣驗證**。

不要只看最終結果，要在鏈路的每一個原子步驟之間建立顯式的斷言：

- **意圖斷言**：如果輸入包含「退款」，那麼 Step 1 的輸出必須包含 `intent: refund`。如果不滿足 $\rightarrow$ 直接標記為該節點的失敗。

- **檢索斷言**：檢查 Step 2 回傳的文件片段是否包含關鍵實體詞。如果檢索結果為空 $\rightarrow$ 觸發回溯機制而非強行生成。

- **結構斷言**：強制要求模型輸出 JSON $\rightarrow$ 使用 Pydantic 等工具進行 Schema 校驗 $\rightarrow$ 不合規則立即重試或報錯。

不再追求全量覆蓋，而是針對潛在風險點進行定向取樣：

- **對抗性樣本**：專門構造包含矛盾指令、極端長度、非法字元的輸入 $\rightarrow$ 測試系統的魯棒性（Robustness）。

- **負樣本驗證**：提供不應觸發任何功能的輸入 $\rightarrow$ 驗證系統是否能正確地拒絕回答而非強行幻覺。

將 E2E 的失敗分解為具體的節點失敗率：

- `Total Failure Rate = P(Intent_Fail) + P(Retrieval_Fail | Intent_Ok) + P(Gen_Fail | Retrieval_Ok)`

這樣你可以清晰地看到瓶頸是在哪裡——是知識庫不夠全（檢索失敗），還是 Prompt 指令不夠明確（生成失敗）。

| 指標 | 端到端測試 (E2E Only) | 中間層斷言 (Layered Assertions) |

| :--- | :--- | :--- |

| **定位速度** | 低 (需人工分析全鏈路日誌) | 高 (直接定位到具體失效節點) |

| **魯棒性** | 低 (依賴已知用例) | 高 (透過邊界取樣覆蓋未知風險) |

| **迭代信心** | 低 (指標波動大且無方向感) | 高 (每個環節都有量化指標支撐) |

| **維護成本** | 高 (用例集隨業務膨脹而臃腫) | 中 (基於邏輯節點的 Schema 定義) |

AI 工程化的核心在於**將不確定性的機率問題轉化為確定性的邏輯問題**。

如果你發現自己每天在花大量時間維護一個數千行的 Excel 測試集並手動打分時，請立刻停下來。這說明你的品質體系處於「結果驅動」而非「過程驅動」。你應該做的是拆分鏈路、定義介面、並在每個介面上建立嚴苛的斷言機制。

記住：一個能夠告訴你「因為檢索節點缺失關鍵實體而導致最終回答錯誤」的系統，遠比一個告訴你「這個 Case 不通過」的系統要有價值得多。