Skuteczne przygotowanie danych do ML: czyszczenie, balansowanie klas i walka z szumem

Po co tyle zachodu z danymi: wpływ jakości danych na model

Reguła „garbage in, garbage out” w praktyce ML

Uczenie maszynowe jest bezlitośnie wrażliwe na jakość danych. Nawet najlepszy model nie uratuje wyniku, jeśli na wejściu podasz zniekształcone, niekompletne lub źle opisane dane. Reguła „garbage in, garbage out” działa tu z całą mocą: błędne dane wejściowe generują błędne predykcje, a błędne predykcje wprost przekładają się na decyzje biznesowe.

Przykład ze scoringiem kredytowym. Jeśli w danych historycznych masz błędnie zarejestrowane opóźnienia spłat (np. z powodu migracji systemu), model nauczy się, że klienci o pewnym profilu częściej nie spłacają kredytu. Potem będzie odrzucał poprawnych wnioskodawców. Średnie metryki na walidacji mogą wyglądać poprawnie, bo błąd jest systematyczny, ale produkt zachowuje się niespójnie w stosunku do realnego ryzyka.

Drugi przykład: system rekomendacji w e-commerce. Jeśli logi kliknięć zawierają duplikaty sesji albo wiele kliknięć z powodu automatycznego odświeżania strony, model uzna, że pewne produkty są częściej wybierane niż w rzeczywistości. Rekomendacje stają się monotonne, mało różnorodne, a użytkownicy dostają w kółko te same propozycje. Dane nie są „brudne” w sensie oczywistego błędu, ale zawierają zniekształcenie, które wymaga przemyślanego czyszczenia.

Hipermodele kontra porządne przygotowanie danych

Typowa pokusa w projektach ML to gonitwa za coraz bardziej złożonymi modelami: kolejne warstwy sieci, skomplikowane architektury, egzotyczne algorytmy. W praktyce znacznie częściej większy zysk przynosi dopracowany preprocessing: lepsze czyszczenie danych, sensowne inżynieria cech i kontrola szumu.

W wielu projektach przesiadka z prostego modelu liniowego na gradient boosting daje mniejszy przyrost jakości niż zmiana sposobu obsługi braków, dodanie kilku dobrze przemyślanych cech agregujących czy zbalansowanie klas. Modele hybrydowe czy głębokie sieci są uzasadnione dopiero wtedy, gdy dane są stabilne, czyste i reprezentatywne.

Dobry workflow jest taki: najpierw upewnienie się, że dane wiernie odzwierciedlają problem biznesowy, potem solidne czyszczenie i walidacja jakości, a dopiero później eksperymenty z modelami. Bez tego tuning modelu często tylko dopasowuje się mocniej do szumu.

Brudne dane, szum i niezbalansowane klasy a metryki

Brudne dane i niezbalansowane klasy szczególnie mocno psują metryki klasyfikacji. Wyobraź sobie problem detekcji rzadkiego zdarzenia, np. fraudu płatniczego, gdzie klasa pozytywna stanowi promil wszystkich obserwacji. Model, który zawsze przewiduje „brak fraudu”, osiągnie accuracy bliskie 100%. Metryka wygląda imponująco, ale model nie robi absolutnie nic użytecznego.

Brak czyszczenia i balansowania klas w takim problemie powoduje, że klasyfikator uczy się po prostu ignorować rzadkie przypadki. Co gorsza, na walidacji krosowej wyniki nadal mogą być wysokie, jeśli nie zadbasz o sensowny dobór metryk (precision, recall, F1, AUC-PR) i przemyślane próbkowanie. Niski poziom szumu w danych negatywnych i ogromna przewaga liczebna tej klasy maskują realny problem.

Podobnie szum w cechach liczbowych (np. losowo rozrzucone ekstremalne wartości) zwiększa wariancję modelu, zmusza go do skomplikowanych granic decyzyjnych lub do ciągłego „przycinania” wag w regularizacji. Model staje się niestabilny: lekka zmiana danych wejściowych powoduje duże różnice w predykcjach, a deploy kolejnej wersji przynosi nieprzewidywalne efekty.

Biznesowe koszty błędów danych

Problemy z danymi rzadko kończą się na „słabszej metryce w notebooku”. Konsekwencje w realnych projektach są znacznie szersze:

• opóźnienia wdrożeń – długie dochodzenie, skąd wzięły się niespójności, pisanie dodatkowych skryptów naprawczych, ponowne trenowanie modeli,
• fałszywe alarmy – system monitoringu podnosi alerty przez źle sformatowaną datę lub nagły skok duplikatów,
• niezadowoleni użytkownicy – rekomendacje nie trafiają, system scoringowy odrzuca poprawnych klientów, chatbot odpowiada absurdalnie,
• błędne decyzje strategiczne – raporty oparte na nieoczyszczonych danych sugerują zmianę oferty lub polityki cenowej.

