Dữ liệu thiếu nên được điền bỏ qua hay mô hình hóa như thế nào

Phần 1. Bối cảnh, khái niệm và cơ chế

Dữ liệu thiếu thường được trình bày như một kỹ thuật riêng lẻ, nhưng giá trị thực tế chỉ xuất hiện khi nó được đặt trong toàn bộ chuỗi quyết định đầu tư. Một kết quả thống kê đẹp không tự biến thành quyết định tốt nếu dữ liệu sai thời điểm, benchmark không phù hợp hoặc chi phí triển khai bị bỏ qua. Missing data không chỉ là vấn đề kỹ thuật; nó có thể mang thông tin về coverage, quy mô doanh nghiệp hoặc sự kiện bất thường. Điền trung bình tùy tiện có thể làm mất cơ chế hoặc tạo look-ahead. Nhìn theo cách này, chủ đề không chỉ là “công thức”, mà là bài toán thiết kế một quy trình có thể kiểm chứng. Đối với dữ liệu thiếu, giả định phải được ghi lại và có thể tái lập.

Lựa chọn nên dựa trên nguyên nhân thiếu, thời gian tồn tại của dữ liệu, mô hình sử dụng và việc missingness có dự báo được hay không. Khi đo dữ liệu thiếu, nên so sánh với một benchmark đơn giản.

Một nguyên tắc đáng giữ là mọi kết luận về dữ liệu thiếu phải có “đường đi” từ dữ liệu tới quyết định. Đường đi đó gồm nguồn dữ liệu, thời điểm dữ liệu khả dụng, phép biến đổi, quy tắc xếp hạng hoặc dự báo, cách chuyển thành vị thế và cách đo kết quả. Nếu một mắt xích không thể mô tả rõ, phần còn lại rất khó audit. Đây cũng là lý do các nhóm nghiên cứu chuyên nghiệp ưu tiên reproducibility và versioning ngay từ đầu thay vì bổ sung khi dự án đã lớn. Ở dữ liệu thiếu, độ bền quan trọng hơn một kết quả đơn lẻ.

Khía cạnh kinh tế không nên bị tách khỏi thống kê. Một quan hệ có p-value nhỏ nhưng không có cơ chế hợp lý dễ là sản phẩm của data mining; ngược lại một câu chuyện kinh tế đẹp nhưng không đứng vững ngoài mẫu cũng chưa đủ cho quyết định. Với dữ liệu thiếu, mục tiêu là để hai lớp này kiểm tra lẫn nhau: cơ chế định hướng phép thử, còn dữ liệu buộc cơ chế phải đối mặt với bằng chứng phản biện. Với dữ liệu thiếu, kết quả cần được đọc cả trước và sau chi phí.

Từ bản phát hành tháng 1/2025, thư viện Fama-French chuyển sang dữ liệu CRSP CIZ cho chuỗi lợi suất nghiên cứu của Mỹ. Trường hợp này cho thấy quản trị phiên bản dữ liệu, lịch công bố và quy tắc tái tạo biến là một phần của nghiên cứu chứ không phải công việc kỹ thuật phụ trợ. Với dữ liệu thiếu, phép kiểm tra độ nhạy là một yêu cầu bắt buộc.

Missing data trong tài chính thường mang thông tin. Một công ty không có analyst forecast có thể vì coverage thấp; doanh nghiệp mới niêm yết thiếu lịch sử vì tuổi đời ngắn; volume bằng 0 khác volume bị thiếu do feed lỗi. Nếu điền mọi ô trống bằng median, model có thể xóa mất chính sự khác biệt này. Trước khi impute cần phân loại missing do cấu trúc, do chưa tới thời điểm công bố hay do lỗi kỹ thuật.

Phần 2. Phương pháp, dữ liệu và cách triển khai

Để đo hiệu quả, không nên chỉ nhìn một chỉ số duy nhất. Với dữ liệu thiếu, một dashboard hợp lý có thể gồm coverage, missingness, freshness, error rate, duplicate rate và reproducibility. Mỗi thước đo soi một mặt khác nhau: lợi nhuận cho biết phần thưởng, drawdown cho biết đường đi của vốn, turnover và liquidity cho biết khả năng triển khai, còn stability cho biết mức phụ thuộc vào sample. Chỉ khi các chỉ số tạo thành một câu chuyện nhất quán mới nên tiến tới bước ra quyết định. Ở dữ liệu thiếu, dữ liệu đúng thời điểm là điều kiện đầu tiên.

Khi đánh giá dữ liệu thiếu, một bài kiểm tra hữu ích là thay đổi từng giả định theo hướng bất lợi nhưng hợp lý: chậm dữ liệu hơn, tăng chi phí, thu hẹp universe, đổi benchmark, đổi cửa sổ và giảm tốc độ tái cân bằng. Nếu kết quả vẫn giữ được logic và không sụp đổ hoàn toàn, độ tin cậy tăng đáng kể. Nếu hiệu quả chỉ tồn tại trong một cấu hình hẹp, điều đó không chứng minh ý tưởng vô giá trị, nhưng cho thấy cần coi nó là giả thuyết yếu thay vì edge đã xác nhận. Riêng dữ liệu thiếu, benchmark nên được xác định trước khi nhìn kết quả.

