MLOps: Giám sát Mô hình & Khả năng Quan sát (Model Monitoring & Observability)

#exam-tip

Mục lục

1. Tổng quan

Việc giám sát mô hình đảm bảo rằng các mô hình ML tiếp tục hoạt động tốt trên môi trường production bằng cách phát hiện tình trạng trôi dạt dữ liệu (data drift), sự xuống cấp của mô hình (model degradation), và sự thiên lệch (bias).

2. Luồng Giám sát Mô hình (Model Monitoring Flow) #important

2.1 Vòng lặp Giám sát và Huấn luyện lại Liên tục

graph TB
    subgraph "Production Endpoint"
        A[Incoming Requests] --> B[SageMaker Endpoint<br/>Mô hình v1.0]
        B --> C[Dự đoán]
        C --> D[Trả lời Client]
    end

    subgraph "Thu thập Dữ liệu (Data Capture)"
        B --> E[Bật Data Capture<br/>trên Endpoint]
        E --> F[Thu thập Đầu vào<br/>+ Dự đoán]
        F --> G[Lưu trên S3<br/>File JSONL có timestamp]
    end

    subgraph "Giám sát Tức thì - Không Cần Nhãn"
        G --> H[Data Quality Monitor<br/>Chạy theo Giờ/Ngày]
        H --> I[So sánh với Baseline<br/>Thống kê Dữ liệu Train]
        I --> J{Dính Data<br/>Drift?}
        J -->|Có| K[⚠️ Báo động CloudWatch<br/>Phân phối Đầu vào Thay đổi]
        K --> L[Thông báo SNS<br/>Báo cho Team]
    end

    subgraph "Giám sát Bị trễ - Cần Nhãn"
        G --> M[Đợi Ground Truth<br/>Vài Giờ/Ngày/Tuần]
        M --> N[Nhãn Ground Truth<br/>Kết quả Thực tế]
        N --> O[Model Quality Monitor<br/>Chạy theo Tuần]
        O --> P[Tính toán Metrics<br/>Độ chính xác, Precision, Recall]
        P --> Q{Giảm<br/>Hiệu suất?}
        Q -->|Có| R[⚠️ Báo động CloudWatch<br/>Mô hình Xuống cấp]
        R --> L
    end

    subgraph "Quyết định Huấn luyện lại"
        L --> S{Cần<br/>Retrain?}
        S -->|Có| T[Kích hoạt Retrain<br/>Lambda/Step Functions]
        S -->|Xem xét Thủ công| U[Team Data Science<br/>Điều tra]

        T --> V[SageMaker Pipeline<br/>Tự động Retrain]
        V --> W[Dữ liệu Train Mới<br/>Dữ liệu Production Gần đây]
        W --> X[Train Mô hình v2.0]
        X --> Y[Đánh giá Hiệu suất]
        Y --> Z{Ngon hơn<br/>v1.0?}
        Z -->|Có| AA[Đăng ký v2.0<br/>vào Model Registry]
        Z -->|Không| AB[Giữ v1.0<br/>Điều tra Vấn đề]

        AA --> AC[Luồng Phê duyệt]
        AC --> AD{Được Duyệt?}
        AD -->|Có| AE[Triển khai v2.0<br/>Canary 5%]
        AD -->|Không| AB

        AE --> AF{Theo dõi<br/>v2.0 An toàn?}
        AF -->|Có| AG[Nâng lên 100%]
        AF -->|Không| AH[Quay về v1.0]

        AG --> B
    end

    style J fill:#fff4e1
    style Q fill:#fff4e1
    style K fill:#ffcccc
    style R fill:#ffcccc
    style AG fill:#d4f4dd
    style AH fill:#ffcccc

2.2 Data Quality vs Model Quality Monitoring

graph LR
    subgraph "Chất lượng Dữ liệu (Data Quality) - Tức thì"
        A1[Đầu vào Production<br/>Chỉ có Đặc trưng] --> B1[So sánh với<br/>Baseline Train]
        B1 --> C1{Trôi dạt<br/>Thống kê?}
        C1 -->|Có| D1[⚠️ Báo động: Đầu vào Thay đổi<br/>Ví dụ: Phân phối Tuổi thay đổi]
        C1 -->|Không| E1[✅ Dữ liệu bình thường]

        F1[Không Cần Nhãn<br/>❌ Ground Truth]
        F1 -.-> A1
    end

    subgraph "Chất lượng Mô hình (Model Quality) - Bị trễ"
        A2[Dự đoán Production] --> B2[Đợi<br/>Ground Truth]
        B2 --> C2[Ground Truth<br/>Đến sau]
        C2 --> D2[Tính toán Metrics<br/>Độ chính xác, Precision, Recall]
        D2 --> E2{Giảm<br/>Hiệu suất?}
        E2 -->|Có| F2[⚠️ Báo động: Mô hình Xuống cấp<br/>Ví dụ: Accuracy 95% → 85%]
        E2 -->|Không| G2[✅ Mô hình hoạt động tốt]

        H2[Cần Nhãn<br/>✅ Ground Truth]
        H2 -.-> C2
    end

    style D1 fill:#ffcccc
    style F2 fill:#ffcccc
    style E1 fill:#d4f4dd
    style G2 fill:#d4f4dd

