Data Leakage và Look-ahead Bias #22

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Data Leakage xảy ra khi pipeline học hoặc kiểm định dùng thông tin không được phép có tại lúc dự báo. Look-ahead Bias là một dạng leakage theo thời gian: quyết định quá khứ vô tình nhìn thấy dữ liệu chỉ xuất hiện sau đó. Muốn kiểm sạch, mỗi feature phải chứng minh thời điểm nó khả dụng.

Đọc xong, bạn sẽ hiểu:

• Data Leakage rộng hơn Look-ahead Bias ở điểm nào.
• Vì sao timestamp của event chưa chắc là lúc hệ thống nhận được event.
• Cách điền Point-in-Time Audit Card bằng dữ liệu giả.

1. Data Leakage và Look-ahead Bias khác nhau thế nào?

a. Leakage là dữ liệu “không được phép” lọt vào

Data Leakage là rò rỉ thông tin từ ngoài phạm vi hợp lệ vào quá trình train, validation hoặc inference. Ví dụ, scaler được fit trên cả train lẫn test đã dùng thống kê của test để chuẩn hóa train. Đây là leakage dù code không gọi trực tiếp giá ngày mai.

Look-ahead Bias tập trung vào thời gian: quyết định tại thời điểm t dùng thông tin chỉ có sau t. Nó có thể lộ liễu như lấy return ngày mai làm feature, hoặc kín đáo như dùng báo cáo quý theo ngày kết thúc quý thay vì ngày báo cáo thật sự công bố.

b. Một event có ít nhất ba đồng hồ

• Event time: lúc sự kiện kinh tế hoặc thị trường xảy ra.
• Available time: lúc dữ liệu đã tới và hệ thống thực sự có thể đọc.
• Decision time: lúc model tạo signal hoặc ruleset ra quyết định.

Có thể thêm order time, lúc lệnh được gửi. Điều kiện tối thiểu là available_time ≤ decision_time ≤ order_time. Nếu chỉ có event time mà không có receipt/available time, ta chưa chứng minh feature hợp lệ.

Ví dụ, bar 10:00 đại diện khoảng 10:00:00–10:00:59 và chỉ hoàn tất lúc 10:01:00. Quyết định lúc 10:00:30 không được dùng close cuối bar ấy. MQL5 cũng lưu ý timestamp của bar cần được căn với thời điểm toàn bộ thông tin bar đã biết để tránh classic look-ahead (MQL5 — Data Leakage and Timestamp Fixes).

Hình 1 — Feature chỉ được đi qua khi available time không muộn hơn decision time.

2. Dữ liệu tương lai thường lọt vào bằng đường nào?

a. Future bar và same-bar execution

Lỗi rõ nhất là shift(-1), lấy hàng tương lai đặt cạnh hàng hiện tại. Lỗi khó hơn: tính signal bằng close của bar rồi giả định fill cũng tại chính close đó, dù trong thực tế close chỉ biết sau khi bar kết thúc. Cách an toàn thường là signal từ bar đã đóng và execution ở tick hoặc bar kế tiếp, với cost/fill hợp lý.

b. Release lag và dữ liệu bị sửa lại

Báo cáo doanh nghiệp có period_end=31/03 nhưng công bố ngày 25/04. Gắn số liệu vào 31/03 khiến gần một tháng tương lai chảy ngược. Dữ liệu CPI, GDP hoặc unemployment còn có revision: file tải hôm nay có thể chứa con số sửa sau này mà người giao dịch ngày công bố đầu tiên chưa từng thấy.

Giải pháp là dữ liệu point-in-time: lưu cả giá trị và thời điểm phiên bản đó khả dụng. Join theo “latest value known as of decision time”, không join theo ngày đẹp nhất trên báo cáo.

c. Preprocessing fit trên toàn bộ dataset

Scaler, imputer, feature selector và PCA đều có bước fit, tức học thống kê từ dữ liệu. Transform là áp dụng thống kê đã học. Fit trên toàn bộ dataset làm mean, standard deviation hoặc feature ranking của test lọt vào train.

