Od Excela do machine learning jak analityk danych może wejść w świat modeli predykcyjnych

Sytuacja wyjściowa: zlecenie „przewidzieć X” i Excel, który zaczyna się krztusić

Historia z biura, którą wielu zna aż za dobrze

Jest poniedziałek, 10:00. Na spotkaniu zarząd prosi o prognozę sprzedaży po regionach i wskazanie klientów z ryzykiem odejścia. Dotąd wszystko robiłeś w Excelu: przestawne, Power Query, parę makr i klasyczna regresja z dodatku Analysis ToolPak. Działa, ale workbook z 20 zakładkami ładuje się minutę, a każdy scenariusz wymaga ręcznej aktualizacji. Pada sugestia: „Może by to ogarnąć modelem predykcyjnym?”.

To typowy moment graniczny: Excel jeszcze daje radę, lecz stabilność, skalowalność i jakość przewidywań stają się losowe. Z drugiej strony „machine learning” brzmi jak ciężka machina i wielomiesięczny projekt. Rzeczywistość zwykle mieści się pośrodku: proste modele da się zbudować i wdrożyć małym nakładem, o ile decyzje są rzeczowe, a zakres pilota precyzyjny.

Najczęstsze pytania, które padają na starcie

• Czy naprawdę potrzebujemy ML, czy wystarczy sensowny model w Excelu/Power BI?
• Ile danych to „wystarczająco”, aby model miał sens?
• Jakie minimum narzędzi i umiejętności pozwala zacząć bez doktoratu z matematyki?
• Jak zbudować pierwszą wersję predykcji szybko, porównywalną z tym, co mamy w Excelu?
• Jak nie wpaść w typowe pułapki (przeciek informacji, złe metryki, przetrenowanie)?
• W jaki sposób dostarczyć wyniki z ML z powrotem do Excela/Power BI, żeby użytkownicy biznesowi z nich korzystali?

Odpowiedzi na te pytania wymagają kilku trzeźwych decyzji i kilkunastu praktycznych kroków. Poniższe wskazówki prowadzą „od Excela do machine learning” przez potwierdzenie sensu, zbudowanie minimalnego rozwiązania i pokazanie, jak bezpiecznie je uruchomić.

1. Oceń, czy ML ma przewagę nad Excelem zanim włożysz w to czas

Kiedy modele predykcyjne dają realną przewagę

Modele uczenia maszynowego zyskują przewagę, gdy zależności są nieliniowe, cech jest dużo, interakcji jeszcze więcej, a objętość danych lub częstotliwość aktualizacji przekracza zdroworozsądną pojemność Excela. W praktyce: klasyfikacja klientów z ryzykiem odejścia (dziesiątki sygnałów zachowań), prognozy popytu zależne od sezonowości i kalendarza świąt, estymacja prawdopodobieństwa konwersji leadów z kanałów cyfrowych. W takich zadaniach lasy losowe lub modele gradient boosting zwykle wygrywają z prostą regresją i ręcznymi regułami.

Jeśli problem „zamknie się” w kilku zmiennych o czytelnej zależności (np. popyt ~ cena + dzień tygodnia), Excel i klasyczna regresja liniowa bywają wystarczające. Zyski z bardziej złożonych algorytmów mogą nie równoważyć kosztu wdrożenia i utrzymania. Co do zasady, jeśli użytkownik biznesowy jest w stanie uzyskać trafność bliską oczekiwanej decyzji prostymi formułami, ML może być przerostem formy.

Kiedy lepiej uważać lub wstrzymać się

Przewiduj kłopoty, gdy danych jest skrajnie mało (np. kilkaset rekordów, dziesiątki cech, silny szum), proces generujący dane jest niestabilny (częste zmiany polityk, brak standaryzacji), albo etykiety są wadliwe (np. „sukces kampanii” mierzone różnymi definicjami). W takich warunkach skomplikowany model może pięknie działać na wczorajszym pliku, a dziś zawodzić. Zwykle najpierw warto ułożyć definicje i pipeline danych, dopiero potem „dokręcać” model.

Prosty test sensowności (baseline vs. oczekiwania)

• Porównaj obecną trafność/MAE/ROAS z prostym baseline: ostatnia wartość, średnia z 4 tygodni, reguła prosta „if-else”.
• Oceń lukę do celu: jeśli baseline ma 80% trafności, a potrzebujesz 82%, skok o 2 p.p. może nie uzasadniać ML. Jeśli potrzeba 10–20 p.p., warto próbować.
• Przelicz potencjalną wartość: czy 5 p.p. poprawy oznacza setki tysięcy złotych rocznie? Jeśli tak, projekt ma sens nawet jako pilotaż.

2. Zdefiniuj problem predykcyjny precyzyjnie jak w umowie