3. SageMaker Model Monitor #exam-tip

Mục đích: Phát hiện các vấn đề về chất lượng mô hình và chất lượng dữ liệu trên production.

3.1 Thu thập Dữ liệu (Data Capture) #exam-tip

Mục đích: Thu thập các request và response suy luận để phục vụ cho việc phân tích của Model Monitor.

Tổng quan:

  • Điều kiện tiên quyết cho Model Monitor - BẮT BUỘC phải bật data capture trên endpoint trước khi có thể giám sát.
  • Chụp lại các payload đầu vào (input) và các dự đoán của mô hình (output) theo thời gian thực.
  • Lưu dữ liệu thu được vào S3 để đem đi phân tích sau.
  • Bắt buộc đối với tất cả các thể loại Model Monitor (Data Quality, Model Quality, v.v…).

Cấu hình:

DataCaptureConfig = {
    'EnableCapture': True,
    'InitialSamplingPercentage': 100,  # Bắt 100% request (hoặc chỉnh thấp hơn nếu traffic quá khủng)
    'DestinationS3Uri': 's3://bucket/data-capture',
    'CaptureOptions': [
        {'CaptureMode': 'Input'},   # Chụp payload của request gửi đến endpoint
        {'CaptureMode': 'Output'}   # Chụp kết quả dự đoán của mô hình trả về
    ]
}

Các Tham số Chính:

  • InitialSamplingPercentage - % lượng request muốn bắt lại (từ 1-100).
    • Dùng 100% nếu endpoint ít traffic.
    • Dùng 20-50% nếu traffic cực lớn để tiết kiệm tiền lưu trữ S3.
  • CaptureMode - Chụp cái gì:
    • Input - Chụp payload của request.
    • Output - Chụp kết quả dự đoán trả về.
    • Bật cả hai - Luôn được khuyến khích để xài full chức năng giám sát.
  • DestinationS3Uri - Chỗ cất dữ liệu trên S3.

Định dạng Dữ liệu đã Chụp:

{
  "captureData": {
    "endpointInput": {
      "observedContentType": "text/csv",
      "mode": "INPUT",
      "data": "1.5,2.3,4.1,...",
      "encoding": "CSV"
    },
    "endpointOutput": {
      "observedContentType": "text/csv",
      "mode": "OUTPUT",
      "data": "0.92",
      "encoding": "CSV"
    }
  },
  "eventMetadata": {
    "eventId": "unique-id",
    "inferenceTime": "2025-01-15T10:30:00Z"
  }
}

Cấu trúc Lưu trữ trên S3:

s3://bucket/data-capture/
├── 2025/01/15/10/
│   ├── request-1.jsonl
│   ├── request-2.jsonl
│   └── ...
  • Phân chia theo thư mục năm/tháng/ngày/giờ.
  • Dạng JSONL (Mỗi dòng là một chuỗi JSON chuẩn chỉnh).

Kịch bản Bài thi: #exam-tip

  • “Bật tính năng giám sát trên endpoint” → Phải cấu hình DataCaptureConfig trước đã.
  • “Khối lượng request khủng, cần tối thiểu hóa tiền storage” → Chỉnh InitialSamplingPercentage thấp xuống (20-50%).
  • “Giám sát cả đầu vào lẫn dự đoán” → Phải bật cả 2 cái CaptureMode là Input và Output.
  • “Dữ liệu đâu để tạo baseline?” → Thằng Data Capture này chính là đứa lấy dữ liệu từ production.

Cạm bẫy Thường gặp (Gotchas): #gotcha

  • Không thể tự nhiên bật data capture cho một endpoint đang chạy - bạn PHẢI thực hiện update cấu hình endpoint (update endpoint configuration).
  • Dữ liệu rác này đem lưu vào S3 thì bạn vẫn phải trả tiền storage như bình thường.
  • Bật data capture gần như không làm chậm hệ thống (độ trễ cộng thêm thường <1ms).
  • Bắt buộc phải có cả Input và Output capture thì mới chạy được Model Quality monitoring.

3.2 Các Loại Giám sát (Monitoring Types)