Sprawny proces przygotowania danych do uczenia maszynowego staje się więc elementem zarządzania ryzykiem, a nie tylko „technicznym etapem” przed modelowaniem. Każda godzina spędzona na porządnym czyszczeniu często oszczędza tygodnie gaszenia pożarów po wdrożeniu.

Zrozumienie problemu i danych przed dotknięciem kodu

Jasne zdefiniowanie typu problemu ML

Pierwszy krok to precyzyjne nazwanie, jaki problem rozwiązuje model. Inne wymagania wobec danych ma klasyfikacja binarna, inne regresja, jeszcze inne ranking czy detekcja anomalii. Nie chodzi tylko o wybór algorytmu, ale też o to, jakie informacje muszą znaleźć się w danych, żeby model mógł w ogóle nauczyć się sensownych wzorców.

Dla klasyfikacji binarnej (np. churn, fraud, lead scoring) kluczowa jest dobrze zdefiniowana etykieta i sensowny horyzont czasowy. Trzeba jasno określić: co dokładnie znaczy „odszedł”, w jakim okresie, jak liczyć event „pozytywny”. Dla regresji (np. prognoza popytu) ważne jest zachowanie ciągłości w czasie, rozkład wartości, sezonowość i wpływ promocji. Dla rankingu (np. rekomendacje) liczy się struktura interakcji, kolejność i kontekst.

Niedookreślenie problemu skutkuje tym, że etykiety są niejednoznaczne, a dane wejściowe nie zawierają kluczowych sygnałów. Zespół spędza tygodnie na dopieszczaniu kodu, podczas gdy brakuje podstawowych informacji, które dałoby się łatwo pozyskać na etapie projektowania schematu danych.

Co jest obserwacją, cechą i etykietą

Dane produktowe rzadko są zorganizowane tak, jak potrzeba to uczenia maszynowego. Dlatego trzeba jednoznacznie ustalić kilka rzeczy:

• obserwacja – pojedynczy wiersz w zbiorze treningowym; może to być użytkownik, transakcja, sesja, produkt, para użytkownik–produkt itp.,
• cecha (feature) – kolumna opisująca obserwację (wiek użytkownika, średnie wydatki, liczba kliknięć, kraj),
• etykieta (label, target) – wartość, którą model ma przewidywać (czy kupi, ile wyda, czy to fraud).

Pomylenie poziomu agregacji jest jednym z najgorszych błędów. Jeśli problemem jest „czy użytkownik kupi produkt w ciągu 7 dni”, obserwacją powinna być zwykle para (użytkownik, produkt) lub użytkownik w konkretnym oknie czasowym. Jeśli użyjesz pojedynczych eventów jako obserwacji, wprowadzisz gigantyczną ilość szumu i zaburzysz dystrybucję klas.

Warto też od razu spisać, które pola w surowym źródle są kandydatami na cechy, a które na etykietę. Uporządkowanie tego na początku oszczędza późniejszych refaktoryzacji pipeline’ów i dziwnych hacków w kodzie.

Mikro-checklista wstępnego rozpoznania danych

Przed budową jakiegokolwiek modelu przydaje się krótka, powtarzalna checklista. Jedna sesja eksploracyjna według takiej listy potrafi ujawnić więcej niż długie dyskusje o algorytmach.

• Źródła danych:
  • skąd pochodzą dane (system transakcyjny, CRM, logi, zewnętrzne API),
  • ile jest źródeł i jak są łączone (joiny, klucze, okna czasowe).
• Częstotliwość i zasięg:
  • od kiedy dostępne są dane,
  • czy są okresy bez danych (dziury),
  • jak często aktualizowane są rekordy.
• Brakujące wartości:
  • jakie zmienne mają najwięcej braków,
  • czy braki są losowe, czy zależą od segmentu lub czasu.
• Typy zmiennych:
  • które są numeryczne, a są zapisane jako tekst,
  • które są kategoryczne, a przechowywane jako liczby bez słownika.

Taka checklista powinna przechodzić w standardowy raport eksploracyjny. Dobrze jest mieć półautomatyczny notebook lub skrypt, który generuje podstawowe statystyki i wizualizacje przy każdym nowym projekcie.

Dane „produktowe” a dane „analityczne”

Dane w systemach produkcyjnych projektuje się pod szybkie transakcje i spójność operacyjną, nie pod analizy i modele. Pliki logów, bazy transakcyjne, API marketingowe – każde z tych źródeł ma własną strukturę, skróty, stare pola, legacy wartości. Analityk często dostaje mieszankę tego wszystkiego.

Dane „analityczne” to już przetworzony, uporządkowany widok, w którym zduplikowane informacje są scalone, a kluczowe byty (użytkownik, produkt, zamówienie) mają jasne identyfikatory i relacje. Konwersja danych produktowych do analitycznych to zwykle zadanie ETL/ELT: joiny, agregacje, deduplikacje, ujednolicenie formatów.

