第五章 模型部署與監控

# 第五章 模型部署與監控 > 本章將帶你從「模型開發」走向「產品落地」，並學會如何確保模型在真實環境中持續表現。\n > 章節重點：容器化、CI/CD、漂移偵測、A/B 測試、回饋迴圈，並以案例說明如何把模型變成企業價值的「動態資產」。 --- ## 5.1 為什麼要部署？ - **價值實現**：模型若不部署，僅是紙上談兵。部署是把洞察轉為可執行行動的關鍵環節。 - **可重複性**：部署流程標準化，可在多個環境重複使用，減少人為差錯。 - **可監控性**：部署後可持續追蹤模型表現，及時偵測漂移與失效。 > **小結**：部署不是最後一步，而是「模型生命週期」中的關鍵節點，直接影響商業效益與用戶體驗。 ## 5.2 容器化：Docker + Kubernetes | 步驟 | 說明 | |---|---| | 1️⃣ **建置 Dockerfile** | 把模型、依賴、環境設定打包為容器鏡像。 | | 2️⃣ **多階段建置** | 第一階段安裝依賴與編譯，第二階段拷貝模型，減少鏡像體積。 | | 3️⃣ **容器註冊** | 推送至私有或公有 registry（如 Docker Hub、AWS ECR）。 | | 4️⃣ **K8s 部署** | 使用 Deployment + Service 定義，實現水平擴容。 | ### Dockerfile 範例 dockerfile # 1️⃣ 建構階段 FROM python:3.10-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 2️⃣ 產出階段 FROM python:3.10-slim WORKDIR /app COPY --from=builder /usr/local/lib/python3.10/site-packages ./lib COPY model.pkl . COPY api.py . ENV PYTHONPATH=/app/lib CMD ["uvicorn", "api:app", "--host", "0.0.0.0", "--port", "8080"] > **Tip**：將預測 API 使用 FastAPI + Uvicorn，可自動產生 OpenAPI 文檔，利於前端整合。 ## 5.3 CI/CD Pipeline（GitHub Actions + Argo CD） 1️⃣ **CI**：每次 push 觸發 - 代碼 lint (flake8, black) - 單元測試（pytest） - 數據驗證（Great Expectations） - 打包 Docker 映像 2️⃣ **CD**：推送到 Registry，Argo CD 監控變更，自動同步到 Kubernetes yaml # .github/workflows/ci.yml name: 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.10 - name: Install dependencies run: pip install -r requirements.txt - name: Run tests run: pytest tests/ - name: Build Docker image run: docker build -t myregistry/model:${{ github.sha }} . - name: Push Docker image run: | echo ${{ secrets.REGISTRY_PASSWORD }} | docker login myregistry --username ${{ secrets.REGISTRY_USER }} --password-stdin docker push myregistry/model:${{ github.sha }} > **關鍵**：CI 只檢查模型行為，CD 則確保環境一致，兩者合起來大幅降低「藍綠部署」風險。 ## 5.4 監控：Prometheus + Grafana + MLflow - **Prometheus**：收集容器指標（CPU、Memory、Request Latency）。 - **Grafana**：可視化 dashboard，設定告警。 - **MLflow Tracking**：記錄每一次推理請求的特徵、預測值與真實值，方便回溯。 ### 監控範例 yaml # prometheus.yml scrape_configs: - job_name: 'model_api' metrics_path: '/metrics' static_configs: - targets: ['model-service:8080'] > **Alert**：若 request latency 超過 200ms 連續 3 次，觸發 Slack 通知。 ## 5.5 漂移偵測（Concept Drift） ### 5.5.1 監測指標 | 指標 | 目的 | |---|---| | Population Stability Index (PSI) | 監測特徵分佈變化 | | Prediction Error Drift | 監測預測誤差上升 | | Kullback–Leibler Divergence | 監測多維分佈變化 | ### 5.5.2 實作範例 python import numpy as np from sklearn.metrics import mean_absolute_error # 舊資料 X_old = np.load('old_features.npy') # 新資料 X_new = np.load('new_features.npy') psi = compute_psi(X_old, X_new) if psi > 0.1: print('警告：特徵分佈漂移') > **策略**：漂移偵測到後，先做「小幅 retrain」或「模型回滾」；若漂移嚴重，則重新蒐集新標籤資料。 ## 5.6 A/B 測試：線上驗證 1️⃣ **設計**：將流量分為兩組，A 組使用舊模型，B 組使用新模型。 2️⃣ **指標**：業務 KPI（如 Conversion Rate）與技術 KPI（Latency）。 3️⃣ **統計檢定**：使用 Chi‑Square 或 t‑test，確保差異顯著。 ### A/B 測試流程圖 [Traffic] --> {A: 50% -> Model v1, B: 50% -> Model v2} --> {Metrics} --> {Statistical Test} > **結論**：A/B 測試不僅驗證模型效能，更能洞察模型對業務的真實影響，降低「模型失敗」風險。 ## 5.7 回饋迴圈：持續改進 | 步驟 | 內容 | |---|---| | 1️⃣ 收集實際輸出 | 與使用者互動時收集真實標籤。 | | 2️⃣ 資料清洗 | 轉換成訓練可用格式。 | | 3️⃣ 模型再訓練 | 以批次或增量方式更新。 | | 4️⃣ 重新部署 | 透過 CI/CD 自動部署新版。 | > **實務提示**：將回饋流程整合至 MLOps 平台，確保「一次部署」即涵蓋「一次學習」。 ## 5.8 商業價值落地：案例總結 ### 案例：線上零售客戶推薦 - **部署**：使用 Docker + Kubernetes，模型容器化，水平擴容滿足 1M 日訪問。 | - **監控**：Grafana dashboard 顯示即時 CTR 與 latency。 | - **漂移**：每週檢測 PSI，發現節慶期間特徵漂移，進行增量 retrain。 | - **A/B**：新模型提升 5% CTR，成本下降 12%。 | - **回饋**：每日收集用戶點擊行為，24h 內完成模型更新。 | > **總結**：透過完整的部署與監控流程，模型不再是一次性成果，而是能夠隨時自我優化、適應市場變化的「動態決策引擎」。 --- > **後記**：下一章將進一步探討「資料治理與倫理」，協助你在部署模型時兼顧合規與社會責任。