Brief pytań, które naprawdę trzeba sobie zadać przed czyszczeniem danych do ML: czy problem leży w modelu, czy w danych? Czy ta wartość jest błędem, czy rzadkim, ale prawdziwym przypadkiem? Czy brak danych coś znaczy, czy tylko przeszkadza? Czy etykieta jest wiarygodna? Czy poprawka nie wprowadza data leakage? Czy czyszczenie poprawi generalizację, czy tylko „upiększy” zbiór treningowy? Czy prawie identyczne rekordy nie przeciekają między train i test? Czy dane po czyszczeniu nadal przypominają to, co model zobaczy po wdrożeniu?
czyszczenie danych do ML, data leakage, błędne etykiety, brakujące dane, outliery w machine learning, duplikaty i near-duplicate, audyt danych przed treningiem, jakość danych treningowych, pipeline przygotowania danych, walidacja po czyszczeniu, dane tekstowe do ML, szeregi czasowe leakage
Czy model uczy się zależności, czy tylko błędów z danych
Pierwsze pytanie zwykle brzmi: czy model jest słaby, czy dane są złe. W praktyce bardzo często problem nie zaczyna się od algorytmu. Zaczyna się od etykiet, źle zrobionego splitu, braków danych, duplikatów albo cech, które niosą wiedzę z przyszłości.
Czyszczenie danych do ML nie polega na tym, żeby tabela wyglądała estetycznie. Chodzi o coś innego: usunąć lub ograniczyć takie zniekształcenia, przez które model uczy się fałszywych wzorców. To zasadnicza różnica. Ładny zbiór danych może dawać gorszy model niż zbiór mniej elegancki, ale bliższy warunkom produkcyjnym.
W analityce BI często priorytetem jest spójny raport, poprawne sumy, brak pustych pól i jednolity format. W ML liczy się przede wszystkim to, czy po przygotowaniu danych model uogólnia na nowe przypadki. Można mieć tabelę bez nulli i bez oczywistych błędów, a mimo to model będzie się mylił, bo nauczył się skrótów, przecieków albo skutków zamiast przyczyn.
Po czym poznać, że model przejmuje błędy z danych
Najbardziej typowy sygnał to bardzo dobry wynik na train i wyraźnie gorszy na walidacji. Sam overfitting nie zawsze oznacza problem jakości danych, ale często jest pierwszym objawem. Jeśli po zmianie algorytmu wynik nadal się nie stabilizuje, warto przestać kręcić gałkami modelu i wrócić do danych.
Drugi sygnał to niestabilne predykcje. Mała zmiana w rekordzie powoduje dużą zmianę wyniku, choć biznesowo nie powinna. Często oznacza to, że model opiera się na przypadkowych korelacjach: na błędnie zakodowanej kategorii, na polu pochodnym od etykiety albo na rzadkim artefakcie procesu zbierania danych.
Trzeci sygnał jest zdradliwy: zaskakująco dobre wyniki z podejrzanych pól. Jeśli cecha wydaje się zbyt „magiczna”, trzeba sprawdzić, kiedy powstała i czy była dostępna w momencie predykcji. Pole „data zamknięcia sprawy” może znakomicie przewidywać wynik procesu, ale tylko dlatego, że powstaje po fakcie.
Ładny dataset to nie to samo co dobry zbiór treningowy
W ML zbyt agresywne czyszczenie też bywa błędem. Jeśli usuniesz wszystkie trudne, brudne i niejednoznaczne przypadki, model nauczy się świata prostszego niż produkcja. Potem trafi na rekord z brakującym polem, literówką, nietypową wartością albo opóźnionym eventem i przestanie działać przewidywalnie.
Idealnie czyste dane mogą być gorsze niż realistyczne dane produkcyjne. To szczególnie ważne w systemach scoringowych, obsłudze zgłoszeń, NLP i danych operacyjnych. Produkcja rzadko jest sterylna. Jeśli pipeline treningowy zakłada sterylność, problem wyjdzie dopiero po wdrożeniu.
Dlatego przy każdej poprawce trzeba pytać nie tylko „czy to wygląda lepiej”, ale też „czy model powinien to zobaczyć”. Literówki w nazwach produktów mogą być zwykłym szumem albo ważnym sygnałem zachowania użytkownika. Brak dokumentu może oznaczać błąd integracji albo cechę istotną dla ryzyka. Bez kontekstu łatwo usunąć to, czego model właśnie powinien się nauczyć.
Cztery pytania, które prowadzą przez każdą decyzję
Praktyczny filtr jest prosty. Przy każdym problematycznym polu albo rekordzie dobrze zadać cztery pytania:
- Czy to błąd, czy prawdziwy przypadek?
- Czy model ma się tego nauczyć?
- Czy poprawka nie tworzy leakage?
- Czy problem dotyczy wejścia, etykiety czy splitu?
To ostatnie pytanie bywa pomijane. A przecież model może być „zepsuty” nie przez surowe cechy, tylko przez złą definicję targetu, konflikt etykiet albo przez to, że niemal te same rekordy są po obu stronach podziału. Czyszczenie danych do ML bez rozdzielenia tych trzech warstw często kończy się chaosem.
Zacznij od celu modelu i podziału danych, nie od kasowania nulli
Kolejność prac, która chroni przed chaosem
Najpierw trzeba ustalić co model przewiduje, dla kogo i w jakim momencie. To nie jest formalność. Bez tej odpowiedzi nie da się rozstrzygnąć, czy dana cecha jest legalna, czy jest przeciekiem z przyszłości, czy brak wartości to problem techniczny, czy sensowny sygnał.
Przykład: model ma przewidywać, czy klient spłaci zobowiązanie. Jeśli cecha zawiera informację o działaniach windykacyjnych uruchomionych później, to nie jest „dobra zmienna”. To klasyczne leakage. Bez ustalenia momentu predykcji łatwo wciągnąć do modelu pola, które istnieją dopiero po zdarzeniu docelowym.
Dopiero po zdefiniowaniu zadania ma sens audyt źródeł danych. Trzeba wiedzieć, skąd biorą się cechy, kiedy są zapisane, czy pochodzą z jednego procesu, czy z wielu systemów, kto nadaje etykiety i czy ten proces jest spójny. Wiele problemów jakościowych nie wynika z samych wartości, tylko z procesu ich powstawania.
Kolejny krok to podział na train, validation i test. Reguły imputacji, skalowania, mapowania kategorii i inne transformacje wolno dopasowywać wyłącznie na train. Jeśli statystyki liczysz na całym zbiorze, nawet bez złej intencji możesz poprawić wynik w sposób, którego nie da się powtórzyć poza eksperymentem.
Moment predykcji decyduje o tym, co jest błędem
Ta sama kolumna może być poprawna w jednym zadaniu i niedozwolona w drugim. Pole „status wniosku po 30 dniach” nadaje się do analizy procesu, ale nie do modelu, który ma podjąć decyzję w dniu złożenia wniosku. Dlatego czyszczenie danych do ML zaczyna się od czasu i kontekstu, nie od listy nulli.
To samo dotyczy etykiety. Jeśli target jest niejednoznaczny, każdy późniejszy etap staje się podejrzany. Model nie odróżni dobrego wzorca od błędnego, jeśli pozytywna klasa raz oznacza „fraud potwierdzony”, a innym razem „transakcja ręcznie zatrzymana do sprawdzenia”. Najpierw trzeba ustabilizować znaczenie targetu.
Przy danych procesowych dobrze rozpisać oś czasu: które pola są dostępne przy predykcji, które pojawiają się później, które są aktualizowane wielokrotnie, a które są nadpisywane. Taki prosty audyt często wykrywa najgroźniejsze przecieki jeszcze przed treningiem modelu.
Split trzeba zaplanować wcześnie, zwłaszcza przy czasie i encjach
W danych tabelarycznych łatwo ulec pokusie losowego podziału. To czasem działa, ale nie zawsze. Jeśli jeden klient ma wiele rekordów, to losowy split może rozrzucić bardzo podobne przypadki między train i walidację. Wynik będzie wyglądał dobrze, bo model w praktyce rozpoznaje klienta, a nie uczy się reguły.
Przy danych czasowych kolejność jest ważniejsza niż „ładne” rozkłady. Jeśli prognozujesz przyszłość, walidacja też musi leżeć w przyszłości względem treningu. Inaczej nawet uczciwe transformacje mogą nieświadomie korzystać z informacji, która w realnym użyciu nie byłaby dostępna.
Dotyczy to także danych tekstowych. Jeśli ten sam dokument, ticket, reklamacja albo wiadomość pojawia się w kilku wersjach, łatwo dopuścić near-duplicate do różnych części zbioru. Model wtedy nie generalizuje języka ani sensu, tylko zapamiętuje niemal te same sekwencje.
Krótki scenariusz: wynik znika po poprawnym podziale czasowym
Typowy przypadek to prognoza szeregu czasowego lub model scoringowy z agregatami. Na całym zbiorze ktoś policzył średnią aktywność użytkownika z całego miesiąca, a model ma przewidywać zdarzenie z początku tego miesiąca. Wynik wygląda świetnie. Po poprawnym splicie czasowym i przeliczeniu cechy tylko z przeszłości skuteczność spada.
To nie znaczy, że model się pogorszył. To znaczy, że dopiero teraz zaczął być uczciwie oceniany. Taki spadek jest bolesny, ale cenny. Lepiej zobaczyć go na etapie przygotowania danych niż po wdrożeniu.
Szybki audyt danych przed treningiem
Krótka checklista, która wyłapuje większość problemów
Zanim zacznie się poprawianie rekordów, dobrze zrobić szybki audyt. Nie chodzi o wielotygodniowy projekt jakości danych. Chodzi o serię prostych pytań, które wyłapują najczęstsze źródła błędów modelu.
- Czy etykieta jest zdefiniowana jednoznacznie i zgodnie z celem modelu?
- Czy te same encje, duplikaty lub near-duplicate nie występują po obu stronach splitu?
- Czy brakujące dane są losowe, czy wynikają z procesu, kanału, segmentu klienta albo okresu?
- Czy jednostki, formaty i zakresy są spójne między źródłami?
- Czy występują kody zastępcze typu 0, 999, „brak”, „unknown”, które trzeba odróżnić od prawdziwej wartości?
- Czy któraś cecha nie zawiera wiedzy z przyszłości albo efektu procesu po zdarzeniu docelowym?
- Czy rozkłady train i walidacji różnią się naturalnie, czy wskazują na błąd splitu lub drift?
- Czy w danych są wartości niemożliwe fizycznie albo biznesowo?
Taka checklista nie zastąpi analizy, ale porządkuje pracę. Największy zysk daje wtedy, gdy zespół ma pokusę, by od razu trenować model i „zobaczyć, co wyjdzie”. W ML to często strata czasu. Słaby model na brudnych danych rzadko mówi, gdzie naprawdę jest problem.
Co dokumentować już na tym etapie
Reguły czyszczenia danych trzeba zapisywać od początku. Nie jako luźne notatki, tylko jako listę decyzji z uzasadnieniem. Na przykład: „kolumna X zawiera 999 jako kod braku, mapujemy na null”; „rekordy z datą zamówienia późniejszą niż data dostawy traktujemy jako błąd procesu i usuwamy”; „brak pola Y oznaczamy dodatkową flagą, bo sam brak niesie informację”.
Dobrze oddzielić decyzje twarde od eksperymentalnych. Twarde to takie, które wynikają z logiki danych lub procesu biznesowego. Eksperymentalne to na przykład różne warianty obchodzenia się z outlierami albo kilka sposobów imputacji. Taki podział ułatwia porównanie wyników i zmniejsza ryzyko, że po kilku iteracjach nikt już nie wie, co naprawdę zostało zmienione.
Równie ważna jest odtwarzalność. Jeśli czyszczenie odbywa się ręcznie w notatniku, łatwo utracić kontrolę nad wersjami. Pipeline przygotowania danych powinien pozwalać odtworzyć wariant „przed” i „po”, policzyć te same metryki i wrócić do wcześniejszej decyzji, jeśli okaże się szkodliwa.
Audyt ma wykrywać źródła błędów, a nie tylko defekty tabeli
Wiele osób sprawdza unikalne wartości, procent nulli i podstawowe statystyki. To dobry początek, ale za mało. Potrzebne jest jeszcze pytanie: czy dany problem ma wpływ na uczenie modelu. Null w kolumnie pomocniczej może nie mieć znaczenia. Ten sam null w polu, które jest systemowo puste tylko dla jednej klasy, może być kluczowym sygnałem lub źródłem stronniczości.
Dobry audyt patrzy też na zależności. Nie wystarczy wiedzieć, że w kolumnie A jest 20% braków. Trzeba sprawdzić, czy te braki częściej pojawiają się w określonym czasie, kanale sprzedaży, typie klienta albo klasie targetu. Wtedy wiadomo, czy to zwykły brak, czy element procesu, którego model może się nauczyć.
Braki danych, duplikaty i niespójne formaty — problem częstszy niż sam model
Brakujące dane — usuwać, imputować czy oznaczać flagą
Brakujące dane to jedna z najczęstszych przyczyn złego modelu, ale nie dlatego, że null sam w sobie jest straszny. Problem polega na tym, że różne rodzaje braków znaczą co innego. Bez tego rozróżnienia łatwo zaszkodzić modelowi bardziej niż samym brakiem.
Pierwszy przypadek to brak losowy. Pole nie zostało zapisane przypadkiem, awaria była chwilowa, brak nie wiąże się z klasą ani segmentem. Tu imputacja może być sensowna, o ile nie zaciera ważnego sygnału. Drugi przypadek to brak systemowy. Na przykład dane z jednego kanału nigdy nie zawierają pewnego pola. Wtedy brak jest informacją o źródle lub procesie.
Trzeci przypadek to brak biznesowo znaczący. Brak dokumentu, brak odpowiedzi klienta, brak aktywności, brak historii zakupów. W takich sytuacjach imputowanie średnią czy medianą często niszczy znaczenie. Lepiej zostawić brak i dodać flagę, która mówi modelowi, że brak sam jest cechą.
Czwarty przypadek to brak wynikający z definicji. Nie każda wartość musi istnieć dla każdego rekordu. Na przykład liczba rat nie dotyczy produktu jednorazowego. Taki brak nie jest błędem jakości danych, tylko konsekwencją struktury procesu. Trzeba go traktować świadomie, a nie mechanicznie uzupełniać.
W praktyce dobrze sprawdza się prosta zasada: najpierw ustalić dlaczego pole jest puste, dopiero potem wybierać technikę. Ten sam zabieg nie nadaje się do każdego braku. Mediana bywa rozsądna dla stabilnej cechy liczbowej, ale już dla pola zależnego od produktu, kanału albo etapu procesu może wprowadzić sztuczny wzorzec, którego w rzeczywistości nie ma.
Trzeba też uważać, żeby imputację liczyć wyłącznie na danych treningowych. To drobiazg, który często psuje ocenę modelu. Jeśli średnia, mediana albo najczęstsza wartość są wyznaczane na całym zbiorze przed splitem, do pipeline’u trafia przeciek. Niewielki, ale wystarczający, by wynik był lepszy niż powinien.
Podobnie z duplikatami i formatami. Duplikat nie zawsze oznacza „usuń wszystko poza jednym rekordem”. Czasem to faktyczne powtórzenie importu, a czasem dwa etapy tego samego zdarzenia. Najpierw trzeba ustalić klucz encji i regułę czasu. Dopiero wtedy da się odróżnić dubel techniczny od poprawnej historii procesu.
Niespójne formaty zwykle wyglądają niewinnie, a potrafią zniszczyć cechy po cichu. Kwota raz zapisana z przecinkiem, raz z kropką, data w dwóch strefach czasowych, kategorie różniące się spacją albo wielkością liter — model widzi to jako różne wartości. Dlatego przed treningiem trzeba ujednolicić typy, jednostki i słowniki. To często daje większy zysk niż kolejna iteracja strojenia hiperparametrów.
Najrozsądniejszy kolejny krok jest prosty: wziąć mały wycinek danych, rozpisać reguły czyszczenia z uzasadnieniem i przepuścić przez nie cały pipeline od splitu po walidację. Jeśli po takim porządku wynik spada, ale staje się stabilny i zrozumiały, to zwykle znak, że model wreszcie uczy się sygnału, a nie bałaganu.
Wartości odstające i przypadki graniczne — kiedy nie ruszać danych
Najważniejsze pytanie brzmi tu prosto: czy to błąd zapisu, czy rzadki, ale prawdziwy przypadek. Te dwie rzeczy wyglądają podobnie na wykresie, ale dla modelu znaczą coś innego.
Jeśli wiek klienta wynosi 350 lat, to prawdopodobnie błąd. Jeśli zamówienie ma wyjątkowo wysoką wartość, nie musi to być problem. Może właśnie taki rekord odróżnia ważny segment od reszty.
Jak odróżnić błąd od sygnału
Najpierw sprawdza się zgodność z logiką procesu. Wartości fizycznie niemożliwe, daty odwrócone, ujemna liczba produktów tam, gdzie nie ma zwrotu — to zwykle kandydaci do poprawy albo usunięcia.
Potem kontekst. Ten sam outlier może być normalny w jednym segmencie i podejrzany w innym. W danych transakcyjnych wysoka kwota dla klienta firmowego może być typowa, a dla mikropłatności już nie.
Dobrze też sprawdzić, czy wartości odstające skupiają się w jednym źródle, okresie albo integracji. Jeśli tak, częściej chodzi o błąd techniczny niż o realny wzorzec.
Co robić zamiast automatycznego obcinania
Proste usunięcie skrajnych wartości bywa kuszące, ale łatwo w ten sposób wyciąć to, czego model powinien się nauczyć. Rozsądniej rozważyć kilka wariantów i porównać wynik walidacji.
Czasem wystarczy ograniczenie do sensownego zakresu biznesowego. Czasem lepsza jest transformacja, na przykład logarytm dla mocno skośnych kwot. A czasem najlepsza decyzja to zostawić dane bez zmian, ale dodać flagę „przypadek skrajny”.
Jeśli model ma działać w produkcji na trudnych, rzadkich obserwacjach, zbyt agresywne czyszczenie zrobi mu krzywdę. Wynik w walidacji może wyglądać ładniej, ale model będzie gorzej reagował na rzeczywistość.
Błędne etykiety psują model szybciej niż brudne cechy
Model uczy się przede wszystkim relacji między wejściem a targetem. Jeśli target jest zły, nawet idealnie wyczyszczone cechy nie pomogą.
To częsty problem w klasyfikacji: reklamacja zamknięta jako „bezzasadna”, choć później została uznana; ticket przypisany do złej kategorii; churn oznaczony bez uwzględnienia opóźnień w danych. Wtedy model nie dostaje trudnych przykładów. Dostaje sprzeczne instrukcje.
Po czym poznać, że problem może leżeć w etykietach
Jedna wskazówka to rekordy, na których model regularnie „myli się” w ten sam sposób, a człowiek po przeglądzie uznaje predykcję modelu za sensowną. Druga to wysoka niezgodność między anotatorami albo między systemami źródłowymi.
Sygnałem bywa też niska stabilność wyniku po drobnych zmianach danych. Jeśli model raz działa dobrze, a po małej korekcie gwałtownie traci skuteczność, przyczyną może być właśnie szum etykiet.
Jak ograniczać błędy etykiet bez wielkiego projektu
Nie trzeba od razu ręcznie przeglądać całego zbioru. Często wystarczy przejrzeć próbkę rekordów z najwyższą stratą, z niską pewnością etykiety albo z konfliktem między regułą biznesową a targetem.
Pomaga też rozdzielenie przypadków niejednoznacznych. Zamiast zmuszać model do nauki na spornej klasie, lepiej czasem odłożyć takie rekordy do osobnego koszyka i zdecydować, czy w ogóle powinny trafiać do treningu.
Jeśli etykieta powstaje z reguły czasowej, trzeba jeszcze sprawdzić opóźnienia. Typowy błąd to oznaczanie klienta jako „brak zdarzenia”, chociaż okno obserwacji było za krótkie i zdarzenie pojawiło się później.
Leakage nie kończy się na oczywistych kolumnach z przyszłości
Najłatwiej wykryć cechę wprost zdradzającą target. Trudniej zauważyć przeciek ukryty w procesie przygotowania danych.
Leakage pojawia się wtedy, gdy decyzja o czyszczeniu lub transformacji korzysta z informacji, której model nie będzie miał w momencie predykcji. To może być globalna imputacja, słownik kategorii zbudowany na pełnym zbiorze, normalizacja policzona z walidacją, ale też ręczna korekta rekordów po obejrzeniu targetu.
Typowe miejsca, w których przeciek wchodzi tylnymi drzwiami
W danych tabelarycznych często problemem są agregaty. Na przykład liczba wcześniejszych zamówień policzona z całej historii, choć predykcja ma zapadać w połowie tej historii.
W tekście przeciek potrafi wejść przez metadane. Nazwa pliku, znacznik workflow, status dodany po obsłudze sprawy — to rzeczy, które wyglądają niewinnie, ale zdradzają wynik.
W szeregach czasowych problemem bywa wygładzanie albo uzupełnianie luk z użyciem przyszłych punktów. Statystycznie wygląda elegancko, operacyjnie jest nieuczciwe.
Różne typy danych czyści się inaczej
Dane tabelaryczne
Tu najwięcej szkód robią kody zastępcze, mieszanie jednostek i niespójne słowniki kategorii. Trzeba sprawdzić, czy 0 oznacza prawdziwe zero, czy brak; czy „Warszawa”, „warszawa” i „Warszawa ” to ta sama wartość; czy kwota jest zawsze w tej samej walucie.
Przy cechach liczbowych dobrze porównać zakresy i rozkłady między źródłami. Przy kategoriach — częstość i udział nowych wartości między train a walidacją. To szybko pokazuje, czy problem leży w danych, a nie w modelu.
Dane tekstowe
Czyszczenie tekstu nie powinno zamieniać go w sterylny ciąg tokenów. Usunięcie wszystkich znaków specjalnych, wielkości liter, numerów czy krótkich słów czasem kasuje sens. W zgłoszeniach serwisowych numer błędu albo kod produktu bywa ważniejszy niż reszta zdania.
Najpierw trzeba ustalić, co w tekście jest nośnikiem informacji. Dopiero potem decydować, co usuwać. Spam, boilerplate i techniczne stopki często warto odfiltrować. Nazwy modułów, identyfikatory, skróty branżowe — już niekoniecznie.
Tu szczególnie groźne są near-duplicate. Kilka niemal identycznych ticketów potrafi sztucznie podbić wynik, jeśli trafią do różnych części zbioru.
Szeregi czasowe
W czasie najważniejsza jest kolejność i dostępność informacji w danym momencie. Luki w danych nie zawsze wolno wypełniać dowolnie. Forward fill może mieć sens, jeśli taka wartość naprawdę byłaby znana w przyszłym kroku. Interpolacja między przeszłością a przyszłością już nie zawsze.
Trzeba też uważać na zmianę sposobu pomiaru. Jeśli sensor zaczął raportować w innej częstotliwości albo system zmienił definicję pola, model może nauczyć się różnicy technicznej zamiast zjawiska.
Bias, nierównowaga klas i drift też są problemem jakości danych
Nie każdy błąd wygląda jak literówka albo null. Czasem dane są poprawne technicznie, ale reprezentują świat w sposób, który psuje model.
Jeśli jedna klasa występuje bardzo rzadko, model może nauczyć się ją ignorować. Jeśli dane historyczne pochodzą głównie z jednego kanału albo regionu, predykcje dla innych segmentów będą słabsze. Jeśli produkcja różni się od treningu, nawet czysty zbiór startowy nie wystarczy.
Dlatego podczas audytu dobrze porównywać nie tylko ogólne statystyki, ale też skład zbioru według czasu, segmentu, źródła i klasy. To pomaga odróżnić problem algorytmu od problemu reprezentacji danych.
Skąd wiedzieć, że czyszczenie naprawdę pomogło
Nie po tym, że tabela wygląda ładniej. Liczy się to, czy model po zmianach lepiej generalizuje i zachowuje się stabilniej.
Najprostszy test to porównanie wariantu przed i po na tym samym, uczciwym splicie. Jeśli metryka lekko spada, ale wynik między foldami lub okresami staje się równiejszy, to często dobry znak. Model przestaje korzystać z przypadku.
Przydają się też sanity checks. Czy najważniejsze cechy nadal mają sens biznesowy? Czy model nie opiera się na polu, które powinno być pomocnicze? Czy błędy koncentrują się w tych samych segmentach co wcześniej, czy zmienił się ich charakter?
Dobrze porównać też kilka prostych rzeczy poza metryką główną: udział odrzuconych rekordów, zmianę rozkładów, liczbę nowych kategorii w walidacji, stabilność predykcji między okresami. To pokazuje, czy czyszczenie usuwa źródło problemu, czy tylko przesuwa go gdzie indziej.
Najbardziej użyteczny kolejny krok jest zwykle mały: wybrać jedną klasę problemu, na przykład etykiety albo near-duplicate, zapisać regułę w pipeline i sprawdzić wynik na niezmienionym splicie. Tak buduje się zbiór, który uczy model rzeczywistych zależności, a nie błędów procesu.
Dokumentuj reguły, bo „ręczne poprawki” psują powtarzalność
Jeśli ten sam rekord dziś poprawiasz inaczej niż tydzień temu, problem nie jest już tylko w danych. Jest w procesie.
Dobra reguła czyszczenia powinna dać się zapisać tak, żeby druga osoba odtworzyła wynik bez zgadywania. Nie „poprawiono dziwne wartości”, tylko: „wiek < 0 ustawiany na brak”, „duplikaty usuwane po kluczu X i najnowszym timestampie”, „kategoria z częstością poniżej progu mapowana do innej klasy tylko w train”.
To ważne z dwóch powodów. Po pierwsze, łatwiej porównać eksperymenty przed i po zmianie. Po drugie, taki sam pipeline można potem uruchomić na nowych danych, bez cichego rozjazdu między treningiem a produkcją.
Kiedy flaga jest lepsza niż korekta
Nie każdą podejrzaną wartość trzeba naprawiać. Czasem lepiej zachować oryginał i dodać informację, że rekord jest nietypowy.
To działa dobrze przy brakach, skrajnych wartościach i polach z wątpliwą jakością. Przykład: jeśli część adresów ma niepełny kod pocztowy, sama niepełność może być sygnałem. Po „upiększeniu” model tę informację traci.
Prosta kolejność decyzji przy każdym problematycznym polu
Zamiast czyścić wszystko jednakowo, lepiej przejść przez kilka pytań. Krótko i bez zgadywania:
- czy to błąd techniczny, czy rzadki, ale prawdziwy przypadek,
- czy ta informacja będzie dostępna w momencie predykcji,
- czy problem dotyczy cechy, etykiety czy samego podziału danych,
- czy lepiej usunąć rekord, poprawić wartość, imputować czy tylko dodać flagę,
- czy regułę da się zastosować identycznie na nowych danych.
Taki filtr zwykle ogranicza dwa częste błędy: nadmierne czyszczenie oraz poprawki oparte na wiedzy z całego zbioru.
Mały eksperyment jest lepszy niż duże porządki
Przy słabym modelu łatwo wpaść w serię zmian naraz: imputacja, usuwanie outlierów, nowe mapowanie kategorii, korekta etykiet. Potem nie wiadomo, co pomogło, a co zaszkodziło.
Bezpieczniej zmieniać jedną rzecz na raz. Na przykład najpierw usunąć near-duplicate między train i walidacją. Potem osobno przetestować korektę kodów zastępczych braków. Jeśli wynik się poprawia, wiadomo, gdzie był realny problem.
To szczególnie ważne wtedy, gdy metryka rośnie mocno i nagle. Duży skok nie zawsze oznacza lepszy model. Czasem oznacza, że przypadkiem otwarto drogę do leakage albo uproszczono zbiór tak bardzo, że walidacja przestała przypominać produkcję.
Na co patrzeć oprócz głównej metryki
Jeśli model po czyszczeniu ma lepszy AUC albo F1, to jeszcze nie zamyka tematu. Dobrze sprawdzić, czy nie pogorszył się na trudnych segmentach, nowych okresach albo rzadkiej klasie.
Praktyczny test to porównanie błędów dla tych samych grup co wcześniej sprawiały kłopot: nowi klienci, krótkie tickety, rekordy z brakami, obserwacje z końca szeregu czasowego. Często tam widać, czy model naprawdę nauczył się lepszej zależności.
Kiedy nie czyścić zbyt agresywnie
Są dane, które wyglądają brzydko, ale dobrze opisują rzeczywistość. Literówki użytkowników, skróty w zgłoszeniach, nieregularne odstępy czasu, rzadkie kategorie — to bywa normalny obraz produkcji.
Jeśli system wejściowy generuje taki bałagan na co dzień, model też powinien go znać. Zbyt sterylny trening daje ładny wynik w notebooku i gorsze zachowanie po wdrożeniu.
Dobrym znakiem ostrzegawczym jest pytanie: czy po tej poprawce dane nadal wyglądają jak te, które naprawdę przyjdą jutro? Jeśli nie, czyszczenie poszło za daleko.
Najczęstszy błąd: poprawianie danych bez poprawienia definicji problemu
Bywa, że dane są czyszczone poprawnie technicznie, a model nadal uczy się złej rzeczy. Powód leży wyżej: źle zdefiniowany target, zły moment predykcji albo błędny split.
Przykład z praktyki: model churn dostaje etykietę zbyt wcześnie, zanim część klientów miała szansę wykonać jeszcze jedną aktywność. Czyszczenie braków i outlierów niewiele tu zmieni. Najpierw trzeba poprawić definicję okna obserwacji i targetu.
Dlatego gdy kolejne porządki nie dają efektu, dobrze wrócić do trzech podstaw: co przewidujesz, z jakiego momentu i na jakich danych dostępnych wtedy naprawdę operujesz. Często tam siedzi główne źródło błędu.
Jak odróżnić problem danych od problemu modelu
Jeśli model raz działa dobrze, a raz bardzo źle, nie zawsze winny jest algorytm. Często sygnał ostrzegawczy widać wcześniej: predykcje są niestabilne po małej zmianie splitu, ważność cech wygląda podejrzanie albo błędy skupiają się w jednym źródle danych.
Dobry test jest prosty. Uruchom bardzo prosty model bazowy na tym samym zbiorze. Jeśli prosty model zachowuje się podobnie do bardziej złożonego, problem bywa w danych. Jeśli tylko złożony model „wygrywa” i to o podejrzanie dużo, trzeba sprawdzić leakage, duplikaty i cechy pochodzące z przyszłości.
Pomaga też ręczny przegląd błędów. Nie dziesiątek tysięcy rekordów, tylko małej próbki: poprawne predykcje, duże pomyłki, przypadki graniczne. W takich miejscach szybko wychodzą złe etykiety, mylące formaty i rekordy, które nie powinny znaleźć się w treningu.
Etykiety psują model częściej niż braki danych
Brak w kolumnie łatwo zauważyć. Zła etykieta już nie. A to ona często najbardziej szkodzi, bo model dostaje sprzeczne przykłady i zaczyna uczyć się szumu.
W praktyce problem wygląda zwykle tak: podobne rekordy mają różne targety bez jasnego powodu, część etykiet powstała według starej definicji, a część według nowej, albo anotacja była subiektywna i niespójna między osobami.
Nie trzeba od razu robić pełnego relabelingu. Często wystarczy znaleźć najbardziej podejrzane przypadki: rekordy, które model konsekwentnie klasyfikuje odwrotnie niż etykieta, albo grupy bardzo podobnych obserwacji z różnymi targetami. To dobry punkt startu do przeglądu.
Co robić z niejednoznacznym targetem
Jeśli nawet człowiek nie potrafi łatwo zdecydować, jaka etykieta jest poprawna, problem leży w definicji zadania albo w regule anotacji. Samo „doczyszczenie” cech niewiele pomoże.
W takich sytuacjach sensowne są trzy ruchy: doprecyzować definicję etykiety, wydzielić klasę „niejednoznaczne” albo odłożyć te rekordy poza główny trening i użyć ich później do testów odporności. To lepsze niż zmuszanie modelu do nauki z losowo opisanych przypadków.
Leakage najczęściej pojawia się w zwykłych, niewinnych krokach
Data leakage nie musi wyglądać spektakularnie. Czasem wystarczy policzyć średnią na całym zbiorze przed splitem, znormalizować kategorię z użyciem walidacji albo usunąć rzadkie klasy po spojrzeniu na dane testowe.
Najbezpieczniejsza zasada jest prosta: każdą regułę, która „uczy się” czegokolwiek z danych, dopasowuj tylko na train. Dotyczy to imputacji, skalowania, grupowania kategorii, progów dla outlierów, a nawet reguł odfiltrowania niektórych rekordów, jeśli te reguły wynikają z rozkładu danych.
W danych czasowych kontrola musi być jeszcze ostrzejsza. Jeśli rekord z marca korzysta z informacji podsumowanej z kwietnia, model dostaje odpowiedź zanim pojawi się pytanie.
Krótki przykład błędu, który łatwo przeoczyć
W modelu fraudowym pole „liczba reklamacji klienta” może wyglądać niewinnie. Jeśli jednak policzono je na pełnej historii, także po dacie ocenianej transakcji, cecha przestaje opisywać stan klienta w chwili decyzji. Taki model zwykle ma świetną walidację i słabszą produkcję.
Reguły czyszczenia powinny być częścią pipeline’u, nie notatką obok
Jeśli czyszczenie dzieje się ręcznie w arkuszu albo jednorazowo w notebooku, szybko traci się kontrolę. Trudno wtedy odpowiedzieć, dlaczego wynik z zeszłego tygodnia był lepszy i czy nowy zbiór został potraktowany tak samo.
Lepsze podejście to zapisanie reguł jako kroków transformacji. Najpierw split, potem czyszczenie zależne od train, później walidacja i test. Dzięki temu łatwo porównać eksperymenty, odtworzyć wynik i sprawdzić, czy produkcja nie dostaje innej logiki niż trening.
To nie musi być rozbudowany system. Wystarczy, że dla każdej reguły da się odpowiedzieć: skąd się wzięła, kiedy działa, na których polach i czy używa informacji niedostępnej w momencie predykcji.
Dwa krótkie testy przed uznaniem danych za „gotowe”
Pierwszy test: czy kilka losowych rekordów po wszystkich transformacjach nadal wygląda jak dane, które mógłby zobaczyć użytkownik albo system źródłowy. Jeśli nie, czyszczenie mogło odciąć zbyt dużo realnego szumu.
Drugi test: czy ten sam pipeline można bez zmian uruchomić jutro na nowej paczce danych. Jeśli odpowiedź brzmi „prawie, ale trzeba coś ręcznie poprawić”, problem nadal nie jest rozwiązany.
W praktyce to zwykle lepszy znak jakości niż idealnie gładkie histogramy. Model nie ma uczyć się danych ładnych. Ma uczyć się danych prawdziwych, tylko bez tych błędów, które fałszują zależność.
Jak czyścić dane tekstowe, żeby nie wyciąć sensu razem z hałasem
W tekście najłatwiej pomylić porządek z utratą informacji. Usunięcie znaków specjalnych, sprowadzenie wszystkiego do małych liter albo agresywne filtrowanie krótkich tokenów bywa wygodne, ale nie zawsze bezpieczne.
Pytanie brzmi: czy model ma rozumieć idealnie zapisany tekst, czy taki, jaki realnie wpisują użytkownicy. Jeśli w produkcji trafiają literówki, skróty i nieregularna interpunkcja, pełne wygładzenie treningu może zaszkodzić.
Dobry przykład to zgłoszenia supportowe. Usunięcie wszystkich liczb może skasować numery błędów. Z kolei łączenie różnych wariantów pisowni produktu może pomóc, jeśli naprawdę oznaczają to samo. Reguła powinna wynikać z celu, nie z estetyki tekstu.
Co zwykle ma sens w tekstach
Najczęściej pomagają proste, powtarzalne reguły: ujednolicenie kodowania, usunięcie pustych rekordów, naprawa oczywistych błędów technicznych po ekstrakcji i oznaczenie pól, które przyszły puste albo uszkodzone.
Ostrożniej z usuwaniem stop words, stemmingiem czy lematyzacją. Dla jednych zadań poprawią sygnał, dla innych usuną różnice ważne dla targetu. W klasyfikacji intencji słowa funkcyjne czasem niewiele dają, ale w analizie skarg mogą zmieniać ton albo znaczenie zdania.
Dane czasowe wymagają innego porządku niż dane tabelaryczne
W szeregach czasowych czyszczenie bez osi czasu prawie zawsze kończy się błędem. Najpierw trzeba ustalić, co było znane w danym momencie, a dopiero potem poprawiać braki, odstające skoki i agregacje.
Brak odczytu z sensora nie jest tym samym co wartość równa zero. Jeśli oba przypadki zleją się w jedną liczbę, model nauczy się fałszywego wzorca. Podobnie z dosztukowaniem brakujących punktów przez interpolację na całym przebiegu, gdy część danych pochodzi z przyszłości względem predykcji.
W praktyce lepiej rozdzielać trzy sytuacje: brak pomiaru, pomiar równy zero i pomiar podejrzany technicznie. Często sama flaga jakości pomiaru daje modelowi więcej niż agresywne „naprawienie” szeregu.
Przypadki graniczne na końcu okna obserwacji
Końcówki szeregu często wyglądają gorzej: są niepełne, opóźnione albo jeszcze niesfinalizowane. To nie zawsze błąd danych. Czasem to dokładnie ten stan niepewności, z którym model spotka się w produkcji.
Jeśli takie rekordy usuniesz z treningu, walidacja może się poprawić, ale model straci odporność na realne wejście. Lepiej wydzielić je do osobnego testu i sprawdzić, jak bardzo psują wynik.
Bias i nierównowaga klas też są problemem jakości danych
Nie każdy słaby wynik wynika z braków lub duplikatów. Czasem zbiór jest „czysty”, ale opisuje świat jednostronnie. Jedna klasa jest rzadka, część grup użytkowników prawie nie występuje, a dane pochodzą głównie z jednego kanału.
To też forma błędu uczącego model złych nawyków. Jeśli w danych kredytowych brakuje części profili klientów, model nie nauczy się dla nich stabilnych zależności. Jeśli w danych ticketowych dominują łatwe zgłoszenia, metryka będzie dobra, ale na trudniejszych przypadkach spadnie.
Tu czyszczenie nie polega na „usunięciu problemu”, tylko na jego ujawnieniu. Dobrze oznaczyć segmenty słabo reprezentowane, osobno je mierzyć i nie mylić poprawy średniej metryki z poprawą ogólnej jakości modelu.
Krótka checklista przed każdą regułą czyszczenia
Jeśli decyzja nie jest oczywista, pomaga krótki filtr:
- czy to błąd techniczny, czy rzadki, ale prawdziwy przypadek,
- czy taka sytuacja pojawi się także po wdrożeniu,
- czy reguła korzysta tylko z informacji dostępnej w momencie predykcji,
- czy zmiana poprawia jakość etykiety, cechy albo splitu, a nie tylko wygląd danych,
- czy da się odtworzyć tę samą operację bez ręcznej ingerencji.
Jeśli na dwa z tych pytań odpowiedź brzmi „nie wiem”, lepiej najpierw zrobić mały eksperyment niż sprzątać cały zbiór.
Po czym poznać, że czyszczenie naprawdę pomogło
Najlepszy sygnał to nie sam wzrost metryki, tylko bardziej przewidywalne zachowanie modelu. Mniej skoków między splitami, mniej dziwnych błędów w tych samych grupach, stabilniejszy wynik na świeższych danych.
Pomaga też porównanie przed i po na konkretnych rekordach. Jeśli po poprawkach znikają błędy wokół znanych problemów — na przykład rekordów z kodami zastępczymi, dubli zgłoszeń albo etykiet mieszanych między starym i nowym procesem — to znak, że zmiana trafiła w źródło problemu.
Jeśli zaś model zyskuje głównie na walidacji, a traci na nowym okresie albo rzadkiej klasie, czyszczenie mogło tylko uprościć zbiór. Wtedy lepiej cofnąć krok i sprawdzić, czy nie usunięto trudnych, ale prawdziwych przypadków.
Najrozsądniejszy kolejny ruch jest prosty: wybrać jeden problem o największym wpływie, zapisać regułę w pipeline’ie i sprawdzić wynik na osobnej walidacji. Nie porządkować wszystkiego naraz. W ML najwięcej daje nie idealnie czysty zbiór, tylko dane oczyszczone dokładnie tam, gdzie model uczył się błędów.
Najczęściej zadawane pytania (FAQ)
Jak poznać, że problem w modelu ML leży w danych, a nie w algorytmie?
Najczęstszy sygnał to bardzo dobry wynik na train i wyraźnie gorszy na walidacji lub teście. Sam overfitting nie przesądza sprawy, ale jeśli zmiana modelu niewiele daje, zwykle trzeba wrócić do etykiet, splitu i cech.
Drugi objaw to niestabilne predykcje. Jeśli drobna zmiana rekordu mocno zmienia wynik, model może opierać się na przypadkowej korelacji, błędnie zakodowanej kategorii albo polu, które zawiera informację z przyszłości.
Od czego zacząć czyszczenie danych do machine learning?
Nie od usuwania nulli. Najpierw trzeba ustalić, co model przewiduje, w którym momencie i jakie informacje są wtedy naprawdę dostępne. Bez tego trudno odróżnić sensowną cechę od data leakage.
Dopiero potem ma sens audyt danych i split na train, validation oraz test. Transformacje takie jak imputacja, skalowanie czy mapowanie kategorii powinny być dopasowywane wyłącznie na zbiorze treningowym.
Jak odróżnić błąd w danych od rzadkiego, ale prawdziwego przypadku?
Trzeba sprawdzić kontekst biznesowy i źródło pola. Nietypowa wartość nie zawsze jest błędem. Może oznaczać realny, trudny przypadek, którego model właśnie powinien się nauczyć.
Dobrze zadać sobie dwa krótkie pytania: czy taki rekord może pojawić się po wdrożeniu i czy jego usunięcie nie uprości sztucznie świata. Na przykład brak dokumentu może być awarią integracji, ale może też być ważnym sygnałem ryzyka.
Co zrobić z brakującymi danymi w ML?
Najpierw ustal, czy brak coś znaczy. W wielu zadaniach brak wartości jest informacją samą w sobie, a nie tylko problemem technicznym. Usunięcie takich rekordów albo ślepa imputacja może pogorszyć generalizację.
W praktyce często działa połączenie imputacji z dodatkową flagą informującą o braku. Kluczowe jest też to, by reguły imputacji wyliczać tylko na train, bo inaczej łatwo nieświadomie wprowadzić leakage.
Jak wykryć i uniknąć data leakage podczas czyszczenia danych?
Trzeba sprawdzić, kiedy powstała każda cecha i czy była dostępna w momencie predykcji. Jeśli pole pojawia się po fakcie, nie powinno trafić do modelu, nawet jeśli świetnie poprawia metryki.
Typowe czerwone flagi to:
- cechy tworzone po zdarzeniu docelowym,
- statystyki liczone na całym zbiorze przed splitem,
- losowy split w danych czasowych,
- pola pochodne od etykiety.
Klasyczny przykład: „data zamknięcia sprawy” znakomicie przewiduje wynik procesu, ale tylko dlatego, że powstaje później.
Czy usuwać outliery i duplikaty przed treningiem modelu?
Nie automatycznie. Outlier może być błędem pomiaru, ale może też być trudnym, realnym przypadkiem. Jeśli takie rekordy występują w produkcji, ich masowe usunięcie zwykle daje zbyt „grzeczny” zbiór treningowy.
Duplikaty i near-duplicate to osobny problem, bo potrafią sztucznie zawyżyć wyniki. Szczególnie groźne jest to, gdy prawie identyczne rekordy trafiają jednocześnie do train i test. Wtedy model nie uogólnia, tylko rozpoznaje to, co już widział.
Jak poprawnie zrobić split danych przy szeregach czasowych, tekstach i wielu rekordach na klienta?
Przy danych czasowych walidacja musi leżeć później niż trening. Jeśli model ma przewidywać przyszłość, nie można mieszać przeszłości z przyszłością tylko po to, by uzyskać ładniejszy rozkład.
Przy wielu rekordach na jedną encję, na przykład klienta, zwykły losowy split bywa mylący. Podobne przypadki powinny trafiać do jednej części zbioru. W tekstach trzeba dodatkowo pilnować wersji tego samego dokumentu, ticketu albo reklamacji, bo near-duplicate łatwo przeciekają między train i test.
Kluczowe Wnioski
- Czyszczenie danych do ML nie służy „upiększaniu” tabeli, tylko usuwaniu zniekształceń, przez które model uczy się fałszywych wzorców zamiast zależności, które zadziałają po wdrożeniu.
- Zanim zmienisz algorytm, sprawdź dane: duża różnica między train i walidacją, niestabilne predykcje po drobnych zmianach rekordu albo „magiczne” cechy często wskazują na błędne etykiety, zły split lub leakage.
- Nie każda nietypowa wartość, luka czy literówka jest błędem — czasem to prawdziwy przypadek albo ważny sygnał. Usunięcie wszystkich trudnych rekordów zwykle daje model, który dobrze działa tylko na sterylnym zbiorze treningowym.
- Każdą decyzję o czyszczeniu dobrze przefiltrować przez cztery pytania: czy to błąd czy realny przypadek, czy model powinien to widzieć, czy poprawka nie tworzy leakage oraz czy problem dotyczy wejścia, etykiety czy podziału danych.
- Prace zacznij od celu modelu i momentu predykcji, bo bez tego nie da się odróżnić legalnej cechy od informacji z przyszłości; pole typu „data zamknięcia sprawy” może wyglądać świetnie, ale często jest klasycznym przeciekiem.
- Audyt powinien objąć nie tylko wartości, ale też proces powstawania danych: źródła cech, czas zapisu, spójność systemów i sposób nadawania etykiet, bo wiele błędów wynika z procesu, a nie z samej zawartości tabeli.
- Split i transformacje trzeba rozdzielić rygorystycznie: imputację, skalowanie czy mapowanie kategorii dopasowuje się wyłącznie na train, a duplikaty i near-duplicate między train i test trzeba wychwycić, inaczej wynik będzie sztucznie zawyżony.
Źródła
- Data Preparation for Data Mining. Morgan Kaufmann (2005) – Klasyczne omówienie czyszczenia danych, braków, outlierów i jakości danych.
- Feature Engineering and Selection: A Practical Approach for Predictive Models. CRC Press (2019) – Praktyki przygotowania cech, walidacji i unikania przecieków danych.
- The Elements of Statistical Learning. Springer (2009) – Podstawy generalizacji, overfittingu i oceny modeli na danych testowych.
- Leakage in Data Mining: Formulation, Detection, and Avoidance. Association for Computing Machinery (2011) – Definicje i przykłady data leakage oraz sposoby wykrywania.
