Overfitting là gì? Nguyên nhân và cách chống quá khớp

Overfitting là gì? Nguyên nhân và kỹ thuật chống quá khớp trong Machine Learning

Overfitting (quá khớp) xảy ra khi mô hình học quá sát những đặc điểm riêng của dữ liệu huấn luyện, bao gồm cả nhiễu, khiến khả năng dự đoán trên dữ liệu chưa từng thấy suy giảm. Một mô hình đạt điểm gần như tuyệt đối trên tập train vẫn có thể hoạt động kém trong thực tế; vấn đề cốt lõi không phải học được bao nhiêu, mà là học được điều gì có thể tổng quát hóa. Bài viết đi từ dấu hiệu nhận biết đến các kỹ thuật chống quá khớp và một thí nghiệm Python có thể tự chạy.

Tóm tắt nội dung

• Quá khớp là vấn đề tổng quát hóa: thành tích trên train không thay thế được đánh giá trên dữ liệu độc lập.
• Đọc đồng thời đường cong train và validation giúp phân biệt thiếu khớp với dấu hiệu quá khớp.
• Chống quá khớp cần phối hợp kiểm soát độ phức tạp, regularization, early stopping, dữ liệu phù hợp và quy trình đánh giá không rò rỉ.

1. Quá khớp khác gì thiếu khớp và tổng quát hóa?

Trong học máy có giám sát, ta dùng tập dữ liệu gồm các cặp đầu vào và nhãn để ước lượng một hàm dự đoán. Dữ liệu huấn luyện (training set) chỉ là một mẫu hữu hạn của môi trường mà mô hình sẽ gặp sau này. Bởi vậy, mục tiêu không phải chỉ giảm sai số trên mẫu đã thấy mà còn giảm sai số tổng quát hóa (generalization error) trên các quan sát mới được lấy từ điều kiện triển khai dự kiến [1].

Có ba tình huống cần phân biệt. Underfitting (thiếu khớp) xảy ra khi mô hình quá hạn chế hoặc chưa học đủ, nên kết quả trên cả train và validation đều yếu. Overfitting thường thể hiện qua chênh lệch đáng kể giữa kết quả train tốt và validation kém. Trường hợp mong muốn là mô hình đạt hiệu năng phù hợp trên dữ liệu chưa thấy, với khoảng cách giữa hai tập được kiểm soát; khoảng cách nhỏ một mình nó không bảo đảm chất lượng.

Hình dung bài toán dự đoán giá nhà: cây quyết định rất sâu có thể ghi nhớ hàng loạt tổ hợp hiếm gặp trong tập train. Nếu những điều kiện đó phản ánh sai số đo đạc hoặc các trường hợp ngẫu nhiên, mô hình sẽ đưa ra dự đoán thiếu ổn định cho căn nhà mới. Một cây vừa đủ sâu có thể bỏ qua chi tiết vụn vặt và khái quát quy luật tốt hơn, nhưng không có độ sâu tối ưu chung cho mọi bộ dữ liệu.

Theo trực giác bias–variance, mô hình quá cứng nhắc dễ có sai lệch hệ thống lớn (bias), còn mô hình rất nhạy với thay đổi nhỏ của dữ liệu huấn luyện thường có phương sai lớn (variance). Đây là khuôn khổ hữu ích để suy nghĩ, không phải quy tắc rằng mọi mạng lớn đều sẽ quá khớp: kết quả còn phụ thuộc dữ liệu, thuật toán tối ưu và cách regularization [1], [2].

2. Nhận biết overfitting bằng train, validation và learning curve

Hai đường cần quan sát là lỗi huấn luyện (training error) và lỗi kiểm định (validation error). Khi mức độ linh hoạt của mô hình tăng, lỗi train thường giảm; lỗi validation có thể giảm ở giai đoạn đầu rồi tăng trở lại nếu mô hình bắt đầu khớp vào nhiễu. Đó là trực giác của đường cong hình chữ U, không phải hình dạng bắt buộc ở mọi bài toán [2].

Sơ đồ tự vẽ nhằm minh họa trực giác; đường cong không biểu diễn số liệu thực nghiệm và không mô tả mọi mô hình.

Để đọc đúng các đường cong, cần tách ba vai trò dữ liệu: train để điều chỉnh tham số; validation hoặc kiểm định chéo (cross-validation) để chọn cấu hình; test để ước lượng cuối cùng hiệu năng trên dữ liệu độc lập. Nếu liên tục nhìn điểm test rồi chỉnh mô hình, tập test đã trở thành một phần của quy trình chọn lựa và không còn là thước đo độc lập [3].