Cel, etykieta i horyzont czasowy

Precyzyjna definicja jest pół sukcesu. Określ: co przewidujemy (np. „czy klient odejdzie”), na kiedy („w ciągu 60 dni”), jak mierzymy sukces (np. recall przy 20% najwyższych score’ów). Dla szeregów czasowych określ horyzont prognozy (T+1 tydzień, T+4 tygodnie) i jednostkę agregacji. Im mniej pól do interpretacji, tym mniejsza szansa na spór przy odbiorze.

W binary classification uzgodnij akceptowalny kompromis między precyzją (precision) a czułością (recall). W praktyce zespoły sprzedaży wolą wysoką precyzję w top N klientów do kontaktu, zespół utrzymania – wysoki recall, by nie przegapić odchodzących. Jedno i drugie ma sens, ale prowadzi do odmiennych metryk i progów.

Unikaj przecieku informacji (data leakage)

Przeciek to użycie cech niedostępnych w momencie podejmowania decyzji. Przykłady: „status reklamacji w kolejnych 30 dniach” do przewidywania churnu w chwili T; „ostateczna cena” do prognozy ceny ofertowej; agregaty z okresu obejmującego okno predykcji. Rozwiązanie: buduj cechy wyłącznie z danych dostępnych przed chwilą decyzji i waliduj w układzie czasowym (train na przeszłości, test na nowszym okresie).

Metryka sukcesu ustalona zawczasu

• Klasyfikacja: ROC-AUC dobre na porównanie modeli, ale decyzje robi się progami – raportuj też precision/recall przy wybranym procencie populacji.
• Regresja: MAE jest czytelne biznesowo (średni błąd w jednostkach), MAPE bywa mylące przy wartościach bliskich 0.
• Szeregi czasowe: sMAPE i MASE są stabilniejsze niż MAPE; używaj walidacji na rolling window, nie k-fold z losowym podziałem.

3. Zacznij od baseline: Excel kontra prosty model w Pythonie

Baseline w Excelu, który daje punkt odniesienia

Zrób na szybko 2–3 proste prognozy w narzędziach, które znasz: średnia krocząca, ostatnia wartość, regresja liniowa z 2–3 zmiennymi, prosty scoring na podstawie kilku reguł. Wylicz metrykę sukcesu na okresie testowym odciętym w czasie. To jest „cena wejścia”, którą ML musi przebić, aby mieć rację bytu.

Minimalny model w Pythonie – dzień pracy, nie tydzień

Do regresji/klasyfikacji wystarczy pandas i scikit-learn. Pipeline: wczytaj CSV, podziel na train/test (czasowo lub losowo), przeskaluj/zakoduj cechy, naucz LogisticRegression/LinearRegression lub RandomForest, policz metryki. Nie stroisz hiperparametrów – najpierw chcesz zobaczyć, czy prosta metoda ma przewagę nad baseline.

Jeśli pracujesz w Power BI, można też użyć wbudowanego AutoML (w wybranych licencjach) lub skorzystać z notatnika w środowisku chmurowym. W małych zespołach lokalny Jupyter zadziała szybciej i taniej.

Porównanie – nie tylko liczba, ale użyteczność

Nawet wyższa ROC-AUC nie musi znaczyć lepszej decyzji w top 10% klientów do kontaktu. Dlatego porównuj także „operacyjne” metryki: ilu klientów faktycznie „trafiasz” w pierwszej dziesiątce procent? Jaki MAE w porównaniu do średniej z ostatnich 4 tygodni? W sprzedaży liczy się lift w top N, w prognozie popytu – odchylenie od planu w jednostkach magazynowych.

Praktyczny sposób porównania wygląda tak: sortujesz klientów według score, zaznaczasz realne ograniczenie (np. zespół jest w stanie obdzwonić 500 leadów tygodniowo), liczysz precision@500 i recall@500 oraz oczekiwany zysk przy założonych kosztach kontaktu i średniej wartości sukcesu. Dla regresji robisz analogię: liczysz MAE/MAPE w segmentach ważnych operacyjnie (np. wysoki wolumen magazynowy) i sprawdzasz, czy błąd w tych segmentach faktycznie spada.

4. Uporządkuj dane i zbuduj cechy, które realnie wspierają decyzję

Minimalny pipeline danych (powtarzalny, bez fajerwerków)

