Najczęstsze błędy w trenowaniu modeli ML

Po co w ogóle mówić o błędach w trenowaniu modeli ML

Trenowanie modelu jako proces, a nie jednorazowy strzał

Uczenie maszynowe rzadko kończy się na jednym modelu, który „po prostu działa”. Większość sensownych projektów przechodzi przez dziesiątki iteracji: kolejne wersje danych, inne cechy, inne modele, tuning hiperparametrów, testy na produkcji. W takim procesie powtarzalne błędy są znacznie groźniejsze niż pojedyncza pomyłka – bo wbudowują się w cały „workflow” i później trudno je dostrzec.

Błędy w trenowaniu modeli ML nie są tylko problemem początkujących. Równie często powstają w dojrzałych zespołach, tylko w bardziej wyrafinowanej formie: data leakage ukryte w pipeline’ach, niestabilna walidacja krzyżowa, niejasne metryki raportowane do biznesu. Różnica polega na tym, że doświadczeni zaczynają mieć system na wykrywanie i minimalizowanie takich potknięć.

Koszt typowych wpadek w uczeniu maszynowym

Źle wytrenowany model to nie tylko gorszy wynik w notatniku Jupytera. To także:

• Stracony czas – tygodnie tuningu hiperparametrów przy źle zdefiniowanym celu albo błędnym podziale danych.
• Stracone pieniądze – drogie GPU/TPU idące na trenowanie modelu, który nigdy nie trafi na produkcję lub z niej szybko poleci.
• Utrata zaufania – menedżerzy widzą, że modele „raz działają, raz nie” i zaczynają traktować ML jak losowanie z kapelusza.
• Ryzyko biznesowe – szczególnie w fraudach, kredytach, medycynie czy rekomendacjach, gdzie złe predykcje bolą realnie.

Jeden źle przygotowany eksperyment może wypaczyć decyzje na kolejne miesiące: zamiast poprawiać dane i proces, zespół wymienia algorytmy, dorzuca warstwy w sieci neuronowej, inwestuje w „lepszą” infrastrukturę – a fundament dalej jest krzywy.

Błąd ucznia vs. szkodliwy antywzorzec

Nie każdy błąd jest równie groźny. Błędy ucznia to na przykład pomyłka w kodzie, nie ten plik CSV, źle ustawiony parametr w bibliotece. Są bolesne, ale zwykle jednorazowe, łatwo je naprawić i niewiele z nich „przecieka” do kolejnych projektów.

Gorzej, gdy w zespole pojawiają się antywzorce, które później są powtarzane wszędzie:

• „Zawsze używamy accuracy, bo jest proste do wytłumaczenia.”
• „Walidacja? Dzielimy na 80/20 i po sprawie.”
• „Im więcej warstw i parametrów, tym lepiej, bo model jest bardziej inteligentny.”
• „Dane z przyszłości? Jak są pod ręką, to czemu nie, przecież model ma się czegoś nauczyć.”

Takie nawyki później replikuje się automatycznie – w nowych projektach, w szablonach notebooków, w pipeline’ach. I nagle okazuje się, że wszystkie modele w organizacji mają te same fundamentalne wady.

Gdzie najczęściej czyha mina: szybka mapa pól minowych

W trenowaniu modeli ML typowe problemy zaskakująco często pojawiają się w tych samych miejscach:

• Definicja problemu i celu – niejasny target, źle dobrane metryki, brak powiązania z realnym celem biznesowym.
• Przygotowanie danych – brudne dane, outliery, brak spójności między źródłami, niedopasowane skale i formaty.
• Data leakage – subtelne wycieki informacji z przyszłości lub z targetu do cech wejściowych.
• Struktura eksperymentu i walidacja – niewłaściwy split, brak cross-validation, mieszanie danych użytkowników między zbiorami.
• Zarządzanie złożonością modelu – overfitting, underfitting, ślepa wiara w „większy model = lepszy model”.
• Używanie zbioru testowego – podglądanie test setu zbyt często, tuning „pod test”, brak finalnego, uczciwego pomiaru.
• Wdrożenie i utrzymanie – drift danych, brak monitoringu, rozjechanie się pipeline’u trenowania i predykcji.

Im szybciej zespół nauczy się rozpoznawać te miny, tym mniej będzie „magicznych” modeli, które w notatniku mają 0.95 AUC, a na produkcji dziwnie nie chcą współpracować.

Fundamenty poprawnego trenowania: dane, cel, metryki

Niejasny problem: model trenowany tylko „dla sportu”

Jednym z częstszych błędów jest rozpoczęcie pracy od pytania: „Jaki model wybrać?”, zamiast: „Jaki problem chcemy rozwiązać i jak go zmierzymy?”. Jeśli cel biznesowy jest rozmyty, to nawet świetny model będzie mało użyteczny.

Przykład: firma chce „wykorzystać AI do zwiększenia sprzedaży”. Zespół ML, bez doprecyzowania, buduje model predykcji prawdopodobieństwa zakupu. Tylko że:

• Nie wiadomo, jaki horyzont czasowy jest istotny (dzień, tydzień, miesiąc?).
• Brakuje definicji „sukcesu”: wzrost przychodu, konwersji, marży, liczby transakcji?
• Nie ma ograniczeń: ile kontaktów z klientem jest akceptowalne, aby go nie zniechęcić?

