Bài 2 — Giám sát Drift: bắt bệnh mô hình sớm

Bài 2 — Giám sát Drift: bắt bệnh mô hình trước khi người dùng bắt được bạn

"Drift" là thủ phạm âm thầm số một khiến mô hình AI xuống cấp. Bài này giúp bạn — với vai trò PM — hiểu drift đủ sâu để định nghĩa monitoring đúng và tránh cả hai cực: mù thông tin hoặc chết chìm trong cảnh báo giả.

Ba loại drift bạn phải phân biệt

• Data drift (input/covariate drift): phân phối đầu vào thay đổi. Ví dụ: app mở rộng sang thị trường mới, độ tuổi người dùng trẻ hơn hẳn. Mô hình chưa "sai" nhưng đang gặp dữ liệu lạ.
• Concept drift: mối quan hệ đầu vào → đầu ra thay đổi. Ví dụ: trước COVID "ho + sốt" ít nghi ngại, sau COVID ý nghĩa khác hẳn. Đây là loại nguy hiểm nhất vì mô hình cũ sai bản chất.
• Prediction/label drift: phân phối đầu ra dự đoán hoặc nhãn thực tế thay đổi (ví dụ tỷ lệ "gian lận" dự đoán tăng gấp đôi).

Là PM, bạn cần hỏi mỗi khi thiết kế monitoring: "Nếu loại drift này xảy ra, ai bị ảnh hưởng và ta phát hiện bằng cách nào?"

Đo drift thế nào (đủ để đối thoại với data team)

Bạn không cần code, nhưng cần biết ngôn ngữ:

• PSI (Population Stability Index): so phân phối hiện tại vs baseline. Quy ước phổ biến: <0.1 ổn định, 0.1–0.25 cần chú ý, >0.25 drift đáng kể.
• KS test / KL divergence / JS divergence: đo khoảng cách giữa hai phân phối liên tục.
• Với concept drift: phải theo dõi chất lượng thực tế (accuracy, AUC) khi có nhãn trễ — ví dụ 30 ngày sau mới biết đơn có gian lận thật hay không. Đây là lý do phải có proxy metric trong lúc chờ nhãn.

Khung tư duy: "Bậc thang tín hiệu drift"

Không phải mọi drift đều cần báo động. Hãy phân bậc:

• Tầng 1 — Input health: thiếu feature, giá trị null tăng, kiểu dữ liệu lỗi. Bắt trước tiên vì rẻ và rõ.
• Tầng 2 — Distribution drift: PSI/KS vượt ngưỡng trên các feature quan trọng.
• Tầng 3 — Prediction drift: phân phối output lệch.
• Tầng 4 — Performance drift: chất lượng thực tế giảm (cần nhãn).

Ngưỡng cảnh báo nên khác nhau theo tầng và theo mức độ quan trọng của feature. Đây chính là product decision.

Ví dụ cụ thể

Mô hình gợi ý sản phẩm của một app grocery. Tết đến, giỏ hàng đổi hoàn toàn (bánh chưng, mứt thay vì sữa, rau). PSI trên feature "danh mục sản phẩm" nhảy lên 0.4. Nếu bạn set một ngưỡng cứng 0.25 cho mọi feature, hệ thống sẽ hú còi mỗi dịp lễ — alert fatigue. Cách PM giỏi làm:

• Thêm ngữ cảnh mùa vụ (so với cùng kỳ năm trước, không so với tháng trước).
• Phân biệt drift "kỳ vọng được" (lễ Tết) và drift "bất thường".
• Gắn drift với tác động: PSI cao nhưng CTR không giảm thì hạ mức ưu tiên.

Checklist thiết kế monitoring drift

• [ ] Liệt kê feature quan trọng nhất và đặt ngưỡng riêng cho từng nhóm.
• [ ] Chọn baseline hợp lý (không dùng baseline lỗi thời hay quá hẹp).
• [ ] Có cả input health check (tầng rẻ) lẫn distribution drift.
• [ ] Xác định độ trễ nhãn và đặt proxy metric cho giai đoạn chờ.
• [ ] Định nghĩa hành động ứng với mỗi tầng (log, thông báo, cảnh báo, chặn deploy).
• [ ] Tính đến mùa vụ / sự kiện để giảm cảnh báo giả.

Sai lầm thường gặp

• Chỉ theo dõi accuracy mà quên input drift. Đến khi accuracy tụt thì đã muộn và bạn không biết vì sao.
• Một ngưỡng cho tất cả feature. Feature ít ảnh hưởng cũng hú còi như feature sống còn.
• Bỏ quên độ trễ nhãn. Tưởng "không thấy giảm chất lượng" trong khi nhãn thật chưa về.
• Nhầm drift với lỗi pipeline. Null tăng do bug ETL bị hiểu nhầm là data drift — luôn kiểm tra input health trước.
• Không gắn drift với business impact, dẫn tới báo động vô nghĩa và đội ngũ mất niềm tin vào hệ thống cảnh báo.