DHDataHọc
Lý thuyếtBài 6/85 phút đọc+10 XP

Rò rỉ dữ liệu

Bạn sẽ học được

  • Sáu loại rò rỉ dữ liệu thường gặp.
  • Cách phát hiện rò rỉ qua điểm bất thường.
  • Vì sao rò rỉ chỉ lộ ra khi triển khai.
  • Quy trình kiểm tra trước khi báo cáo kết quả.
  • Cách sửa từng loại rò rỉ.

Khái niệm cốt lõi

Rò rỉ dữ liệu là khi mô hình được tiếp xúc với thông tin mà lúc dự đoán thật nó sẽ không có.

Mô hình không "gian lận" — nó chỉ học đúng thứ được đưa vào. Vấn đề là thứ đó không tồn tại trong production.

code
Điểm validation 0,98  →  triển khai  →  thực tế 0,62

Khoảng cách đó gần như luôn là rò rỉ.

Sáu loại rò rỉ

LoạiVí dụDấu hiệu
Rò rỉ nhãnCột cancel_date khi dự đoán huỷMột đặc trưng áp đảo
Ô nhiễm train-testChuẩn hoá trước khi chiaĐiểm CV cao hơn test
Rò rỉ thời gianChia ngẫu nhiên dữ liệu chuỗiĐiểm test rất cao
Rò rỉ nhómCùng khách ở train và testĐiểm cao bất thường
Dòng trùngBản ghi lặp ở hai tậpTest gần như train
Rò rỉ gián tiếpcustomer_id tương quan với nhãnID có trọng số lớn

Rò rỉ nhãn

Ví dụ rõ nhất: dự đoán khách huỷ, nhưng đặc trưng gồm cancel_date hoặc refund_after_cancel.

code
print(df.groupby(df["cancel_date"].notna())["churned"].mean())

Kết quả:

code
cancel_date
False    0.00
True     1.00

Một đặc trưng dự đoán hoàn hảo. Không phải vì mô hình giỏi, mà vì thông tin đó chỉ tồn tại sau khi khách đã huỷ.

Cách sửa: xác định thời điểm dự đoán, rồi loại mọi cột được tạo sau thời điểm đó.

Ô nhiễm train-test

code
# Sai
scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)
X_train, X_test = train_test_split(X_scaled)

# Đúng
model = Pipeline([("scale", StandardScaler()), ("clf", LogisticRegression())])
model.fit(X_train, y_train)

Lỗi này thường nhỏ và khó thấy, nhưng với tập dữ liệu nhỏ hoặc nhiều đặc trưng, nó làm điểm lạc quan rõ rệt. Cách phòng: luôn dùng Pipeline.

Rò rỉ thời gian

Dữ liệu tháng 1–12, chia ngẫu nhiên 80/20. Mô hình học từ tháng 11 để dự đoán tháng 3 — dùng tương lai dự đoán quá khứ.

Cách sửa: chia theo mốc thời gian, train luôn trước validation và test.

Với dự báo theo thời gian, còn cần kiểm tra các đặc trưng dạng cửa sổ trượt: giá trị trung bình 30 ngày tại thời điểm t chỉ được dùng dữ liệu đến t, không dùng t+1.

Rò rỉ nhóm

code
overlap = set(train["customer_id"]) & set(test["customer_id"])
print("Khách xuất hiện ở cả hai tập:", len(overlap))

Nếu con số lớn hơn 0 với dữ liệu nhiều dòng mỗi khách, phải chia theo nhóm:

code
from sklearn.model_selection import GroupShuffleSplit

splitter = GroupShuffleSplit(n_splits=1, test_size=0.2, random_state=42)
train_idx, test_idx = next(splitter.split(X, y, groups=df["customer_id"]))

Dòng trùng

code
dups = df.duplicated(subset=["customer_id", "event_date"], keep=False)
print("Số dòng trùng:", dups.sum())

Xử lý trước khi chia. Nếu không, cùng một quan sát có thể rơi vào cả train và test.

Rò rỉ gián tiếp qua ID

customer_id thường không mang thông tin thật, nhưng nếu dữ liệu được tạo hoặc sắp xếp theo thời gian, ID có thể tương quan với nhãn. Mô hình sẽ học ID thay vì tín hiệu.

Cách phòng: loại mọi cột định danh khỏi đặc trưng, trừ khi ID thật sự có ý nghĩa dự báo và có sẵn lúc dự đoán.

Quy trình kiểm tra

Trước khi báo cáo bất kỳ kết quả nào:

  1. Liệt kê thời điểm dự đoán và xác nhận từng đặc trưng có sẵn tại thời điểm đó.
  2. Kiểm tra điểm bất thường. Validation AUC trên 0,95 với dữ liệu hành vi thường là dấu hiệu xấu.
  3. Kiểm tra đặc trưng áp đảo. Nếu một đặc trưng chiếm phần lớn độ quan trọng, xem nó có hợp lệ không.
  4. Kiểm tra trùng lặp và giao nhau giữa các tập.
  5. Kiểm tra pipeline để chắc tiền xử lý nằm trong đó.
  6. So sánh với một mô hình chỉ dùng đặc trưng an toàn. Nếu chênh lệch lớn, tìm đặc trưng gây ra.

Lỗi thường gặp

  • Tin vào điểm validation quá cao: không kiểm tra nguồn gốc đặc trưng.
  • Chuẩn hoá trước khi chia: ô nhiễm.
  • Chia ngẫu nhiên dữ liệu thời gian: rò rỉ tương lai.
  • Giữ customer_id làm đặc trưng: học ID.
  • Không khử trùng lặp: cùng dòng ở hai tập.
  • Chỉ kiểm tra sau khi triển khai: phát hiện muộn và tốn kém.

Thực hành

  1. Tìm một đặc trưng rò rỉ nhãn trong bộ dữ liệu mẫu.
  2. Kiểm tra giao nhau của customer_id giữa train và test.
  3. Đếm dòng trùng theo khách và ngày.
  4. So sánh điểm khi chuẩn hoá trước và sau khi chia.
  5. Viết danh sách kiểm tra sáu bước cho dự án của bạn.

Lỗi thường gặp

Triệu chứngNguyên nhânCách sửa
Validation 0,99Rò rỉ nhãnLoại cột tương lai
Test tốt, production kémNhiều loại rò rỉKiểm tra sáu bước
CV cao hơn testTiền xử lý ngoài pipelineDùng Pipeline
ID có trọng số lớnRò rỉ gián tiếpBỏ cột định danh
Điểm giảm khi bỏ một cộtCột đó gây rò rỉKiểm tra nguồn gốc

Tóm tắt

  • Rò rỉ là mô hình thấy thông tin không có lúc dự đoán.
  • Sáu loại: nhãn, ô nhiễm, thời gian, nhóm, trùng lặp, gián tiếp.
  • Điểm validation quá cao là dấu hiệu cảnh báo, không phải thành tích.
  • Pipeline loại bỏ phần lớn ô nhiễm train-test.
  • Kiểm tra trước khi báo cáo, không chờ đến khi triển khai.

Dùng ← → để chuyển bài