Sau khi một model AI được deploy lên production, có một xu hướng phổ biến: team tập trung vào tính năng mới, và model tiếp tục chạy im lặng — cho đến khi có ai đó để ý rằng kết quả đang kém hơn trước. Không phải lỗi code, không phải exception trong log — mà là thế giới đã thay đổi, nhưng model thì không.

Đây là hai cơ chế drift phổ biến nhất trong production AI: data drift (phân phối đầu vào thay đổi so với lúc training) và concept drift (mối quan hệ giữa đầu vào và đầu ra kỳ vọng thay đổi). Cả hai đều không tạo ra bất kỳ lỗi nào trong log, và cả hai đều có thể phát hiện sớm — nếu có monitoring loop đúng chỗ.

Hai loại drift — khác nhau ở nguyên nhân và cách xử lý

Phân biệt đúng loại drift là bước đầu tiên để xử lý đúng cách. Retrain với data mới không giải quyết được concept drift nếu không đi kèm với việc review nhãn; sửa feature engineering không giải quyết được upstream data quality issue.

Data drift: phân phối của đầu vào (features) thay đổi so với lúc training. Ví dụ điển hình: model phân loại lỗi bề mặt được train trên ảnh chụp ban ngày, nhưng sau một tháng camera được chuyển sang phòng có ánh sáng khác. Model vẫn nhận ảnh và trả kết quả — chỉ là ảnh đầu vào giờ khác về histogram pixel intensity so với training data
Concept drift: mối quan hệ giữa input và output đúng thay đổi, dù input distribution không đổi. Ví dụ: model dự báo churn được train trên hành vi người dùng trước một đợt thay đổi sản phẩm lớn — sau đó cùng một pattern hành vi không còn tương quan với churn theo cách cũ nữa. Đây là loại drift khó xử lý hơn vì không thể chỉ retrain với data mới nếu không review lại nhãn
Upstream data quality drift: pipeline nguồn thay đổi âm thầm — một cột bị đổi đơn vị, giá trị null được xử lý khác đi, hoặc một nguồn dữ liệu bên thứ ba bắt đầu trả về kết quả chất lượng thấp hơn. Về mặt thống kê đây là data drift, nhưng nguyên nhân là data engineering — không phải thế giới thực thay đổi

Cả ba loại đều không tạo ra exception hay lỗi hệ thống. Hệ thống vẫn chạy, model vẫn trả về kết quả — chỉ là kết quả ngày càng ít tin cậy hơn.

Đo drift bằng gì — từ statistical test đến proxy metric

Khi không có drift monitoring, thường phải đợi đến khi ground truth (kết quả thực tế) tích lũy đủ và sai lệch đủ lớn để nhận ra. Với các hệ thống có feedback chậm (dự báo, phân loại ảnh), đó có thể là vài tuần. Một số công cụ đo sớm hơn:

PSI (Population Stability Index): đo độ thay đổi trong phân phối của một feature liên tục. PSI < 0.1 thường được coi là ổn định, 0.1–0.2 là cần theo dõi, > 0.2 là đáng kể. Có thể tính song song cho tất cả input features trong batch monitoring
Wasserstein distance và KL divergence: đo "khoảng cách" giữa distribution hiện tại và distribution baseline lúc training, phù hợp hơn PSI cho distribution nhiều chiều hoặc distribution có đuôi dài
Output distribution shift: theo dõi phân phối của chính output model (predicted probability, class distribution). Nếu tỷ lệ predicted positive tăng từ 5% lên 20% mà không có lý do nghiệp vụ rõ ràng, đó là dấu hiệu sớm của drift — dù chưa có ground truth nào về
Ground truth có delay: với nhiều bài toán (phát hiện gian lận, churn), ground truth về sau vài ngày đến vài tuần. Khi về, so sánh trực tiếp với prediction để tính accuracy/F1 trên cửa sổ thời gian gần nhất. Đây là tín hiệu đáng tin cậy nhất nhưng đến muộn nhất

Ba tầng monitoring — từ feature đến business metric

Không có một chỉ số đơn nào đủ tin cậy để quyết định khi nào model cần retrain. Monitoring hiệu quả cần ba tầng phối hợp — cho phép phát hiện sớm ở tầng trên và xác nhận ở tầng dưới:

Tầng 1 — Feature monitoring: log distribution của từng feature đầu vào theo batch (hằng giờ hoặc hằng ngày), so sánh với baseline distribution lúc training. Đây là lớp cảnh báo sớm nhất — thường thấy drift ở features trước khi ảnh hưởng đến output. Công cụ phổ biến: Evidently AI, WhyLogs, hoặc custom pipeline dựa trên Great Expectations
Tầng 2 — Output monitoring: theo dõi distribution của model output (predicted probabilities, confidence scores, predicted class ratio). Output drift thường đến sau feature drift nhưng trực tiếp hơn — nếu output distribution thay đổi mạnh mà không có feature drift đi kèm, thường là dấu hiệu của concept drift hoặc lỗi ở tầng preprocessing
Tầng 3 — Business metric monitoring: conversion rate, precision thực tế khi ground truth về, số cảnh báo false positive từ hệ thống xuôi. Đây là tín hiệu muộn nhất nhưng quan trọng nhất — nếu business metric vẫn ổn, drift ở tầng 1–2 chưa đủ để kích hoạt retrain

Mục tiêu của ba tầng không phải là có nhiều alert hơn — mà là phát hiện suy giảm sớm hơn 2–4 tuần so với khi business metric xấu đi, đủ thời gian để thu thập data mới, retrain và validate trước khi người dùng cuối chịu ảnh hưởng.

Khi nào retrain, khi nào cần xem lại kiến trúc

Không phải mọi drift đều dẫn đến retrain. Quyết định phụ thuộc vào loại drift, mức độ, và tốc độ suy giảm:

PSI > 0.1 trên 2–3 features quan trọng nhất, business metric chưa bị ảnh hưởng đáng kể → scheduled retrain với data mới nhất, không cần khẩn cấp
Output drift và feature drift cùng tăng → retrain khẩn cấp, kèm kiểm tra data pipeline xem có upstream quality issue không
Concept drift xác nhận (ground truth về và accuracy giảm nhưng feature distribution không đổi nhiều) → retrain nhưng cần review nhãn, vì training data cũ có thể chứa nhãn không còn đúng nữa
Drift tái xuất sau nhiều lần retrain với data mới → distribution đã thay đổi đủ để cần xem lại feature engineering hoặc model architecture — đây không còn là vấn đề retrain mà là vấn đề kiến trúc

Ví dụ thực tế: model phân loại lỗi bề mặt trong sản xuất thép

Trong dự án giám sát kết cấu và phân loại lỗi tại 4 nhà máy thép, model computer vision được deploy để phát hiện defect trên bề mặt thép cuộn từ ảnh camera công nghiệp. Ba tuần sau khi deploy trên dây chuyền 3 và 4, output confidence score bắt đầu giảm — model vẫn dự đoán, nhưng phân phối confidence dịch về phía thấp hơn so với baseline.

Tầng 1 (feature monitoring) phát hiện: histogram pixel intensity của ảnh từ camera dây chuyền 3–4 drift đáng kể so với training data — ánh sáng tại hai dây chuyền đó thay đổi theo mùa. Giải pháp không phải retrain từ đầu: augment training set với ảnh từ cả 4 điều kiện ánh sáng, thêm normalization ở tầng preprocessing. Nếu không có monitoring loop, drift này có thể không bị phát hiện cho đến khi recall trên lỗi thực tế giảm đủ để ảnh hưởng đến quy trình QC.

Kết luận

Model AI không "set and forget" — đây là điểm khác biệt cơ bản nhất giữa phần mềm truyền thống và AI trong production. Optimization Loop, lớp thứ sáu trong stack KonexForge, là nơi monitoring, alerting và quyết định retrain được chuẩn hóa thành một quy trình lặp lại — không phải tác vụ ad-hoc chỉ làm khi đã quá trễ. Mỗi Pilot Build đều được thiết kế với monitoring baseline ngay từ ngày deploy đầu tiên, không phải bổ sung sau.

Model AI trong production suy giảm như thế nào — và cách phát hiện trước khi quá trễ