• Jednoznaczne klucze i zakres czasu: zdefiniuj identyfikator rekordu (np. klient_id + data_sna­pshot) i okno obserwacji, z którego budujesz cechy.
• Łączenie źródeł: połącz fakty (transakcje, logi) z wymiarami (klienci, produkty). Usuń duplikaty; rozstrzygnij konflikty regułą „ostatnia wygrana” lub większością.
• Braki danych: jawnie imputuj (np. mediana dla liczb, „brak” dla kategorii). Zapisz reguły, by przy kolejnym przebiegu mieć identyczne zachowanie.
• Agregacje w oknach: licz sumy/średnie/odchylenia w ostatnich 7/30/90 dniach. Dla churnu: liczba logowań 30 dni vs. 90 dni, trend zamówień, odsetek reklamacji w ostatnim kwartale.
• Chronologia: buduj cechy wyłącznie z danych dostępnych do chwili T. Agregacje po T+1 to ukryty przeciek.

Przykład z praktyki: dla prognozy popytu tygodniowego na SKU wprowadzono trzy cechy, które „trafiają” w Excelu słabo: liczba dni roboczych w tygodniu, flaga długiego weekendu oraz opóźniony popyt z T−1 i T−52 (sezonowość roczna). Już to często daje zauważalny spadek MAE.

Kodowanie i skalowanie bez komplikowania

• Niskokardynalne kategorie (np. region): one‑hot. Wysokokardynalne (np. kod produktu): target/mean encoding ze stratyfikacją w walidacji, by nie wprowadzić przecieku.
• Skalowanie liczb (Standard/MinMax) ma sens głównie dla modeli liniowych i odległościowych. Drzewa i boosting radzą sobie bez tego.
• Daty na liczby: dzień tygodnia, tydzień roku, kwartał; dla cykliczności rozważ sin/cos z dnia tygodnia.

Mała kontrola jakości danych (szybka i powtarzalna)

• Rozkłady i wartości skrajne: proste histogramy, odsetek zer/NAN po każdej transformacji.
• Stabilność cech w czasie: porównaj mediany/odchylenia miesiąc do miesiąca. Skok o rząd wielkości zwykle oznacza problem w źródle.
• Spójność etykiety: czy definicja „churn w 60 dni” jest liczona identycznie w train i test?

5. Minimalny zestaw narzędzi i umiejętności, żeby ruszyć z miejsca

Stack „na start”, który nie przytłacza

• Język/środowisko: Python 3.10+, Jupyter Notebook lub VS Code + venv/pip.
• Biblioteki: pandas (ETL), numpy (obliczenia), scikit‑learn (modele, walidacja), matplotlib/seaborn (wykresy), joblib (serializacja modeli).
• Opcjonalnie: LightGBM/XGBoost (silny boosting), statsmodels/sktime dla prostych szeregów, DuckDB do szybkich zapytań SQL na plikach CSV/Parquet.
• Kontrola wersji: Git (choćby lokalnie). Commituj notatniki i skrypty, modele w katalogu „models/”.

Mapa z Excela do Pythona (intuicyjne przełożenie)

• Tabele przestawne → groupby/agg w pandas.
• Power Query (merge/append) → pandas.merge/concat.
• Formuły warunkowe → numpy.where lub pandas.apply (lepiej wektorowo).
• Filtry/segmentacje → zapytania boole’owskie w pandas (df[df[„kol”] > 0]).

Szablon projektu, który ratuje porządek

• data/raw, data/processed, notebooks/, src/, models/, reports/.
• Skrypt run_pipeline.py: wczytanie → cechy → uczenie → metryki → zapis predykcji do CSV/Parquet.
• Plik config (YAML/JSON) na parametry: ścieżki, okna czasowe, próg decyzyjny.

6. Walidacja, lekkie strojenie i próg decyzji nastawiony na zysk

Walidacja dopasowana do problemu

• Dane czasowe: rolling/expanding window. Trenujesz na [T0, T1], testujesz na (T1, T2]; przesuwasz okno.
• Dane i.i.d.: stratified train/test split; przy rzadkich zdarzeniach zapewnij reprezentację klasy pozytywnej w obu zbiorach.

Strojenie bez popadania w research

• Grid/RandomSearch z kilkoma sensownymi wartościami (max_depth, n_estimators, learning_rate). 30–60 prób wystarczy, by wygrać z baseline.
• Ustal ziarno losowe i trzymaj stały zestaw cech, by porównania były uczciwe.
• Nauka z wczesnym stopem (boosting) obcina zbędne iteracje i przeuczenie.

Ustawienie progu według ekonomii decyzji

• Top‑N: jeśli zespół obsłuży 500 spraw tygodniowo, optymalizuj precision/recall@500, nie ogólną AUC.
• Koszt‑zysk: zdefiniuj koszt fałszywego alarmu i wartość trafienia; wybierz próg maksymalizujący oczekiwany zysk. Raportuj krzywą zysku vs. próg.
• Kalibracja prawdopodobieństw (Platt/Isotonic), jeśli progi będą używane dynamicznie w różnych segmentach.

7. Wyjaśnialność, której można użyć na spotkaniu