Uczenie maszynowe stoi na szczycie tej piramidy. Jeśli przeskoczysz etap budowy sensownego warstwy analitycznej i spróbujesz trenować model bezpośrednio na danych produktowych, większość czasu spędzisz na ręcznym łatania braków, konwersjach typów i dziwnych warunkach w kodzie. Znacznie bezpieczniej jest zainwestować w porządny strumień danych analitycznych i dopiero na nim budować pipeline ML.

Audyt jakości danych: odkrywanie braków, niespójności i artefaktów

Podstawowe statystyki i wizualizacje

Systematyczny audyt danych zaczyna się od prostych rzeczy: rozkładów, korelacji, rozkładu klas, zmian w czasie. Te kilka kroków warto zautomatyzować i powtarzać cyklicznie.

Dla każdej kolumny numerycznej przyda się:

• min, max, średnia, mediana, kwartyle, odchylenie standardowe,
• liczba braków i udział procentowy,
• liczba unikalnych wartości.

Dla kolumn kategorycznych:

• liczba unikalnych kategorii,
• top-k najczęstszych kategorii z częstością,
• udział kategorii rzadkich (np. poniżej 1% obserwacji).

Do tego proste wizualizacje: histogramy, wykresy pudełkowe, wykresy rozkładu w czasie. Jedno spojrzenie na histogram dat potrafi ujawnić, że przez kilka miesięcy dane nie były logowane albo logowanie przeszło na inny format i część okresu zniknęła z widoku.

Typowe problemy jakości danych

W większości projektów ML pojawia się powtarzalny zestaw problemów. Im szybciej je zidentyfikujesz, tym mniej późniejszych niespodzianek.

• Duplikaty:
  • te same rekordy powtórzone kilkukrotnie po błędzie w systemie integracyjnym,
  • logi eventów zapisywane przez kilka warstw (np. backend i front) bez deduplikacji.
• Sprzeczne rekordy:
  • różne wartości dla tego samego klucza głównego (np. dwa adresy dla jednego klienta bez dat ważności),
  • różne stany zamówienia w zależności od systemu źródłowego.
• Błędne typy:
  • liczby zapisane jako tekst z dodatkowymi znakami (spacje, waluty, różne separatory dziesiętne),
  • daty w wielu formatach, mieszające się w jednej kolumnie.
• Nierealistyczne wartości:
  • data urodzenia w przyszłości,
  • wartość transakcji ujemna, gdy nie powinna,
  • wieki powyżej rozsądnych progów (np. 150 lat).

Część z tych problemów da się złapać prostymi regułami, część wymaga zrozumienia domeny i konsultacji z właścicielem systemu źródłowego. Najgorszy scenariusz to bezrefleksyjne przyjęcie danych jako „prawdziwych” tylko dlatego, że pochodzą z systemu produkcyjnego.

Wykrywanie driftu danych i zmian definicji pól

Nawet jeśli dane startowe wyglądają dobrze, z czasem wszystko się zmienia. Zmieniają się produkty, regulaminy, procesy, a wraz z nimi systemy zapisujące dane. Z punktu widzenia ML kluczowe są dwa zjawiska: data drift i concept drift.

• Data drift – zmienia się rozkład cech wejściowych; np. pojawia się nowy typ urządzeń, nowy kraj, inny profil klientów. Model widzi inne dane niż w treningu.
• Concept drift – zmienia się relacja między cechami a etykietą; np. po wprowadzeniu nowej polityki kredytowej ryzyko określonych klientów spada, mimo że cechy wejściowe są podobne.

Monitoring jakości danych w czasie

Jednorazowy audyt na starcie projektu nie wystarcza. Potrzebny jest prosty monitoring, który wychwyci zmiany w danych zanim model zacznie się zachowywać dziwnie na produkcji.

• Kontrola rozkładu cech – dla każdej kluczowej cechy przechowuj:
  • średnią, medianę, kwartyle, min/max,
  • udział braków,
  • liczbę unikalnych wartości (dla kategorii).

  Porównuj te statystyki w czasie (dzień do dnia, tydzień do tygodnia). Skoki sygnalizują zmianę w źródle lub zachowaniu użytkowników.

• Monitoring etykiety – jeśli target jest znany dopiero po czasie (np. churn po 30 dniach), utrzymuj osobny monitoring:
  • udział klasy pozytywnej/negatywnej w czasie,
  • czas do wystąpienia zdarzenia (np. ile dni do churnu).
• Alerty na zmiany schematu – prosty test schematu (obecność kolumn, typy, słowniki kategorii) uruchamiany przy każdym batchu danych. Przy pierwszym błędzie pipeline powinien się zatrzymać i zgłosić problem.

Narzędzia typu „data quality / data monitoring” są wygodne, ale na początek wystarczy cron z notebookiem generującym raport i prostymi progami alarmowymi.

Techniczne wskaźniki driftu

Ręczne oglądanie histogramów szybko przestaje skalować się do dziesiątek cech. Pomagają proste, zautomatyzowane miary podobieństwa rozkładów.

