Model ML nie jest magikiem. To raczej bardzo szybki kalkulator, który uczy się wzorców z tego, co mu podasz. Jeśli dostaje dane brudne, niespójne i pełne braków, to nawet najbardziej wyrafinowany algorytm zacznie podejmować dziwne decyzje. Z drugiej strony dość prosty model, ale zasilony świetnie przygotowanym zbiorem danych, potrafi bić na głowę skomplikowane architektury zasilane chaosem.
Doświadczone zespoły ML często powtarzają, że 70–80% czasu pracy nad projektem to przygotowanie danych, a nie wybór modelu czy strojenie hiperparametrów. To na etapie preprocessingu zapadają decyzje, czy model będzie uczyć się prawdziwych zależności, czy artefaktów i przypadkowych korelacji. Samo przejście od surowego pliku CSV do spójnego dataframe’u z sensownymi typami i cechami potrafi zająć długie dni.
Wyobraź sobie dwa zespoły korzystające z tego samego algorytmu (np. gradient boosting) i tego samego narzędzia (np. XGBoost albo LightGBM). Jeden zespół poświęca czas na rzetelne czyszczenie danych, świadome obchodzenie się z brakami i balansowanie klas. Drugi wrzuca dane „jak leci”, dorzucając tylko prostą imputację średnią. Różnica w jakości modelu potrafi być dramatyczna, mimo identycznego kodu modelu.
Dane z prawdziwego świata: chaos, szum i braki
Większość osób zaczyna przygodę z uczeniem maszynowym od schludnych datasetów z tutoriali: brak pustych komórek, zero błędów typów, klasy ładnie zbalansowane. A potem przychodzi pierwsze spotkanie z realnym logiem z aplikacji, CRM-em czy hurtownią danych i entuzjazm stygnie.
Rzeczywiste dane często mają:
wiele różnych formatów dat w jednej kolumnie,
wartości typu „brak”, „n/a”, „-„, „?” wymieszane z pustymi komórkami,
pola numeryczne zapisane jako teksty z przecinkami, spacjami lub znakami walut,
powtarzające się rekordy (duplikaty) generowane przez systemy integracyjne,
braki tylko w określonych okresach czasu (np. awaria integracji przez tydzień),
ekstremalne wartości (outliery), które czasem są błędem, a czasem najcenniejszą informacją.
Do tego dochodzą subtelniejsze problemy: lekkie przesunięcia czasowe, zmiany definicji pól w trakcie życia systemu, czy „ciche” modyfikacje schematów baz danych. Bez zrozumienia, jak powstały dane, nie ma mowy o sensownym czyszczeniu czy imputacji.
Od surowych danych do gotowego zestawu – krótka mapa procesu
Zanim model zacznie się uczyć, dane przechodzą kilka kluczowych etapów. W praktyce proces wygląda często tak:
Zrozumienie problemu: co chcemy przewidzieć, dla jakiej jednostki (klient, transakcja, sesja), w jakim momencie czasu.
Pobranie surowych danych z różnych źródeł (bazy SQL, pliki CSV, logi zdarzeń, API).
Diagnoza braków i outlierów: gdzie i dlaczego pojawiają się braki, jakie wartości są podejrzane.
Strategie obchodzenia się z brakami: usuwanie, imputacja, zostawianie jawnego „braku”.
Balansowanie klas (dla klasyfikacji): walka z silną nierównowagą pozytywnych i negatywnych przykładów.
Inżynieria cech: tworzenie nowych, bardziej informatywnych zmiennych.
Budowa pipeline’u: spięcie czyszczenia, imputacji, kodowania i modelu w jeden powtarzalny proces.
Podział na zbiory treningowe i walidacyjne/testowe z uwzględnieniem czasu i struktury danych.
Każdy z tych etapów może poprawić lub zniszczyć jakość modelu. Świadome decyzje w okolicy braków, czyszczenia i balansowania klas często mają większy wpływ na wynik niż zamiana jednego algorytmu na inny.
Zrozumienie problemu i danych przed pierwszym „clean()”
Co model ma przewidywać i dlaczego
Zanim w ruch pójdą pierwsze skrypty czyszczące, potrzebna jest jasność: jaka jest dokładnie zmienna docelowa i po co budowany jest model. Inaczej wygląda preprocessing dla klasyfikacji binarnej (np. czy klient odejdzie), inaczej dla regresji (prognoza przychodu), a jeszcze inaczej dla rankingu (kolejność produktów w rekomendacjach).
Kilka kluczowych pytań, które porządkują myślenie:
Jaki typ problemu rozwiązujemy: klasyfikacja, regresja, przewidywanie sekwencji, ranking?
W jakim momencie czasu ma być dostępna predykcja (np. przy logowaniu, po zakupie, co godzinę)?
Jak będzie używany wynik modelu: decyzja automatyczna, podpowiedź dla człowieka, filtr alertów?
Jaki koszt mają fałszywie pozytywne i fałszywie negatywne przewidywania?
Od odpowiedzi na te pytania zależy m.in. to, jak zdefiniujesz etykietę (target), jak potraktujesz braki w danych (np. brak transakcji to często też informacja) i jak później rozwiążesz problem nierównowagi klas w klasyfikacji.
Jednostka obserwacji i jej konsekwencje dla cech
Jednym z najczęstszych, a jednocześnie najmniej widocznych błędów jest niejasno zdefiniowana jednostka obserwacji. Czy jeden wiersz w danych reprezentuje:
klienta (agregacja po wielu transakcjach),
pojedynczą transakcję,
sesję użytkownika w aplikacji,
produkt w sklepie?
Jeśli jednostka jest niejasna, szybko pojawia się bałagan: cechy transakcyjne mieszają się z cechami klienta, a do pojedynczego rekordu trafiają informacje, które w danym momencie nie są jeszcze znane. To prosty przepis na data leakage – wyciek informacji z przyszłości do przeszłości, który zawyża wyniki na walidacji, a potem kończy się rozczarowaniem na produkcji.
Przykład: model ma przewidywać rezygnację klienta z usługi w ciągu najbliższego miesiąca, a wśród cech pojawia się „liczba transakcji w następnym miesiącu”. Model na walidacji będzie błyszczał, ale w rzeczywistym scenariuszu nikt tej cechy jeszcze nie zna w momencie predykcji.
Rozmowy z ekspertem dziedzinowym i analiza czasowa
Surowe dane rzadko mówią same za siebie. Krótkie spotkanie z product ownerem czy analitykiem biznesowym potrafi oszczędzić godziny zgadywania. Warto rozumieć:
jakie zakresy wartości są realistyczne dla danej cechy,
które braki wynikają z normalnego procesu (np. brak numeru telefonu, bo klient nie podał),
które momenty w czasie są „podejrzane” (np. migracja systemu, zmiana regulaminu),
jak interpretować zera i puste pola (0 zamówień vs. brak danych o zamówieniach).
Niezwykle ważne jest też jasne wyznaczenie granicy czasowej: co jest przeszłością, a co przyszłością względem chwili, gdy model ma podjąć decyzję. Pod tę granicę trzeba później ułożyć feature engineering: np. liczyć „liczbę logowań w ciągu ostatnich 7 dni przed predykcją”, a nie w dowolnym oknie obejmującym przyszłość.
Pierwsze EDA: rozkłady, korelacje, anomalie
Exploratory Data Analysis (EDA) to wstępne „oswojenie” się z danymi. Na tym etapie dobrze jest:
policzyć korelacje między najważniejszymi cechami a targetem (dla wstępnej intuicji),
zidentyfikować kolumny nieinformacyjne (np. jedna stała wartość w całej kolumnie),
wykryć ewidentne problemy (np. wartości ujemne tam, gdzie nie powinno ich być).
Już na tym etapie pojawia się masa wskazówek dla dalszego czyszczenia: jakie kolumny można bez żalu usunąć, gdzie są poważne braki, które cechy wymagają specjalnej troski (np. outliery, ogromna skośność rozkładu).
Podstawowe czyszczenie danych – od surowej tabeli do sensownego dataframe’u
Identyfikacja i usuwanie oczywistych błędów
Pierwsza fala sprzątania to pozbycie się tego, co ewidentnie nie ma sensu lub nie wnosi informacji. W praktyce chodzi o:
duplikaty rekordów – np. gdy ten sam event został zapisany dwa razy,
puste wiersze – rekordy bez żadnych wartości lub niemal całkowicie puste,
kolumny z jedną wartością – brak zróżnicowania, więc brak informacji dla modelu,
czyste identyfikatory (np. losowy ID transakcji) – przydają się do łączenia danych, ale zwykle nie jako cecha.
Usuwanie duplikatów wydaje się banalne, ale bywa zdradliwe. Zamiast ślepo wywoływać funkcję drop_duplicates(), dobrze jest ustalić:
czy pełne duplikaty są naprawdę duplikatami, czy np. różnią się nieobserwowaną cechą,
jakie kryteria unikalności są istotne: ID klienta + data, czy może ID transakcji,
który rekord zostawić, gdy występuje konflikt (najświeższy, najstarszy, z najmniejszą liczbą braków?).
Zdarza się, że „duplikat” systemowy wcale nie jest duplikatem z punktu widzenia biznesu – np. ponowiona płatność tej samej faktury. Zanim skasujesz tysiące rekordów, lepiej zapytać kogoś, kto zna procesy stojące za danymi.
Sprzątanie typów danych i formatów
Kolejny krok to sprowadzenie kolumn do sensownych typów. Częsty obrazek: daty jako teksty, liczby wymieszane z symbolami walut, wartości „N/A” i „brak” jako zwykłe stringi. Taki miszmasz sprawia, że część logiki biznesowej jest ukryta przed modelem.
Podstawowe zadania:
konwersja kolumn z datami do typu daty/czasu (i ewentualne wyciąganie komponentów: rok, miesiąc, dzień tygodnia),
konwersja kolumn numerycznych zapisanych jako tekst do typu liczbowego (po uprzednim usunięciu zbędnych znaków),
przekształcenie kategorycznych tekstów na typ kategoryczny (co ułatwia późniejsze enkodowanie),
konsekwentne oznaczenie braków (np. NaN), zamiast trzymania ich jako różne stringi.
Problemem bywają jednostki. Dane w groszach wrzucone do jednego worka z danymi w złotówkach albo czas w sekundach wymieszany z czasem w minutach to szybka droga do absurdu. Zanim dane trafią do modelu, dobrze jest:
ujednolicić jednostki monetarne i czasowe,
zadbać o spójne użycie separatorów dziesiętnych (przecinek vs. kropka),
pozbyć się tysięcznych separatorów (spacje, kropki, przecinki w złym miejscu).
Delikatność przy usuwaniu rekordów
Usuwanie rekordów to najszybsze i najbardziej kuszące rozwiązanie przy „dziwnych” danych. Kilka procent braków? Wywalimy. Parę tysięcy podejrzanych outlierów? Out. Problem w tym, że często razem z brudem wynosisz z mieszkania także cenne rzeczy.
Kilka pytań pomocniczych, zanim wyrzucisz większy fragment danych:
Czy braki lub błędy są równomiernie rozłożone po zbiorze, czy skupione w konkretnej grupie (np. nowi klienci, konkretne kraje)?
Czy usunięcie rekordów nie zaburzy rozkładu klas (np. usunięcie wielu rzadkich przypadków pozytywnych)?
Czy dane z brakami nie są właśnie tymi, które są dla biznesu najciekawsze (np. „problemowe” transakcje)?
Dobrym kompromisem jest tworzenie zmiennych pomocniczych (np. flaga „rekord_niekompletny”) zamiast całkowitego wyrzucania. Czasem sama informacja, że coś jest „podejrzane” lub „niepełne”, ma spory ładunek informacyjny dla modelu.
Brakujące dane – diagnoza przed leczeniem
Rodzaje braków: MCAR, MAR, MNAR w praktycznej wersji
Braki w danych nie są sobie równe. W statystyce wyróżnia się trzy główne typy:
MCAR (Missing Completely At Random) – brak zupełnie losowy, niezależny od innych cech i od samej zmiennej.
Jak rozumieć mechanizm powstawania braków
Formalne nazwy (MCAR, MAR, MNAR) bywają odstraszające, ale stoją za nimi bardzo przyziemne sytuacje z systemów produkcyjnych. Klucz nie leży w zapamiętaniu skrótów, tylko w zrozumieniu, dlaczego czegoś brakuje.
MCAR w praktyce to np. losowo „wysypujące się” eventy logów z powodu chwilowego błędu sieci. Brak pojawia się niezależnie od klienta, produktu czy wartości samej zmiennej.
MAR (Missing At Random) to sytuacja, gdy brak zależy od innych cech, ale nie od samej brakującej wartości. Przykład: brak dochodu klienta częściej występuje wśród młodszych osób albo osób z konkretnego kanału sprzedaży.
MNAR (Missing Not At Random) to już twardy orzech. Brak sam w sobie niesie informację o wartości zmiennej. Jeśli klienci o bardzo wysokich dochodach wyjątkowo często nie podają dochodu w ankiecie, to brak mówi coś o dochodzie.
Po co ta cała klasyfikacja? Od niej zależy, jak agresywnie można imputować dane. Przy MCAR prostsze metody zwykle nie skrzywią rozkładów. Przy MNAR ślepe wypełnianie medianą potrafi zabić najciekawszy sygnał – sam fakt braku.
Mapowanie braków na procesy biznesowe
Zanim uruchomisz jakikolwiek algorytm imputacji, dobrze jest narysować sobie obrazek: skąd bierze się dana kolumna, na jakim etapie procesu jest uzupełniana i kiedy może się „nie udać”.
Pomaga kilka prostych kroków:
Przejście ścieżki użytkownika – od pierwszego kontaktu do finalnego zdarzenia (np. zakupu). W którym momencie klient podaje numer telefonu? Kiedy system zapisuje geolokalizację? Gdzie może „wypaść” część danych?
Sprawdzenie wersji systemu – migracje, zmiany formularzy, nowe integracje z zewnętrznymi API. Często widać okresy, w których braki skaczą, bo coś się zmieniło technicznie.
Porównanie kanałów – inny poziom braków w call center, inny w aplikacji mobilnej, a jeszcze inny w oddziale stacjonarnym. To nie przypadek, tylko element procesu.
Kiedy raz zobaczysz, że np. brak numeru telefonu występuje głównie w jednym kanale sprzedaży, inaczej spojrzysz na pomysł „po prostu imputujmy najczęściej występującą wartość”.
Proste testy na losowość braków
Nie trzeba od razu sięgać po zaawansowane modele, żeby sprawdzić, czy braki są „dziwne”. Wystarczy kilka prostych sztuczek analitycznych:
utworzenie binarnej flagi czy_brak dla każdej problematycznej kolumny,
porównanie rozkładów innych cech dla rekordów z brakami i bez nich (np. boxploty, średnie, częstości),
sprawdzenie korelacji flag braków z targetem (np. czy brak dochodu koreluje z wyższym ryzykiem kredytowym?),
analiza w czasie: czy od pewnej daty braków jest nagle dużo więcej (np. po wdrożeniu nowej wersji aplikacji).
Jeśli flaga „brak wartości” ma wyraźną zależność z targetem, z dużym prawdopodobieństwem nie masz do czynienia z niewinnym MCAR. To sygnał, by nie zamazywać braków prostą imputacją bez zostawienia dodatkowej flagi.
Źródło: Pexels | Autor: Yan Krukau
Strategie radzenia sobie z brakami – proste i zaawansowane podejścia
Usuwanie wierszy i kolumn – kiedy „twarde cięcie” ma sens
Najprostsza reakcja na braki to usuwanie: wierszy, w których czegoś brakuje, albo całych kolumn z dużym odsetkiem pustych wartości. Ta strategia bywa uzasadniona, ale tylko wtedy, gdy spełnionych jest kilka warunków.
Mały odsetek braków i brak wzorców – jeśli w kolumnie brakuje 1–2% wartości, a analiza nie pokazuje żadnego systematycznego schematu, usunięcie kilku procent rekordów nie zniszczy zbioru.
Kolumny niemal całkowicie puste – jeśli w polu jest wypełnione parę promili rekordów, często bardziej opłaca się je wyciąć niż poświęcać na nie czas i późniejszą uwagę.
Kolumny zbędne biznesowo – opcjonalne dodatkowe informacje, z których zespół i tak nigdy nie korzystał i nie planuje korzystać.
Przed „twardym cięciem” warto jednak policzyć, jak usunięcie rekordów zmienia rozkład targetu i kluczowych cech. Czasem 5% usuniętych wierszy zawiera nieproporcjonalnie dużo przypadków klasy mniejszościowej – i wtedy zamiast niewinnego uproszczenia dostajesz agresywne zubożenie sygnału.
Stałe podstawienia: zero, średnia, mediana, tryb
Następny poziom to proste imputacje stałą wartością. Kuszą, bo są szybkie, stabilne i dobrze wspierane przez biblioteki. Pytanie brzmi: gdzie wolno sobie na nie pozwolić?
Zero bywa sensowne, gdy brak semantycznie oznacza „brak zdarzeń”. Jeśli klient nie ma historii zakupów, to liczba zamówień = 0 jest naturalna. Trzeba jednak odróżnić „zero zdarzeń” od „brak logowania tego zdarzenia”.
Średnia/mediana dla zmiennych numerycznych ma sens przy niewielkim odsetku braków, gdy zmienna jest stosunkowo „gładka” i niezbyt skośna. Mediana bywa bardziej odporna na outliery niż średnia.
Tryb (najczęstsza kategoria) jest typowym wyborem dla zmiennych kategorycznych. Problem pojawia się, gdy najczęstsza kategoria zdominuje kolumnę jeszcze bardziej i model przestanie „widzieć” rzadkie, ale istotne stany.
Prosty, ale bardzo przydatny trik: przy każdej automatycznej imputacji stałą wartością dodać osobną flagę braku. Dzięki temu model ma szansę nauczyć się, że „tu coś było puste” i zachować część informacji o mechanizmie braku.
Specjalne kody i kategorie „missing”
Przy danych kategorycznych często sensowniej jest nie „zgadywać” kategorii, tylko jawnie powiedzieć: „tu nie wiemy”. Można to zrobić, dodając osobną kategorię typu 'missing', 'unknown' czy 'not_provided'.
Kilka zalet takiego podejścia:
transparentność – widać, że dana wartość nie została podana lub nie mogła zostać zmierzona,
zachowanie informacji – model może nauczyć się, że „brak typu urządzenia” jest sam w sobie sygnałem (np. starsza wersja aplikacji),
prostota we wdrożeniu – nowe rekordy z brakami automatycznie wpadają do kategorii „missing”, bez dodatkowej logiki.
Przy zmiennych numerycznych podobną rolę może pełnić osobna wartość (np. -1) albo daleki od reszty zakresu kod liczbowy, ale wtedy szczególnie istotna jest flaga braku – inaczej model może uznać, że -1 to po prostu bardzo niska, lecz realna wartość.
Imputacja oparta na modelu: regresja, drzewa, KNN
Kiedy braków jest więcej, a zmienna jest ważna dla problemu, proste metody zaczynają być zbyt toporne. Wtedy pojawia się opcja imputacji opartej na modelu – czyli przewidywania brakujących wartości na podstawie innych kolumn.
Najczęstsze warianty:
Regresja liniowa / logistyczna – dla relatywnie prostych zależności. Wypełniasz jedną kolumnę na podstawie kilku dobrze powiązanych cech.
Modele drzewiaste (np. Random Forest) – radzą sobie z nieliniowościami i interakcjami. Dobre, gdy relacje między cechami są złożone, a danych jest sporo.
KNN Imputer – szuka „podobnych” rekordów (sąsiadów) i używa ich wartości do imputacji. Intuicyjne, ale kosztowne obliczeniowo przy dużych zbiorach i wrażliwe na skalę zmiennych.
Imputacja modelowa ma jednak kilka pułapek:
łatwo o nadmierny optymizm – jeśli ten sam algorytm używasz później do modelowania targetu, zacierasz granicę między etapami przygotowania danych a treningiem,
dane „zmyślone” mogą wyglądać zbyt gładko – rozkład imputowanych wartości bywa mniej rozrzutny niż oryginalny, przez co model uczy się nieco „upiększonej” rzeczywistości,
zwiększa się złożoność pipeline’u – trzeba pamiętać o trzymaniu tego samego modelu imputującego na produkcji i pilnować jego wersji.
Dobrym kompromisem jest stosowanie imputacji modelowej tylko dla kilku kluczowych zmiennych, które rzeczywiście wnoszą dużo informacji do modelu końcowego, zamiast hurtem imputować w ten sposób wszystko.
Algorytmy tolerujące braki a obowiązek sprzątania
Część nowoczesnych algorytmów (np. XGBoost, LightGBM, CatBoost) potrafi w różnym stopniu radzić sobie z brakami „w locie”. To bardzo wygodne, bo pozwala pominąć część ręcznego wypełniania wartości. Nie oznacza to jednak, że temat braków można zignorować.
Kilka powodów, dla których mimo „tolerancji na NaN-y” nadal opłaca się przemyśleć braki:
mechanizm traktowania braków jest częścią logiki modelu – jeśli braki wynikają z błędów systemowych, można je po prostu naprawić na etapie ETL i nie mieszać tego z predykcją,
przy przejściu na inny algorytm (np. prostszy model liniowy dla real-time scoringu) brak solidnej strategii braków nagle bardzo boli,
analiza braków często ujawnia problemy jakościowe i procesowe w systemach źródłowych, które warto naprawić niezależnie od ML.
W praktyce dobrze jest łączyć te podejścia: część braków potraktować jawnie (np. flagami i kategoriami „missing”), a resztę zostawić algorytmowi, który „wie”, jak z nimi żyć.
Braki w sekwencjach i szeregach czasowych
Dane sekwencyjne, logi zdarzeń czy szeregi czasowe niosą dodatkowy kłopot: braki pojawiają się w czasie, a nie tylko w pojedynczych komórkach tabeli. Czasem brakuje pojedynczego punktu, a czasem całego okresu.
Kilka typowych sytuacji:
dziury w czasie – brak obserwacji dla danego dnia/godziny (np. awaria trackingu),
niepełne sekwencje – nowi użytkownicy mają krótszą historię niż starzy, co w klasycznej tabeli wygląda jak „braki”, a jest po prostu młodością konta,
rzadko obserwowane zdarzenia – np. pomiary tylko przy spełnieniu warunku (dane medyczne zbierane przy wizytach).
W takich przypadkach typowe narzędzia to:
forward-fill/backward-fill – „przeciąganie” ostatniej znanej wartości do kolejnych punktów czasu, sensowne np. dla salda konta, ale już niekoniecznie dla chwilowego tętna,
interpolacja (liniowa, spline) – uzupełnianie brakujących punktów na podstawie trendu, dobre przy gładkich procesach fizycznych, mniej przy skokowych danych transakcyjnych,
agregacja w szersze okna – zamiast przejmować się każdym brakującym kwadransem, można liczyć sumy/średnie w dobowych oknach, w których jedna-dwie luki nie robią różnicy.
Znów pomaga myślenie o procesie: jeśli brak eventu logowania w danym dniu oznacza po prostu, że użytkownik się nie zalogował, to brak nie jest „dziurą”, tylko sensowną informacją: aktywność = 0.
Dziwne wartości, outliery i szum – jak nie wylać dziecka z kąpielą
Czym jest outlier w konkretnym projekcie
Outlier w statystyce to obserwacja „daleko” od reszty. W praktyce ML-owej ważniejsze pytanie brzmi: czy to błąd, czy może właśnie najbardziej interesujący przypadek? W detekcji fraudów „dziwna” transakcja jest złotem, a nie śmieciem.
Pomaga rozróżnienie trzech kategorii:
błędy pomiaru lub przetwarzania – np. wiek = 500 lat, wielkość zamówienia ujemna, data dostawy wcześniejsza niż data zakupu,
prawdziwe, ale rzadkie zdarzenia – pojedyncza gigantyczna faktura, klient z ekstremalnie wysoką liczbą transakcji, nietypowe kombinacje cech,
szum losowy – obserwacje poprawne, ale nieprzewidywalne, których nie ma sensu „naprawiać”.
Proste reguły biznesowe kontra „statystyczna dziwność”
Zanim pojawią się złożone wykresy i algorytmy detekcji anomalii, zaskakująco skuteczne bywają zwykłe reguły biznesowe. Zwłaszcza tam, gdzie „zdrowy rozsądek domenowy” jest mocny: finanse, logistyka, medycyna.
Kilka typów prostych reguł:
zakresy fizycznie/logiczenie możliwe – temperatura ciała człowieka nie będzie ujemna, liczba dzieci nie jest ułamkiem, liczba godzin pracy w miesiącu ma górny limit,
spójność pól – data dostawy ≥ data wysyłki, data urodzenia + wiek ≈ dziś, suma pozycji na fakturze ≈ kwocie końcowej,
relacje między kolumnami – jeśli typ_konta = 'FIRMA', to nip nie może być pusty; jeśli kraj = 'PL', to kod pocztowy ma konkretny format.
Te reguły bardzo często wyłapują prawdziwe błędy danych – literówki, uszkodzone rekordy, podwójne parsowanie walut – a nie „ciekawe przypadki biznesowe”. Zanim więc cokolwiek usuniesz jako „outlier”, spróbuj odpowiedzieć: czy łamie to jakąś oczywistą regułę świata, w którym działasz?
Miary statystyczne: od pudełek do odległości
Gdy „zdrowy rozsądek” nie wystarcza, wchodzą klasyczne narzędzia statystyczne – pozwalają odfiltrować jedynie najbardziej podejrzane wartości, które potem można obejrzeć ręcznie lub potraktować dedykowanymi regułami.
Kilka najczęstszych podejść:
reguła IQR (interquartile range) – liczymy kwartyle (Q1, Q3) i zakres międzykwartylowy IQR = Q3 − Q1. Typowo outlierem uznajemy wszystko poniżej Q1 − 1.5×IQR i powyżej Q3 + 1.5×IQR. Proste i odporne na kilka ekstremów.
standaryzacja i z-score – normalizujemy zmienną (średnia = 0, odchylenie = 1) i patrzymy na wartości o |z| > 3, 4, … Dobre przy mniej więcej normalnych rozkładach, dużo gorsze przy bardzo skośnych.
odległości w przestrzeni cech – w wielu wymiarach „dziwność” jest kombinacją wielu kolumn. Stosuje się wtedy np. odległość Mahalanobisa lub modele typu Isolation Forest, One-Class SVM, które wskazują punkty odstające wielowymiarowo.
Pułapka jest prosta: statystyka nie wie, co jest błędem, a co po prostu rzadkim, lecz ważnym przypadkiem. Dlatego wynik takich algorytmów traktuje się raczej jako listę kandydatów do specjalnego traktowania, nie automatyczny wyrok „do usunięcia”.
Co zrobić z outlierem: usuwać, przycinać, transformować?
Załóżmy, że masz już listę podejrzanych punktów. Dalej pojawia się praktyczne pytanie: jak z nimi postąpić? Poza klasycznym „dropnijmy je” istnieje kilka łagodniejszych ścieżek.
Usunięcie rekordu – rozsądne, gdy masz mocne przesłanki, że to błąd (wiek = 999, ujemne kilometry przebiegu auta). Trzeba jednak uważać, by przypadkiem nie wyciąć całej grupy użytkowników (np. bardzo zamożnych).
Winsoryzacja (przycinanie) – wartości poniżej/ powyżej określonego percentyla (np. 1% i 99%) zastępuje się wartościami granicznymi. Rozkład nadal ma „ogon”, ale bez ekstremów, które potrafią zdominować model liniowy.
Transformacje – logarytm, pierwiastek, Box-Cox; zmniejszają wpływ bardzo dużych wartości, zamiast je wycinać. W finansach lub e‑commerce to często naturalny wybór dla obrotów, wydatków czy liczby transakcji.
Osobne cechy dla outlierów – zamiast maskować, można dodać flagę typu is_extreme_amount i zostawić oryginalną wartość po delikatnej transformacji. Model sam oceni, kiedy ekstremalność ma znaczenie.
W klasyfikacji fraudów typowym zabiegiem jest dokładnie odwrotna strategia: „normalne” rekordy są czasem subsamplowane, a skrajne wartości zostają – bo to one są sednem problemu. Zamiast więc pytać „jak to uciąć?”, lepiej czasem zapytać „czy to nie jest właśnie to, czego szukam?”.
Outliery a metryki modelu: czym innym MAE, czym innym RMSE
To, jak mocno outliery „bolą”, zależy też od tego, jak mierzymy jakość modelu. Ten sam błąd w ogonie rozkładu może być prawie niewidoczny przy jednej metryce, a dewastujący wynik przy innej.
RMSE / MSE – błędy są podnoszone do kwadratu, więc ekstremalne pomyłki dostają gigantyczną wagę. Parę outlierów może praktycznie zdominować metrykę.
MAE / Mediana błędu – dużo bardziej odporne na pojedyncze skrajne przypadki. Dla zestawów z nieuniknionymi outlierami bywają sensowniejsze.
Quantile loss – dla modeli, które mają przewidywać konkretne kwantyle (np. „konserwatywną” prognozę kosztu), ogony są wręcz kluczowe.
Jeżeli biznes żyje ekstremami (ryzyko kredytowe, zapotrzebowanie szczytowe, awarie), to agresywne „wygładzanie” outlierów tylko po to, by poprawić RMSE, zwykle mija się z celem. Wtedy zamiast usuwać ogony, lepiej dobrać metryki tak, by szanowały ich wagę.
Balansowanie klas: kiedy problemem jest nie liczba kolumn, tylko mała liczebność „jedynek”
W wielu projektach przygotowanie danych nie kończy się na sprzątaniu wierszy i kolumn, tylko na bolesnym odkryciu: klasa pozytywna prawie nie istnieje. Fraud, rezygnacja klienta, awaria, rzadki efekt uboczny – wszystko to ma jedną cechę wspólną: jest rzadkie.
Algorytm uczący się z 99% „nie” i 1% „tak” ma naturalną pokusę, by przewidywać zawsze „nie” i osiągać imponującą, lecz całkowicie bezużyteczną dokładność. Cała reszta zabiegów na cechach niewiele pomoże, jeśli nie zajmiemy się tą nierównowagą.
Diagnoza nierównowagi: nie tylko liczby, ale też „jakie to są przypadki”
Zanim sięgniesz po oversampling czy undersampling, dobrze jest „poznać” klasy. Chodzi nie tylko o ich proporcje, ale też o to, czy pozytywne przypadki są w miarę jednorodne, czy rozrzucone po całej przestrzeni cech.
Kilka prostych kroków:
policz udział klasy pozytywnej ogółem i w podgrupach (np. per kraj, kanał pozyskania, segment klienta) – bywa, że ogólnie jest 1%, ale w niektórych niszach 10–20%,
obejrzyj kilka surowych przykładów z każdej klasy – czy są logiczne, dobrze zlabelowane, nie zawierają oczywistych błędów etykiet,
sprawdź, czy klasy nie „przeciekają” przez zmienne – jeśli jedna kolumna niemal idealnie wskazuje klasę (np. status_fraud_flag z systemu regułowego), to zmienia to strategię balansowania.
Nierównowaga klas sama w sobie nie jest problemem. Problemem jest nierównowaga połączona z trudnością odróżnienia klas, słabą jakością etykiet i małą liczbą rzeczywiście „informacyjnych” przykładów.
Ważenie klas: gdy nie chcemy zmieniać danych, tylko sposób uczenia
Najczystsza koncepcyjnie metoda radzenia sobie z nierównowagą to nie ruszać samych danych, tylko zmienić funkcję kosztu tak, aby błędy na rzadkiej klasie „bolały” bardziej. Wiele algorytmów ma do tego gotowy parametr.
Typowe pomysły:
wagi odwrotnie proporcjonalne do liczebności – jeśli klasa pozytywna ma 1% udziału, dostaje wagę około 99, a negatywna 1,
nadawanie ręcznych wag – zgodnie z kosztem biznesowym błędów: false negative w wykrywaniu raka może być znacznie droższy niż false positive,
parametry typu class_weight lub scale_pos_weight – w bibliotkach jak scikit-learn, XGBoost, LightGBM pozwalają zmienić „głośność” klas bez fizycznego modyfikowania zbioru.
Ważenie klas dobrze współgra z zachowaniem oryginalnego rozkładu danych, więc łatwiej później interpretować prawdopodobieństwa i kalibrować model. Zwykle jest to pierwsze narzędzie, po które sięga się przed agresywnym oversamplingiem.
Undersampling: mniej negatywnych, szybciej i prościej
Undersampling polega na losowym (lub sprytniejszym) usuwaniu części obserwacji z klasy dominującej. Zaletą jest prostota i zmniejszenie rozmiaru danych – model uczy się szybciej, a struktura klasy pozytywnej pozostaje nietknięta.
Najprostszy wariant to losowy wybór podzbioru klasy negatywnej tak, by jej liczebność była np. 2–5 razy większa niż klasy pozytywnej. Często jednak da się zrobić coś mądrzejszego:
undersampling warstwowy – tworzymy podzbiór „nie” tak, aby zachował rozkład ważnych cech (np. kraj, kanał, typ klienta),
undersampling informacyjny – zostawiamy przede wszystkim te negatywne, które są „blisko” pozytywnych w przestrzeni cech, bo właśnie tam granica decyzyjna jest najciekawsza.
Minusem jest utrata informacji o pełnym rozkładzie klasy dominującej. Jeśli model ma później działać na całej populacji, trzeba pilnować, by to, co usunięto, nie było systematycznie inne niż to, co zostało (np. nie wycieło się wszystkich małych klientów).
Oversampling: więcej „jedynek”, ale ostrożnie z kopiowaniem
Oversampling to powiększanie klasy mniejszościowej – albo przez proste duplikowanie, albo przez generowanie syntetycznych przykładów. Klasyczne kopiowanie jest kuszące, ale ma jedną oczywistą wadę: przeucza model na kilka tych samych rekordów.
Lepszym podejściem są algorytmy typu:
SMOTE (Synthetic Minority Over-sampling Technique) – generuje nowe przykłady klasy mniejszościowej jako kombinacje istniejących sąsiadów; „wypełnia” przestrzeń między rzadkimi punktami,
ADASYN – wariant SMOTE, który generuje więcej nowych przykładów w regionach, gdzie klasa mniejszościowa jest szczególnie trudno rozpoznawalna,
różne modyfikacje SMOTE dla danych kategorycznych – np. SMOTE-NC, które potrafią obchodzić się ze zmiennymi jakościowymi, zamiast linearnie je interpolować.
Syntetyczne dane zawsze niosą ryzyko wprowadzenia artefaktów: model zaczyna uczyć się gładkich, „wymyślonych” granic, które w prawdziwych danych nigdy się nie pojawią. Dobrą praktyką jest stosowanie oversamplingu tylko na zbiorze treningowym oraz łączenie go z lekkim undersamplingiem klasy negatywnej.
Balansowanie a podział na train/validation/test
Łatwo popełnić błąd, który potrafi zupełnie zafałszować ocenę modelu: najpierw zbalansować dane, a dopiero potem podzielić je na zbiory. Efekt? Zbiory walidacyjne i testowe przestają przypominać rzeczywistość.
Bezpieczniejsza sekwencja:
najpierw dzielisz oryginalne dane na train/validation/test, wciąż z naturalnymi proporcjami klas,
tylko na zbiorze treningowym stosujesz oversampling/undersampling czy inne techniki balansowania,
zbiory walidacyjny i testowy pozostają nietknięte, tak by odzwierciedlały prawdziwe środowisko produkcyjne.
Jeśli nierównowaga jest ekstremalna, czasem dodatkowo stratifikujesz podział (czyli pilnujesz, by każda część miała choć kilka przypadków klasy rzadkiej). W przeciwnym razie łatwo skończyć z walidacją, na której nie ma ani jednego pozytywnego przypadku – model wygląda wtedy idealnie, ale tylko na papierze.
Balansowanie w problemach sekwencyjnych i szeregach czasowych
Przy danych czasowych i sekwencjach sprawa jest trudniejsza. Nie można bezkarnie losować rekordów z całej historii, bo niszczymy strukturę czasową. A jednak w wielu takich zadaniach klasa pozytywna (np. awaria, churn, incydent) wciąż jest rzadkością.
Parę sprawdzonych trików:
balansowanie na poziomie okien – zamiast oversamplować pojedyncze punkty w czasie, pracujesz na oknach (np. 30-dniowe sekwencje) i zwiększasz udział okien prowadzących do zdarzenia pozytywnego,
próbkowanie epizodów – częściej wybierasz epizody z okresów „burzliwych” (blisko zdarzeń pozytywnych), rzadziej z okresów całkowitego spokoju,
Najważniejsze wnioski
Jakość danych jest ważniejsza niż wyrafinowanie algorytmu – prosty model na dobrze wyczyszczonym, spójnym zbiorze potrafi pokonać skomplikowane architektury karmione chaosem.
Większość pracy w ML to nie wybór modelu, lecz żmudny preprocessing: od surowego CSV do sensownego dataframe’u z poprawnymi typami, cechami i logiczną strukturą.
Prawdziwe dane są brudne i niespójne (różne formaty dat, teksty zamiast liczb, duplikaty, outliery, luki czasowe), więc bez zrozumienia, skąd się wzięły i jak powstają, nie da się ich rozsądnie czyścić ani uzupełniać.
Dobry pipeline obejmuje cały łańcuch: czyszczenie, diagnozę i obsługę braków, balansowanie klas, inżynierię cech oraz poprawny podział na zbiory treningowe i walidacyjne z uwzględnieniem czasu.
Kluczowe jest jasne zdefiniowanie problemu i zmiennej docelowej: co dokładnie przewidujemy, kiedy ma być dostępna predykcja i jaki jest koszt błędów typu false positive vs false negative.
Jednostka obserwacji (klient, transakcja, sesja, produkt) musi być jednoznaczna – w przeciwnym razie łatwo o pomieszanie poziomów danych i data leakage, czyli „przeciekanie” informacji z przyszłości do przeszłości.
Świadome decyzje dotyczące braków, outlierów i nierównowagi klas często poprawiają wyniki bardziej niż zmiana modelu; to tutaj doświadczenie i zdrowy rozsądek dają największy zwrot z inwestycji.
Bibliografia
Pattern Recognition and Machine Learning. Springer (2006) – Jakość danych, overfitting, wpływ szumu na modele ML
The Elements of Statistical Learning: Data Mining, Inference, and Prediction. Springer (2009) – Preprocessing, outliery, wybór cech, wpływ danych na generalizację
Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow. O’Reilly Media (2019) – Praktyka: pipeline’y, imputacja, kodowanie cech, podział na zbiory
Imbalanced Learning: Foundations, Algorithms, and Applications. Wiley (2013) – Teoria i praktyka radzenia sobie z niezbalansowanymi klasami
