Data Science dla początkujących: jak zacząć bez matematyki wyższej

Scenka z życia i jasny cel: dlaczego chcesz wejść w Data Science bez matematyki wyższej

Szef prosi o raport: „Które kampanie przyciągają klientów, a które tylko spalają budżet?”. Masz Excela, dane i zero czasu na naukę równań. Brzmi znajomo? Da się wejść w Data Science dla początkujących bez matematyki wyższej – krok po kroku, narzędziowo, z małymi, mierzalnymi efektami.

Cel: w 90 dni zbudować praktyczną bazę, by samodzielnie wczytać dane, oczyścić je, narysować sensowne wykresy, policzyć miary statystyczne, zbudować pierwszy model uczenia maszynowego i zaprezentować efekt w notatniku lub prostym dashboardzie – bez dowodów, całek i równań na tablicy.

Najpierw pytania, które naprawdę masz w głowie

Krótka lista, którą warto mieć przed oczami. Na te kwestie odpowiadamy w procedurze i checklistach niżej:

• Czy da się zacząć bez wyższej matematyki? Jeśli tak – od czego konkretnie?
• Jakie narzędzia zainstalować, by nie utknąć na konfiguracji?
• Jak sprawdzić, czy dobrze rozumiem dane, zanim uruchomię „magiczny” algorytm?
• Jak wybrać pierwszy model i skontrolować, czy nie przegiąłem z dopasowaniem?
• Jakie projekty do portfolio mają sens, gdy dopiero startuję?
• Jak mierzyć postępy w 30/60/90 dni i nie zgubić motywacji?
• Jakie błędy najczęściej popełniają początkujący bez zaplecza matematycznego i jak ich uniknąć?

Mapa drogi: 10 kroków, by zacząć bez matematyki wyższej

Krok 0: Ustal użytek biznesowy

Wybierz 1–2 scenariusze, które realnie ci się przydadzą. Przykłady: przewidywanie odpływu klientów, prognozowanie sprzedaży, segmentacja klientów, klasyfikacja zgłoszeń do kategorii. Jasny scenariusz wyznacza kierunek nauki, dane, metryki i kryteria decyzji.

Krok 1: Wybierz narzędzia niskotarciowe

Na start: Python, Jupyter/Colab, pandas, scikit-learn, matplotlib/seaborn. Zero kompilacji, gotowe do eksperymentów. Opcjonalnie: SQL do prostych ekstrakcji.

Krok 2: EDA – eksploracja danych bez równań

Ucz się patrzeć na dane: brakujące wartości, rozkłady, korelacje, wartości odstające. To połowa sukcesu. Proste wykresy i zdrowy rozsądek chronią przed 80% błędów.

Krok 3: Prosty baseline i walidacja

Ustal punkt odniesienia: dummy model (np. zawsze przewiduje średnią lub najczęstszą klasę), dziel dane na zbiory uczący/testowy, licz uczciwe metryki. Dopiero potem ulepszaj.

Krok 4: Pierwszy model „z pudełka”

Użyj gotowych algorytmów: regresja liniowa, drzewa decyzyjne, las losowy, regresja logistyczna. Skup się na wejściu/wyjściu, transformacjach i interpretacji metryk – nie na wyprowadzaniu wzorów.

Krok 5: Prezentacja wyników

Notebook z narracją, wykresami i wnioskami. Krótki raport tekstowy z rekomendacją i wymienionymi ograniczeniami. To realnie bardziej wartościowe niż ładny kod bez historii.

Krok 6: Małe iteracje

Po jednej zmianie naraz: imputacja braków, inna metryka, prostszy model, bardziej użyteczne cechy. Każdą zmianę oceniaj na tym samym zbiorze walidacyjnym.

Krok 7: Projekt do portfolio

Wybierz problem, dane, zrób cleanup, baseline, model, krótką narrację, repo na GitHub i linkowalny notebook. Nadaj projektowi tytuł mówiący o efekcie.

Krok 8: Rozszerzenia bez teorii

NLP i obrazy przez gotowe pipeline’y: zero trenowania od zera. Rozsądnie podejdź do wydajności i prywatności danych.

Krok 9: Plan 30/60/90 dni

Na koniec znajdziesz szczegółową checklistę działań i kryteriów zaliczenia etapów. Mierz postępy, nie czas nauki.

Role i ścieżki bez matematyki wyższej: jaką „czapkę” zakładasz

Analityk danych z akcentem na biznes

Priorytet: czyszczenie danych, wizualizacja, proste modele predykcyjne, story z danymi. Narzędzia: Excel/SQL + Python/pandas + matplotlib/seaborn + scikit-learn. Matematyka: intuicje, średnie, mediany, rozkłady, podstawy korelacji i błędów pomiaru.

„Citizen data scientist” w zespole produktowym