Một khoảng cách train–validation lớn là tín hiệu đáng điều tra nhưng chưa đủ để xác nhận nguyên nhân. Cần xem độ biến động giữa các fold, quy mô tập validation, tỷ lệ lớp, sự khác nhau giữa nhóm người dùng hoặc thời điểm thu thập. Ngược lại, cả train và validation cùng đạt điểm cao vẫn có thể gây hiểu nhầm nếu dữ liệu trùng lặp hoặc xuất hiện data leakage (rò rỉ dữ liệu).

3. Vì sao mô hình dễ quá khớp?

Nguyên nhân thường không nằm ở một thuật toán riêng lẻ. Dữ liệu ít so với độ phức tạp của quan hệ cần học khiến mô hình có nhiều cách khớp các quan sát mà không rõ cách nào phản ánh quy luật thật. Nhãn sai, biến đầu vào mang nhiễu, các cột định danh gần như duy nhất hoặc quá nhiều đặc trưng không liên quan cũng tạo điều kiện cho mô hình học các tương quan tình cờ.

Độ linh hoạt và thời lượng huấn luyện là hai yếu tố khác. Một cây quyết định không giới hạn độ sâu có thể tách tới những nhóm cực nhỏ; mạng nơ-ron cũng có thể tiếp tục tối ưu loss trên train sau khi validation không còn cải thiện. Điều đó không có nghĩa mô hình nhỏ luôn tốt hơn hoặc cứ huấn luyện lâu là sai. Cần đối chiếu đồng thời hai tập để quyết định.

Cuối cùng, lỗi thuộc quy trình dữ liệu có thể làm điểm đánh giá đẹp giả tạo: chuẩn hóa trên toàn bộ dữ liệu trước khi chia, chọn đặc trưng bằng cả nhãn test, hoặc để nhiều bản ghi của cùng một khách hàng nằm ở cả train và test. Những trường hợp này không đơn thuần là overfitting do độ phức tạp; phải khắc phục cách chia và xử lý dữ liệu trước khi điều chỉnh thuật toán [5].

4. Regularization: hạn chế việc khớp quá mức

Chính quy hóa (regularization) là tên chung cho các thay đổi trong cách học nhằm cải thiện tổng quát hóa. Một nhóm kỹ thuật đưa thêm hình phạt lên độ lớn tham số vào hàm mục tiêu; nhóm khác giới hạn kiến trúc hoặc tập nghiệm mà thuật toán được phép lựa chọn [1]. Với mô hình có tham số θ, dạng tổng quát phổ biến là:

J_reg(θ) = J_train(θ) + λ Ω(θ)

Ở đây, J_train là loss trên train, Ω(θ) đo đại lượng bị phạt và λ ≥ 0 điều khiển mức phạt. Khi λ tăng, sức ép lên tham số thường mạnh hơn, nhưng không có bảo đảm rằng validation sẽ cải thiện mãi; chính quy hóa quá tay có thể gây thiếu khớp. Công thức cũng không có nghĩa mọi mô hình đều phạt toàn bộ tham số giống nhau.

L1 và L2 tác động khác nhau như thế nào?

Với tập trọng số w_i, L1 dùng Ω(w) = Σ|w_i|, thường khuyến khích nhiều hệ số bằng đúng 0 trong một số mô hình tuyến tính. L2 dùng Ω(w) = Σw_i², thường kéo các hệ số về gần 0 theo cách phân bổ liên tục hơn. Hai loại này có thể giúp mô hình giảm phụ thuộc vào các biến yếu hoặc những hệ số quá lớn, nhưng hiệu quả phụ thuộc giả định và dữ liệu [1].

Một chi tiết thực tế dễ nhầm: trong LogisticRegression của scikit-learn, tham số C thường đại diện cho nghịch đảo cường độ chính quy hóa; C nhỏ tương ứng phạt mạnh hơn. Không nên áp dụng máy móc quy tắc “tham số càng lớn thì regularization càng mạnh” cho mọi API.

Giảm độ phức tạp một cách có kiểm soát

Không cần thêm L1 hoặc L2 cho mọi mô hình. Với cây quyết định, có thể giới hạn max_depth, tăng min_samples_leaf hoặc cắt tỉa cây (pruning). Với mô hình dựa trên đặc trưng, loại bỏ biến rò rỉ, giảm biến nhiễu hoặc ràng buộc cách tạo đặc trưng thường có giá trị hơn việc thử rất nhiều tham số. Mọi lựa chọn vẫn cần được kiểm tra bằng validation chứ không suy đoán từ train.

5. Early stopping, dropout và dữ liệu: chống quá khớp không chỉ bằng loss

Early stopping: dừng theo validation, không theo train

Dừng sớm (early stopping) giám sát loss hoặc metric trên validation trong quá trình huấn luyện. Khi metric không còn cải thiện sau một số lần kiểm tra — thường gọi là patience — quá trình học dừng lại, đồng thời có thể khôi phục bộ trọng số đạt validation tốt nhất. Đây là một hình thức regularization vì nó giới hạn quãng đường tối ưu hóa, thay vì nhất thiết thêm hình phạt vào hàm loss [1].