Quy trình thực hành có thể bắt đầu bằng data contract, point-in-time storage, validation test, feature pipeline và versioning. Thứ tự rất quan trọng: baseline đơn giản nên được chạy trước khi thêm độ phức tạp; chi phí nên được mô hình hóa trước khi kết luận có alpha; và holdout nên được bảo vệ trước khi tuning. Cách làm này giảm nguy cơ một mô hình “tốt dần” chỉ vì nhà nghiên cứu đã nhìn quá nhiều vào cùng một giai đoạn lịch sử. Khi mỗi thay đổi đều có lý do và được ghi lại, kết quả cuối dễ tin cậy hơn. Với dữ liệu thiếu, kết quả ngoài mẫu quan trọng hơn độ đẹp trong mẫu.

Trong triển khai dữ liệu thiếu, trade-off quan trọng thường nằm giữa độ nhạy và độ bền. Hệ thống phản ứng nhanh có thể bắt tín hiệu sớm nhưng chịu turnover, noise và cost cao hơn; hệ thống chậm ổn định hơn nhưng có thể bỏ lỡ cơ hội. Không có lựa chọn tối ưu chung. Thiết kế nên xuất phát từ decay của tín hiệu, liquidity của tài sản, capacity, latency cần thiết và khả năng giám sát của tổ chức. Trong dữ liệu thiếu, chi phí và giới hạn triển khai cần được tính cùng.

Khi dữ liệu hoặc thị trường thay đổi quanh dữ liệu thiếu, việc “retrain” hay “reoptimize” không nên diễn ra tự động chỉ vì hiệu suất giảm. Trước hết cần phân rã nguyên nhân: data issue, execution issue, exposure shift, regime change hay edge decay. Mỗi nguyên nhân đòi một hành động khác. Nếu mọi drawdown đều dẫn đến đổi tham số, quy trình sẽ biến thành overfitting trực tiếp trên dữ liệu sống. Bởi vậy, dữ liệu thiếu cần được đánh giá trong cùng một pipeline nhất quán.

Ví dụ cho dữ liệu thiếu nên được xây theo nguyên tắc “nhỏ nhưng audit được”. Thay vì bắt đầu bằng hàng nghìn tài sản và hàng trăm biến, có thể chọn một universe đủ thanh khoản, một horizon rõ ràng và một benchmark đơn giản. Sau đó mô tả từng bước từ dữ liệu đến kết quả. Khi pipeline đã đúng, mới mở rộng universe hoặc model. Cách phát triển này làm giảm số nguồn lỗi đồng thời và giúp biết chính xác bước nào thực sự tạo thêm giá trị. Ở cấp triển khai, dữ liệu thiếu cần ngưỡng kiểm soát rõ ràng.

Ở góc độ ứng dụng, nội dung đáng tập trung là làm rõ chủ đề dữ liệu thiếu nên được điền bỏ qua hay mô hình hóa như thế nào bằng khái niệm, dữ liệu và ví dụ có thể kiểm chứng. Phần ví dụ chỉ nên dùng số liệu có nguồn và ghi rõ thời điểm quan sát. Với nhóm độc giả data analyst, quant researcher, kỹ sư dữ liệu và sinh viên FinTech, cách trình bày hiệu quả là giải thích cơ chế trước, sau đó mới đưa chỉ số và phép kiểm định để người đọc có thể tự đánh giá giả định.

Checklist thực hành ngắn:

·         Xác nhận dữ liệu và timestamp phù hợp với quyết định về dữ liệu thiếu.

·         So sánh với một benchmark đơn giản trước khi thêm độ phức tạp.

·         Đánh giá tối thiểu các nhóm chỉ số: coverage, missingness, freshness, error rate, duplicate rate và reproducibility.

·         Chạy kiểm tra độ nhạy với chi phí, lag, universe và tham số.

·         Ghi rõ điều kiện khiến kết luận về financial data không còn hợp lệ.

Thực hành nên tạo missingness indicator khi nguyên nhân có thể mang tín hiệu, sau đó chọn phương pháp theo feature. Cross-sectional accounting ratio có thể dùng industry median nếu hợp lý; time series không nên forward-fill vô hạn vì biến đã stale. Với ML, tree model xử lý missing theo cách riêng nhưng vẫn cần kiểm soát timestamp. Nên chạy sensitivity: drop, median impute, model-based impute và so OOS. Quan trọng là fit imputer chỉ trên training data, nếu dùng toàn sample sẽ tạo leakage.

Phần 3. Rủi ro, kiểm soát và cách áp dụng

