10 · Praktyka · 4 min czytania · aktualizacja 8 października 2026

Jak wygląda projekt uczenia maszynowego krok po kroku?

Co to jest

Przebieg projektu uczenia maszynowego (ML workflow) to uporządkowana sekwencja kroków od pytania biznesowego do działającego i monitorowanego modelu: sformułowanie problemu i metryki, zebranie i zrozumienie danych, podział na zbiory, model bazowy, iteracyjne ulepszanie z uczciwą walidacją, ostateczna ocena oraz wdrożenie. Najbardziej znany opis tego procesu to CRISP-DM z przełomu lat 90. i 2000.

Kluczowe słowo to „pętla”. Prawie nikt nie przechodzi tych kroków raz, od góry do dołu. Analiza błędów modelu odsyła do danych, dane zmieniają definicję problemu, a monitoring po wdrożeniu odsyła z powrotem na początek. Dobry workflow nie jest biurokracją — to zestaw zabezpieczeń przed najdroższymi pomyłkami.

Mechanizm — dlaczego tak działa

Kolejność kroków wynika z tego, gdzie projekty naprawdę się psują. Zły algorytm rzadko jest głównym problemem. Znacznie częściej zawodzi źle postawione pytanie (przewidujemy coś, czego nikt nie potrzebuje), zła metryka (dokładność przy rzadkiej klasie) albo wyciek informacji, który daje świetny wynik w walidacji i katastrofę w produkcji. Dlatego problem i metryka idą pierwsze, a zbiór testowy odkłada się na bok, zanim ktokolwiek zacznie oglądać dane zbyt dokładnie.

Model bazowy (baseline) daje skalę. Wynik 80% nic nie znaczy, dopóki nie wiesz, że przewidywanie zawsze tej samej klasy daje 62%, a reguła z jednej cechy 79%. Bez punktu odniesienia łatwo świętować model, który niczego nie wnosi, albo latami dopieszczać coś, co już dawno osiągnęło sufit danych.

Uczciwa walidacja jest sercem całej pętli, bo każda decyzja — cecha, model, hiperparametr — jest podejmowana na podstawie jej wyniku. Jeśli walidacja kłamie (wyciek, zła strategia podziału, za mały zbiór), każda kolejna decyzja optymalizuje szum. Stąd pipeline'y, które pilnują, żeby przetwarzanie danych było dopasowywane tylko na części uczącej, oraz walidacja krzyżowa zamiast jednego podziału.

Iteruje się małymi krokami, bo tylko wtedy wiadomo, co pomogło. Zmiana pięciu rzeczy naraz i poprawa o 1 punkt procentowy nie mówi nic o żadnej z nich. Zbiór testowy używa się raz, na końcu: każde kolejne zerknięcie zamienia go w kolejny zbiór walidacyjny i wynik przestaje być nieobciążony.

Ostatnie kroki — wdrożenie i monitoring — istnieją, bo świat się zmienia. Model jest zdjęciem zależności z przeszłości. Gdy rozkład danych dryfuje, jakość spada po cichu, bez żadnego komunikatu o błędzie.

Na przykładzie

Titanic: 891 pasażerów, przeżyło 38,4%. Model bazowy „wszyscy zginęli” ma dokładność 61,6%. Reguła z jednej cechy „kobiety przeżywają, mężczyźni nie” daje już 78,7%. Regresja logistyczna w pipelinie z imputacją i kodowaniem (5-krotna walidacja krzyżowa) osiąga 79,6%, las losowy 81,3%, las z głębokością ograniczoną do 5 — 82,3%, gradient boosting 81,5%.

Ten szereg liczb uczy więcej niż każdy z modeli osobno. Największy skok (z 61,6% do 78,7%) kosztuje jedną linijkę kodu. Kolejne 3–4 punkty kosztują resztę pracy. A odchylenie standardowe wyniku między foldami wynosi około 2–3 punktów, więc różnice między trzema ostatnimi modelami mieszczą się w szumie — wybór między nimi powinien zależeć też od prostoty i stabilności, nie tylko od trzeciej cyfry po przecinku.

Dane: Titanic

W praktyce

• Zacznij od jednego zdania: kto użyje predykcji, w jakiej decyzji i jaki błąd kosztuje więcej. Z tego wynika metryka.
• Odłóż zbiór testowy od razu (train_test_split(..., stratify=y)), a dla danych czasowych tnij po czasie, nie losowo.
• Model bazowy zawsze: DummyClassifier, DummyRegressor albo prosta reguła domenowa.
• Całe przetwarzanie zamknij w Pipeline i oceniaj przez cross_val_score lub cross_validate — to najprostsza ochrona przed wyciekiem.
• Prowadź dziennik eksperymentów: zmiana, wynik CV, odchylenie między foldami, ziarno losowości.
• Typowy błąd: wielokrotne „tylko zerknięcie” na zbiór testowy i strojenie pod niego.

Najczęstsze pytania

Ile czasu poświęca się danym, a ile modelom?

W praktyce większość czasu pochłania zrozumienie problemu, czyszczenie danych i budowa cech. Wybór algorytmu jest zwykle najkrótszym etapem, bo dla danych tabelarycznych kilka sprawdzonych rodzin modeli (regresja liniowa lub logistyczna, lasy, boosting) wystarcza w ogromnej większości przypadków.

Czy zawsze trzeba zaczynać od prostego modelu?

Tak, i nie chodzi o skromność. Prosty model szybko pokazuje, czy dane w ogóle niosą sygnał, ujawnia błędy w danych i wycieki (podejrzanie dobry prosty model to czerwona flaga) oraz wyznacza poprzeczkę, którą złożony model musi przeskoczyć, by uzasadnić swój koszt.

Kiedy można użyć zbioru testowego?

Raz, na samym końcu, do raportu ostatecznego wyniku. Jeśli po teście wracasz do zmian w modelu, test staje się zbiorem walidacyjnym, a jego wynik — optymistycznie obciążonym. Do wszystkich decyzji po drodze służy walidacja krzyżowa na części uczącej.

Źródła

Zobacz też