Globalnie: co zwykle „niesie” model

• Wagi/ważność cech: dla drzew — importance; dla modeli liniowych — współczynniki po standaryzacji.
• Krzywe zależności (PDP/ICE) dla 3–5 kluczowych cech, aby pokazać kierunek wpływu bez obietnicy „przyczynowości”.

Lokalnie: dlaczego ten rekord ma taki wynik

• SHAP/LIME dla pojedynczych przypadków z adnotacją: „niska aktywność 30‑dniowa” + „ostatnia reklamacja” podbiły ryzyko.
• Unikaj przeładowania wykresami — jedna strona z esencją: top cechy globalnie, dwa przykłady lokalne.

8. Dostarczenie wyników do Excela/Power BI i mini‑wdrożenie

Trzy proste ścieżki dowozu

• Plik wynikowy: zapis Parquet/CSV z id i score → folder sieciowy/SharePoint → Power BI (pobranie + incremental refresh) lub Excel Power Query.
• Baza danych: tabela predictions (id, data_score, score, wersja_modelu) w SQL Server/Azure; raport podłącza się bezpośrednio.
• Lekki endpoint: FastAPI/Flask na wewnętrznym serwerze dla ad hoc scoringu (opcjonalne w pilocie).

Harmonogram i wersjonowanie bez MLOps‑owego kombajnu

• Plan zadań (Windows Task Scheduler) lub GitHub Actions/cron: uruchom pipeline co tydzień.
• Wersjonuj model i cechy: nazwa pliku modelu z datą i hashem (models/model_2024‑10‑15_ab12.joblib), zapisuj metryki do CSV/JSON.

9. Pilotaż ML jako kontrolowany eksperyment biznesowy

Hipoteza → miara → decyzja (proste i spisane)

• Hipoteza: „Model zwiększy skuteczność kontaktu w top 500 leadów tygodniowo o ≥20% vs. obecna reguła w Excelu”. Jedno zdanie, mierzalne.
• Miara sukcesu: precision/recall@N lub MAE/MAPE w zdefiniowanych segmentach. Dodatkowo szacowany zysk netto przy założonych kosztach.
• Horyzont: min. 4–8 tygodni danych testowych lub 2–3 cykle biznesowe, aby uniknąć przypadkowego szczęścia.
• Decyzja Go/No-Go: progi „wchodzimy”, „warunkowo”, „rezygnujemy”. Przykład: Go jeśli lift@500 ≥ 1.25 i zysk ≥ 0; Warunkowo jeśli lift 1.10–1.25; No-Go poniżej.

Przykład: zespół sprzedaży może obdzwonić 500 leadów. Obecna reguła „ostatnia aktywność + region” daje 14% sukcesu. Jeśli model utrzyma ≥17% w 3 kolejnych tygodniach i zwiększy przychód netto przy tym samym koszcie, projekt przechodzi do wdrożenia wąskiego.

Zakres i bezpieczeńniki, żeby pilotaż nie „puchł”

• Zakres danych: 12–18 miesięcy historii zwykle wystarcza do pierwszego modelu transakcyjnego. Doklejanie niszowych źródeł zostaw na iterację 2.
• Frozen baseline: zablokuj regułę porównawczą na czas pilotażu (bez rotacji kryteriów w Excelu), inaczej wyników nie porównasz uczciwie.
• Plan A/B: część rekordów kierujesz według modelu, część według baseline. Prosty split 50/50 lub top‑N vs. losowa kontrola.

10. Ryzyka i pułapki – szybkie testy, które je wychwytują

Przeciek informacji (data leakage)

• Objaw: „magiczne” wyniki na walidacji, które znikają w produkcji.
• Test: symulacja time‑split i twarda zasada „cechy tylko do chwili T”. Wyłącz zmienne będące skutkiem zdarzenia (np. „data reklamacji” przy predykcji reklamacji).
• Naprawa: restrykcyjne okna czasowe, transformacje w pipeline scikit‑learn (fit na train, transform na test).

Niereprezentatywność i drift

• Objaw: spadek skuteczności po zmianie kanału, cennika lub sezonu.
• Test: monitoruj rozkłady cech i etykiet w czasie; wskaźniki typu PSI/KS dla kluczowych zmiennych miesiąc do miesiąca.
• Reakcja: re‑trening cykliczny (np. co kwartał) lub rolling window; lista „cech wrażliwych” do audytu przy zmianach biznesowych.

Rzadkie zdarzenia i złudna AUC

• Objaw: wysoka AUC przy zerowej użyteczności w top‑N.
• Test: metryki ograniczone zasobem (precision/recall@N), analiza progu oparta o koszt‑zysk, nie o ogólną krzywą ROC.
• Remedium: ważenie klas, oversampling lub fokalna funkcja straty w boostingu; ewaluacja na segmentach wysokiej wartości.