Priorytet: szybkie prototypy, A/B testy, rekomendacje z gotowych bibliotek, integracja z produktami (np. webhooki, API). Matematyka: rozumienie metryk i granic modeli. Często wystarczy gotowy pipeline i selekcja sensownych cech.

Praktyk ML „hands-on” bez teorii

Priorytet: pipeline’y, walidacja krzyżowa, monitoring metryk, prosty deployment. Matematyka: minimum konieczne do wyboru metryk, odróżnienia overfittingu od underfittingu i rozumienia błędu generalizacji.

Środowisko pracy: instalacja bez tarcia i szybkie testy

Szybki start z Google Colab (zero instalacji)

• Wejdź do Colab, utwórz nowy notatnik.
• Wczytaj CSV z dysku lub przez link.
• Przetestuj 3 polecenia: import pandas, df.head(), df.describe().

Instalacja lokalna: Anaconda + VS Code lub JupyterLab

• Pobierz Anacondę, utwórz środowisko: conda create -n ds python=3.11
• Zainstaluj: pandas, numpy, matplotlib, seaborn, scikit-learn, jupyterlab.
• Otwórz JupyterLab: jupyter lab – sprawdź, czy działa.

Kontrola jakości instalacji: checklista

• W notatniku wykonaj: import numpy, pandas, sklearn; bez błędów?
• Wczytaj mały CSV i narysuj histogram – czy widać wykres?
• Uruchom train_test_split i stwórz prosty model – czy się trenuje?

Porównanie narzędzi na start

Fundament: Python i pandas bez „teoretyzowania”

Minimalny zestaw Pythona dla Data Science

• Struktury: listy, słowniki, zbiory, krotki – do operacji na cechach i mapowaniach.
• Pętle i list comprehensions – szybkie transformacje.
• Funkcje – enkapsulacja powtarzalnych kroków (np. czyszczenie jednej kolumny).
• Moduły – import bibliotek i praca z API.

pandas w praktyce: 80% użycia, 20% funkcji

• Wczytywanie: read_csv, read_excel, to_csv
• Podgląd: head, info, describe, value_counts
• Czyszczenie: dropna, fillna, astype, replace
• Filtrowanie i wybór: loc, iloc, query
• Agregacje: groupby, agg, pivot_table
• Łączenie danych: merge, concat

EDA w praktyce: szybka procedura oceny danych

Plik od sprzedaży ma 120 MB, spotkanie za 40 minut. Pytanie pada wprost: „Możemy na tym cokolwiek policzyć dziś?”. Zamiast paniki — krótki przegląd jakości danych.

Procedura 15–30 minut

1. Wczytaj i policz podstawy: wiersze, kolumny, typy, odsetek braków na kolumnę.
2. Oznacz typy cech: numeryczne, kategoryczne, daty, identyfikatory (ID nie wchodzą do modelu).
3. Szybkie podglądy: head(), sample(5), value_counts() dla głównych kategorii.
4. Rozkłady i anomalie: histogramy dla liczb, liczność kategorii, boxploty pod outliery.
5. Target pod lupą: balans klas (klasyfikacja) lub zakres i skośność (regresja).
6. Zależności „na szybko”: korelacje liczbowe, tabele krzyżowe target × główne kategorie.
7. Wydzielenie zbiorów: train/test zanim cokolwiek liczysz (np. 80/20 z losowym seedem).

Wyjście z EDA: checklista jakości

• Wiesz, które kolumny są bezużyteczne (ID, stałe, duplikaty pola).
• Masz listę kolumn z >20% braków i strategię: usunąć/uzupełnić.
• Znasz balans klas i plan metryki (np. F1 zamiast accuracy przy nierównych klasach).
• Masz 3–5 hipotez do sprawdzenia (np. „kanał A ma wyższy churn niż B”).
• Zapisany seed i podział danych — nie zmieniasz go w kolejnych iteracjach.

Ostrzeżenia

• Nie licz korelacji na danych połączonych z testem — grozi przeciekiem informacji.
• Nie wnioskuj z jednego wykresu. Szukaj potwierdzeń w 2–3 spojrzeniach na dane.

Wniosek: EDA to bramka bezpieczeństwa — zanim uruchomisz model, wiesz, co psuje dane i jak to obejść.

Czyszczenie i przygotowanie danych: plan operacyjny

W kolumnie „cena” masz „—”, „brak” i „0”. W dacie: dwa formaty. To klasyka. Porządki robimy raz, ale porządnie — w pipeline’ie.

Kolejność działań

