branch · ★★★

ML / AI

This is the ML/AI engineer branch: you teach a machine to find patterns where hard-coded 'if X then Y' rules run out, and you turn that into a working product — from credit scoring and recommendations to LLM assistants. It's the finale of a four-guide series: ML sits on top of everything — data, statistics, engineering. Keep the big truth in mind: the model is 20% of the job; the rest is data, features, honest evaluation, and shipping.

what you do

In practice, 80% of the time isn't 'neural-net magic' — it's data wrangling: cleaning tables, engineering features, training a model, honestly checking it on held-out data, and watching for overfitting. You always start with the simplest baseline and add complexity only when it can't keep up. Then the real work: getting the model into production so it earns its keep instead of rotting in a notebook.

stack

Python + scikit-learn as the foundation; gradient boosting (XGBoost / LightGBM / CatBoost) as the tabular workhorse; PyTorch and Hugging Face for neural nets, CV and NLP; the LLM stack — embeddings, vector DBs (Chroma/Qdrant), RAG, LangChain/LlamaIndex; and for production — MLflow, FastAPI, Docker, and drift monitoring.

who it suits

It fits people for whom 'explaining the past' isn't enough — you want the system itself to make decisions and predict the future. People ready to dig into data, features, and metrics rather than chase headline model names. Especially analysts and data engineers who already have the fundamentals and are looking for the next step.

how it differs

The analyst answers 'what happened and why' and delivers insight to people; the data engineer builds the pipes data flows through reliably; the ML engineer teaches a model to predict and lives with that model in production. The lines blur — recommendations and forecasts are ML on top of analytics, and MLOps is essentially data engineering for models. The key difference: your product isn't a dashboard or a pipeline, it's a trained model that makes decisions on its own.

L0

Your first model in 10 lines

a couple of evenings

Feel the full ML cycle on a ready-made dataset. Don't be scared — it really is ten lines of code, not six months of math.

tool scikit-learn (sklearn) in Jupyter/Colab dataset Any ready-made teaching dataset that interests you — Palmer Penguins, Titanic, Iris. Something small and clear where the answers already exist.
what you do A trained model that makes a prediction, and your first honest metric on data the model has never seen.
Ready for the next level when:
  • You split data into train/test and can explain in your own words why that matters
  • You train a model with a single .fit() call and get predictions via .predict()
  • You compute at least one metric (e.g. accuracy) on the held-out set
  • You can explain what 'accuracy on new data' means and why it beats accuracy on training data
  • You tell apart the three task types (supervised / unsupervised / reinforcement) and know which one yours is
L1

Classic ML on tabular data

2–4 weeks

Take regression and classification seriously: task-appropriate metrics, overfitting, cross-validation. This is where you stop copy-pasting and start understanding.

tool scikit-learn — regressions, trees, metrics, pipelines dataset A real tabular problem you care about: customer churn, scoring, price, demand. Grab data from the data guide (Olist, Telco) or your own.
what you do A solved classification or regression task with a baseline and honest evaluation: model comparison, an ROC curve / error metric, and a verdict on overfitting.
Ready for the next level when:
  • You always build a simple baseline (logistic/linear regression) before adding complexity
  • You pick the metric that fits the task (ROC-AUC / RMSE / accuracy) and can justify the choice
  • You catch overfitting by comparing performance on train vs test
  • You evaluate with cross-validation rather than a single split
  • You prep features: encode categoricals, scale, and handle missing values
  • You read feature importances and understand what drives the prediction
L2

Boosting — king of tabular data

2–3 weeks · the key level

Master what actually wins on structured data — in production and on Kaggle. Straight up: this is the most underrated and best-paid skill in ML.

tool XGBoost / LightGBM / CatBoost + SHAP for interpretation dataset The same tabular task from L1, but now you push it to a strong result. Want a thrill — grab an open Kaggle dataset that interests you.
what you do A boosted tabular model that clearly beats your baseline, with tuned hyperparameters and predictions explained via SHAP.
Ready for the next level when:
  • You train gradient boosting and consistently outperform your baseline
  • You understand the key hyperparameters (n_estimators, learning_rate, max_depth) and tune them deliberately
  • You do feature engineering — new features genuinely lift the metric
  • You explain a specific prediction via SHAP, not 'the model decided so'
  • You choose between XGBoost / LightGBM / CatBoost based on data size and categorical features
  • You spot and remove data leakage in your features
L3

Pick a direction

3–5 weeks

Go deep in one direction: NLP/LLM, computer vision, or recommendations. Don't spread thin — pick what excites you and take it to a working project.

tool PyTorch as the base + domain tools: Hugging Face (text), OpenCV/YOLO (vision), recsys libraries dataset Data from your chosen domain, by interest: text (reviews, articles), images (your own photo set), user×item interactions (MovieLens, Yambda).
what you do A working project in one direction, from raw domain data to a measurable result: a trained/fine-tuned model and a domain metric.
Ready for the next level when:
  • You choose a direction deliberately, matched to your interest and data type
  • You grasp neural-net basics (layers, training loop, loss) in PyTorch
  • You take a pretrained model and adapt it to your task instead of training from scratch
  • You assemble a pipeline from raw domain data through to a result
  • You evaluate with a domain metric (F1 for text, mAP for detection, ranking metrics for recsys)
L4

LLM applications (RAG)

3–4 weeks

Build a genuinely useful AI tool, not an 'API wrapper'. The value goes to those who build reliable systems on their own data, not those who just call someone's GPT.

tool LlamaIndex / LangChain, a vector DB (Chroma/Qdrant), embeddings, Langfuse for evaluation dataset Your own document corpus, by interest: notes, a knowledge base, game reviews, PDFs. Something where the answers are 'hidden' in the text.
what you do A RAG assistant over your data: documents → embeddings → vector DB → retrieval → grounded answer, with an eval attached to measure quality.
Ready for the next level when:
  • You build the full RAG loop: documents → embeddings → vector DB → retrieval → answer
  • You understand why an LLM hallucinates and how grounding in your data fixes it
  • You write working prompts and keep the ladder in mind: prompt → RAG → and only then fine-tuning
  • You measure answer quality with an eval, not 'by eye'
  • You deliberately choose between a closed API model and open-weight based on cost/privacy
  • You understand what an agent is (LLM + tools) and when it's actually warranted
L5

Production and MLOps

the finish · model in the wild

Get the model to production: serving, monitoring, drift, retraining. A model in a notebook is worthless — value shows up when it lives and doesn't decay.

tool MLflow, FastAPI, Docker, drift monitoring; orchestration (Airflow/Prefect) for retraining dataset Your own model from the earlier levels — you put it in front of a real request stream via API or batch.
what you do A model behind an API with versioning, metrics and a degradation alert, retrained on a schedule instead of rotting in a notebook.

Finish: The model lives in production and retrains itself instead of gathering dust in a notebook.

  • You log experiments and version models in a registry (MLflow)
  • You serve predictions via an API (FastAPI) or batch — matched to the task
  • You pick a safe rollout pattern: canary / shadow / A-B
  • You monitor data drift and set an alert for silent quality decay
  • You set up retraining through orchestration, not by hand
  • You understand how MLOps ties to data engineering: Docker, pipelines, feature store