Koszty ukryte i operacyjne tarcia

• Objaw: model lepszy na papierze, ale zespół „nie ma co z nim zrobić”.
• Test: mapa procesu przed pilotażem – kto, kiedy i w jakim narzędziu wykorzysta przewidywania.
• Remedium: progi i listy działań uzgadniaj z operacją; zasilaj istniejące raporty (Excel/Power BI), nie buduj równoległych wszechświatów.

Zgodność i prywatność

• Zasada: minimalizacja danych. Jeśli wynik nie poprawia się po dodaniu wrażliwych pól, usuń je.
• Ślad audytowy: loguj wersję danych, cech i modelu dla każdej predykcji (id, timestamp, wersja).

11. Kiedy zostać przy Excelu/BI, a kiedy przejść na ML

Excel/BI zwykle wygrywa, gdy

• Reguły są stabilne i zrozumiałe, a baza mała (np. kilkaset rekordów miesięcznie). Heurystyka „ostatnia aktywność + ARPU” bywa wystarczająca.
• Decyzja wymaga pełnej transparentności krok po kroku (audyt, compliance), a koszt błędu jest niski.
• Horyzont i zmienność są ograniczone: powtarzalny popyt bez silnej sezonowości, brak efektów interakcji.
• Nie ma kanału dowozu predykcji. Jeśli wynik kończy jako „tabela do ręcznego kopiowania”, zysk stopnieje.

Krótki przykład: planowanie zakupów dla 30 SKU w jednym sklepie – średnia krocząca + sezonowość z T‑52 w Excelu może być szybsza i wystarczająco celna.

ML daje przewagę, gdy

• Decyzje są ograniczone zasobem (top‑N), a cechy mają nieliniowe relacje (interakcje, progi).
• Występuje sezonowość, kampanie i efekty krzyżowe (produkt × region × kanał), których Excel nie obejmie bez ogromnej złożoności.
• Skala rośnie: dziesiątki tysięcy klientów/SKU, wiele zdarzeń dziennie – ręczne reguły nie nadążają.
• Potrzebna jest iteracja i monitoring w czasie (drift, re‑trening), a wynik trafia automatycznie do procesów.

Przykład: scoring leadów z wielu kanałów (web, kampanie, partnerzy) – model potrafi łączyć sygnały z historii, zachowania i kontekstu dnia tygodnia, co do zasady wygrywając z prostą sumą punktów.

12. Krótka lista kontrolna startu (do odhaczenia)

• Zdefiniowana hipoteza biznesowa i miara sukcesu (lift/MAE/ROI) – spisana w jednym akapicie.
• Baseline w Excelu zamrożony na czas porównania (wersja i data).
• Podział czasowy lub stratyfikowany; brak cech „z przyszłości”.
• 3–5 okien agregacji i 1–2 opóźnienia (lag) dla sygnałów czasowych.
• Jedna prosta rodzina modeli na start (liniowy + las/boosting) bez nadmiarowego strojenia.
• Metryki operacyjne top‑N oraz krzywa zysku vs. próg.
• Plan dowozu: gdzie wyląduje score (CSV/SQL/Power BI) i kto go użyje.
• Monitoring po wdrożeniu: rozkłady cech, PSI/KS, harmonogram re‑treningu.
• Ślad audytowy: wersja danych/cech/modelu dla każdej predykcji.

Jeśli trzy czwarte pól z tej listy masz pokryte i model pokazuje zysk w ograniczeniu „top‑N”, zwykle jest sens iść w ML. Gdy nie spełniasz tych warunków lub przewaga nad Excelem jest marginalna – lepiej doszlifować reguły i wrócić do tematu po zebraniu bogatszych danych.

13. Minimalny stack narzędziowy na start (bez przerostu)

• Środowisko: Python 3.11, VS Code + Jupyter. Jedno środowisko wirtualne (venv), requirements.txt.
• Biblioteki: pandas, numpy, scikit‑learn, lightgbm (opcjonalnie), matplotlib/seaborn, joblib, pyarrow (Parquet), SQLAlchemy/pyodbc (jeśli łączysz się z bazą).
• Kontrola wersji: Git + jeden prywatny repozytorium; commit przy każdej zmianie cech/modelu.
• Wejście/wyjście: Parquet/CSV do wymiany z Power BI/Excelem; jeśli jest SQL Server – bezpośrednie INSERT/SELECT do tabeli predictions.
• Harmonogram: Windows Task Scheduler lub GitHub Actions (cron) do uruchamiania pipeline’u cyklicznie.

Praktyczny sens: ten zestaw zwykle wystarczy do zbudowania, oceny i dowiezienia predykcji bez MLOps‑owego kombajnu. Przykład: lokalny skrypt Python → zapis Parquet do SharePoint → raport Power BI z odświeżaniem przyrostowym.