1. Standaryzacja braków: zamień „”, „—”, „NA”, „brak” na prawdziwe NaN.
2. Typy danych: liczby na float/int, daty na datetime, kody na string.
3. Daty na cechy: wyciągnij rok/miesiąc/dzień tygodnia, policz różnice (np. dni od rejestracji).
4. Duplikaty: usuń duplikaty wierszy lub zdefiniuj regułę agregacji.
5. Outliery: zdefiniuj politykę (ucięcie percentyli, winsoryzacja lub zostawienie — ale świadomie).
6. Kategorie: one-hot dla małej krotności, rzadkie kategorie scal do „innych”.
7. Skalowanie: tylko gdy model tego potrzebuje (regresja/logistyczna, kNN, SVM) — StandardScaler/MinMaxScaler.
8. Pipeline: zbuduj ColumnTransformer + Pipeline, żeby te same kroki działały na train/val/test identycznie.

Checklista „gotowe do modelu”

• Braki uzupełnione lub kolumny świadomie usunięte; spis decyzji dodany do notatnika.
• Brak przecieków: cechy liczone wyłącznie z danych dostępnych w momencie prognozy.
• Stabilne typy: brak liczby zapisanej jako tekst i odwrotnie.
• Transformacje zamknięte w pipeline’ie; fit wyłącznie na treningu, transform na walidacji/test.

Ostrzeżenia

• Imputacja średnią na zmiennej o skośnym rozkładzie zniekształci dane — użyj mediany.
• Encoding kategorii połączony z targetem (np. target encoding) łatwo przecieka — stosuj z cross-foldem lub odpuść na start.

Wniosek: czyszczenie bez pipeline’u to proszenie się o niespójności między treningiem a produkcją.

Walidacja i metryki bez teorii: jak nie oszukać siebie

Model krzyczy „98% accuracy”, ale wszyscy klienci zostali oznaczeni jako nieodchodzący. Papier zniesie wszystko; walidacja — nie.

Dobór walidacji do problemu

• Dane niezależne w czasie: prosty podział train/val/test lub stratified k-fold (klasyfikacja).
• Szeregi czasowe: walidacja rolowana (TimeSeriesSplit), żadnego mieszania przeszłości z przyszłością.
• Mało danych: k-fold 5–10, ale trzymaj oddzielny finalny test bez dotykania.

Wybór metryk w praktyce

• Klasyfikacja z równym balansem: accuracy + F1.
• Klasy nierówne: F1 lub ROC-AUC; przy ograniczonych zasobach działania — precision@k/recall@k.
• Regresja: MAE (łatwo wytłumaczyć w jednostkach), RMSE (gdy duże błędy bolą bardziej), unikaj MAPE przy zerach.

Reguły zdrowego rozsądku

• Miej baseline (dummy). Nowy model powinien przebić go o sensowny margines (np. ≥5–10% względnie w głównej metryce).
• Sprawdzaj rozjazd train vs val. Duży gap = overfitting, mały i słaby wynik = underfitting.
• Raportuj niepewność: średnia i odchylenie metryki z k-fold, nie jeden „złoty” wynik.

Ostrzeżenia

• Nie dobieraj metryki pod „ładny” wynik. Dobierz ją pod decyzję biznesową.
• Nie tuninguj na teście. Test dotykasz raz — na końcu.

Wniosek: metryka to kompas; bez niej nawet szybki progres bywa ruchem w złym kierunku.

Pierwsze modele: wzorce użycia i kryteria wyboru

Masz 5 tys. wierszy, kilkanaście kolumn i mało czasu. Chcesz modelu, który „po prostu działa” i daje sygnały, co poprawić.

Dobór modelu do zadania

• Regresja (sprzedaż, czas dostawy): LinearRegression/Lasso na start; gdy nieliniowo — RandomForestRegressor.
• Klasyfikacja (churn, lead scoring): LogisticRegression (z regularizacją) lub RandomForestClassifier.
• Nierówny target: ustaw class_weight=’balanced’ lub zrób prosty undersampling/oversampling na walidacji.
• Tekst krótki (tytuły, opisy): TfidfVectorizer + LogisticRegression; limit cech, usuń stopwords.
• Szereg czasowy: naive (ostatnia wartość), średnia krocząca, prosty Prophet/ETS jako rozsądny próg wejścia.

Minimalny tuning, który ma sens

• Drzewa/las: max_depth (np. 5–15), n_estimators (100–300), min_samples_leaf (1–10).
• Regresja/logistyczna: C (siła regularizacji), penalty (l2), standardyzacja cech przed treningiem.

Eksperymenty i śledzenie: porządek zamiast „który notebook to był?”

Model z wczoraj dawał lepsze wyniki, ale nie pamiętasz, na jakich parametrach. Szef pyta o powtarzalność. Telefon zaczyna dzwonić częściej niż kernel się restartuje.

Procedura pracy nad eksperymentami

