Overfitting & data leakage: demo đẹp mà production hỏng

TL;DR: Model đo đẹp trên tập huấn luyện nhưng tệ trên dữ liệu mới đang overfitting — nó thuộc lòng thay vì học quy luật chung. Tệ hơn: nếu cả train lẫn validation đều đẹp mà production vẫn hỏng, nghi ngờ số một là data leakage — feature vô tình mang thông tin chỉ tồn tại sau khi đã biết đáp án, nên đo nội bộ đẹp giả tạo còn lúc chạy thật thông tin đó luôn trống. Nguyên tắc chẩn đoán: nhìn bộ ba train/validation/production, không nhìn một con số đơn lẻ — điểm càng đẹp bất thường càng đáng soát lại pipeline dữ liệu, không phải ăn mừng.

Đội bạn build model chấm điểm rủi ro giao dịch. Trên tập test giữ lại, model đạt độ chính xác cao ngất — deploy production ngay tuần đó. Một tháng sau, đội gian lận báo cáo model bỏ lọt phần lớn ca gian lận thật, còn báo động nhầm hàng loạt giao dịch bình thường, dù không ai đổi code hay hạ tầng. Điều gì đã sai giữa lúc đo và lúc chạy thật?

Bài này cho bạn quy trình chẩn đoán: đọc ba con số train/validation/production để phân biệt hai nguyên nhân phổ biến nhất khiến "đo đẹp mà chạy hỏng" — overfitting và data leakage.

1. Analogy — học thuộc đề thi cũ vs hiểu bài

Có hai cách chuẩn bị cho kỳ thi: học thuộc lòng đúng đề năm ngoái (làm lại đạt điểm tuyệt đối), hoặc hiểu bản chất bài học. Khác biệt chỉ lộ ra khi gặp đề mới: người học thuộc trượt thảm, người hiểu bài vẫn làm được.

Model overfitting làm đúng việc người học thuộc đề làm: nó không học quy luật sinh ra nhãn, mà học thuộc từng điểm dữ liệu trong tập train — kể cả nhiễu vô nghĩa. Đề cũ và đề mới, với model, chính là tập train và dữ liệu thật lúc chạy production.

2. Thử đoán trước khi đọc tiếp

Quay lại model chấm điểm rủi ro giao dịch. Giả sử đội đo được ba scenario dưới đây — số liệu ví dụ giả định, không phải benchmark thật:

3. Bảng chẩn đoán theo triệu chứng

Ba con số, đọc đúng thứ tự, kể câu chuyện khác nhau tuỳ tổ hợp cao/thấp:

Đối chiếu lại ba scenario ở mục 2:

• Scenario A (98% / 61% / 58%) — train cao, validation thấp: đúng khuôn overfitting. Model khớp gần hoàn hảo với tập train nhưng rớt mạnh ngay khi gặp dữ liệu validation nó chưa thấy.
• Scenario B (96% / 95% / 52%) — train cao, validation cũng cao, nhưng production lại tệ: đây là ca đáng ngại nhất, vì validation không hề tố cáo vấn đề. Mục 4 và 5 mổ xẻ nguyên nhân.
• Scenario C (54% / 52% / 50%) — train đã thấp ngay từ đầu: model chưa học được quy luật nào. Đây là underfit, nguyên nhân và cách sửa khác hẳn overfitting — bài này không đi sâu, chỉ cần nhận diện đúng để không áp nhầm cách sửa.

Sơ đồ chẩn đoán gộp cả ba nhánh:

Overfitting lộ ra ngay ở bước validation; data leakage thì không — nó qua mặt cả hai lớp kiểm tra nội bộ, chỉ lộ khi chạm dữ liệu thật.

4. Data leakage — vì sao validation cũng bị lừa

Data leakage (rò rỉ dữ liệu) là khi một feature vô tình mang thông tin chỉ có sau khi đáp án đã biết. Model không "gian lận" cố ý — nó chỉ tìm quy luật thống kê mạnh nhất trong feature được đưa vào, dù đó là một lối tắt vô dụng.