14. Plan 4 tygodnie do pierwszego wyniku (z artefaktami)

Tydzień 1 – problem i dane „na czysto”

• Definicja etykiety i horyzontu (np. churn w 60 dni; popyt T+1 tydzień). Spisz regułę bazową z Excela.
• Ekstrakt danych z 12–18 mies. historii. Identyfikatory, znaczniki czasu, cechy kandydackie.
• Artefakty: dataset_train.parquet, dataset_test.parquet (split czasowy), notatka z definicjami pól.

Tydzień 2 – cechy i baseline

• 3–5 okien agregacji (7/30/90 dni), 1–2 opóźnienia (lag), proste flagi (np. reklamacja_30d).
• Baseline: model liniowy/logit oraz reguła z Excela przeliczona na tych samych danych.
• Artefakty: features.py (powtarzalne generowanie cech), metryki baseline (CSV/JSON).

Tydzień 3 – model i próg operacyjny

• Las losowy lub LightGBM z domyślnymi parametrami + ograniczone strojenie (2–3 hiperparametry).
• Metryki ograniczone zasobem (precision/recall@N) + krzywa zysku przy realistycznych kosztach.
• Artefakty: model.joblib, raport metryk z datą/hashem, wykres top‑N vs. zysk.

Tydzień 4 – dowóz i „tryb operacyjny”

• Eksport score do CSV/Parquet/SQL z polami: id, data_score, score, wersja_modelu.
• Power BI/Excel: wizualizacja progu, top‑N i liftu vs. baseline; prosty manual użycia.
• Artefakty: skrypt run_score.py, harmonogram zadań, instrukcja 1‑stronicowa dla operacji.

Efekt: po 4 tygodniach masz liczby porównywalne z Excelem, plik z predykcją w procesie i jasną decyzję Go/No‑Go.

15. Mikro‑pipeline predykcyjny w ~40 linijkach (do skopiowania i adaptacji)

# pip install pandas numpy scikit-learn lightgbm joblib pyarrow
import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import OneHotEncoder, StandardScaler
from sklearn.pipeline import Pipeline
from sklearn.metrics import average_precision_score
from sklearn.linear_model import LogisticRegression
from joblib import dump
from datetime import date

# 1) Dane
df = pd.read_parquet("dataset.parquet")
df = df.sort_values("event_date")
cut = int(len(df) * 0.8)
train, test = df.iloc[:cut], df.iloc[cut:]

X_train = train.drop(columns=["target"])
y_train = train["target"].astype(int)
X_test  = test.drop(columns=["target"])
y_test  = test["target"].astype(int)

num = X_train.select_dtypes(include="number").columns.tolist()
cat = [c for c in X_train.columns if c not in num]

# 2) Przetwarzanie + model
pre = ColumnTransformer(
    transformers=[
        ("num", StandardScaler(with_mean=False), num),
        ("cat", OneHotEncoder(handle_unknown="ignore", min_frequency=50), cat)
    ]
)
clf = LogisticRegression(max_iter=200, n_jobs=-1, class_weight="balanced")
pipe = Pipeline(steps=[("pre", pre), ("clf", clf)])

pipe.fit(X_train, y_train)
proba = pipe.predict_proba(X_test)[:, 1]

# 3) Metryka ograniczona zasobem (przykład: top 500)
test["proba"] = proba
topN = test.nlargest(500, "proba")
precision_at_500 = topN["target"].mean()
ap = average_precision_score(y_test, proba)

print("AP:", round(ap, 4), "Precision@500:", round(precision_at_500, 4))

# 4) Zapis modelu i predykcji
ver = date.today().isoformat()
dump(pipe, f"models/model_{ver}.joblib")
test[["id", "proba"]].to_parquet(f"predictions/preds_{ver}.parquet", index=False)

Jak użyć: podmień „target”, „event_date”, listę kolumn numerycznych/kategorialnych i wielkość top‑N zgodnie z procesem biznesowym. Na start model liniowy bywa wystarczający; jeśli jest miejsce na nieliniowości, zamień LogisticRegression na LightGBM.

16. ROI i decyzja budżetowa w 15 minut

• Koszt jednostkowy działania (K): telefon, e‑mail, rabat, wysyłka. Policz realnie, z kosztami pracy.
• Zysk jednostkowy przy trafieniu (Z): marża, oszczędność CAPEX/OPEX, uniknięta strata.
• Precision@N i Recall@N: ile trafień w top‑N i jaki udział całej „puli trafień” łapiesz.

Prosty wzór: Zysk_netto = (TP × Z) − (N × K). Gdzie TP = liczba trafień w top‑N. Jeśli porównujesz z Excelem, licz „delta zysku” jako różnicę między modelami.