1. Ustal konwencję nazw: projekt, data, cel. Przykład nazwy runu: lead_scoring_2026-07-13_baseline_v1.
2. Zamroź dane wejściowe: zapisuj ścieżkę i sumę kontrolną pliku (md5) lub commit z repozytorium danych.
3. Ustaw random_state we wszystkich krokach (podział, modele, samplowanie).
4. Zdefiniuj baseline i jedną główną metrykę — reszta to pomocnicze.
5. Loguj parametry i metryki do jednego miejsca: MLflow/Weights & Biases lub przynajmniej CSV z kolumnami run_id, params, metric_main, metric_aux....
6. Zapisuj artefakty: model (.joblib), scaler/encoder, requirements.txt, wersję Pythona.
7. Każdy „lepszy” run porównaj na tym samym zbiorze walidacyjnym. Zapisz różnicę względem baseline (np. +0.06 F1).
8. Najlepszy run taguj jako candidate_production i otaguj commit w Git.

Checklista „czy odtworzysz wynik jutro”

• Seed ustawiony i zapisany.
• Ścieżka + checksum danych zapisane.
• Parametry modeli i transformacji zlogowane.
• Wersje bibliotek i Pythona dołączone.
• Zachowany pipeline (preprocessing + model) jako jeden artefakt.

Ostrzeżenia

• „Niewinne” zmiany w preprocessingu bez re-fit mogą pogorszyć wynik — trzymaj wszystko w jednym Pipeline.
• Nie mieszaj wyników z różnych foldów bez standardu (średnia + odchylenie to minimum).

Interpretacja bez równań: co naprawdę napędza wynik

Prezes chce wiedzieć „dlaczego model tak decyduje”, a nie „że ma 0.84 ROC-AUC”. Na slajdzie musi się zmieścić sedno.

Procedura diagnozy wpływu cech

1. Permutation importance na zbiorze walidacyjnym: kolejność 5–10 najważniejszych cech, różnica w metryce po permutacji.
2. Partial Dependence/ICE dla 2–3 kluczowych cech liczbowych: pokaż kierunek wpływu (rosnący/malejący, punkty załamania).
3. Modele drzewiaste: SHAP summary plot do weryfikacji stabilności top-cech (opcjonalnie — wystarczy na walidacji).
4. Regresja/logistyczna: standaryzuj cechy i odczytaj współczynniki (znak i rząd wielkości).
5. Klasyfikacja: przesuń próg decyzyjny, narysuj krzywą precision–recall, wybierz próg pod ograniczenia operacyjne (np. maks. 50 leadów dziennie).
6. Sprawdź grupy: metryki per segment (kanał, region, typ klienta). Duże rozjazdy = ryzyko błędów systematycznych.

Szybkie decyzje na bazie interpretacji

• Cecha ważna, ale niestabilna między foldami → zbadaj jej jakość lub wytnij z v0.
• Płaska zależność PD → cecha nie wnosi sygnału w obecnym modelu.
• Silna nieliniowość → rozważ drzewa/las/GBM zamiast liniowego modelu.

Ostrzeżenia

• Permutation importance w obecności silnie skorelowanych cech bywa myląca — rozważ grupowanie/odrzucenie duplikatów informacji.
• SHAP licz na walidacji, nie na treningu — inaczej „wyjaśniasz” overfitting.

Od notatnika do użycia w firmie: lekkie wdrożenie bez DevOpsu

Handlowcy proszą o listę „top 50” szans na jutro. Nie potrzebują serwera, tylko pliku do pracy.

Kroki do wersji „batch v0”

1. Zamknij preprocessing i model w jednym Pipeline.
2. Zapisz artefakt: joblib.dump(pipeline, "model_v0.joblib") i numer wersji.
3. Napisz skrypt wsadowy: wczytuje CSV, stosuje pipeline.predict_proba, dokleja wynik, sortuje i zapisuje top-k do nowego CSV.
4. Dodaj walidacje wejścia: kontrola kolumn, typów, proste reguły (np. zakresy).
5. Zapewnij konfigurację poza kodem: config.yaml (ścieżki, progi, kolumny obowiązkowe).
6. Uruchom w CRON/Task Scheduler raz dziennie; loguj status i rozmiar pliku wyjściowego.

Checklista wydania „v0”

• Artefakt modelu + wersja + checksum.
• Opis wejścia/wyjścia (kolumny, typy, przykład wiersza).
• Seed, metryka z walidacji, data treningu, zakres danych.
• Prosty monitoring: średnia/odchylenie predykcji dziennie, odsetek braków, drift top-cech (porównanie do rozkładu z treningu).

Ostrzeżenia

• Nie ładuj obcych pickli — bezpieczeństwo. Artefakty tylko z zaufanego repo.
• Zmiana schematu danych wejściowych bez wersjonowania = niereprodukowalność wyników.

Raport, który przechodzi przez spotkanie