Bez tych informacji trudno dobrać target, metryki i sensowne progi decyzyjne. Model może wyglądać dobrze „na papierze”, ale jego decyzje nie przekładają się na realny efekt biznesowy.

Źle zdefiniowana zmienna celu i mylące etykiety

Target jest fundamentem całego uczenia nadzorowanego. Kilka typowych wpadek:

• Odwrócona interpretacja etykiet – klasa 0 to fraud, a 1 to „nie fraud”, ale ktoś założył odwrotnie i całe raportowanie staje się nieintuicyjne.
• Pomylone klasy – dane oznaczone ręcznie przez kilka osób bez spójnych wytycznych; ten sam przypadek raz dostaje etykietę „spam”, raz „nie spam”.
• Mieszanie horyzontów czasowych – „czy klient odejdzie w ciągu 30 dni” vs „czy odejdzie w ogóle”, a w kodzie to po prostu jedna kolumna churned.
• Target pochodzący z przyszłości – wykorzystywany przy generowaniu cech w sposób, który później prowadzi do data leakage.

Przy ustalaniu zmiennej celu warto przejść przez prostą checklistę:

• Czy target jest jednoznaczny, możliwy do zrozumienia przez osobę techniczną i biznes?
• Czy etykiety są spójne na całym zbiorze (brak sprzecznych zasad anotacji)?
• Czy dokładnie wiadomo, kiedy target jest znany (czas, zdarzenie), a kiedy model ma przewidywać?
• Czy target da się odtworzyć z logów / danych źródłowych w przyszłości?

Niewłaściwe metryki: accuracy wszędzie i do wszystkiego

Jednym z najbardziej klasycznych błędów w uczeniu maszynowym jest używanie accuracy przy silnie niezbalansowanych klasach. Przykład z fraudami pojawia się często, bo jest bardzo namacalny:

Mamy dane, gdzie fraudy stanowią 1% transakcji. Klasyfikator, który zawsze przewiduje „brak fraudu”, osiąga 99% accuracy. Z perspektywy biznesu taki model jest bezużyteczny, ale w tabelce z metrykami wygląda wręcz imponująco.

Dobór metryk musi odpowiadać na realne pytania:

• W fraudach i anomaliach – precision, recall, F1, ROC-AUC, PR-AUC.
• W rankingach i rekomendacjach – MAP, NDCG, hit rate@k.
• W regresji – MAE, gdy ważny jest błąd w jednostkach, RMSE, gdy mocno karzemy duże pomyłki.
• W problemach z progami decyzyjnymi – krzywe precision-recall, cost-sensitive metrics.

Błędny lub nielogiczny podział danych: train/validation/test

Bez porządnego podziału danych na train/validation/test trudno mówić o wiarygodnej ocenie modelu. Typowe błędy:

• Brak zbioru walidacyjnego – model jest tunowany wprost na zbiorze testowym.
• Losowy podział w problemach czasowych – dane z przyszłości trafiają do treningu, a wcześniejsze do testu.
• Duplikaty lub te same obiekty w train i test – np. ten sam użytkownik w obu zbiorach w problemie personalizacji.
• Zbyt mały test set – wyniki są niestabilne, a różnice między modelami nieistotne statystycznie.

Sensowny minimalny podział wygląda zwykle tak:

• Train – dane do trenowania i wstępnego dopasowania modelu.
• Validation – dane do tuningu hiperparametrów i wyboru modelu.
• Test – dane „zamrożone”, używane tylko raz na koniec, jako uczciwy pomiar.

W problemach czasowych dodatkowo trzeba zadbać o to, by czas zawsze „płynął do przodu”: trenowanie na starszych danych, walidacja i test na nowszych przedziałach.

Brudne dane, brudne wyniki: częste grzechy w przygotowaniu danych

Chaotyczne czyszczenie danych: skrajności, które mszczą się później

Sprzątanie danych to jedno z tych zadań, które mało kto lubi, więc czasem pojawia się pokusa pójścia na skróty. Skutki bywają dość przewidywalne.

Pierwsza skrajność to „wyrzucam wszystko, co ma NaN”. Przy dużych zbiorach może to zadziałać, ale często kończy się:

• utratą rzadkich, ale istotnych przypadków,
• silnym zaburzeniem rozkładu danych,
• wycięciem całych segmentów użytkowników (np. tylko nowi klienci mają brakujące dane w pewnej kolumnie).

Druga skrajność to bezrefleksyjne imputowanie średnią lub medianą wszędzie, gdzie się da. Taki zabieg spłaszcza rozkłady, zmniejsza wariancję i może ukryć ważne zależności. Do tego imputer trenowany na całym zbiorze (zamiast na train) prowadzi prosto do lekkiego, ale realnego data leakage.

Rozsądniejsze podejście wymaga kilku kroków:

• Sprawdzenie, dlaczego dane są brakujące (błąd systemu, brak pomiaru, specyfika grupy użytkowników?).
• Zastosowanie różnych strategii imputacji dla różnych kolumn (np. osobne kategorie „missing”, imputacja na poziomie grup, modele imputujące).
• Dodanie cech-flag informujących o brakach danych – często sama informacja, że coś jest missing, jest predykcyjna.

Ignorowanie rozkładu danych i wartości odstających

Outliery potrafią popsuć każdy model, ale równie często są najcenniejszym sygnałem. Wszystko zależy od kontekstu.