Przykład zastosowania: zespół może obsłużyć 500 leadów tygodniowo (K = koszt telefonu). Wariant A (reguła): 70 trafień; Wariant B (model): 90 trafień. Jeśli Z − K > 0, różnica 20 trafień × (Z − K) to przyrostowy zysk. Jeżeli Z jest zmienne segmentowo, policz warianty dla 2–3 segmentów i wybierz próg osobno dla każdego.

• Gdy ROI nie wychodzi dodatnie przy żadnym rozsądnym N – ML jest przedwczesny. Zwykle problem leży w definicji celu lub braku kanału dowozu.
• Gdy ROI dodatnie, ale wąsko – rozważ tańsze działanie (np. e‑mail przed telefonem) albo próg bardziej konserwatywny.

17. Standard danych „gotowe do ML” (kontrola 10 minut)

• Identyfikatory i czasy: unikalny id rekordu, poprawny timestamp, brak przyszłych dat w cechach dla chwili T.
• Spójność kluczy: joiny 1‑do‑1 lub 1‑do‑wielu jawnie agregowane. Raportuj liczbę duplikatów przed i po joinach.
• Braki danych: udział NaN per kolumna; decyzja: imputacja (mediana/tryb) vs. flaga „brak”. Dla kategorycznych – kategoria „Unknown”.
• Skale i jednostki: jawne jednostki (dni, zł, szt.), standaryzacja zakresów dla modeli liniowych.
• Wyjątki i outliery: progi winsoryzacji lub log‑transform dla długich ogonów (przychód, czas trwania).
• Dokument: plik data_dictionary.md – definicja pola, źródło, częstotliwość aktualizacji, odpowiedzialny właściciel.

Przykład szybkiego testu: policz procent braków i odsetek wartości stałych w każdej kolumnie; jeżeli kolumna jest pusta lub ma jedną wartość przez 95% rekordów – odłóż ją do „ławki rezerwowych”. Dzięki temu model nie „uczy się szumu”.

18. Kalibracja i próg decyzji zamiast „accuracy”

Modele predykcyjne zwracają zwykle prawdopodobieństwo. Żeby decyzje były spójne biznesowo, te prawdopodobieństwa muszą być możliwie „prawdziwe” (skalibrowane), a próg wyboru przypadków – dopasowany do zasobu i kosztów.

• Kalibracja: porównaj koszyki predykcji (np. 0.2–0.3, 0.3–0.4 itd.) z rzeczywistymi trafieniami. Jeśli w koszyku 0.3 masz ~30% trafień – kalibracja jest z grubsza poprawna.
• Metody: Platt (logistyczna) lub izotoniczna kalibracja na walidacji. W scikit‑learn: CalibratedClassifierCV na gotowym modelu.
• Próg operacyjny: nie „0.5 z przyzwyczajenia”, tylko próg dający N przypadków zgodny z pojemnością procesu (lub taki, przy którym Zysk_netto jest maksymalny).
• Specyfika klas niezbalansowanych: accuracy bywa mylące; bazuj na precision/recall@N, PR‑AUC i krzywej zysku vs. próg.

Przykład: zespół obsługuje tygodniowo 200 spraw. Ustaw suwak progu w raporcie tak, by generować ~200 rekordów o najwyższym score. Co miesiąc sprawdź, czy precision@200 nie spada – jeśli tak, skoryguj próg lub odśwież model.

19. Interpretacja: od „feature importance” do działania

Ważność cech jest użyteczna tylko wtedy, gdy przekłada się na konkretną interwencję. Zacznij od prostych metod, unikaj nadinterpretacji korelacji i „magii” wyjaśnień.

• Ranking wpływu: permutation importance na zbiorze walidacyjnym – odporniejsza na skale niż surowe współczynniki.
• Kierunek efektu: wykresy zależności częściowej lub ALE dla 3–5 kluczowych cech (czy „więcej” oznacza wyższe ryzyko?).
• Ostrożność: cechy skorelowane „dzielą” wpływ; nie wyciągaj wniosków polityki biznesowej z pojedynczej liczby.
• Mapa akcji: dla top 3–5 cech dopisz możliwe działania (kampania reaktywacyjna, dodatkowa weryfikacja, inny kanał kontaktu) i warunki ich opłacalności.

Przykład: „dni_od_ostatniej_aktywności” i „liczba_błędów_logowania_7d” w churnie są wysoko – sensowna interwencja to miękki e‑mail przypominający i szybka ścieżka resetu hasła zamiast natychmiastowego rabatu.

20. Mały model, duże konsekwencje: zgodność i ryzyko