Masz 12 minut na status. Decydenci chcą wiedzieć „co robimy inaczej jutro”, nie „jak piękny jest wykres rozkładu”.

Struktura 1-pagera

• Cel: jedno zdanie z decyzją, jaką raport wspiera.
• Dane: źródła, zakres czasu, liczebność, najważniejsze ograniczenie.
• Metoda: 2–3 punkty (model, walidacja, metryka główna).
• Wynik: liczba + porównanie do baseline + niepewność (średnia ± odchylenie).
• Rekomendacja: próg, lista działań, wpływ operacyjny (np. ile rekordów dziennie do kontaktu).
• Ryzyka i następny krok: jedna rzecz do poprawy, termin.

Wizualizacje obowiązkowe

• Confusion matrix/PR-curve dla klasyfikacji lub wykres rzeczywiste vs przewidywane dla regresji.
• Top-cechy (permutation importance) — wykres poziomy z wartościami.
• Stabilność między foldami — słupki z wynikiem na fold.

Kontrola jakości przed wysyłką

• Sprawdź spójność liczb między slajdami i notatnikiem.
• Podaj datę, wersję modelu, seed i link do runu/artefaktu.
• Usuń z raportu elementy nieakcyjne — zostaw to, co zmienia decyzję.

Plan 30 dni: bez matematyki wyższej, z wynikami

Chcesz namacalnego progresu w miesiąc. Bez miliona kursów, z jednym mini‑projektem dowiezionym do końca.

Tydzień 1 — narzędzia i EDA

1. Setup: Colab lub Jupyter, utwórz repo i struktury katalogów (data/, notebooks/, models/).
2. EDA na publicznym zbiorze (np. sprzedaż/marketing): profil braków, typów, rozkładów.
3. Decyzje danych: lista kolumn do usunięcia/uzupełnienia + plan metryki.

Rezultat: notatnik EDA + checklista jakości.

Tydzień 2 — przygotowanie i baseline

1. Pipeline czyszczenia: imputacja, kodowanie, skalowanie tam, gdzie trzeba.
2. Baseline: dummy + prosty model (logistyczna/liniówka), stabilna walidacja.
3. Logowanie eksperymentów: CSV lub MLflow.

Rezultat: pierwszy model przebijający baseline z opisem decyzji.

Tydzień 3 — szybki tuning i interpretacja

1. Siatka 3–5 sensownych parametrów (bez grzebania w setkach kombinacji).
2. Permutation importance + 2 wykresy PD/ICE.
3. Dobór progu pod realne ograniczenia (np. 50 leadów dziennie).

Tydzień 4 — wdrożenie „light” i pętla zwrotna

Oddajesz pierwszy plik do działu operacji. Po godzinie wraca informacja: „Brakuje kilku ID, a nazwy kolumn inne niż w szablonie”. Nie rób nowej wersji „na szybko” — ustaw standard, żeby kolejny plik był przewidywalny.

1. Cel tygodnia: zaakceptowany batch z jasnymi kryteriami jakości i pętla feedbacku.
2. Uzgodnij kontrakt danych (Data Contract):
   • Wejście: nazwy kolumn, typy, wymagane pola, dopuszczalne braki.
   • Wyjście: nazwa pliku, kolumny (id, score, score_rank, model_version, scored_at), kodowanie (UTF‑8), separator.
3. Test akceptacyjny na próbce:
   • Weź 100 wierszy z realnych danych, uruchom pipeline, porównaj do szablonu.
   • Kryteria „pass”: 0 błędów walidacji, 100% wymaganych kolumn, brak pustych id, rozkład score sensowny (bez samych 0/1).
4. Tryb shadow na 1–2 cykle:
   • Równolegle generuj plik „do szuflady” i zapisuj wyniki rzeczywiste, gdy się pojawią.
   • Policz precision@k i prosty drift (średnia/odchylenie top‑cech vs trening).
5. Ustal progi operacyjne z biznesem:
   • Pytania kluczowe: ile rekordów dziennie realnie obsłuży zespół? jaki minimalny zysk na rekord?
   • Reguła: jeśli k > zdolność operacyjna → podnieś próg; jeśli precision@k spada poniżej ustalonego minimum → wróć do analizy cech.
6. Rytm utrzymania:
   • Harmonogram retreningu (np. co 4–8 tygodni) lub gdy drift > próg.
   • Jedna osoba odpowiedzialna za „cięcie” wersji: wersja, data, zakres danych, link do runu.

Checklista odbioru od biznesu

• Plik ma stały format, nazwy i typy zgodne z kontraktem.
• Top‑k = zdolność operacyjna ±10%.
• precision@k na shadow ≥ uzgodniony próg.
• Opis pola score (interpretacja) i prosty przewodnik „co zrobić z wynikiem”.