1. Giám sát Chất lượng Dữ liệu (Data Quality Monitoring)

  • Phát hiện: Sự thay đổi trong phân phối dữ liệu đầu vào.
  • Cơ chế: So sánh đầu vào của production với một baseline chuẩn của dữ liệu train (sử dụng đối chiếu thống kê - statistical comparison).
  • KHÔNG CẦN NHÃN (NO LABELS REQUIRED) - Nó chỉ soi dữ liệu đầu vào, chả thèm quan tâm mô hình dự đoán ra cái gì hay kết quả thực tế ra sao.
  • Phát hiện tức thì (Immediate detection) - Bắt tại trận ngay khi có dữ liệu lệch chuẩn bay vào.
  • Metrics: Các thống kê của đặc trưng, giá trị bị thiếu (missing values), sai kiểu dữ liệu, sai phân phối.
  • Baseline: Lấy từ dữ liệu train để làm chuẩn.
  • Báo động (Alerts): Hú còi ngay khi dữ liệu production lệch so với baseline (thậm chí trước khi mô hình kịp đưa ra dự đoán).

2. Giám sát Chất lượng Mô hình (Model Quality Monitoring) #important

  • Phát hiện: Sự xuống cấp về chất lượng dự đoán của mô hình.
  • Yêu cầu: Phải có nhãn chuẩn (ground truth) (kết quả thực tế) - những cái này ĐẾN RẤT TRỄ.
  • Cơ chế thời gian: Mô hình đưa ra dự đoán hôm nay → Kết quả thực tế thì sau này (vài giờ/ngày/tuần) mới biết.
  • Ví dụ:
    • Phát hiện gian lận (Fraud detection): Mô hình báo “Có gian lận” hôm nay → Phải đi điều tra → 3 ngày sau mới biết chắc là có lừa đảo hay không.
    • Dự đoán rời bỏ (Churn): Dự đoán “Ông này sẽ bỏ đăng ký” vào tháng 3 → Phải đợi hết 30 ngày → Mới biết tháng 4 ông ấy có thực sự rời đi không.
  • Metrics: Accuracy, precision, recall, AUC (chỉ có thể tính được sau khi gom đủ ground truth).
  • Use case: Phát hiện model drift theo thời gian (đòi hỏi sự kiên nhẫn để đợi ground truth).
  • Điểm khác biệt chí mạng với Data Quality: Data Quality = Tức thì (không cần nhãn), Model Quality = Bị trễ (cần phải đợi nhãn).

3. Giám sát Độ lệch Thiên vị (Bias Drift Monitoring)

  • Phát hiện: Sự thay đổi của các bias metrics qua thời gian.
  • Tích hợp: Dùng chung với SageMaker Clarify.
  • Giám sát: Tác động chênh lệch (disparate impact), sự công bằng về nhân khẩu học (demographic parity).

4. Giám sát Sự thay đổi Quan trọng của Đặc trưng (Feature Attribution Drift)

  • Phát hiện: Sự thay đổi về tầm quan trọng của các đặc trưng (feature importance).
  • Sử dụng: Các giá trị SHAP (SHAP values).
  • Chỉ báo: Hành vi “nhìn nhận” vấn đề của mô hình đã bị thay đổi.

3.3 Bảng So sánh Các Loại Giám sát #exam-tip

Tiêu chí Data Quality Model Quality
Cần Nhãn không? ❌ Không ✅ Có (cần ground truth)
Tốc độ phát hiện ⚡ Tức thì ⏳ Bị trễ (phải đợi nhãn)
Giám sát cái gì Chỉ quan tâm dữ liệu đầu vào Quan tâm độ chính xác (accuracy)
Khi nào dùng Luôn luôn (chốt chặn đầu tiên) Khi nào nhặt được ground truth
Báo động mẫu “Phân phối Tuổi đã bị lệch” “Độ chính xác rớt từ 95% xuống 85%”
Chi phí Thấp hơn (không tốn tiền thu thập nhãn) Cao hơn (phải bỏ tiền/công sức đi gom nhãn)

Khung ra Quyết định (Decision Framework): #exam-tip

  • Nếu đề bài nói “không cần nhãn (without labels)” → Chọn Data Quality Monitoring.
  • Nếu đề bài hỏi về “sự xuống cấp của độ chính xác mô hình (model accuracy degradation)” → Chọn Model Quality Monitoring (thằng này cần nhãn).
  • Nếu cần “phát hiện tức thì (immediate detection)” → Chọn Data Quality Monitoring.
  • Best practice (Tốt nhất): Dùng CẢ HAI - Data Quality hú còi ngay lập tức, Model Quality sẽ làm nhiệm vụ chốt hạ kết luận.