• PSI (Population Stability Index) – porównuje rozkład cechy w danych bieżących do rozkładu z treningu:
  • cechę dzielisz na koszyki (np. decyle),
  • liczysz udział obserwacji w każdym koszyku dla zbioru referencyjnego i bieżącego,
  • sumujesz różnice według wzoru PSI.

  Wysoki PSI dla cechy to sygnał, że rozkład się znacząco zmienił.

• Testy statystyczne:
  • dla zmiennych ciągłych – test KS (Kolmogorov–Smirnov),
  • dla kategorii – chi-kwadrat lub odległość KL (Kullback–Leibler).
• Monitoring nowych i znikających kategorii – osobna metryka: liczba nowych kategorii vs. znanych ze zbioru treningowego oraz kategorie, które przestały się pojawiać.

Te wskaźniki same niczego nie naprawią, ale pokazują, które cechy zaczynają „odjeżdżać” i czy problem jest lokalny (kilka feature’ów) czy globalny (cały strumień danych).

Czyszczenie danych krok po kroku: brakujące wartości, duplikaty, błędy logiczne

Strategia zamiast zbioru przypadkowych hacków

Czyszczenie danych często kończy się w kodzie jako zbiór ad-hoc warunków. Lepsze podejście to spójna strategia oparta na kilku pytaniach dla każdej zmiennej:

• czy zmienna jest istotna dla biznesu lub modelu,
• jakie ma typowe zakresy i jednostki,
• jaki jest mechanizm powstawania braków,
• jakie reguły logiczne musi spełniać (kontra inne pola).

Na tej podstawie tworzysz konkretne reguły czyszczenia i dokumentujesz je w jednym miejscu (np. w YAML-u lub tabeli konfiguracyjnej), zamiast rozsypywać po notebookach.

Obsługa brakujących wartości

Brak danych to osobna informacja, nie „zero”. Obsługa braków powinna łączyć statystykę z logiką biznesową.

Diagnoza braków

• Mapa braków – prosta macierz (obserwacja × cecha) pokazująca, gdzie brakuje wartości. Dobrze widać wtedy, czy braki skupiają się w konkretnych okresach, segmentach klientów lub typach produktów.
• Współwystępowanie braków – sprawdź, czy braki w jednej kolumnie „ciągną” za sobą braki w innych. To często wskazuje na problem źródłowy (np. brak eventu źródłowego).

Strategie imputacji

Wybór strategii zależy od typu zmiennej i mechanizmu braków.

• Usunięcie obserwacji – rozsądne, gdy:
  • brak dotyczy kluczowego pola (np. brak etykiety),
  • odsetek braków jest mały i wydaje się losowy.
• Stała techniczna – np. -1 dla ID lub osobna kategoria „UNKNOWN”:
  • przydatne, gdy brak niesie informację (np. brak limitu kredytowego),
  • dobrze działa z drzewami decyzyjnymi, gorzej z modelami liniowymi bez odpowiedniej normalizacji.
• Imputacja prostą statystyką:
  • średnia/mediana dla zmiennych numerycznych,
  • moda dla kategorycznych,
  • grupowa imputacja (np. mediana w segmencie kraju/produktu).
• Imputacja modelowa – osobny model przewiduje brakującą wartość:
  • warto stosować tylko dla nielicznych, krytycznych zmiennych,
  • dobrze udokumentować cechy używane do imputacji, by nie wprowadzić przecieku (leakage).

Częsta praktyka: dodanie binarnego wskaźnika „czy_cecha_brakująca”, a samą wartość imputujesz medianą lub stałą. Model może wtedy sam zdecydować, czy sam brak jest istotny.

Polityka duplikatów

Duplikaty dzielą się na „identyczne” i „prawie identyczne”. Każdy typ wymaga innego podejścia.

• Duplikaty 1:1 – wszystkie kolumny identyczne:
  • często wynik błędu integracji lub wielokrotnego ładowania pliku,
  • w większości przypadków można je bezpiecznie usunąć, zostawiając pojedynczy rekord.
• Duplikaty po kluczu – ten sam klucz główny (np. user_id, order_id) ma wiele rekordów:
  • potrzebujesz jasnej reguły: ostatni stan, pierwszy stan, agregacja (np. max, min, suma),
  • czasami lepiej zbudować osobną tabelę historii, a do modelu użyć zdefiniowanej agregacji po czasie.

Warto mieć prosty raport: liczba duplikatów po kluczu głównym, lista pól, które się różnią. To często ujawnia ukryte reguły biznesowe (np. zmiany statusu, poprawki ręczne).

Weryfikacja i naprawa błędów logicznych

Same zakresy wartości nie wystarczą. Trzeba sprawdzić relacje między polami, czyli prostą „logikę świata”.

• Reguły czasowe:
  • data_zamówienia <= data_wysyłki,
  • data_urodzenia <= data_rejestracji,
  • okres_start <= okres_koniec.