Ostrzeżenia operacyjne

• Zmiana nazwy kolumny przez źródło = cichy błąd. Waliduj schemat przed predykcją i zatrzymuj run z komunikatem.
• Nie mierz skuteczności na rekordach, które nie miały szansy być obsłużone (bias selekcyjny). Oznaczaj status obsługi.

Minimalny zestaw narzędzi: wybierz po jednym z każdej półki

Masz otwartych 12 zakładek z porównaniami narzędzi. Ustal proste kryterium: działa lokalnie, ma dokumentację i nie blokuje wdrożenia w v0.

• Notebook: Jupyter lub Colab — jeśli potrzebujesz GPU/udostępniania bez instalacji, bierz Colab; do pracy z repo lokalnie — Jupyter.
• Dane: pandas na start; jeśli tabele > kilka mln wierszy i ogranicza RAM — Polars.
• Wizualizacja: seaborn do EDA; Plotly Express, gdy trzeba interakcji w raporcie.
• Modelowanie: scikit‑learn jako domyślny; XGBoost/LightGBM dopiero, gdy las/RegLog nie wyrabia.
• Śledzenie eksperymentów: MLflow (serwer lokalny) albo CSV + konwencja nazw runów.
• Paczka i wersjonowanie: pip + requirements.txt na start; Poetry, gdy pojawią się zależności binarne i środowiska.
• Walidacja danych: prosty assert + słownik reguł, a następnie Pandera, gdy reguł rośnie.
• Harmonogram: CRON/Task Scheduler; GitHub Actions, jeśli źródła są w repo i batch może biec w chmurze.
• Dokumentacja: README.md + 1‑pager decyzji + szablon raportu.

Małe decyzje, które rozstrzygają wybór

• Offline i Windows w dziale? Zostań przy Jupyter + CRON, unikaj egzotycznych bibliotek.
• Współdzielone środowisko? MLflow na wspólnym serwerze lub W&B, żeby nie mnożyć CSV.
• Wiele źródeł danych? Dodaj warstwę ekstrakcji (np. proste extract.py) i loguj wersje zapytań SQL.

Ostrzeżenia narzędziowe

• Mieszanie wersji Pythona między maszynami kończy się „działa u mnie”. Spisz i przypnij wersje (plik requirements.txt + python==X.Y).
• „Szybka” przesiadka na nowe narzędzie w połowie projektu zjada czas na migrację, nie na wynik. Zmieniaj po zakończeniu iteracji.

Gotowość do komercyjnego mini‑projektu: test samosprawdzający

Telefon z pierwszą płatną prośbą: „Czy jesteście w stanie dowieźć pilota w 3 tygodnie?”. Sprawdź, czy spełniasz poniższe punkty — bez egzotycznej matematyki.

• Jest baseline i przewyższenie o X (uzgodnione, np. F1 +0.05) na powtarzalnej walidacji.
• Eksperymenty da się odtworzyć: seed, dane, parametry, wersje bibliotek.
• Pipeline łączy preprocessing i model; jeden artefakt do ładowania.
• Metryka główna powiązana z decyzją (np. precision@k zamiast samego ROC‑AUC).
• Raport 1‑pager istnieje i zawiera rekomendację operacyjną.
• Walidacja wejścia łapie brak kolumn i nietypowe zakresy.
• Monitoring prosty, ale działa: rozkłady cech i średni score vs trening, alert na odchylenie.
• Prawa do danych i licencji bibliotek są wyjaśnione (brak blokad na komercyjne użycie).

Najczęstsze potknięcia początkujących i szybkie remedia

Dwa pytania przewijają się najczęściej: „Dlaczego wynik się pogorszył?” i „Czemu plik nie przechodzi walidacji?”. Poniżej skrót odpowiedzi „co kliknąć”, zanim zaczniesz szukać złożonych przyczyn.

• Objaw: wynik gorszy po „drobnej” zmianie notatnika.
  • Naprawa: wciągnij preprocessing do Pipeline, przypnij random_state, policz wynik na tym samym foldzie.
• Objaw: metryka rośnie na treningu, stoi na walidacji.
  • Naprawa: zaostrz walidację (GroupKFold/TimeSeriesSplit), zmniejsz złożoność modelu, dodaj regularizację lub wczesne stopowanie.
• Objaw: plik wsadowy odrzucony przez biznes.
  • Naprawa: dodaj test kontraktu w skrypcie; jeśli test nie przejdzie, pipeline przerywa i wypisuje, które pola/typy są niezgodne.
• Objaw: cecha „top1” raz jest wysoko, a raz nisko.
  • Naprawa: sprawdź stabilność między foldami; jeśli niestabilna, zbadaj brakujące wartości/rozrzut i ewentualnie wyklucz w v0.
