Hej, dodaje dodatkowo, dla zainteresowanych „od czego zacząć z AI" i prawie zawsze odpowiedź miesza dwie różne ścieżki.
Pierwsza to używanie gotowych modeli przez API albo narzędzia. Czyli umiesz wkleić dobry prompt do Claude'a, używasz Cursora, znasz Continue.dev. To jest dziś standard u każdego seniora w 2026, jak dwa lata temu znajomość Gita.
Druga ścieżka to tworzenie modeli i systemów ML. Bierzesz surowe dane, trenujesz na nich coś co działa, wdrażasz to i monitorujesz. To jest rola ML/AI engineera. Według ostatnich raportów z rynku pensje w tej roli poszły w górę o jakieś 20% w ciągu ostatniego roku (https://abhyashsuchi.in/ai-certifications-skills-in-2026/)), ale wymaga wejścia w fundamenty których prompt engineering nawet nie dotyka.
Ten post jest o drugiej ścieżce. Inny o poprzedniego. I nie dotyka high levelu, cczyli researchu architektury itd.
Najpierw kalibracja
Termin „AI" jest tak szeroki, że sensowne jest podzielenie go na trzy poziomy. Każdy ma inną drogę wejścia i inny rynek pracy.
Klasyczny ML to trening modeli na danych tabelarycznych. Klasyfikacja, regresja, forecasting, anomaly detection. Algorytmy w stylu regresji logistycznej, drzew decyzyjnych, gradient boostingu (XGBoost, LightGBM), klastrowania. Stack opiera się na Pythonie, pandas, scikit-learn plus jakiś framework do MLOps. Tu jest 70% realnej pracy ML w firmach które nie są big-techem, mimo że mało kto o tym mówi.
Deep learning to sieci neuronowe trenowane od zera albo fine-tuningowane do konkretnych zadań. Computer vision, NLP, audio. Stack to PyTorch, Hugging Face Transformers i infrastruktura GPU. Tu jest gros nowoczesnej pracy.
Trzeci poziom to LLM-y i generatywne AI. Praca z modelami takimi jak Llama, Qwen, Claude. Fine-tuning, RAG, agenty, ewaluacja. Rzadko trenujesz cokolwiek od zera bo ekonomicznie to się nie spina, częściej adaptujesz istniejące modele. Stack zostaje PyTorch z Transformerami, plus biblioteki dedykowane (PEFT do LoRA, vLLM do serwowania) i czasem orkiestracja typu LangChain albo Llamaindex, choć tu najlepiej wybierać selektywnie.
Większość ludzi która mówi „chcę robić AI" myśli o trzecim poziomie, bo to widać w mediach. Ale nie da się tam skoczyć z pominięciem dwóch pierwszych. LLM-y są też sieciami neuronowymi trenowanymi gradient descentem, ich ewaluacja używa tych samych metryk co reszta ML, a debugowanie wymaga rozumienia jak działa trening i attention. Można udawać że się rozumie, do pierwszego nietrywialnego problemu produkcyjnego.
Czego nie kupować
Zanim wyłożę roadmapę, parę rzeczy których nie warto.
Bootcampy za 5-15 tysięcy złotych z gwarancją pracy. Najczęściej uczą scikit-learna w 12 tygodni i sprzedają to jako „karierę w AI". Po takim bootcampie masz portfolio z trzech projektów na publicznych datasetach (Titanic, Iris, House Prices), które rekruterzy widzieli już 50 000 razy. Niektóre programy są lepsze od innych (https://www.dataquest.io/blog/best-machine-learning-bootcamps/)), ale za te same pieniądze możesz mieć trzy lata pracy własnej z lepszym efektem.
Certyfikaty od cloud vendorów (AWS ML Specialty, Azure AI Engineer, Google ML Engineer) mają sens jeśli już pracujesz w ML i firma wymaga papierka. Nie mają sensu jako droga wejścia. Uczą jak używać konkretnego cloudu, nie jak rozumieć ML. Ucz się ML, certyfikat dorobisz w tydzień przed egzaminem jeśli będzie potrzebny.
„Master Prompt Engineering" za 500 dolarów. Promptowanie LLM-ów jest częścią pracy w 2026, ale to nie jest „tworzenie AI". Kurs prompt engineeringu jako wstęp do ML jest jak kurs „jak używać API Stripe" w roli wstępu do programowania backendu.
W ostatnim roku pojawiło się sporo bootcampów „AI Engineering" które uczą głównie LangChaina. Po takim kursie potrafisz zbudować prosty RAG w trzy dni, co jest ok, ale nie nazywaj tego inżynierią ML.
Roadmapa, czyli 9-12 miesięcy uczciwej pracy
Czas potrzebny do osiągnięcia poziomu junior ML engineera od zera, przy 10-15 godzinach tygodniowo, to według różnych źródeł 6-12 miesięcy. Z mojej perspektywy 6 miesięcy to mit dla kogoś bez tła technicznego, 9-12 miesięcy to realistyczne minimum dla osoby która już programuje. Jeśli zaczynasz od zera bez programowania, dolicz dodatkowe 3-6 miesięcy na Pythona i podstawy.
Roadmapa zakłada że umiesz programować w Pythonie na podstawowym poziomie. Pętle, funkcje, klasy, list comprehensions, requesty, pliki.
Faza 0: matematyka której naprawdę potrzebujesz (4-8 tygodni)
Tu jest największy mit całej dziedziny. Że trzeba „skończyć kurs liniowej algebry i analizy zanim się zacznie ML". Nie trzeba.
Potrzebujesz algebry liniowej w wersji praktycznej. Wektory, macierze, mnożenie macierzy, transpozycja, rozkład SVD na poziomie intuicyjnym. Bez dowodów twierdzeń.
Z analizy potrzebujesz pochodnych, gradientu i reguły łańcuchowej. Po to żeby zrozumieć jak gradient descent szuka minimum funkcji.
Statystyka i prawdopodobieństwo to rozkłady (normalny, dwumianowy), oczekiwana wartość, wariancja, twierdzenie Bayesa, korelacja vs przyczynowość, p-values (i czemu są mylone), rozkład próbkowy.
Źródła które nie marnują czasu:
3Blue1Brown Essence of Linear Algebra. Dwanaście odcinków, jakieś trzy godziny, daje intuicję której nie da się wyciągnąć z podręczników.
3Blue1Brown Essence of Calculus. To samo dla analizy.
StatQuest with Josh Starmer. Najlepsze wyjaśnienia statystyki dla ML jakie znam, plus konkretne algorytmy.
Khan Academy jeśli chcesz wrócić do podstaw bardziej od zera.
Nie zaczynaj od podręczników typu „Mathematics for Machine Learning" Deisenrotha. Są dobre, ale nie jako pierwsza pozycja. Najpierw intuicja z 3Blue1Brown, potem kod, dopiero potem wracasz do matematyki gdy widzisz że czegoś brakuje.
Faza 1: klasyczny ML (8-12 tygodni)
Tu trafia większość roadmap, bo tu ML faktycznie się robi w nie-big-techowych firmach.
Algorytmy które musisz znać i wiedzieć kiedy stosować to regresja liniowa i logistyczna (wraz z wytłumaczeniem czemu logistyczna mimo nazwy to klasyfikator), drzewa decyzyjne, random forest, gradient boosting (XGBoost, LightGBM), K-means, DBSCAN, KNN, naive Bayes, SVM (klasyka, dziś rzadziej używane ale warto znać), PCA i inne techniki redukcji wymiarów, walidacja krzyżowa, train/val/test split, k-fold.
Ale ważniejsze od kolejnych algorytmów są kluczowe koncepty.
Bias-variance tradeoff. Overfitting i regularyzacja (L1/L2, dropout, early stopping). Feature engineering, czyli najważniejsza umiejętność której się nie nauczysz na publicznych datasetach. Zasada brzmi: dobry feature engineering bije lepszy algorytm.
Metryki ewaluacji. Nie tylko accuracy. Precision, recall, F1, ROC-AUC, confusion matrix. Trzeba wiedzieć kiedy które stosować.
Imbalanced data, czyli co robić gdy 99% danych to klasa większościowa. Data leakage, najczęstszy błąd początkujących, gdzie test data wycieka do treningu.
Źródła:
Andrew Ng Machine Learning Specialization na Courserze. To wciąż w 2026 najlepszy fundament ML dla początkujących (LearnDataSci). Nowa wersja używa Pythona zamiast Octave (jak stara), jest bardziej praktyczna.
„Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow" Aurélien Géron. Najlepszy podręcznik praktyczny do tej fazy. Trzecie wydanie z 2022 nadal aktualne dla większości materiału.
Kaggle Learn. Krótkie kursy darmowe, dobre uzupełnienie. Plus Kaggle competitions jako poligon.
Projekty końcowe tej fazy. Nie używaj Titanica, Iris, ani Boston Housing. Te datasety są tak ograne, że są wręcz przeciwskuteczne w portfolio. Zrób coś z realnymi danymi. Klasyfikator z public dataseta którego nikt nie używa, na przykład z Kaggle z mniej niż 100 notebookami publicznymi. Pipeline który scrapuje dane sam (z respektem dla TOS), czyści je, trenuje model, wystawia jako API z FastAPI. To pokazuje że umiesz cały flow, nie tylko sklearn.fit(). Jeden projekt z anomaly detection albo time series forecasting, czyli ścieżki które są mniej oczywiste niż klasyfikacja, ale często bardziej w cenie biznesowo.
Faza 2: deep learning (8-12 tygodni)
Najczęstszy błąd na tym etapie to skok do PyTorch i Transformerów bez zrozumienia że to wciąż jest gradient descent na funkcji błędu, tylko bardziej złożonej.
Co trzeba zrozumieć. Sieć neuronową od zera, co najmniej raz zaimplementowaną w numpy bez frameworku. Forward pass, backpropagation, update wag. Brzmi pedantycznie, ale to jedyny sposób żeby PyTorch nie był magią.
Activation functions (ReLU, sigmoid, tanh, GELU) i dlaczego ReLU wygrał. Optymalizatory: SGD, Adam, AdamW, dlaczego learning rate ma znaczenie i jak go dobierać. Loss functions: MSE, cross-entropy, focal loss, kiedy które.
Convolutional networks, czyli podstawa computer vision. Recurrent networks (RNN, LSTM), historyczne, ale warto zrozumieć przed Transformersami. Same Transformers i attention, kluczowy moduł nowoczesnego deep learningu. Transfer learning i fine-tuning, w praktyce robisz to częściej niż trenowanie od zera.
Stack to PyTorch (nie TensorFlow, w 2026 PyTorch dominuje research i przemysł, TF jest legacy w wielu nowych projektach), Hugging Face Transformers (de facto standard), Weights & Biases albo MLflow do trackingu eksperymentów.
Źródła:
Andrew Ng Deep Learning Specialization. Kontynuacja po pierwszej. Dobre fundamenty.
fast.ai Practical Deep Learning for Coders. Bardzo praktyczny kurs Jeremy'ego Howarda, top-down. Po tym kursie potrafisz fine-tuningować modele do realnych zadań. To jest mój top-1 dla osób które już programują i nie chcą tracić tygodni na teorię przed kodem.
„Deep Learning" Goodfellow, Bengio, Courville. Podręcznik referencyjny. Czytasz selektywnie do konkretnych tematów, nie od deski do deski.
Karpathy Neural Networks: Zero to Hero. Najlepszy materiał o tym jak działają sieci od środka. Andrzej Karpathy buduje od micrograd przez nanoGPT do Llamy. Jeśli zrobisz tylko jeden cykl wykładów w całej tej drodze, niech to będzie ten.
Projekty fazy 2. Klasyfikator obrazów na własnych danych (zdjęcia rzeczy które Cię interesują, sklasyfikowane ręcznie), od zbierania danych przez augmentację po fine-tuning ResNet/ViT. Fine-tuning modelu NLP (BERT albo mniejsza Llama) do klasyfikacji tekstu albo NER w specyficznej domenie. Bonus jeśli to po polsku, bo modeli polskich jest mniej więc to bardziej wartościowe niż angielski. Implementacja prostego Transformera od zera w PyTorch żeby naprawdę rozumieć co robi attention.
Faza 3: LLM-y, RAG, agenty (8-12 tygodni)
Ta faza jest najbardziej dynamiczna i to co piszę dziś za pół roku będzie tylko częściowo aktualne. Ale fundamenty są stabilne.
Co warto zrozumieć. Tokenizację (BPE, SentencePiece, jak modele „widzą" tekst). Architekturę transformerów (encoder vs decoder vs encoder-decoder). Pre-training, supervised fine-tuning, RLHF, DPO jako etapy treningu współczesnych LLM-ów. LoRA i QLoRA jako ekonomiczne fine-tuningi, bo full fine-tuning 30B+ modelu wymaga klastra. Quantization (INT8, INT4 i jak to wpływa na jakość). RAG (embedding models, vector databases, retrieval strategies, reranking).
Ewaluacja LLM-ów to hardcore. Klasyczne metryki nie działają, trzeba kombinować z LLM-as-judge, human eval, task-specific benchmarks.
Stack: Hugging Face Transformers plus PEFT do fine-tuningów, vLLM albo TGI do serwowania, Sentence Transformers do embeddings, vector DB (Qdrant, Weaviate, pgvector, wybór mniej istotny niż kiedyś, wszystkie są ok). LangChain albo Llamaindex używaj selektywnie, nie wszystko trzeba przez to robić.
Źródła:
Andrej Karpathy „Let's build GPT" / nanoGPT. Implementacja GPT od zera, najjaśniejsze wyjaśnienie istniejące w internecie.
Hugging Face NLP Course. Darmowy, praktyczny, regularnie aktualizowany.
Maxime Labonne LLM Course na GitHubie. Bardzo praktyczny zbiór notebooków o fine-tuningu, ewaluacji, deploymencie.
Hamel Husain hamel.dev. Najlepsze pisanie o ewaluacji LLM-ów jakie znam. Praktyczne, anty-hype, oparte na realnych wdrożeniach.
Eugene Yan eugeneyan.com. Mocno praktyczne pisanie o ML w produkcji.
Simon Willison simonwillison.net. Codzienny puls tego co dzieje się w LLM-ach, bez hype'u.
Projekty fazy 3. RAG na własnych dokumentach (PDFy techniczne z Twojej dziedziny). Nie kolejny chatbot do dokumentacji, zrób coś z konkretną metryką sukcesu którą da się zmierzyć. Fine-tuning małego modelu (Llama 3.2 3B albo Qwen2.5 3B) do specyficznego zadania, takiego jak generowanie commit messages, klasyfikacja maili, summary techniczne. LoRA, dataset 1-5k przykładów. Ewaluacja własnego systemu, czyli miejsce gdzie 90% projektów upada. Zbuduj eval set, mierz, iteruj.
Faza 4: MLOps i produkcja (równolegle z fazą 2 i 3)
To jest rzecz której nikt nie uczy w bootcampach, a jest najważniejsza zawodowo. Model w Jupyter notebooku to nie ML w produkcji.
Co trzeba znać. Tracking eksperymentów (MLflow, Weights & Biases). Wersjonowanie danych (DVC, Git LFS, S3 z wersjonowaniem). Reprodukowalność (seedy, deterministyczne runy, environment pinning z Poetry albo uv). Serwowanie modeli (FastAPI, BentoML, Ray Serve, vLLM dla LLM-ów). Monitoring, czyli drift detekcja, performance degradation, alerting. A/B testing modeli w produkcji. CI/CD dla modeli, gdzie testy modelu są jak testy kodu.
Źródła:
„Designing Machine Learning Systems" Chip Huyen. Najlepszy podręcznik ML w produkcji.
MadeWithML. Darmowy kurs o MLOps, bardzo praktyczny.
Full Stack Deep Learning. Wykłady o całym stacku DL od strony produkcyjnej.
Rytm pracy, czyli co realnie robić w tygodniu
Roadmapa to za mało jeśli nie ma rytmu pracy. Co u mnie zadziałało i co widzę u ludzi którym się udało wejść w ML.
Codziennie 1-2h, czytanie albo kod. Czytanie samo nie daje umiejętności. Kod bez czytania daje powierzchowne rozumienie. Mix.
Jeden projekt na 4-6 tygodni. Dłuższy niż „zrób klasyfikator" w jeden weekend. Realne projekty w pracy ML trwają tygodnie, ucz się rytmu pracy a nie tylko algorytmów.
Notebook lab plus repo na GitHubie. Wszystko co robisz idzie do publicznego repo. Nie dlatego że ktoś to zobaczy (raczej nie zobaczy), ale dlatego że pisanie kodu który będzie publiczny zmusza do innego standardu.
Feed researcherów. Śledzisz na Twitterze albo Mastodonie kilkanaście osób z dziedziny. Karpathy, Howard, Husain, Yan, Willison, Karras. Nie żeby być na bieżąco z każdą publikacją, ale żeby mieć poczucie pulsu pola.
Kaggle competitions albo open-source contributions. Kalibracja własnych umiejętności wobec innych. Nie dla rankingu, dla informacji zwrotnej.
Jak wygląda realna praca w ML
Roadmapy są abstrakcyjne. „Wytrenuj model klasyfikacji" brzmi jak coś co robisz w popołudnie. W rzeczywistości to są projekty trwające tygodnie albo miesiące, gdzie samo trenowanie modelu zajmuje 20% czasu.
Pokażę pięć typów projektów z różnych poziomów zaawansowania, z czasem trwania, złożonością i pułapkami. Wszystko to rzeczy które albo robiłem sam.
Projekt 1: klasyfikator danych tabelarycznych dla biznesu (poziom junior)
Brief biznesowy. „Mamy dane historyczne klientów, chcemy przewidywać kto zrezygnuje z subskrypcji w następnym miesiącu (churn prediction)."
Czas trwania: 4-8 tygodni dla solo ML engineera.
Co realnie robisz przez te tygodnie. Najpierw tydzień albo dwa rozmów z biznesem żeby zrozumieć co tak naprawdę znaczy „churn". Czy klient który anulował i wrócił to churn? Czy zmiana planu na tańszy to churn? Definicja zmienia model.
Potem dwa tygodnie na dostęp do danych. Bazy są w trzech systemach (CRM, billing, support tickets). Dane są niespójne, bo customer_id w jednym systemie to UUID, w drugim INT. Daty w trzech strefach czasowych. To jest praca ETL której nikt nie uczy na kursach.
Dopiero potem feature engineering. Liczysz cechy w stylu „liczba ticketów support w ostatnich 30/60/90 dniach", „średnia wartość zamówień per kwartał", „dni od ostatniego logowania". To miejsce gdzie wygrywasz lub przegrywasz. Algorytm to 20% jakości, features to 80%.
Trening i walidacja zajmują kolejny tydzień, może dwa. XGBoost albo LightGBM jako default. Ważna rzecz, walidacja temporalna, nie random split, bo dane mają strukturę czasową. Mierzenie precision i recall przy konkretnych progach prawdopodobieństwa.
Potem kalibracja modelu i interpretacja. SHAP values żeby pokazać biznesowi które cechy wpływają na predykcję. Bez tego nikt nie zaufa modelowi, jakkolwiek dobry by nie był.
Na końcu deployment. FastAPI endpoint, batch scoring nightly w Airflow, monitoring drift, alerting.
Pułapki które zaskakują juniorów. Data leakage przez cechy które „znają przyszłość" (total_lifetime_value zawiera dane sprzed eventu churn). Class imbalance, bo 95% klientów nie rezygnuje, więc naive accuracy 95% bez żadnego modelu. Trzeba używać F1, AUC, focal loss albo SMOTE. Concept drift, czyli model trenowany na danych z marca przestaje działać we wrześniu, bo zmieniła się oferta produktowa. Trzeba mieć retrain pipeline.
Stack: Python, pandas, scikit-learn, XGBoost, SHAP, FastAPI, Airflow albo Prefect, MLflow, PostgreSQL.
Projekt 2: pipeline klasyfikacji produktów (poziom mid)
Brief biznesowy. „Dostajemy katalogi produktów od 200 dostawców w różnych formatach. Trzeba je sklasyfikować do naszej taksonomii (5000 kategorii) i wyciągnąć atrybuty (rozmiar, kolor, materiał)."
Czas trwania: 3-6 miesięcy dla zespołu 2-3 osób.
Co realnie robisz. Pierwszy miesiąc to analiza danych wejściowych. Format jest „CSV" tylko z nazwy. Separator różny u każdego dostawcy, encoding pół na pół UTF-8 i Windows-1250, polski i angielski wymieszane, opisy mają HTML-owe tagi, ceny w czterech walutach. Pisanie ekstraktorów per dostawca jest mozolne ale nie da się przeskoczyć.
Potem budowanie taksonomii. Pięć tysięcy kategorii to mnogość, niektóre mają pięć produktów, niektóre pięćdziesiąt tysięcy. Hierarchia w stylu Elektronika → Komputery → Laptopy → Gaming. Decyzja czy klasyfikator hierarchiczny czy flat ma duże konsekwencje na całość pipeline'u.
Pierwszy model bywa wieloetapowym pipeline'em. Najpierw klasyfikacja na 20 głównych kategorii (BERT albo Qwen embeddings plus klasyfikator), potem wewnątrz każdej kategorii drugi klasyfikator. LLM jako fallback dla rzeczy z confidence niższym niż 0.7.
Ekstrakcja atrybutów to zadanie NER. Z tekstu „Bluza męska XL czarna bawełna 100%" wyciągasz strukturę typu {kategoria: bluza, płeć: męska, rozmiar: XL, kolor: czarny, materiał: bawełna 100%}. Fine-tuning XLM-RoBERTa albo LLM z few-shot promptingiem. To miejsce gdzie polskie modele są słabsze niż angielskie i trzeba kombinować.
Potem ewaluacja. Tworzenie eval setu z ręcznie oznakowanymi 2000 produktami. To kosztuje 20-40 tysięcy złotych bo wymaga ekspertów domenowych. Bez tego nie wiesz czy model działa.
Na końcu produkcja. API, batch processing miliona produktów dziennie, monitoring drift, retrain schedule, human-in-the-loop dla edge cases.
Pułapki tej skali projektu. Distribution shift między dostawcami, gdzie model wytrenowany na danych dostawcy A nie działa na dostawcy B. Long tail, czyli 80% produktów to 200 najpopularniejszych kategorii, ale 20% jest w 4800 ogonowych kategoriach z 0-3 przykładów każdy. Few-shot learning, hierarchical fallback, czasem human review. Multilingual, gdzie model który działa po angielsku miażdży się na polskim, bo ma 100x mniej danych w pre-trainingu. Atrybuty są kontekstowe, bo „XL" to rozmiar dla ubrania, ale to też nazwa modelu komputera Dell.
Stack: Python, Hugging Face Transformers, LLM (Claude/GPT albo lokalny Qwen), Qdrant do embeddings, PostgreSQL, Ray do distributed inference, vLLM dla LLM serving, Streamlit dla dashboardu human-in-the-loop.
Projekt 3: system ownership hierarchii dla compliance (poziom mid-senior)
Brief biznesowy. „Banki muszą wiedzieć kto realnie kontroluje firmę-klienta (Ultimate Beneficial Owner). Mamy KRS, źródła otwarte, zagraniczne rejestry. Zbuduj system który dla danej firmy zwraca kto jest właścicielem na każdym poziomie hierarchii."
Czas trwania: 6-12 miesięcy dla zespołu 3-5 osób. To projekt który robiłem dla amerykańskiego klienta.
Pierwsze dwa miesiące to scope. Co znaczy „kontrola"? 25%+ udziałów? Prawo głosu? Beneficial ownership w sensie regulacyjnym (FATF, OFAC)? Każdy region ma inne reguły. Definicja wpływa na wszystko co budujesz dalej.
Potem data ingestion, kolejne dwa miesiące. KRS Polska to pięć milionów wpisów. Companies House UK to cztery miliony. SEC EDGAR to 800 tysięcy. Plus zagraniczne rejestry z kilkudziesięciu jurysdykcji, z których część daje dostęp przez API a część tylko PDF.
Entity resolution to osobny problem na dwa-trzy miesiące. „John Smith" w UK i „Jan Smith" w Polsce to ta sama osoba? „Acme Corp Ltd" i „Acme Corporation Limited" to ta sama firma? Klasyczny problem entity resolution. Fuzzy matching, embeddings, graph-based deduplication.
Graf własności jest modelowany jako graf skierowany ważony, gdzie krawędź to procent udziałów. Algorytmy do znajdowania UBO to właściwie problem grafowy z agregacją wzdłuż ścieżek.
Ostatnie miesiące to orkiestracja agentów LLM. Część informacji jest w niestrukturalnych dokumentach (umowy, sprawozdania finansowe). Agent LLM czyta dokument, ekstrahuje fakty o właścicielstwie, dodaje do grafu z confidence score. Tu wchodzi RAG, tool calling, structured outputs.
Cały czas, nie jednorazowo, ewaluacja przeciwko ręcznie zbudowanemu eval setowi (1000 znanych UBO). Compliance ma niski próg tolerancji błędu.
Pułapki tej klasy projektu. Adversarial data, bo niektóre struktury własnościowe są celowo skomplikowane żeby ukryć UBO. Twój model musi sobie radzić z wrogim środowiskiem. Stale data, czyli informacje w rejestrach są aktualizowane z opóźnieniem, więc trzeba wersjonować graf w czasie. Privacy, gdzie RODO i lokalne odpowiedniki ograniczają jakie dane można przetwarzać. Część musi zostawać on-premise. LLM hallucinations w compliance to katastrofa regulacyjna, więc wszystkie outputy muszą być z citation do źródła.
Stack: Python, Neo4j albo TigerGraph dla grafu, Postgres, Apache Spark dla data ingestion, Hugging Face dla NER, OpenAI/Anthropic API dla agentów, dbt dla transformacji, Airflow, MLflow, własna infrastruktura ewaluacji.
Projekt 4: forecasting biznesowy z foundation models (poziom mid-senior)
Brief biznesowy. „Mamy 5 lat sprzedaży produktów per region per kanał. Chcemy forecast na 12 miesięcy do przodu, dokładniejszy niż obecne 65% MAPE z Excela."
Czas trwania: 2-4 miesiące dla zespołu 1-2 osób.
Pierwsze tygodnie to EDA. Sezonowość, trendy, anomalie (Covid w danych z 2020-2021 burzy wszystko). Hierarchia danych, czyli region, kanał, produkt, SKU. Pytanie czy forecast top-down, bottom-up czy reconciled, ma duże konsekwencje.
Potem baseline. Najpierw ARIMA albo Prophet jako baseline. Bez baseline nie wiesz czy fancy ML faktycznie pomaga. Często baseline jest „dobry enough" dla 70% serii.
Classical ML to LightGBM z lag features, rolling means, kalendarzowymi cechami (święta, weekendy, Black Friday). To wciąż dziś state-of-the-art dla większości real-world forecastingu, mimo że nie brzmi efektownie.
Foundation models są nowością. Chronos od Amazona, TimesFM od Google, Moirai od Salesforce. To pretrenowane modele time-series, zero-shot na nowych seriach, czasem lepsze od trenowanych modeli na małych danych.
Ostatnie tygodnie to ensemble i deployment. Kombinacja Prophet plus LightGBM plus Chronos z meta-learnerem decydującym którego użyć per seria. Cały czas ewaluacja na backtestingu (rolling window), nie na pojedynczym test set.
Pułapki forecastingu. Backtesting z leakage, gdzie używasz cechy „średnia za ostatni rok" w treningu, ale to obejmuje przyszłość względem testu. Subtelne i niszczące. Ewaluacja po MAPE jest problematyczna gdy serie mają wartości bliskie zeru, bo MAPE eksploduje. SMAPE, MASE, zależnie od kontekstu. Foundation models są wolne, bo Chronos to LLM-grade inference, nie zawsze opłaca się ekonomicznie wobec LightGBM który kosztuje 100x mniej.
Stack: Python, pandas, statsmodels, Prophet, LightGBM, Chronos, MLflow, Streamlit dla dashboardu z forecastami.
Projekt 5: RAG dla dokumentacji technicznej (poziom mid)
Brief biznesowy. „Mamy 50 000 stron dokumentacji technicznej i 200 inżynierów którzy tracą 30 minut dziennie szukając informacji. Zrób im chatbota."
Czas trwania: 2-4 miesiące dla 1-2 osób.
Pierwsze dwa tygodnie to ingestion. PDFy techniczne to koszmar. Tabele, schematy, wzory matematyczne, kod inline. PyMuPDF, Marker, czasem Docling. Trzeba sprawdzić jakość ekstrakcji ręcznie na próbce, bo automatyczne metryki nic nie powiedzą.
Potem chunking. To niedoceniana decyzja. Naive split na 512 tokenów niszczy kontekst. Semantic chunking (split na końcu sekcji), hierarchical chunking, parent-child retrieval. Zrobiona źle blokuje wszystko poniżej.
Embeddings i retrieval, kolejne dwa-trzy tygodnie. Wybór modelu embeddingów (BGE, E5, OpenAI). Hybrydowe wyszukiwanie (BM25 plus dense). Reranking (Cohere Rerank albo open-source cross-encoder). Tu jest większość różnicy między „działa" a „nie działa".
Generation z LLM (Claude, GPT, Qwen) z context i query. Prompt engineering, czyli gdzie wstawić retrieved chunks, jak instruować żeby cytował źródła, jak handle'ować przypadek gdy nie ma odpowiedzi.
Ewaluacja to miejsce gdzie 90% RAG-projektów upada. Budujesz eval set z 200 pytaniami i znanymi odpowiedziami. Mierzysz retrieval recall (czy potrzebny chunk jest w top-k), generation faithfulness (czy odpowiedź jest oparta na chunks), answer correctness (czy odpowiedź jest poprawna). Bez tego pieczone gołąbki.
Reszta projektu to iteracja. Logujesz wszystkie zapytania, oznaczasz które poszły źle, identyfikujesz wzorce, poprawiasz. To rytm pracy w produkcji który trwa cały czas życia systemu.
Pułapki RAG-a. LLM halucynuje fakty których nie ma w retrieved chunks. Weryfikacja jest hardcore. Pytania wieloetapowe (multi-hop), w stylu „kto jest dyrektorem produktu X i kiedy ostatnio aktualizował dokumentację Y", wymagają agentowych workflow z multiple retrieval rounds. Stale data, bo dokumentacja się zmienia. Strategia re-indexowania, deduplication wersji. Cost, gdzie przy 200 inżynierach razy 5 zapytań dziennie razy 8000 input tokens (chunks plus system prompt) na Claude Sonnet to jakieś 600 USD miesięcznie tylko za inferencję.
Stack: Python, LangChain albo własna orkiestracja, Qdrant/Weaviate/pgvector, Sentence Transformers, BGE Reranker, Claude/GPT/Qwen API, LangSmith albo Langfuse dla observability, Streamlit/Gradio dla UI.
I:
Modeling to 20% pracy. Reszta to dane, infrastruktura, ewaluacja, integracja, monitoring. Ludzie którzy uczą się tylko modelingu są w pracy bezużyteczni przez pierwsze pół roku, bo nie umieją zrobić nic produkcyjnie.
Każdy projekt zaczyna się od dyskusji co tak naprawdę chcemy zrobić. Brief biznesowy „chcemy AI do X" ma 80% szansy że X jest źle zdefiniowane. ML engineer który pyta i kalibruje wartość dla biznesu jest pięć razy bardziej wartościowy niż ten kto bierze brief jak jest.
Ewaluacja jest najważniejsza i najtrudniejsza. W każdym z tych przykładów ewaluacja zajmuje 30-50% czasu. To miejsce gdzie się odróżnia projekt który działa od projektu który „działa demo a w produkcji się sypie".
To są też projekty które realnie generują wartość biznesową, sumarycznie kilkaset tysięcy do kilku milionów złotych rocznych oszczędności albo przychodu per projekt. ML w 2026 to nie eksperymenty z GPT-4, to systemy które robotyzują procesy o mierzalnej ekonomii.
Czego nauczysz się dopiero w pracy
Roadmapa nauczy Cię ML. Praca w ML uczy innych rzeczy.
Pracy z brudnymi danymi. Każdy publiczny dataset jest ułożony. Realne dane to chaos. Brakujące wartości, błędy w etykietach, drift, sprzeczne źródła. 60% pracy ML engineera to data wrangling, nie modeling.
Komunikacji z biznesem. Stakeholder mówi „chcemy AI" a oczekuje czegoś konkretnego. Tłumaczenie biznesowych potrzeb na ML problem to umiejętność której nie da się nauczyć z książek.
Decydowania kiedy ML to nadgryzienie. Czasem regex i dobrze napisane reguły biją gradient boosting. Senior ML engineer wie kiedy nie używać ML.
Ewaluacji w niepewności. W ML rzadko masz „test pass". Masz „95% accuracy na walidacji, ale dryf po trzech miesiącach". Decyzje pod niepewnością to esencja pracy.
To są rzeczy których nikt nie nauczy Cię na kursie. Jedyna droga to praca, najlepiej z mentorem albo seniorem który Cię koryguje.
Realna ekonomia tej decyzji
Spojrzałem na siebie osiem lat temu, kiedy wchodziłem w to z tłem psychologii klinicznej, i nie żałuję ani jednej godziny. Ale uczciwie powiem że pierwsze dwa lata to była głównie frustracja i syndrom oszusta. Czas zwrotu z inwestycji w ML jest mierzony latami, nie miesiącami.
Jeśli rozważasz tę drogę, sprawdź najpierw czy Cię to interesuje na poziomie „chcę spędzać 10 godzin tygodniowo czytając papers przez rok zanim zarobi mi to grosza". Bo tak to wygląda.
Wynagrodzenie po dojściu do mid-level seniora ML w Polsce jest w 2026 dobre. Top tier kontraktów B2B w okolicy 30-50 tysięcy złotych miesięcznie dla seniora z pięcioma plus latami doświadczenia. FAANG-tier remote z USA jeszcze wyżej. Ale droga do tego punktu jest długa.
Druga uczciwa uwaga. Rynek juniorów ML jest brutalnie konkurencyjny w 2026. Stanowiska junior ML mają 200-500 aplikujących, większość z certyfikatami i bootcampami. Wyróżniasz się realnymi projektami, najlepiej w niszy która Cię odróżnia. U mnie psychologia kliniczna plus NLP, u kolegi muzyka plus audio ML. Generic portfolio z Kaggle competitions już nie wystarcza.
Źródła i lektura
Kursy fundamentalne:
- Andrew Ng Machine Learning Specialization
- Andrew Ng Deep Learning Specialization
- fast.ai Practical Deep Learning for Coders
- Karpathy Neural Networks: Zero to Hero
- Hugging Face NLP Course
Książki:
- „Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow" Aurélien Géron
- „Deep Learning" Goodfellow, Bengio, Courville
- „Designing Machine Learning Systems" Chip Huyen
- „Mathematics for Machine Learning" Deisenroth, Faisal, Ong (do studiowania selektywnego)
Kanały YouTube i blogi:
- 3Blue1Brown
- StatQuest with Josh Starmer
- Andrej Karpathy
- Simon Willison simonwillison.net
- Hamel Husain hamel.dev
- Eugene Yan eugeneyan.com
- Sebastian Raschka magazine.sebastianraschka.com
Praktyka:
Społeczność:
To wszystko. Jeśli zaczynasz dziś i utrzymasz 10-15 godzin tygodniowo przez rok, w kwietniu 2027 będziesz na realnym poziomie junior ML.
