Machine Learning Foundations

A beginner-friendly course that explains what machine learning is, how common algorithms work, and how to build and evaluate simple models. You will learn core concepts, practical workflows, and the most important pitfalls to avoid.

1. What Machine Learning Is and When to Use It

What Machine Learning Is and When to Use It

Machine Learning (ML) is a way to build systems that learn patterns from data to make predictions or decisions, instead of being explicitly programmed with a long list of rules.

A useful mental model:

  • Traditional programming: you write rules; the computer follows them.
  • Machine learning: you provide examples; the system learns a rule-like function from them.
  • What “learning” means in ML

    In ML, we usually assume there is some relationship between inputs (information you have) and outputs (what you want). The goal is to learn a function that maps inputs to outputs.

    A common way to express this is:

    Explanation of each part:

  • = the input (also called features), e.g., a customer’s past purchases.
  • = the model (the learned mapping), e.g., a decision tree or a linear model.
  • = the prediction (the model’s output), e.g., “will churn” or “won’t churn.”
  • The model is learned from a dataset of past examples. In supervised learning, those examples typically include:

  • Features: what you know at prediction time
  • Labels: what actually happened (the “correct answer”)
  • The key idea is generalization: performing well not just on past data, but on new, unseen cases.

    The main families of machine learning (high-level)

  • Supervised learning: learn from labeled examples.
  • - Use cases: spam detection, house price prediction, medical risk estimation.
  • Unsupervised learning: find structure without labels.
  • - Use cases: customer segmentation, anomaly detection, discovering topics in text.
  • Reinforcement learning: learn actions by trial-and-error with rewards.
  • - Use cases: game-playing agents, robotics control, adaptive resource allocation.

    You don’t need to memorize these categories; what matters is recognizing what kind of feedback your problem provides: labels, structure, or rewards.

    A practical ML workflow (conceptual)

    ML is not just “training a model.” It is an end-to-end process where data quality and evaluation often matter more than fancy algorithms.

    When machine learning is a good fit

    Use ML when at least one of these is true:

  • Rules are hard to write: The logic is complex, fuzzy, or full of exceptions.
  • - Example: classifying images of defective parts—writing explicit rules for all defect types is impractical.
  • Patterns change over time: A hand-coded rule system becomes outdated.
  • - Example: fraud patterns evolve; models can be retrained.
  • You have lots of examples: You can learn from historical data.
  • - Example: predicting delivery times from millions of past deliveries.
  • You can define success clearly: There is a measurable objective.
  • - Example: reduce false positives in spam filtering while keeping high recall.
  • Some error is acceptable: ML outputs are probabilistic and can be wrong.
  • - Example: recommending products; an imperfect suggestion is tolerable.

    When not to use machine learning

    ML is often the wrong tool when:

  • A simple rule works: If the logic is stable and easy to specify, rules are cheaper and more reliable.
  • - Example: “If a user is under 13, block account creation.”
  • You don’t have the right data: No sufficient examples, no reliable labels, or the features needed are missing.
  • You can’t tolerate errors: If mistakes are catastrophic, you may need deterministic logic, strong verification, or human review.
  • The problem is about policy, not prediction: ML can estimate outcomes, but it cannot decide what is fair or acceptable on its own.
  • The environment changes faster than you can adapt: If data drifts daily and you can’t monitor/retrain, ML may degrade silently.
  • Common misconceptions to avoid

  • “More data always wins.” More relevant, clean, representative data wins.
  • “A high score means we’re done.” A model can score well in testing but fail in the real world due to data shifts or biased sampling.
  • “ML finds truth.” ML finds patterns in your dataset—which may include noise, bias, or historical unfairness.
  • “The algorithm is the main decision.” Often, the biggest impact comes from defining the target properly and collecting the right data.
  • A quick decision checklist

    Ask these questions before choosing ML:

  • What is the decision/prediction, in one sentence?
  • What input information will you have at the moment you need the prediction?
  • Do you have historical examples that connect inputs to outcomes?
  • How will you measure success (and what errors are most costly)?
  • What will you do when the model is uncertain or wrong?
  • If you can’t answer these clearly, you likely need to clarify the problem or improve data readiness before building a model.

    ---

    Practice tasks

  • Classify each scenario as: Best with rules, Good ML candidate, or Needs more info.
  • 1. Blocking access when a password is entered incorrectly 10 times. 2. Predicting which customers are likely to cancel a subscription next month. 3. Identifying “suspicious” transactions when you have almost no labeled fraud examples.

  • For the statement , explain what , , and could be in a movie recommendation setting.
  • List two reasons why an ML model that performed well last year might perform worse today.
  • <details> <summary> Answers </summary>

    1. 1. Best with rules (clear threshold, deterministic policy). 2. Good ML candidate (historical behavior can be predictive; patterns can be complex). 3. Needs more info (could use unsupervised/anomaly methods, but lack of labels makes supervised fraud detection hard; you’d need alternative signals, labeling strategy, or a different approach).

  • Example mapping:
  • - (inputs/features): user watch history, ratings, time of day, device type. - (model): the learned recommender that maps user/context to a score per movie. - (prediction): predicted rating, click probability, or a ranked list of movies.

  • Two common reasons:
  • 1. Data drift / concept drift: user behavior or the underlying system changed (pricing, competitors, new product features). 2. Pipeline or sampling changes: data collection or definitions changed (new tracking events, label definition updated, missing values increased).

    </details>

    2. Data Basics: Features, Labels, and Data Splits

    Data Basics: Features, Labels, and Data Splits

    In the previous article, you saw the core supervised-learning idea: learn a mapping from inputs to outputs. This article focuses on what those “inputs” and “outputs” look like in real datasets, and how to split data so your evaluation reflects reality.

    1) Features: what the model is allowed to know

    Features are the pieces of information you will have at prediction time and feed into a model.

    A single example (one row) usually looks like:

  • Numeric features: age, balance, number of logins
  • Categorical features: country, device type, plan tier
  • Text/image/audio features: raw content or embeddings (still “features,” just higher-dimensional)
  • Derived features: ratios, counts over windows, “days since last purchase”
  • The “prediction-time availability” rule

    A feature is valid only if it is available at the moment you want to make the prediction.

    Example: predicting whether a customer will churn next month.

  • Valid: number of support tickets so far, last login date, current plan
  • Invalid: “canceled_date” (you only know it after churn happens)
  • Violating this rule creates data leakage: the model learns from information that would not exist in the real decision.

    Feature vs. identifier

    Some columns are technically available but still harmful:

  • Unique IDs (user_id, order_id) rarely generalize; they encourage memorization.
  • High-cardinality tokens (exact URL, exact device fingerprint) can act like IDs.
  • A safe question: Would this column help a human make the prediction for a new case, or does it just name the case?

    2) Labels (targets): what you want to predict

    A label (also called the target) is the outcome you want the model to learn.

  • Classification labels: discrete classes (spam vs. not spam)
  • Regression labels: continuous values (delivery time in minutes)
  • Label definition is a product decision

    Labels are not “found,” they’re defined. Small wording changes can create a different problem:

  • “Churn” could mean cancel within 30 days or no activity for 60 days.
  • Fraud labels might represent confirmed fraud, not all fraud.
  • Good labels are:

  • Observable: you can measure them reliably.
  • Timely: you can get them soon enough to train and update models.
  • Aligned: they reflect the business goal (not a proxy that drifts away).
  • Common label pitfalls

  • Label leakage via timing: using information recorded after the event.
  • Noisy labels: human error, ambiguous cases, inconsistent rules.
  • Class imbalance: one outcome is rare (e.g., 0.2% fraud). Accuracy can look great while the model is useless.
  • 3) One dataset, many representations

    Most supervised datasets can be viewed as pairs .

  • means “the i-th example” (one row).
  • is the feature set for that row.
  • is the label for that row.
  • This notation is just a compact way to say: “for each row, we have inputs and the correct output.”

    4) Data splits: train, validation, test

    To measure generalization, you evaluate on data the model did not train on.

    Typical splits:

  • Training set: used to fit model parameters.
  • Validation set: used to choose between options (features, hyperparameters, thresholds).
  • Test set: used once at the end for an unbiased estimate.
  • A simple flow:

    Why three splits?

    If you repeatedly “peek” at the test set while making decisions, you slowly tailor the system to that test set. The score becomes optimistic, even if you never explicitly train on it.

    5) How to split correctly (common scenarios)

    Random split (IID assumption)

    Works when examples are well-mixed and independent (e.g., many unrelated customers).

    Tip: For classification, use stratified splitting so class proportions stay similar across splits.

    Time-based split (for forecasting and evolving behavior)

    If your model predicts the future, your split should reflect time:

  • Train on earlier period
  • Validate on later period
  • Test on the most recent period
  • This reduces leakage from “future patterns” and better simulates deployment.

    Group-based split (avoid near-duplicates)

    If multiple rows come from the same entity (user, device, patient, household), don’t let the same group appear in both train and test.

    Otherwise, the model can recognize the entity rather than learn general patterns.

    6) A quick split-and-leakage checklist

  • Are all features available at prediction time?
  • Did you accidentally include “future” columns (timestamps after the event, outcomes, resolutions)?
  • Are there duplicates or near-duplicates crossing splits?
  • Should you split by time or by group instead of randomly?
  • Did you reserve the test set and avoid using it for decisions?
  • ---

    Practice tasks

  • For each column below in a churn prediction task (“Will the user churn next month?”), mark it as Valid feature, Leakage, or Probably an identifier:
  • 1. days_since_last_login 2. cancellation_date 3. user_id 4. number_of_support_tickets_last_30d

  • You have transaction data where each customer generates many rows. You randomly split rows into train/test and get an excellent score. Name one reason this could be misleading, and propose a better split.
  • Choose the best split type (random, time-based, or group-based) for each situation:
  • 1. Predicting next week’s demand using daily sales data from the last 2 years. 2. Classifying whether an email is spam, where emails are independent. 3. Predicting hospital readmission when each patient has multiple visits.

    <details> <summary> Answers </summary>

    1. 1. Valid feature (known at prediction time; summarizes recent behavior) 2. Leakage (only known after churn/cancellation occurs) 3. Probably an identifier (encourages memorization; rarely generalizes) 4. Valid feature (available from past records)

  • Misleading reason: rows from the same customer appear in both train and test, so the model can “recognize” customers rather than learn general churn patterns. Better split: group-based split by customer_id, keeping each customer entirely in one split.
  • 3. 1. Time-based (future prediction; avoid training on later data) 2. Random (IID is reasonable; optionally stratify if imbalanced) 3. Group-based (avoid patient overlap across splits)

    </details>

    3. Core Algorithms: Regression, Classification, and Clustering

    Core Algorithms: Regression, Classification, and Clustering

    Три самых базовых типа задач в ML отличаются тем, какой вид ответа вы хотите получить:

  • Regression (регрессия): предсказать число.
  • Classification (классификация): выбрать класс (категорию).
  • Clustering (кластеризация): сгруппировать объекты без заранее заданных классов.
  • (Про то, как формировать признаки/метки и как честно делить данные на train/val/test, см. предыдущие статьи.)

    ---

    1) Regression: предсказываем непрерывное значение

    Что на выходе: число (например, цена, время, спрос).

    Интуиция

    Модель строит функцию, которая для объекта с признаками выдаёт предсказание ("y с крышкой" — предсказанное значение). Ошибка — насколько отличается от истинного .

    Типичные алгоритмы

  • Линейная регрессия
  • - Идея: зависимость примерно линейная; вклад каждого признака складывается. - Плюсы: быстро, интерпретируемо. - Минусы: плохо ловит сложные нелинейности без инженерии признаков.

  • Деревья решений (Regression Tree) и ансамбли (Random Forest / Gradient Boosting)
  • - Идея: серия "если… то…" разбиений пространства признаков. - Плюсы: хорошо ловят нелинейности, устойчивы к разным типам признаков. - Минусы: одиночные деревья легко переобучаются; ансамбли сложнее объяснять.

  • kNN-регрессия
  • - Идея: ответ — среднее (или взвешенное среднее) по ближайшим объектам. - Плюсы: проста. - Минусы: требовательна к масштабу признаков и к размеру данных.

    Как обучается (идея через функцию ошибки)

    Часто используют среднеквадратичную ошибку:

    Пояснения:

  • — число объектов в обучающем наборе.
  • — индекс объекта.
  • — истинное значение для объекта .
  • — предсказание модели для объекта .
  • — ошибка на объекте.
  • Квадрат сильнее штрафует большие промахи.
  • ---

    2) Classification: выбираем класс (и часто вероятность)

    Что на выходе: класс (например, "спам/не спам") или вероятность класса.

    Интуиция

    Классификатор часто сначала оценивает вероятность положительного класса , а затем превращает её в метку по порогу (например, 0.5). Порог почти всегда — бизнес-решение: что дороже, ложная тревога или пропуск события.

    Типичные алгоритмы

  • Логистическая регрессия
  • - Несмотря на название, это классификация. - Выдаёт вероятность; хорошо работает как сильный базовый метод.

    Вероятность часто задаётся через сигмоиду:

    Пояснения:

  • — предсказанная вероятность положительного класса.
  • — «сырое» число, которое модель вычисляет из признаков (часто взвешенная сумма).
  • — математическая константа (основание натурального логарифма).
  • переводит любое в диапазон от 0 до 1.
  • Деревья решений и ансамбли
  • - Часто дают отличный старт на табличных данных.

  • SVM (метод опорных векторов)
  • - Хорош для задач с чёткой границей классов; чувствителен к настройкам и масштабу.

  • kNN-классификация
  • - Класс определяется по большинству среди ближайших.

    Как оценивать (кратко, по смыслу)

  • Accuracy — доля верных ответов (опасна при дисбалансе классов).
  • Precision / Recall — полезны, когда важны ложные срабатывания или пропуски.
  • ROC-AUC — качество ранжирования по вероятностям.
  • ---

    3) Clustering: группируем без меток

    Что на выходе: номер группы (кластера) для каждого объекта или структура групп.

    Интуиция

    Вы не знаете правильных ответов заранее. Вы пытаетесь найти "естественные" группы по похожести. Кластеры — это гипотеза о структуре данных, а не истина.

    Типичные алгоритмы

  • k-means
  • - Требует заранее выбрать число кластеров . - Находит центры кластеров и относит каждый объект к ближайшему центру. - Лучше работает, когда кластеры примерно "шарообразные" и масштабы признаков сопоставимы.

  • Иерархическая кластеризация
  • - Строит дерево объединений (можно выбрать уровень детализации). - Удобна для анализа, но может быть тяжёлой на больших данных.

  • DBSCAN
  • - Ищет плотные области; может находить кластеры сложной формы. - Умеет выделять шум (объекты, не принадлежащие кластерам).

    Текстовая визуализация идеи кластеров:

    Как понять, что кластеризация «полезна»

  • Интерпретируемость: можно ли описать кластеры человеческими признаками?
  • Стабильность: кластеры сильно меняются при небольших изменениях данных/параметров?
  • Практическая проверка: помогают ли кластеры в задаче (сегментация, рекомендации, поиск аномалий)?
  • ---

    4) Как выбирать базовый алгоритм (правила-подсказки)

  • Если нужен простой и объяснимый baseline: линейная/логистическая регрессия.
  • Если данные табличные и зависимость сложная: деревья и ансамбли.
  • Если важна геометрия расстояний (kNN, k-means): следите за масштабом признаков (нормализация часто критична).
  • Если классы/кластеры не «круглые»: попробуйте методы, устойчивые к форме (DBSCAN, ансамбли деревьев).
  • ---

    Practice tasks

  • Определите тип задачи (regression/classification/clustering):
  • 1) прогноз времени доставки в минутах; 2) определить, является ли письмо спамом; 3) сегментировать пользователей по поведению без меток.

  • Почему accuracy может быть плохой метрикой при редком положительном классе (например, 1% событий)? Назовите две более информативные альтернативы.
  • В k-means нужно выбрать . Назовите два практических способа/подхода, как подобрать без знания истинных меток.
  • Для каждой пары «задача → алгоритм» скажите, выглядит ли выбор разумным (да/нет) и почему:
  • 1) регрессия → логистическая регрессия 2) классификация на табличных данных → градиентный бустинг по деревьям 3) кластеризация сложной формы с шумом → DBSCAN

    <details> <summary> Ответы </summary>

    1. 1) regression (число) 2) classification (класс) 3) clustering (группы без меток)

    2. - При 1% событий модель, которая всегда отвечает «нет», даст 99% accuracy, но будет бесполезной. - Альтернативы: precision/recall (или F1), ROC-AUC (ещё часто используют PR-AUC).

    3. - «Elbow method» по инерции/внутрикластерной дисперсии: искать точку, после которой улучшение замедляется. - Проверка полезности/интерпретируемости кластеров для задачи (например, сегменты различимы по ключевым признакам и дают разные бизнес-метрики). Дополнительно: метрики вроде silhouette score.

    4. 1) Нет: логистическая регрессия решает классификацию, а не предсказание непрерывного числа. 2) Да: бустинг по деревьям часто даёт сильное качество на табличных данных и хорошо ловит нелинейности. 3) Да: DBSCAN рассчитан на кластеры произвольной формы и умеет отделять шум.

    </details>

    4. Training Models: Loss Functions and Optimization

    Training Models: Loss Functions and Optimization

    Обучение модели — это процесс подбора её параметров так, чтобы предсказания были «как можно ближе» к правильным ответам на обучающих примерах. В предыдущих статьях мы говорили, что важно честно разделять данные и избегать утечек; здесь фокус — как именно модель учится на train.

    1) Идея обучения: минимизируем ошибку на данных

    Почти всегда обучение формулируется как задача минимизации функции потерь (loss): она измеряет, насколько плохи предсказания.

    Часто оптимизируют среднюю потерю по обучающей выборке:

    Разберём обозначения:

  • — итоговая «стоимость» (objective), которую мы хотим сделать маленькой.
  • — параметры модели (например, веса в линейной/логистической регрессии, параметры дерева/ансамбля и т.д.).
  • — число объектов в обучающем наборе.
  • — индекс объекта.
  • — истинная метка объекта .
  • — предсказание модели для объекта .
  • — потеря на одном объекте (насколько ошиблись именно на нём).
  • Важно: минимизация на train не гарантирует качества на новых данных — поэтому нужны валидация/тест и правильные разбиения (см. статью про data splits).

    2) Функции потерь: что именно считается «ошибкой»

    Правильная потеря зависит от типа задачи и от того, что вы хотите «наказать» сильнее.

    Регрессия

  • MSE (Mean Squared Error) — средний квадрат ошибки.
  • - Сильнее штрафует большие промахи. - Хорошо, если большие ошибки особенно болезненны.

  • MAE (Mean Absolute Error) — средняя абсолютная ошибка.
  • - Более устойчив к выбросам (outliers), чем MSE. - Ошибка растёт линейно, а не квадратично.

    Практическая подсказка: если в данных бывают редкие «очень большие» значения (выбросы), MAE часто ведёт себя стабильнее.

    Бинарная классификация (0/1)

    Часто модель предсказывает вероятность положительного класса , а не сразу 0/1. Популярная потеря — логистическая (log loss), она же бинарная кросс-энтропия:

    Объяснение частей:

  • — истинный класс (0 или 1).
  • — предсказанная вероятность класса 1 (число от 0 до 1).
  • — «награда/штраф» за уверенность: если вы уверены в правильном классе, потеря мала.
  • Минус перед скобками делает так, что более правильные вероятности дают меньшую потерю.
  • Интуиция: эта потеря сильно наказывает «уверенные, но неправильные» ответы (например, при ).

    Многоклассовая классификация

    Используют кросс-энтропию по всем классам (модель выдаёт распределение вероятностей). Главная идея та же: поощряем высокую вероятность у истинного класса.

    3) Оптимизация: как находят параметры, уменьшающие потерю

    Когда есть функция , нужно найти такие параметры , чтобы стала минимальной. Для многих моделей это делают итеративно с помощью градиентных методов.

    Градиентный спуск (Gradient Descent)

    Базовое правило обновления параметров:

    Пояснения:

  • — текущие параметры.
  • Стрелка означает «заменить текущие параметры новыми».
  • learning rate (шаг обучения): насколько большой шаг делаем.
  • — градиент (вектор направлений, куда растёт быстрее всего).
  • Знак «минус» означает: идём против градиента, то есть уменьшаем .
  • Batch vs mini-batch vs SGD

  • Batch GD: градиент считается по всем объектам.
  • - Стабильно, но может быть медленно на больших данных.
  • Stochastic GD (SGD): обновление по одному объекту.
  • - Быстро и «шумно», может лучше выходить из плато.
  • Mini-batch: компромисс (например, 32–1024 объектов в батче).
  • - Самый распространённый вариант на практике.

    Текстовая схема:

    Почему learning rate так важен

  • Слишком большой :
  • 1) обучение «скачет» и не сходится; 2) loss может расти.
  • Слишком маленький :
  • 1) обучение идёт очень медленно; 2) может «застрять» в слабом решении из-за ограничения времени/итераций.

    На практике часто используют адаптивные методы (например, Adam) и/или расписания изменения шага, но смысл остаётся тем же: контролировать размер и устойчивость шагов.

    4) Регуляризация и ранняя остановка: как не переобучиться

    Минимизировать loss на train легко; сложнее — сохранить качество на новых данных.

    L2-регуляризация (weight decay)

    К исходной цели добавляют штраф за большие веса:

    Разбор:

  • — средняя потеря на данных.
  • — сумма квадратов параметров (мера «размера» весов).
  • — сила регуляризации: больше → сильнее стремимся к простым (маленьким) весам.
  • Интуиция: мы платим «налог» за слишком сложное решение, что часто улучшает обобщение.

    Early stopping

    Если качество на validation перестало улучшаться, обучение останавливают до того, как модель начнёт подгоняться под шум train. Это особенно полезно для итеративных методов.

    5) Частые практические ошибки

  • Оптимизируют не ту цель: loss не соответствует реальной стоимости ошибок (например, пропуск мошенничества намного дороже ложной тревоги).
  • Слишком много «тюнинга» по test: итоговая оценка становится завышенной (test должен быть финальной проверкой).
  • Неправильный масштаб признаков для градиентных методов: обучение может быть нестабильным или очень медленным.
  • ---

    Practice tasks

  • Выберите более подходящую потерю и объясните почему:
  • 1) прогноз цены квартиры, где иногда встречаются «аномально дорогие» объекты; 2) бинарная классификация, где модель должна выдавать калиброванные вероятности.

  • В формуле объясните смысл и что произойдёт, если выбрать его слишком большим.
  • Что такое mini-batch обучение и почему его часто выбирают вместо чистого batch или чистого SGD?
  • Вам дали две модели. У первой loss на train очень низкий, но на validation заметно хуже. У второй loss на train выше, но на validation лучше. Какую вероятнее стоит выбрать и почему?
  • Что делает L2-регуляризация на интуитивном уровне? Как влияет увеличение ?
  • <details> <summary> Ответы </summary>

    1. 1) Часто MAE: она менее чувствительна к редким выбросам (аномально дорогим объектам), чем MSE. 2) Log loss / кросс-энтропия: она напрямую работает с вероятностями и сильно штрафует уверенные неправильные предсказания.

    2. - — размер шага обновления параметров. - Если слишком большой, обновления будут «перепрыгивать» минимум: loss может колебаться или даже расти, обучение станет нестабильным.

    3. - Mini-batch: градиент считают по небольшому подмножеству данных (например, 128 примеров) и делают обновление. - Почему часто выбирают: это баланс между скоростью (быстрее, чем full batch на огромных данных) и стабильностью (меньше шума, чем SGD по одному примеру).

    4. - Чаще выбирают вторую: цель — обобщение на новых данных, а validation лучше отражает это. - Первая выглядит как переобучение (модель «выучила» train и хуже переносит знания).

    5. - L2-регуляризация поощряет «простые» решения с меньшими весами и снижает склонность подгонять шум. - Чем больше , тем сильнее штраф за большие веса: модель становится более «сглаженной», иногда ценой недообучения, если слишком велик.

    </details>

    5. Model Evaluation: Metrics, Validation, and Overfitting

    Model Evaluation: Metrics, Validation, and Overfitting

    Оценка модели отвечает на главный практический вопрос: насколько хорошо она будет работать на новых данных. Обучение минимизирует loss на train (см. статью про loss и оптимизацию), но качество продукта определяет именно валидация и корректные метрики. Про базовые разбиения train/val/test и утечки данных см. статью про data splits — здесь будем говорить, что считать хорошим качеством и как не обмануться.

    1) Метрики: что значит «хорошо»

    Классификация: начните с матрицы ошибок

    Большинство метрик для бинарной классификации выводятся из confusion matrix:

    | | Истина: 1 | Истина: 0 | |---|---:|---:| | Предсказали 1 | TP | FP | | Предсказали 0 | FN | TN |

    Расшифровка:

  • TP (true positive) — правильно нашли «1».
  • FP (false positive) — ложная тревога: предсказали «1», но истина «0».
  • FN (false negative) — пропуск события: предсказали «0», но истина «1».
  • TN (true negative) — правильно нашли «0».
  • Ключевые метрики:

  • Precision — насколько «чистые» ваши срабатывания:
  • Пояснения: 1) — верные срабатывания; 2) — ложные срабатывания; 3) — все случаи, когда модель сказала «1».

  • Recall — насколько хорошо вы находите событие:
  • Пояснения: 1) — найденные реальные «1»; 2) — пропущенные реальные «1»; 3) — все реальные случаи класса «1».

  • F1-score — компромисс между precision и recall (полезен, когда важны оба):
  • Пояснения: 1) — precision; 2) — recall; 3) множитель делает среднее «гармоническим», сильнее наказывая перекос (например, высокий recall при очень низком precision).

  • ROC-AUC — качество ранжирования: насколько модель ставит объекты класса 1 выше, чем класса 0. Хорошо, когда важен общий ранжирующий сигнал.
  • PR-AUC — часто информативнее ROC-AUC при сильном дисбалансе (редких событиях), потому что фокусируется на precision/recall.
  • Важно: accuracy может быть бесполезной при редком событии (например, 1% «1»). Модель, которая всегда отвечает «0», даст 99% accuracy и 0% пользы.

    Регрессия: измеряйте ошибку в «понятных единицах»

    Для регрессии чаще всего выбирают метрику, которая соответствует стоимости ошибки:

  • MAE — средняя абсолютная ошибка: «в среднем промахиваемся на X единиц». Хорошо читается и устойчивее к выбросам.
  • RMSE — корень из средней квадратичной ошибки: сильнее наказывает большие промахи. Полезно, если большие ошибки особенно болезненны.
  • MAPE/SMAPE (осторожно) — ошибки в процентах; могут плохо вести себя при малых истинных значениях.
  • Практическое правило: выбирайте метрику так, чтобы её можно было перевести в последствия: деньги, время, риски, нагрузку на поддержку.

    2) Вероятности, порог и «рабочая точка»

    Многие классификаторы выдают вероятность , а класс получается через порог (например, 0.5). Порог — не «настройка модели», а решение о компромиссе:

  • Ниже порог → больше срабатываний: recall растёт, но precision может падать.
  • Выше порог → меньше срабатываний: precision растёт, но увеличиваются пропуски (FN).
  • Выбирайте порог на validation под вашу стоимость ошибок. Удобный приём — мысленно задать «цену» FP и FN и подобрать порог, где ожидаемые потери минимальны.

    Отдельная тема — калибровка вероятностей: две модели могут иметь одинаковый ROC-AUC, но одна выдаёт вероятности, которым можно доверять (например, «0.8 ≈ 80% случаев действительно 1»), а другая — нет. Если вы принимаете решения по риску, калибровка критична.

    3) Валидация: как сравнивать модели честно

    Вы уже знаете идею train/val/test. Теперь — про выбор процедуры сравнения:

  • Holdout (одно разбиение) — быстрее всего; подходит при большом датасете.
  • K-fold cross-validation — данные делятся на частей; модель обучается раз, каждый раз с новым «валидационным» фолдом. Это снижает случайность оценки, особенно на небольших данных.
  • Настройка гиперпараметров: любые решения (признаки, порог, регуляризация, выбор алгоритма) должны приниматься по train+validation (или CV). Test — только финальная проверка.
  • Если ваши данные имеют время или группы (пользователь/пациент), применяйте соответствующие разбиения (см. статью про splits). Иначе вы получите оптимистичную оценку.

    4) Переобучение: как распознать и что делать

    Overfitting — модель отлично объясняет train, но хуже работает на новых данных.

    Типичные симптомы:

  • Большой разрыв: качество на train сильно лучше, чем на validation.
  • Улучшения на train продолжаются, а на validation уже нет (или становится хуже).
  • Текстовая «картинка» паттерна:

    Что обычно помогает:

  • Упростить модель или усилить регуляризацию (см. статью про регуляризацию).
  • Добавить данных или улучшить их репрезентативность.
  • Убрать утечки и «почти-идентификаторы» (см. статью про features/leakage).
  • Использовать early stopping, если обучение итеративное.
  • Отдельная ловушка: "overfitting на validation". Если вы пробуете десятки вариантов и выбираете лучший по одной и той же валидации, вы подгоняете решение под неё. Лечение: аккуратнее с количеством итераций, использовать CV, держать test «священным».

    5) Мини-чеклист перед тем как поверить метрике

  • Метрика соответствует реальной цене ошибок?
  • Процедура валидации отражает реальность (время/группы)?
  • Порог выбран на validation, а не «на глаз» по test?
  • Нет ли утечек или дублей между сплитами?
  • Стабильна ли оценка (доверяете ли вы одной случайной разбивке)?
  • ---

    Practice tasks

  • У вас редкое событие (0.5% положительных). Какая метрика/кривая чаще будет более информативной: ROC-AUC или PR-AUC? Почему?
  • Дана confusion matrix: TP=40, FP=60, FN=10, TN=890. Посчитайте precision и recall.
  • Вы выбираете порог для модели мошенничества. Что скорее важнее: precision или recall, если пропуск мошенничества стоит дорого, а ручная проверка ложных тревог дёшева?
  • На train метрика растёт, на validation сначала растёт, потом падает. Что это похоже и какое простое действие можно сделать без смены модели?
  • Вы сравнили 30 вариантов и выбрали лучший по одной validation-выборке. Какой риск возникает и как его снизить?
  • <details> <summary> Ответы </summary>

  • PR-AUC. При сильном дисбалансе ROC-AUC может выглядеть «хорошо» даже у модели, которая даёт много ложных срабатываний; PR-AUC напрямую отражает компромисс precision/recall для редкого класса.
  • 2.

  • .
  • .
  • Чаще важнее recall: лучше поймать максимум мошенничества ценой дополнительных ложных тревог (которые дешево проверять).
  • Похоже на переобучение. Простое действие: применить early stopping (остановиться на лучшей точке по validation) или усилить регуляризацию.
  • Риск: подгонка под validation (оптимистичная оценка, которая не повторится на новых данных). Снижение риска: использовать k-fold CV для выбора, ограничить количество «попыток», и держать test только для финальной проверки.
  • </details>

    6. Feature Engineering and Basic Preprocessing

    Feature Engineering and Basic Preprocessing

    Хорошие признаки часто дают больший прирост качества, чем замена «одного алгоритма на другой». Feature engineering — это превращение сырых данных в представление, с которым выбранная модель может эффективно работать. Preprocessing — базовые преобразования: обработка пропусков, кодирование категорий, масштабирование чисел и т.п.

    Важно: проверяйте доступность признаков на момент предсказания и корректные разбиения (см. статьи про features/leakage и data splits). В этой статье фокус — как превращать данные в рабочие признаки.

    1) Базовое правило: всё «учим» только на train

    Многие преобразования требуют подбора параметров из данных: среднее для заполнения пропусков, список категорий, параметры масштабирования.

    Правило:

  • На train: вычисляем параметры преобразований.
  • На validation/test: применяем только уже вычисленные параметры.
  • Иначе возникает утечка: даже «безобидное» знание средних/частот по test делает оценку оптимистичной.

    Текстовая схема:

    2) Числовые признаки: масштаб, выбросы, нелинейности

    Масштабирование (когда нужно)

    Некоторые модели чувствительны к масштабу признаков (например, kNN, SVM, градиентные методы). Для деревьев решений и их ансамблей масштабирование обычно не критично.

    Два типовых подхода:

  • Стандартизация (привести к «сопоставимому масштабу»).
  • - Часто описывается формулой . - Где: 1) — исходное значение признака; 2) — среднее по train; 3) — стандартное отклонение по train; 4) — преобразованное значение (безразмерное).
  • Нормализация к диапазону (например, 0…1) — полезна, когда важны границы или интерпретация «доли от максимума».
  • Выбросы

    Если редкие экстремальные значения ломают масштаб (например, «очень большие суммы»), практичные приёмы:

  • Лог-преобразование (для строго положительных величин) — сжимает большие значения.
  • Ограничение (winsorization/clipping) — обрезать значения выше/ниже разумных порогов.
  • Использовать устойчивые статистики (медиана/квантили) для заполнения и масштабирования.
  • Нелинейности

    Если эффект признака «не линейный» (например, рост дохода важен до определённого уровня), иногда помогает:

  • Биннинг (разбиение на интервалы).
  • Нелинейные преобразования (лог, корень).
  • 3) Пропуски: не просто «удалить строки»

    Стратегия зависит от смысла пропуска.

  • Заполнение (imputation):
  • 1) числовые — средним/медианой; 2) категориальные — самым частым или отдельной категорией "missing".
  • Индикатор пропуска: отдельный бинарный признак «было ли значение отсутствующим».
  • Почему индикатор полезен: иногда сам факт пропуска несёт сигнал (например, пользователь не заполнил профиль).

    4) Категориальные признаки: как превратить в числа

    Большинство моделей требуют числовой вход, поэтому категории кодируют.

    | Метод | Идея | Когда хорош | Риски | |---|---|---|---| | One-hot | отдельный столбец на категорию | мало/средне категорий | рост размерности | | Ordinal | каждой категории назначить число | есть естественный порядок (S/M/L) | модель может «увидеть» ложный порядок | | Frequency/Count | заменить на частоту/кол-во | много категорий (high-cardinality) | утечка, если частоты посчитаны не по train | | Target encoding | заменить на среднее значение таргета по категории | много категорий и сильный сигнал | высокий риск переобучения и утечек, нужен аккуратный CV |

    Практические детали:

  • Редкие категории: объединяйте в "other".
  • Неизвестные категории на проде: заранее решите, что делать ("other" или отдельный код).
  • 5) Даты и время: не храните дату как «одно число»

    Дата/время часто полезнее как набор смысловых признаков:

  • Час, день недели, месяц, сезон.
  • Признаки «сколько времени прошло»: days_since_last_login.
  • Скользящие окна: число покупок за 7/30 дней.
  • Осторожно: агрегаты по истории должны использовать только данные, доступные до момента предсказания.

    6) Простые, но мощные признаки из «сырья»

    Часто помогают:

  • Отношения и разницы: price_per_unit, доля скидки.
  • Счётчики и частоты: число обращений в поддержку за 30 дней.
  • Групповые агрегаты (особенно в транзакциях):
  • 1) по пользователю: средний чек, медианный интервал между покупками; 2) по товару: средняя конверсия, доля возвратов.
  • Взаимодействия: признак A и признак B (когда эффект проявляется только в комбинации).
  • Принцип: признак должен быть интерпретируемым как «сигнал, который действительно существует до события».

    7) Мини-чеклист перед обучением

  • Есть ли пропуски и что они означают (ошибка сбора или «нет значения»)?
  • Нужны ли масштабирование/устойчивость к выбросам для выбранного алгоритма?
  • Как кодируются категории (и что с редкими/новыми значениями)?
  • Не вычисляете ли вы статистики по всей выборке (включая val/test)?
  • Все ли агрегаты и окна посчитаны без «заглядывания в будущее»?
  • ---

    Practice tasks

  • Вы обучаете kNN для скоринга клиентов. Два признака: доход (0…300000) и число покупок (0…50). Что может пойти не так без preprocessing и какое базовое преобразование поможет?
  • В датасете есть категориальный признак city с 50 000 уникальных значений. Назовите два подхода кодирования и по одному риску для каждого.
  • У вас много пропусков в признаке "phone_number" (строка). Что лучше: удалить столбец, заполнить или сделать индикатор? Ответьте в формате: «зависит от…» и приведите 2 фактора.
  • Вы посчитали для каждого пользователя "avg_purchase_last_30d" используя все транзакции за весь год, включая будущие относительно даты предсказания. Как называется проблема и как исправить расчёт?
  • <details> <summary> Ответы </summary>

  • kNN использует расстояния, и доход будет доминировать над числом покупок из-за масштаба. Поможет стандартизация или нормализация числовых признаков, чтобы вклад признаков в расстояние стал сопоставимым.
  • Подходы:
  • 1) Frequency/count encoding: заменить город на частоту в train. Риск — утечка/смещение, если частоты посчитаны с использованием val/test, и нестабильность при дрейфе частот. 2) Target encoding: заменить город на средний таргет по городу (только по train и желательно с CV/сглаживанием). Риск — сильное переобучение и утечка, если кодирование «видит» таргет для тех же строк.

  • Зависит от:
  • 1) является ли сам факт наличия телефона сигналом (тогда полезен индикатор "has_phone" и аккуратная обработка строк); 2) нужен ли номер как идентификатор/ключ (обычно нельзя использовать как признак из-за риска меморизации и приватности). Часто лучше не использовать сам номер как признак, но оставить индикатор наличия.

  • Это утечка по времени (data leakage): признак использует будущую информацию. Исправление: считать агрегат в окне относительно даты решения, используя только транзакции до этой даты (например, «последние 30 дней до момента предсказания»), и строить вычисление отдельно для train/val/test без смешивания.
  • </details>

    7. From Notebook to Practice: Building an End-to-End ML Pipeline

    From Notebook to Practice: Building an End-to-End ML Pipeline

    Ноутбук удобен для экспериментов, но «модель в проде» — это повторяемый процесс, который стабильно превращает сырые данные в предсказания и позволяет контролировать качество со временем. Ниже — практический каркас end-to-end ML pipeline без привязки к конкретным инструментам.

    1) Что такое ML pipeline (в прикладном смысле)

    Pipeline — это цепочка шагов, где у каждого шага есть:

  • Входы (данные/артефакты),
  • Выходы (данные/артефакты),
  • Версионирование/идентификатор запуска,
  • Проверки (валидация данных и качества).
  • Текстовая схема:

    Детали про признаки, утечки и разбиения не дублируем (см. статьи про data splits и feature engineering), но в production pipeline эти правила должны быть «встроены в рельсы».

    2) Артефакты, которые нужно сохранять (иначе вы не сможете повторить результат)

    В ноутбуке легко потерять контекст: «какие данные», «какие параметры», «какая версия признаков». В практике фиксируйте минимум:

  • Версия данных: период, фильтры, источник, правила формирования label.
  • Схема данных: список колонок, типы, допустимые диапазоны, доли пропусков.
  • Версия признаков/преобразований: как считали агрегаты, как кодировали категории, чем заполняли пропуски (важно: параметры считаются на train и применяются на val/test — см. статью про preprocessing).
  • Конфигурация обучения: алгоритм, гиперпараметры, seed.
  • Метрики и пороги: что оптимизировали и почему (см. статью про model evaluation).
  • Модельный артефакт: файл/объект модели.
  • Практическое правило: если через неделю вы не можете воспроизвести метрику тем же запуском — это ещё эксперимент, а не система.

    3) Разделяйте pipeline на «offline» и «online» части

    Обычно всё, что тяжёлое и использует историю, делается offline (пакетно), а в момент запроса — online (быстро).

  • Offline: расчёт агрегатов по истории, обучение, переоценка порога, подготовка справочников категорий.
  • Online: получение текущих входов, применение тех же преобразований, вызов модели, пост-обработка результата.
  • Ключевой риск: «разъехалась логика» признаков между ноутбуком и продом. Лечится тем, что вы используете один и тот же описанный набор преобразований как артефакт (а не «пере-написали примерно так же»).

    4) Data validation: поймать проблемы до обучения и до предсказаний

    Минимальные проверки, которые окупаются почти всегда:

  • Схема и типы: колонка пропала/переименовалась/стала строкой вместо числа.
  • Диапазоны и здравый смысл: отрицательная сумма, возраст 999.
  • Пропуски: резкий рост доли missing по ключевому признаку.
  • Кардинальность категорий: внезапный взрыв новых значений.
  • Стабильность распределений: данные «похожи» на то, на чём учили.
  • Если проверки падают — лучше остановить pipeline и не выкатывать модель, чем тихо ухудшать продукт.

    5) Оценка качества в pipeline: как избежать самообмана

    Три практических принципа:

  • Метрика и “рабочая точка”: метрика должна отражать цену ошибок, а порог выбирается на validation (см. статью про metrics/threshold).
  • Единый протокол сравнения: одинаковые сплиты, одинаковые правила препроцессинга, одинаковый набор метрик.
  • Quality gates: автоматические условия «можно/нельзя выкатывать».
  • Примеры quality gates:

  • Новая модель не хуже текущей по выбранной метрике.
  • Recall для редкого события не падает ниже минимума.
  • Время ответа укладывается в лимит.
  • 6) Упаковка: что нужно для “predict()” в реальном мире

    Чтобы предсказание было корректным, вам нужны не только веса модели:

  • Преобразования признаков (включая параметры: средние, списки категорий, словари).
  • Контракт входа: какие поля обязательны, какие допустимы значения.
  • Версия модели: чтобы можно было откатиться и сравнивать.
  • Логирование: входные признаки (в допустимом виде), версия модели, выход и уверенность/скор.
  • Важно: логирование должно помогать расследовать ошибки и мониторить качество, но не нарушать приватность и правила хранения данных.

    7) Мониторинг после запуска: качество уезжает молча

    В production модель портится из-за дрейфа данных и изменений процесса. Мониторьте хотя бы:

  • Data drift: изменились распределения признаков, доля пропусков, частоты категорий.
  • Prediction drift: модель стала выдавать подозрительно много «1» или наоборот почти всегда «0».
  • Бизнес-метрики: то, ради чего модель сделана (конверсия, потери, нагрузка на операторов).
  • Delayed labels: когда появились истинные ответы, пересчитайте метрики по свежему периоду.
  • Практика: лучше иметь простые алерты и регулярный отчёт качества, чем «идеальную систему мониторинга», которую никогда не внедрили.

    ---

    Practice tasks

  • Перечислите 5 артефактов, которые обязательно сохранять для воспроизводимости ML-результата.
  • Вы заметили, что в проде модель стала чаще предсказывать положительный класс, хотя бизнес-процесс не менялся. Назовите 3 возможные причины и 2 метрики/сигнала мониторинга, которые помогут диагностике.
  • Сформулируйте 3 примера quality gates для модели мошенничества (fraud) и объясните, почему они полезны.
  • В чём практическая разница между offline и online частью pipeline? Приведите по 2 примера задач для каждой.
  • <details> <summary> Answers </summary>

  • Пример набора артефактов:
  • 1) версия данных (период, фильтры, источник); 2) схема/контракт входных данных; 3) описание и версия признаков + параметры preprocessing (посчитанные на train); 4) конфигурация обучения (алгоритм, гиперпараметры, seed); 5) метрики/порог и протокол валидации (какой split, какая метрика); 6) файл/объект модели (веса) и версия модели.

  • Возможные причины:
  • 1) data drift: изменились распределения признаков или пришли новые категории; 2) поломка/изменение данных: выросли пропуски, поменялись типы, сместились значения; 3) training-serving skew: в проде признаки считаются иначе, чем в обучении.

    Сигналы мониторинга: 1) доля предсказаний класса 1 (prediction drift) и распределение скорингов; 2) доля пропусков/новых категорий и статистики распределений признаков; 3) когда появятся истинные метки — PR-AUC/recall/precision на свежем периоде.

  • Примеры quality gates для fraud:
  • 1) Recall на validation не ниже порога (например, не хуже текущей модели) — чтобы не увеличить пропуски дорогого события. 2) Precision не ниже минимума — чтобы ручная проверка не стала перегружена. 3) PR-AUC/стоимостная метрика не хуже baseline — чтобы качество ранжирования по риску не деградировало. Дополнительно: лимит на время ответа и долю объектов, уходящих в ручную проверку.

  • Offline vs online:
  • - Offline (пакетно): (1) расчёт агрегатов за 30 дней по транзакциям; (2) обучение и переоценка порога; (3) построение словаря категорий. - Online (в момент запроса): (1) применение сохранённых преобразований к одному объекту; (2) вычисление скоринга моделью; (3) правило принятия решения по порогу и логирование результата.

    </details>