scikit-learn khuyến nghị không gọi fit trên test và dùng Pipeline để preprocessing chỉ học từ train phù hợp (scikit-learn — Common pitfalls and recommended practices). Với time series, preprocessing phải được fit lại bên trong từng fold, không một lần trước toàn bộ WFA.

d. Split và label overlap

Random split trộn hàng mới với hàng cũ. Model có thể học từ tháng 12 rồi được “kiểm” trên tháng 3. Nếu label dùng return 5 ngày tới, sample train sát test còn chồng cửa sổ outcome với test. Cần chronological split, rồi purge/gap dựa trên prediction horizon.

e. Universe của hôm nay áp vào quá khứ

Backtest chỉ dùng cổ phiếu đang còn trong chỉ số hôm nay đã loại công ty phá sản hoặc delist khỏi lịch sử. Đây thường gọi là survivorship bias và cũng vi phạm point-in-time universe. Thành viên chỉ số, symbol mapping, corporate action và availability đều cần snapshot theo ngày.

Hình 2 — Leakage có thể xuất hiện trước model, trong split hoặc ngay tại cách mô phỏng lệnh.

3. Làm sao phát hiện một pipeline có thể bị leak?

a. Kết quả quá đẹp là chuông báo, không phải bằng chứng

Accuracy gần hoàn hảo, Sharpe bất thường, drawdown cực thấp hoặc signal đổi đúng trước mọi cú rơi là red flag. Nhưng không có ngưỡng chung để kết luận leakage. Một kết quả đẹp có thể do sample nhỏ, regime thuận lợi hoặc bug khác; một leak nhỏ cũng có thể không tạo đường vốn ngoạn mục.

b. Shift test và truncation test

Shift test: trễ feature thêm một bar hoặc một khoảng release lag. Nếu performance sụp hoàn toàn, cần kiểm timeline. Truncation test: chạy pipeline chỉ với dữ liệu tới ngày T, lưu feature tại T; sau đó thêm dữ liệu tương lai và chạy lại. Feature lịch sử tại T không nên đổi nếu pipeline causal.

Ta cũng có thể hoán đổi target, đưa timestamp giả vào, hoặc cấm tất cả cột sau decision time. Negative test tốt phải khiến performance về mức hợp lý; nếu model vẫn “thần”, có thể còn đường leak khác.

c. OOS và WFA không tự động cứu được dữ liệu bẩn

Nếu scaler fit toàn bộ dataset trước khi chia fold, cả IS và OOS đều đã nhiễm. Nếu economic series dùng phiên bản revised cho mọi ngày, WFA vẫn đi qua nhưng mỗi fold nhìn thấy dữ liệu chưa tồn tại lúc đó.

Chắc chắn: split theo thời gian là cần thiết nhưng chưa đủ. Có điều kiện: OOS, WFA, purge và paper reconciliation cùng audit availability làm bằng chứng mạnh hơn, nhưng detection không bao giờ chỉ dựa vào một test.

AWS cảnh báo dữ liệu lịch sử thường được enrich bằng cột hoặc giá trị chưa tồn tại ở một thời điểm trong quá khứ; khi deploy, đối tượng mới không có những dữ kiện ấy (AWS — Splits and data leakage).

4. Checklist xây pipeline point-in-time

a. Viết Availability Matrix

Với mỗi feature, ghi source, event_time, available_time, timezone, revision_policy, max_delay, owner. Nếu không xác định được available time, đánh trạng thái BLOCKED, không tự đoán bằng event time.

b. Làm join theo thời điểm khả dụng

1. Chuẩn hóa timezone và đồng hồ trước khi join.
2. Dùng as-of join: tại decision time chỉ lấy record mới nhất đã available.
3. Không backfill giá trị tương lai vào quá khứ.
4. Fit scaler/imputer/selector riêng trong từng train fold.
5. Lag signal trước execution; mô phỏng order time và fill time tách biệt.
6. Purge hoặc gap khi label/position horizon chồng biên split.
7. Lưu raw snapshot, data version, code hash và feature lineage.
8. Chạy truncation, shift và replay-parity test trước khi xem P&L.

