Trong nhiều dự án Machine Learning, nhóm phát triển dành rất nhiều thời gian cho việc huấn luyện, chọn mô hình, tối ưu tham số và đánh giá trên tập kiểm thử. Nhưng sau khi mô hình được đưa vào sản phẩm thật, một vấn đề khác bắt đầu xuất hiện: dữ liệu ngoài đời thay đổi, hành vi người dùng thay đổi, hệ thống upstream thay đổi, và mô hình có thể xuống cấp mà không báo trước. Vì vậy, triển khai mô hình không nên được xem là điểm kết thúc. Nó là điểm bắt đầu của giai đoạn theo dõi và vận hành mô hình. Một ví dụ thực tế: bạn xây dựng mô hình dự đoán khả năng khách hàng rời bỏ dịch vụ. Khi huấn luyện, dữ liệu đến từ 12 tháng trước, với các gói giá cũ và hành vi sử dụng cũ. Sau đó công ty thay đổi chính sách giá, thêm tính năng mới, hoặc chạy chiến dịch khuyến mãi lớn. Phân phối dữ liệu đầu vào có thể thay đổi đáng kể. Mô hình vẫn trả ra xác suất như bình thường, nhưng độ tin cậy của nó có thể đã giảm. Có vài nhóm tín hiệu nên được theo dõi sau khi deploy: 1. Chất lượng dữ liệu đầu vào Đây là lớp kiểm tra đầu tiên. Hãy theo dõi các vấn đề như: - Tỷ lệ giá trị thiếu tăng bất thường - Kiểu dữ liệu thay đổi, ví dụ trường số bị gửi thành chuỗi - Giá trị nằm ngoài khoảng hợp lý - Một feature vốn có nhiều giá trị nay gần như chỉ còn một giá trị - Dữ liệu đến chậm hoặc thiếu theo lô Nhiều lỗi mô hình trong thực tế không đến từ thuật toán, mà đến từ pipeline dữ liệu. Ví dụ, một cột “số ngày kể từ lần đăng nhập gần nhất” bị tính sai thành 0 cho mọi người dùng có thể làm mô hình dự đoán lệch hàng loạt. 2. Drift của dữ liệu Data drift xảy ra khi phân phối dữ liệu hiện tại khác với dữ liệu dùng để huấn luyện. Không phải drift nào cũng nguy hiểm, nhưng drift là dấu hiệu cần kiểm tra. Ví dụ, trong mô hình phát hiện gian lận giao dịch, nếu tỷ lệ giao dịch từ một kênh thanh toán mới tăng nhanh, mô hình cũ có thể chưa học đủ mẫu từ kênh đó. Khi đó, việc theo dõi phân phối theo thời gian giúp nhóm phát hiện sớm vùng dữ liệu mà mô hình chưa quen. Không nhất thiết phải bắt đầu bằng kỹ thuật phức tạp. Với nhiều hệ thống, các biểu đồ đơn giản theo ngày hoặc theo tuần cho từng feature quan trọng đã rất hữu ích: trung bình, trung vị, phần trăm giá trị thiếu, top giá trị phổ biến, phân vị 5% và 95%. 3. Hiệu năng dự đoán khi có nhãn thật Nếu bài toán có nhãn phản hồi sau một thời gian, hãy thiết kế cơ chế nối lại dự đoán với kết quả thực tế. Ví dụ: - Mô hình dự đoán khách hàng rời bỏ: nhãn thật có thể có sau 30 ngày - Mô hình chấm điểm lead bán hàng: nhãn thật có thể có sau khi sale xử lý - Mô hình phát hiện gian lận: nhãn thật có thể đến sau điều tra hoặc khiếu nại Khi có nhãn, nên theo dõi metric theo thời gian, theo phân khúc và theo phiên bản mô hình. Đừng chỉ nhìn một con số tổng. Một mô hình có thể vẫn ổn trên toàn bộ dữ liệu nhưng giảm mạnh trên nhóm người dùng mới, khu vực mới hoặc loại sản phẩm mới. 4. Hành vi đầu ra của mô hình Ngay cả khi chưa có nhãn thật, bạn vẫn có thể theo dõi phân phối prediction: - Tỷ lệ dự đoán lớp dương có tăng hoặc giảm bất thường không? - Xác suất đầu ra có bị dồn về gần 0 hoặc gần 1 không? - Top nhóm được mô hình đánh điểm cao có thay đổi đột ngột không? - Có request nào tạo ra kết quả không hợp lệ không? Ví dụ, nếu hệ thống gợi ý sản phẩm bỗng chỉ đề xuất một vài mặt hàng lặp đi lặp lại, vấn đề có thể nằm ở dữ liệu đầu vào, logic lọc ứng viên, hoặc mô hình embedding bị cập nhật sai. Một quy trình thực tế nên bắt đầu như thế nào? Nếu nhóm của bạn chưa có hệ thống monitoring bài bản, có thể bắt đầu theo thứ tự sau: - Ghi log đầy đủ: input chính, output mô hình, thời gian dự đoán, phiên bản mô hình, phiên bản feature pipeline - Tạo dashboard đơn giản cho các feature quan trọng và phân phối prediction - Thiết lập cảnh báo cho lỗi rõ ràng: thiếu dữ liệu, schema sai, latency tăng, tỷ lệ prediction bất thường - Khi có nhãn thật, tính metric định kỳ theo ngày, tuần hoặc tháng - Lưu lại dữ liệu phục vụ phân tích lỗi và huấn luyện lại Một điểm quan trọng là monitoring không chỉ dành cho kỹ sư ML. Product owner, data engineer, backend engineer và người vận hành nghiệp vụ đều nên hiểu các tín hiệu chính. Khi mô hình xuống cấp, nguyên nhân có thể nằm ở thay đổi sản phẩm, thay đổi nguồn dữ liệu, thay đổi hành vi người dùng hoặc lỗi triển khai. Lời khuyên thực tế: - Đừng chờ đến khi có hệ thống hoàn hảo mới bắt đầu theo dõi. Một vài biểu đồ đúng còn tốt hơn không có gì. - Hãy theo dõi theo phân khúc, không chỉ theo trung bình toàn hệ thống. - Luôn lưu phiên bản mô hình và phiên bản dữ liệu/feature để truy vết. - Coi việc huấn luyện lại là một quy trình có kiểm soát, không phải phản ứng vội vàng mỗi khi metric giảm. - Khi phát hiện drift, hãy phân tích trước khi kết luận rằng cần đổi thuật toán. Machine Learning trong môi trường thật là một hệ thống sống. Mô hình hôm nay tốt không đảm bảo ngày mai vẫn tốt. Theo dõi sau triển khai giúp nhóm phát hiện vấn đề sớm, hiểu nguyên nhân rõ hơn và cải tiến mô hình một cách có trách nhiệm.