AI 應用有一個獨特的品質挑戰：你無法靠讀 code 確認它是否正確運作。
傳統函式 add(2, 3) 永遠回傳 5，單元測試可以保證。LLM 的輸出是機率分佈——同樣的 prompt 可能給不同的回應，品質是統計概念而非二元對錯。這意味著傳統的 QA 思維需要補充新的工具。
Eval Dataset：你的「測試套件」
好的 AI 應用有 eval dataset：一組輸入-期望輸出的對，用來量化模型在你的 use case 的表現。
- 有代表性的 golden dataset（50-200 個真實案例）
- 每次改 prompt 或換模型前後都跑 eval，比較分數
- Eval 有明確的評分標準——人工標注或 LLM-as-judge
- Regression eval：確保改進一個地方沒有讓其他地方退步
不健康的訊號：改了 prompt 就直接上線，「感覺比較好」是唯一依據；換了更便宜的模型但不知道品質有沒有影響。
Observability：知道它在生產環境做什麼
AI 應用的 observability 跟一般後端不一樣：latency 是秒級而不是毫秒級、輸出需要被記錄和分析、cost 需要被追蹤。
- Prompt 和 response 都有 log（考慮 PII，可能需要遮蔽）
- Latency 按 token 數分解：是 TTFT（Time to First Token）慢，還是 throughput 慢
- Token 用量 per request：發現異常（某些 case 用了 10x token）
- Error rate：rate limit、timeout、content policy 拒絕的比例
- User feedback 收集：thumbs up/down 或 explicit 評分
工具：LangSmith（LangChain 生態）、Phoenix（Arize）、Langfuse（開源）、或自建的 logging pipeline。
Fallback 和 Degraded Mode
LLM API 會 rate limit、timeout、偶爾壞掉——你的應用能不能撐住？
- API timeout 設定：不要等超過 30 秒，超時要有 fallback 行為
- Retry with backoff：rate limit 時不是立刻失敗，而是重試
- Graceful degradation：模型不可用時，應用能以降級模式運作（例如顯示靜態回應或引導到人工）
- 多模型 fallback：主要模型掛了，能切換到備用模型（不同廠商更好）
Cost Control
LLM API 按 token 計費，沒有管控就會有意外帳單。
- 每個 use case 估算 cost per request：知道邊界條件
- Token budget：對長對話設上限，防止無限延伸
- Caching：完全相同的輸入可以 cache 輸出（semantic cache 更進一步）
- Cost alert：每日費用超過閾值就告警
- 模型選型：不是所有任務都需要最貴的模型——分類任務用小模型、生成任務用大模型
Security
AI 應用的安全面除了傳統的 web security，還有 LLM 特有的：
- Prompt injection 防禦：用戶輸入不能直接拼進 system prompt 沒有任何隔離
- 輸出驗證：如果輸出要被用於後續邏輯（例如 JSON 解析），有格式驗證
- PII 過濾：response 不包含不應該回傳的個人資料
- Rate limiting：每個用戶的 API 呼叫有限制，防止濫用和意外高費用
- Jailbreak 監測：記錄並 review 異常的 prompt pattern
好的 AI 應用 Checklist 小結
| 面向 | 最低要求 | 完整狀態 |
|---|---|---|
| 品質 | 有 eval dataset | 自動化 eval + regression |
| 觀測 | 有 prompt/response log | LLM tracing + user feedback |
| 韌性 | API timeout + retry | 多模型 fallback |
| 成本 | 知道每 request 多少錢 | 自動 alert + caching |
| 安全 | 基本 prompt injection 防禦 | 完整輸入輸出驗證 |
AI 應用的工程品質標準還在快速演進。這份 checklist 是 2024-2025 年的最佳實踐快照，跟 engineering 章節配合看有更深入的實作細節。