Trong nhiều dự án Machine Learning, nhóm phát triển thường tập trung vào mô hình: chọn thuật toán, tinh chỉnh tham số, tăng điểm đánh giá. Nhưng khi đưa vào sử dụng thật, một nguyên nhân rất phổ biến khiến mô hình hoạt động kém là sai lệch giữa dữ liệu lúc huấn luyện và dữ liệu lúc suy luận, thường được gọi là training-serving skew. Nói đơn giản, mô hình được học trên một kiểu dữ liệu, nhưng khi chạy thật lại nhận một kiểu dữ liệu hơi khác. Sự khác biệt có thể rất nhỏ, khó nhìn thấy ngay, nhưng đủ để làm dự đoán sai lệch. Ví dụ thực tế: mô hình dự đoán khách hàng có khả năng rời bỏ dịch vụ Giả sử bạn xây dựng mô hình dự đoán khách hàng có nguy cơ hủy thuê bao. Trong tập huấn luyện, một đặc trưng là: - số_lần_liên_hệ_hỗ_trợ_trong_30_ngày Khi tạo dữ liệu huấn luyện, nhóm dữ liệu tính trường này bằng cách lấy toàn bộ lịch sử ticket đã được đồng bộ đầy đủ vào kho dữ liệu. Nhưng trong hệ thống chạy thật, đặc trưng này được tính từ dịch vụ vận hành theo thời gian gần thực, nơi một số ticket có thể cập nhật chậm vài giờ. Kết quả: cùng một khách hàng, ở môi trường huấn luyện có giá trị là 5, nhưng khi suy luận có thể chỉ là 2 hoặc 3. Mô hình vẫn chạy, không báo lỗi, nhưng quyết định đưa ra đã dựa trên tín hiệu khác với tín hiệu mà nó từng học. Các dạng sai lệch thường gặp 1. Khác cách xử lý dữ liệu thiếu Trong notebook huấn luyện, dữ liệu thiếu được điền bằng giá trị trung bình. Nhưng trong API suy luận, trường thiếu lại được gán bằng 0. Nếu 0 cũng là một giá trị có nghĩa, mô hình có thể hiểu sai nghiêm trọng. 2. Khác định nghĩa đặc trưng Một nhóm định nghĩa “doanh thu 30 ngày” là 30 ngày gần nhất tính đến hôm nay. Nhóm khác lại tính theo tháng lịch. Hai cách này nghe gần giống nhau nhưng tạo ra phân phối dữ liệu khác nhau. 3. Khác thời điểm có dữ liệu Một đặc trưng có thể tồn tại trong dữ liệu lịch sử, nhưng tại thời điểm dự đoán thật thì chưa có. Đây là lỗi rất nguy hiểm vì mô hình khi huấn luyện có vẻ rất tốt, nhưng thực tế không thể sử dụng đúng thông tin đó. 4. Khác phiên bản mã tiền xử lý Huấn luyện dùng một hàm chuẩn hóa cũ, production dùng hàm mới. Nếu không quản lý phiên bản rõ ràng, việc truy vết nguyên nhân sẽ rất mất thời gian. 5. Khác danh mục hoặc cách mã hóa biến phân loại Ví dụ, trong huấn luyện, tỉnh/thành được mã hóa theo một bảng mapping. Khi triển khai, hệ thống lại nhận thêm giá trị mới hoặc viết khác định dạng như “TP.HCM”, “Hồ Chí Minh”, “HCM”. Nếu không xử lý nhất quán, mô hình có thể nhận đầu vào ngoài dự kiến. Cách giảm rủi ro training-serving skew 1. Dùng chung mã xử lý đặc trưng khi có thể Nếu pipeline huấn luyện và pipeline suy luận cùng dùng một thư viện hoặc một module xử lý đặc trưng, khả năng lệch logic sẽ giảm đáng kể. Tránh tình trạng notebook có một kiểu, backend có một kiểu, SQL báo cáo có một kiểu. 2. Ghi rõ định nghĩa đặc trưng Mỗi đặc trưng quan trọng nên có mô tả rõ: - Tên đặc trưng - Ý nghĩa nghiệp vụ - Cửa sổ thời gian tính toán - Nguồn dữ liệu - Cách xử lý thiếu - Thời điểm đặc trưng sẵn sàng Tài liệu này không cần quá dài, nhưng phải đủ để người khác tái tạo đúng. 3. Kiểm tra phân phối dữ liệu giữa huấn luyện và production Sau khi triển khai, nên so sánh các thống kê cơ bản như trung bình, trung vị, tỷ lệ thiếu, giá trị nhỏ nhất/lớn nhất, danh mục phổ biến. Nếu một đặc trưng trong huấn luyện có tỷ lệ thiếu 2% nhưng production là 40%, đó là tín hiệu cần điều tra ngay. 4. Tạo bộ kiểm thử cho pipeline dữ liệu Không chỉ kiểm thử model, hãy kiểm thử cả dữ liệu đầu vào. Ví dụ: - Trường bắt buộc không được rỗng - Giá trị tuổi phải nằm trong khoảng hợp lý - Tổng tiền giao dịch không được âm nếu nghiệp vụ không cho phép - Các biến phân loại phải thuộc danh sách được chấp nhận hoặc có cơ chế xử lý giá trị mới Những kiểm thử đơn giản này giúp phát hiện lỗi trước khi mô hình đưa ra dự đoán sai hàng loạt. 5. Lưu lại dữ liệu đầu vào khi mô hình dự đoán Nếu điều kiện bảo mật và quyền riêng tư cho phép, hãy lưu lại phiên bản dữ liệu đặc trưng mà mô hình đã nhận tại thời điểm suy luận. Khi có phản hồi sai hoặc chất lượng giảm, bạn có thể đối chiếu: mô hình sai vì thuật toán, vì dữ liệu đầu vào, hay vì nghiệp vụ đã thay đổi. Một lời khuyên thực tế Khi mô hình hoạt động kém ngoài production, đừng vội huấn luyện lại mô hình lớn hơn hoặc đổi thuật toán phức tạp hơn. Hãy kiểm tra trước ba câu hỏi: - Dữ liệu suy luận có cùng định nghĩa với dữ liệu huấn luyện không? - Các đặc trưng có được tính tại đúng thời điểm dự đoán không? - Pipeline tiền xử lý giữa hai môi trường có thật sự giống nhau không? Trong nhiều trường hợp, cải thiện chất lượng mô hình không bắt đầu từ mạng nơ-ron sâu hơn, mà từ việc làm cho dữ liệu nhất quán hơn. Một mô hình vừa phải nhưng nhận dữ liệu đúng và ổn định thường đáng tin cậy hơn một mô hình phức tạp được nuôi bằng pipeline lệch chuẩn.