1. 17:20 13/10/2026
Khi mô hình machine learning đã được triển khai vào sản xuất, việc theo dõi liên tục các chỉ số hiệu suất là yếu tố then chốt để đảm bảo độ tin cậy và kịp thời phát hiện sự suy giảm. Dưới đây là quy trình thực tế mà nhiều đội ngũ áp dụng thành công.
1. Xác định tập chỉ số cốt lõi
- Độ chính xác (accuracy), F1‑score, AUC cho bài toán phân loại.
- MAE, RMSE, MAPE cho bài toán hồi quy.
- Latency trung bình, P95, P99 của inference.
- Tỷ lệ lỗi (error rate) và tỷ lệ request thất bại.
- Chỉ số drift: Population Stability Index (PSI) cho feature, KL‑divergence cho phân phối prediction.
2. Thu thập dữ liệu tự động
- Gắn middleware vào API serving (FastAPI, Flask, Triton) để ghi log request, response, latency, prediction vào Kafka hoặc Pub/Sub.
- Lưu trữ raw log trong data lake (Parquet trên S3/MinIO) để truy vấn lịch sử.
- Sử dụng side‑car container (Fluent Bit, Vector) để đẩy metric sang Prometheus.
3. Tính toán metric gần thời gian thực
- Viết job Flink / Spark Structured Streaming đọc từ Kafka, tính rolling window 5‑15 phút cho các chỉ số trên.
- Cập nhật PSI hàng ngày bằng cách so sánh phân phối feature của cửa sổ hiện tại với baseline training.
4. Trực quan hóa và cảnh báo
- Dashboard Grafana hiển thị: latency, error rate, F1, PSI theo thời gian.
- Cấu hình alert: nếu latency P99 > 200ms hoặc PSI > 0.25 thì gửi Slack/PagerDuty.
- Tích hợp runbook: alert kèm link tới notebook phân tích nguyên nhân (feature drift, data quality, model version).
5. Quy trình phản hồi và re‑training
- Khi alert drift kích hoạt, tự động tạo issue Jira/GitLab gán cho data scientist.
- Pipeline CI/CD (GitHub Actions + DVC + MLflow) pull dữ liệu mới, chạy re‑training, so sánh metric với baseline, nếu tốt hơn thì promote version mới qua canary deployment.
6. Ví dụ minh họa
Giả sử dịch vụ gợi ý sản phẩm phục vụ 10k request/phút. Dashboard cho thấy F1 giảm từ 0.87 xuống 0.81 trong 2 giờ, PSI feature "price" nhảy từ 0.08 lên 0.31. Alert gửi ngay cho team. Data scientist kiểm tra log thấy nhà cung cấp thay đổi quy tắc định giá, dẫn đến phân phối price lệch. Họ cập nhật feature engineering, re‑train model, push version v2.3. Sau canary 10% traffic, F1 hồi phục 0.86 và latency không tăng. Toàn bộ quy trình mất khoảng 4 tiếng từ phát hiện đến khôi phục.
Lời khuyên áp dụng ngay:
- Bắt đầu với tập metric nhỏ nhất (latency, error rate, PSI) rồi mở rộng.
- Tách biệt pipeline monitoring khỏi training pipeline để tránh coupling.
- Luôn version hóa baseline data và metric để so sánh chính xác.
- Tự động hóa runbook: alert kèm link notebook, script rollback, checklist xác minh.
- Định kỳ review dashboard hàng tuần để điều ngưỡng alert phù hợp với business.
Việc xây dựng hệ thống giám sát như trên không chỉ giúp phát hiện sự cố sớm mà còn tạo vòng lặp phản hồi liên tục, biến mô hình ML từ "deploy và quên" thành tài sản có thể cải tiến liên tục.