• Jeśli mamy błędy systemowe (np. cena ujemna, czas trwania -5 sekund), to zwykle są to dane do naprawy lub usunięcia.
• Jeśli mamy ekstremalnie dużą wartość transakcji w fraudach – to może być właśnie kluczowy sygnał dla modelu.

Błędem jest mechaniczne „obcinanie” wszystkiego powyżej lub poniżej pewnego percentyla bez sprawdzenia konsekwencji. W regresji outliery potrafią mocno wypchnąć model liniowy, ale w drzewach decyzyjnych mogą dostarczać wartościowych reguł podziału. Zanim cokolwiek się utnie, dobrze jest:

• zobaczyć rozkład zmiennej (histogram, wykres pudełkowy),
• sprawdzić kilka przykładów rekordów z outlierami,
• porównać wyniki modelu z i bez agresywnego traktowania outlierów.

Mieszanie danych z różnych źródeł bez normalizacji

Sklejanie tabel „na wiarę” i błędy w joinach

Łączenie danych z wielu źródeł brzmi niewinnie, dopóki nie okaże się, że model „uczy się” efektów ubocznych złych joinów. To jeden z tych problemów, które trudno wychwycić samymi metrykami.

Typowe potknięcia przy joinach:

• Duplikowanie rekordów – join many-to-many zamiast one-to-many; pojedynczy klient nagle ma pięciokrotnie większy „historial zakupów”, bo w logach występuje kilka technicznych wierszy na to samo zdarzenie.
• Nieświadome inner joiny – część użytkowników wypada całkowicie ze zbioru, bo w jednym z systemów nigdy się nie pojawiła; model jest potem ślepy na ten segment.
• Łączenie po niestabilnych kluczach – np. po adresie e-mail, który użytkownicy zmieniają; część historii „gubi się” lub jest przypisywana do złej osoby.

Przy złożonych joinach pomaga kilka prostych kontroli:

• sprawdzenie, jak zmienia się liczba wierszy przed i po joinie,
• weryfikacja liczby unikalnych kluczy (czy nie rośnie nagle dwa-trzy razy),
• przegląd kilku losowych przykładów ręcznie – tak, otwarcie CSV w edytorze tekstu bywa lepsze niż godzina patrzenia w wykresy.

Dobrą praktyką jest też jawne opisywanie w kodzie założeń typu „jeden klient – wiele zamówień”, „jeden event – co najwyżej jeden rekord w logu agregującym” i asercje, które to sprawdzają.

Feature engineering, który miesza czas i rzeczywistość

Tworzenie cech z danych historycznych jest świetne, dopóki nie prowadzi do subtelnego cofania się w czasie. Problem pojawia się, gdy do budowy cech używany jest stan wiedzy z przyszłości względem momentu, w którym model ma podjąć decyzję.

Przykłady:

• Liczenie „średniego miesięcznego wydatku” klienta na podstawie całej jego historii, w tym zakupów po dacie, dla której przewidujemy churn.
• Agregaty „ostatnie 30 dni” zbudowane bez okna czasowego – w praktyce obejmują dane także po momencie klasyfikacji.
• Cecha „liczba reklamacji” liczona z tabeli, która jest uzupełniana z opóźnieniem, a timestamp jest nadpisywany datą przetworzenia, nie zgłoszenia.

To klasyczny wstęp do data leakage: model uczy się sygnałów, których w realnym użyciu po prostu nie będzie. Z zewnątrz wyniki wyglądają fantastycznie, dopóki nie spróbuje się tego odtworzyć w systemie produkcyjnym.

Bezpieczniejszy proces to:

• budowanie cech w oparciu o ściśle zdefiniowany moment referencyjny (timestamp decyzji),
• tworzenie cech okiennych (np. 7/30/90 dni) z jasnym filtrem po czasie,
• symulowanie procesu online: generowanie cech wyłącznie z informacji dostępnych do danej chwili.

Brak standaryzacji i logiki w preprocessingu

Często pipeline przetwarzania danych rozwija się „organicznie”: coś się dodało w notatniku, coś w osobnym skrypcie, coś w ETL-u. Po pół roku nikt nie pamięta, czy dana kolumna była log-transformowana, normalizowana, czy może jednak zostawiona „jak leci”.

Brak powtarzalnego preprocessingu prowadzi do kilku problemów:

• Inny preprocessing w treningu i produkcji – w notatniku były one-hot encodery, a w API model dostaje surowe stringi.
• Sprzeczne transformacje – ta sama cecha jest raz skalowana MinMaxScalerem, innym razem StandardScalerem, bo skrypty przygotowywały inne eksperymenty.
• Ukryte założenia – np. wycięcie części danych w preprocessingu bez odzwierciedlenia tego w dokumentacji.

Rozwiązaniem jest pilnowanie jednego, spójnego pipeline’u (choćby w prostym frameworku typu scikit-learn Pipeline), który jest:

• wersjonowany razem z modelem,
• testowany na małych próbkach (czy dane wejściowe z produkcji „przechodzą” bez błędów),
• opisany – choćby kilkoma komentarzami, co dana transformacja robi i dlaczego.

Data leakage – cichy zabójca wiarygodnych wyników

Najczęstsze źródła data leakage w praktyce

Data leakage nie zawsze jest efektem spektakularnej pomyłki. Częściej wynika z serii drobnych decyzji, które osobno wyglądają rozsądnie.

Kilka klasycznych scenariuszy:

• Użycie całego zbioru do skalowania / imputacji – StandardScaler, który „podgląda” również test set; model uczy się rozkładu danych, których w momencie predykcji jeszcze nie widzi.
• Cechy pochodzące z procesów post-factum – np. etykieta reklamacji klienta, która w systemie pojawia się tydzień po zdarzeniu, ale w tabeli ma timestamp z dnia zakupu.
• Label encoding na całości danych – rzadkie kategorie, które występują tylko w test secie, wpływają na mapowanie kategorii w trainie.
• Ręczne „doanotowanie” trudnych przykładów na podstawie wiedzy, którą tak naprawdę mielibyśmy dopiero po czasie (np. w fraudach po dochodzeniu).

Każda z tych sytuacji delikatnie podnosi wyniki na walidacji i teście, ale nie ma szans powtórzyć się w realnym świecie. To trochę jak trenowanie do egzaminu na pytaniach, które przypadkiem były w kluczu odpowiedzi.

Jak wykrywać i ograniczać data leakage

Nie ma jednego magicznego testu, ale da się znacząco zmniejszyć ryzyko. Pomagają zarówno narzędzia, jak i „zdrowy paranoiczny” proces.

• Przegląd cech pod kątem ich „dostępności w czasie” – dla każdej kolumny warto jasno powiedzieć, od kiedy jest znana (timestamp, event), zanim zostanie użyta do treningu.
• Stricte rozdzielony preprocessing – wszystkie fit-y (scalery, imputery, encodery) wyłącznie na train, a potem transform na validation/test.
• Walidacja typu time-based w problemach sekwencyjnych – jeśli wyniki dramatycznie spadają przy przejściu z random split na split czasowy, coś jest nie tak.
• Manualne sanity-checki – cechy, które mają podejrzanie wysoką ważność, warto „ręcznie” sprawdzić i zadać pytanie: czy na pewno znamy to w chwili predykcji?

Dobrym nawykiem jest też próba odtworzenia procesu generowania cech z wykorzystaniem tylko danych dostępnych w „prawdziwym” systemie (np. logi zdarzeń, a nie hurtownia z opóźnieniem i przetworzeniami).

Overfitting, underfitting i błędna intuicja wokół złożoności modeli

Mylenie „mocnego modelu” z „dobrym modelem”

Głęboka sieć neuronowa z milionem parametrów robi wrażenie, ale niekoniecznie rozwiązuje prosty problem lepiej niż logiczna regresja czy las losowy. Silne przeuczanie to nie tylko domena małych datasetów – duże, bogate modele też potrafią pięknie nauczyć się szumu.

Typowa sytuacja: na zbiorze treningowym model osiąga niemal perfekcyjny wynik, na walidacji jest „średnio, ale akceptowalnie”, a na nowym, realnym deployu – wyniki spadają gwałtownie. W tle często widać:

• model z dużo większą liczbą parametrów niż realna ilość informacji w danych,
• zbyt agresywny tuning hiperparametrów pod jedną metrykę,
• brak regularizacji albo jej losowe ustawienia „z tutoriala”.

Jak rozróżnić overfitting od underfittingu

Zamiast zgadywać, lepiej spojrzeć na kilka prostych sygnałów:

• Underfitting: słabe wyniki na train i validation, krzywe uczenia „płaskie” – dokładanie danych niewiele zmienia.
• Overfitting: świetne wyniki na train, zauważalnie gorsze na validation, duża różnica między nimi; dokładanie danych poprawia validation, ale train jest już „sufit”.

Pomaga też obserwacja, co się dzieje przy zmianie złożoności modelu (liczby warstw, głębokości drzew, liczby cech). Jeżeli uproszczenie modelu praktycznie nie pogarsza wyniku na validation, a poprawia stabilność, to znak, że wcześniejsza wersja była zbędnie skomplikowana.

Najpopularniejsze pułapki w tuningu modeli

Tuning hiperparametrów często zamienia się w wyścig: kto „wyklika” wyższe ROC-AUC na walidacji. Problem w tym, że walidacja nie jest nieskończonym zasobem – po tysiącu prób model zaczyna się uczyć także specyfiki walidacji.

Kilka często spotykanych błędów:

• „Strzelanie na oślep” – ogromna siatka parametrów (grid search) bez sensownych zakresów; sporo mocy obliczeniowej idzie na modele kompletnie niedorzeczne.
• Ręczne poprawianie parametrów „bo tak czuć” – kilka losowych zmian po każdej iteracji, bez notowania, co już było sprawdzane.
• Brak oddzielnego hold-outu – decyzja o finalnym modelu wyłącznie na podstawie wyników na tym samym foldzie / zbiorze walidacyjnym.

Rozsądniejsze podejście:

• zawężenie przestrzeni hiperparametrów na podstawie wiedzy o modelu (dokumentacja, doświadczenie innych zespołów),
• użycie bayesian optimization lub random search zamiast pełnego grid search,
• utrzymywanie małego, „świętego” zbioru, na którym sprawdza się tylko kilka najlepszych kandydatów.

Regularizacja, która pomaga – i taka, która tylko wygląda profesjonalnie

Dodanie do modelu „czegoś z L1/L2/dropoutem” brzmi jak szybkie lekarstwo na overfitting. Rzeczywistość bywa mniej łaskawa, zwłaszcza gdy regularizacja jest ustawiana na chybił trafił.

Typowe problemy:

• Zbyt silna regularizacja – model nie jest w stanie nauczyć się nawet prostych zależności, wyniki na train pozostają niskie.
• Niespójność między warstwami – w sieciach neuronowych jeden moduł ma ogromny dropout, inny żaden; sieć zachowuje się niestabilnie w trakcie uczenia.
• Brak powiązania z ilością danych – ta sama siła regularizacji niezależnie od tego, czy mamy kilkadziesiąt tysięcy przykładów, czy kilkaset milionów.

Dobrym nawykiem jest traktowanie regularizacji jak parametru z jasno zdefiniowanym celem: ograniczyć złożoność modelu tylko tam, gdzie dane nie dają dość informacji. Kilka kontrolnych wykresów (np. learning curves w funkcji liczby próbek) mówi o tym dużo więcej niż „zgadywanie na oko”.

Zła walidacja i nadużywanie test setu

Walidacja niedopasowana do natury problemu

Ten sam sposób walidacji nie zadziała dla wszystkich zadań. Random split, choć wygodny, bywa kompletnie mylący w danych sekwencyjnych, recommendation systemach czy problemach z silną korelacją między przykładami.

Typowe niedopasowania:

• Random split w danych czasowych – model uczy się z przyszłości i jest testowany na przeszłości; wyniki są z definicji zbyt optymistyczne.
• Brak group splitu – ten sam użytkownik, pacjent, urządzenie pojawia się w train i validation; model „kojarzy” jednostkę, zamiast generalizować.
• Uśrednianie po przykładach, nie po jednostkach – w medycynie jeden pacjent z setkami pomiarów dominuje metryki.

Rozwiązania są znane, tylko rzadko konsekwentnie stosowane: TimeSeriesSplit, GroupKFold, agregacja metryk per użytkownik/podmiot, a dopiero potem globalne uśrednianie.

Test set jako „kolejna walidacja”

Test set ma służyć do jednego: końcowej, uczciwej oceny gotowego modelu. W praktyce bywa odpalany co kilka dni, przy każdym większym eksperymencie, „żeby zobaczyć, jak tam idzie”.

Efekt? Po kilkunastu iteracjach test set staje się de facto kolejnym zbiorem walidacyjnym, a wyniki są przestrojone do konkretnych przykładów. Prawdziwy performance na nowych danych będzie niższy niż na teście, ale nikt już nie ma zaufania do żadnych liczb.

Kilka prostych zasad higieny:

• Test set jest zamrożony – nie dotyka się go podczas codziennych iteracji.
• Decyzje o architekturze i hiperparametrach zapadają bez zaglądania do testu.
• Jeśli test set był używany wielokrotnie – trzeba uczciwie przyznać, że jego rola została „zużyta” i zbudować nowy, z innych danych.

Cross-validation bez zrozumienia statystyki

Najczęstsze błędne założenia w cross-validation

Cross-validation ma opinię „złotego standardu”, więc łatwo wyłączyć myślenie: skoro jest K-fold, to wszystko jest dobrze. Niestety, sama technika nie naprawi źle zaprojektowanego eksperymentu ani błędnych założeń o danych.

Kilka pułapek pojawia się zaskakująco często:

• Założenie niezależności przykładów – zwykły KFold w sytuacji, gdy przykłady są powiązane (sesje użytkownika, wizyty pacjenta, pomiary z tego samego sensora). Wynik jest optymistyczny, bo model widzi „bliźniaczo podobne” rekordy w train i valid.
• Zbyt mała liczba foldów przy silnej heterogeniczności – przy bardzo zróżnicowanych danych (wiele krajów, produktów, typów użytkowników) 3-fold CV może przypadkowo złożyć „łatwe” przypadki do jednego folda i zaburzyć obraz.
• Ignorowanie wariancji między foldami – raportowany jest tylko średni wynik, ale nie widać, że jeden fold ma świetny rezultat, a inny katastrofalny. To sygnał, że model jest niestabilny lub dane są bardzo nierówne.

Zamiast ślepo ufać numerkom, przydaje się zwykły podgląd: jakie rekordy wpadają do poszczególnych foldów, jak rozkładają się klasy, użytkownicy, timestampy. Czasem 10 minut eksploracji danych daje więcej niż 10 godzin dodatkowego trenowania.

Gdy cross-validation zamienia się w leakage

Paradoksalnie, cross-validation samo w sobie może stać się źródłem data leakage, jeśli preprocessing nie jest ściśle rozdzielony między foldy. Klasyczny grzech: jeden StandardScaler czy TargetEncoder fitowany na całości, a dopiero potem CV.

Co potrafi pójść źle:

• Globalny fit przed splitowaniem – wszystkie statystyki (średnie, wariancje, encodery) „widziane” są jednocześnie przez train i valid. Wyniki CV są zawyżone w podobny sposób jak przy klasycznym leakagu.
• Target encoding bez rozbicia na foldy – informacje o etykiecie przeciekają do cech w walidacji. Modele drzewiaste aż się proszą, żeby to wykorzystać.
• Feature selection na całym zbiorze – wybór cech na bazie korelacji/feature importance policzonej przed CV. W efekcie walidacja korzysta z cech „dobranych” pod kątem także jej własnych etykiet.

Bezpieczny wzorzec to pipeline, który w każdym foldzie osobno robi fit na części treningowej i transform na walidacyjnej. Dla target encodingu – wariant z K-fold encodingiem wewnątrz treningu, bez podglądania labeli z foldu walidacyjnego.

