Overfitting là gì?

Overfitting xảy ra khi một mô hình nắm bắt các mẫu hoặc nhiễu mà trên dữ liệu huấn luyện hoạt động quá tốt nhưng không thể tổng quát hoá cho các ví dụ mới. Một mô hình overfit có thể có lỗi huấn luyện rất thấp trong khi hiệu suất trên tập validation hoặc thực tế lại kém đáng kể.

Vấn đề ngược lại là underfitting: mô hình hoặc quá trình huấn luyện không thể nắm bắt đủ tín hiệu ngay cả trên tập huấn luyện. Việc mô hình hoá tốt cần cân bằng giữa độ phù hợp và khả năng tổng quát hoá thay vì chỉ theo đuổi hiệu suất huấn luyện hoàn hảo.

Những điểm chính

• Hiệu suất huấn luyện riêng lẻ không thể chẩn đoán khả năng tổng quát hoá.
• Dừng sớm nên dựa trên hành vi của validation, không bao giờ đưa ra quyết định lặp lại trên tập test cuối cùng.
• Thêm dữ liệu có thể giúp, nhưng thêm nhiều đặc trưng hoặc tăng khả năng mô hình cũng có thể làm tăng overfitting.
• Regularization, augmentation, cross-validation, ngăn ngừa rò rỉ dữ liệu, và đánh giá phù hợp giải quyết các nguyên nhân khác nhau.

Phù hợp, underfitting và overfitting

Một mô hình underfit khi các giả định của nó quá hạn chế, các đặc trưng bỏ qua tín hiệu quan trọng, tối ưu hoá không đủ, hoặc quá trình huấn luyện không đầy đủ. Thêm các đặc trưng hoặc khả năng phù hợp liên quan có thể giúp, nhưng việc chỉ thêm các đặc trưng tùy ý có thể làm tăng nhiễu và gây overfitting.

Một mô hình overfit khi khả năng thực tế của nó quá cao so với lượng thông tin trong dữ liệu huấn luyện. Các ví dụ bao gồm một cây decision tree sâu tạo ra các lá rất nhỏ, một đa thức theo dõi các biến động ngẫu nhiên, hoặc một mạng nơ-ron ghi nhớ các ví dụ.

Vai trò của dữ liệu huấn luyện, validation và test

• Dữ liệu huấn luyện dùng để ước lượng các tham số mô hình.
• Dữ liệu validation dùng để chọn kiến trúc, siêu tham số, ngưỡng và thời điểm dừng.
• Dữ liệu test cung cấp ước lượng cuối cùng sau khi các lựa chọn đã hoàn tất.

Nếu tập test liên tục được dùng để hướng dẫn quyết định, nó sẽ trở thành một phần của quá trình phát triển và không còn cung cấp ước lượng cuối cùng không thiên lệch. Cross-validation có thể sử dụng dữ liệu hạn chế một cách hiệu quả hơn, nhưng mọi tiền xử lý và lựa chọn đặc trưng phải được thực hiện bên trong mỗi fold huấn luyện.

Dừng sớm

Trong quá trình huấn luyện, loss trên tập huấn luyện thường tiếp tục giảm. Loss trên tập validation có thể giảm ban đầu rồi sau đó tăng lên khi mô hình quá chuyên biệt vào nhiễu của dữ liệu huấn luyện. Dừng sớm lưu checkpoint có mục tiêu validation tốt nhất hoặc dừng lại sau khi validation không cải thiện trong một khoảng thời gian kiên nhẫn xác định.

Checkpoint đúng không phải là checkpoint có loss huấn luyện thấp nhất. Một tập test cuối cùng riêng biệt sẽ được đánh giá sau khi dừng sớm và các quyết định tinh chỉnh đã hoàn tất.

Phương pháp Regularization

Phạt trọng số

Regularization L2 hoặc weight decay ngăn chặn các giá trị tham số quá lớn. Regularization L1 có thể khuyến khích các hệ số thưa. Tác động của chúng phụ thuộc vào mô hình và bộ tối ưu; ví dụ, AdamW tách weight decay khỏi cập nhật thích nghi.

Dropout và regularization ngẫu nhiên

Dropout ngẫu nhiên ẩn một phần các activation trong quá trình huấn luyện. Các phương pháp khác loại bỏ các đường đi, làm nhiễu đặc trưng, hoặc làm mịn nhãn. Những kỹ thuật này thay đổi mục tiêu huấn luyện và phải được tắt hoặc xử lý thích hợp khi suy diễn.

Tăng cường dữ liệu

Tăng cường tạo ra các biến thể thực tế—như cắt ảnh, xoay, nhiễu, hoặc diễn lại—mà vẫn giữ nguyên mục tiêu. Các biến đổi không hợp lệ có thể thay đổi nhãn và gây hại cho mô hình. Đối với thị giác máy tính, các công cụ như Albumentations hỗ trợ triển khai các pipeline kiểm soát.

Kiểm soát khả năng

