Machine Learning Basics

Зачем

Machine Learning — это построение функций, которые обучаются на данных, а не пишутся вручную. Если правила слишком сложны, меняются, или их вообще никто не знает (распознать кошку, предсказать отток клиента, отличить fraud от обычной покупки) — пиши не правила, а датасет, и пусть оптимизатор подберёт параметры. Это фундамент под всё: RAG, рекомендации, model serving, MLOps, evals.

Перед тем как нырять в feature store, vector DB или RLHF — нужно понимать три вещи: какие бывают задачи (supervised/unsupervised/RL), как устроен offline-pipeline (data → features → train → eval → registry), и как замкнуть петлю обратной связи в проде (predict → log → monitor → retrain).

Mental model

Любая ML-система — это две петли вокруг общего реестра моделей.

Левая петля — offline training pipeline: сырые данные → feature engineering → train/val/test split → trainer → evaluator → model registry. Она медленная (часы-дни), batch-ориентированная, выполняется на исторических данных, и её цель — выдать артефакт-модель с подтверждёнными метриками.

Правая петля — online serving + monitoring: пользователь шлёт запрос → API достаёт фичи из feature store → модель предсказывает → ответ возвращается + логируется → drift monitor сравнивает прод-распределение с обучающим → при дрейфе триггерит retrain-job, который заново раскручивает левую петлю.

Точка сшивки — model registry (MLflow, SageMaker Model Registry, кастомный). Только через него модель попадает в serving. И только через monitor → retrain петля замыкается. Без registry — невозможно откатиться. Без monitor — модель тихо деградирует.

Три ключевых режима обучения:

• Supervised — есть labels: classification (fraud/legit, cat/dog), regression (цена квартиры). Подавляющее большинство prod ML.
• Unsupervised — labels нет: clustering (k-means, DBSCAN), dimensionality reduction (PCA, UMAP). Используется для исследования данных и feature extraction.
• Self-supervised — labels генерируются из самих данных (masked LM в BERT, contrastive learning в SimCLR). Фундамент современных foundation models.
• Reinforcement learning — агент учится через reward signal (RLHF в LLM, AlphaGo). Дорого, нестабильно, нишево.

Что на диаграмме

Offline pipeline (верхняя группа):

• raw — сырые данные в data lake (S3, GCS). Источник правды.
• features — feature engineering: cleaning, encoding, scaling, derived features.
• split — train/val/test split. Часто time-based: обучаемся на прошлом, валидируем на будущем.
• trainer — XGBoost/LightGBM/PyTorch. Обучает модель на X_train, y_train.
• evaluator — считает метрики на val: precision, recall, F1, PR-AUC, MSE, RMSE.
• registry — MLflow / SageMaker. Хранит артефакты + метаданные + lineage (git SHA, data version).

Online serving (нижняя группа):

• user — клиент, шлёт POST /score.
• api — Inference API, тонкий слой над моделью.
• fstore — feature store (Feast, Tecton). Online-кэш фичей с low-latency lookup.
• model — model server (Triton, Ray Serve, BentoML). Держит модель в памяти.
• logger — prediction log. Каждая (input, prediction, model_version) едет в storage.
• monitor — drift monitor. Считает PSI, KS-test, live PR-AUC.
• retrain — retrain job. Триггерится по дрейфу или по расписанию.

Edges:

• Offline-цепочка строго слева направо: raw → features → split → {trainer, evaluator} → registry.
• Serving: user → api → {fstore, model} → user, и параллельно model → logger.
• Замыкающая петля: logger → monitor → retrain → {raw, trainer}, плюс monitor → model для promote/rollback.

Сценарии

Классический offline pipeline на примере fraud detection: 2M транзакций, бинарная классификация (is_fraud). Демонстрирует все ключевые этапы — extract, clean, engineer (amount_log, tx_count_7d), scale только на train (чтобы не было leakage), time-based split, XGBoost с scale_pos_weight=300 для дикого imbalance (0.3% positive class), и важнейший момент: accuracy=0.997 здесь бесполезна — модель, всегда предсказывающая «не fraud», даст ту же цифру. Реальные метрики — precision, recall, F1, PR-AUC. После первого прогона видим overfitting (train F1 0.94 vs val 0.70), откатываемся, режем max_depth, добавляем L2, регистрируем v3.1.0 в staging.

Promote модели из registry в production, обслуживание реального запроса. Канарей 5%, warm-up booster, lookup фичей в feature store, predict, log, return. Показывает read-after-write проблему feature store: если p99 lookup перевалил за SLA, не падаем — отдаём stale features с явным флагом. Молча отдавать degraded ответы — путь к тихой деградации модели.

Замыкание петли. Drift monitor видит, что avg_tx_amount в проде = 78 USD vs 42 USD в train (PSI = 0.31, выше порога 0.25), и live PR-AUC падает с 0.78 до 0.61 за 14 дней — gift-card laundering, паттерн которого не было в обучении. Триггер retrain: новая модель v3.2.0, оффлайн PR-AUC 0.81, канарей 1%, shadow-логирование обоих версий 7 дней, потом промоут в 100%. Гатча сценария — feedback loop: если модель блокирует все подозрительные транзакции, мы никогда не увидим их истинную метку. Лекарство — uniform sampling небольшой доли запросов для размыкания петли.

Trade-offs (ADR)

ADR-001: Classical ML vs Deep Learning