Không nên dừng chỉ sau một epoch xấu: metric dao động do minibatch, learning rate và quy mô tập kiểm định. Cần chọn metric phù hợp nhiệm vụ, xác định ngưỡng cải thiện tối thiểu và lưu best checkpoint. Nếu dừng bằng test loss rồi báo cáo cùng tập đó, đánh giá cuối cùng đã mất tính độc lập.

Dropout: giảm sự lệ thuộc giữa các đơn vị trong mạng

Dropout ngẫu nhiên loại bỏ tạm thời một phần activation trong quá trình huấn luyện mạng nơ-ron, khiến mạng khó phụ thuộc cứng nhắc vào một tập đơn vị cố định. Cơ chế này được trình bày và đánh giá trong công trình của Srivastava và cộng sự [4]. Ở chế độ suy luận thông thường, dropout được tắt hoặc xử lý theo quy ước triển khai tương ứng; nó không phải kỹ thuật trực tiếp áp dụng cho mọi thuật toán như cây quyết định.

Tỷ lệ dropout quá cao có thể làm mô hình học không đủ. Với kiến trúc hiện đại, mức dropout hữu ích còn phụ thuộc normalization, lượng dữ liệu, weight decay và chiến lược fine-tuning. Vì vậy, không thể đưa ra một tỷ lệ mặc định tốt nhất cho tất cả bài toán.

Dữ liệu bổ sung và tăng cường dữ liệu

Thu thập thêm dữ liệu đại diện có thể giúp giảm độ nhạy với những quan sát ngẫu nhiên, đặc biệt khi learning curve cho thấy hiệu năng validation còn tăng theo quy mô train [2]. Tăng cường dữ liệu (data augmentation) tạo các biến thể vẫn giữ đúng nhãn: xoay hoặc thay đổi ánh sáng ảnh trong phạm vi phù hợp; với văn bản, phép thay từ hoặc diễn đạt lại phải kiểm tra xem nghĩa và nhãn có bị đổi không [1].

Augmentation chỉ được thực hiện trên dữ liệu train sau khi chia tập. Nếu tạo biến thể trước rồi chia ngẫu nhiên, một bản gốc có thể nằm ở train và bản gần giống nằm ở test, khiến phép đánh giá lạc quan giả. Trong các bài toán theo chuỗi thời gian, người dùng hoặc thiết bị, cách chia theo thời gian hoặc theo nhóm đôi khi quan trọng hơn việc tăng kích thước mẫu.

6. Ví dụ Python: cây học thuộc train nhưng kém trên dữ liệu mới

Ví dụ sau dùng dữ liệu phân loại nhị phân tổng hợp từ scikit-learn, không phải benchmark thực tế. Ta giữ lại 20% dữ liệu làm holdout test, sau đó dùng kiểm định chéo phân tầng 5 fold trên 80% còn lại để so sánh các độ sâu của cây quyết định. Các giá trị được in từ lần chạy cụ thể chỉ có ý nghĩa minh họa hành vi của mô hình trong cấu hình này.

Python · scikit-learn

from sklearn.datasets import make_classification
from sklearn.model_selection import train_test_split, StratifiedKFold, cross_validate
from sklearn.tree import DecisionTreeClassifier
from sklearn.metrics import accuracy_score

X, y = make_classification(
    n_samples=900, n_features=20, n_informative=6, n_redundant=3,
    flip_y=0.08, class_sep=0.8, random_state=42
)
X_dev, X_test, y_dev, y_test = train_test_split(
    X, y, test_size=0.20, stratify=y, random_state=42
)
cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
results = []
for depth in [2, 4, 6, None]:
    model = DecisionTreeClassifier(max_depth=depth, random_state=42)
    scores = cross_validate(
        model, X_dev, y_dev, cv=cv, scoring='accuracy',
        return_train_score=True
    )
    train_acc = scores['train_score'].mean()
    valid_acc = scores['test_score'].mean()
    results.append((depth, train_acc, valid_acc))
    print(f'depth={str(depth):>4} | train={train_acc:.3f} | CV={valid_acc:.3f}')

best_depth = max(results, key=lambda item: item[2])[0]
final_model = DecisionTreeClassifier(
    max_depth=best_depth, random_state=42
).fit(X_dev, y_dev)
test_acc = accuracy_score(y_test, final_model.predict(X_test))
print(f'Best depth by CV: {best_depth}; final test: {test_acc:.3f}')

Trên môi trường chạy thử, độ sâu 2 cho train accuracy 0,738 và CV accuracy 0,693; độ sâu 4 đạt tương ứng 0,817 và 0,726. Khi không giới hạn độ sâu, cây đạt 1,000 trên train nhưng chỉ 0,685 trên CV. Đó là bằng chứng trực quan rằng học thuộc gần hết tập huấn luyện không giúp kết quả trên các fold chưa thấy tốt hơn.