Błędy w interpretacji wyników walidacji

Nawet przy poprawnym schemacie walidacji można wnioskować tak, że statystycy łapią się za głowę. Kilka typowych skrótów myślowych szybko prowadzi do nadinterpretacji.

• Brak przedziałów ufności – różnica 0.002 w ROC-AUC między dwoma modelami jest traktowana jak „wyraźnie lepszy”, choć wariancja między foldami jest większa niż ta różnica.
• Wybieranie „najlepszego folda” – analizowanie wyłącznie najmocniejszego wyniku (np. najlepszy z pięciu foldów) i ignorowanie reszty. To tak, jakby oceniać piłkarza po jednym meczu w karierze.
• Ignorowanie driftu – dane z kolejnych miesięcy/systemów mają inne rozkłady, ale performance raportowany jest jako jedna liczba „globalna”, bez rozbicia na okresy czy segmenty.

Pomaga prosta dyscyplina: zawsze raportować średnią i odchylenie standardowe z foldów, sprawdzać stabilność wyniku po różnych losowych seedach, a przy danych zmieniających się w czasie – także performance per okres. Wtedy „lepszy” model oznacza realną przewagę, a nie trafiony przypadkiem seed.

Walidacja produkcyjna, czyli co się dzieje po deployu

Najlepsza walidacja offline i tak jest tylko przybliżeniem. Prawdziwy egzamin zaczyna się po wdrożeniu, kiedy pojawiają się nowe wzorce zachowań, bugi integracyjne i presja czasu. Błędy popełniane na tym etapie są równie kosztowne jak te w trenowaniu.

Kilka klasycznych potknięć:

• Brak A/B testu lub shadow deploymentu – model od razu zastępuje stary system, bez porównania „head to head”. Jeśli coś pójdzie źle, trudno odróżnić problem modelu od problemu integracji.
• Zmiana definicji celu w produkcji – etykiety offline definiowane są inaczej niż KPI biznesowe online, a mimo to oczekuje się, że model „magicznie” poprawi wyniki na docelowej metryce.
• Niedoszacowanie opóźnień – label pojawia się po tygodniach (np. chargeback, churn), a mimo to performance jest oceniany po kilku dniach. Wykresy wyglądają słabo i zaczyna się paniczne „naprawianie” modelu.

Rozsądne podejście to etap przejściowy: najpierw shadow mode (nowy model liczy predykcje, ale nie wpływa na decyzje), potem ograniczony rollout (np. procent ruchu), dopiero na końcu pełne przełączenie. Przy okazji wychodzi na jaw masa błędów typu „inny preprocessing w produkcji niż w trenowaniu”.

Źle zdefiniowany cel trenowania

Model może być technicznie poprawnie wytrenowany, walidacja czysta, a mimo to system nie daje wartości. Źródło bywa dużo wcześniej: w definicji celu. Jeśli label nie odpowiada temu, co faktycznie chcemy optymalizować, cały proces uczy się „czegoś innego”.

Kilka typowych nieporozumień:

• Cel techniczny zamiast biznesowego – maksymalizacja ROC-AUC przy ekstremalnie niezbalansowanych klasach, podczas gdy krytyczne jest precision/recall w wąskim zakresie thresholdów.
• Nieaktualne etykiety – model uczy się na starych definicjach fraudu, churnu czy konwersji, które w systemie biznesowym dawno się zmieniły.
• Mylenie proxy z celem – np. przewidywanie kliknięć jako proxy do przewidywania przychodu, a potem zdziwienie, że rośnie liczba „byle jakich” klików, a nie zysk.

Pomaga wspólne wypracowanie metryk z biznesem i productem: co dokładnie jest sukcesem, w jakim horyzoncie czasowym, przy jakich ograniczeniach (np. liczba fałszywych alarmów, SLA czasowe). Dopiero wtedy da się sensownie ustawić loss, metryki walidacyjne i sposób użycia modelu.

Ignorowanie kosztów różnych typów błędów

W teorii: false positive i false negative są „równoważne”. W praktyce: w fraudach, medycynie czy rekomendacjach różnica w koszcie bywa gigantyczna. Trening bez uwzględnienia tej asymetrii kończy się „ładnymi” metrykami i fatalnymi decyzjami.

Kilka objawów:

• Stały threshold 0.5 – z przyzwyczajenia, bez powiązania z realnym kosztem błędów i korzyściami z trafnych decyzji.
• Porównywanie modeli tylko po jednej metryce – np. F1-score, który miesza precision i recall, ale nie pokazuje, czy bardziej „boli” nas strata recallu, czy precision.
• Brak analizy trade-offów – brak krzywych precision–recall, brak symulacji: „co się stanie, jeśli podniesiemy threshold do 0.8?”.

Prosty, ale skuteczny krok to wprowadzenie choćby przybliżonej funkcji kosztu i ocenianie modeli także pod jej kątem. Nie musi być perfekcyjna od pierwszego dnia, ważne żeby w ogóle istniała i odzwierciedlała asymetrię błędów.

Nadmierne zaufanie do automatyzacji (AutoML, AutoFeatureItp.)

AutoML potrafi być ogromnym wsparciem, ale nie zastępuje zrozumienia danych ani zdrowego rozsądku. Błąd polega na traktowaniu go jak czarnej skrzynki: „wrzucimy CSV, wybierzemy metrykę, reszta się zrobi sama”.