Cách thức Vận hành:

  1. Tạo baseline lấy từ dữ liệu train.
  2. Đặt lịch chạy các monitoring jobs (ví dụ: mỗi giờ, mỗi ngày).
  3. Jobs sẽ tự động lấy production data ra đọ với baseline.
  4. Đẻ ra cái báo cáo vi phạm (violations report).
  5. Hú CloudWatch/SNS nếu thấy biểu hiện drift.

Kịch bản Bài thi (Exam Scenarios): #exam-tip

  • Production data bị lệch so với tập train → Data Quality Monitor
  • Độ chính xác mô hình đang tuột dốc → Model Quality Monitor (cần ground truth)
  • Kiểm tra tính công bằng của mô hình → Bias Drift Monitor (Clarify)

4. Khả năng Quan sát & Giám sát (Monitoring & Observability) #exam-tip

4.1 Tích hợp CloudWatch

  • Metrics (Chỉ số đo lường):
    • Số lượt gọi endpoint (Endpoint invocations).
    • Độ trễ của mô hình (ModelLatency).
    • Khả năng ăn tài nguyên máy (CPU, memory, GPU).
    • Tỷ lệ lỗi (Error rates 4xx, 5xx).
  • Alarms (Báo động): Tự động hú còi khi vượt ngưỡng quy định.
  • Dashboards: Vẽ biểu đồ để theo dõi sức khỏe của mô hình.

4.2 CloudWatch Logs

  • Chứa logs của quá trình training (Training job logs).
  • Chứa logs của những lần gọi endpoint (Endpoint invocation logs).
  • Chứa logs của quá trình xử lý dữ liệu (Processing job logs).
  • Thời gian lưu (Retention): Thích thì để 7 ngày, còn không thì lưu đến hết đời cũng được.

4.3 AWS X-Ray

  • Dùng để theo dõi dấu vết (Trace requests) đi xuyên suốt toàn bộ luồng pipeline suy luận.
  • Định vị nhanh các điểm nghẽn cổ chai (bottlenecks).
  • Cực kỳ hữu dụng để gỡ lỗi các vấn đề về hiệu suất.

5. Tối ưu hóa Chi phí (Cost Optimization) #exam-tip

5.1 Tối ưu Chi phí Huấn luyện (Training Cost)

  1. Managed Spot Training - Tiết kiệm đến 90%.
  2. Right-size instances (Chọn đúng size máy) - Đừng xài dao mổ trâu đi giết gà.
  3. Local mode - Chạy thử (test) trên notebook instance của mình cho trơn tru rồi hẵng vác lên máy xịn.
  4. Checkpoint thường xuyên - Để lỡ xài spot instance bị giật máy giữa chừng thì không khóc.
  5. Pipe input mode - Vừa stream dữ liệu vừa train thay vì tải cả đống về tốn thời gian.

5.2 Tối ưu Chi phí Suy luận (Inference Cost)

  1. Batch Transform - Dành cho các món không cần gấp (offline predictions).
  2. Serverless Inference - Dành cho cái bọn traffic lèo tèo, thỉnh thoảng mới ghé (intermittent traffic).
  3. Multi-model endpoints - Nhét một đống mô hình vào chung 1 endpoint cho tiết kiệm hạ tầng.
  4. Auto-scaling - Khuya ít người xài thì tự động bớt máy lại.
  5. Neo optimization - Tối ưu mô hình nhỏ gọn lại để xài instance cùi bắp hơn.
  6. Reserved capacity (Đặt trước dung lượng) - Cam kết mua sỉ để lấy giá hời cho các hệ thống dễ đoán.

5.3 Tối ưu Chi phí Lưu trữ (Storage Cost)

  1. S3 Intelligent-Tiering - Cho AWS tự đẩy dữ liệu ít xài xuống kho rẻ tiền.
  2. Lifecycle policies (Chính sách vòng đời) - Tự động xóa bớt mô hình rác từ năm nảo năm nào.
  3. Model compression (Nén mô hình) - Giảm bớt dung lượng artifact.

6. Tổng hợp Kịch bản Bài thi (Exam Scenarios Summary) #exam-tip

Kịch bản Giải pháp
Phát hiện drift trên production data Model Monitor (Data Quality)
Độ chính xác mô hình tuột dốc không phanh Model Monitor (Model Quality) + Retrain ngay và luôn
Chạy A/B test 2 mô hình khác nhau Endpoint chia Production Variants
Tự động hóa cái đống ML workflow này SageMaker Pipelines
Lập phiên bản và đi duyệt mô hình Model Registry
Triển khai tuần tự sang các môi trường dev/staging/prod SageMaker Projects + CodePipeline
Soi xem mô hình production có thiên vị ai không Model Monitor + Clarify (Bias Drift)