• Reguły arytmetyczne:
  • kwota_brutto ≈ kwota_netto + podatek,
  • suma_linii_zamówienia ≈ kwota_zamówienia,
  • liczba_aktywności = liczba_kliknięć + liczba_wyświetleń, jeśli tak zdefiniowano.
• Reguły spójności kategorii:
  • status_zamówienia = „zwrócone” ⇒ kwota_zwrotu > 0,
  • typ_konta = „firmowe” ⇒ NIP niepusty,
  • kanał = „offline” ⇒ brak identyfikatora kampanii online.

Zamiast twardo usuwać wszystkie rekordy niezgodne z regułami, lepiej wprowadzić politykę:

• krytyczne złamania reguł – odrzucenie rekordu,
• niekrytyczne – korekta (np. ucięcie do maksymalnej sensownej wartości) + flaga techniczna „rekord_skorigowany”.

Przekształcanie cech: skalowanie, kodowanie i inżynieria cech pod konkretne modele

Dobór transformacji do rodziny modeli

Różne algorytmy mają inne wymagania co do formy cech. Zamiast stosować „zestaw standardowy” wszędzie, warto dopasować przekształcenia do planowanego modelu bazowego.

• Modele liniowe (logistic/linear regression, GLM):
  • wrażliwe na skalę – potrzebują standaryzacji lub normalizacji,
  • często wymagają ręcznej inżynierii cech (interakcje, transformacje nieliniowe),
  • źle znoszą wysoką krotność kategorii przy prostym one-hot (przekleństwo wymiarowości).
• Drzewa decyzyjne i boosting (XGBoost, LightGBM, CatBoost):
  • mniej wrażliwe na skalę, często można pominąć skalowanie,
  • dobrze radzą sobie z monotonicznymi transformacjami typu log,
  • nie lubią szumu w postaci dziesiątek prawie pustych kategorii.
• Modele oparte na odległości (kNN, k-means) i sieci neuronowe:
  • skalowanie kluczowe (często min–max lub standaryzacja),
  • cechy o większej skali dominują bez normalizacji.

Skalowanie i normalizacja

Skalowanie nie jest celem samym w sobie. Chodzi o to, by model nie był zdominowany przez cechy o dużych liczbach.

• Standaryzacja (z-score) – odejmujesz średnią, dzielisz przez odchylenie standardowe:
  • sprawdza się w modelach liniowych i sieciach neuronowych,
  • wymaga zapisania parametrów (średnia, sigma) z treningu i użycia ich przy inferencji.
• Min–max – przeskalowanie do [0,1]:
  • przydaje się, gdy cechy mają naturalne dolne/górne granice,
  • wrażliwe na outliery – ekstremalna wartość „rozciąga” skalę.
• Skalowanie robust – używa mediany i IQR:
  • lepsze, gdy rozkład ma długi ogon,
  • kompromis między informacją o skali a odpornością na outliery.

Transformację liczysz wyłącznie na zbiorze treningowym. Parametry przenosisz do walidacji i produkcji. Inaczej wprowadzasz przeciek informacji z przyszłości.

Kodowanie zmiennych kategorycznych

Kategorie trzeba zamienić na liczby z głową. Sposób kodowania mocno wpływa na stabilność modelu na nowych danych.

Kodowanie prostymi metodami

• One-hot encoding:
  • bezpieczny, przejrzysty, dobrze działa dla małej liczby kategorii,
  • przy dużej kardynalności (np. tysiące produktów) generuje ogromną macierz,
  • wymaga polityki dla kategorii niewidzianych na treningu (np. kolumna „OTHER”).
• Label encoding:
  • proste przypisanie numeru do kategorii,
  • dla drzew może działać, ale bywa mylące (porządek liczb sugeruje relacje, których nie ma),
  • dla modeli liniowych bez sensu – sztuczny porządek.

Kodowanie oparte na statystykach (target encoding i pochodne)

Przy wysokiej kardynalności i modelach drzewiastych często stosuje się kodowanie oparte na targetcie.

• Target encoding – każdą kategorię zamieniasz na:
  • średnią wartości targetu w tej kategorii (dla regresji),
  • udział klasy pozytywnej (dla klasyfikacji binarnej).
• Problemy i zabezpieczenia:
  • leakage: nie wolno liczyć kodowania na całym zbiorze, musisz robić to wewnątrz cross-validation (fold-by-fold),
  • kategorie rzadkie – potrzebna regularizacja w kierunku średniej globalnej (np. mieszanka: średnia kategorii + średnia globalna z wagą zależną od liczności),
  • kategorie niewidziane – używają średniej globalnej lub średniej grupy nadrzędnej (np. segment produktu).

Inżynieria cech pod konkretny problem

Największe zyski z jakości predykcji często biorą się z dobrych cech, nie z wymiany modelu. Tu najlepiej działają proste, ale przemyślane transformacje.

Cechy agregowane po czasie

Cechy agregowane po czasie

