Tabelka, która wygląda porządnie w Excelu, rzadko kiedy jest od razu gotowa do uczenia maszynowego. Dla człowieka drobne niespójności są pomijalne – oko dopowie sobie znaczenie. Model nie „domyśla się” kontekstu. Każdy literówkowy wariant kategorii, nietypowy format daty czy dodatkowa spacja tworzą nową, odrębną wartość. Z perspektywy algorytmu „PL”, „Polska” i „POLSKA ” to trzy różne kraje.
Różnica między „ładną tabelką” a zbiorem gotowym do modelowania polega głównie na jednoznaczności, spójności typów i przetwarzalności. Wszystko, co trafi do modelu, musi dać się zapisać w postaci liczb – bez wyjątków. Nawet jeśli biblioteka wykona część pracy za użytkownika (np. automatyczne kodowanie kategorii), to wciąż użytkownik odpowiada za to, czy te liczby coś sensownego reprezentują.
Jakość danych ważniejsza niż wybór algorytmu
W praktyce projekty uczenia maszynowego częściej zawodzą na etapie przygotowania danych niż na etapie wyboru algorytmu. Zmiana modelu z regresji liniowej na gradient boosting zwykle daje mniejszy efekt niż konsekwentne:
wyczyszczenie spójności typów,
sensowne potraktowanie braków danych,
przemyślane kodowanie zmiennych kategorycznych,
usunięcie lub naprawa oczywistych błędów (np. ujemny czas trwania).
Model jest w stanie „przeżyć” umiarkowany poziom szumu, ale nie wybacza systematycznych błędów. Błędne etykiety (target), przesunięte daty, przecieki informacji czy pomieszane jednostki potrafią całkowicie wypaczyć wnioski – i to w sposób trudny do wykrycia na samych metrykach typu accuracy czy RMSE.
Co zwykle jest „surowe” w realnych danych
Surowe zbiory z systemów produkcyjnych mają pewne stałe cechy. Typowe problemy:
duplikaty – ten sam klient, ta sama transakcja, powielone w różnych systemach lub wersjach;
brak spójności typów – liczby zapisane jako tekst, daty jako stringi w kilku formatach, logiczne flagi jako „tak/nie”, „1/0”, „Y/N”;
brak standardów nazewniczych – różne zapisy tych samych kategorii, mieszanie języków, skróty;
wartości techniczne – placeholdery typu „-999”, „brak”, „N/A”, które nie są jawnie oznaczone jako brak danych.
Bez jawnego przepracowania tych problemów model będzie przetwarzał chaos, a nie informacje. W najlepszym razie straci część mocy predykcyjnej, w najgorszym – zacznie działać w sposób nieprzewidywalny po wdrożeniu.
Decyzje preprocessingowe, których nie da się cofnąć
Przygotowanie danych do uczenia maszynowego składa się z szeregu decyzji, które później bywają nieodwracalne. Kilka przykładów:
Usuwanie obserwacji – gdy rząd zostanie wyrzucony, nie ma już jak go odzyskać; jeśli usunięto określony typ rzadkich przypadków, model może ich później w ogóle „nie znać”.
Agregacja w czasie – gdy dane dzienne zostaną zagregowane do tygodniowych, pewne wzorce sezonowe (np. weekendowe piki) znikają definitywnie.
Łączenie kategorii – scalanie drobnych kategorii w „inne” bywa wygodne, ale zamyka drogę do późniejszej analizy ich specyfiki.
Obcięcie wartości odstających – ucięcie skrajnych wartości na sztywno (np. percentyl 1 i 99) może wyeliminować prawdziwe, ale rzadkie zjawiska.
Dlatego preprocessing nie powinien polegać na mechanicznej aplikacji kilku „sprawdzonych trików”. Każdy krok warto móc wyjaśnić: co zmieniono, dlaczego i jaki to ma wpływ na interpretację modelu.
Krótki przykład konsekwencji nieoczyszczonych danych
Prosty scenariusz: zespół sprzedaży chce modelu przewidującego szansę wygrania oferty. Do modelu trafiają dane historyczne z CRM. Nie wykonano sensownego czyszczenia:
statusy „wygrana”/„przegrana” mieszają się z „w toku” i „do weryfikacji”, ale wszystkie są traktowane jako „nieprzegrana”,
daty są w różnych formatach, część niepoprawnie rozpoznana jako tekst – w efekcie kolejność zdarzeń jest pomylona,
brak informacji o liczbie spotkań jest traktowany jak „0 spotkań”, choć w praktyce oznacza nieuzupełnione pola.
Model, który się na tym szkoli, będzie „uczył się” wzorca, którego w rzeczywistości nie ma. W predykcjach pokaże wysoką pewność tam, gdzie faktycznie nie ma danych, a nie wysokiego prawdopodobieństwa wygranej. Menedżerowie zaczną ufać tym liczbom, co przełoży się na błędne priorytety w pracy handlowców. Problem nie leży w algorytmie, tylko w źle przygotowanych danych.
Zrozumienie problemu i danych zanim ruszy kod
Cel biznesowy a typ modelu: regresja, klasyfikacja, rekomendacje
Uczenie maszynowe nie działa w próżni – model ma odpowiadać na konkretne pytanie. Zanim padnie pierwsze read_csv, trzeba ustalić:
Co jest celem: przewidywanie liczby (regresja), klasy (klasyfikacja), kolejności (ranking, rekomendacje)?
Co jest jednostką obserwacji: klient, transakcja, sesja, produkt, dzień?
Jaki horyzont czasowy ma model: prognoza na jutro, miesiąc, rok?
Bez tego trudno ocenić, czy w danych w ogóle istnieją informacje pozwalające odpowiedzieć na pytanie. Próba zbudowania modelu churn bez wiarygodnych etykiet, kiedy klient „odszedł”, skończy się modelowaniem błędu w systemie, a nie realnego zachowania.
Co musi się znaleźć w danych, żeby model miał sens
Minimalny zestaw informacji, który powinien pojawić się w danych:
Target (y) – jasno zdefiniowany i poprawnie zmierzony wynik, który model ma przewidywać;
Cecha czasowa – w zadaniach predykcyjnych konieczny jest znacznik czasu, inaczej trudno uniknąć przecieku;
Cecha identyfikująca jednostkę – np. ID klienta, transakcji, urządzenia (często nie trafia do modelu, ale jest kluczowa do łączenia danych);
Cechy opisujące kontekst – np. produkt, kanał, region, historia aktywności.
Jeżeli którejś z kluczowych informacji brakuje, to problem może być technicznie nierozwiązywalny. Żaden stopień „magii” w algorytmach nie zastąpi danych, których po prostu nie zebrano.
Mapowanie pól: wejścia, target i kolumny zbędne
Etap mapowania danych to rutynowa, ale krytyczna praca. Każdej kolumnie trzeba przypisać jedną z kategorii:
Target (y) – jedna (lub więcej) kolumna będąca celem predykcji;
Cecha wejściowa (X) – kandydat do wykorzystania przez model;
Identyfikator / klucz – kolumny służące do łączenia tabel, raczej nie wchodzą do modelu;
Metadane / techniczne – znaczniki importu, nazwy plików, ścieżki, które zwykle należy pominąć;
Cechy potencjalnie zabronione – płeć, rasa, kod pocztowy itp., które bywają problematyczne regulacyjnie lub etycznie.
Zaniedbanie tej mapy skutkuje np. przypadkowym użyciem identyfikatora zamówienia jako cechy. Model błyskawicznie uczy się „rozpoznawać” konkretne id zamiast generalizować wzorce, a wyniki w cross-validacji są absurdalnie dobre i zupełnie bezużyteczne w produkcji.
Czemu sam CSV nie wystarczy: kontekst domenowy
Tabelka danych rzadko kiedy mówi całą prawdę. Przykłady pułapek bez znajomości domeny:
kolumna „status klienta” może oznaczać różne rzeczy w różnych systemach (status rozliczeniowy vs status marketingowy),
brak daty w polu „data zamknięcia zgłoszenia” może oznaczać „w toku”, a nie brak danych,
wartość „0” w kolumnie „rabat” może oznaczać zarówno „brak rabatu”, jak i „nie policzono jeszcze”.
Bez rozmowy z osobami odpowiedzialnymi za system źródłowy (analityk biznesowy, właściciel procesu, administrator systemu) łatwo źle zinterpretować pola i oprzeć model na fałszywych założeniach. Zwłaszcza przy brakach danych interpretacja „co znaczy brak” bywa wyłącznie w głowie ludzi, a nie w dokumentacji.
Wczesne odkrywanie nierealnych oczekiwań
Na etapie rozumienia danych często wychodzą na jaw oczekiwania, których po prostu nie da się spełnić:
chęć przewidywania zdarzeń, których nie da się zmierzyć lub dla których nie ma etykiet,
oczekiwanie dokładności 99% tam, gdzie sam proces pomiaru ma błąd większy niż kilka procent,
chęć predykcji „z wyprzedzeniem” bez historycznej osi czasu (tylko przekrój danych w jednym momencie).
Lepiej zderzyć takie oczekiwania z faktami zanim zacznie się czyszczenie danych. Bez tego można spędzić tygodnie na pedantycznym przygotowywaniu zbioru, który i tak nie pozwoli zbudować sensownego modelu.
Źródło: Pexels | Autor: Google DeepMind
Pierwsze spojrzenie na dane: eksploracja i sanity-check
Podstawowe statystyki opisowe i liczność wartości
Pierwszy kontakt z danymi powinien obejmować proste, ale systematyczne sprawdzenie:
rozmiaru zbioru (liczba wierszy, kolumn),
statystyk liczbowych: min, max, średnia, mediana, odchylenie standardowe dla cech numerycznych,
liczby unikalnych wartości dla cech kategorycznych,
liczby braków w każdej kolumnie.
Już na tym poziomie często widać kluczowe problemy. Przykładowo: minimalny wiek klienta wynosi -5, maksymalny 500; liczba unikalnych wartości w kolumnie „płeć” jest większa niż 5; w kolumnie „data_urodzenia” braków jest 90%, więc może nie będzie przydatna. To są sygnały, że bez dodatkowych decyzji preprocessingowych nie ma sensu przechodzić do bardziej wyrafinowanych analiz.
Proste wizualizacje, które szybko ujawniają błędy
Nawet kilka podstawowych wykresów potrafi ujawnić błędy, których nie widać w tabelkach:
histogramy dla cech liczbowych – pozwalają wykryć „ogon” wartości odstających, niespodziewane drugie piki, rozkłady mocno skośne,
wykresy pudełkowe (boxploty) – ujawniają wartości odstające i rozrzut w różnych grupach,
scatterploty – pokazują relacje między dwiema zmiennymi, w tym nieliniowości i klastry,
wizualizacje braków danych – macierze braków (np. heatmap) pozwalają zobaczyć wspólne wzorce braków w wielu kolumnach.
Na tym etapie chodzi bardziej o sanity-check niż o dogłębną eksplorację. Celem jest złapanie sygnałów typu: „wiek” ma nienaturalne zakresy; „przychód” ma kilka ekstremalnych wartości, prawdopodobnie błędy w jednostkach; „czas trwania” jest zawsze większy od „czasu do rozpoczęcia” – a powinien być odwrotnie.
Sprawdzanie typów danych i skutków automatycznych konwersji
Wiele narzędzi (pandas, Excel, narzędzia BI) próbuje odgadnąć typ danych. Niestety, robią to heurystycznie. Typowe problemy:
daty odczytane jako tekst, bo część wierszy ma niepoprawny format,
kolumny numeryczne z domieszką „brak” czy „n/a” odczytane jako tekst,
identyfikatory numeryczne odczytane jako integer, choć powinny pozostać tekstem (np. kody do wiodącymi zerami),
wartości logiczne („true/false”, „yes/no”) potraktowane jako tekst zamiast bool.
Każdą kolumnę warto zweryfikować: czy typ, który widzi narzędzie, odpowiada typowi, jakiego oczekuje model? Jeśli nie, trzeba zdefiniować jawne reguły konwersji, z obsługą błędów i wyjątków, a nie polegać na domyślnych ustawieniach.
Wykrywanie oczywistych anomalii i literówek
Prosty przegląd unikalnych wartości w kolumnach kategorycznych potrafi pokazać:
Nietypowe wartości, jednostki i ukryte kody
Przy pierwszym przejrzeniu danych numerycznych i kategorycznych pojawia się jeszcze jeden wątek: wartości, które formalnie „mieszczą się” w typie kolumny, ale semantycznie są błędne. Kilka wzorców powtarza się w większości projektów:
wartości specjalne zakodowane liczbą – np. -1 oznacza „brak danych”, 9999 oznacza „nie dotyczy”,
mieszanie jednostek – część wierszy w metrach, część w centymetrach, czasem bez jawnej flagi,
ukryte kody biznesowe – np. „status=3” ma w systemie zupełnie inne znaczenie niż „status=2”, ale dokumentacja milczy,
agregaty wymieszane z danymi atomowymi – np. w tej samej tabeli są pojedyncze transakcje i ręcznie dopisane „sumy miesięczne”.
Bez rozpoznania takich wzorców model będzie traktował kody techniczne jak zwykłe liczby, a wartości błędne jak prawidłowe obserwacje. Skutkiem jest systematyczne wypaczenie rozkładów i korelacji. Identyfikacja i opis takich wyjątków powinna poprzedzać jakiekolwiek automatyczne procesy czyszczące.
Po wstępnej eksploracji dobrze jest zamknąć temat typów danych. Chodzi o świadome zdefiniowanie, jak każda kolumna ma być interpretowana:
daty i czasy – jawne parsowanie z podaniem formatu, strefy czasowej i sposobu obsługi błędnych wartości,
liczby – konwersja tekstu na liczby z kontrolą separatora dziesiętnego i tysięcy,
kategorie – określenie skończonego zbioru dozwolonych wartości i wyłapanie wszystkiego spoza tego zbioru,
boole – ujednolicenie reprezentacji (np. „Y/N”, „yes/no”, „1/0”) i zdefiniowanie, co robić z wartościami pośrednimi typu „maybe”.
Kuszące bywa „naprawianie” typów jednym wywołaniem biblioteki, ale to zwykle prowadzi do cichych błędów – np. nieparsujące się daty stają się NaT, a w projekcie nikt nie zauważa, że połowa rekordów „nie ma czasu”. Lepsze jest rzutowanie kolumna po kolumnie, z logowaniem liczby błędów.
Duplikaty: kiedy usuwać, a kiedy są sygnałem problemu
Znajdowanie duplikatów to nie tylko uruchomienie drop_duplicates. Najpierw trzeba odpowiedzieć na pytanie: co znaczy „duplikat” w danym kontekście?
Pełny duplikat wiersza może wskazywać na problem w procesie ekstrakcji lub ładowania.
Duplikat po kluczu (np. tym samym ID transakcji) przy różnych innych polach może oznaczać korekty, wersjonowanie lub błąd danych.
Duplikat po kombinacji pól, która powinna być unikalna (np. klient + data + produkt), może wskazywać na zdublowaną rejestrację zdarzenia.
Zanim cokolwiek zostanie usunięte, dobrze jest:
zdefiniować poziom, na którym unikalność ma obowiązywać (ID, kombinacja kolumn?),
sprawdzić, jak duża jest skala problemu,
ustalić z właścicielem danych, czy duplikaty są błędem, czy częścią logiki biznesowej (np. kilka wpisów na tę samą fakturę).
Dopiero potem można zadecydować: usuwać najnowsze, najstarsze, agregować, a może zachować wszystkie, ale przeliczyć cechę, która odzwierciedla liczbę powtórzeń.
Niespójne formaty i pisownia w kolumnach tekstowych
Kolumny tekstowe i kategoryczne są podatne na drobne niespójności, które potrafią „rozdzielić” jedną kategorię na kilka:
różne wielkości liter („PL”, „pl”, „Pl”),
dodatkowe spacje, znaki specjalne, znaki niewidoczne,
różne skróty tej samej wartości („Mazowieckie”, „Maz.”, „MZ”),
literówki („Warszwa”, „Warzsawa”).
Zwykle potrzebne jest ujednolicenie:
trybu (np. wszystko na wielkie litery),
usunięcie zbędnych spacji i znaków kontrolnych,
zmapowanie równoważnych form do jednej wartości referencyjnej.
Przy większych zbiorach pomocne bywa zbudowanie osobnej tabeli mapowań (słownika), która łączy surowe wartości z wartością docelową. Zyskuje się przy tym możliwość audytu: widać, co zostało z czym połączone i w razie sporu można wrócić do oryginałów.
Konflikty między kolumnami i niespójności logiczne
Oprócz pojedynczych błędów w komórkach istotne są niespójności między kolumnami. Przykładowe schematy:
data zakończenia jest wcześniejsza niż data rozpoczęcia,
flaga „zamknięte=1” przy pustej dacie zamknięcia,
liczba pozycji na zamówieniu mniejsza niż 0 lub mniejsza niż liczba pozycji w szczegółach.
Takie konflikty lepiej traktować jako osobną kategorię problemów. Zamiast automatycznie naprawiać, można:
oznaczyć rekordy jako „podejrzane” dodatkową cechą,
przy trenowaniu modeli wrażliwych na jakość czasu lub sekwencji wykluczyć je,
przekazać listę do korekty właścicielom systemów źródłowych.
Część niespójności daje się rozwiązać heurystyką (np. zamiana dat, gdy ewidentnie przestawiono dzień z miesiącem), ale w długim horyzoncie bez korekty procesu źródłowego problem będzie powracał.
Źródło: Pexels | Autor: Google DeepMind
Braki danych: diagnoza zamiast automatycznego fillna
Rodzaje braków: MCAR, MAR, MNAR w praktyce
Teoria rozróżnia trzy główne mechanizmy powstawania braków:
MCAR (Missing Completely At Random) – brak pojawia się zupełnie losowo, niezależnie od innych cech i samej nieobserwowanej wartości,
MAR (Missing At Random) – prawdopodobieństwo braku zależy od innych obserwowanych cech, ale nie od samej nieobserwowanej wartości,
MNAR (Missing Not At Random) – brak koreluje z samą nieobserwowaną wartością, czyli „to, że jest pusto, już coś mówi”.
W praktyce rzadko da się jednoznacznie sklasyfikować każdy brak, ale próba zrozumienia mechanizmu pozwala uniknąć niebezpiecznych uproszczeń. Jeśli pole „dochód” jest częściej puste wśród klientów o niestabilnej historii zatrudnienia, to nie jest to „losowy brak”, tylko nośnik informacji.
Brak techniczny kontra brak znaczący
Nie każdy brak ma tę samą wagę. Dobrze odróżnić:
braki techniczne – wynik błędów integracji, migracji, parsowania,
braki biznesowe – wynik procesu, decyzji użytkownika lub logiki systemu.
Przykłady:
pusta kolumna dla całego zakresu dat po wdrożeniu nowej wersji systemu – to najpewniej problem techniczny,
brak daty zakończenia zgłoszenia, gdy status to „w toku” – to część definicji procesu, a nie błąd.
Przy brakach technicznych celem jest maksymalne ograniczenie ich wpływu (czasem nawet wycięcie danego okresu), przy brakach biznesowych częściej szuka się sposobu na wykorzystanie samego faktu braku jako cechy informacyjnej.
Analiza wzorców braków i współwystępowania
Zanim zacznie się wypełnianie, dobrze jest spojrzeć na:
odsetek braków w każdej kolumnie – czy to 1%, 20%, czy 90%,
wzorce braków wspólnych – np. brak równocześnie w polach A i B, ale nigdy w C,
zależność braków od targetu – inne częstotliwości braków w klasie pozytywnej i negatywnej.
Taka analiza pozwala wychwycić m.in.:
cechy, które są niemal całkowicie puste i prawdopodobnie nie wnoszą informacji (lub wnoszą ją wyłącznie swoją „pustością”),
grupy zmiennych, które są zawsze puste razem – np. cały blok formularza wypełniany tylko dla wybranych typów klientów,
przeciek informacji – jeśli cecha częściej jest pusta po wystąpieniu zdarzenia docelowego, mogła zostać uzupełniona później niż target.
W praktyce do takiej analizy przydają się macierze braków, korelacje „brak/nieważny” z innymi cechami oraz proste tabele przestawne: co się dzieje z brakami w zależności od grupy, czasu, segmentu.
Braki a definicja zbiorów trening/valid/test
Braki danych często nie są rozłożone równomiernie w czasie. Przykładowo, w starszych danych mogło nie być obowiązku wypełniania części pól, a w nowszych – już tak. Jeśli zbiór treningowy i walidacyjny zostaną losowo przetasowane z całej historii, model nauczy się wzorców, które nie będą odpowiadały sytuacji produkcyjnej.
Rozwiązania obejmują m.in.:
podział danych w oparciu o czas (walidacja na nowszym okresie),
sprawdzenie, czy odsetek braków jest podobny w każdym ze zbiorów,
w razie silnych różnic – osobne modele dla „nowego” i „starego” świata lub dodatkowe cechy odzwierciedlające wersję procesu.
Ignorowanie tego aspektu łatwo prowadzi do sytuacji, w której wynik walidacji jest optymistyczny, a w produkcji model trafia na inny rozkład braków i zaczyna się zachowywać nieprzewidywalnie.
Strategie uzupełniania braków: od prostych do zaawansowanych
Kiedy wolno po prostu wyrzucić wiersze lub kolumny
Usuwanie braków jest najszybszą metodą, ale bywa też najbardziej kosztowne informacyjnie. Zwykle sens ma w dwóch sytuacjach:
bardzo mały odsetek braków w wierszach – np. kilka promili rekordów z fatalnie uzupełnionymi danymi,
bardzo mały udział informacji w kolumnie – cecha, która jest pusta w prawie wszystkich wierszach.
Poziomy progowe (np. „wyrzucamy wszystko co ma >50% braków”) nie powinny być ustalane w ciemno. Im bardziej cecha jest kluczowa z punktu widzenia domeny, tym więcej wysiłku opłaca się włożyć w jej ratowanie, nawet jeśli formalnie ma dużo pustych wartości.
Proste imputacje: średnia, mediana, dominanta, stała
Najpopularniejsze techniki to:
średnia / mediana dla zmiennych numerycznych,
dominanta (najczęstsza wartość) dla zmiennych kategorycznych,
stała wartość (np. 0, -1, „UNKNOWN”).
Zalety są oczywiste: szybkość, prostota, dobry punkt startowy dla modeli drzewiastych. Wady również:
zaniżanie wariancji – im więcej braków uzupełnionych tą samą wartością, tym bardziej spłaszczony rozkład,
wprowadzanie sztucznych „klastrów” – wiele obserwacji skupia się w jednym punkcie,
ryzyko przesunięcia zależności – szczególnie gdy rozkład jest skośny, a używa się średniej zamiast mediany.
Tego typu imputacje są akceptowalne, gdy udział braków jest niewielki, a cecha nie jest kluczowa diagnostycznie. Przy dużej skali braków lub ważnych zmiennych lepiej sięgnąć po coś bardziej przemyślanego.
Imputacja warunkowa: grupy i segmenty
Zamiast uzupełniać braki jedną wartością globalnie, można to robić w ramach segmentów danych. Przykładowo:
dochód uzupełniany medianą w ramach kraju lub regionu,
czas dostawy imputowany średnią w ramach kombinacji „typ produktu + kraj wysyłki”,
wiek uzupełniany medianą w danym przedziale „stanowisko + branża”.
Taki zabieg lepiej zachowuje struktury zależności i minimalizuje przesunięcia rozkładów. Trzeba jednak pilnować, aby grupy były wystarczająco liczne – imputowanie medianą w grupach po kilka obserwacji zwykle prowadzi do niestabilnych i trudnych do powtórzenia wyników.
Użycie modeli do imputacji: regresja, drzewa, k-NN
Gdy braki dotyczą ważnych kolumn i jest ich sporo, często stosuje się metody oparte na modelach. Kilka typowych podejść:
Modele jednowymiarowe i wielowymiarowe
Modelową imputację można zorganizować na dwa główne sposoby:
jednowymiarowo – każdą kolumnę z brakami imputuje osobny model, korzystając z innych kolumn jako predyktorów,
wielowymiarowo – brakujące wartości w wielu kolumnach są szacowane iteracyjnie, przy czym modele dla poszczególnych cech „współpracują” ze sobą (np. MICE – Multiple Imputation by Chained Equations).
Prosty workflow jednowymiarowy może wyglądać tak: najpierw usuwa się wiersze, gdzie w imputowanej kolumnie nie ma braku, trenuje model regresyjny/klasyfikacyjny przewidujący tę kolumnę na podstawie innych, a następnie przewiduje wartości dla wierszy z brakami. Wersja wielowymiarowa zwykle:
startuje od prostego wypełnienia (np. medianą),
dla każdej kolumny z brakami trenuje model, traktując pozostałe kolumny jako wejście,
podmienia imputowane wartości nowymi predykcjami,
powtarza cykl kilka razy, aż zmiany się ustabilizują.
Takie podejście pozwala wykorzystać współzależności między zmiennymi, ale kosztuje czas i wymaga porządnego rejestrowania kroków, żeby dało się je odtworzyć później w produkcji.
Jakie modele nadają się do imputacji
Z perspektywy praktyka liczy się nie tyle „najlepszy” model, co taki, który:
jest stabilny przy dużej liczbie cech i współliniowości,
dobrze radzi sobie z nieliniowościami,
nie jest koszmarem do wdrożenia i utrzymania.
Często stosowane są:
regresje liniowe / logistyczne – gdy relacje są względnie proste, a zależy na interpretowalności,
drzewa decyzyjne i lasy losowe – rozsądny kompromis między elastycznością a odpornością na dziwne rozkłady,
k-NN – dla mniejszych zbiorów, gdzie metryka „podobieństwa” ma sens biznesowy.
Modele bardzo „mocne” (gradient boosting, głębokie sieci) potrafią świetnie imputować, ale łatwo tu o przesadę: dokładnie ten sam model (lub rodzina modeli) ma się później uczyć zadania docelowego. Ryzyko jest takie, że założymy zbyt idealne dane wejściowe, których w realnym świecie nie będzie.
Ryzyko przecieku informacji przy imputacji modelowej
Najczęstszy grzech przy imputacji modelowej to mieszanie perspektywy „wiemy wszystko o całym zbiorze” z perspektywą „w produkcji widzimy tylko przeszłość”. Parę wrażliwych punktów:
trenowanie modeli imputacyjnych na całym zbiorze, w tym na danych z walidacji i testu,
używanie cech z przyszłości (np. statystyk z całego okresu) do imputacji cech historycznych,
„dosztukowywanie” targetu lub cech z nim bezpośrednio powiązanych modelami, które miałyby w praktyce dostęp do informacji post-factum.
Bezpieczniejsza procedura:
dzieli dane na zbiory trening/valid/test według tego samego schematu, który planuje się odwzorować w produkcji (np. w oparciu o czas),
wszystkie transformatory imputujące trenuje wyłącznie na treningu,
zapisuje parametry imputacji (np. współczynniki regresji, strukturę drzew),
stosuje te same obiekty imputujące do walidacji, testu i następnie do przepływu produkcyjnego.
Jeśli w jakimkolwiek kroku imputacja ma „wzrok” sięgający poza horyzont czasowy dostępny w chwili predykcji, wyniki walidacji staną się zbyt optymistyczne.
Wielokrotna imputacja a niepewność
Klasyczne podejście statystyczne sugeruje wielokrotną imputację: zamiast jednego uzupełnienia braków tworzy się kilka wersji zbioru, trenuje modele na każdym z nich, a wyniki i parametry uśrednia. W efektach:
oddziela się niepewność związaną z doborem modelu od niepewności wynikającej z braków danych,
dostaje się bardziej realistyczne przedziały ufności i stabilniejsze wnioski przy analizach przyczynowych.
W maszynowym uczeniu produkcyjnym ma to swoje ograniczenia – trudno utrzymywać kilka pełnych pipeline’ów. Natomiast sam koncept przydaje się choćby po to, żeby oszacować, jak bardzo wyniki modelu zależą od przyjętej strategii imputacji. Jeśli performance silnie fluktuuje między różnymi imputacjami, problem braków sygnalizuje, że dane są zbyt kruche, aby bezrefleksyjnie je „naprawiać”.
Oznaczanie imputacji jako osobna cecha
Przy każdej zaawansowanej strategii opłaca się dorzucić prosty element: flagi informujące o imputacji. Dla każdej ważniejszej kolumny można stworzyć:
cechę binarną: 1, jeśli wartość została imputowana, 0, jeśli pochodzi ze źródła,
lub – w przypadku kilku typów braków – kod kategoryczny wskazujący rodzaj braku/źródło imputacji.
Modele drzewiaste potrafią takie flagi dobrze wykorzystać. Często okazuje się, że sama informacja „tu mieliśmy lukę w danych” niesie większy sygnał niż dokładna imputowana wartość.
Imputacja specyficzna dla domeny
Gotowe algorytmy rzadko uwzględniają logikę biznesową. Prosty przykład: w danych o subskrypcjach brak daty rezygnacji przy aktywnych klientach. Zamiast próbować imputować „prawdopodobną datę końca” można:
przyjąć, że brak = „do dziś aktywny”,
operować na cechach typu „liczba dni od rozpoczęcia do dziś” i „czy klient aktywny”,
zrezygnować z imputowania daty końca w ogóle.
Podobnie przy zmiennych finansowych brak raty kredytu może oznaczać „jeszcze nie spłacał” zamiast „nie wiemy, ile zapłacił”. Zamiast imputować kwotę raty, lepszą cechą bywa liczba miesięcy bez płatności lub wskaźnik „klient w okresie karencji”.
Kodowanie zmiennych kategorycznych: dobór metody do problemu
Dlaczego kodowanie ma znaczenie
Modele numeryczne nie rozumieją etykiet typu „PL”, „DE”, „USA”. Sposób, w jaki zostaną zamienione na liczby, wpływa na:
jak model interpretuje odległość i podobieństwo między kategoriami,
czy nie powstaną sztuczne porządki (np. 1 < 2 < 3),
skalę i rzadkość cech wejściowych,
podatność na przeuczenie przy wielu rzadkich kategoriach.
Przy drzewach i boostingach niektóre problemy są łagodniejsze, ale przy regresjach i sieciach kodowanie to jeden z kluczowych elementów przygotowania danych.
One-hot encoding i jego ograniczenia
Najprostszy wariant kodowania to one-hot (zmienna binarna na kategorię). Zalety:
brak narzuconego porządku między kategoriami,
łatwa interpretacja i debugowanie,
dobra współpraca z modelami liniowymi i wieloma algorytmami opartymi na odległościach (po odpowiedniej normalizacji).
Problemy pojawiają się, gdy:
liczba kategorii jest duża (kod pocztowy, ID produktu, domena e-mail) – macierz cech staje się bardzo rzadka i „szeroka”,
część kategorii jest ekstremalnie rzadka – model dopasowuje się do szumu (overfitting),
pojawiają się nowe kategorie w produkcji – brak im dedykowanych kolumn.
Rozsądna praktyka to stosowanie one-hot dla cech o niewielkiej liczbie wartości (do kilkudziesięciu) i łączenie rzadkich kategorii w grupę „INNE” / „RARE_xx”, która ma sens biznesowy (np. „kraj poza TOP-20 rynków”).
Leave-one-out i target encoding
Przy kategoriach liczonych w setkach lub tysiącach częstym wyborem jest target encoding – zamiana kategorii na statystykę związaną z targetem, np.:
średnią wartości zależnej (dla regresji),
prawdopodobieństwo klasy pozytywnej (dla klasyfikacji).
Odmianą ograniczającą przeuczenie jest leave-one-out encoding, gdzie statystyka liczona jest z pominięciem aktualnej obserwacji. W obu przypadkach trzeba uważać na kilka zjawisk:
przeciek informacji – jeśli target encoding liczony jest na całym zbiorze (w tym walidacji i teście), wyniki walidacji będą zawyżone,
niestabilność dla rzadkich kategorii – kategoria, która wystąpiła kilka razy, może otrzymać ekstremalną wartość kodowania,
zmiana rozkładu w czasie – jeśli relacja między kategorią a targetem dryfuje, statystyki szybko się dezaktualizują.
Bezpieczniejsza konfiguracja to:
wyliczanie target encodingu w ramach wewnętrznych foldów cross-validation na treningu,
dodanie shrinkage – wygładzania wartości w kierunku średniej globalnej, zależnie od liczby obserwacji w kategorii,
zastępowanie zbyt rzadkich kategorii wartością „globalną” lub dla nadrzędnej grupy (np. kraju zamiast miasta).
Dzięki temu model dostaje bardziej wiarygodny sygnał, a walidacja lepiej odzwierciedla sytuację produkcyjną.
Count encoding i inne proste statystyki
Zamiast od razu wiązać kategorie z targetem, można zacząć od prostszych statystyk:
count encoding – liczba wystąpień danej kategorii w zbiorze treningowym,
frequency encoding – udział procentowy danej kategorii,
ranking po częstości – zamiana kategorii na jej pozycję w rankingu popularności.
Takie kodowania:
często wystarczająco rozróżniają „typowe” i „egzotyczne” wartości,
są mniej podatne na przeciek, ponieważ nie korzystają bezpośrednio z targetu,
Przy cechach typu ID produktu count encoding bywa jednym z niewielu rozsądnych wyjść, jeśli nie ma dodatkowego słownika opisującego produkty (atrybuty, kategorie, cenę itp.).
Porządkowanie kategorii a zmienne naprawdę uporządkowane
Część zmiennych kategorycznych ma naturalny porządek: poziomy wykształcenia, skale ocen (np. „bardzo zły” – „bardzo dobry”), przedziały wielkości firmy. W takich sytuacjach:
kodowanie liczbami całkowitymi odwzorowującymi ten porządek jest uzasadnione,
modele liniowe mogą wykorzystać monotoniczność (przy pewnym ryzyku nadmiernego uproszczenia),
drzewa zyskują prostszy podział niż przy one-hot na każdą kategorię.
Kłopot zaczyna się, gdy porządku nie ma, a jest on sugerowany sztucznie (np. kraj = 1, 2, 3…). Taki zabieg wprowadza do modelu fałszywe „odległości” między kategoriami, co bywa jeszcze gorsze niż prymitywny one-hot. Jeżeli nie da się obronić logicznego porządku, lepiej pozostać przy kodowaniach „bezładnych” (one-hot, target, count).
Embeddings dla kategorii wysokiej krotności
Gdy liczba kategorii jest ogromna (kilkadziesiąt tysięcy kodów produktów, miliony użytkowników), klasyczne kodowania stają się niepraktyczne. Jednym z rozwiązań są embeddingi – gęste wektory liczbowe uczone razem z modelem (np. siecią neuronową).
W praktyce:
każda kategoria otrzymuje indeks,
uczy się macierzy przekształcającej indeks w krótki wektor liczb (kilka–kilkadziesiąt wymiarów),
te wektory są dalej przetwarzane przez model jak zwykłe cechy numeryczne.
Embeddingi pozwalają uchwycić podobieństwa między kategoriami, których się nie zadeklarowało (np. produkty kupowane przez podobnych klientów kończą blisko siebie w przestrzeni embeddingów). Ceną jest bardziej skomplikowane środowisko treningowo-produkcyjne i ograniczona interpretowalność.
Obsługa kategorii nieznanych i rzadkich
Prawie każdy system produkcyjny prędzej czy później trafi na kategorię, której nie było w treningu. Jak można na to zareagować:
mieć jawnie zdefiniowaną kategorię typu „OTHER/UNKNOWN” i mapować na nią wszystko, czego nie ma w słowniku,
Najczęściej zadawane pytania (FAQ)
Dlaczego przygotowanie danych jest ważniejsze niż wybór algorytmu?
Źle przygotowane dane wprowadzają do modelu systematyczne błędy, których nie widać na pierwszy rzut oka. Algorytm, nawet bardzo zaawansowany, będzie jedynie wiernie „uczył się” tych błędów: pomylonych etykiet, złych dat, przecieków informacji czy pomieszanych jednostek.
Zmiana modelu z prostego na złożony zwykle daje mniejszy efekt niż solidne ogarnięcie danych: spójnych typów, poprawnego traktowania braków, sensownego kodowania kategorii i usunięcia oczywistych nonsensów (np. ujemny czas trwania). To w tych miejscach projekty najczęściej się wykładają, nie na poziomie algorytmu.
Jakie są najczęstsze problemy z „surowymi” danymi do uczenia maszynowego?
Dane z systemów produkcyjnych rzadko nadają się od razu do modelu. Typowy zestaw problemów to:
duplikaty rekordów (ten sam klient lub transakcja w kilku systemach),
brak spójności typów: liczby jako tekst, daty jako różne stringi, flagi jako „tak/nie”, „1/0”, „Y/N”,
błędne lub niespójne etykiety (np. mylenie „rezygnacji” z „brakiem kontaktu”),
różne zapisy tych samych kategorii („PL”, „Polska”, „POLSKA ”),
wartości techniczne udające dane („-999”, „brak”, „N/A” zamiast jawnego braku).
Bez uporządkowania tych kwestii model uczy się chaosu. Efekt to gorsza skuteczność lub – co gorsze – bardzo dobre metryki na walidacji i kompletnie niestabilne zachowanie po wdrożeniu.
Jakie decyzje w preprocessingu danych są nieodwracalne?
Kilka typów decyzji trudno cofnąć bez powrotu do surowych danych. Najczęściej chodzi o:
trwałe usuwanie obserwacji (rzadkie przypadki znikają z „świata” modelu),
agregację po czasie (np. z dziennych na tygodniowe – zanikają wzorce dzienne i weekendowe),
łączenie wielu kategorii w jedno „inne” (tracisz szczegółowość i możliwość późniejszej analizy),
sztywne obcinanie wartości odstających (można wyciąć rzadkie, ale prawdziwe zjawiska).
Dlatego każdy krok dobrze jest umieć uzasadnić: co dokładnie zmieniono, dlaczego, i jaki to ma wpływ na interpretację modelu i późniejsze decyzje biznesowe.
Jak poprawnie potraktować brakujące dane w modelu ML?
Brak danych to nie zawsze to samo co „zero” lub „nie dotyczy”. Przykładowo brak liczby spotkań handlowych może oznaczać, że nikt nie wpisał wartości, a nie faktyczne „0 spotkań”. Automatyczne podstawianie zera w takich miejscach tworzy fałszywy sygnał, który model chętnie wykorzysta.
Sposób obsługi braków zależy od kontekstu. Stosuje się m.in.:
dedykowany znacznik braku (osobna kategoria lub flaga „missing”),
imputację (np. medianą, wartością najbardziej typową w danej grupie),
świadome usuwanie rekordów lub kolumn, gdy braków jest zbyt dużo i nie da się ich sensownie odtworzyć.
Kluczowe jest zrozumienie, co brak oznacza w systemie źródłowym – bez tego łatwo pomylić „brak informacji” z „brakiem zjawiska”.
Jak zdecydować, które kolumny użyć jako cechy, a które wykluczyć z modelu?
Dobrym punktem wyjścia jest mapowanie pól. Każdej kolumnie przypisuje się rolę: target (y), cecha wejściowa (X), identyfikator/klucz, metadane techniczne, potencjalnie zabronione cechy (np. płeć, rasa, kod pocztowy). Tę mapę lepiej zrobić na początku, zamiast ładować „wszystko jak leci”.
Typowe błędy to użycie identyfikatorów (np. ID transakcji) jako cech, wciąganie metadanych importu do modelu oraz pozostawienie pól, które wprost ujawniają target (przeciek informacji). Model osiąga wtedy „magicznie” świetne wyniki, ale kompletnie nie generalizuje do nowych danych.
Czy dane w CSV wystarczą, żeby zbudować sensowny model?
Sam CSV to za mało, jeśli brakuje kontekstu domenowego. Pola o tej samej nazwie potrafią znaczyć coś zupełnie innego w różnych systemach: „status klienta” może być rozliczeniowy albo marketingowy, „0 rabatu” może oznaczać brak rabatu albo to, że rabat nie został jeszcze policzony.
Bez rozmowy z właścicielami procesów lub analitykami biznesowymi łatwo błędnie zinterpretować kolumny. Model wtedy nie przewiduje rzeczywistego zachowania klientów, tylko artefakty działania systemu (np. opóźnienia w aktualizacji statusów), co daje złudne poczucie skuteczności.
Jak sprawdzić, czy w danych w ogóle da się rozwiązać mój problem ML?
Na początku trzeba jasno zdefiniować: co ma być celem (targetem), jaka jest jednostka obserwacji (klient, transakcja, sesja itp.) i jaki horyzont czasowy ma model. Do tego dochodzi minimalny zestaw informacji: wiarygodny target, znacznik czasu (w zadaniach predykcyjnych), identyfikator jednostki oraz sensowne cechy kontekstowe.
Jeśli np. nie ma rzetelnie zebranych etykiet „odszedł/nie odszedł”, to model churn będzie w praktyce przewidywał błędy w systemie, a nie realną rezygnację. W takiej sytuacji problem jest technicznie nierozwiązywalny niezależnie od wybranego algorytmu – zaczynanie od „tuningu” modelu tylko maskuje brak kluczowych danych.
Opracowano na podstawie
Data Preparation for Data Mining. Morgan Kaufmann (2001) – Klasyczne omówienie etapów przygotowania danych do modeli ML
Feature Engineering and Selection: A Practical Approach for Predictive Models. Chapman and Hall/CRC (2019) – Praktyczne techniki cech, braków danych, kodowania kategorii
Applied Predictive Modeling. Springer (2013) – Proces budowy modeli: czyszczenie, brakujące dane, zmienne kategoryczne