Trong thử nghiệm này, max_depth=4 có CV trung bình cao nhất trong bốn ứng viên và được chọn trước khi mở tập holdout. Mô hình được huấn luyện lại trên toàn bộ phần development cho test accuracy khoảng 0,833. Đây là kết quả của một tập dữ liệu sinh và một lần chia xác định, không phải tuyên bố rằng cây sâu 4 luôn tối ưu hay kết quả test chắc chắn sẽ bằng điểm CV.

Điểm cần nhớ về phương pháp: kiểm định chéo trong ví dụ được dùng để lựa chọn cấu hình, còn holdout chỉ được chấm một lần để đánh giá cuối. Nếu dữ liệu có cấu trúc nhóm hoặc thời gian, phải thay chiến lược chia tương ứng. Nếu có bước chuẩn hóa, lựa chọn đặc trưng hoặc mã hóa cần học tham số, hãy đưa chúng vào Pipeline trong mỗi fold để tránh rò rỉ [3], [5].

7. Quy trình thực tế: ưu tiên sửa đúng vấn đề trước khi thêm kỹ thuật

Bắt đầu từ một baseline đơn giản và một chiến lược chia dữ liệu phản ánh cách mô hình được dùng. Chọn metric phù hợp: accuracy có thể che giấu lỗi với dữ liệu mất cân bằng; có trường hợp cần precision, recall, F1, log loss hoặc sai số hồi quy. Sau đó so sánh hiệu năng train với validation qua vài mức độ phức tạp, xem sai số theo từng nhóm và kiểm tra xem feature có mang thông tin từ tương lai hay không.

Nếu cả train lẫn validation đều kém, tăng regularization hoặc dropout thường không phải hướng ưu tiên; cần xem đặc trưng, kiến trúc, thuật toán tối ưu hoặc lượng thông tin trong dữ liệu. Nếu train rất tốt nhưng validation giảm rõ rệt, hãy thử giảm độ sâu, tăng regularization, early stopping hoặc thu thập thêm mẫu đại diện. Nếu validation dao động mạnh giữa các fold, cần kiểm tra số mẫu, cấu trúc nhóm và độ bất định trước khi so sánh những cải thiện rất nhỏ.

Một lỗi khó nhận diện là overfitting lên chính tập validation: thử hàng chục biến thể rồi chỉ giữ lại biến thể có điểm số cao nhất có thể tận dụng nhiễu ngẫu nhiên của validation. Với dự án có nhiều vòng tối ưu, tập test thực sự độc lập hoặc đánh giá lồng nhau (nested cross-validation) sẽ cho cái nhìn thận trọng hơn [2], [3]. Đặc biệt, không nên xem việc thêm nhiều kỹ thuật cùng lúc là bằng chứng mỗi kỹ thuật đều có tác dụng; hãy thực hiện so sánh có kiểm soát.

Nguyên tắc thực hành: Không “chữa” overfitting bằng cách chọn kỹ thuật theo thói quen. Hãy kiểm tra dữ liệu và phép chia trước, xác nhận dấu hiệu bằng metric trên validation, thay đổi một nhóm yếu tố có kiểm soát, rồi đánh giá cuối cùng trên test độc lập.

Kết luận

Overfitting không đơn giản là mô hình có quá nhiều tham số: nó là sự thất bại trong việc chuyển những gì đã học trên dữ liệu huấn luyện sang dữ liệu mới. Regularization, giới hạn độ phức tạp, early stopping, dropout và cải thiện dữ liệu đều có thể hữu ích, nhưng không kỹ thuật nào thay thế được quy trình đánh giá độc lập và chống rò rỉ. Một mô hình đáng tin cậy cần được lựa chọn bằng bằng chứng trên validation và kiểm tra trên dữ liệu phản ánh bối cảnh triển khai.

Tài liệu tham khảo

[1] I. Goodfellow, Y. Bengio, and A. Courville, Deep Learning. Cambridge, MA, USA: MIT Press, 2016, ch. 5 và ch. 7. Chương về Regularization.

[2] scikit-learn developers, “Validation curves: plotting scores to evaluate models,” scikit-learn User Guide. Documentation.

[3] scikit-learn developers, “Cross-validation: evaluating estimator performance,” scikit-learn User Guide. Documentation.

[4] N. Srivastava, G. Hinton, A. Krizhevsky, I. Sutskever, and R. Salakhutdinov, “Dropout: A Simple Way to Prevent Neural Networks from Overfitting,” Journal of Machine Learning Research, vol. 15, no. 56, pp. 1929–1958, 2014. Paper.

[5] scikit-learn developers, “Common pitfalls and recommended practices,” scikit-learn User Guide. Documentation.