Surowe logi rzadko nadają się bezpośrednio do modelu. Typowy schemat: masz zdarzenia (kliknięcia, transakcje, logowania), a potrzebujesz jednej linijki na użytkownika lub zamówienie. Tu wchodzą agregacje czasowe.

• Okna czasowe:
  • „ostatnie 7 dni”, „ostatnie 30 dni”, „ostatnie 3 miesiące” – osobne zestawy cech dla każdego okna,
  • dobrze oddzielać okna „krótkie” (zachowanie bieżące) od „długich” (trend długoterminowy).
• Agregaty ilościowe:
  • liczba transakcji,
  • suma/średnia wartości,
  • liczba unikalnych produktów/kategorii.
• Agregaty behawioralne:
  • udział transakcji w weekendy vs. dni robocze,
  • udział transakcji nocnych (np. 22–6),
  • średni odstęp między zdarzeniami (czas między logowaniami, zakupami).

Przy tworzeniu okien ważne jest cięcie po czasie referencyjnym. Jeśli budujesz model churnu „na dzień X”, wszystkie agregacje liczysz tylko ze zdarzeń z przeszłości (do X), nigdy z przyszłości. W praktyce oznacza to często osobną tabelę „snapshotów” na dzień oceny.

Relacje i interakcje między cechami

Wiele zależności jest nieliniowych. Proste interakcje potrafią „odkleić” model od założeń liniowości.

• Stosunki/ratio:
  • zadłużenie_do_dochodu,
  • liczba_zwrotów_do_liczby_zakupów,
  • otwarte_tiki_do_wszystkich_tików (support).
• Różnice:
  • aktualne_saldo − saldo_miesiąc_temu,
  • cena − średnia_cena_kategorii,
  • czas_od_ostatniej_aktywności (timestamp_ref − ostatni_event).
• Interakcje kategoryczne:
  • połączenie kraj × kanał_sprzedaży,
  • segment_klienta × typ_produktu.

Przy modelach liniowych część interakcji trzeba wprost dodać (np. jako nowe kolumny). Algorytmy drzewiaste część z nich odkryją same, ale jawne cechy nadal mogą pomóc, szczególnie gdy chcesz wymusić pewne relacje biznesowe lub ograniczyć głębokość drzew.

Transformacje nieliniowe i bucketowanie

Niektóre zmienne działają lepiej po „podcięciu” lub nieliniowej transformacji.

• Transformacje typu log:
  • log(1 + x) przy kwotach, liczbach transakcji, odsłonach,
  • zmniejszają wpływ ekstremalnie wysokich wartości.
• Binning (bucketowanie):
  • dzielenie na przedziały: wiek, liczba_dni_od_rejestracji, kwota_zakupu,
  • ułatwia modele liniowe i tworzy cechy bliższe „regułom” znanym analitykom,
  • często stosuje się kwantyle (decyli/percentyle), nie stałe przedziały co 10 jednostek.

Przy binningu opłaca się sprawdzić stabilność rozkładu w czasie. Jeżeli w ciągu roku biznes mocno rośnie, przedziały kwantylowe ustalone na starych danych mogą przestać mieć sens – potrzebny jest mechanizm ich odświeżania.

Balansowanie klas i praca z niezbalansowanymi danymi

W wielu zastosowaniach klasy pozytywne są rzadkie: oszustwo, default kredytowy, churn, awarie. Model, który „nigdy” nie przewiduje klasy 1, może mieć wysoką dokładność, a jednocześnie zero wartości biznesowej.

Diagnoza problemu niezbalansowania

Najpierw trzeba policzyć podstawowe statystyki. Prosty raport wystarcza, by zorientować się w skali problemu.

• proporcje klas (np. 1:20, 1:100),
• rozkład klas w czasie (czy rzadkie zdarzenia pojawiają się w „pasmach”),
• rozkład klas po głównych segmentach (kraj, produkt, kanał).

Następnie testujesz bazowe modele bez balansu, monitorując nie accuracy, ale metryki wrażliwe na niezbalansowanie: precision, recall, F1, PR-AUC, G-mean. To punkt odniesienia dla późniejszych technik.

Balansowanie na poziomie próbkowania

Najbardziej intuicyjne podejście: zmienić rozkład danych w treningu. W zależności od danych i celu możesz usuwać nadreprezentowaną klasę lub dociążać klasę rzadką.

• Undersampling klasy większościowej:
  • losowe usuwanie części przykładów klasy 0,
  • proste, szybkie, ale można utracić różnorodność – model gorzej generalizuje,
  • czasami pomaga sprytne undersampling, np. zachowanie „najbliższych” przykładów wokół klasy mniejszościowej.
• Oversampling klasy mniejszościowej:
  • proste duplikowanie przypadków pozytywnych,
  • ryzyko przetrenowania – model „nauczy się na pamięć” tych samych obserwacji,
  • dobrze działa w połączeniu z silną regularyzacją lub drzewami z ograniczeniami.