• Objaw: dobre ROC‑AUC, słaby efekt operacyjny.
  • Naprawa: dobierz próg pod precision@k i budżet działań; pokaż PR‑curve, nie tylko ROC.

Checklisty „przed / w trakcie / po” jednym rzutem oka

Przed startem

• Cel decyzji i jedna metryka uzgodnione.
• Źródło danych, zakres czasu, minimalna liczebność.
• Struktura repo i konwencja nazw runów gotowe.

W trakcie

• Baseline policzony; walidacja stabilna.
• Eksperymenty logowane w jednym miejscu.
• Top‑cechy i PD/ICE dla 2–3 zmiennych zinterpretowane.

Po

• Artefakt modelu z wersją i checksum.
• Skrypt batch + walidacja schematu.

Metryka i próg bez wzorów: decyzja → liczba → plik

Masz ROC‑AUC 0.86, a szef pyta: „Ile telefonów dziennie i z jaką skutecznością?”. Cyferka z notatnika nie przekłada się na kolejny krok operacyjny — trzeba jasno wskazać próg i liczbę rekordów.

1. Zacznij od decyzji i ograniczenia:
   • Decyzja: „kontaktujemy / nie”, „przyznajemy / odrzucamy”, „które rekordy idą do ręcznego sprawdzenia”.
   • Ograniczenie: dzienna zdolność (np. 50 rekordów), minimalny zysk/rekord, SLA czasu.
2. Dobierz metrykę pod decyzję (bez żargonu):
   • Limit miejsc (ranking): precision@k lub hit@k — ile trafień w top‑k.
   • Filtr binarny (bez limitu): precision/recall z docelową równowagą (np. „wolimy mniej fałszywych trafień” → precision).
   • Regresja (wielkość, nie decyzja): MAE i „błąd względny” (np. MdAPE) po ucięciu skrajności (winsoryzacja 1–5%).
   • Anomalie: liczba sensownych przypadków w top‑N + szybka weryfikacja ręczna 20 rekordów.
3. Ustal próg w 3 krokach:
   • Posortuj rekordy po score, wybierz top‑k = zdolność operacyjna.
   • Policz precision@k na walidacji; jeśli poniżej progu — wróć do cech/baseline.
   • Gdy brak stałej zdolności: zbuduj mapę „próg → liczba rekordów → precision”, wybierz punkt z akceptowalnym kompromisem.
4. Spisz warunki sukcesu przed raportem:
   • „Akceptujemy, jeśli precision@k ≥ X i k mieści się w ±10% zdolności”.
   • Dla regresji: „MAE ≤ Y, a 80% błędów względnych ≤ Z%”.
5. Raportuj w formacie operacyjnym:
   • Jedna linia: „Top‑k=50, precision@k=0.42, próg=0.71, wersja=model_2024‑09‑12”.
   • Załącz wykres: krzywa precision@k lub dystrybucja score z zaznaczonym progiem.

Mini‑checklista metryk

• Czy metryka wynika z decyzji, a nie z „tego, co ładnie wygląda”?
• Czy próg/przedział został policzony na walidacji, a nie na treningu?
• Czy wynik da się przełożyć na liczbę rekordów i plan dnia zespołu?

Ostrzeżenia przy wyborze metryk

• Wysokie ROC‑AUC nie gwarantuje dobrego precision@k przy małym k. Zawsze pokaż krzywą precision@k.
• F1 bywa mylące przy silnej nierównowadze klas; gdy liczy się precyzja w top‑N, użyj precision@k.
• MAPE eksploduje dla wartości bliskich 0. Użyj MdAPE i dolnego progu wartości (np. y > 1), albo raportuj MAE w jednostkach biznesowych.

Szablon repozytorium i uruchomienie end‑to‑end w 30 minut

Operacje proszą o powtórkę scorowania sprzed miesiąca. Notatnik się nie uruchamia, brakuje bibliotek i nikt nie pamięta parametrów. Standard repo rozwiązuje 90% takich sytuacji.

1. Ustal strukturę katalogów:
   • notebooks/ — tylko eksploracja, bez „magii” produkcyjnej.
   • src/ — kod: data.py, features.py, model.py, inference.py.
   • configs/ — train.yaml, score.yaml (ścieżki, parametry, próg).
   • artifacts/ — zapisany model, encodery, checksumy.
   • reports/ — EDA, metryki, wykresy.
2. Dodaj dwa punkty wejścia:
   • python -m src.train --config configs/train.yaml
   • python -m src.score --config configs/score.yaml --input data/batch.csv --output out/scores.csv
3. Spisz środowisko i wersje:
   • requirements.txt + python==3.10 w README.md.
   • Komenda instalacyjna: python -m venv .venv && .venv/Scripts/activate|source .venv/bin/activate && pip install -r requirements.txt.