Cây nông hơn, ít tham số hơn, lựa chọn đặc trưng, pruning, và các lớp giả thuyết đơn giản hơn có thể giảm phương sai. Pruning cây được thực hiện dựa trên tiêu chí, không phải là việc loại bỏ ngẫu nhiên các chi tiết đã học.

Rò rỉ dữ liệu có thể trông giống như hiệu suất xuất sắc

Rò rỉ xảy ra khi thông tin không có sẵn tại thời điểm dự đoán được đưa vào quá trình huấn luyện hoặc đánh giá. Các ví dụ phổ biến bao gồm chuẩn hoá dựa trên toàn bộ dữ liệu, chia các bản ghi lặp lại qua các fold, sử dụng dữ liệu tương lai để dự đoán quá khứ, hoặc bao gồm một đặc trưng được suy ra từ mục tiêu.

Rò rỉ không phải là overfitting thông thường, nhưng nó tạo ra khoảng cách gây hiểu lầm tương tự giữa kết quả offline và triển khai. Chiến lược chia dữ liệu cần tôn trọng thời gian, danh tính, vị trí và quy trình tạo dữ liệu.

Độ dịch phân phối là một vấn đề riêng

Một mô hình có thể tổng quát hoá với phân phối test của nó nhưng vẫn thất bại khi dữ liệu sản xuất thay đổi. Các thiết bị mới, chính sách, dân số, mùa vụ hoặc hành vi đối kháng có thể làm thay đổi mối quan hệ giữa đầu vào và mục tiêu. Việc giám sát và đánh giá lại định kỳ là cần thiết ngay cả khi mô hình gốc không bị overfit.

Chẩn đoán overfitting

Sử dụng learning curves, phương sai cross‑validation, các chỉ số nhóm phụ, calibration và kiểm tra lỗi. Nếu cả hiệu suất huấn luyện và validation đều kém, hãy tập trung vào underfitting, đặc trưng, nhãn hoặc tối ưu hoá. Nếu hiệu suất huấn luyện mạnh nhưng validation yếu, hãy điều tra khả năng, rò rỉ, regularization và tính đại diện trước khi chỉ đơn thuần thu thập thêm dữ liệu.

Tại sao overfitting xảy ra và cách phát hiện

Overfitting xảy ra khi một mô hình học các mẫu giảm lỗi huấn luyện nhưng không tổng quát hoá cho quần thể mục tiêu. Nguyên nhân bao gồm khả năng quá cao so với dữ liệu thực tế, nhiễu nhãn, các thực thể lặp lại, lựa chọn đặc trưng linh hoạt, rò rỉ dữ liệu, và tinh chỉnh trên cùng một tập validation. Khoảng cách ngày càng rộng giữa hiệu suất huấn luyện và validation là bằng chứng phổ biến, nhưng một khoảng cách nhỏ không loại trừ overfitting nếu cả hai tập đều bị ô nhiễm hoặc khác với môi trường triển khai. Learning curves qua khối lượng dữ liệu và khả năng giúp phân biệt phương sai và độ lệch.

Rò rỉ đặc biệt gây hiểu lầm: thông tin tương lai, bản sao, chồng lấn đối tượng, tiền xử lý được áp dụng trên toàn bộ dữ liệu, hoặc nhãn được mã hoá trong metadata có thể tạo ra các điểm số giữ lại xuất sắc. Chia dữ liệu theo đơn vị sẽ mới khi triển khai—bệnh nhân, khách hàng, máy móc, vị trí hoặc thời gian—trước khi áp dụng các biến đổi hoặc tăng cường. Giữ một tập test cuối cùng kín khi lựa chọn đặc trưng, kiến trúc và ngưỡng. Nếu các nhóm liên tục kiểm tra kết quả test, tập test sẽ trở thành một tập validation khác và cần được thay thế hoặc sửa chữa chính thức.

Regularization, lựa chọn mô hình và drift trong sản xuất

Giảm overfitting bằng cách sử dụng dữ liệu đại diện hơn, giảm khả năng, weight decay, dropout, dừng sớm, tăng cường, ensemble, hoặc các ràng buộc phản ánh cấu trúc miền. Mỗi phương pháp đều có nhược điểm: tăng cường có thể làm biến dạng nhãn, dropout thay đổi quá trình tối ưu, và ensemble làm tăng chi phí phục vụ. Cross‑validation ước tính sự biến đổi trong lựa chọn, nhưng các fold nhóm hoặc có nhận thức thời gian phải bảo toàn ranh giới triển khai. So sánh với một mô hình đơn giản và báo cáo độ không chắc chắn qua các fold hoặc seed thay vì chỉ chọn chạy có kết quả tốt nhất.

Sản xuất có thể bộc lộ một dạng thất bại tổng quát hoá khác khi đầu vào, người dùng, động cơ hoặc cách đo lường thay đổi. Giám sát phân phối đặc trưng và dự đoán, calibration, kết quả nhóm phụ, và ground truth bị trễ. Không tự động huấn luyện lại dựa trên phản hồi chưa được xem xét; quyết định của mô hình có thể định hình các nhãn mà nó sau này nhận được. Chẩn đoán xem thất bại xuất phát từ drift, pipeline dữ liệu, thay đổi chính sách, hay mục tiêu không hợp lệ. Overfitting được kiểm soát bằng thiết kế thí nghiệm và kỷ luật vòng đời, không phải bằng một cài đặt regularization duy nhất.

