Po co baseline i czym różni się „sensowny” baseline od bylejakiego
Baseline jako punkt odniesienia, a nie ozdobnik w repozytorium
Baseline w machine learning to nie jest „pierwszy lepszy model, który coś zwraca”. To świadomie zaprojektowany punkt odniesienia, który mówi: „jeśli nie umiesz pokonać mnie w sposób istotny statystycznie i biznesowo, to nie ma sensu komplikować systemu”. Bez takiego punktu cała dyskusja o jakości modeli opiera się na wrażeniach i życzeniach, a nie na faktach.
Sensowny baseline pełni trzy kluczowe funkcje:
sanity check – sprawdza, czy dane w ogóle niosą sygnał i czy metryki są poprawnie liczone,
punkt startowy do iteracji – pozwala ocenić, czy kolejne „ulepszenia” naprawdę coś wnoszą,
zabezpieczenie przed nad-inżynierią – jeśli prosty model działa równie dobrze jak skomplikowany, nie ma sensu utrzymywać potwora.
Bylejaki baseline to skrypt napisany „na szybko”, bez przemyślanej walidacji, bez stabilnych metryk, bez możliwości odtworzenia. Sensowny baseline to niewielki, ale pełnoprawny system eksperymentalny: prosty, czytelny, spójny z celem biznesowym. Można go w razie potrzeby wrzucić na produkcję i nie wstydzić się podpisać pod nim imieniem i nazwiskiem.
Różnica między „żeby coś działało” a baseline’em jako narzędziem do decyzji
Model „żeby coś działało” ma tylko jeden cel: dać jakikolwiek wynik. Często powstaje w notebooku, z jednym podziałem train/test, bez sensownego logowania, bez kontroli data leakage. Na jego podstawie trudno prowadzić rozmowę o tym, czy kolejne pomysły są lepsze czy gorsze – bo brakuje powtarzalności i rzetelnej ewaluacji.
Sensowny baseline to narzędzie decyzyjne. Odpowiada na pytania:
Czy pomysł na dane i cechy ma w ogóle sens, czy sygnał jest zbyt słaby?
Czy warto inwestować czas w bardziej złożone modele (deep learning, stacking itd.)?
Gdzie są główne słabości – w danych, w metryce, w przygotowaniu cech, czy w samym algorytmie?
Żeby baseline nadawał się do podejmowania decyzji, musi być:
powtarzalny – te same dane wejściowe dają ten sam wynik,
przejrzysty – wiadomo, jakie kroki wykonuje pipeline,
porównywalny – korzysta z tych samych metryk i tej samej strategii walidacji, co kolejne modele.
Kiedy baseline wystarcza jako model produkcyjny
W wielu biznesowych zastosowaniach prosty baseline jest w zupełności wystarczający. Zwłaszcza tam, gdzie:
problem jest prosty, a dane mają wyraźny sygnał,
koszt błędów nie jest wysoki,
ważniejsza jest stabilność, konserwacja i łatwość wyjaśnienia niż ostatnie procenty metryk.
Przykłady:
Ocena ryzyka churnu dla niewielkiej bazy klientów – regresja logistyczna z kilkunastoma cechami i dobrze dobranym progiem decyzyjnym może dać wystarczającej jakości wyniki.
Prosta rekomendacja treści na blogu – ranking „najpopularniejsze w ostatnim tygodniu” jako baseline rankingowy bywa tak skuteczny, że dodawanie bardziej skomplikowanych systemów ma sens dopiero od odpowiedniej skali.
Jeśli baseline:
spełnia cel biznesowy (np. zwiększa konwersję, oszczędza czas konsultantów),
jest prosty w utrzymaniu,
jest dobrze zrozumiały przez zespół i biznes,
to często nie ma biznesowego powodu, by koniecznie go „przeskakiwać” tylko dlatego, że bardziej zaawansowane modele są modne.
Przykład kosztownego projektu bez baseline’u
Typowy scenariusz z życia: zespół dostaje zadanie zbudowania systemu predykcji popytu. Zamiast zacząć od prostego baseline’u (np. prognoza „taka sama jak w poprzednim tygodniu” albo średnia ruchoma), od razu wpada w tryb: złożone sieci neuronowe, automatyczne wyszukiwanie architektury, dziesiątki hiperparametrów.
Po kilku tygodniach:
modele są trudne do interpretacji,
wyniki na walidacji wyglądają obiecująco, ale nikt nie wie, czy to faktycznie dobrze,
biznes pyta: „Czy to lepsze niż nasze dotychczasowe proste prognozy?” – a zespół nie ma jasnej odpowiedzi.
Dopiero po fakcie ktoś implementuje baseline: prognoza „taki sam popyt jak w zeszłym tygodniu, skorygowany o prostą sezonowość”. Okazuje się, że zaawansowany model wygrywa tylko symbolicznie, a czasu i pieniędzy poszło mnóstwo. Gdyby baseline powstał na początku, to:
można by szybko zobaczyć, jaki poziom jakości już zapewnia prosta metoda,
zespół mógłby zadecydować, czy potencjalne zyski z bardziej złożonych rozwiązań są warte wysiłku,
od razu wyszłyby na jaw błędy w metrykach lub podziale danych.
Uporządkowanie problemu: co trzeba wiedzieć, zanim powstanie baseline
Cel biznesowy i typ problemu: fundament sensownego baseline’u
Bez jasno sformułowanego celu biznesowego baseline zamienia się w akademickie ćwiczenie. Zanim powstanie choćby linijka kodu, trzeba ustalić:
co dokładnie ma się zmienić w biznesie dzięki modelowi (np. mniej niepotrzebnych telefonów, więcej kliknięć w ofertę, lepsza kolejność zgłoszeń),
jaki jest typ problemu: klasyfikacja (binarną/wieloklasowa), regresja, ranking, detekcja anomalii, seria czasowa,
jakie decyzje człowiek/ system podejmie na podstawie predykcji.
Przykład: zamiast ogólnego „chcemy przewidywać churn”, lepiej określić: „chcemy wytypować 10% klientów z najwyższym ryzykiem odejścia, którym wyślemy ofertę retencyjną, i sprawdzić, czy ograniczy to liczbę odejść”. Od razu widać, że:
problem to klasyfikacja binarna,
liczy się jakość rankingu w górnym procencie klientów, nie sama accuracy,
metryki typu precision@k lub lift będą istotniejsze niż „gołe” F1.
Zrozumienie danych: rozkłady, braki, sezonowość
Bazowanie na danych, których się nie rozumie, to prosty przepis na bezużyteczny baseline. Minimalna analiza eksploracyjna przed budową baseline’u powinna objąć:
rozkłady cech – czy są silnie skośne, czy wymagają transformacji (np. log),
brakujące wartości – gdzie, jak często i z jakiego powodu występują,
typy zmiennych – numeryczne, kategoryczne, daty/czasy, teksty,
sezonowość – cykle dobowe, tygodniowe, roczne, wpływ świąt, weekendów, kampanii marketingowych.
Kilka prostych wykresów i statystyk opisowych potrafi wyjaśnić, czemu „sprytne” modele nie dają poprawy nad średnią. Jeżeli np. klasa pozytywna stanowi promil danych, to baseline w postaci „zawsze przewiduj klasę negatywną” może mieć przyzwoitą accuracy, ale wątek biznesowy będzie kompletnie niezaspokojony.
Ograniczenia czasowe i obliczeniowe a kształt baseline’u
Baseline nie powstaje w próżni. Warunki brzegowe wpływają na to, jak daleko można się posunąć już na pierwszym etapie:
ile jest czasu na przygotowanie pierwszych efektów (dni, tygodnie, miesiące),
jakie są zasoby obliczeniowe (lokalny laptop vs klaster, GPU/CPU),
jak często model ma się aktualizować (batch raz na dzień/tydzień vs predykcje online w milisekundach).
Przy mocnych ograniczeniach obliczeniowych baseline powinien być:
szybki w trenowaniu,
tani w inferencji,
łatwy do zdeployowania – np. model liniowy lub małe drzewo.
Taki baseline nie tylko posłuży za punkt odniesienia, lecz także wyznaczy klasę rozwiązań, które wchodzą w grę. Nie ma sensu porównywać rozbudowanego deep learningu do baseline’u liniowego, jeśli i tak nie da się go wdrożyć z powodu wymagań latency.
Uzgodnienie metryk sukcesu z biznesem
Model może bić baseline w accuracy, a jednocześnie przegrywać z nim w praktyce biznesowej. Klucz leży w odpowiednim wyborze metryk, których definicja jest wspólna dla zespołu ML i biznesu.
Dla klasyfikacji binarnej zamiast „chcemy mieć jak najwyższą accuracy” lepiej powiedzieć:
„fałszywie pozytywne przewidywania są kosztowne (np. zbędne kontakty sprzedażowe)”,
„fałszywie negatywne są jeszcze bardziej kosztowne (np. przeoczone oszustwa)”,
„ważniejsza jest dla nas czułość (recall) powyżej określonego progu, przy ograniczonych fałszywych alarmach”.
Dopiero z takiej rozmowy wynika, jaką metryką oceniać baseline i kolejne modele: F1, AUC, ROC, precision@k, cost-based metric. Uzgodniona metryka staje się później jedyną walutą do porównywania zmian, więc baseline musi być nią poprawnie oceniony od samego początku.
Wybór metryk, które realnie mają sens
Przekład celu biznesowego na metrykę modelu
Model ML żyje na styku dwóch światów: biznesu i statystyki. Metryki typu AUC, RMSE czy NDCG są użyteczne tylko o tyle, o ile mają jasne przełożenie na realne decyzje i koszty.
Kilka praktycznych zasad:
jedna główna metryka do porównań (np. AUC, F1, RMSE),
2–3 metryki pomocnicze, które pokazują różne aspekty działania modelu (np. precision/recall, MAE + R²),
metryka kosztowa, jeżeli da się policzyć przybliżony efekt finansowy błędów.
Baseline musi być oceniany dokładnie tym samym zestawem metryk, co bardziej złożone modele. W przeciwnym razie porównanie przestaje mieć sens, a dyskusja wraca do „wrażenia, że nowy model jest lepszy”.
Klasyfikacja: accuracy, F1, AUC, log-loss i klasy niezbalansowane
W klasyfikacji binarnej najczęściej pojawiają się następujące metryki:
Accuracy – odsetek trafnych predykcji. Intuicyjna, ale zdradliwa przy niezbalansowanych klasach; baseline „zawsze przewiduj klasę większościową” potrafi mieć świetną accuracy i zerową wartość biznesową.
Precision i recall – dokładność pozytywnych predykcji oraz pokrycie pozytywnej klasy. Istotne, gdy koszt fałszywie pozytywnych i negatywnych jest różny.
F1 – harmoniczna średnia precision i recall. Dobry kompromis, gdy obie te miary są ważne.
AUC ROC – jakość rankingu prawdopodobieństw; niezależna od progu decyzyjnego, wygodna do porównań modeli.
Log-loss – kara za złe probabilistyczne przewidywania; ważny, gdy modelowe p(y=1) mają być używane w dalszych kalkulacjach (np. expected value).
Przy niezbalansowanych klasach sensowny baseline powinien używać metryk odpornych na dysproporcje, np. AUC, F1 dla klasy mniejszościowej, precision/recall@k. Z kolei log-loss bywa doskonałym wykrywaczem data leakage – jeśli „głupi” model ma bardzo dobry log-loss, coś jest podejrzane.
Regresja: RMSE, MAE, MAPE, R²
Dla zadań regresyjnych baseline ocenia się m.in. przez:
RMSE (root mean squared error) – mocno karze duże błędy, przez co skupia uwagę na ogonach rozkładu,
MAE (mean absolute error) – bardziej odporny na pojedyncze ekstremalne obserwacje, łatwiejszy do interpretacji („średnio mylimy się o X jednostek”),
MAPE – błąd procentowy; intuicyjny, ale rozpada się, gdy wartości rzeczywiste są bliskie zera,
Szeregi czasowe i prognozy: MAE, sMAPE, MASE
W prognozowaniu (popytu, ruchu, obciążenia systemu) klasyczne metryki regresyjne często nie wystarczają. Kluczowe jest porównanie modelu do „naiwnej” prognozy z przeszłości.
MAE / RMSE na horyzont – liczone osobno dla +1, +7, +30 kroków naprzód. Pozwalają sprawdzić, czy model nie „rozjeżdża się” na dalszym horyzoncie.
sMAPE (symetryczny MAPE) – łagodniej traktuje wartości bliskie zera, ale interpretacja bywa mniej intuicyjna.
MASE – błąd zeskalowany względem błędu prostej prognozy naiwnej (np. „jaka była wartość wczoraj”). Jeśli MASE < 1, oznacza to poprawę względem baseline’u naiwnego.
Dla sensownego baseline’u szeregowego kluczowe jest, żeby metryka porównywała model do prostej reguły czasowej, a nie do zera. Z zewnątrz MASE wygląda jak „jeszcze jedna literka”, ale w praktyce od razu pokazuje, czy cokolwiek udało się ograć względem „powtórz ostatnią wartość / średnią z poprzedniego tygodnia”.
Ranking i systemy rekomendacyjne: NDCG, MAP, precision@k
W rankingach i rekomendacjach kluczowe są pozycje z góry listy. Użytkownik widzi pierwsze kilka wyników – tam trzeba trafić jak najczęściej.
precision@k – odsetek trafnych rekomendacji w top-k. Dobre przy prostych scenariuszach „czy w top-5 jest coś sensownego”.
MAP (mean average precision) – średnia jakość listy wyników po wszystkich użytkownikach/zapytaniach.
NDCG – bierze pod uwagę zarówno trafność, jak i pozycję; poprawa trafności na 1. miejscu jest więcej warta niż korekta na 10.
Baseline rankingowy często polega na prostym sortowaniu po popularności (globalnej lub w segmencie) albo po ostatniej aktywności. Metryki rankingowe trzeba od początku liczyć dokładnie na tym samym zbiorze i z tym samym protokołem (np. leave-one-out na sekwencjach użytkownika), żeby porównanie z późniejszymi modelami było uczciwe.
Najprostsze baseline’y: „głupie” modele, które ratują projekty
Reguły biznesowe jako baseline zerowego poziomu
Często istnieje już ręczny proces decyzyjny: skrypt, reguły w systemie, prosta heurystyka analityka. To idealny pierwszy baseline.
Przykłady:
antyfraud: „zablokuj transakcję > X zł z kraju Y bez historii klienta”,
credit scoring: „odrzuć wnioski z zaległościami > 90 dni w ostatnim roku”,
lead scoring: „posortuj leady po wielkości firmy i dopasowaniu branży”.
Taki baseline trzeba zmaterializować w kodzie: odtworzyć reguły na historycznych danych, policzyć metryki. Nagle okazuje się, że „intuicyjny system” ma np. 85% precision w top-5% wniosków i sensowny model ML musi to przebić, a nie tylko „mieć lepszy AUC od losowego strzału”.
Losowy model i „zawsze przewiduj X”
Kolejny poziom to baseline’y statystyczne:
zawsze przewiduj klasę większościową (dla klasyfikacji),
zawsze przewiduj średnią / medianę (dla regresji),
losowa permutacja kolejności (dla rankingu).
Mogą wydawać się zbyt prymitywne, ale pokazują dolną granicę jakości. Jeżeli złożony model z wieloma cechami ledwo poprawia wynik „średnia z historii”, to problem nie leży już w algorytmie, tylko w danych, cechach albo etykietach.
Prognozy naiwne w szeregach czasowych
W prognozowaniu są trzy klasyczne baseline’y, które trzeba policzyć zawsze:
naive – prognoza na jutro = wartość z dziś,
seasonal naive – prognoza na przyszły tydzień = wartość z analogicznego dnia poprzedniego tygodnia,
moving average – np. średnia z ostatnich N dni/tygodni.
Te proste metody wykorzystują tylko strukturę czasową i potrafią być zaskakująco mocne, zwłaszcza przy stabilnych procesach. Zaawansowane modele, które nie przebijają sezonowego baseline’u, zwykle cierpią na źle przygotowane cechy (np. brak świąt, efektu weekendu) albo na błędny podział czasowy.
Baseline z minimalnym feature engineeringiem
Między regułami a „prawdziwym” ML jest miejsce na baseline’y z użyciem kilku prostych cech:
dla klasyfikacji: liczba logowań w ostatnich 7 dniach, suma zakupów, liczba ticketów do supportu,
dla regresji: ostatnia wartość, średnia z ostatnich 3–5 obserwacji, prosta różnica (trend).
Model może być dalej banalny (np. regresja liniowa, drzewo głębokości 3), ale już korzysta z bardziej bogatej reprezentacji danych. To dobry „krok zerowy” przed odpaleniem całej machiny featuringu i tuningu.
Źródło: Pexels | Autor: Laura Musikanski
Pierwszy sensowny model: baseline z klasy „prosty, ale już ML”
Dlaczego prosty model przewidziany do bicia ma być porządny
„Prosty baseline ML” to nie jest byle jaka regresja liniowa z domyślnymi parametrami. Chodzi o pierwszy model, którego nie wstyd byłoby produkcyjnie wdrożyć, gdyby nikt nie miał czasu na dalsze eksperymenty.
To oznacza:
poprawny podział danych (train/valid/test, bez przecieków czasowych),
sensowny zestaw cech z minimalną obróbką (missing values, kategoryki),
metody uczące się, które działają dobrze „z pudełka”: logistic regression, ridge/elastic net, drzewa decyzyjne, simple gradient boosting.
Minimalny feature engineering dla sensownego baseline’u
Zamiast od razu generować setki cech, lepiej zacząć od małej, przemyślanej paczki. Praktyczny zestaw startowy:
agregaty po czasie: liczba zdarzeń w ostatnich 7/30 dniach, średnia, maksimum, trend,
flagi: czy użytkownik logował się w ostatnim tygodniu, czy przekroczył próg X,
cechy relacyjne: liczba produktów na koszyk, liczba urządzeń na konto,
kategoryki zakodowane prostymi metodami: one-hot dla małych słowników, target encoding z ostrożnością (tylko na train, z walidacją K-fold).
Tak przygotowane cechy w połączeniu z prostym modelem zwykle dają baseline, który już „czuje” strukturę danych. Każdy kolejny model musi udowodnić, że wnosi coś ponad to.
Wybór algorytmu dla baseline’u ML
Dla większości klasycznych zadań nie ma sensu eksperymentować z egzotycznymi modelami na etapie baseline’u. Sprawdzają się:
logistic regression – szybka, dobrze kalibrowana probabilistycznie; świetna do klasyfikacji binarnej z dużą liczbą rzadkich cech,
linear/elastic net regression – dla regresji z dużą liczbą predyktorów; pozwala łatwo kontrolować overfitting,
drzewo decyzyjne o małej głębokości – interpretowalne, potrafi wychwycić kilka nieliniowych zależności,
gradient boosting (np. XGBoost, LightGBM, CatBoost) z domyślnymi parametrami – zaskakująco mocny baseline, zwłaszcza przy mieszanych typach cech.
Klucz: minimum tuningu. Kilka rozsądnych parametrów (głębokość, learning rate, liczba drzew) dobranych szybko na prostym gridzie lub random searchu. Nie ma sensu spędzać tygodnia na szlifowaniu baseline’u – wystarczy, że będzie stabilny i powtarzalny.
Stabilność baseline’u a losowość
Modele z losową inicjalizacją (np. lasy losowe, boosting) mogą dawać lekko różne wyniki przy każdym uruchomieniu. Jeśli baseline ma służyć jako punkt odniesienia dla miesięcy rozwoju, trzeba ograniczyć tę zmienność.
ustaw stały random seed,
zapisuj konfigurację modelu i wersję danych,
przelicz kilka razy (np. różne foldy walidacji) i raportuj średnią + odchylenie, a nie pojedynczą liczbę.
Dzięki temu nie będzie sytuacji, w której „nowy” model wydaje się lepszy tylko dlatego, że baseline miał pecha w danym losowaniu.
Projektowanie baseline’u pod konkretny typ zadania
Klasyfikacja binarna: od reguły do logistycznej regresji
Dla klasyfikacji binarnej sensowna ścieżka budowy baseline’u wygląda tak:
odtworzenie aktualnych reguł biznesowych i policzenie metryk,
model „zawsze klasa większościowa” i ewentualnie „losowy” dla dolnej granicy,
logistic regression na kilku prostych cechach agregujących zachowanie użytkownika lub historię obiektu,
niewielkie drzewo lub prosty boosting dla porównania.
Próg decyzyjny (np. od jakiego prawdopodobieństwa przewidujemy klasę pozytywną) dobiera się pod kątem kosztów błędów i tego, ile przypadków jesteśmy w stanie obsłużyć (np. ile leadów ma realnie zadzwonić dział sprzedaży). To element baseline’u – nie zostawia się go na „później, jak już będziemy mieli lepszy model”.
Klasyfikacja wieloklasowa: top-k accuracy i klasy „inne”
Przy większej liczbie klas pojawiają się dodatkowe problemy:
część klas jest bardzo rzadka – sensowny baseline powinien mieć kategorię „inne”, która zbiera ogon,
użytkownik często widzi listę podpowiedzi – metryka top-1 może być mniej ważna niż top-3 czy top-5.
Dobry baseline:
porównuje się z prostym modelem częstotliwości (zawsze przewiduj najczęstszą klasę lub N najczęstszych klas),
raportuje macro/micro F1 oraz top-k accuracy,
obsługuje klasy rzadkie tak, jak będzie to robił system produkcyjny (np. mapuje je do „inne”).
Regresja: medianowa wartość i model liniowy
W regresji rozsądna kombinacja baseline’ów to:
średnia i mediana na trainie jako predykcja stała,
średnia/mediana w segmencie (np. typ klienta, region, kategoria produktu),
regresja liniowa na kilku prostych cechach (agregaty historyczne, segmenty, flagi).
Taki zestaw daje szybki obraz: czy dodatkowe cechy i nieliniowości w ogóle są potrzebne. Czasem okazuje się, że sama segmentacja (np. rozdzielenie B2B/B2C) jest większym skokiem jakości niż przejście z regresji liniowej na wyrafinowany boosting.
Prognozowanie szeregów czasowych: jednostka prognozy ma znaczenie
horyzont (ile kroków naprzód, z jaką rozdzielczością czasową),
czy model ma być globalny (jedna prognoza dla wszystkich serii), czy osobny dla każdej serii.
Baseline można zbudować dwuetapowo:
proste prognozy naiwne i ruchome średnie per seria,
prosty model globalny (np. regresja liniowa/boosting) na cechach typu: wartość z poprzednich lagów, średnia z ostatniego tygodnia, dzień tygodnia, święto, sezon.
Już na tym etapie widać, czy globalny model ma sens, czy raczej procesy są zbyt różne między seriami i lepiej iść w osobne baseline’y per grupa.
Ranking i rekomendacje: popularność i współoglądalność
Dla rekomendacji sensowny baseline powinien odzwierciedlać to, co i tak robiłby prosty system:
globalna popularność – sortowanie po liczbie zakupów/odsłon w ostatnim okresie,
popularność w segmencie – osobna lista dla kraju, kategorii produktu, pory dnia,
współoglądalność (item-item) – „użytkownicy, którzy kupili X, kupili też Y”.
Metryki rankingowe dobrane do realnego użycia
W rankingach i rekomendacjach „dobra metryka” rzadko oznacza po prostu accuracy. Trzeba ją dopasować do tego, jak system jest używany:
CTR / konwersja – jeśli ranking steruje listą ofert czy artykułów, kluczowe jest, czy użytkownicy realnie wchodzą w interakcję z topowymi wynikami,
precision@k / recall@k – przy rekomendacjach produktów w koszyku liczy się jakość pierwszych kilku propozycji,
NDCG / MAP – gdy użytkownik przegląda dłuższą listę (np. wyniki wyszukiwania), liczy się zarówno trafność, jak i pozycja na liście.
Sensowny baseline rankingowy powinien być oceniany dokładnie tymi metrykami, na których będzie rozliczany system produkcyjny. „Model lepszy o 5% NDCG@10” ma znaczenie tylko wtedy, gdy @10 odpowiada faktycznej liczbie rekomendacji na stronie.
Jak zbudować pipeline baseline’owy, który da się łatwo rozwijać
Oddzielenie logiki od eksperymentów
Baseline najczęściej umiera, bo mieszają się w nim trzy światy: eksperymenty, featury i logika produkcyjna. Żeby to zatrzymać, dobrze jest od razu rozdzielić:
przygotowanie danych surowych – ekstrakcja z hurtowni, joiny, filtrowanie,
budowę cech – wszystko, co zamienia dane surowe na wektory wejściowe modelu,
trenowanie i ewaluację – modele, podziały, metryki.
Praktyka: trzy osobne moduły/skrypty, osobne konfiguracje. W efekcie wymiana modelu na lepszy nie wymaga przepisania całej ścieżki od zera.
Konfiguracja zamiast twardego kodowania
Pierwszy baseline jest zwykle „na szybko”. Ktoś koduje parametry w środku notebooka i nikt potem nie wie, co było ustawione. Lepiej już na starcie:
trzymać parametry modeli w plikach konfiguracyjnych (YAML/JSON),
opisać źródła danych i filtry w jednym miejscu,
spisywać zestaw cech (lista kolumn, typy, transformacje).
Dzięki temu:
łatwo porównać eksperymenty (diff dwóch plików konfiguracyjnych),
łatwiej przenieść baseline na inną wersję danych lub środowisko,
da się w prosty sposób dodać drugi model bez ruszania starego.
Artefakty, które trzeba wersjonować od pierwszego dnia
Żeby baseline naprawdę był bazą, musi dać się odtworzyć. Minimum:
snapshot danych użytych do trenowania i testu (lub deterministyczny query + znacznik czasu),
kod i konfiguracja modelu z dokładną wersją bibliotek,
wyniki metryk na ustalonym zbiorze testowym, zapisane razem z metadanymi (data, autor, git commit).
Nie trzeba od razu stawiać MLOps-owej machiny. Wystarczy prosty wzorzec: folder experiments/, w nim podkatalogi z datą i nazwą eksperymentu, a tam: config, logi, metryki, ewentualnie pickle modelu. Za pół roku ktoś z zespołu będzie mógł wrócić i zrozumieć, co dokładnie oznaczało „baseline_v2”.
Automatyzacja minimalnego przepływu
Ręczne odpalanie trzech notebooków zabija baseline po kilku tygodniach. Dobrze jest złożyć prosty pipeline:
skrypt do budowy datasetu (extract + transform + save),
skrypt do trenowania i zapisu modelu,
skrypt do ewaluacji na teście i raportu metryk.
Może to być makefile, task runner (np. tox, nox) czy prosty plik run.sh. Klucz, żeby jedna komenda typu make baseline potrafiła odtworzyć cały proces na świeżym środowisku.
Mały, ale spójny kontrakt predykcji
Jeśli baseline ma być wymienialny na lepsze modele, interfejs predykcji powinien być stały:
wejście – strukturę danych (kolumny, typy) trzeba opisać i pilnować,
wyjście – forma predykcji powinna być ustalona (np. score 0–1, label, ewentualnie explanations).
Nawet jeśli pierwszy baseline to prosty model z scikit-learn, opakowanie go w funkcję lub mały serwis z jasnym API oszczędzi bólu przy przejściu na kolejny model. Produkcja nie będzie musiała się dostosowywać za każdym razem.
Walidacja baseline’u: jak nie oszukać samego siebie
Stały zestaw danych testowych
Jeśli test zmienia się co eksperyment, porównanie z baseline’em jest iluzoryczne. Trzeba:
wydzielić twardy test set, zamrożony na dłuższy okres,
nie używać go do wyboru modelu ani tuningu (tylko do finalnego porównania),
nie mieszać danych z przyszłości do trenowania modeli historycznych.
W zadaniach czasowych dobrym wzorcem jest „rolling origin” – test to ostatnie tygodnie/miesiące, a trenowanie obejmuje tylko przeszłość. Baseline musi być zbudowany dokładnie w takiej samej konfiguracji jak każdy kolejny model.
Dobór schematu walidacji do problemu
Różne typy zadań wymagają różnych walidacji. Kilka praktycznych reguł:
dane niezależne i wymieszane (np. ankiety, pojedyncze transakcje) – zwykły K-fold albo prosty train/valid,
dane sekwencyjne lub czasowe – time-based split, bez mieszania przyszłości z przeszłością,
zadania per użytkownik/obiekt – grouped split, żeby ten sam użytkownik nie lądował w train i valid jednocześnie.
Sensowny baseline używa dokładnie tego samego schematu walidacji, co nowsze modele. W przeciwnym wypadku porównuje się jabłka z pomarańczami.
segmentację wyników – metryki per kraj, kanał, typ klienta, dzień tygodnia,
analizę przypadków skrajnych – kilka przykładów największych błędów.
Na tym etapie często wychodzi, że baseline „nie widzi” ważnej grupy (np. nowych klientów). To nie tylko sygnał do ulepszenia modelu, ale też jasny benchmark: nowy model ma poprawić wynik właśnie tam, a nie tylko w ogóle.
Kalibracja prognoz a decyzje biznesowe
Model może mieć wysokie AUC, ale źle skalibrowane prawdopodobieństwa. Dla baseline’u, który ma być punktem odniesienia, kalibracja bywa równie ważna, co „siła” modelu:
dla klasyfikacji – sprawdzenie reliability plots i Brier score, ewentualnie prosty Platt scaling lub isotonic regression na walidacji,
dla regresji – ocena, czy przedziały ufności (jeśli są) realnie pokrywają procent przykładowo deklarowany przez model.
Przykład z praktyki: zespół ma model churnowy z AUC „w okolicach 0.8”, ale prawdopodobieństwa są przesunięte – segment klientów z predykcją 0.2 churnu w rzeczywistości odchodzi dużo częściej. W takim scenariuszu „gorszy” model o AUC 0.77, ale z dobrą kalibracją, może lepiej wspierać decyzje (np. dobór progu do akcji ratunkowych). Dlatego baseline powinien pokazywać nie tylko ranking jakości, ale też jakość liczb samych w sobie.
Testy statystyczne i stabilność w czasie
Jeśli baseline ma żyć miesiącami, trzeba ocenić nie tylko średnią metrykę, ale i stabilność:
mierzenie metryk w rozbiciu na okresy (np. tygodnie, miesiące) i obserwacja dryfu,
prosty test statystyczny przy porównaniu modeli (np. test McNemary dla klasyfikacji, paired t-test dla MSE),
porównanie odchyleń – model z mniejszą wariancją wyników w czasie może być cenniejszy niż minimalnie lepszy średnio.
Nowy model bijący baseline o kilka dziesiątych punktu procentowego, ale z dużo większą zmiennością, nie zawsze jest wygraną. Dobry baseline pokazuje „minimum jakości” i „minimum stabilności”, które kolejne wersje muszą przeskoczyć.
Spójność między offline a online
Ostatnia pułapka: baseline świetny offline, a po wdrożeniu wyniki nie zgadzają się z oczekiwaniami. Powody są zwykle prozaiczne:
inna logika featuringu w produkcji niż w eksperymentach,
różne filtry danych (np. w online odpadają niektóre przypadki),
opóźnienia danych, przez co model widzi inną historię niż w trenowaniu.
Dlatego sensowny baseline ma:
wspólną bibliotekę cech dla offline i online (np. współdzielony moduł lub feature store),
mały shadow test – porównanie predykcji baseline’u offline i w produkcji na tym samym zestawie przykładów,
monitoring kilku prostych metryk w produkcji (rozkład score’ów, odsetek pozytywów, liczba predykcji dziennie).
Jeśli baseline przejdzie ten test spójności, staje się wiarygodnym punktem odniesienia. Każdy kolejny model musi nie tylko dawać lepsze metryki offline, ale też utrzymać (lub poprawić) zachowanie w warunkach rzeczywistych.
Kluczowe Wnioski
Baseline to świadomie zaprojektowany punkt odniesienia, który musi być istotny statystycznie i biznesowo; jeśli nowy model nie wygrywa z nim wyraźnie, nie ma sensu komplikować systemu.
Sensowny baseline pełni trzy role naraz: sanity check (czy dane i metryki mają sens), punkt startowy do iteracji oraz bezpiecznik przed nad-inżynierią, gdy prosty model działa tak dobrze jak skomplikowany.
Baseline musi być powtarzalny, przejrzysty i porównywalny z kolejnymi modelami (ta sama walidacja i metryki), inaczej nie nadaje się jako narzędzie do podejmowania decyzji.
Prosty baseline często w zupełności wystarcza jako model produkcyjny, jeśli spełnia cel biznesowy, jest tani w utrzymaniu i dobrze zrozumiały dla zespołu – nie ma obowiązku „przeskakiwać” go tylko z powodu mody na bardziej złożone algorytmy.
Brak baseline’u prowadzi do kosztownych projektów z przesadnie złożonymi modelami, których przewaga nad prostymi metodami (np. „taki sam popyt jak w zeszłym tygodniu”) okazuje się minimalna, gdy już ktoś ten baseline zbuduje.
Przed stworzeniem baseline’u trzeba doprecyzować cel biznesowy, typ problemu (klasyfikacja, regresja, ranking itd.) oraz decyzje podejmowane na podstawie predykcji, bo to one definiują sensowne metryki i sposób oceny.
Bez zrozumienia danych (rozkłady, braki, sezonowość) nawet najlepiej zaprojektowany baseline staje się ćwiczeniem akademickim, a nie praktycznym narzędziem do prowadzenia projektu ML.