Na etapie walidacji i testu danych nie balansujesz. Tam używasz naturalnego rozkładu i sprawdzasz, jak model zachowuje się w rzeczywistości.

Metody syntetyczne: SMOTE i warianty

Aby uniknąć prostego kopiowania, stosuje się metody generowania sztucznych przykładów klasy rzadkiej.

• SMOTE (Synthetic Minority Over-sampling Technique):
  • tworzy nowe punkty jako interpolacje między istniejącymi przykładami klasy mniejszościowej,
  • lepiej zachowuje różnorodność niż duplikowanie,
  • może „wlać” dane klasy mniejszościowej w obszary klasy większościowej – potrzebna ostrożność.
• ADASYN, Borderline-SMOTE:
  • kładą większy nacisk na punkty „trudne” lub z pogranicza klas,
  • mogą pomóc, gdy ważne są punkty z brzegu decyzyjnego, ale rośnie ryzyko generowania nielogicznych przykładów.

Metody syntetyczne stosuje się wyłącznie na zbiorze treningowym, po podziale train/validation, nigdy wcześniej. Przy danych z ograniczeniami biznesowymi (np. reguły finansowe, medyczne) dobrze jest zweryfikować losowo kilka wygenerowanych przykładów – choćby prostymi regułami logicznymi opisanymi wcześniej.

Dostosowanie wag klas w algorytmie

Zamiast zmieniać dane, można zmienić funkcję kosztu. Większość bibliotek pozwala na nadanie wag klasom.

• class_weight w modelach liniowych i drzewach:
  • większa kara za błędną klasyfikację klasy rzadkiej,
  • proste ustawienie: odwrotnie proporcjonalnie do częstości klasy,
  • dobrze działa jako pierwsze przybliżenie, często bez ingerencji w dane.
• Własna funkcja kosztu:
  • ważone logloss lub focal loss (w boostingach, sieciach),
  • możliwość odzwierciedlenia realnych kosztów biznesowych: fałszywy negatyw >> fałszywy pozytyw.

Ustawiając wagi, dobrze jest przetestować różne konfiguracje na walidacji, patrząc nie tylko na F1, ale także na krzywą precision–recall i sensowny punkt odcięcia (threshold) dla konkretnej decyzji biznesowej.

Balansowanie a leakage i walidacja

Balansowanie wprowadza dodatkową złożoność do procesu walidacji. Kilka prostych zasad porządkuje temat:

• najpierw dzielisz dane na train/validation/test (w czasie lub losowo),
• balansujesz wyłącznie część treningową w ramach każdego folda,
• wagi klas i próbkowanie dokumentujesz jako element pipeline’u, aby odtworzyć proces w przyszłości.

Jeżeli danych klasy mniejszościowej jest bardzo mało, lepiej skupić się na dobrej walidacji czasowej i prostych modelach niż na wyrafinowanych technikach syntetycznych, które dodatkowo utrudniają interpretację.

Outliery i obserwacje podejrzane: jak rozróżnić szum od sygnału

Definicja outliera w kontekście biznesowym

Outlier to nie tylko „wartość odległa statystycznie”. Często jest to po prostu nietypowe, ale prawdziwe zachowanie klienta, urządzenia lub procesu. Pierwszy krok: odróżnić błąd od rzadkiego, ale realnego zjawiska.

• Outlier techniczny:
  • nierealne wartości (wiek > 120, ujemne ilości produktów bez kontekstu zwrotu),
  • artefakty integracyjne (duplikacja danych, złą skala, pomylone jednostki).
• Outlier behawioralny:
  • klient z bardzo wysokim koszykiem, ale zgodnym z logiką (hurtownik w systemie B2C),
  • urządzenie generujące nietypowe, ale spójne odczyty (specjalny tryb pracy).

Outliery techniczne zwykle trzeba naprawić lub usunąć. Outliery behawioralne bywają najcenniejszym sygnałem – szczególnie w detekcji nadużyć lub awarii.

Proste metody wykrywania outlierów

Nie trzeba od razu skomplikowanych algorytmów. Kilka prostych raportów daje sporą widoczność.

• Reguły progowe:
  • twarde limity znane z biznesu (maksymalna możliwa kwota, liczba produktów w koszyku, zakres temperatury),
  • przycinanie do rozsądnych wartości i oznaczanie rekordu flagą techniczną.
• Reguły oparte na rozkładzie:
  • znaczne odchylenia od mediany: np. wartości poza [Q1 − 1.5×IQR, Q3 + 1.5×IQR],
  • punktowo: |x − μ| > k × σ (z ostrożnością przy rozkładach ciężkoogonowych).
• Reguły wielowymiarowe:
  • połączenie kilku cech: np. wysoka kwota przy bardzo krótkim czasie rejestracji,
  • klastrowanie (k-means, DBSCAN) i obserwacje daleko od centrów klastrów.

W praktyce dobrze działa podejście mieszane: proste reguły biznesowe + kilka wskaźników statystycznych, wizualizowanych na wykresach pudełkowych lub scatter plotach.

