1. 06:34 06/08/2026
Trong nhiều dự án Machine Learning, có một kiểu lỗi rất dễ bị bỏ qua: data leakage, hay rò rỉ dữ liệu. Đây là tình huống mô hình vô tình được học từ thông tin mà đáng lẽ tại thời điểm dự đoán nó chưa được biết. Kết quả là điểm đánh giá trên tập validation/test rất đẹp, nhưng khi triển khai thật thì mô hình suy giảm mạnh.
Nói ngắn gọn: mô hình không thực sự học quy luật tổng quát, mà đang “nhìn lén đáp án”.
Ví dụ thực tế dễ gặp
Giả sử bạn xây mô hình dự đoán khách hàng có hủy dịch vụ trong 30 ngày tới hay không. Trong dữ liệu có cột “ngày đóng tài khoản” hoặc “lý do hủy”. Nếu đưa các cột này vào lúc huấn luyện, mô hình sẽ dự đoán cực tốt. Nhưng ngoài thực tế, tại thời điểm cần dự đoán, bạn chưa thể biết khách hàng sẽ đóng tài khoản ngày nào. Đây là leakage rõ ràng.
Một ví dụ khác: dự đoán khoản vay có bị vỡ nợ hay không. Nếu dữ liệu có trường “số lần nhắc nợ sau 90 ngày”, thì trường này chỉ xuất hiện sau khi sự kiện đã diễn ra. Dùng nó để dự đoán rủi ro trước khi duyệt vay là sai về mặt thời gian.
Các dạng leakage phổ biến
1. Leakage do đặc trưng chứa thông tin tương lai
Đây là dạng dễ hiểu nhất. Một cột dữ liệu được sinh ra sau thời điểm dự đoán nhưng lại được đưa vào mô hình. Các trường như trạng thái cuối cùng, ngày hoàn tất, kết quả xử lý, lý do rời bỏ, số lần khiếu nại sau sự kiện... đều cần kiểm tra kỹ.
Câu hỏi nên đặt ra cho mỗi feature: “Tại thời điểm mô hình ra quyết định, thông tin này đã tồn tại chưa?” Nếu câu trả lời là chưa, không nên dùng.
2. Leakage do xử lý dữ liệu trước khi chia train/test
Một lỗi rất hay gặp là chuẩn hóa, điền giá trị thiếu, chọn feature hoặc tạo thống kê trên toàn bộ dữ liệu rồi mới chia tập. Ví dụ bạn tính trung bình của một cột trên toàn dataset để điền missing value, sau đó chia train/test. Khi đó thông tin từ test đã ảnh hưởng tới train.
Cách làm đúng là: chia dữ liệu trước, sau đó fit các bước xử lý trên train, rồi chỉ transform validation/test bằng thông tin học được từ train. Trong scikit-learn, Pipeline là công cụ rất nên dùng để giảm lỗi kiểu này.
3. Leakage do trùng lặp hoặc gần trùng lặp bản ghi
Nếu cùng một người dùng, cùng một giao dịch, hoặc các bản ghi gần giống nhau xuất hiện ở cả train và test, mô hình có thể ghi nhớ thay vì học. Điều này đặc biệt nguy hiểm với dữ liệu ảnh, văn bản, log người dùng, hồ sơ y tế, dữ liệu giao dịch.
Ví dụ: một khách hàng có nhiều dòng giao dịch. Nếu chia ngẫu nhiên theo từng dòng, giao dịch của cùng khách hàng có thể nằm ở cả train và test. Khi đó điểm số có thể cao bất thường. Trong trường hợp này nên chia theo nhóm, chẳng hạn GroupKFold theo customer_id.
4. Leakage do sai mốc thời gian
Với bài toán có yếu tố thời gian, chia dữ liệu ngẫu nhiên thường không phù hợp. Nếu bạn dùng dữ liệu tháng 12 để dự đoán cho tháng 6 trong quá trình đánh giá, mô hình đã hưởng lợi từ tương lai.
Cách thực tế hơn là chia theo thời gian: huấn luyện trên giai đoạn trước, kiểm tra trên giai đoạn sau. Ví dụ train từ tháng 1 đến tháng 9, validation tháng 10, test tháng 11. Cách này thường cho điểm thấp hơn nhưng phản ánh đúng hơn khi triển khai.
Dấu hiệu nghi ngờ có leakage
- Điểm validation/test cao bất thường so với kỳ vọng nghiệp vụ.
- Mô hình đơn giản nhưng đạt kết quả gần như hoàn hảo.
- Một vài feature có importance cao áp đảo và tên cột nghe giống “kết quả sau cùng”.
- Khi triển khai thử, chất lượng giảm mạnh dù dữ liệu đầu vào có vẻ không đổi.
- Cross-validation tốt nhưng kiểm tra theo thời gian lại kém.
Checklist phòng tránh data leakage
- Xác định rõ thời điểm dự đoán: mô hình ra quyết định khi nào?
- Với mỗi feature, kiểm tra nó có sẵn tại thời điểm đó không.
- Chia train/validation/test trước khi fit preprocessing.
- Dùng Pipeline để đóng gói preprocessing và model.
- Với dữ liệu theo người dùng/tổ chức/sản phẩm, cân nhắc chia theo nhóm thay vì chia từng dòng.
- Với dữ liệu thời gian, ưu tiên split theo thời gian.
- Kiểm tra feature importance và rà soát các cột đáng ngờ.
- Tạo một bộ test mô phỏng tình huống triển khai thật nhất có thể.
Một lời khuyên thực dụng
Đừng chỉ hỏi “mô hình đạt accuracy bao nhiêu?”, hãy hỏi thêm “mô hình có được biết thông tin này ở thời điểm dự đoán thật không?”. Trong nhiều dự án AI, loại bỏ leakage có thể làm điểm số ban đầu giảm xuống, nhưng đó là tín hiệu tốt: bạn đang tiến gần hơn tới một đánh giá trung thực.
Một mô hình điểm thấp nhưng phản ánh đúng thực tế vẫn hữu ích hơn mô hình điểm cao nhờ nhìn lén đáp án. Data leakage không phải lỗi thuật toán, mà là lỗi thiết kế thí nghiệm. Vì vậy, phòng tránh nó cần sự phối hợp giữa người làm dữ liệu, kỹ sư ML và người hiểu nghiệp vụ.