第五章：模型落地——部署、監控與迭代

# 第五章：模型落地——部署、監控與迭代 在前四章，我們已經從資料蒐集、清理、探索，到模型選擇、訓練、評估與商業化落地，搭建了一條完整的數據科學流程。此章將把理論推向實際系統，著重於 **模型部署**、**監控** 與 **迭代**，確保模型在實戰中不斷維持準確與合規。 ## 5.1 部署環境與架構 - **容器化**：將模型與其依賴封裝成 Docker 映像，確保跨環境可重複執行。 - **雲端 Orchestration**：利用 Kubernetes 或 Knative 進行自動擴縮、滾動升級。Kubernetes 的 *Deployment*、*Service*、*Ingress* 方便將推論服務公開於內部網路或 API Gateway。 - **推論平台**：選擇符合需求的推論框架—— - **TensorFlow Serving**：針對 TensorFlow 模型的高效推論。 - **Seldon Core**：支援多模型、不同框架，並提供內建 A/B 測試與流量分配。 - **ONNX Runtime**：多框架通用，適合多種模型。 - **模型管理**：使用 MLflow 或 DVC 追蹤模型版本、參數、輸出指標。版本號（如 `v1.2.0`）配合 git 標籤，確保可回溯。 > **實務提醒**：雖然容器化降低部署風險，但若忽略網路安全與 IAM 權限管理，可能導致 API 被公開暴露，造成資料洩露。務必為容器設定最小權限，使用 ServiceAccount 與 RBAC 控制存取。 ## 5.2 版本管理與 CI/CD | 步驟 | 工具 | 重點 | |------|------|------| | 1. 版本控制 | Git | 以 `git flow` 管理模型分支，確保 `feature/model` → `main` 時已經經過測試 | | 2. 建置 | GitHub Actions / GitLab CI | 在每次 push 時執行 unit test、模型驗證（如 `mlflow run`） | | 3. 測試 | PyTest / MLflow | 包含單元測試、資料完整性測試、推論一致性測試 | | 4. 部署 | Argo CD / Helm | 將 Docker 映像推送至 Registry，並在 Kubernetes 中自動部署 | | 5. 監控 | Prometheus + Grafana | 監控 CPU、記憶體、延遲、錯誤率 | > **注意**：CI 流程不應只檢查程式碼，而應完整驗證模型的 **回歸測試**。如果模型在新版本上降低 2% 的 AUC，必須立刻回滾。 ## 5.3 監控指標與告警 | 指標 | 來源 | 目的 | |------|------|------| | 推論延遲 | 服務端 log | 確保 SLA 內 | | 成功率 | 失敗率 | 防止錯誤聚集 | | CPU / Memory | Kubernetes metrics | 防止資源耗盡 | | 例外類型 | Application logs | 追蹤特定錯誤 | | 監測漂移 | `sklearn.metrics.mean_absolute_error` 監測輸入分佈 | - **告警**：設置閾值並整合 Slack / Email。若平均延遲 > 200ms 或錯誤率 > 1%，立即觸發告警並自動回滾至上一版。 - **Dashboards**：Grafana 提供即時視覺化，並結合 **SHAP** 解析器，展示特徵貢獻變化，協助分析師辨識漂移來源。 > **實務提醒**：若告警設置過寬鬆，可能導致問題被忽視；若過緊，會頻繁回滾，影響業務。建議先從 **基礎指標** (延遲、成功率) 入手，逐步加入 **偏差指標** (AUC 漂移)。 ## 5.4 實時與批處理推理 ### 實時推論 - **場景**：線上廣告系統、金融風控。需求是毫秒級延遲。 - **實現**：使用 **FastAPI** 或 **Flask** 包裝推論模型，並部署於 Kubernetes Service。利用 **Redis** 或 **Kafka** 作為訊息佇列，減少高併發下的瓶頸。 ### 批處理推論 - **場景**：每日營收預測、定期報表。延遲容忍度高。 - **實現**：利用 Airflow 或 Prefect 建立 DAG，調度 Spark 或 Flink 批處理，將結果寫入資料倉儲。可使用 **MLflow Models** 在批處理腳本中載入模型。 > **注意**：若將實時與批處理共用同一模型版本，請確保兩者使用的 **feature store** 版本一致，避免 feature 失配。 ## 5.5 監測漂移與自動化更新 ### 數據漂移 - **特徵分佈漂移**：利用 `scipy.stats.ks_2samp` 或 `sklearn.compose.ColumnTransformer` 對每個特徵做 Kolmogorov–Smirnov 測試。 - **概念漂移**：監控模型預測分佈與真實標籤分佈。若 P(pred) 與 P(true) 差距 > 5% 即可觸發警報。 ### 模型漂移 - **策略**：在監測到漂移後，觸發自動重訓（如每週）或手動重訓流程。使用 **MLflow Projects** 重新跑訓練 pipeline，並更新 `model registry`。若更新後指標提升 1% 以上，將新版本上線；否則保留舊版。 > **實務提醒**：漂移檢測若過於頻繁，可能導致「過擬合」於歷史資料。建議設置 *冷卻時間*（如 1 週）與 *多重指標*，並結合 **Human-in-the-loop** 進行最終決策。 ## 5.6 案例分析：線上電商推論服務 1. **需求**：預測客戶購買意向，支援即時廣告投放。 2. **模型**：Gradient Boosting Machine，使用 `xgboost`。特徵來自 **Feature Store**，包括瀏覽行為、購買歷史、客戶基礎資料。 3. **部署**： - 將模型封裝成 Docker，推送至 ECR。 - 使用 **Seldon Core** 在 EKS 上部署，配置 A/B 測試。 - 設定 **Prometheus** 監控，告警閾值為 250ms 延遲、5% 失敗率。 4. **監控**： - 每 5 分鐘拉取一次推論結果，計算預測正確率。 - 若正確率下降 3% 以上，觸發回滾。 5. **迭代**： - 由於季節性促銷，特徵分佈漂移頻繁。透過 **MLflow** 重新訓練，週期為 2 天。 - 成功率提升 0.5% 的新版本即時上線。 > **學到的教訓**： > 1. **自動化流程** 能大幅降低人工回應時間。 > 2. **告警設置** 需要與業務目標對齊，避免過度敏感。 > 3. **解釋性工具** (SHAP) 讓商業決策者能理解模型決策，提升信任度。 ## 5.7 小結 | 主題 | 關鍵要點 | |------|----------| | 部署 | 容器化 + Kubernetes + 推論平台 | | CI/CD | 版本控制、測試、回滾機制 | | 監控 | 延遲、成功率、資源、漂移指標 | | 推論 | 實時 + 批處理，Feature Store 一致性 | | 漂移 | 數據漂移 + 模型漂移檢測，回滾 / 重新訓練 | | 案例 | 具體實踐與學習點 | > **結語**：模型的生命週期不止於「訓練完畢」。部署、監控與迭代是確保模型持續為業務創造價值的關鍵環節。只有在實際系統中把握這些節點，才能真正做到「從資料洞察到決策智慧」的完整迴圈。