10 · Praktyka · 4 min czytania · aktualizacja
Jak znaleźć błąd, gdy model uczenia maszynowego działa źle?
W skrócie
Debugowanie modelu to seria testów kontrolnych: baseline, przeuczenie małej próbki, przetasowane etykiety, krzywe uczenia i analiza błędów.
Co to jest
Debugowanie modelu ML to systematyczne szukanie przyczyny, dla której model działa gorzej, niż powinien — albo podejrzanie lepiej. W odróżnieniu od zwykłego programu model z błędem rzadko się wywraca. Zwykle uczy się „czegoś”, daje wynik i nie zgłasza żadnego wyjątku, nawet gdy etykiety są przesunięte o jeden wiersz, a cecha zawiera odpowiedź.
Dlatego debugowanie ML polega na testach kontrolnych: eksperymentach, których wynik znasz z góry. Jeśli model nie przechodzi testu, którego prawidłowy wynik jest oczywisty, błąd jest w kodzie lub danych, a nie w wyborze algorytmu.
Mechanizm — dlaczego tak działa
Błędy w ML są ciche, bo modele są elastyczne. Sieć neuronowa lub las losowy potrafią dopasować się nawet do losowych etykiet, więc „model się uczy” nie dowodzi, że dane są poprawne. Z drugiej strony drobny błąd przetwarzania (zła kolumna, odwrócone etykiety, normalizacja tylko części danych) obniża wynik o kilka punktów i wygląda jak „trudny problem”.
Testy kontrolne dzielą przestrzeń możliwych błędów na połowy. Model bazowy mówi, czy model w ogóle wnosi informację. Przeuczenie małej próbki (np. 20 przykładów) sprawdza, czy kod uczenia działa: model, który nie potrafi zapamiętać 20 przykładów, ma błąd w pętli uczenia, w funkcji straty lub w danych. Przetasowane etykiety sprawdzają walidację: po permutacji celu wynik musi spaść do poziomu bazowego; jeśli tak się nie dzieje, informacja o celu przecieka inną drogą.
Krzywe uczenia rozróżniają dwa podstawowe stany. Wysoki błąd na zbiorze uczącym i walidacyjnym oznacza niedouczenie: model jest za prosty, cechy za słabe albo uczenie się nie zbiega. Niski błąd uczący przy wysokim walidacyjnym oznacza przeuczenie: potrzeba regularyzacji, prostszego modelu lub więcej danych. Te dwa stany wymagają przeciwnych działań, więc pomylenie ich kosztuje dużo czasu.
Na koniec analiza błędów: obejrzyj kilkadziesiąt najgorzej przewidzianych przykładów. Często od razu widać wspólny wzór — złe etykiety, brakującą cechę, jedną grupę, której model nie rozumie. To najtańsze źródło pomysłów na poprawę.
Na przykładzie
Titanic, 5-krotna walidacja krzyżowa. Drzewo decyzyjne bez ograniczeń ma 98,2% dokładności na danych uczących i 77,8% na walidacji — klasyczne przeuczenie, gorsze niż prosta reguła płci (78,7%). Test „zapamiętaj 20 przykładów” drzewo przechodzi ze 100%, więc kod uczenia działa; problemem jest pojemność modelu, nie błąd.
Test przetasowanych etykiet: po losowej permutacji kolumny survived regresja logistyczna osiąga 61,1%, a gradient boosting 57,6% — obie wartości przy lub poniżej modelu bazowego 61,6%, czyli walidacja jest szczelna. Kontrprzykład: dodanie kolumny alive daje 100% dokładności. Wynik „za dobry, żeby był prawdziwy” to też objaw do debugowania — tu kolumna jest zakodowaną etykietą.
Dane: Titanic
W praktyce
- Zawsze porównuj z
DummyClassifier/DummyRegressor; model poniżej bazowego ma błąd lub złą metrykę. - Przeuczenie małej próbki: w PyTorch jedna mini-paczka powtarzana przez kilkaset kroków powinna dać stratę bliską zeru.
- Przetasowane etykiety:
y_perm = rng.permutation(y)i ta sama walidacja — wynik musi spaść do poziomu bazowego. - Krzywe uczenia:
learning_curvelubcross_validate(..., return_train_score=True); patrz na lukę między uczeniem a walidacją. - Analiza błędów: posortuj obserwacje po stracie (
log_lossper przykład) i obejrzyj najgorsze; sprawdźconfusion_matrixi wyniki w podgrupach. - Typowe źródła błędów: przesunięte indeksy po
merge, etykiety w złym kodowaniu, brakmodel.eval()w PyTorch, za duża stała uczenia, wyciek przez cechy z przyszłości.
Najczęstsze pytania
- Strata nie spada od początku uczenia. Od czego zacząć?
- Od przeuczenia jednej mini-paczki. Jeśli i to się nie udaje, sprawdź stałą uczenia (często za dużą lub za małą o rząd wielkości), czy dane i etykiety pasują do siebie, czy funkcja straty dostaje to, czego oczekuje (logity czy prawdopodobieństwa), oraz czy gradienty w ogóle docierają do wag.
- Wynik walidacji jest świetny, a w produkcji słaby. Co sprawdzić?
- Najpierw wyciek: cechy powstające po momencie decyzji, przetwarzanie dopasowane na całym zbiorze, duplikaty między zbiorami. Potem różnice rozkładów między danymi uczącymi a produkcyjnymi oraz rozbieżności w przetwarzaniu danych w obu środowiskach.
- Jak odróżnić przeuczenie od niedouczenia?
- Porównaj błąd na danych uczących i walidacyjnych. Oba wysokie i bliskie sobie — niedouczenie. Uczący niski, walidacyjny wyraźnie wyższy — przeuczenie. Krzywa uczenia (wynik w funkcji liczby przykładów) dodatkowo pokazuje, czy więcej danych pomoże.
Źródła
- Goodfellow I., Bengio Y., Courville A. „Deep Learning”, MIT Press 2016, rozdz. 11 (Practical Methodology), zwłaszcza 11.5 (Debugging Strategies).
- Zhang C., Bengio S., Hardt M., Recht B., Vinyals O. „Understanding deep learning requires rethinking generalization”, ICLR 2017.
- Karpathy A. „A Recipe for Training Neural Networks”, 2019, https://karpathy.github.io/2019/04/25/recipe/
- Breck E., Cai S., Nielsen E., Salib M., Sculley D. „The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction”, IEEE Big Data 2017.