Với dữ liệu thiếu, một sai lầm khác là xem sự phức tạp như bằng chứng chuyên môn. Trong tài chính, càng nhiều tham số và tầng xử lý thì càng có nhiều nơi để leakage, bug hoặc assumption ẩn đi. Phức tạp chỉ hợp lý khi nó tạo cải thiện ngoài mẫu ổn định và có thể giải thích được nguồn cải thiện. Nếu benchmark đơn giản đạt kết quả tương đương sau chi phí, lựa chọn đơn giản thường có lợi hơn về vận hành và quản trị rủi ro. Đối với dữ liệu thiếu, giả định phải được ghi lại và có thể tái lập.

Tính minh bạch giúp kiểm soát hai loại sai lệch: sai lệch của dữ liệu và sai lệch của con người. Khi giả định, phiên bản và quyết định được ghi lại, nhóm nghiên cứu khó vô thức thay đổi tiêu chuẩn đánh giá sau khi nhìn kết quả. Điều này đặc biệt quan trọng với dữ liệu thiếu, nơi một thay đổi nhỏ về lag, universe hoặc cost có thể làm kết luận đảo chiều. Khi đo dữ liệu thiếu, nên so sánh với một benchmark đơn giản.

Những rủi ro cần theo dõi gồm look-ahead, survivorship, leakage, corporate-action error và silent schema drift. Điểm chung của chúng là có thể không xuất hiện trong giai đoạn bình thường và chỉ lộ ra khi thị trường căng thẳng hoặc khi hệ thống mở rộng quy mô. Vì vậy, kiểm soát tốt phải được thiết kế trước sự cố: limit, alert, fallback, audit log và người chịu trách nhiệm. Sau sự cố, post-mortem nên tập trung vào cải thiện hệ thống thay vì chỉ tìm lỗi cá nhân. Ở dữ liệu thiếu, độ bền quan trọng hơn một kết quả đơn lẻ.

Khi theo dõi dữ liệu thiếu, review định kỳ nên tách performance review khỏi research review. Performance review hỏi chiến lược đang lời hay lỗ và vì sao; research review hỏi bằng chứng cho cơ chế có thay đổi hay không. Nếu hai việc bị trộn, một tháng thua lỗ có thể khiến nhóm bỏ ý tưởng tốt, còn một tháng thắng có thể che dữ liệu lỗi. Kỷ luật tách hai lớp giúp quyết định ít bị ảnh hưởng bởi recency bias. Với dữ liệu thiếu, kết quả cần được đọc cả trước và sau chi phí.

Với dữ liệu thiếu, một tổ chức có thể nâng chất lượng bằng cách dùng checklist thống nhất cho mọi nghiên cứu: nguồn dữ liệu, point-in-time, benchmark, cost, OOS, robustness, risk và owner. Checklist không thay tư duy chuyên môn, nhưng ngăn các lỗi cơ bản lặp lại. Quan trọng hơn, nó tạo ngôn ngữ chung giữa research, engineering, risk và người ra quyết định. Với dữ liệu thiếu, phép kiểm tra độ nhạy là một yêu cầu bắt buộc.

Để đưa dữ liệu thiếu vào vận hành, nên xác định rõ “điều kiện sử dụng”. Điều kiện có thể gồm mức thanh khoản tối thiểu, data freshness, giới hạn exposure, trạng thái thị trường hoặc độ tin cậy của model. Khi điều kiện không thỏa, hệ thống có thể giảm quy mô, chuyển sang fallback hoặc dừng. Cách thiết kế theo trạng thái giúp tránh việc một mô hình được dùng ngoài phạm vi mà ban đầu nó được kiểm định. Ở dữ liệu thiếu, dữ liệu đúng thời điểm là điều kiện đầu tiên.

Kết luận quan trọng không phải rằng dữ liệu thiếu luôn đúng hay luôn hiệu quả. Điều đáng giữ là một cách đánh giá có kỷ luật: hỏi cơ chế gì tạo kết quả, dữ liệu nào chứng minh, kết quả có sống ngoài mẫu và sau chi phí hay không, và điều gì sẽ khiến quan điểm phải thay đổi. Khi các câu hỏi này được trả lời rõ, quyết định đầu tư trở nên minh bạch hơn và ít phụ thuộc vào cảm giác. Ở dữ liệu thiếu, độ bền quan trọng hơn một kết quả đơn lẻ.

Một rule hữu ích là đặt freshness limit. Ví dụ dữ liệu fundamental quá X ngày không được dùng như dữ liệu mới mà phải gắn age feature hoặc loại. Nếu tỷ lệ missing đột ngột tăng trong production, đó có thể là data incident chứ không phải thay đổi thị trường; alert nên kích hoạt trước model. Báo cáo cần công bố coverage theo thời gian và nhóm cổ phiếu, vì strategy có thể “tốt” chỉ trên subset có dữ liệu đầy đủ. Không xử lý missing cũng là một assumption và phải được audit như mọi transformation khác.