Nawet prosty scoring dotyka danych osobowych. Co do zasady wystarczą podstawowe zabezpieczenia i przejrzystość procesu – bez „ciężkiego” compliance, ale z kilkoma twardymi zasadami.

• Podstawa prawna i cel: jasno opisz cel przetwarzania (np. personalizacja oferty) i sprawdź podstawę (zgoda lub uzasadniony interes). Nie używaj danych poza deklarowanym celem.
• Minimalizacja: nie zasilaj modelu wrażliwymi kategoriami; wyrzuć cechy, które nie podnoszą metryk lub są proxy „ryzykownych” informacji.
• Przejrzystość: utrzymuj „kartę modelu” (wersja, zakres danych, metryki, właściciel), by móc wyjaśnić ogólne zasady działania.
• Bezpieczeństwo: dane robocze trzymaj w lokalizacji służbowej z kontrolą dostępu; unikaj dumpów na dysku lokalnym lub prywatnym chmurze.
• Retencja: czyść zbiory treningowe po okresie uzasadnionym cyklem życia modelu; dokumentuj, kiedy i co usunięto.

Przykład: model skłonności do zakupu. Zakres: historia interakcji i zakupów, bez danych szczególnej kategorii. Podstawa: uzasadniony interes, z opcją łatwej rezygnacji z profilowania marketingowego.

21. Gdy problem jest czasowy – walidacja krocząca i cechy okienne

Dane szeregów i zdarzeń w czasie wymagają innej walidacji niż losowy podział. Kluczem jest porządek czasowy i cechy budowane z informacji „dostępnej w chwili T”.

• Walidacja: split kroczący (walk‑forward) lub blokowy; żadnych losowych miksów, jeśli etykieta jest w przyszłości względem cech.
• Okna i opóźnienia: agregacje 7/30/90 dni i lags, ale zawsze obcięte do T (bez „podglądu przyszłości”).
• Prognoza vs. klasyfikacja: dla popytu T+1 rozważ modele regresyjne/forecasting (SARIMAX/Prophet/LightGBM), dla churnu – klasyfikację binarną z horyzontem (np. 60 dni).
• Sezonowość i święta: dodaj cechy kalendarzowe (dzień tygodnia, miesiąc, święta), najlepiej jako kategorie lub sygnały sinus/cosinus.

Przykład: tygodniowa prognoza sprzedaży per sklep. Ustaw horyzont T+1 tydzień, trenuj na blokach miesięcznych, w cechach trzy okna sprzedaży (7/28/84 dni) i flagi „przed/po wypłacie”.

22. Power BI/Excel jako front do predykcji – wzorzec integracji

Zwykle wynik modelu żyje w Power BI lub Excelu. Schemat integracji powinien być prosty, powtarzalny i odporny na drobne zmiany danych.

• Struktura tabeli predykcji: id, data_score, score, wersja_modelu, ewentualnie segment i cechy pomocnicze do filtrowania.
• Join: do tabeli faktów/klientów po id i aktualnym okresie; unikaj duplikatów kluczy.
• Kontrola progu w raporcie: slicer/what‑if parameter na próg lub na N; miary DAX wyliczające top‑N i zysk przy zadanych K i Z.
• Odświeżanie: przyrostowe (incremental refresh) i historia wersji modelu jako wymiar, by śledzić zmiany metryk w czasie.
• Operacyjność: pole „assign_to” i status pracy w tej samej tabeli lub tabeli podrzędnej – dzięki temu widać, co zostało wykonane i z jakim skutkiem.

Przykład: codzienny plik Parquet z kolumnami id, score, wersja_modelu ląduje w Data Lake/SharePoint. Power BI scala go z CRM i pokazuje listę „Top 200” do obdzwaniania z przyciskiem filtra progu.

23. Uczenie w pętli: kiedy odświeżać i jak nie popsuć procesu

Model, który nie uczy się na nowej rzeczywistości, traci trafność. Jednocześnie zbyt częste retreningi zwiększają koszty i ryzyko regresji jakości.

• Harmonogram: zwykle 4–12 tygodni dla procesów marketingowo‑operacyjnych; krócej przy szybkich zmianach oferty, dłużej przy stabilnym popycie.
• Warunki wyzwolenia: drift cech (PSI), spadek precision@N poniżej progu, zmiana procesu (np. nowy kanał sprzedaży).
• Champ‑challenger: utrzymuj „mistrza” i testuj „pretendenta” równolegle na ~10–20% ruchu lub w offline’owych backtestach; decyzja o podmianie na liczbach.
• Zbieranie etykiet: zamknij pętlę — wynik działania (sukces/nie) musi wrócić do danych treningowych wraz z datą.
• Plan awaryjny: możliwość powrotu do poprzedniej wersji modelu i prosta procedura rollbacku (wersjonowane pliki + przełącznik w harmonogramie).