Liệu AI có thể phát hiện rò rỉ dữ liệu trước khi mô hình đạt độ chính xác 99%?

--> Liệu AI có thể phát hiện rò rỉ dữ liệu trước khi mô hình đạt độ chính xác 99%? - KDnuggets --> Blog Bài viết hàng đầu Giới thiệu Chủ đề AI Lời khuyên nghề nghiệp Thị giác máy tính (Computer Vision) Kỹ thuật dữ liệu (Data Engineering) Khoa học dữ liệu (Data Science) Mô hình ngôn ngữ Học máy (Machine Learning) MLOps Xử lý ngôn ngữ tự nhiên (NLP) Lập trình Python SQL Bộ dữ liệu Sự kiện Tài nguyên Tài liệu tóm tắt (Cheat Sheets) Đề xuất Bản tin công nghệ Quảng cáo Đăng ký nhận bản tin Liệu AI có thể phát hiện rò rỉ dữ liệu trước khi mô hình đạt độ chính xác 99%? Bốn trường hợp rò rỉ kinh điển, được lồng ghép vào dữ liệu thực tế, thử nghiệm độc lập trên bốn mô hình. Tác giả Nate Rosidi, Chuyên viên phân tích xu hướng thị trường & nội dung SQL của KDnuggets, ngày 9/11/2026 trong chuyên mục Machine Learning --> Bất kỳ chuyên gia khoa học dữ liệu nào cũng từng trải qua cảm giác: một mô hình đạt độ chính xác 99%, nhưng thay vì ăn mừng, sự hoài nghi lại xuất hiện. Trong phần lớn trường hợp, nguyên nhân là hiện tượng rò rỉ dữ liệu (data leakage): một số thông tin trong tập dữ liệu huấn luyện trên thực tế sẽ không khả dụng tại thời điểm dự đoán. Thực nghiệm này hướng tới hai con số cụ thể. Thứ nhất, mức độ tăng vọt về độ chính xác trên dữ liệu thực tế lớn đến mức nào, thay vì chỉ là ví dụ mô phỏng? Thứ hai, nếu quy trình xử lý dữ liệu (pipeline) được mô tả cho một mô hình AI trước khi vận hành và không đưa ra bất kỳ gợi ý nào về sai sót, liệu mô hình đó có phát hiện được sự rò rỉ và kết quả có thay đổi tùy theo từng mô hình được thử nghiệm hay không? Do đó, nhóm nghiên cứu đã chọn bốn dự án dữ liệu thực tế, lồng ghép vào mỗi dự án một dạng rò rỉ dữ liệu phổ biến khác nhau, huấn luyện một mô hình thực tế trong cả hai trường hợp có và không có rò rỉ, sau đó ghi nhận các số liệu thực tế. Tiếp theo, trong một quy trình riêng biệt, từng pipeline được mô tả bằng thuật ngữ thông thường để yêu cầu bốn mô hình Claude, từ phiên bản có tốc độ nhanh nhất đến phiên bản có năng lực mạnh nhất, chỉ ra các điểm bất thường cần lưu ý trước khi có thể tin cậy kết quả. Thiết lập thực nghiệm Mỗi dạng rò rỉ xâm nhập vào pipeline theo một cách khác nhau: một đặc trưng xác định nhãn theo cách cơ học, một đặc trưng được xây dựng bằng thông tin tương lai, việc phân chia dữ liệu bỏ qua cấu trúc quan hệ, và một bước tiền xử lý được thực hiện sai thứ tự. Về phía các mô hình AI, các thử nghiệm được thực hiện trên Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5 và Claude Fable 5.1, bao quát các dải tốc độ và năng lực hiện có. Các mô hình được nêu đích danh trong thử nghiệm và không mang tính so sánh chéo giữa các nhà cung cấp khác nhau, do đây không phải là mục tiêu của nghiên cứu. Mỗi mô hình được vận hành trong một phiên làm việc độc lập, hoàn toàn không lưu lại dữ liệu từ các phiên khác, chỉ tiếp nhận mô tả đóng về pipeline, các đặc trưng hoặc mã nguồn, và không có quyền thực thi chương trình. Không có mô hình nào được báo trước về sự tồn tại của lỗi rò rỉ dữ liệu. Trường hợp 1: Đặc trưng mang sẵn câu trả lời Trong trường hợp này, các tập dữ liệu từ dự án Dự đoán xu hướng giá cổ phiếu (Prediction of Stock Price Direction) đã được sử dụng. Nhiệm vụ: dự đoán giá đóng cửa của cổ phiếu Amazon có cao hơn giá mở cửa trong cùng ngày hay không. Tại đây, Nhãn (Label) nhận giá trị 1 nếu giá Đóng cửa (Close) cao hơn giá Mở cửa (Open), và nhận giá trị 0 trong trường hợp ngược lại. Dưới đây là một mẫu trích từ một trong các tập dữ liệu, trường hợp này là tệp AMZN_train.csv: So sánh hiệu suất giữa trường hợp có và không có rò rỉ dữ liệu Khi cung cấp cho mô hình giá Close và Close điều chỉnh (Adj Close) của cùng ngày đó bên cạnh các biến Open, High, Low và Volume, độ chính xác xác thực đạt 97,0%, với diện tích dưới đường cong ROC (AUC) đạt 0,999. Khi giới hạn mô hình chỉ sử dụng giá mở cửa, giá cao nhất, giá thấp nhất, giá đóng cửa và khối lượng giao dịch của ngày hôm trước — hoàn toàn không có dữ liệu của ngày cần dự đoán — độ chính xác giảm xuống 51,6%, AUC đạt 0,476: tương đương với xác suất ngẫu nhiên. Sự chênh lệch giữa 97% và 52% là minh chứng rõ nét cho toàn bộ vấn đề được đề cập. Đánh giá khả năng phát hiện của AI Cả bốn mô hình đều phát hiện vấn đề ngay lập tức và đưa ra lý do chính xác: giá Close chính là yếu tố xác định nhãn dự đoán. Phiên bản Haiku mô tả đây là mối quan hệ "vòng lặp luẩn quẩn" (circular). Sonnet cho biết mô hình "có thể tái tạo lại nhãn mục tiêu chỉ bằng một phép so sánh duy nhất". Opus thậm chí còn chỉ ra rõ hơn mà không cần gợi ý: "nếu High bằng Open, phiên giao dịch trong ngày chưa từng vượt qua giá mở cửa, do đó nhãn chắc chắn phải là 0". Mô hình này cũng tự đưa ra dự báo trung thực rằng, một mô hình chuẩn mực chỉ nên đạt "độ chính xác ở mức hơn 50% một chút", con số gần như trùng khớp với kết quả thu được từ lượt chạy thử nghiệm với dữ liệu sạch. Trường hợp 2: Bộ dữ liệu đã bộc lộ sẵn kết quả Đối với trường hợp này, nhóm nghiên cứu sử dụng các bộ dữ liệu từ dự án Delivery Duration Prediction (Dự đoán thời gian giao hàng). Cụ thể, một tập hợp con từ tập dữ liệu mang tên historical_data.csv đã được đưa vào sử dụng. Nhiệm vụ đặt ra: dự đoán duration_sec, khoảng thời gian tính bằng giây từ lúc đơn hàng được tạo đến khi giao hàng thành công, được xác định bằng actual_delivery_time trừ đi created_at. Tệp historical_data.csv của DoorDash ghi nhận 197.428 đơn hàng, mỗi hàng tương ứng một đơn, gồm 16 cột. Biến mục tiêu là duration_sec: actual_delivery_time trừ đi created_at, tức số giây từ khi đơn hàng được đặt cho đến lúc được giao đến nơi. Các cột dữ liệu mô hình thực tế đã xử lý: Các trường market_id, store_primary_category và order_protocol—lần lượt là khu vực, danh mục nhà hàng và kênh đặt hàng—đã được loại bỏ. Điều này không phải vì chúng vô giá trị, mà bởi việc mã hóa 74 danh mục nhà hàng khác nhau không liên quan đến lỗi rò rỉ dữ liệu đang được kiểm tra. Một đặc trưng kỹ thuật (engineered feature) đã được bổ sung là thời gian giao hàng trung bình của mỗi cửa hàng, được tính toán theo hai phương pháp: # leaked: uses every row, including the ones about to be scored store_avg = df.groupby("store_id")["duration_sec"].transform("mean") df_shuffled = df.sample(frac=1.0) # random split on timestamped data # clean: only training-period orders, then a chronological split store_avg = train.groupby("store_id")["duration_sec"].mean() train["store_avg"] = train["store_id"].map(store_avg) test["store_avg"] = test["store_id"].map(store_avg) Đặc trưng kỹ thuật duy nhất này lại mang theo hai lỗi rò rỉ dữ liệu độc lập. Thứ nhất: store_avg được tạo ra bằng cách gom nhóm toàn bộ bảng—gồm cả các hàng của tập huấn luyện (train) và tập kiểm thử (test)—theo store_id rồi tính giá trị trung bình của duration_sec, chính là đối tượng cần dự đoán, sau đó sao chép giá trị trung bình này vào từng hàng dữ liệu. Đối với một cửa hàng chỉ có số lượng đơn hàng ít ỏi, giá trị trung bình sẽ rất gần với duration_sec của chính hàng đó, khiến mô hình thực tế đang đọc một bản sao đã được làm phẳng của đáp án. Thứ hai: created_at là mốc thời gian (timestamp), do đó bảng dữ liệu này vốn có trật tự thời gian cố định. Việc xáo trộn ngẫu nhiên trước khi phân chia theo tỷ lệ 80/20 đã khiến các hàng trong tập huấn luyện có thời gian xảy ra sau các hàng trong tập kiểm thử. Trên thực tế, một mô hình vận hành chỉ có thể tiếp cận những đơn hàng được đặt trước thời điểm cần đưa ra dự đoán. So sánh hiệu suất giữa mô hình rò rỉ dữ liệu và mô hình chuẩn Cả hai phiên bản đều được đánh giá bằng sai số toàn phương trung bình (RMSE), tính theo đơn vị giây, cùng đơn vị với duration_sec. Kết quả cho thấy