Ví dụ thực tế: loại bỏ rò rỉ trong mô hình gian lận

Một bộ phân loại gian lận ban đầu đạt điểm rất cao vì các sự kiện thẻ và merchant lặp lại xuất hiện ngẫu nhiên trong các dòng train và test, và thông tin chargeback được ghi lại sau vài tuần lại được đưa vào như một đặc trưng. Nhóm thực hiện tái cấu trúc thời gian khả dụng của mỗi đặc trưng, loại bỏ các trường sau quyết định, nhóm theo tài khoản, và sử dụng cách chia thời gian tiến phía trước. Hiệu suất giảm mạnh nhưng hiện ước tính quyết định thực tế. Một baseline quy tắc đơn giản và learning curves hướng dẫn độ phức tạp mô hình cần thiết.

Regularization và dừng sớm được tinh chỉnh chỉ trong các fold lịch sử. Đánh giá cuối cùng báo cáo precision tại mức độ xem xét, recall, calibration, và chi phí theo loại gian lận và phân khúc khách hàng. Trong sản xuất, các nhãn đã xác nhận đến muộn và bị thiên lệch bởi các giao dịch đã được xem xét, vì vậy việc giám sát tách rời drift của điểm số khỏi ước tính kết quả. Việc huấn luyện lại sử dụng các trường hợp đã được xét xử và chạy lại theo chính sách hiện tại. Dự án ưu tiên một điểm số trung thực thấp hơn so với một điểm số rò rỉ cao không thể tồn tại trong triển khai.

Bằng chứng triển khai và sẵn sàng vận hành

Một quyết định sản xuất cần nhiều hơn một buổi trình diễn thành công. Xác định người dùng mục tiêu, môi trường vận hành, đầu vào, đầu ra, các phụ thuộc, người sở hữu, và hậu quả của mỗi lỗi quan trọng. Thiết lập một baseline có thể tái tạo và một bộ đánh giá có phiên bản trước khi tinh chỉnh. Kiểm tra các trường hợp thông thường, điều kiện biên, đầu vào sai định dạng hoặc thiếu, độ dịch phân phối, sự cố phụ thuộc, lạm dụng, và các nhóm hoặc môi trường có khả năng bị thiếu hụt. Đo lường chất lượng nhiệm vụ cùng với calibration hoặc độ không chắc, độ trễ, thông lượng, chi phí tài nguyên, khả năng tiếp cận, quyền riêng tư và bảo mật. Ghi lại mọi biến đổi và ngưỡng để một người đánh giá độc lập có thể tái tạo kết quả và phân biệt bằng chứng với một prototype hấp dẫn.

Trước khi ra mắt, chỉ định quyền trách nhiệm cho việc phát hành, ngoại lệ, thay đổi, rollback và ngừng sử dụng. Sử dụng triển khai theo giai đoạn, duy trì một fallback an toàn, và xác minh giám sát bằng cách đưa vào các lỗi cố ý. Telemetry vận hành nên tiết lộ chất lượng đầu vào, hành vi đầu ra, phiên bản mô hình hoặc quy tắc, tình trạng phụ thuộc, can thiệp của con người, và kết quả đã xác nhận mà không thu thập dữ liệu nhạy cảm không cần thiết. Định nghĩa ngưỡng cảnh báo và người chịu trách nhiệm phản hồi, sau đó xem xét bằng chứng thực tế sau triển khai thay vì giả định hiệu suất offline sẽ kéo dài. Đánh giá lại mỗi khi nguồn dữ liệu, người dùng, mô hình, nhà cung cấp, chính sách, phần cứng hoặc mục tiêu thay đổi. Một hệ thống được duy trì cũng cần có tài liệu phục hồi, học hỏi từ sự cố, quy trình xóa và lưu trữ, và một điểm rõ ràng khi nó nên bị vô hiệu hoá hoặc thay thế.

Câu hỏi thường gặp

Một mô hình đơn giản có thể overfit không?

Có. Việc lựa chọn đặc trưng lặp lại, tinh chỉnh ngưỡng, hoặc đánh giá trên cùng một tập holdout có thể làm quá trình phát triển overfit ngay cả khi mô hình cuối cùng đơn giản.

Thêm dữ liệu huấn luyện luôn giải quyết overfitting không?

Không. Thêm dữ liệu đại diện, được gán nhãn chính xác có thể giúp, nhưng dữ liệu trùng lặp, thiên lệch, rò rỉ, hoặc ngoài miền có thể không. Mục tiêu học và thiết kế đánh giá vẫn quan trọng.

Tài liệu tham khảo chính

• scikit-learn: Đồ thị học
• scikit-learn: Cross-validation
• Google Machine Learning Crash Course: Overfitting