Konsekwencje takiego podejścia:

• Brak kontroli nad leakage – automatyczne generowanie cech z danych czasowych bez świadomości, które kolumny są „przyszłościowe”. Wyniki w AutoML dashboardzie wyglądają świetnie, produkcja już nie.
• Model kompletnie nieinterpretowalny w kluczowych zastosowaniach – np. w kredytach powstaje złożony ensemble, którego nie da się wytłumaczyć regulatorowi ani klientowi.
• Optymalizacja pod „łatwą” metrykę – AutoML podbija ROC-AUC, bo jest to ustawione jako domyślny cel, ale ignoruje constrainty biznesowe: latency, koszt predykcji, pamięć.

Rozsądne użycie AutoML to potraktowanie go jako narzędzia do wstępnej eksploracji: szybkie benchmarki, inspiracje co do architektury czy cech. Ostateczny model i proces trenowania warto jednak zapanować ręcznie, szczególnie tam, gdzie w grę wchodzi odpowiedzialność prawna lub duże pieniądze.

Brak kontroli wersji eksperymentów i danych

Modele żyją w czasie. Dane się zmieniają, biblioteki się aktualizują, nowe feature’y wchodzą do pipeline’u. Bez ścisłej kontroli wersji bardzo trudno dojść, dlaczego nowy model jest gorszy (lub lepszy) i co faktycznie się zmieniło.

Bez tego pojawiają się klasyczne problemy:

• Niepowtarzalne eksperymenty – ktoś twierdzi, że „wczoraj miał 2 punkty ROC-AUC więcej”, ale nikt nie jest w stanie tego odtworzyć, bo seed, dane i parametry nie zostały zapisane.
• Cicha zmiana danych źródłowych – kolumna w bazie zmienia format albo zakres wartości, a pipeline i model udają, że wszystko jest po staremu.
• Brak historii metryk – nowy model jest wdrażany, bo „wydaje się lepszy”, mimo że nie ma jasnej, porównywalnej historii wyników z poprzednimi wersjami.

Narzędzia typu MLflow, DVC czy nawet dobrze zorganizowane repozytorium z configami i logami eksperymentów szybko spłacają dług. W połączeniu z sensownym nazewnictwem modeli i datasetów znikają dyskusje w stylu „który model to był ten dobry z zeszłego tygodnia?”.

Ignorowanie monitoringu i retrainingu

Nawet najlepiej wytrenowany model traci formę, gdy świat dookoła się zmienia. Drift danych, nowe typy użytkowników, zmiana interfejsu – to wszystko sprawia, że performance powoli (albo gwałtownie) spada. Błędem jest założenie, że raz wdrożony model będzie działał „aż się znudzi”.

Najczęstsze zaniedbania:

• Brak monitoringu rozkładów cech – nie ma alertów przy zmianach w inputach (np. pojawienie się nowych kategorii), dopóki ktoś ręcznie nie zajrzy do logów.
• Brak monitoringu metryk biznesowych i ML – nie śledzi się na bieżąco jakości predykcji, konwersji, odsetka błędów; pierwszym sygnałem problemu jest mail od wkurzonego klienta.
• Ad-hoc retraining – model jest przeuczany raz na kilka miesięcy „przy okazji”, bez jasnych kryteriów, kiedy i jak aktualizować parametry.

Bezpieczniejszy wzorzec to jasna polityka: jakie metryki są monitorowane, jakie progi uruchamiają alarmy i kiedy inicjowany jest retraining (np. co określony czas lub po wykryciu drastycznego drifta). Dzięki temu trenowanie modeli przestaje być jednorazowym projektem, a staje się powtarzalnym procesem.

Najczęściej zadawane pytania (FAQ)

Jakie są najczęstsze błędy przy trenowaniu modeli machine learning?

Najczęściej powtarzają się problemy na poziomie fundamentów: źle zdefiniowany cel biznesowy, niejasny target, przypadkowy dobór metryk i chaotyczny podział na zbiory train/validation/test. Zespół skupia się na wyborze modelu i hiperparametrów, a nie na tym, czy w ogóle mierzy właściwą rzecz.

Częste są też klasyki: data leakage (wykorzystywanie informacji z przyszłości lub z targetu), używanie accuracy przy skrajnie niezbalansowanych klasach, „tunowanie pod test” oraz przekonanie, że większy i bardziej skomplikowany model magicznie rozwiąże problemy słabych danych.

Co to jest data leakage i jak go uniknąć w trenowaniu modeli?

Data leakage to sytuacja, w której model w czasie trenowania widzi informacje, których nie będzie miał w realnym użyciu – np. cechy wyliczone z przyszłych zdarzeń albo zmienne bezpośrednio powiązane z targetem. Model uczy się wtedy „na skróty” i osiąga świetne wyniki na walidacji, ale spektakularnie zawodzi na produkcji.

Aby ograniczyć leakage, trzeba pilnować porządku czasowego (cechy mogą używać tylko danych z przeszłości względem momentu predykcji), rozdzielać dane użytkowników między zbiory oraz nie korzystać z kolumn, które są funkcją targetu. Dobrą praktyką jest osobny przegląd cech z pytaniem: „Czy tę informację naprawdę znamy w momencie podejmowania decyzji?”.

Jak poprawnie podzielić dane na train, validation i test?