Feature lineage là đường truy từ nguồn thô qua transform tới cột model. Replay parity là kiểm cùng dữ liệu tới thời điểm T thì research pipeline và runtime tạo cùng feature/signal.

c. Khi nào phải đứng ngoài?

Đứng ngoài khi vendor không cung cấp lịch sử revision, receipt timestamp bị mất, join không tái lập, current constituents bị áp cho toàn kỳ hoặc preprocessing nằm ngoài fold. Đừng vá bằng “thêm một bar lag” nếu chưa biết nguồn leak; lag ngẫu nhiên có thể che triệu chứng mà không sửa clock contract.

5. Bài tập 15 phút: Point-in-Time Audit Card

a. Dùng Google Sheets hoặc LibreOffice

Tạo sáu event giả với cột feature, event_time, available_time, decision_time, allowed, reason. Dùng cùng timezone UTC+7. Không nối API hoặc dùng dữ liệu tài khoản.

Nhập ba dòng mẫu: bar close available 10:01:00 nhưng decision 10:00:30; news release available 14:00:05 và decision 14:00:10; revised CPI chỉ available sau 30 ngày nhưng pipeline đặt vào ngày công bố đầu.

b. Mẫu tham khảo đã điền

Xem quyết định mẫu

Chọn BLOCK + REBUILD JOIN. Sửa bar signal sang bar đã đóng, dùng vintage CPI point-in-time và fit scaler bên trong từng fold. Sau đó chạy truncation test; chưa dùng tiền thật.

Hình 3 — Card không hỏi feature có “hay” không; nó hỏi feature đã tới trước quyết định chưa.

c. Điều cần lưu lại

Lưu sheet cùng timezone, data version và rule available ≤ decision. Nếu phải giả định available time, ghi rõ assumption và để trạng thái review. Kết quả sạch hơn không chứng minh edge; bài tập chỉ kiểm temporal integrity.

6. Tổng kết

a. Năm ý chính

• Data Leakage là thông tin không hợp lệ lọt vào pipeline; Look-ahead là leakage từ tương lai.
• Event time khác available time; decision chỉ được dùng feature đã available.
• Bar close, release revision, preprocessing, split và universe đều có thể leak.
• OOS/WFA không cứu được pipeline đã nhiễm trước lúc chia fold.
• Availability Matrix, as-of join, in-fold fit và negative test giúp giảm rủi ro.

b. Câu hỏi tự kiểm tra

• Vì sao event time chưa đủ chứng minh feature hợp lệ?
• Fit scaler trên toàn dataset leak bằng cách nào?
• Truncation test kiểm điều gì?
• Khi nào WFA vẫn cho kết quả bị look-ahead?

c. Gợi ý đáp án

Xem gợi ý câu 1

Vì hệ thống có thể nhận dữ liệu muộn hơn event xảy ra. Xem mục 1b.

Xem gợi ý câu 2

Mean/std của test đã ảnh hưởng cách biến đổi train. Xem mục 2c.

Xem gợi ý câu 3

Feature lịch sử tại T không được đổi khi thêm dữ liệu sau T. Xem mục 3b.

Xem gợi ý câu 4

Khi data/preprocessing đã dùng tương lai trước khi chia fold. Xem mục 3c.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• scikit-learn — Common pitfalls: data leakage
• AWS — Splits and data leakage
• MQL5 — Data Leakage and Timestamp Fixes
• NFA — Compliance Rule 2-29

Đọc lại Overfitting trong Trading, quay về AI Trading là gì, rồi học tiếp bài #23 về Sharpe, Profit Factor và Drawdown.

Chọn đúng bài trong lộ trình

Bài này tập trung vào data leakage và look-ahead bias — phân biệt leakage, bias và audit ba đồng hồ. Nếu bạn cần bức tranh chung trước khi đi sâu, hãy bắt đầu từ AI Trading là gì? Hướng dẫn từ nền tảng đến kiểm định. Các bước liên quan trực tiếp là Data trong AI Trading là gì, Overfitting trong Trading và AI Trading cho chứng khoán.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.