Strategie obchodzenia się z outlierami

Sposób traktowania outlierów zależy od tego, co model ma robić i jak wygląda koszt błędów.

• Usuwanie rekordów:
  • stosujesz, gdy masz mocne dowody, że to błąd (np. ujemny wiek, odczyt spoza fizycznie możliwego zakresu),
  • musisz sprawdzić, czy nie usuwasz istotnej części jednej z klas (np. wszystkie oszustwa mają ekstremalne wartości).
• Winsoryzacja (przycinanie):
  • zamiana wartości powyżej określonego percentyla (np. 99,5) na wartość graniczną,
  • zmniejsza wpływ skrajnych punktów w modelach liniowych,
  • zachowuje rekord, ale ogranicza jego „siłę przebicia”.
• Transformacje odporne:
  • log(1 + x), sqrt(x), Box–Cox, Yeo–Johnson,
  • spłaszczają ogony rozkładu, przez co outliery mniej zaburzają optymalizację.
• Specjalne traktowanie w modelu:
  • dodanie flag „ekstremalny_wynik_cechy_X”,
  • oddzielne modele dla segmentu „normalnego” i „ekstremalnego”.

Wykorzystanie flag technicznych ma tę zaletę, że dane pozostają możliwie surowe, a model może sam zadecydować, czy dany ekstremum coś znaczy. To podejście dobrze gra z modelami drzewiastymi.

Outliery a modele drzewiaste i liniowe

Drzewa decyzyjne w naturalny sposób są mniej wrażliwe na outliery niż modele liniowe, ale nie oznacza to, że temat można całkowicie zignorować.

Co warto zapamiętać

• Jakość danych bezpośrednio decyduje o jakości modelu – nawet najlepszy algorytm nie skompensuje błędnych, zniekształconych czy niekompletnych danych (klasyczna zasada „garbage in, garbage out”).
• Systematyczne błędy danych (np. źle zarejestrowane opóźnienia spłat, duplikaty w logach kliknięć) mogą dawać „ładne” metryki na walidacji, a jednocześnie prowadzić do fatalnych decyzji biznesowych i nielogicznych zachowań produktu.
• Większy zwrot daje porządne przygotowanie danych (czyszczenie, sensowna obsługa braków, inżynieria cech, balansowanie klas) niż pogoń za coraz bardziej skomplikowanymi modelami i architekturami.
• Brudne dane, szum i niezbalansowane klasy szczególnie fałszują metryki klasyfikacji – model może mieć wysokie accuracy, a jednocześnie kompletnie ignorować rzadkie, kluczowe przypadki (np. fraudy).
• Źle kontrolowany szum w cechach (np. przypadkowe ekstremalne wartości) zwiększa wariancję modelu, powoduje niestabilne predykcje i sprawia, że kolejne wdrożenia zachowują się nieprzewidywalnie.
• Problemy z danymi generują realne koszty biznesowe: opóźnienia wdrożeń, fałszywe alarmy monitoringu, frustrację użytkowników i błędne decyzje strategiczne oparte na zafałszowanych raportach.
• Punkt wyjścia to dobre zrozumienie problemu i danych: precyzyjne zdefiniowanie typu zadania ML, etykiety, horyzontu czasowego oraz jasne ustalenie, czym jest obserwacja, cecha i etykieta zanim powstanie pierwsza linijka kodu.

Bibliografia

• Pattern Recognition and Machine Learning. Springer (2006) – Podstawy ML, wpływ jakości danych i szumu na modele
• The Elements of Statistical Learning: Data Mining, Inference, and Prediction. Springer (2009) – Modele statystyczne, przeuczenie, szum i przygotowanie danych
• Data Preparation for Data Mining. Morgan Kaufmann (1999) – Klasyczna pozycja o czyszczeniu, transformacji i jakości danych
• Imbalanced Learning: Foundations, Algorithms, and Applications. Wiley (2013) – Teoria i praktyka uczenia z niezbalansowanymi klasami
• Learning from Imbalanced Data Sets. AAAI Press (2000) – Artykuł przeglądowy o problemach i metrykach przy klasach rzadkich
• Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow. O’Reilly Media (2023) – Praktyczne techniki czyszczenia danych, inżynierii cech i walidacji
• Feature Engineering and Selection: A Practical Approach for Predictive Models. CRC Press (2019) – Metody inżynierii cech, agregacji i redukcji szumu
• Data Cleaning: Problems and Current Approaches. IEEE Computer Society (1996) – Przegląd technik czyszczenia danych i typowych błędów w zbiorach
• CRISP-DM 1.0: Step-by-step Data Mining Guide. SPSS (2000) – Standardowy proces: zrozumienie problemu, danych i przygotowanie przed modelowaniem
• Machine Learning Yearning. deeplearning.ai (2018) – Praktyczne wskazówki o priorytecie jakości danych nad złożonością modeli