W najprostszym scenariuszu dane dzieli się na trzy zbiory: train (trenowanie), validation (tuning, wybór modelu) i test (jednorazowa, końcowa ocena). Kluczowe jest, aby decyzje o architekturze i hiperparametrach zapadały na walidacji, a test był „święty” i nie służył do ciągłego podglądania wyników.

W problemach czasowych podział musi uwzględniać chronologię: starsze dane do trenowania, nowsze do walidacji i testu. W zadaniach z użytkownikami trzeba unikać mieszania danych tego samego użytkownika między zbiory, bo to zaniża ocenę realnego błędu. Jeśli danych jest mało, warto użyć cross-validation zamiast pojedynczego splitu.

Dlaczego accuracy to zła metryka przy niezbalansowanych danych?

Przy silnie niezbalansowanych klasach accuracy potrafi być kompletnie mylące. Model, który zawsze przewiduje klasę większościową, może mieć accuracy na poziomie 95–99%, mimo że nie rozpoznaje w ogóle klasy rzadkiej (np. fraudów). Na dashboardzie wygląda to świetnie, a w biznesie – katastrofa.

W takich przypadkach dużo ważniejsze są metryki skupione na klasie rzadkiej: precision, recall, F1, PR-AUC. Pozwalają ocenić, ile realnie wartościowych przypadków wykrywamy i jakim kosztem fałszywych alarmów. Accuracy może wtedy służyć co najwyżej jako ciekawostka, a nie główna miara sukcesu.

Jak dobrze zdefiniować zmienną celu (target) w modelu ML?

Dobry target musi mieć jasną, jednoznaczną definicję, zrozumiałą zarówno dla zespołu technicznego, jak i biznesu. Trzeba ustalić, co dokładnie oznacza „sukces” i w jakim horyzoncie czasowym – np. „czy klient dokona zakupu w ciągu 7 dni od wysłania oferty” zamiast ogólnego „czy kupi”.

Przy definiowaniu celu przydaje się krótka checklista: spójne etykietowanie (te same zasady dla wszystkich przypadków), jasny moment powstania targetu w czasie, brak mieszania różnych horyzontów (30 dni vs „kiedykolwiek”) oraz możliwość odtworzenia targetu z logów w przyszłości. Dobrze zrobiony target to mniej „magii” w modelach i mniej dziwnych niespodzianek przy wdrożeniu.

Jak uniknąć overfittingu przy trenowaniu modeli?

Overfitting najczęściej pojawia się, gdy model jest zbyt skomplikowany w stosunku do ilości i jakości danych albo gdy proces walidacji jest słaby. Model uczy się wtedy szumu, a nie reguł – w notebooku wynik wygląda fantastycznie, a na produkcji przychodzi szybkie zderzenie z rzeczywistością.

Aby temu przeciwdziałać, stosuje się m.in. solidny podział danych lub cross-validation, regularizację, ograniczanie złożoności modelu, early stopping i sensowny dobór cech. W praktyce często lepiej sprawdza się prostszy model na dobrze przygotowanych danych niż „wypasiona” sieć neuronowa na chaosie.

Jakie skutki biznesowe mogą mieć błędy w trenowaniu modeli ML?

Skutki są znacznie szersze niż tylko „trochę gorsze metryki”. Źle wytrenowany model to stracony czas zespołu (długie iteracje tuningu przy błędnym celu), niepotrzebne koszty infrastruktury, a czasem także realne straty – np. niewykryte fraudy, błędne decyzje kredytowe czy słabe rekomendacje, które zniechęcają klientów.

Dodatkowo źle działające modele podkopują zaufanie do całego ML w organizacji. Jeśli menedżerowie widzą, że „raz działa, raz nie”, traktują projekty data science jak eksperymenty bez kontroli. Paradoksalnie często wtedy inwestuje się w „lepsze algorytmy” i „mocniejsze GPU”, zamiast naprawić proces definiowania celu, danych i walidacji.

Najważniejsze punkty

• Trenowanie modeli ML to proces iteracyjny, a nie jednorazowy „strzał”; powtarzalne błędy w danych, cechach czy walidacji wbudowują się w cały workflow i później trudno je wykorzenić.
• Największy koszt błędów to nie tylko gorsze metryki, lecz stracony czas, pieniądze na infrastrukturę, utrata zaufania do ML oraz realne ryzyko biznesowe, gdy złe predykcje wpływają na decyzje w kredytach, fraudach czy medycynie.
• Pojedyncze „błędy ucznia” są mniej groźne niż utrwalone antywzorce (np. zawsze używamy accuracy, zawsze dzielimy dane 80/20, im większy model tym lepszy), bo te ostatnie automatyzują złe praktyki w całej organizacji.
• Kluczowe „pola minowe” to: definicja problemu i celu, jakość i spójność danych, data leakage, zła walidacja, niekontrolowana złożoność modelu, niewłaściwe użycie zbioru testowego oraz brak sensownego monitoringu po wdrożeniu.
• Bez jasno zdefiniowanego celu biznesowego (co dokładnie mierzymy, w jakim horyzoncie czasu, przy jakich ograniczeniach) nawet model z imponującym AUC może okazać się bezużyteczny w realnym procesie decyzyjnym.
• Źle zdefiniowana zmienna celu (odwrócone etykiety, niespójne oznaczanie przypadków, mieszanie horyzontów czasowych, target „z przyszłości” w cechach) podważa cały eksperyment – model uczy się czegoś, ale niekoniecznie tego, co faktycznie chcemy.