第九章 模型部署與監控

# 第九章 模型部署與監控 在前幾章已經掌握了資料探索、特徵工程與模型建構的核心流程，接下來的重點便是將模型從實驗環境轉移到生產環境，並確保其長期可靠性、可追溯性與合規性。本章將透過實務案例、開源工具與標準框架，細述如何構建可重複、可維護的 MLOps 流程。 ## 9.1 需求與策略 | 目標 | 重點 | 工具/技術 | |------|------|----------| | 版本管理 | 模型、資料與程式碼同步更新 | Git、DVC | | 可追蹤性 | 追蹤實驗結果與模型版本 | MLflow、Weights & Biases | | 合規性 | 確保隱私、倫理與安全 | GDPR、ISO/IEC 27701、OpenMined PySyft | | 持續交付 | 快速、安全地推送到生產 | GitHub Actions、ArgoCD | | 監控 | 過程、性能與偏移監測 | Prometheus、Grafana、Seldon Core | **策略要點** 1. **分離環境**：開發、測試、預備與正式環境獨立。 2. **自動化**：將資料抓取、預處理、訓練與部署腳本全部納入 CI/CD。 3. **基於容器**：使用 Docker/K8s 以確保執行環境一致。 4. **安全審計**：將合規檢查嵌入到流水線中，例如使用 `deid` 或 `k-anonymity` 來處理敏感資料。 5. **可擴展性**：透過水平擴充 (ReplicaSet) 或無伺服器 (Lambda) 處理不同負載。 ## 9.2 部署管道 ### 9.2.1 CI Pipeline yaml name: MLOps CI on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.11' - name: Install dependencies run: pip install -r requirements.txt - name: Data Versioning uses: iterative/dvc-action@v1 with: command: dvc pull - name: Run tests run: pytest tests/ - name: Train model run: python train.py - name: Publish model artifact uses: iterative/cli-action@v1 with: command: mlflow models build-docker -m ./mlruns/0/1/artifacts/model - **重點說明**：每一次 `push` 都觸發完整的訓練、測試與模型打包流程。 - **優勢**：確保程式碼與資料同步，降低版本衝突。 ### 9.2.2 CD Pipeline yaml name: MLOps CD on: workflow_dispatch: jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Deploy to K8s uses: azure/k8s-deploy@v1 with: manifests: "k8s/*.yaml" images: "myrepo/model:latest" namespace: ml-prod - **部署方式**：可使用 **Helm** 或 **ArgoCD** 進行宣告式部署，確保環境一致性。 - **藍綠部署**：在正式切換前，先在 **staging** 階段做 A/B 測試，降低風險。 ## 9.3 模型註冊與服務化 | 步驟 | 目的 | 工具 | |------|------|------| | 1. 版本化 | 追蹤模型的 metadata 與參數 | MLflow Registry | | 2. 服務化 | 提供 API 或 batch 服務 | FastAPI + Uvicorn, Seldon Core | | 3. 監控 | 收集使用者請求與性能 | Prometheus, Loki | ### 9.3.1 MLflow Registry 範例 python import mlflow mlflow.set_tracking_uri("http://mlflow-server:5000") # 登錄模型 model_uri = "runs:/<run_id>/model" mlflow.register_model(model_uri, "CreditRiskModel") # 取得最新穩定版 model_version = mlflow.get_latest_versions("CreditRiskModel", stages=["Production"]).iloc[0] print(model_version.version) - **Benefits**：提供可回溯的模型歷史，方便 A/B 測試與快速回滾。 ## 9.4 監控與警報 ### 9.4.1 監測指標 - **輸入資料分佈**：使用 **TensorBoard** 或 **KDE plots** 追蹤特徵漂移。 - **預測結果分佈**：隨時間累積，觀察模型輸出是否偏離預期。 - **延遲與吞吐量**：API 的 RTT 與每秒請求數。 - **資源使用**：CPU/GPU/記憶體占用。 ### 9.4.2 Drift Detection - **Population Stability Index (PSI)**：評估輸入特徵分佈漂移。 - **KS Test**：統計檢驗預測分佈是否顯著不同。 - **Alerting**：若 PSI 超過 0.1 或 KS p-value < 0.01，即觸發警報。 yaml # Prometheus rule example groups: - name: drift rules: - alert: FeatureDrift expr: psi_value{model="credit_risk"} > 0.1 for: 5m labels: severity: warning annotations: summary: "Feature drift detected" description: "PSI > 0.1 for feature {{ $labels.feature }}" ## 9.5 合規與倫理 | 要件 | 實作方式 | 工具 | |------|----------|------| | 隱私保護 | 匿名化、差分隱私 | PySyft、diffprivlib | | 公平性 | 監控受眾分布 | Aequitas, AI Fairness 360 | | 可解釋性 | 事後解釋 | SHAP, LIME | | 合規審核 | 版本紀錄、審計日誌 | MLflow, Git, DVC | **流程示例** 1. **資料處理**：在 DVC pipeline 內加入 `deid` 步驟。 2. **模型訓練**：使用差分隱私優化器。 3. **部署**：將公平性指標納入模型服務的 `metrics` 接口。 4. **監控**：每日生成 Model Card，更新於內部合規審核平台。 ## 9.6 事例研究 ### 9.6.1 金融風險模型 - **目標**：實時預測信用卡欺詐。 - **部署**：使用 **Kubernetes** + **Seldon Core**，每 5 分鐘重新訓練一次。 - **監控**：PSI 與 KS 檢測 5 分鐘一次，任何 drift 立即觸發回滾。 - **合規**：所有交易資料均經 `k-anonymity` 處理，並透過 MLflow 產生 Model Card，供內部審計。 ### 9.6.2 醫療診斷模型 - **目標**：肺部 CT 影像的肺癌檢測。 - **部署**：使用 **TorchServe** 於 GPU 節點，並透過 **FastAPI** 提供 REST 接口。 - **監控**：透過 `Prometheus` 收集 GPU 利用率、推論延遲；使用 `SHAP` 在 Web Dashboard 上顯示每張圖像的重要特徵。 - **倫理**：加入公平性審查，確保不同族群的誤診率相近；所有模型版本均以 **FHIR** 標準進行注記。 ## 9.7 小結 - **MLOps 的核心**：自動化、可追蹤性與可回復性。 - **部署策略**：容器化、宣告式部署、藍綠策略。 - **監控重點**：漂移、性能與安全。 - **合規嵌入**：從資料治理到模型註解，每一步都應有明確的審計痕跡。 - **未來展望**：隨著 AI 監管日趨嚴格，MLOps 將不僅是技術流程，更是法律與倫理的交叉點。 透過本章的實務框架，讀者可以在實際專案中落地部署與監控，確保模型在生產環境中持續合規、可靠並具備高可維護性。