Quay lại ví dụ chấm điểm rủi ro giao dịch: giả sử bảng feature có cột "trạng thái tranh chấp" — chỉ được điền sau khi khách hàng khiếu nại, tức sau khi đã biết chắc giao dịch đó có gian lận hay không. Model học được quy luật gần như hoàn hảo: "có trạng thái tranh chấp thì gần chắc là gian lận" — đúng tuyệt đối trong dữ liệu lịch sử, vì kết quả có sẵn rồi mới điền cột đó. Nhưng lúc chạy thật, giao dịch vừa xảy ra thì cột này luôn rỗng — thông tin model dựa vào không tồn tại đúng thời điểm cần dự đoán.

Cột leak có mặt đều trong cả train lẫn validation (cùng lấy từ một kho dữ liệu lịch sử) nên validation không phát hiện gì — đúng scenario B ở mục 2. Production là nơi duy nhất cột đó trống, và cũng là nơi vấn đề lộ ra.

5. Data leakage qua đường tiền xử lý

Leakage còn len vào qua thứ tự làm việc với dữ liệu, không chỉ qua một cột "biết trước tương lai": tính bất cứ thống kê nào trên toàn bộ dữ liệu (chuẩn hoá, điền thiếu, chọn feature) trước khi tách train/validation/test là đã trộn ngược thông tin từ phần "chưa từng thấy" vào phần train.

Vi phạm này tinh vi hơn cột "trạng thái tranh chấp" ở mục 4 — lỗi nằm ở quy trình, không ở feature. Nguyên tắc chung cho cả hai kiểu leakage: tự hỏi "thông tin này có sẵn, đúng thời điểm cần dự đoán khi chạy production không?" — không thì là leakage.

6. Vì sao điểm số đẹp bất thường là tín hiệu đáng ngờ?

Trực giác tự nhiên khi thấy độ chính xác cao là ăn mừng — với model, cần đảo ngược: một con số cao vượt kỳ vọng là tín hiệu đi soát lại pipeline dữ liệu trước, ăn mừng sau. So với baseline đơn giản, bài toán này có thật "khó" cỡ đó không? Điểm cao hơn hẳn mức hợp lý thường là leakage cho model một lối tắt, không phải model đột nhiên giỏi.

7. Pitfall tổng hợp

❌ Nhầm 1 — thấy train và validation đều cao là yên tâm deploy:

✅ Điều kiện cần, không phải điều kiện đủ (mục 6) — cả hai đo trên cùng một kho lịch sử, kho đó chứa leakage thì cả hai con số bị lừa như nhau.

❌ Nhầm 2 — validation thấp thì luôn kết luận overfitting:

✅ Chỉ đúng khi train cao. Train cũng thấp là underfit — vấn đề khác hẳn, cách sửa khác hẳn. Đọc cả ba con số theo đúng thứ tự trong bảng chẩn đoán, đừng chỉ nhìn validation một mình.

❌ Nhầm 3 — nghĩ tách train/validation/test là đã miễn nhiễm với leakage:

✅ Tách tập chỉ chặn leakage nếu làm đúng thứ tự — trước mọi bước tiền xử lý, không chỉ trước bước train (mục 5). Tách sai thứ tự, hoặc có feature "biết trước tương lai" (mục 4), vẫn leak dù ba tập đã chia riêng.

8. 📚 Deep Dive

9. Liên hệ các bài khác

• Bài 03 — Dữ liệu, nhãn và ba tập không được trộn — hàng rào chính chặn leakage qua tiền xử lý (mục 5).
• Bài 04 — Train vs inference — vì sao lỗi này chỉ lộ khi model chạy thật (Recall đầu bài).
• Mini-challenge — đọc mô tả một hệ AI — luyện chẩn đoán đúng loại lỗi bằng bảng ở bài này.

10. Tóm tắt

• Đọc ba con số theo đúng thứ tự train/validation/production — không nhìn một con số đơn lẻ.
• Train thấp là underfit — model chưa học được gì kể cả trên dữ liệu nó đã thấy.
• Leakage có hai dạng: feature chứa thông tin chỉ có sau khi biết đáp án, hoặc tiền xử lý tính trên toàn bộ trước khi tách tập.
• Leakage nguy hiểm hơn overfitting vì qua mặt được cả validation — chỉ lộ khi chạm dữ liệu thật.

11. Tự kiểm tra

Bài tiếp theo: LLM trên bản đồ