Od intuicji do definicji: co naprawdę oznacza „uczenie nadzorowane”?
Codzienne decyzje jako modele: klasyfikacja i regresja na przykładach
Uczenie nadzorowane to formalizacja tego, co robisz intuicyjnie każdego dnia. Patrzysz na kilka przesłanek i na tej podstawie przewidujesz wynik. Gdy oceniasz, czy nowy klient zapłaci fakturę w terminie, korzystasz z historii: jak płacili inni podobni klienci, jaka jest sytuacja na rynku, jakie sygnały wysyła w rozmowie. To nic innego jak ręczny model klasyfikacji: zapłaci na czas / nie zapłaci na czas.
Jeśli zamiast „zapłaci / nie zapłaci” pytasz „ilu klientów złoży zamówienie w przyszłym miesiącu”, przechodzisz do regresji – przewidywania konkretnej liczby. Takich sytuacji w biznesie jest mnóstwo: prognoza sprzedaży, liczby zgłoszeń do helpdesku, czasu dostawy, kosztu naprawy.
Klasyfikacja odpowiada na pytania typu „czy / który / do której grupy”, a regresja na „ile / jaki poziom / jaka wartość”. W obu przypadkach masz zestaw danych wejściowych (cech) i jedną zmienną wyjściową (etykietę), którą chcesz przewidzieć.
Zanim zagłębisz się w algorytmy, dobrze jest zadać sobie jedno, bardzo proste pytanie: czy przewidywana rzecz jest etykietą (kategoria) czy liczbą? Od tego wyboru zależy cała reszta – rodzaje modeli, metryki, sposób oceny, a potem wdrożenie.
Różnica między klasyfikacją a regresją bez żargonu
Wyobraź sobie, że prowadzisz sklep internetowy i chcesz lepiej planować kampanie marketingowe. Masz historię klientów: liczba wizyt na stronie, średnia wartość koszyka, produkty oglądane, region, wiek, reakcje na poprzednie kampanie.
Możesz zadać dwa różne pytania:
Klasyfikacja: czy klient zrobi zakup w ciągu najbliższych 7 dni? (odpowiedź: tak / nie)
Regresja: jaką kwotę ten klient wyda w ciągu najbliższych 30 dni? (odpowiedź: wartość w złotówkach)
Dane wejściowe są prawie te same. Zmienia się pytanie wyjściowe. W klasyfikacji wynik zamieniasz zwykle na decyzję: wysłać kod rabatowy czy nie, przekazać lead do sprzedaży czy zostawić w newsletterze. W regresji wyniki służą do planowania budżetu, prognozy przychodów, planowania zatowarowania.
Klucz tkwi w tym, ile informacji potrzebujesz. Klasyfikacja jest prostsza w użyciu: 0 lub 1, grupa A lub B. Regresja daje więcej niuansu, ale jest też bardziej czuła na błędy. Co będzie dla ciebie ważniejsze: prosty sygnał „podjąć akcję / nie” czy dokładne oszacowanie skali?
Czym uczenie nadzorowane różni się od nienadzorowanego i reguł biznesowych
Uczenie nadzorowane ma jeden wyróżnik: etykiety. Dla każdej obserwacji w danych historycznych wiesz, jaki był wynik. Czy klient odszedł, ile kupił, czy zgłoszenie zostało uznane, czy transakcja okazała się fraudem. Model uczy się odwzorowania: cechy → etykieta.
W uczeniu nienadzorowanym etykiet nie masz. Tam szukasz struktur samych w sobie: grup podobnych klientów, nietypowych zachowań, wymiarów zmniejszających złożoność danych. To jest inne narzędzie do innych pytań: „kogo mamy w bazie?” zamiast „czy odejdzie?”, „jakie są typy zachowań?” zamiast „ile kupi?”.
Reguły biznesowe to z kolei ręcznie zdefiniowane „jeśli–to”: jeśli klient ma zaległości powyżej X i jest po terminie powyżej Y dni, to blokujemy kolejne zamówienie. Proste, przewidywalne, łatwe do wytłumaczenia. Problem zaczyna się wtedy, gdy kombinacji cech jest dziesiątki lub setki – człowiek nie ogarnie tylu reguł jednocześnie i zaczyna przegrywać z uczeniem maszynowym.
Uczenie nadzorowane wchodzi tam, gdzie reguły zaczynają być zbyt liczne lub zbyt często zmieniają się w czasie. Z jednej strony daje większą elastyczność i dokładność, z drugiej wymaga danych, infrastruktury i dbałości o jakość.
Kiedy uczenie nadzorowane ma sens, a kiedy odpuścić
Zastanów się: czy potrzebujesz modelu ML, czy wystarczy dobrze ustawiona reguła albo raport? Uczenie nadzorowane ma sens, gdy:
masz wiele przykładów historycznych z oznaczoną etykietą,
zależność między wejściem a wyjściem jest zbyt złożona na proste reguły,
stawka jest na tyle wysoka, że dokładność prognoz przekłada się na realne pieniądze lub ryzyko,
proces będzie się powtarzał – czyli przewidywanie ma sens nie raz, ale setki lub tysiące razy.
Prosty przykład: jeśli chcesz raz określić, ile mniej więcej produktów zamówić na święta, może wystarczyć analiza w Excelu. Jeśli chcesz codziennie optymalizować ceny w sklepie na podstawie dziesiątek sygnałów, wtedy model nadzorowany ma znacznie więcej sensu.
Pytanie do ciebie: jaki konkretny problem próbujesz przewidzieć – etykieta czy liczba? Jeśli nie umiesz odpowiedzieć jednym zdaniem, to znak, że warto doprecyzować samą definicję problemu, zanim ruszysz dalej.
Źródło: Pexels | Autor: Google DeepMind
Dobrze sformułowany problem: od „chcę AI” do jasnej etykiety
Co jest wejściem, a co wyjściem?
Jednym z najczęstszych zaburzeń w projektach ML jest chaos na poziomie definicji: czego tak naprawdę chcesz się nauczyć? Dane wejściowe (cechy) to fakty, które masz do dyspozycji w momencie podejmowania decyzji. Dane wyjściowe (etykieta, target) to wynik, który chcesz przewidzieć.
Jeżeli prognozujesz rezygnację klienta z usługi, to:
wejście: historia płatności, wykorzystanie usługi, liczba kontaktów z BOK, typ abonamentu, wiek klienta, kanał sprzedaży, region, sezon,
wyjście: czy klient zrezygnował w ciągu kolejnych 90 dni (tak / nie).
Pomyłka zaczyna się wtedy, gdy jako cechy używasz informacji, które realnie pojawią się dopiero po decyzji. Przykład: liczba telefonów do BOK w miesiącu po rezygnacji. Model zadziała na papierze, ale w praktyce będzie bezużyteczny.
Zadaj sobie pytanie: jakie konkretnie dane realnie masz dostępne w momencie użycia modelu? To, co masz później, jest dobre do analizy przyczyn, ale nie do trenowania predykcji.
Zamiana „chcę AI” na precyzyjne pytanie przewidywania
„Chcę użyć AI w firmie” to jeszcze nie problem ML. Dla uczenia nadzorowanego potrzebujesz bardzo precyzyjnego pytania: co przewidujesz, dla kogo, kiedy i w jakiej formie ma zostać użyty wynik.
Przykłady doprecyzowania:
zamiast „chcę przewidywać sprzedaż” → „chcę przewidzieć dzienne obroty na poziomie całego sklepu w horyzoncie 14 dni” (regresja czasowa),
zamiast „chcę przewidywać fraudy” → „chcę oznaczyć każdą nową transakcję jako prawdopodobnie fraud / prawdopodobnie ok w ciągu maksymalnie 2 sekund od kliknięcia zapłać” (klasyfikacja online),
zamiast „chcę segmentować klientów” → „chcę przewidzieć szansę reakcji na kampanię SMS w ciągu 7 dni od wysyłki” (klasyfikacja reakcji).
Im bardziej konkretne pytanie, tym łatwiej dobrać metryki, zbiór danych, algorytmy i proces walidacji. Rozmyta definicja na starcie niemal gwarantuje frustrację na końcu.
Wybór etykiety: zawężenie, które „ratuje” model
Źle dobrana etykieta jest jak źle postawione zadanie. Model będzie się czegoś uczył, ale niekoniecznie tego, co jest dla ciebie ważne. Kilka praktycznych wskazówek:
Jedna główna etykieta na start. Jeśli dopiero zaczynasz, unikaj sytuacji, w której próbujesz na raz przewidzieć i rezygnację, i kwotę wydatków, i reakcję na kampanię. Najpierw pojedynczy, dobrze zdefiniowany target.
Czytelna definicja. „Klient utracony” wymaga kalendarza: po ilu dniach braku aktywności przyjmujesz, że odszedł? Po 30, 60, 90? Tu przydają się doświadczenia biznesowe i analiza danych.
Spójność w czasie. Jeśli zmieniasz definicję etykiety w trakcie projektu, modele stają się nieporównywalne. Lepiej zdefiniować raz, a później świadomie ewentualnie przeliczyć dane.
Czasem warto zawęzić target tak, by lepiej odpowiadał decyzjom: zamiast ogólnego „uwielbia markę”, użyj etykiety „dokonał co najmniej jednego zakupu w ciągu 30 dni po kampanii X”. Mniej romantycznie, ale znacznie bardziej użytecznie.
Jednostka predykcji i granice czasowe
Jednostka predykcji to odpowiedź na pytanie: dla czego dokładnie robisz prognozę? Najczęstsze opcje:
pojedynczy klient (churn, CLV, reakcja na kampanię),
pojedynczy dzień / godzina (obciążenie call center, ruch w sklepie, liczba zgłoszeń).
Drugą stroną medalu są granice czasowe: jak daleko w przeszłość patrzy model i jak daleko w przyszłość ma prognozować. Trzy kluczowe decyzje:
okno obserwacji – zakres danych wejściowych, np. zachowanie klienta w ostatnich 90 dniach,
horyzont predykcji – jak długo do przodu przewidujesz, np. churn w ciągu kolejnych 60 dni,
okno karencji – okres pomiędzy końcem obserwacji a początkiem prognozy, żeby uniknąć „zaglądania w przyszłość”.
Jeśli przygotowujesz dane, zadaj sobie krótkie pytanie kontrolne: jakie masz dane wejściowe, jaką jedną rzecz chcesz przewidzieć i w jakim horyzoncie czasu? Jasna odpowiedź daje solidną ramę dla całej reszty pracy.
Dane pod lupą: z czego składa się dobry zbiór do treningu?
Jak ocenić, czy w ogóle masz z czego trenować model
Zanim ruszysz do Jupyter Notebooka, sprawdź, czy twoje dane w ogóle „niosą” problem. Ilość, jakość, reprezentatywność – trzy słowa, które warto przełożyć na konkretne pytania.
Od czego zacząć?
Liczba obserwacji. Tysiąc wierszy to co innego niż milion. Przy małych zbiorach proste modele i mocna walidacja są zwykle bezpieczniejsze niż skomplikowane sieci.
Udział obserwacji z etykietą. Jak duży fragment bazy ma znany wynik? Jeśli tylko niewielki, może trzeba najpierw zainwestować w etykietowanie.
Szum i błędy. Czy widzisz oczywiste dziury, wartości z kosmosu, niespójne formaty? To zapowiedź pracy nad czyszczeniem.
Typy zmiennych i konsekwencje dla obróbki
Dane rzadko są jednorodne. W jednym zbiorze obok siebie leżą:
zmienne numeryczne (kwoty, liczby wizyt, wiek),
zmienne kategoryczne (kraj, kanał sprzedaży, typ produktu),
teksty (opisy zgłoszeń, notatki konsultantów, recenzje),
daty i czas (data zakupu, czas ostatniego logowania, godzina zgłoszenia).
Każdy typ wymaga innego traktowania:
zmienne numeryczne można skalować, logarytmować, normalizować,
zmienne kategoryczne trzeba zakodować (one-hot, target encoding, itp.),
teksty trzeba sprowadzić do cech liczbowych (np. długość tekstu, TF‑IDF, embeddingi),
daty zwykle rozbijasz na części (dzień tygodnia, miesiąc, godzina, sezon).
Warto już na tym etapie wiedzieć, z czym pracujesz. Pytanie do ciebie: czy masz listę wszystkich kolumn z typem danych i krótkim opisem, co w nich naprawdę jest? Taka „mapa danych” to prosty dokument, który oszczędza godziny domysłów przy kolejnych iteracjach.
Reprezentatywność: czy historia przypomina przyszłość?
Reprezentatywność: czy historia przypomina przyszłość? (ciąg przyczynowo‑skutkowy)
Model uczy się na historii z założeniem, że przyszłość będzie do niej wystarczająco podobna. To założenie jest kruche. Twoje dane mogą być świetnie wyczyszczone, ale jeśli pochodzą z innej „epoki” biznesowej, model będzie kalibrowany na świat, który już nie istnieje.
Zadaj sobie pytanie: czy okres, z którego masz dane, pasuje do okresu, w którym model ma działać? Kilka typowych pułapek:
zmiana oferty – wprowadzenie nowej linii produktów, likwidacja kanału sprzedaży, mocne promo, które „przestraja” zachowania klientów,
szoki zewnętrzne – pandemie, wojny, zmiany prawa; wszystko, co „łamie” dotychczasowe sezonowości,
zmiany w systemach – migracja CRM, zmiana sposobu logowania danych, inne definicje pól.
Dobrym nawykiem jest porównanie rozkładów kluczowych cech między okresem historycznym a nowszymi danymi (np. prostymi histogramami lub wykresami pudełkowymi). Jeśli widzisz, że np. struktura kanałów sprzedaży kompletnie się zmieniła, zadaj pytanie: czy nie trzeba ograniczyć okna historii lub osobno potraktować „stary świat” i „nowy świat”?
Pomyśl: czy masz w danych przykłady sytuacji, które chcesz dobrze przewidywać? Jeżeli chcesz prognozować zachowania nowych klientów po dużej kampanii, a w historii jej nigdy nie było, model może bardziej zgadywać niż przewidywać.
Balans klas i rzadkie zdarzenia
W wielu realnych problemach „pozytywne” przypadki są rzadkie: fraudy, poważne awarie, rezygnacje VIP‑ów. To klasyczny scenariusz niezbalansowanych klas. Jeden rzut oka na rozkład etykiety bywa bardzo pouczający: 99% „nie”, 1% „tak”.
Zadaj sobie pytanie: jak rzadki jest mój pozytywny przypadek i jak bardzo boli mnie jego przeoczenie? Od odpowiedzi zależą techniki, które wybierzesz:
ważenie klas – podniesienie „wagi błędu” dla klasy rzadkiej (większy koszt pomyłki na fraudzie niż na transakcji OK),
oversampling (np. SMOTE) – sztuczne zwiększanie liczby obserwacji rzadkiej klasy w zbiorze treningowym,
undersampling – redukcja liczby przykładów z klasy dominującej, gdy masz ich bardzo dużo,
specjalne metryki – zamiast samej accuracy, skupienie na recall/precision, F1, AUC‑PR.
Nierównowaga klas sama w sobie nie jest problemem, ale jej zignorowanie już tak. Jeżeli budujesz model fraudowy, który ma „trafność 99%”, ale prawie nigdy nie oznacza fraudów, to nie masz systemu wykrywania fraudów, tylko licznik transakcji OK.
Stabilność definicji i źródeł danych
Stabilność oznacza, że to samo pole w danych znaczy to samo dzisiaj i rok temu. W praktyce często tak nie jest: zmieniają się słowniki, zakresy wartości, formaty. Systemy są migrowane, zespoły raportujące – reorganizowane.
Sprawdź kilka prostych rzeczy:
czy w logach/systemach nie było znanych zmian (np. nowego CRM) w środku okresu danych,
czy wartości kategoryczne nie „przeskakują” nagle (np. nowy sposób kodowania statusów zamówień),
czy pola kluczowe dla etykiety nie zmieniły znaczenia (np. inny algorytm liczenia „aktywności klienta”).
Dopytaj zespół biznesowy lub IT: kiedy ostatnio zmienialiście sposób zbierania tych danych? Krótka rozmowa potrafi ujawnić rzeczy, których nie widać z poziomu SQL‑a.
Źródło: Pexels | Autor: Tara Winstead
Porządkowanie i czyszczenie danych: fundament, którego nie da się ominąć
Braki danych: kiedy imputować, a kiedy odpuścić kolumnę
Braki danych (NaN, NULL, puste pola) pojawiają się zawsze. Kluczowe pytanie brzmi: czy brak jest informacją, czy błędem?
Jeśli brak wynika z logiki procesu (np. „data rezygnacji” pusta dla aktywnych klientów), to sam brak może być cenną cechą.
Jeśli brak jest efektem błędu technicznego (np. przez miesiąc padł log w jednej aplikacji), trzeba rozważyć naprawę/wycięcie fragmentu danych.
Strategie uzupełniania (imputacji):
proste wartości – średnia/mediana dla zmiennych numerycznych, najczęstsza kategoria dla jakościowych; dobre na start, ale spłaszczają rozkład,
wartości „specjalne” – np. −1, „UNKNOWN” plus dodatkowa flaga „brak_danych=1”; model sam oceni, czy brak niesie sygnał,
imputacja oparta na modelu – przewidywanie braków innym modelem (np. KNN, regresja); sensowna przy ważnych kolumnach i większych projektach.
Zanim wybierzesz metodę, odpowiedz: jak duży procent wartości w tej kolumnie jest pusty? Jeśli 80–90%, czasem uczciwiej jest ją usunąć lub potraktować tylko jako flagę „wiemy / nie wiemy”, zamiast udawać precyzję tam, gdzie jej nie ma.
Błędne i skrajne wartości: walka z „kosmosem” w danych
Drugą kategorią problemów są wartości wyraźnie nieprawdziwe lub „z innej planety”: wiek 999 lat, minusowy obrót, daty z przyszłego roku. Tu potrzeba połączenia zdrowego rozsądku i wiedzy o procesach biznesowych.
Zastanów się: jakie wartości są fizycznie lub procesowo niemożliwe? Ustal proste reguły sanity‑check:
zakres wieku (np. 0–100),
zakaz ujemnych ilości/sztuk, jeśli system na to nie pozwala,
daty w rozsądnym oknie (np. nie starsze niż 10 lat, nie późniejsze niż dziś).
Co zrobić z wartościami, które wychodzą poza te ramy?
poprawić według innego wiarygodnego źródła (jeśli istnieje),
uciąć (winsoryzacja) – ściąć do ustalonego progu, gdy chodzi o pojedyncze ekstremalne wartości w długim ogonie,
usunąć rekordy, jeśli liczba błędów jest mała, a dane wyraźnie uszkodzone.
Dobre pytanie kontrolne: czy skrajne wartości są realnym zjawiskiem biznesowym, czy błędem? Najwyższy jednorazowy zakup w historii sklepu może być zarówno realnym klientem hurtowym, jak i duplikatem faktury.
Spójność między tabelami i źródłami
Jeżeli korzystasz z kilku tabel (np. klienci, transakcje, reklamacje), spójność kluczy i dat staje się krytyczna. Bardzo łatwo zbudować piękny zbiór treningowy z przesuniętymi w czasie informacjami.
Zadaj sobie pytanie: czy na pewno łączysz dane tym kluczem, który odzwierciedla proces biznesowy? Typowe problemy:
różne identyfikatory dla tego samego klienta w różnych systemach,
duplikaty transakcji po stronie bramki płatniczej i systemu księgowego,
różne strefy czasowe lub formaty dat, prowadzące do subtelnych przesunięć.
Dobrym testem jest przejście przez kilka losowo wybranych przypadków „ręcznie”: klient X, transakcja Y, zgłoszenie Z. Czy daty i kwoty pasują logicznie? Jeśli nie, model zbuduje sobie wizję świata opartą na tej niespójności.
Data leakage: gdy model wie za dużo
„Przeciek informacji” (data leakage) to sytuacja, w której w cechach ląduje informacja niedostępna w momencie przewidywania. Model na walidacji wygląda genialnie, w produkcji – katastrofalnie.
Pomyśl: czy wśród twoich cech nie ma takich, które są skutkiem zdarzenia, które próbujesz przewidzieć? Przykłady:
liczba kontaktów z BOK w tygodniu po rezygnacji, gdy przewidujesz churn,
flaga „transakcja_zgłoszona_jako_fraud” w modelu predykcji fraudu,
kwota korekty faktury, gdy przewidujesz ryzyko korekt.
Bezpieczna zasada: przy każdej kolumnie zadaj pytanie „kiedy staje się znana?” Jeżeli odpowiedź brzmi „po dacie przewidywania” – ta cecha nie może być wykorzystana. W praktyce brak tego kroku to jedna z głównych przyczyn „magicznych” wyników na PoC, które nie dają się powtórzyć na produkcji.
Standaryzacja i normalizacja: kiedy skalować zmienne
Wiele algorytmów jest wrażliwych na skalę cech (np. regresja liniowa, k‑NN, sieci neuronowe). Gdy jedna zmienna ma zakres 0–1, a inna 0–1 000 000, druga zdominuje obliczenia dystansów lub gradientów.
Masz do wyboru kilka podstawowych podejść:
standardyzacja (z‑score) – odejmujesz średnią i dzielisz przez odchylenie standardowe; rozkład ma średnią 0 i wariancję 1,
min‑max – skalowanie do zakresu [0, 1] lub [−1, 1]; użyteczne przy sieciach neuronowych,
logarytmowanie – gdy rozkład jest silnie skośny (np. kwoty transakcji), log świetnie „spłaszcza” duże wartości.
Krytyczny szczegół: parametry skalowania wyliczasz wyłącznie na zbiorze treningowym, a potem stosujesz te same parametry do walidacji i testu. W przeciwnym wypadku „podsuwasz” modelowi informacje o rozkładzie spoza treningu i delikatnie oszukujesz walidację.
Źródło: Pexels | Autor: cottonbro studio
Projekt cech: jak zamienić surowe dane w coś zrozumiałego dla modelu
Myślenie cechami, nie tylko kolumnami
Surowa kolumna „liczba transakcji” to dopiero początek. Kluczowe pytanie brzmi: co w zachowaniu klienta lub obiektu jest istotne dla twojej decyzji? Zamiast bezrefleksyjnie wrzucać wszystko, warto świadomie konstruować cechy, które odzwierciedlają hipotezy biznesowe.
Przykład: przewidujesz churn w aplikacji mobilnej. Poza surową liczbą logowań możesz zbudować:
trend aktywności (czy logowania rosną, czy maleją),
różnicę między aktywnością w ostatnim tygodniu a średnią z poprzedniego miesiąca,
liczbę dni bez logowania w ostatnim okresie.
Zapytaj siebie i zespół: po czym „na oko” poznajecie klienta, który odejdzie? Każda taka intuicja to kandydat na cechę.
Agregacje czasowe: okna, które „chwytają” zachowanie
Gdy masz dane transakcyjne lub logi, pojedyncze rekordy rzadko wystarczają. Model zwykle pracuje na poziomie klienta, produktu, dnia – potrzebujesz więc agregować zachowania w czasie.
Kilka praktycznych schematów:
okna ruchome (rolling windows) – np. liczba zakupów w ostatnich 7, 30, 90 dniach; różne okna łapią inne typy zachowań,
statystyki opisowe – średnia, mediana, maksimum/minimum, odchylenie standardowe wartości w oknie,
miary recency / frequency / monetary (RFM) – czas od ostatniej aktywności, liczba aktywności, suma wydatków.
Dobre pytanie: jakie horyzonty czasowe są sensowne dla mojego procesu? Dla e‑commerce tygodnie i miesiące, dla fraudu – minuty i godziny, dla churnu – miesiące.
Inżynieria cech kategorycznych: od słowników do sygnałów
Zmiennych kategorycznych nie da się wprost podać większości algorytmów – trzeba je zakodować. Sposób kodowania ma duży wpływ na jakość modelu, zwłaszcza gdy liczba kategorii jest duża.
one‑hot encoding – tworzysz osobną kolumnę dla każdej kategorii z wartościami 0/1; prosty i bezpieczny, ale przy wielu kategoriach prowadzi do „wybuchu wymiarów”,
target encoding – zastępujesz kategorię statystyką związaną z etykietą (np. średnie prawdopodobieństwo pozytywnej etykiety w tej kategorii); bardzo skuteczny, ale wymaga ostrożnej walidacji, żeby nie przemycić informacji o etykiecie,
hashing trick – rzutowanie kategorii na ograniczoną liczbę „kubłów” przez funkcję hash; przydatne przy ogromnych słownikach (np. ID produktów),
łączenie lub grupowanie rzadszych kategorii w jedną kategorię „INNE” lub większe klastry (np. zamiast konkretnych miast – regiony).
Koniecznie zadaj pytanie: ile unikalnych wartości ma ta kolumna i czy wszystkie są potrzebne? Jeżeli masz tysiące rzadkich kategorii używanych raz lub dwa razy, rozsądniej jest je połączyć niż przerabiać na tysiące cech.
Interakcje i nieliniowości: gdy „2 + 2” nie równa się „4”
Łączenie cech: gdy pojedyncza kolumna to za mało
Często nie sama wartość, lecz relacja między wartościami niesie najwięcej informacji. Zamiast osobno podawać „liczbę zakupów” i „czas bycia klientem”, możesz skonstruować cechę „zakupy na miesiąc współpracy”.
Zapytaj siebie: co jest naprawdę porównywane w głowie analityka lub menedżera? Kilka typowych wzorców:
ilorazy – koszt / przychód, liczba reklamacji / liczba zamówień, liczba logowań / dni od rejestracji,
różnice – saldo: wpłaty minus wypłaty; różnica między limitem kredytowym a aktualnym zadłużeniem,
udziały – udział danego produktu w koszyku, udział kanału (mobile vs web) w całości ruchu klienta.
Jeśli już masz kilka bazowych cech, zadaj pytanie kontrolne: które z nich naturalnie się ze sobą „porównują”? To dobra lista kandydatów do interakcji.
Proste nieliniowości: progi, przedziały, binning
Modele liniowe lub drzewiaste często lepiej działają, gdy dodasz im lekko przetworzone wersje prostych cech. W praktyce wiele zjawisk ma charakter progowy: zachowanie klienta zmienia się po przekroczeniu pewnego poziomu wydatków czy liczby logowań.
Możesz wprowadzać:
binaryzacje – flaga „klient VIP” po przekroczeniu określonego przychodu, flaga „nowy klient” do 30 dni od rejestracji,
przedziały (binning) – grupowanie ciągłych wartości w kilka sensownych „koszyków” (np. wiek 18–25, 26–35 itd.),
transformacje – pierwiastki, logarytmy, kwadraty, gdy zależność jest wyraźnie nieliniowa.
Przy każdym takim pomyśle zadaj sobie pytanie: czy taka konstrukcja ma sens biznesowy, czy tylko „ładniej wygląda na wykresie”? Najlepsze nieliniowości odzwierciedlają rzeczywiste progi decyzyjne w procesie.
Automatyczna inżynieria cech: korzystać, ale z głową
Narzędzia AutoML i biblioteki do automatycznej inżynierii cech (np. oparte o „feature tools”) potrafią wygenerować setki lub tysiące kandydatów. Kusząca perspektywa, ale pojawia się pytanie: czy rozumiesz, co model tak naprawdę wykorzystuje?
Praktyczny kompromis:
najpierw przygotuj ręcznie kilka kluczowych, dobrze przemyślanych cech,
potem pozwól narzędziu wygenerować dodatkowe kombinacje i agregacje,
następnie przejrzyj ranking ważności cech i zadaj sobie pytanie: czy te topowe cechy mają logiczne wyjaśnienie?
Jeżeli najważniejsze sygnały są zupełnie nielogiczne z perspektywy procesu (np. dziwne kombinacje ID i timestampów), trzeba sprawdzić, czy nie wkradł się data leakage albo błąd w łączeniu danych.
Śledzenie rodowodu cech (feature lineage)
Im większy projekt, tym bardziej przydaje się wiedza: skąd wzięła się ta cecha i jak jest liczona? Bez tego po kilku iteracjach nikt nie wie, czym naprawdę jest „score_klienta_v3b”.
Prosty, ale skuteczny nawyk:
dla każdej nowej cechy zapisz krótki opis (1–2 zdania),
zapisz źródła: z jakich tabel i kolumn pochodzi,
dodaj wzór lub pseudokod generowania, najlepiej w repozytorium obok kodu.
Zapytaj siebie: czy osoba spoza zespołu, patrząc na ten opis, byłaby w stanie odtworzyć cechę? Jeżeli nie – opis jest zbyt mglisty.
Podział na zbiory treningowe, walidacyjne i testowe: gdzie kończy się nauka, a zaczyna sprawdzian
Dlaczego jeden zbiór danych nie wystarczy
Model, który „uczy się na pamięć”, będzie świetny na tych samych danych, na których trenował, ale słaby w nowych sytuacjach. Potrzebujesz więc niezależnego sprawdzianu.
Zanim zaczniesz dzielić dane, zadaj pytanie: jakiego typu decyzje będzie wspierał ten model i jak stabilne są dane w czasie? Od tego zależy sposób podziału.
Podział losowy: kiedy ma sens
Jeśli dane nie mają istotnego wymiaru czasowego (np. klasyfikacja obrazów, ocena wiarygodności wniosku kredytowego bez silnego trendu w czasie), można zastosować prosty podział losowy.
Typowa praktyka:
train: 60–80% danych – służy do nauki parametrów modelu,
validation: 10–20% – używany do strojenia hiperparametrów i wyboru architektury,
test: 10–20% – dotykany dopiero na końcu, tylko raz, jako finalny egzamin.
Jeśli korzystasz z takiego podziału, zapytaj: czy losowanie nie rozbija kluczowych struktur? Na przykład dane z jednego pacjenta lub klienta powinny trafić wyłącznie do jednego zbiory, żeby nie „przenikały” między treningiem a testem.
Podział czasowy: gdy ważna jest chronologia
W wielu zastosowaniach (churn, prognozy popytu, fraud) dane mają silny wymiar czasowy. Model ma przewidywać przyszłość na podstawie przeszłości. Wtedy losowy podział byłby nielogiczny – kazałby modelowi „znać przyszłość”.
Lepszym pomysłem jest podział według czasu:
train – najstarszy okres (np. pierwsze 12 miesięcy),
validation – późniejszy okres (np. kolejne 3–6 miesięcy),
test – najnowszy okres, najbardziej zbliżony do tego, co zobaczysz w produkcji.
Zapytaj siebie: jakie okno czasowe najlepiej odzwierciedla przyszłe użycie modelu? Jeśli model będzie aktualizowany co kwartał, test dobrze jest ustawić na ostatni kwartał, a nie losowy miks miesięcy.
Stratyfikacja: aby klasy nie zniknęły
Przy zadaniach klasyfikacji, szczególnie z niezrównoważonymi klasami (np. fraud, rzadkie awarie), czysto losowy podział może sprawić, że w walidacji lub teście pozytywna klasa będzie prawie niewidoczna.
Lepiej użyć stratyfikowanego podziału, czyli losowania z zachowaniem proporcji klas w każdym zbiorze. W większości bibliotek to dosłownie jeden parametr, ale konsekwencje są ogromne: metryki stają się stabilniejsze, a porównania modeli – uczciwsze.
Dobre pytanie kontrolne: jaki jest udział klasy pozytywnej w całym zbiorze i czy podobny udział widać w train/validation/test?
Cross‑validation: kiedy danych jest mało
Przy małych zbiorach prosty podział na trzy części bywa zbyt kosztowny – zbyt mało danych zostaje do nauki. Wtedy z pomocą przychodzi k‑fold cross‑validation.
W skrócie:
dzielisz dane na k części (foldy),
trenujesz model k razy – za każdym razem inne 1/k danych gra rolę walidacji, reszta to trening,
uśredniasz wyniki ze wszystkich foldów.
Jeśli myślisz o cross‑validation, zadaj pytanie: czy dane mają strukturę, której nie wolno mieszać? Dla danych sekwencyjnych lub z czasem lepsze są warianty „time series CV”, gdzie foldy są kolejnymi przedziałami czasu, a nie losową mieszanką.
Jeżeli dopiero poznajesz świat data science, przejrzyj najpierw bazę prostymi narzędziami – Excel, SQL, prosty Python – zamiast od razu rzucać się na budowanie modelu. W sieci, m.in. na praktyczne wskazówki: informatyka, znajdziesz sporo przykładów, jak takie wstępne oględziny zaplanować.
Oddzielny zbiór testowy: dlaczego nie wolno go „podglądać”
Bardzo łatwo niechcący „zużyć” zbiór testowy: kilkanaście razy sprawdzić wyniki, poprawić cechy, dobrać hiperparametry… Formalnie to nadal test, praktycznie – część procesu strojenia.
Ustal od początku: kiedy pierwszy raz spojrzysz na wyniki na teście? Zdrowa praktyka to:
wszystkie decyzje projektowe opierać na wynikach na walidacji (ewentualnie na cross‑validation),
zbiór testowy uruchomić raz przed wdrożeniem, jak prawdziwy egzamin końcowy,
po wdrożeniu traktować dane produkcyjne jako kolejny „test” w czasie.
Uważaj na przeciek między zbiorami
Data leakage to nie tylko „złe cechy”. To również przenikanie informacji między zbiorem treningowym a testowym.
Sprawdź kilka rzeczy:
czy preprocessingi (skalowanie, imputacja, target encoding) uczone są wyłącznie na treningu, a potem stosowane do walidacji/testu,
czy te same obiekty (np. ten sam klient, pacjent, urządzenie) nie występują w więcej niż jednym zbiorze,
czy przy serializowaniu cech nie zapisujesz „w pamięci” statystyk policzonych na całości danych (np. globalnych średnich).
Zadaj sobie pytanie: czy gdybym jutro dostał zupełnie nową paczkę danych, byłbym w stanie zastosować dokładnie ten sam pipeline, niczego nie przeliczając z użyciem nowych etykiet? Jeśli nie – konfiguracja podziału i przetwarzania wymaga korekty.
Nawet poprawnie przygotowane train/validation/test nie gwarantują sukcesu, jeżeli scenariusz walidacyjny znacząco różni się od produkcyjnego.
Zastanów się:
jak często model będzie aktualizowany (codziennie, co miesiąc, raz na rok?),
z jakim opóźnieniem będziesz znać etykietę (np. churn jest widoczny po miesiącach),
z jakich źródeł faktycznie będziesz korzystać na produkcji (czy wszystkie dziś używane kolumny są tam dostępne?).
Dobry nawyk to zbudowanie małego eksperymentu: weź historyczny okres jako „trening”, a kolejny – jako „produkcję”, i zasymuluj sposób działania modelu dzień po dniu lub tydzień po tygodniu. Sprawdź, jak zmieniają się metryki w czasie, a nie tylko jako jedna liczba z całego okresu.
Monitorowanie dryfu: gdy świat zmienia się po podziale
Nawet idealny podział na zbiory nie gwarantuje, że rozkład danych pozostanie taki sam po wdrożeniu. Pojawia się dryf danych: inne typy klientów, nowe produkty, zmiana procesów.
Warto więc już na etapie przygotowywania zbioru testowego zadać pytanie: które cechy są najbardziej narażone na zmianę w czasie? Następnie:
porównaj rozkład tych cech między train a test (np. histogramy, statystyki),
przygotuj prosty raport, który później odtworzysz na produkcji (np. co miesiąc),
zdefiniuj proste progi alarmowe: jak duża zmiana w rozkładzie ma skłonić cię do ponownego treningu.
Dzięki temu podział na zbiory nie jest jednorazową operacją, tylko początkiem świadomego zarządzania cyklem życia modelu.
Najczęściej zadawane pytania (FAQ)
Czym jest uczenie nadzorowane w prostych słowach?
Uczenie nadzorowane to sposób uczenia modeli na podstawie przykładów, gdzie dla każdego przypadku znasz poprawną odpowiedź. Masz dane wejściowe (cechy) i etykietę (wynik), a model uczy się odwzorowania: z cech do etykiety. Potem stosujesz to odwzorowanie do nowych przypadków.
Pomyśl o tym jak o praktykancie w zespole: pokazujesz mu setki sytuacji „tak było” → „taką decyzję podjęliśmy”. Po jakimś czasie zaczyna sam przewidywać wyniki dla nowych sytuacji. Zastanów się: jakie decyzje w twojej firmie dziś podejmowane są „na czuja”, ale masz do nich historię i wynik?
Jaka jest różnica między klasyfikacją a regresją?
Klasyfikacja przewiduje etykietę, czyli kategorię: tak/nie, typ klienta, grupa ryzyka. Regresja przewiduje liczbę: przychód, czas dostawy, prawdopodobieństwo w skali 0–1, kwotę zamówienia. W obu przypadkach dane wejściowe mogą być bardzo podobne – różni się pytanie wyjściowe.
Proste kryterium: co chcesz dostać na końcu – konkretną liczbę czy wybór jednej z kilku klas? Zadaj sobie pytanie: czy wystarczy ci sygnał „zareaguje / nie zareaguje”, czy potrzebujesz oszacować „o ile wzrosną zakupy tego klienta”?
Kiedy opłaca się użyć uczenia nadzorowanego, a kiedy wystarczy Excel lub reguły?
Uczenie nadzorowane ma sens, gdy masz dużo historycznych przykładów z jasnym wynikiem, zależność jest zbyt złożona na proste reguły, a decyzja powtarza się setki lub tysiące razy. Im większa stawka (koszty, przychody, ryzyko), tym bardziej inwestycja w model może się zwrócić.
Jeśli problem jest jednorazowy (np. „ile zamówić towaru na jedną akcję promocyjną”) albo można go ogarnąć kilkoma czytelnymi regułami biznesowymi, często szybszy i tańszy będzie dobrze skonstruowany raport lub arkusz. Zastanów się: czy naprawdę potrzebujesz modelu, czy tak naprawdę brakuje ci porządnie policzonej analizy?
Jak poprawnie zdefiniować problem do uczenia nadzorowanego?
Dobry problem ML da się streścić jednym konkretnym zdaniem: co przewidujesz, dla kogo, na jaki horyzont czasu i jak użyjesz wyniku. Przykład: „Chcę przewidzieć, czy klient zrezygnuje z usługi w ciągu 90 dni od dziś, żeby wcześniej zaproponować mu utrzymanie”. To jest jasny target i kontekst decyzji.
Sprawdź siebie trzema pytaniami: jaka jest jedna główna etykieta (klasa lub liczba)? Kiedy dokładnie ma być znany wynik (horyzont czasu)? Co konkretnego zrobisz, gdy model da sygnał X lub Y? Jeśli nie potrafisz odpowiedzieć, to znak, że problem jest jeszcze zbyt rozmyty.
Co powinno być danymi wejściowymi, a co etykietą (wyjściem) modelu?
Dane wejściowe to wszystko, co masz dostępne w momencie podejmowania decyzji: historia zachowań klienta, segment, kanał sprzedaży, sezon, kontekst transakcji. Etykieta to wynik, który pojawi się później, a który chcesz przewidzieć: zakup / brak zakupu, kwota, rezygnacja, zgłoszenie fraudu.
Kluczowa pułapka: nie używaj jako cech informacji, które znasz dopiero po wyniku. Jeśli przewidujesz odejście klienta, liczba zgłoszeń po rezygnacji nie może być cechą. Zadaj sobie pytanie: czy ta dana istniała i była dla mnie dostępna w momencie, gdy w realnym świecie miałbym użyć predykcji?
Jak wybrać dobrą etykietę (target) dla modelu nadzorowanego?
Dobra etykieta jest: pojedyncza na start, jasno zdefiniowana i spójna w czasie. Zamiast ogólnego „lojalny klient”, sprecyzuj: „dokonał co najmniej jednego zakupu w ciągu 90 dni od pierwszej wizyty” albo „nie zrezygnował przez 6 miesięcy od aktywacji”. Taka definicja pozwala jednoznacznie oznaczyć każdy przypadek w danych.
Zadaj sobie trzy pytania: po ilu dniach klient jest dla ciebie „utracony”? Co dokładnie oznacza „aktywowany”? Jak długo chcesz obserwować wynik (okno czasowe)? Ustal to na początku i nie zmieniaj definicji w trakcie, bo inaczej nie porównasz uczciwie kolejnych wersji modeli.
Czym uczenie nadzorowane różni się od uczenia nienadzorowanego i od reguł biznesowych?
W uczeniu nadzorowanym zawsze masz etykietę – wiesz, jaki był wynik dla historycznych przypadków i uczysz model przewidywać ten wynik. W uczeniu nienadzorowanym etykiet nie ma: szukasz wzorców, klastrów, anomalii, ale nie „prawidłowej odpowiedzi”. To raczej narzędzie do exploracji i segmentacji niż do konkretnej prognozy.
Reguły biznesowe to ręcznie ustawione „jeśli–to”, oparte na wiedzy eksperckiej. Działają świetnie, gdy kombinacji jest mało i łatwo je zrozumieć. Gdy liczba zmiennych rośnie, ich interakcje robią się nieintuicyjne i wówczas modele nadzorowane zaczynają wygrywać – pod warunkiem, że masz dane i jasno określony target. Pytanie do ciebie: ile tych reguł masz dzisiaj i jak często trzeba je poprawiać?
Co warto zapamiętać
Uczenie nadzorowane to uporządkowana wersja codziennych decyzji: na podstawie znanych przesłanek przewidujesz wynik – kategorię (klasyfikacja) albo liczbę (regresja).
Klasyfikacja odpowiada na pytania typu „czy / który / do której grupy”, a regresja na „ile / jaka wartość”; pierwszy krok to zawsze jasne określenie, czy chcesz przewidywać etykietę, czy konkretną wartość liczbową.
Ten sam zestaw danych wejściowych może służyć do różnych zadań (np. „czy klient kupi?” vs „ile wyda?”) – kluczowy jest cel biznesowy: potrzebujesz prostego sygnału do akcji czy precyzyjnej prognozy skali?
Uczenie nadzorowane różni się od nienadzorowanego obecnością etykiet oraz od reguł biznesowych tym, że skaluje się tam, gdzie liczba kombinacji cech i ich zmienność przekraczają ludzką zdolność do ręcznego „jeśli–to”.
Model nadzorowany ma sens, gdy masz dużo oznaczonych przykładów, relacja wejście–wyjście jest złożona, stawka biznesowa jest wysoka, a przewidywanie powtarza się często (np. codzienna wycena, scoring leadów, prognoza popytu).
Jednorazowe, proste decyzje (np. jednorazowa prognoza zamówień na święta) często lepiej załatwić raportem lub Excelem; model ML przydaje się, gdy ten sam typ decyzji trzeba podejmować setki lub tysiące razy.
Opracowano na podstawie
The Elements of Statistical Learning: Data Mining, Inference, and Prediction. Springer (2009) – Klasyczne omówienie uczenia nadzorowanego, klasyfikacji i regresji
Pattern Recognition and Machine Learning. Springer (2006) – Formalne definicje modeli nadzorowanych, funkcji straty, oceny modeli
Machine Learning. McGraw-Hill (1997) – Podstawy uczenia nadzorowanego, pojęcia etykiet, cech i generalizacji
Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow. O’Reilly Media (2019) – Praktyczne przykłady przygotowania danych i trenowania modeli nadzorowanych
Introduction to Machine Learning. MIT Press (2020) – Przegląd algorytmów nadzorowanych i nienadzorowanych oraz ich zastosowań
Data Mining: Practical Machine Learning Tools and Techniques. Morgan Kaufmann (2016) – Praktyczne techniki budowy, strojenia i oceny modeli klasyfikacji i regresji
The Hundred-Page Machine Learning Book. Andriy Burkov Publications (2019) – Zwięzłe omówienie typów problemów ML, w tym klasyfikacji i regresji
Machine Learning Yearning. Deeplearning.ai – Praktyczne wskazówki definiowania problemu ML i podziału na wejścia i wyjścia