4. Wprowadź konfigurację zamiast „magicznych liczb”:
   • Parametry modelu, ścieżki danych, random_state, threshold — w YAML.
   • Wersja modelu generowana ze znacznika czasu lub taga z Gita.
5. Wyjścia, które muszą powstać po uruchomieniu:
   • reports/metrics.json — metryki walidacyjne z datą i seede’em.
   • artifacts/model.pkl + artifacts/preprocess.pkl — jeden pipeline do ładowania.
   • out/scores.csv — zgodny z kontraktem danych (kolumny + UTF‑8).

Lista kontrolna repo

• README.md zawiera 3 komendy: instalacja, trening, scoring.
• Każdy run zapisuje wersję bibliotek i random_state.
• Brak importów z notebooks/ w kodzie produkcyjnym.
• Test kontraktu danych uruchamia się przed score i przerywa run przy błędzie.

Od skorowania do małej aplikacji: „czy to da się kliknąć?”

Szef zostawia na biurku CSV i pyta: „Da się to ocenić i wypluć 50 rekordów do kontaktu jeszcze dziś?”. Brzmi jak presja, ale to dobry test — nie modelu, tylko używalności. Szybka aplikacja pozwala przejść od notebooka do przycisku „Uruchom”.

• Najprostsza ścieżka: Streamlit.
  • Ekrany: upload pliku, podgląd 20 wierszy, suwak progu lub pole „k”, przycisk „Oblicz”, podgląd top‑k i przycisk „Pobierz CSV”.
  • Technicznie: ładujesz zapisany Pipeline z artifacts/, stosujesz preprocessing i predykcję, a potem filtrujesz według progu lub wybierasz top‑k.
  • Dodaj mini‑log: data, wersja modelu, liczba wejściowych rekordów, wybrany próg/k, nazwa pliku wejściowego.
• Alternatywa dla integracji: proste API.
  • FastAPI z dwoma endpointami: POST /score-batch (CSV → CSV) i GET /health.
  • Walidacja schematu na wejściu; przy błędzie zwróć listę brakujących kolumn i typów.
• Małe decyzje z dużym wpływem:
  • Nie zapisuj wyników w tym samym katalogu co wejście; trzymaj „wejścia” i „wyjścia” osobno.
  • Dodaj kontrolkę „wersja modelu” i wymuś potwierdzenie przy zmianie.
  • W trybie demo trzymaj limity (np. max 20k wierszy) i jasny komunikat o ograniczeniach.

Miniwniosek: aplikacja nie musi być piękna, ma być przewidywalna. Gdy operacje mogą same uruchomić scoring i dostać plik zgodny z kontraktem, temat „czy to działa?” znika z agendy.

Nauka bez matematyki wyższej: plan 4 tygodnie

Wieczór, 45 minut między kolacją a serialem. Laptop, CSV z pracy i cel: „chcę to policzyć bez wzorów”. Z takim rytmem da się przejść od zera do pierwszego, sensownego pipeline’u.

Tydzień 1 — dane i nawyki

• Python + pandas: read_csv, typy kolumn, brakujące wartości, groupby, merge, value_counts, describe.
• Mini‑kontrakt danych: lista obowiązkowych kolumn, dozwolone wartości, próg braków, prosty test w skrypcie.
• Zadanie: policz 3 proste agregacje, zapisz do reports/eda.md 5 wniosków i 2 hipotezy na cechy.

Tydzień 2 — baseline i walidacja

• Podział czasu/grup zamiast losowego, jeden baseline: drzewo lub regresja logistyczna w Pipeline.
• Jedna metryka dobrana do decyzji i spójny random_state.
• Zadanie: policz baseline + precision@k lub MAE, zapisz do reports/metrics.json.

Tydzień 3 — cechy bez wzorów

• Kategorie: OneHotEncoder lub TargetEncoder z walidacją w KFold (żeby nie „przeciekało”).
• Daty: różnice w dniach, dzień tygodnia, pora dnia; kwantyle zamiast surowych wartości skrajnych.
• Tekst (krótkie pola): cięcie do top‑n słów, prosty TF‑IDF jako jedna z gałęzi ColumnTransformer.
• Zadanie: dorzuć 3 cechy, porównaj stabilność wyniku między foldami i opisz 2 najważniejsze cechy.

Tydzień 4 — decyzja i produkt

• Mapa „próg → liczba rekordów → precision”, wybór punktu działania.
• Skrypt batch i mały interfejs (Streamlit lub FastAPI), zapis top‑k jako CSV.
• Jednostronicowy raport dla biznesu: decyzja, próg, liczba rekordów, ograniczenia i następny krok.

Po miesiącu masz repo, które da się uruchomić, i wynik, który łączy się z działaniem. Matematyka nie znika, ale nie blokuje startu.