Dlaczego przygotowanie danych decyduje o jakości modeli
Większość problemów z modelami uczenia maszynowego nie wynika z wyboru algorytmu, ale z jakości danych wejściowych. Nawet najlepszy model nie uratuje sytuacji, jeśli dane są brudne, niespójne albo nieprzygotowane do zadania.
Relacja jest prosta: lepsze dane dają więcej niż bardziej skomplikowany model. Zamiast przerzucać się z XGBoost na najnowsze architektury deep learning, częściej opłaca się poświęcić czas na solidne czyszczenie, obsługę braków, sensowne skalowanie i kodowanie zmiennych.
Typowy przykład: model prognozujący sprzedaż, w którym:
daty są w różnych formatach (dzień-miesiąc-rok vs miesiąc-dzień-rok),
część cen jest w złotówkach, część w groszach,
brakujące ceny zastąpiono zerami, „bo tak było najprościej”.
Na zbiorze treningowym model może mieć sensowne metryki. Na produkcji zaczyna jednak generować absurdalne prognozy dla konkretnych miesięcy, nowych produktów albo promocji, których nie widział podczas treningu. Źródło problemów nie leży w algorytmie regresji, tylko w tym, że preprocessing wprowadził systematyczne przekłamania.
Słaby preprocessing prowadzi do kilku przewidywalnych skutków:
overfitting – model dopasowuje się do szumu, błędów i artefaktów w danych, które nie wystąpią później,
niestabilne predykcje – drobne zmiany w danych wejściowych powodują skoki wyników,
data leakage – informacje z przyszłości lub z etykiety przedostają się do cech, zawyżając wyniki na walidacji,
rozjazd między treningiem a produkcją – transformacje zastosowane na etapie uczenia nie są wiernie odtworzone w pipeline produkcyjnym.
Dlatego przygotowanie danych do uczenia maszynowego trzeba traktować jak część modelu, a nie „przygotówkę” przed właściwą pracą.
Charakterystyka danych do ML: typy, skale, rozkłady
Typy zmiennych i ich znaczenie dla preprocessing’u
Efektywny preprocessing zaczyna się od poprawnej klasyfikacji zmiennych. Inaczej traktuje się liczby ciągłe, inaczej kategorie tekstowe, a jeszcze inaczej dane czasowe.
Podstawowy podział wygląda tak:
numeryczne ciągłe – np. dochód, temperatura, cena; można je porównywać i sensownie liczyć różnice,
numeryczne dyskretne – np. liczba transakcji, liczba dzieci; wartości całkowite, ale często można je traktować jak ciągłe,
kategoryczne nominalne – np. kraj, kolor, typ produktu; brak naturalnego porządku,
kategoryczne porządkowe – np. poziom wykształcenia, skala ocen; istnieje kolejność, ale odległości między poziomami nie są równe,
czasowe – daty, timestampy, sekwencje czasowe; wymagają innego podejścia do braków, outlierów i podziałów na zbiory.
Typ zmiennej bezpośrednio wpływa na wybór metod:
numeryczne można skalować (standardyzacja, normalizacja) i imputować średnią lub medianą,
kategoryczne wymagają kodowania (one-hot, target encoding i inne),
tekstowe często przekształca się do reprezentacji liczbowej (TF-IDF, embeddingi),
czasowe rozbija się na cechy kalendarzowe (dzień tygodnia, miesiąc), interwały, opóźnienia (lag) itd.
Szczególna grupa to zmienne techniczne:
identyfikatory (ID klienta, ID zamówienia) – zwykle nie nadają się jako cechy; traktuje się je jako klucze do łączenia tabel,
kody (np. kody produktów, numery kont) – podobnie jak ID, niosą mało sensownej struktury dla większości modeli,
flagi binarne (0/1, True/False) – nie wymagają skalowania; trzeba jedynie zadbać o spójny typ (int/bool).
Umieszczenie identyfikatora w modelu bez przemyślenia często prowadzi do katastrofalnego overfittingu. Model „uczy się” specyficznych ID zamiast wzorców, co na walidacji może wyglądać dobrze, a na produkcji generuje losowe wyniki.
Skale i rozkłady cech numerycznych
Nawet jeśli zmienne są poprawnie oznaczone jako numeryczne, trzeba rozumieć ich skalę i rozkład. To decyduje o sposobie skalowania i imputacji.
Przykładowe skale:
surowe wartości – np. kwota w złotówkach, liczba dni; skalowanie zależy od zakresu,
procenty – np. marża, konwersja; często ograniczone do zakresu 0–1 lub 0–100,
wartości logarytmiczne – np. log-przychodu; nadmierne skalowanie może zniszczyć interpretację,
wskaźniki – np. liczba transakcji na klienta; często mają skośne rozkłady i outliery.
Rozkłady danych można z grubsza podzielić na:
symetryczne – zbliżone do normalnych; dobrze współpracują ze standardyzacją (odjęcie średniej, podzielone przez odchylenie),
skośne – większość obserwacji małe, kilka bardzo dużych; czasem przydaje się transformacja logarytmiczna,
z długim ogonem – ekstremalne wartości mocno oddziałują na średnią i odchylenie standardowe,
z outlierami – pojedyncze wartości daleko poza typowym zakresem.
Te informacje są kluczowe przed skalowaniem i imputacją. StandardScaler na zmiennej z ciężkimi outlierami spowoduje „rozciągnięcie” skali, co utrudni naukę modelu. Imputacja średnią w rozkładzie bardzo skośnym wprowadza wartość, która w praktyce prawie nie występuje. Często lepszym wyborem jest mediana lub imputacja warunkowa.
Wstępna inspekcja danych: zanim cokolwiek zmienisz
Podstawowe oględziny zbioru
Pierwszy krok to szybki przegląd struktury danych. Kilkanaście minut inspekcji potrafi ujawnić problemy, które później kosztują tygodnie pracy.
Podstawowy zestaw pytań:
ile jest wierszy i kolumn – rząd wielkości ma znaczenie dla wyboru metod (np. złożone imputacje),
jaki jest procent braków w każdej kolumnie – czy mówimy o pojedynczych ubytkach czy o kolumnach „pustych w połowie”,
jakie są typy danych – czy liczby nie są wczytane jako teksty, czy daty nie są stringami.
Przydatne są podstawowe statystyki opisowe:
dla zmiennych numerycznych: minimum, maksimum, kwantyle, średnia, odchylenie,
dla kategorycznych: liczba unikalnych wartości, najczęstsze wartości i ich częstości.
Proste wizualizacje (nawet w notatniku Jupyter) szybko ujawniają problemy:
wykresy braków – np. macierz braków, heatmapy korelacji z brakami.
Na tym etapie chodzi o ogólne wyczucie danych, a nie o „naprawianie wszystkiego”. Dobrze jest zapisać sobie wnioski: które kolumny są najbardziej problematyczne, gdzie widać dziwne zakresy, co wymaga konsultacji z osobą od domeny.
Kontrola spójności i zgodności z domeną
Drugi krok to porównanie danych z tym, jak działa rzeczywistość biznesowa lub proces, z którego pochodzą. Bez tego łatwo zaakceptować wartości, które są statystycznie „w porządku”, ale biznesowo niemożliwe.
Typowe problemy spójności:
wartości niemożliwe – ujemny wiek, ilość sprzedanych sztuk poniżej zera, daty z przyszłości w danych historycznych,
niewłaściwe zakresy – marża powyżej 100%, odsetek konwersji powyżej 1 (jeśli skala 0–1),
sprzeczne kolumny – data zakończenia wcześniej niż data rozpoczęcia, status „zamknięte” przy zerowej kwocie.
Należy sprawdzić również unikalność identyfikatorów i duplikaty rekordów:
czy klucz główny (np. ID zamówienia) jest rzeczywiście unikalny,
czy nie ma wielu rekordów dotyczących tego samego zdarzenia,
czy duplikaty nie powstały przy łączeniu źródeł.
Bardzo przydatne są rozmowy z ekspertem domenowym lub analiza dokumentacji systemu źródłowego. To tam znajdzie się informacja, że np. „status X oznacza transakcję testową” i wszystkie takie wiersze trzeba wykluczyć z modelu, bo nie odzwierciedlają realnego procesu.
Duplikaty to nie tylko identyczne wiersze. Częściej chodzi o powtarzające się klucze lub częściowo zdublowane informacje.
Podstawowe rodzaje duplikatów:
identyczne wiersze – wszystkie kolumny są takie same; zwykle można je bezpiecznie usunąć,
duplikujące się klucze – to samo ID klienta lub zamówienia, ale różne wartości innych kolumn,
duplikaty częściowe – prawdopodobnie to samo zdarzenie wpisane na dwa sposoby (np. różnice w polach tekstowych).
Samo „drop_duplicates” bywa zbyt prymitywne. W wielu przypadkach lepszą strategią jest:
agregacja rekordów (np. zsumowanie ilości dla tego samego ID w danym dniu),
wybranie najświeższego rekordu na podstawie daty aktualizacji,
łączenie informacji (np. braki w jednym wierszu uzupełnić z innego wiersza o tym samym kluczu).
Przy dużej liczbie podejrzanych duplikatów warto zdefiniować proste reguły, np. „jeśli różni się tylko pole komentarza, traktuj jako duplikat, w przeciwnym razie zgłoś do ręcznego przeglądu”. W praktyce często powstaje osobny krok pipeline’u „deduplikacja”, który można uruchamiać cyklicznie.
Korekta wartości błędnych i anomalii
Wartości ewidentnie błędne można wykrywać na dwa sposoby: regułami biznesowymi i prostymi metodami statystycznymi.
Przykłady reguł biznesowych:
ilość sztuk musi być większa lub równa 0 oraz mniejsza niż techniczny maks dla systemu,
data zamówienia nie może być późniejsza niż data faktury,
rata kredytu nie może być wyższa niż kwota kredytu.
Metody statystyczne pomagają tam, gdzie nie ma twardych reguł. Popularne podejście to analiza przedziału między kwartylami (IQR):
wyznacz Q1 (25% quantile) i Q3 (75% quantile),
policz IQR = Q3 – Q1,
za obserwacje odstające uznaj wartości poniżej Q1 – 1.5*IQR i powyżej Q3 + 1.5*IQR.
Co zrobić z anomaliami:
ewidentne błędy jednostek – np. cena wpisana w groszach zamiast w złotówkach; można przeskalować do prawidłowej jednostki,
literówki w tekstach – np. „Polksa”, „Poland”, „PL”; warto zbudować słownik mapowań, czasem użyć fuzzy matching,
prawdziwe ekstremalne wartości – bardzo wysoka transakcja, która faktycznie miała miejsce; nie należy ich automatycznie usuwać, tylko ewentualnie traktować ostrożnie przy skalowaniu.
Zawsze trzeba rozróżnić: czy anomalia jest błędem, czy rzadkim, ale realnym zdarzeniem. W pierwszym przypadku można poprawiać lub usuwać rekordy. W drugim – usuwać ich nie wolno, bo model traci informację o rzadkich, ale ważnych sytuacjach (np. duże zamówienia kluczowych klientów).
Dane niespójne między źródłami
W projektach ML często łączy się dane z kilku systemów: CRM, ERP, systemów transakcyjnych, logów aplikacji. Każde źródło ma własne formaty i słowniki, czasem niespójne względem siebie.
Typowe problemy przy łączeniu źródeł:
różne formaty dat i czasu,
Mapowanie słowników i jednostek
Łączenie źródeł to także różne słowniki pojęć i jednostki miary. Bez ich ujednolicenia model zobaczy ten sam fakt jako kilka różnych kategorii.
Typowe przykłady niespójności:
statusy: „closed”, „zamknięte”, „ZAM” oznaczające to samo,
kraje: „Poland”, „PL”, „POL”,
waluty: kwoty w EUR i PLN w jednej kolumnie bez jawnej informacji o walucie,
jednostki: kilogrami vs sztuki, metry vs centymetry.
Rozsądny porządek to:
zdefiniować docelowy słownik (np. słowniki referencyjne z systemu master data),
zbudować mapy konwersji dla każdego źródła,
zapisać reguły mapowania w kodzie lub tabelach konfiguracyjnych, a nie „w głowie” analityka.
Przy jednostkach trzeba zawsze trzymać informację o konwersji. Przykładowo – pole „dystans_m” zamiast ogólnego „dystans”, żeby każdy następny członek zespołu nie musiał zgadywać skali.
Konflikty wartości między systemami
Jeszcze trudniejsze są sytuacje, gdy ta sama encja ma różne wartości w różnych systemach, np. różne numery telefonów klienta albo inne kwoty faktury.
Przydatne są proste reguły priorytetyzacji:
jedno źródło traktowane jako nadrzędne (np. system finansowy wygrywa z CRM),
wybór najświeższej wartości na podstawie pola „last_update_at”,
reguły warunkowe: „jeśli kwota z ERP różni się od kwoty z systemu faktur o mniej niż X, przyjmij ERP, inaczej zgłoś konflikt”.
W modelach predykcyjnych nie zawsze trzeba domykać taki konflikt do jednej „prawdy”. Czasem lepiej zostawić dwie kolumny (np. kwota_z_ERP, kwota_z_CRM) i pozwolić modelowi nauczyć się, które źródło jest bardziej użyteczne dla danego celu.
Brakujące wartości: diagnoza, strategie i pułapki
Rodzaje braków i ich znaczenie
Brak danych to nie tylko „pusty” rekord. To także silny sygnał informacyjny. Kluczowe jest zrozumienie, dlaczego danych nie ma.
Podstawowe typy braków:
MCAR (Missing Completely At Random) – braki całkowicie losowe, niezależne od cech i etykiety; rzadko spotykane w realnych systemach,
MAR (Missing At Random) – braki zależą od innych obserwowanych cech (np. dochód brakujący częściej u młodszych klientów),
MNAR (Missing Not At Random) – braki zależą od samej brakującej wartości (np. brak podanego dochodu częściej przy niskich dochodach).
MCAR można uzupełniać dość swobodnie klasycznymi metodami. MAR i MNAR wymagają ostrożności, bo imputacja może wprowadzić systematyczny bias. Dla MNAR często lepiej zachować informację o braku jako osobny feature.
Diagnozowanie braków
Zanim cokolwiek zostanie uzupełnione, trzeba policzyć i zobaczyć wzorce braków.
Praktyczny zestaw kroków:
procent braków w każdej kolumnie i w każdym wierszu (np. ile kolumn jest pustych dla danego rekordu),
korelacje braków między kolumnami – czy brak jednej danej „idzie w parze” z innymi brakami,
porównanie rozkładów cech i targetu dla obserwacji z brakami vs bez braków (np. osobne histogramy, statystyki).
Czasem samo stwierdzenie „dochód brakujący częściej przy niespłaconych kredytach” pokazuje, że imputacja stałą wartością zaszkodzi bardziej niż pomoże.
Kiedy usuwać, a kiedy imputować
Najprostsza decyzja to wyrzucenie rekordów lub kolumn z brakami. Nie zawsze jednak jest to kosztowo akceptowalne.
Usuwanie wierszy ma sens, gdy:
braków jest bardzo mało (np. poniżej 1–2% zbioru),
brak dotyczy cechy kluczowej, której nie da się rzetelnie odtworzyć,
obsługujesz krytyczny przypadek użycia, w którym nie możesz ryzykować błędnej imputacji (np. model medyczny).
Usuwanie kolumn jest uzasadnione, jeśli:
braki dominują (np. powyżej 80–90%),
cecha jest słabo powiązana z problemem biznesowym lub targetem,
nie da się jej rzetelnie uzupełnić danymi z innych źródeł.
W wielu projektach lepszym kompromisem jest kombinacja: kilka bardzo ubogich kolumn usunąć, a resztę imputować w przemyślany sposób.
Proste strategie imputacji dla danych numerycznych
Dla danych liczbowych najczęstsze metody to imputacja stałą wartością, średnią, medianą lub w oparciu o modele.
stała wartość (np. 0, -1) – dobra, gdy 0 ma naturalne znaczenie (np. liczba zakupów) albo gdy to wyraźny „kod braku” i dodasz osobny wskaźnik „is_missing”,
średnia – sprawdza się przy zbliżonych do normalnych rozkładach, ale jest wrażliwa na outliery,
mediana – stabilniejsza przy skośnych rozkładach i outlierach, często bezpieczniejszy wybór niż średnia,
kwantyle warunkowe – mediana/średnia liczona osobno w segmentach (np. według kraju lub typu klienta).
Przykład: dla cechy „dochód” lepiej imputować medianę w obrębie grupy wiekowej i regionu niż jedną globalną medianę dla całego zbioru.
Imputacja dla danych kategorycznych
Przy kategoriach klasyczne numerki nie mają sensu. Tu używa się innych prostych technik.
najczęstsza kategoria (mode) – szybka, ale może przeważyć jedną klasę i zaburzyć rozkład,
specjalna kategoria „MISSING” – szczególnie przydatna, gdy brak sam w sobie niesie informację (np. brak deklaracji zawodu),
uzupełnienie z reguł biznesowych – np. jeśli kraj jest pusty, a waluta to SEK, przypisz „Sweden”, jeśli nie ma innych danych.
Kategoria „MISSING” jest często najlepszym wyborem startowym, zwłaszcza jeśli później kodujesz cechę one-hotem. Model może łatwo nauczyć się, że brak należy traktować osobno.
Imputacja oparta na modelach
Bardziej zaawansowane podejścia wykorzystują modele ML do przewidywania brakujących wartości na podstawie innych cech.
Przykłady technik:
regresja – dla cech numerycznych; np. model liniowy lub drzewo regresyjne przewidujące dochód na podstawie wieku, regionu, historii zakupów,
klasyfikacja – dla cech kategorycznych; np. przewidywanie segmentu klienta, gdy brakuje ręcznej klasyfikacji,
iteracyjna imputacja (MICE) – każda cecha z brakami jest naprzemiennie przewidywana w oparciu o pozostałe,
KNN imputation – zastępowanie braków średnią/medianą wartości z najbliższych sąsiadów w przestrzeni cech.
To podejścia kosztowniejsze obliczeniowo i podatne na przecieki informacji. Modele imputujące muszą być trenowane wyłącznie na train set, a następnie stosowane na validation i test. Inaczej ocena jakości głównego modelu będzie sztucznie zawyżona.
Flagi braków i interakcje
Niezależnie od sposobu imputacji, często przydatne są dodatkowe cechy binarne wskazujące, że dana wartość była oryginalnie pusta.
Prosty wzorzec implementacji:
dla każdej imputowanej kolumny tworzysz „colname_is_missing” (0/1),
imputujesz wartość (np. medianą),
obie kolumny przekazujesz do modelu.
Dla wielu problemów flagi braków mają większą moc predykcyjną niż sama imputowana wartość. Przykład z praktyki: w modelach ryzyka kredytowego sama informacja „klient nie podał dochodu” bywa silnym predyktorem defaultu.
Pułapki przy brakach danych
Przy pracy z brakami kilka błędów powtarza się najczęściej.
Imputacja przed podziałem na zbiory – jeśli liczysz medianę na całym zbiorze, wykorzystujesz informację z przyszłości (validation/test) do uzupełnienia train. Trzeba liczyć statystyki tylko na train.
Uśrednianie wszystkiego – imputacja średnią w każdej kolumnie wygląda „naukowo”, ale niszczy strukturę danych, zwłaszcza przy skośnych rozkładach.
Ignorowanie zależnych braków – jeśli kilka cech ma braki dokładnie w tych samych rekordach, to sygnał o problemie systemowym (np. część źródeł niedostępna dla konkretnej grupy klientów). Tego nie widać, gdy patrzysz na każdą kolumnę osobno.
Nadmiernie agresywne odrzucanie – usunięcie wszystkich wierszy z choć jednym brakiem przy 20–30 cechach potrafi zredukować zbiór o większość obserwacji.
Sensowna praktyka to przygotowanie kilku wariantów strategii braków (np. „prosta mediana + flagi” vs „MICE dla kluczowych cech”) i porównanie ich wpływu na wynik modelu, zamiast zakładać, że jedna technika będzie optymalna we wszystkich projektach.
Skalowanie cech numerycznych
Po co skalować dane
Skalowanie nie poprawi informacji w danych, ale ułatwia życie wielu algorytmom. Różne rzędy wielkości potrafią zdominować optymalizację lub miary odległości.
Jeśli w jednym zbiorze masz „wiek” w latach (0–100) i „dochód” w tysiącach (0–500), a używasz regresji liniowej, SVM lub KNN, to dochód będzie miał dużo większy wpływ tylko dlatego, że ma większą skalę.
Rodzaje skalowania
Najczęściej stosuje się kilka prostych przekształceń. Wybór zależy od modelu i rozkładu cechy.
standardyzacja (z-score) – odejmujesz średnią i dzielisz przez odchylenie standardowe; wynik ma średnią 0 i odchylenie 1 (w przybliżeniu),
min-max – przeskalowanie do [0, 1] lub innego przedziału; przydatne przy algorytmach opartych na odległościach,
robust scaling – użycie mediany i IQR zamiast średniej i odchylenia; lepiej działa w obecności outlierów,
log/transformacje potęgowe – dla bardzo skośnych rozkładów (np. przychód, liczba transakcji), często stosowane razem z klasycznym skalowaniem.
Standardyzacja i min-max wymagają obliczenia statystyk na train set, a potem zastosowania tych samych parametrów do validation i test.
Kiedy skalowanie ma znaczenie
Skalowanie jest krytyczne dla algorytmów:
opartych na gradientach i regularyzacji (regresja/logreg, sieci neuronowe),
opartych na odległościach (KNN, K-means, DBSCAN),
opartych na rozkładach zakładających zbliżoną wariancję (PCA, LDA).
Modele drzewiaste (Random Forest, Gradient Boosting, XGBoost, LightGBM, CatBoost) z reguły nie wymagają skalowania – dzielą przestrzeń po progach, nie po odległościach euklidesowych.
Skalowanie a przecieki informacji
Błąd bywa prosty: wyliczenie średniej i odchylenia na całym zbiorze, a potem random_state i cross-validation „wyglądają dobrze”.
Bezpieczny wzorzec:
dzielisz dane na train/validation/test,
dopasowujesz scaler tylko na train (fit),
stosujesz ten sam scaler do transformacji validation i test (transform).
W narzędziach typu scikit-learn najlepiej zamknąć to w Pipeline, żeby nie pomylić kolejności operacji.
Problemy przy skalowaniu
Kilka typowych potknięć przy skalowaniu:
skalowanie cech binarnych/one-hot bez potrzeby – dla wielu modeli nie ma z tego zysku, a interpretacja staje się trudniejsza,
mieszanie surowych i skalowanych cech o podobnym znaczeniu (np. „dochód” i „dochód_zlogowany_zeskalowany”) bez jasnego powodu,
używanie min-max przy obecności przyszłych outlierów – nowe obserwacje potrafią wyjść poza [0, 1],
log-transformacja wartości z zerami i ujemnymi – trzeba dodać stałą lub użyć innej transformacji (np. Yeo–Johnson).
Przy aplikacjach produkcyjnych warto na poziomie kodu jasno oddzielić blok obliczający statystyki skalowania od bloku, który je wykorzystuje – i utrwalać parametry w artefaktach modelu.
Źródło: Pexels | Autor: Pixabay
Kodowanie zmiennych kategorycznych
Dlaczego kodowanie ma znaczenie
Modele numeryczne nie „rozumieją” etykiet tekstowych. Samo zamienienie „A”, „B”, „C” na 1, 2, 3 sugeruje porządek, którego może nie być.
Inaczej koduje się kilka kategorii, inaczej dziesiątki tysięcy. Inaczej cechy stabilne (np. płeć), inaczej dynamiczne (np. ID kampanii marketingowej).
One-hot encoding
Najpopularniejsza technika dla kategorii z małą liczbą możliwych wartości.
dla każdej kategorii powstaje osobna kolumna 0/1,
czasem usuwa się jedną kolumnę, żeby uniknąć pełnej kolinearności (dummy trap) przy modelach liniowych,
dobrze działa z drzewami, regresją, sieciami o małej skali.
Problem pojawia się przy wysokiej krotności. Kolumna „miasto” z kilkoma tysiącami wartości może zamienić się w tysiące sparsowanych cech i znacząco zwiększyć rozmiar macierzy.
Label encoding i jego pułapki
Label encoding to przypisanie kolejnym kategoriom kolejnych liczb całkowitych: „A”→0, „B”→1, „C”→2.
Dla modeli drzewiastych jest to najczęściej akceptowalne, bo drzewa i tak sprawdzają progi typu „≤ 1.5”. Nie interpretują różnicy 0–1 inaczej niż 1–2.
Dla modeli liniowych i opartych na odległościach label encoding jest ryzykowny – wprowadza sztuczny porządek i odległości między kategoriami, których nie ma w rzeczywistości.
Target encoding i warianty
Dla cech o dużej krotności (np. ID produktu) one-hot szybko staje się niepraktyczny. Wtedy przydaje się kodowanie wykorzystujące target.
Podstawowy target encoding:
dla każdej kategorii liczysz statystykę targetu (np. średnią dla regresji, prawdopodobieństwo klasy 1 dla klasyfikacji),
podmieniasz kategorię na tę wartość liczbową,
stosujesz regularizację, by uniknąć przeuczenia (smoothing, dodanie globalnego średniego, noise).
Kluczowy element to unikanie przecieku: statystyk dla każdej próbki nie liczysz na niej samej, tylko w ramach K-fold lub na osobnym zbiorze.
W praktyce przeważnie używa się:
mean encoding – średnia targetu na kategorię,
leave-one-out encoding – średnia targetu poza bieżącą obserwacją,
expanding mean – średnia liczona po czasie lub po kolejnych rekordach, by symulować napływające dane.
Frequency i count encoding
Dla cech kategorycznych bez jednoznacznego porządku, ale z dużą liczbą wartości, często wystarczy informacja o tym, jak często kategoria występuje.
count encoding – kategoria → liczba wystąpień w zbiorze,
frequency encoding – kategoria → udział procentowy w zbiorze.
Takie kodowanie jest proste, nie korzysta z targetu, więc mniej grozi przeciekiem. Pomaga też w identyfikowaniu rzadkich wartości, które model może traktować inaczej niż często występujące.
Rzadkie kategorie i kategoria „OTHER”
Jeśli przy kodowaniu dostajesz dziesiątki bardzo rzadkich kategorii, rozbicie ich na one-hot zwykle nie ma sensu.
Praktyczny sposób postępowania:
policz częstości dla każdej kategorii na train,
wszystkie poniżej wybranego progu (np. <0.5% obserwacji) zmapuj do „OTHER”,
stosuj tę samą mapę do validation i test; nowe, nieznane wartości też trafiają do „OTHER”.
W jednym projekcie e-commerce zredukowało to liczbę kategorii w „id_źródła_ruchu” z kilkuset do kilkunastu, bez spadku jakości modelu.
Kodowanie sekwencji i wielokrotnych wartości
Często jedna kolumna zawiera listę kategorii: tagi produktu, role użytkownika, listę odwiedzonych sekcji.
Relatywnie proste opcje:
zamiana na kilka cech agregowanych – liczba tagów, obecność wybranych ważnych tagów,
hashing trick – mapowanie niskowymiarowe do z góry ustalonej liczby bucketów,
embeddingi uczone razem z modelem (częstsze w deep learningu niż w klasycznym ML).
Hashing jest wygodny przy strumieniach danych, gdzie nowe wartości pojawiają się codziennie i nie ma sensu aktualizować słownika kategorii.
Kodowanie a pipeline produkcyjny
Każde kodowanie wymaga przechowania „słownika” lub parametrów z fazy treningu. W przeciwnym razie produkcja wygeneruje inne zmienne niż te, na których trenował się model.
Bezpieczny wzorzec:
tworzysz obiekt enkodera (np. OneHotEncoder, TargetEncoder),
dopasowujesz go na train (fit),
utrwalasz stan (pickle, joblib, artefakt modelu),
w produkcji ładujesz dokładnie ten obiekt i stosujesz do nowych danych (transform).
Konieczne jest też przemyślenie polityki dla nieznanych kategorii („unknown” do „OTHER”, ignorowanie, osobna flaga). Brak takiej polityki często kończy się błędami w predykcjach online.
Przekształcenia i inżynieria cech wspierające skalowanie i kodowanie
Stabilne reprezentacje liczbowe
Część cech numerycznych reprezentuje w rzeczywistości kategorie lub stopnie intensywności (np. rating 1–5, poziom ryzyka 1–3). Takich pól zwykle nie skalujemy jak zwykłych zmiennych ciągłych.
Jeśli rating 1–5 jest porządkowy, lepsze może być:
pozostawienie go w oryginalnej postaci (dla modeli drzewiastych),
one-hot dla każdego poziomu, gdy zależy ci na nieliniowych efektach w modelach liniowych.
Logika biznesowa przed statystyką
Wiele „magicznych” przekształceń można zastąpić prostymi zasadami z domeny.
Przykład: zamiast skalować „liczbę produktów w koszyku” i osobno „łączną wartość koszyka”, można dodać cechę „średnia cena produktu” i potem dopiero skalować wszystkie trzy kolumny.
Inny przykład: z daty rejestracji i daty transakcji można wyliczyć staż klienta w dniach, który często jest lepszą, jednowymiarową cechą niż kilka kolumn z datami i godzinami.
Transformacje dla danych o rozkładach ciężkoogonowych
Przychody, liczba transakcji czy rozmiary plików często mają bardzo długie ogony. Klasyczne skalowanie bywa wtedy mało użyteczne.
Praktyczne transformacje:
log(1 + x) dla wartości nieujemnych – zmniejsza wpływ ekstremów i „prostuje” rozkład,
Box–Cox / Yeo–Johnson – bardziej elastyczne transformacje potęgowe, które można dopasować do danych,
winsoryzacja – ścięcie skrajnych wartości do wybranych percentyli (np. 1. i 99.), zanim zastosujesz skalowanie.
Transformacje tego typu najlepiej wbudować w ten sam pipeline co skalowanie, żeby uniknąć niespójności między treningiem a produkcją.
Łączenie cech i redukcja wymiarowości
Nadmiernie rozbudowane kodowanie (np. one-hot dla wielu kolumn) może prowadzić do setek lub tysięcy cech. Wtedy pojawia się problem wymiarowości.
Dwa kierunki działania:
agregacja cech – tworzenie prostszych zmiennych z kilku pól (np. „liczba aktywnych produktów” zamiast 20 binarnych cech),
redukcja wymiarowości (PCA, autoenkodery) – użyteczna przy cechach gęstych o powiązanej strukturze, rzadziej przy one-hot.
Przy klasycznych projektach tabularnych prostsza, ręczna agregacja daje często lepsze efekty niż agresywne PCA na całym zbiorze.
Spójność między treningiem offline a predykcją online
Cały proces przygotowania danych (czyszczenie, brakujące wartości, skalowanie, kodowanie) musi być odtwarzalny 1:1 w produkcji.
Praktyczne elementy takiej spójności:
jedna, wersjonowana definicja pipeline’u danych, używana zarówno w treningu, jak i w serwisie predykcyjnym,
testy porównujące wyniki transformacji tych samych surowych danych w środowisku offline i online,
monitoring rozkładów cech po transformacjach (drifty, nowe kategorie, wzrost odsetka braków).
Bez takiej dyscypliny modele z czasem „starzeją się” nie tylko przez zmianę świata, ale też przez ciche rozjazdy w logice przetwarzania danych.
Co warto zapamiętać
Jakość przygotowania danych ma większy wpływ na wyniki modeli niż wybór konkretnego algorytmu – brudne, niespójne dane zniszczą nawet najlepszy model.
Preprocessing trzeba traktować jako część modelu: błędne czyszczenie, imputacja czy kodowanie prowadzą do overfittingu, niestabilnych predykcji, data leakage i rozjazdu między treningiem a produkcją.
Kluczowe jest poprawne rozpoznanie typu zmiennej (ciągła, dyskretna, kategoryczna, tekstowa, czasowa), bo od tego zależy dobór technik skalowania, imputacji i kodowania.
Identyfikatory i kody techniczne nie powinny być bezrefleksyjnie używane jako cechy – model może nauczyć się „na pamięć” konkretnych ID, co na walidacji wygląda dobrze, a na produkcji daje losowe wyniki.
Skala i rozkład cech numerycznych (symetryczne, skośne, z outlierami) determinują wybór metody skalowania i imputacji; standardyzacja i średnia na danych z ciężkim ogonem zwykle pogarszają sytuację.
Dane tekstowe i czasowe wymagają osobnych pipeline’ów (tokenizacja, wektoryzacja, cechy kalendarzowe, lags), bo proste potraktowanie ich jak zwykłych liczb prowadzi do utraty informacji.
Krótka, świadoma inspekcja danych na starcie (rozmiar zbioru, typy kolumn, udział braków) pozwala wcześnie wychwycić problemy, które w późniejszym etapie kosztują najwięcej czasu i błędów.
