Trong nhiều dự án Machine Learning, nhóm phát triển dành khá nhiều thời gian chọn mô hình, tinh chỉnh tham số, thử thêm feature mới, nhưng lại chia dữ liệu huấn luyện - validation - test một cách rất vội: lấy ngẫu nhiên 80/10/10 là xong. Cách này đôi khi ổn, nhưng trong nhiều bài toán thực tế, nó tạo ra một validation set quá “dễ tính”, khiến kết quả thử nghiệm đẹp hơn rất nhiều so với khi triển khai thật. Vấn đề không nằm ở tỷ lệ chia dữ liệu, mà nằm ở câu hỏi: tập validation có mô phỏng đúng tình huống mô hình sẽ gặp sau này không? Ví dụ 1: Dự đoán khách hàng rời bỏ dịch vụ Giả sử bạn có dữ liệu khách hàng trong 12 tháng và muốn dự đoán ai có khả năng hủy gói trong tháng tới. Nếu chia ngẫu nhiên toàn bộ dữ liệu, mô hình có thể học được các mẫu hành vi từ cả tương lai lẫn quá khứ trộn lẫn với nhau. Validation score có thể rất cao, nhưng khi triển khai cho tháng 13, mô hình gặp phân phối dữ liệu mới hơn và hiệu năng giảm mạnh. Cách hợp lý hơn là chia theo thời gian: - Train: tháng 1 đến tháng 8 - Validation: tháng 9 đến tháng 10 - Test: tháng 11 đến tháng 12 Cách chia này giúp bạn kiểm tra xem mô hình học từ quá khứ có dự đoán tốt cho tương lai hay không. Đây là điều gần với thực tế vận hành hơn nhiều so với chia ngẫu nhiên. Ví dụ 2: Phân loại giao dịch gian lận Trong bài toán fraud detection, hành vi gian lận thường thay đổi theo thời gian. Nếu một nhóm giao dịch gian lận tương tự nhau xuất hiện trong cùng một chiến dịch tấn công, việc chia ngẫu nhiên có thể khiến các mẫu rất giống nhau nằm cả trong train và validation. Khi đó mô hình không thực sự học cách tổng quát hóa, mà chỉ “nhận ra” những mẫu đã thấy gần như tương tự. Một cách kiểm tra tốt hơn là chia theo cụm thời gian, theo người dùng, hoặc theo chiến dịch nếu có thông tin. Mục tiêu là tránh việc cùng một thực thể hoặc cùng một ngữ cảnh rò rỉ giữa train và validation. Một số kiểu chia dữ liệu nên cân nhắc 1. Chia ngẫu nhiên có phân tầng Phù hợp khi dữ liệu độc lập tương đối và không có yếu tố thời gian mạnh. Ví dụ: phân loại ảnh sản phẩm, phân loại câu hỏi hỗ trợ khách hàng, dự đoán nhãn từ bản ghi độc lập. Nếu dữ liệu mất cân bằng, nên dùng stratified split để tỷ lệ nhãn giữa các tập không lệch quá nhiều. 2. Chia theo thời gian Phù hợp với forecasting, churn prediction, risk scoring, fraud detection, giá cả, nhu cầu kho vận, log người dùng. Nguyên tắc đơn giản: không để dữ liệu tương lai xuất hiện trong train nếu khi chạy thật mô hình không thể biết điều đó. 3. Chia theo nhóm Dùng khi nhiều dòng dữ liệu thuộc cùng một người dùng, thiết bị, cửa hàng, bệnh nhân, công ty hoặc phiên làm việc. Ví dụ, nếu bạn dự đoán bệnh từ nhiều ảnh y tế của cùng một bệnh nhân, không nên để ảnh của cùng bệnh nhân xuất hiện ở cả train và validation. Nếu không, mô hình có thể học đặc điểm riêng của bệnh nhân thay vì dấu hiệu bệnh. 4. Chia theo kịch bản khó Đôi khi validation set nên có một phần dữ liệu đại diện cho trường hợp khó: người dùng mới, sản phẩm mới, khu vực mới, loại văn bản ít gặp, thiết bị ít phổ biến. Điều này giúp bạn biết mô hình sẽ yếu ở đâu trước khi người dùng thật phát hiện. Các câu hỏi nên tự đặt trước khi chia dữ liệu - Khi triển khai thật, mô hình sẽ dự đoán cho dữ liệu “tương lai” hay dữ liệu cùng phân phối với quá khứ? - Có thực thể nào lặp lại nhiều lần không, như user_id, shop_id, device_id, patient_id? - Có khả năng cùng một nội dung bị trùng hoặc gần trùng giữa các tập không? - Nhãn có bị mất cân bằng không? - Có nhóm dữ liệu nào quan trọng về mặt kinh doanh nhưng chiếm tỷ lệ nhỏ không? - Validation set hiện tại có phản ánh đúng chi phí sai lầm ngoài thực tế không? Một quy trình thực tế nên áp dụng Đầu tiên, xác định cách mô hình sẽ được dùng trong sản phẩm. Nếu mô hình được huấn luyện hàng tuần để dự đoán tuần tiếp theo, hãy thiết kế validation theo tuần. Nếu mô hình phục vụ người dùng mới, hãy có tập kiểm tra riêng cho người dùng chưa từng xuất hiện trong train. Tiếp theo, tạo một test set “khóa lại” và không dùng để tinh chỉnh mô hình hằng ngày. Validation set dùng để chọn feature, chọn mô hình, chỉnh hyperparameter. Test set chỉ nên dùng ở các mốc đánh giá quan trọng, nếu không bạn sẽ vô tình tối ưu theo test set. Cuối cùng, đừng chỉ nhìn một chỉ số trung bình. Hãy phân tích theo lát cắt: nhóm khách hàng mới/cũ, khu vực, loại thiết bị, độ dài văn bản, phân khúc sản phẩm, mức độ hiếm của nhãn. Một mô hình có accuracy cao nhưng thất bại ở nhóm người dùng quan trọng vẫn có thể là mô hình không phù hợp để triển khai. Kết luận Chia dữ liệu không phải là bước thủ tục, mà là một quyết định thiết kế thí nghiệm. Một validation set tốt không nhất thiết làm điểm số đẹp hơn; nó giúp bạn nhìn thấy rủi ro sớm hơn. Trong dự án thực tế, điều đó thường có giá trị hơn nhiều so với việc tăng thêm vài phần trăm trên một tập đánh giá quá dễ.