Для табличных данных < 1M строк с структурными фичами gradient boosting (XGBoost/LightGBM/CatBoost) обыгрывает нейросети по accuracy И по training time И по interpretability. Kaggle/индустрия: GBDT берёт ~70% табличных задач. Deep learning доминирует только когда (a) данные неструктурные — text/image/audio/video, где фичи невозможно вручную сконструировать, (b) датасет огромный (>10M), и NN может перерасти GBDT, или (c) нужны выученные embeddings как фича для downstream-систем.

Решение: дефолт — XGBoost/LightGBM для табличных задач. Переход на DL только если (1) вход — сырой текст/картинка/аудио, (2) у тебя >10M размеченных строк, (3) нужны embeddings, или (4) GBDT упёрся в потолок и дополнительные пара процентов оправдывают 5-10x infra cost. Всегда начинай с logistic/linear regression как baseline — если 50-строчный baseline в пределах 2% от твоей навороченной модели, шипи baseline.

ADR-002: Train/val/test split — random vs time-based

Random split (sklearn train_test_split) протекает информацией из будущего в обучение, если в данных есть временное измерение (клики, транзакции, сенсоры). Модель красиво смотрится оффлайн (AUC 0.95), складывается в проде (AUC 0.62). Time-based split (train на Jan-Aug, val на Sep, test на Oct) воспроизводит deployment-условия: предсказывай будущее по прошлому.

Решение: time-based split для любых данных с timestamps или потенциалом user-id leakage. Stratified random — только для статичных датасетов (image benchmarks, фиксированные корпусы). Для k-fold CV на time data используй TimeSeriesSplit / rolling-origin CV. Test set заморожен — один взгляд = он заражён, придётся перестраивать.

Реальные системы

• Netflix — рекомендации: классический ML (matrix factorization) + DL (sequence models). Offline batch training, online retrieval + ranking, A/B тесты на всё.
• Uber Michelangelo — внутренняя ML-платформа: offline training в Spark, online serving через model server, feature store + drift monitoring. Одна из первых публичных архитектур, повлиявшая на отрасль.
• Stripe Radar — fraud detection: gradient boosting на табличных фичах + DL для embeddings транзакций. Live retraining при дрейфе.
• Spotify — рекомендации на embeddings (BERT-like модели для треков), online serving через TensorFlow Serving.
• Tabular Kaggle competitions — за 2015-2024 годы XGBoost/LightGBM выигрывали ~70% табличных соревнований; deep learning доминирует только в vision/NLP/audio.

Anti-patterns

• Smile-curve overfitting: train acc 0.99, val acc 0.62 → не «надо больше данных», а «модель слишком сложная». Регуляризуй, режь глубину, добавляй dropout.
• Accuracy на imbalanced classes: 99% accuracy на «есть рак / нет рака» (1% positive) ничего не значит — это baseline «всегда нет». Смотри precision/recall, PR-AUC.
• Data leakage: StandardScaler.fit() на всём датасете до split → mean/std видели тестовые данные. Всегда fit только на train, transform на val/test.
• Random split на временных данных: модель видит август при обучении, угадывает июль на тесте. В проде — катастрофа.
• Test set как валидационный: смотришь метрики на test, тюнишь, смотришь снова — это уже не test, это второй val. Заморозь test, посмотри один раз перед запуском.
• Train/serve skew: обучаешь на pandas DataFrame, в serving у тебя protobuf через gRPC, и преобразование различается на 0.01 — модель в проде хуже. Feature store нужен именно ради этого.
• Silent degradation: модель в проде, никто не смотрит метрики, distribution дрейфует, через 6 месяцев бизнес замечает падение конверсии. Без monitor + retrain пайплайн не закончен.
• Feedback loop без размыкания: модель блокирует подозрительные транзакции → ты не видишь их истинных меток → обучаешь на смещённой выборке → модель деградирует. Лечится uniform-сэмплированием.

Когда НЕ использовать

• Правила работают: если бизнес-логику можно выразить в виде десятка if/else (валидация email, форматирование номера) — не нужен ML. Rules-based прозрачнее, дешевле, debug-friendly.
• Нет данных: ML без размеченных данных — это не ML, это wishful thinking. До train-pipeline нужна layer сбора и разметки данных (Labelbox, Snorkel, ручная разметка).
• Стоимость ошибки выше стоимости отказа: медицинская диагностика, autonomous driving критичных решений — нужен human-in-the-loop, ML как hint, не как решение.
• Bias недопустим: hiring, lending, judicial decisions — ML усиливает bias в training data. Либо очень тщательный fairness-аудит, либо не ML.
• Объясняемость обязательна: если регулятор требует объяснить каждое решение (GDPR Article 22), используй interpretable модели (linear/logistic regression, decision trees) или вообще rules.
• Малая выгода vs стоимость: ML-проект — это data pipeline + training + serving + monitoring + retraining. Если задача даст +0.5% к KPI, а команда из 3 ML-инженеров стоит $1M/год — посчитай ROI.

Дальше читать

• [CONCEPT]embeddings-basics — векторные представления текста/картинок/чего угодно, без которых нет RAG и современных рекомендаций.
• [CONCEPT]feature-store — production-сторона фичей: как обеспечить, что одна и та же фича одинаково считается в train и serve.
• [CONCEPT]model-serving — как доставлять обученную модель в прод: REST, gRPC, batch, streaming, edge.
• [CONCEPT]mlops-pipeline — оркестрация всего pipeline: Airflow, Kubeflow, Argo, CI/CD для моделей.
• [CONCEPT]ai-evals — как оценивать качество моделей (особенно LLM): offline metrics, A/B, LLM-as-judge, golden sets.
• [CASE]recommendation-system — кейс, где всё это собирается в архитектуру масштаба Netflix/Spotify.