Машинное обучение с нуля: понять основы и начать практиковаться

Что такое ML: задачи, примеры и ограничения

Зачем вообще нужно машинное обучение

Машинное обучение (Machine Learning, ML) — это подход, при котором программа не получает жёсткие правила вида «если … то …», а учится на примерах находить закономерности и делать полезные предсказания.

Проще всего думать так:

* есть данные о прошлом (примеры); * есть задача (что мы хотим предсказывать или находить); * алгоритм подбирает способ делать это как можно лучше.

ML особенно полезно, когда:

* правил слишком много или они постоянно меняются (антиспам, мошенничество); * правила сложно формализовать словами (распознавание речи/изображений); * вы хотите автоматизировать решения на основе данных (прогноз спроса, рекомендации).

Чем ML отличается от обычного программирования

В классическом программировании вы пишете правила, и они превращают входные данные в ответ.

В ML вы даёте:

данные* (примеры); ответы* для части примеров (не всегда);

а система подбирает правила сама и затем применяет их к новым данным.

!Сравнение классического подхода и ML

Основные термины (без которых дальше будет сложно)

Данные* — таблица, тексты, изображения, логи, аудио, то есть то, из чего мы учимся. Признаки* — измеримые свойства объекта, которые подаются в модель (например, возраст, сумма покупки, время на сайте). Цель (или таргет*) — то, что мы хотим предсказать (например, «уйдёт ли клиент», «цена квартиры»). Модель* — обученный механизм, который по входным данным выдаёт предсказание. Обучение* — процесс настройки модели на данных. Инференс* (применение модели) — когда модель уже обучена и используется на новых данных.

Типы задач ML

На старте достаточно понимать три больших класса.

Обучение с учителем

Есть примеры, где известен правильный ответ (цель). Модель учится связывать признаки и цель.

Чаще всего встречаются два типа задач:

Классификация* — нужно выбрать класс/категорию. Регрессия* — нужно предсказать число.

Примеры:

* классификация: спам/не спам, мошенничество/норма, «кредит одобрить/отказать»; * регрессия: прогноз цены, времени доставки, спроса.

Обучение без учителя

Правильных ответов заранее нет. Мы ищем структуру в данных.

Частые задачи:

Кластеризация* — сгруппировать похожие объекты. Снижение размерности* — сжать признаки так, чтобы сохранить главное (часто для визуализации и подготовки данных). Поиск аномалий* — найти редкие и подозрительные случаи.

Примеры:

* сегментация клиентов на группы; * выявление необычных транзакций; * сжатие и визуализация данных.

Обучение с подкреплением

Есть агент, который действует в среде и получает награду (поощрение) за хорошие действия. Он учится стратегией: что делать, чтобы суммарная награда была максимальной.

Примеры:

* игровые агенты; * управление ресурсами (при корректной постановке); * обучение роботов (часто в симуляции).

!Три базовых парадигмы обучения

Популярные прикладные задачи и примеры

Ниже — «карта местности», чтобы понимать, где ML встречается чаще всего.

| Задача | Что делаем | Пример в жизни/бизнесе | |---|---|---| | Классификация | выбираем категорию | определить спам-письмо, распознать дефект на фото | | Регрессия | предсказываем число | прогноз цены квартиры, прогноз спроса на товар | | Ранжирование | упорядочиваем объекты по полезности | поисковая выдача, сортировка товаров в каталоге | | Рекомендации | предлагаем подходящие варианты | «вам также может понравиться», подбор видео | | Кластеризация | группируем похожих | сегменты клиентов, группировка новостей по темам | | Поиск аномалий | ищем необычное | подозрительные платежи, сбои датчиков | | Работа с текстом | извлекаем смысл/структуру | тональность отзывов, классификация обращений в поддержку | | Работа с изображениями | распознаём и локализуем объекты | распознавание лиц, контроль качества на производстве | | Временные ряды | анализируем значения во времени | прогноз нагрузки, обнаружение скачков метрик |

Важно: одна и та же прикладная проблема может формулироваться по-разному. Например, «кому показать рекламу» можно решить как:

* классификацию (кликнет/не кликнет), * регрессию (вероятность клика), * ранжирование (отсортировать кандидатов для показа).

Когда ML подходит, а когда — нет

ML — не магия и не универсальная кнопка.

ML подходит, если:

* есть данные (или вы реально можете их собрать); * есть понятный критерий «хорошо/плохо» (что значит качественное предсказание); * задача повторяется много раз (иначе автоматизация не окупится); * можно терпеть некоторую долю ошибок и управлять рисками.

ML обычно не подходит, если:

* данных мало, они шумные и собрать больше нельзя; * задача редкая или уникальная (разовая аналитика); * требования к объяснимости абсолютные, а ошибка недопустима (иногда нужно правило, регламент или проверка человеком); * проблема на самом деле не в предсказании, а в процессе/организации (ML не исправит хаос в данных и учёте).

Ограничения и типичные ловушки

Данные решают больше, чем «крутая модель»

Качество ML почти всегда упирается в:

* ошибки в разметке (неправильные «правильные ответы»); * пропуски и несогласованность данных; * смещение выборки (данные обучения не похожи на реальные будущие случаи).

Корреляция не равна причине

ML хорошо находит связи «одно часто встречается вместе с другим». Но это не означает, что одно вызывает другое.

Пример: модель может заметить, что пользователи с определённого устройства чаще покупают — но причина может быть не в устройстве, а в аудитории, маркетинге или регионе.

Переобучение

Переобучение — когда модель слишком хорошо запоминает обучающие примеры и хуже работает на новых.

Симптом: на обучении качество высокое, а на новых данных заметно хуже.

Утечка данных

Утечка — когда в признаки случайно попадает информация из будущего или напрямую из ответа.

Примеры утечки:

* признак «факт возврата» в задаче «предсказать возврат»; * использование данных после даты события при прогнозе до этой даты.

Нестабильность мира

Данные и поведение людей меняются:

* сезонность; * новые товары и конкуренты; * изменения продукта; * изменения в экономике.

Из-за этого модель может «устареть», даже если раньше работала хорошо.

Этические и правовые ограничения

Риски:

* дискриминация (модель ухудшает решение для отдельных групп); * нарушение приватности; * непрозрачные решения там, где нужны объяснения.

Часто это решается не одной техникой, а комбинацией:

* корректная постановка задачи; * ограничения на использование признаков; * аудит качества по группам; * участие юристов и ответственных за риск.

Как выглядит типичный ML-процесс (очень кратко)

Дальше в курсе мы будем возвращаться к этому циклу постоянно.

Формулируем задачу: что предсказываем и зачем.

Определяем метрику качества: как понять, что стало лучше.

Собираем и готовим данные.

Делим данные на части (обычно обучение и проверка).

Обучаем базовую модель.

Проверяем качество и ошибки.

Улучшаем данные/признаки/модель.

Внедряем и следим за качеством после запуска.

!Итеративный цикл ML-проекта

Куда двигаться дальше в курсе

После этой статьи логичный следующий шаг — научиться:

* переводить бизнес-вопрос в ML-задачу (классификация/регрессия/ранжирование); * понимать, что такое признаки и как они связаны с качеством; * оценивать модели и избегать переобучения и утечек; * собирать минимальный рабочий ML-пайплайн на практике.

Полезные источники

* Wikipedia: Machine learning * Google Machine Learning Glossary * Документация scikit-learn: Machine Learning in Python

Данные и признаки: сбор, очистка и подготовка

Почему эта тема важнее, чем выбор «крутой модели»

В предыдущей статье мы разобрали, что ML учится на примерах и что качество сильно зависит от данных, а не только от алгоритма. На практике большинство проблем с ML-моделями — это не «плохой алгоритм», а:

данные собраны не так, как будет в реальном применении;

в данных много ошибок и пропусков;

признаки построены так, что модель случайно «подглядывает» ответ (утечка);

обучающие данные не похожи на будущие (смещение выборки).

Эта статья — про базовый, но критически важный слой: как собирать данные, превращать их в признаки и готовить к обучению.

Данные, признаки и цель: что есть что

Чтобы не путаться, зафиксируем простые определения.

Объект — то, про что мы делаем предсказание.

- Примеры: пользователь, письмо, заказ, квартира, транзакция.

Признаки — измеримые свойства объекта, которые вы подаёте в модель.

- Примеры: возраст пользователя, регион, средний чек, текст письма, число покупок за 30 дней.

Цель (таргет, метка) — правильный ответ, который модель должна научиться предсказывать.

- Примеры: «спам/не спам», «уйдёт/не уйдёт», цена квартиры.

В табличных данных чаще всего всё выглядит как таблица:

| Строка | Что означает | Пример | |---|---|---| | Строка | один объект | один клиент | | Столбец-признак | свойство объекта | возраст | | Столбец-цель | что предсказываем | уйдёт ли клиент |

Важно: один и тот же «сырой» факт может быть либо признаком, либо целью — зависит от постановки задачи.

Сбор данных: откуда они берутся и что важно учесть

Источники данных обычно такие:

продуктовые события (логи кликов, просмотров, действий);

транзакции (покупки, платежи, возвраты);

CRM/анкеты (возраст, город, сегмент);

поддержка (тексты обращений);

внешние источники (например, погода, курсы валют), если это законно и уместно.

При сборе данных заранее подумайте о трёх вещах.

Что является объектом? (строкой в датасете)

В какой момент времени мы делаем предсказание? (точка принятия решения)

Какие данные доступны в этот момент? (это главный щит от утечки)

!Общая карта пути данных от источников до модели

Практический принцип «точки во времени»

Если вы предсказываете событие в будущем (например, отток в течение 30 дней), то признаки должны быть рассчитаны только из информации до момента предсказания.

Например:

корректно: «кол-во покупок за последние 30 дней до сегодня»;

риск утечки: «кол-во покупок за 30 дней после сегодня»;

явная утечка: «факт оттока» как признак в задаче «предсказать отток».

Сырые данные почти никогда не готовы к ML

Сырые данные часто содержат:

пропуски (нет возраста, не указан город);

дубликаты (одно и то же событие записано дважды);

ошибки ввода (отрицательный возраст, перепутанные единицы измерения);

разный формат (даты строкой в разных стилях);

редкие категории (тысячи уникальных значений у признака «модель устройства»);

выбросы (аномальные значения, которые ломают статистику).

Задача подготовки данных — сделать так, чтобы модель:

получала стабильные, понятные числовые представления признаков;

не «училась» на артефактах и ошибках;

валидация честно показывала качество на новых данных.

Очистка данных: базовые операции

Пропуски

Пропуск — это не просто «дырка», а информация.

Типичные подходы:

удалить строки/столбцы, если пропусков слишком много и признак бесполезен;

заполнить разумным значением:

- числовые: медианой/средним или специальным значением; - категориальные: отдельной категорией вроде unknown;

добавить отдельный бинарный признак «значение было пропущено» (иногда это улучшает качество).

Что выбрать зависит от смысла признака и причины пропуска. Пример: «доход не указан» может означать другую аудиторию, а не случайную потерю данных.

Дубликаты

Дубликаты бывают разных типов:

полные (вся строка совпадает);

логические (одна и та же транзакция с разными техническими полями).

Важно понять: дубликат — это ошибка записи или реальное повторение? В событиях пользователя «повтор» может быть нормой, а в транзакциях — нет.

Некорректные значения и единицы измерения

Сначала задайте «правила здравого смысла»:

возраст не может быть отрицательным;

дата рождения не может быть завтра;

сумма заказа не может быть бесконечной.

А затем решайте, что делать:

исправлять (если есть достоверный способ);

помечать как пропуск;

удалять наблюдения, если они явно ошибочны и редки.

Выбросы

Выброс — значение, сильно отличающееся от большинства. Он может быть:

ошибкой (лишний ноль в сумме заказа);

редким, но реальным случаем (оптовая закупка).

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

посмотреть распределение (хотя бы минимумы/максимумы/квантили);

понять бизнес-смысл;

проверить несколько примеров вручную.

Преобразование данных в признаки

Многие модели (особенно классические алгоритмы) ожидают на вход числовую матрицу. Поэтому данные часто нужно закодировать.

Числовые признаки

Частые шаги:

привести типы (int, float), единицы измерения и формат;

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

логарифмировать «тяжёлые хвосты» (например, суммы, которые распределены очень неравномерно) — только если это осмысленно.

Категориальные признаки

Примеры категориальных: город, тариф, тип устройства.

Основные подходы:

One-hot encoding — сделать отдельный столбец на категорию (часто хорошо для небольшого числа категорий);

объединять редкие значения в «other», чтобы не раздувать размерность;

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

Даты и время

Сырые даты редко подают «как есть». Обычно извлекают:

день недели, месяц, час;

признак «выходной/будний»;

время с последнего события;

агрегаты по окнам времени (например, «покупок за 7/30 дней»).

Ключевой момент: такие признаки нужно считать так, чтобы они были доступны в момент предсказания.

Текст, изображения, аудио

На старте курса важно понять принцип:

модель не понимает текст «как человек» — его нужно представить числами;

для классического ML часто используют мешок слов или TF-IDF;

для современных подходов часто используют нейросетевые эмбеддинги.

Если вы начинаете с нуля, самый практичный путь — сначала научиться на табличных данных, а потом переходить к тексту/изображениям.

Разделение на train/validation/test

Чтобы честно оценивать качество, данные делят на части.

Train — на нём модель учится.

Validation — на нём подбирают настройки и сравнивают версии.

Test — финальная проверка «как на новых данных».

!Наглядное разбиение данных на train/validation/test

Почему нельзя «подглядывать» в test

Если вы много раз улучшаете модель, постоянно проверяя качество на test, то вы неосознанно подстраиваетесь под него. В итоге test перестаёт быть честной оценкой.

Правило: test используем редко, в самом конце.

Особый случай: временные данные

Если вы прогнозируете будущее по прошлому (спрос, метрики, отток по месяцам), то случайное перемешивание часто неверно. Тогда делают разбиение по времени:

train — ранние даты;

validation — более поздние;

test — самые поздние.

Утечка данных: самый частый «скрытый чит»

Утечка — когда в признаках оказывается информация, которая в реальности недоступна на момент предсказания или напрямую связана с целью.

Типовые источники утечки:

признаки, рассчитанные после события (например, «количество обращений в поддержку за следующие 7 дней»);

признаки-заменители таргета (например, статус «закрыт как мошенничество» в задаче «предсказать мошенничество»);

агрегации, посчитанные на всей таблице целиком, включая test (например, нормализация или статистики, рассчитанные до разбиения).

Хороший тест на утечку: представьте, что модель работает в продакшене «прямо сейчас». Могли бы вы вычислить этот признак в этот момент?

Минимальный практический пайплайн подготовки (на примере табличных данных)

Ниже — примерный шаблон шагов, который применим в большинстве задач.

Определить объект, цель, момент предсказания.

Собрать «сырой» датасет и описать каждое поле.

Разделить на train/validation/test до сложных преобразований.

На train настроить преобразования:

- заполнение пропусков, - кодирование категорий, - масштабирование чисел.

Применить те же преобразования к validation/test.

Обучить базовую модель и проверить качество.

Пример кода: базовая подготовка в scikit-learn

Что здесь важно концептуально:

преобразования обучаются на train (например, медианы для заполнения пропусков);

затем те же правила применяются к новым данным;

handle_unknown="ignore" помогает не падать, если в реальности появится новый город/тариф.

Проверка качества данных: чек-лист перед обучением

Полезный минимум, который стоит сделать почти всегда:

проверить размеры данных и долю пропусков по столбцам;

проверить типы (число/категория/дата) и единицы измерения;

посмотреть базовые статистики чисел (минимум/максимум/квантили);

оценить число уникальных значений у категорий;

убедиться, что нет явной утечки (признаки из будущего);

убедиться, что разбиение на train/test сделано корректно (особенно для времени и групп).

Документация признаков: привычка, которая экономит недели

Когда признаков становится много, без описания вы быстро теряете контроль. Хорошая практика — вести «паспорт признаков».

| Поле | Тип | Как считается | Доступен когда | Риски | |---|---|---|---|---| | orders_30d | число | число заказов за последние 30 дней | на момент предсказания | утечка, если окно захватывает будущее | | city | категория | из профиля | всегда | новые значения | | avg_check_90d | число | средний чек за 90 дней | на момент предсказания | выбросы |

Куда дальше

Дальше логично перейти к тому, как измерять качество модели и как понимать, что улучшение — реальное, а не случайность. Для этого нам понадобятся:

метрики качества для классификации и регрессии;

правильные схемы валидации;

диагностика переобучения.

Полезные источники

Документация scikit-learn: Pipelines and composite estimators

Документация pandas: Working with missing data

Google Machine Learning Glossary

Базовые модели: регрессия, классификация, kNN, деревья

Зачем нужны базовые модели

В предыдущих статьях мы разобрали:

что такое ML, какие бывают задачи и ограничения;

как данные превращаются в признаки и почему важно избегать утечек.

Теперь логичный шаг — посмотреть на несколько базовых моделей, с которых чаще всего начинают в реальных проектах. Они важны по двум причинам:

дают понятный старт и часто уже неплохо работают;

помогают «почувствовать» связь между признаками, качеством данных и ошибками.

Мы разберём четыре опоры классического ML:

линейная регрессия (задачи регрессии);

логистическая регрессия (задачи классификации);

k ближайших соседей (kNN);

деревья решений.

!Четыре модели в одной картинке: как выглядят их предсказания

Два типа задач: регрессия и классификация

Регрессия

Регрессия — когда модель предсказывает число.

Примеры:

цена квартиры;

время доставки;

спрос на товар.

Классификация

Классификация — когда модель выбирает класс.

Примеры:

спам или не спам;

уйдёт клиент или нет;

дефект на фото или норма.

Важно: очень часто модель сначала оценивает вероятность класса, а затем вы превращаете её в решение правилом вроде «если вероятность больше 0.5, то класс 1». Это особенно характерно для логистической регрессии.

Линейная регрессия

Идея

Линейная регрессия пытается описать зависимость между признаками и числом-целью как взвешенную сумму признаков.

Если у объекта есть признаки , то предсказание записывают так:

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

— предсказанное моделью число;

— смещение (базовый уровень, когда все признаки равны нулю);

— веса признаков (насколько каждый признак влияет на ответ);

— значения признаков объекта.

Как модель обучается

На обучении модель подбирает веса так, чтобы ошибки на тренировочных примерах были как можно меньше.

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

Что здесь означает каждая часть:

— число объектов в обучающей выборке;

— индекс объекта;

— истинный ответ для объекта ;

— предсказание модели для объекта ;

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

Плюсы и минусы

Плюсы:

быстро обучается и быстро работает;

относительно легко объяснять влияние признаков через веса;

хорошая базовая линия для многих задач.

Минусы:

описывает зависимость «почти прямой линией» и плохо ловит сложные нелинейности без дополнительной инженерии признаков;

чувствительна к выбросам в цели (очень большие ошибки сильно влияют на обучение).

Когда уместна

когда связь примерно линейная;

когда важна интерпретируемость;

как стартовая модель для сравнения.

Ссылки:

scikit-learn: LinearRegression

Логистическая регрессия

Почему это не регрессия в бытовом смысле

Логистическая регрессия — базовая модель для классификации, чаще всего бинарной (0/1).

Она тоже строит линейную комбинацию признаков, но затем превращает её в вероятность класса 1.

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

Сначала считается линейная часть:

Потом применяется сигмоида:

Объяснение элементов:

— «сырое» линейное значение (может быть любым числом);

— число от 0 до 1, которое удобно трактовать как вероятность;

— математическая константа (основание натурального логарифма);

— делает так, что при большом вероятность близка к 1, а при малом — близка к 0.

После этого решение получают порогом, например:

если , предсказываем класс 1;

иначе класс 0.

Порог не обязан быть 0.5: его выбирают под стоимость ошибок и бизнес-риски.

Плюсы и минусы

Плюсы:

выдаёт вероятности, что удобно для ранжирования и настройки порога;

часто хороший баланс качества, скорости и объяснимости;

хорошо работает на разреженных признаках, например после one-hot.

Минусы:

граница решений линейная: сложные зависимости ловит хуже деревьев или моделей с нелинейностями;

требует аккуратной подготовки признаков (категории кодировать, пропуски обрабатывать).

Ссылки:

scikit-learn: LogisticRegression

k ближайших соседей (kNN)

Идея

kNN — модель «по аналогии».

Чтобы предсказать ответ для нового объекта:

находим самых похожих объектов в обучающих данных;

для классификации берём самый частый класс среди соседей;

для регрессии берём среднее (или взвешенное среднее) ответов соседей.

Сходство обычно измеряют расстоянием, например евклидовым.

Ключевое свойство: всё решают расстояния

Из-за расстояний появляются две практические особенности:

масштаб признаков критичен: признак в «тысячах» может полностью задавить признак в «единицах»;

качество сильно зависит от того, какие признаки вы придумали и как их нормировали.

Пример проблемы масштаба:

признак income в рублях (0–300000);

признак age (0–100).

Без масштабирования «похожесть» будет почти целиком определяться доходом.

Как выбирать k

Интуитивно:

маленькое делает модель очень чувствительной к шуму (риск переобучения);

большое делает модель слишком сглаженной (риск недообучения).

Обычно подбирают на validation.

Плюсы и минусы

Плюсы:

простая идея, хороший учебный эталон;

может хорошо работать на «геометрически разделимых» данных.

Минусы:

медленный инференс на больших данных (надо искать соседей);

плохо работает в высоких размерностях (когда признаков много и расстояния становятся менее информативными);

требует масштабирования числовых признаков.

Ссылки:

scikit-learn: KNeighborsClassifier

scikit-learn: KNeighborsRegressor

Деревья решений

Идея

Дерево решений строит последовательность правил вида «если признак меньше/больше порога, идём влево/вправо».

Пример логики дерева:

если orders_30d больше 3, то вероятность покупки выше;

иначе смотрим is_weekend;

иначе смотрим avg_check_90d.

В листе дерева хранится итоговое предсказание:

для классификации: класс или вероятности классов;

для регрессии: число (часто среднее по объектам в листе).

!Как дерево превращает признаки в последовательность условий

Почему деревья часто дают сильный базовый результат

Деревья умеют ловить нелинейности и взаимодействия признаков автоматически.

Примеры взаимодействий:

«если регион = A и средний чек высокий, то…»;

«если пользователь новый, то важен один набор признаков, иначе другой».

Линейным моделям для такого обычно нужна ручная инженерия признаков.

Главная опасность: переобучение

Дерево может углубляться до тех пор, пока не начнёт «запоминать» обучающие данные.

Типичные способы сдерживать дерево:

ограничивать глубину max_depth;

требовать минимум объектов в листе min_samples_leaf;

требовать минимум объектов для разбиения min_samples_split.

Плюсы и минусы

Плюсы:

часто сильное качество без сложной подготовки;

легко объяснить конкретное решение как путь по условиям;

не чувствительны к масштабу признаков так, как kNN.

Минусы:

одиночное дерево нестабильно: небольшие изменения данных могут сильно менять структуру;

легко переобучается без ограничений;

в популярных библиотеках категориальные признаки часто всё равно нужно кодировать числами.

Ссылки:

scikit-learn: DecisionTreeClassifier

scikit-learn: DecisionTreeRegressor

Как сравнивать модели на старте

Ниже — практичная «карта выбора», когда вы только начинаете и строите первую версию.

| Модель | Лучше для | Требует масштабирования | Сильно переобучается | Сильные стороны | |---|---|---|---|---| | Линейная регрессия | регрессия | иногда полезно | умеренно | простота, скорость, интерпретируемость | | Логистическая регрессия | классификация | иногда полезно | умеренно | вероятности, скорость, хороший базовый уровень | | kNN | и то и другое | да | при малом k | простота, «по похожести» | | Дерево решений | и то и другое | обычно нет | да, если без ограничений | нелинейности, взаимодействия, понятные правила |

Минимальные рабочие пайплайны в scikit-learn

Ключевой принцип из прошлой статьи: все преобразования должны обучаться на train и применяться одинаково к validation/test. Для этого удобно использовать Pipeline.

Классификация: логистическая регрессия + подготовка

Регрессия: линейная регрессия + подготовка

kNN: важно не забыть масштабирование

Дерево: масштабирование не обязательно, но ограничения важны

Типичные ошибки новичка при выборе базовой модели

Сравнивать модели без одинаковой подготовки данных и честного разбиения на train/test.

Пытаться «выжать качество» подбором модели, когда проблема в данных:

- утечка; - пропуски; - неправильная точка во времени; - смещение выборки.

Забывать, что kNN требует масштабирования.

Оставлять дерево без ограничений и радоваться идеальному качеству на train.

Что дальше по курсу

Теперь у вас есть набор базовых моделей и понимание, почему они ведут себя по-разному.

Следующий необходимый шаг — научиться измерять качество и честно сравнивать модели:

метрики для классификации и регрессии;

корректная валидация;

диагностика переобучения и ошибок.

Полезные источники

scikit-learn: Supervised learning

scikit-learn: Pipelines and composite estimators

Wikipedia: Linear regression

Wikipedia: Logistic regression

Wikipedia: k-nearest neighbors algorithm

Wikipedia: Decision tree learning

Обучение и оптимизация: градиентный спуск и регуляризация

Как эта тема связана с предыдущими статьями

В прошлых материалах курса мы разобрали:

что такое ML и какие бывают задачи;

как готовить данные и избегать утечек;

базовые модели: линейная и логистическая регрессия, kNN, деревья.

Теперь важно понять как именно модель "подбирает" свои параметры при обучении и почему без специальных приёмов она может переобучаться. Два ключевых инструмента здесь:

градиентный спуск как универсальный способ минимизировать ошибку;

регуляризация как способ сделать модель проще и устойчивее.

Что значит "обучить модель"

Во многих моделях есть параметры, которые нужно подобрать по данным:

в линейной регрессии это веса признаков и смещение ;

в логистической регрессии тоже есть веса и смещение;

в нейросетях параметров ещё больше, но принцип похожий.

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

Пример для регрессии: среднеквадратичная ошибка

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

— число объектов в обучающей выборке;

— индекс объекта;

— истинное значение цели для объекта ;

— предсказание модели для объекта ;

— ошибка предсказания;

квадрат нужен, чтобы большие промахи штрафовались сильнее и чтобы ошибки не "компенсировали" друг друга.

Дальше задача обучения сводится к оптимизации:

найти такие параметры модели, при которых функция потерь минимальна.

Почему часто нельзя решить "в лоб"

Иногда оптимальные параметры можно найти формулой. Но на практике часто мешает одно из условий:

слишком много данных;

слишком много признаков;

функция потерь сложная;

модель сложная (например, нейросеть).

Поэтому обычно делают итеративный процесс: немного изменяем параметры, смотрим стало ли лучше, повторяем. Главный рабочий алгоритм для этого — градиентный спуск.

Градиентный спуск: идея без лишней математики

Интуиция:

функция потерь — это "высота" на поверхности;

параметры модели — координаты на этой поверхности;

градиент показывает направление самого быстрого роста;

чтобы уменьшить потери, нужно идти в противоположную сторону.

!Схема: как градиентный спуск шаг за шагом уменьшает loss

Формально один шаг градиентного спуска часто записывают так:

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

— параметры модели (иногда это один вес, иногда целый вектор весов);

— функция потерь, зависящая от параметров;

— градиент: направление наискорейшего увеличения потерь;

— скорость обучения: насколько большой шаг мы делаем;

знак минус означает, что мы идём в сторону уменьшения потерь.

Важно понимать практический смысл:

если шаг слишком большой, можно "перепрыгивать" минимум и обучение будет нестабильным;

если шаг слишком маленький, обучение будет идти очень медленно.

Скорость обучения: главный рычаг стабильности

Скорость обучения часто важнее выбора модели на старте.

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

слишком большая : loss скачет, качество не улучшается, иногда появляются nan;

слишком маленькая : loss уменьшается, но очень медленно.

Популярные подходы:

подобрать вручную на валидации;

использовать схемы уменьшения по мере обучения;

использовать адаптивные оптимизаторы (чаще в нейросетях), но идею градиентного спуска они не отменяют.

Полный градиент, SGD и mini-batch

Чтобы посчитать градиент, нужно понять, как сильно каждый параметр влияет на потери. Есть три режима, которые отличаются тем, на скольких объектах считать градиент.

Batch gradient descent: градиент считается на всей обучающей выборке.

SGD (stochastic gradient descent): градиент считается по одному объекту.

Mini-batch: градиент считается по небольшому пакету объектов.

Сравнение по смыслу:

| Подход | На чём считается градиент | Плюсы | Минусы | |---|---|---|---| | Batch | на всех данных | стабильные шаги | может быть очень медленно на больших данных | | SGD | на одном объекте | быстрые шаги, можно обучаться на потоке данных | шаги шумные, loss может "дрожать" | | Mini-batch | на пакете объектов | баланс скорости и стабильности | нужно выбрать размер пакета |

Практический вывод для новичка:

если данных мало, часто удобно считать на всём наборе;

если данных много, почти всегда используют mini-batch или SGD.

Почему масштабирование признаков помогает оптимизации

Для градиентного спуска важно, чтобы признаки были сопоставимы по масштабу.

Пример проблемы:

income измеряется от 0 до 300000;

age измеряется от 0 до 100.

Тогда изменение веса при income может доминировать, и оптимизация будет идти неудобными "зигзагами".

Отсюда связь с подготовкой данных из прошлой статьи:

стандартизация числовых признаков через StandardScaler часто ускоряет и стабилизирует обучение линейных моделей и моделей, которые используют расстояния.

Что такое переобучение на языке оптимизации

Переобучение — это ситуация, когда модель нашла параметры, которые отлично уменьшают loss на train, но плохо работают на новых данных.

Типичные причины:

модель слишком гибкая для объёма данных;

в признаках есть шум, и модель подстраивается под него;

слишком долго обучали и "довели" параметры до подгонки под train.

Два основных способа бороться:

регуляризация (штраф за сложность);

ранняя остановка (early stopping).

Регуляризация: сделать решение проще и устойчивее

Регуляризация добавляет к основной ошибке дополнительный штраф за "сложность" модели. В линейных моделях сложность удобно измерять размерами весов.

Общая форма:

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

— итоговая функция, которую минимизируем;

— ошибка на данных (например, MSE или логистическая потеря);

— регуляризатор: штраф за большие веса;

— коэффициент регуляризации: насколько сильно штрафуем сложность.

Интуитивно:

маленькая : модель почти не ограничена и может переобучаться;

большая : модель становится проще, но может недообучиться.

!Иллюстрация: регуляризация уменьшает переобучение, делая модель проще

L2-регуляризация: Ridge

L2-регуляризация добавляет штраф за сумму квадратов весов:

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

— число признаков;

— вес при признаке ;

квадрат делает штраф особенно сильным для больших по модулю весов.

Что это даёт на практике:

веса становятся меньше и стабильнее;

модель меньше реагирует на шум;

редко зануляет веса полностью, чаще "сжимает" их.

Название модели в регрессии:

Ridge regression.

Ссылки:

scikit-learn: Ridge

L1-регуляризация: Lasso

L1-регуляризация штрафует сумму модулей весов:

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

— модуль веса: штрафует и положительные, и отрицательные веса одинаково;

сумма по всем признакам означает, что штраф действует на каждый вес.

Практический эффект:

часть весов может стать ровно нулевой;

модель автоматически делает простой отбор признаков;

полезно, когда признаков много и часть из них лишняя.

Название модели в регрессии:

Lasso regression.

Ссылки:

scikit-learn: Lasso

Регуляризация в логистической регрессии

Логистическая регрессия почти всегда используется с регуляризацией, потому что:

one-hot кодирование может дать много признаков;

без ограничений веса могут раздуваться, особенно при почти идеально разделимых данных.

В scikit-learn важная деталь:

параметр C в LogisticRegression — это обратная сила регуляризации.

Правило:

меньше C означает сильнее регуляризация;

больше C означает слабее регуляризация.

Ссылка:

scikit-learn: LogisticRegression

Ранняя остановка как "регуляризация временем"

Если обучать модель итеративно (SGD, нейросети), то часто работает простой приём:

следить за качеством на validation;

остановить обучение, когда качество перестало улучшаться.

Это помогает, потому что модель не успевает "дотюниться" под шум train.

Важное правило честности (из статьи про данные):

early stopping делается по validation, а test используется редко и в конце.

Минимальные примеры в scikit-learn

Линейная модель с SGD и регуляризацией

SGDRegressor и SGDClassifier используют оптимизацию через SGD, то есть прямо применяют идею градиентного спуска.

Смысл ключевых параметров:

loss="log_loss" включает логистическую потерю для классификации;

penalty="l2" включает L2-регуляризацию;

alpha управляет силой регуляризации в SGD-моделях: больше alpha означает сильнее штраф.

Ссылка:

scikit-learn: SGDClassifier

Ridge как "линейная регрессия + L2"

Интуиция параметра alpha в Ridge:

больше alpha означает сильнее регуляризация и более "сжатые" веса.

Типичные ошибки новичка

Пытаться лечить переобучение только подбором модели, игнорируя качество признаков и утечки.

Не масштабировать числовые признаки при SGD и других методах, чувствительных к масштабу.

Использовать слишком большую скорость обучения и не понимать, почему обучение стало нестабильным.

Настраивать регуляризацию по test вместо validation.

Куда двигаться дальше

После того как вы поняли, как модели обучаются и почему регуляризация помогает, следующий обязательный шаг — научиться измерять качество и сравнивать модели корректно:

метрики для классификации и регрессии;

кросс-валидация и честная схема проверки;

анализ ошибок и выбор порога в классификации.

Полезные источники

Wikipedia: Gradient descent

Wikipedia: Regularization (mathematics))

scikit-learn: SGDClassifier

scikit-learn: Ridge

scikit-learn: Lasso

Оценка качества: метрики, валидация, переобучение

Зачем оценка качества — обязательный шаг

В предыдущих статьях курса мы уже:

разобрали, что такое ML и какие бывают задачи;

научились готовить данные и избегать утечек;

посмотрели базовые модели;

поняли, как обучение связано с оптимизацией и регуляризацией.

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

Оценка качества в ML — это три вещи вместе:

метрика: чем измеряем «хорошо/плохо»;

валидация: как честно проверяем на данных, которые модель не видела;

контроль переобучения: как убеждаемся, что модель не «запомнила» train.

Базовая логика: что именно мы измеряем

Любая оценка качества начинается с двух простых вопросов:

Что модель выдаёт?

- число (регрессия); - класс или вероятность класса (классификация).

Какая ошибка для нас «дороже»?

- ложные срабатывания (например, ошибочно заблокировать платёж); - пропуски (например, пропустить мошенничество).

От ответов зависит выбор метрики и порога принятия решения.

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

Матрица ошибок

Для бинарной классификации удобно мыслить через 4 исхода:

TP (true positive): предсказали 1 и это правда 1

FP (false positive): предсказали 1, но на самом деле 0

TN (true negative): предсказали 0 и это правда 0

FN (false negative): предсказали 0, но на самом деле 1

!Матрица ошибок показывает, какие типы ошибок делает классификатор

Accuracy

Accuracy — доля правильных ответов.

Где:

— количества исходов из матрицы ошибок;

числитель — сколько объектов классифицировали правильно;

знаменатель — сколько объектов всего.

Когда не стоит опираться на accuracy:

при сильном дисбалансе классов (например, 1% мошенничества).

Precision и Recall

Precision отвечает на вопрос: если модель сказала «1», как часто она права?

Где:

— истинные срабатывания;

— ложные срабатывания;

знаменатель — все объекты, которые модель пометила как класс 1.

Recall отвечает на вопрос: из всех настоящих «1» сколько мы нашли?

Где:

— пропуски (настоящие 1, которые модель не заметила);

знаменатель — все объекты, которые на самом деле относятся к классу 1.

Практическая интерпретация:

если важнее не пропустить (медицина, безопасность) — обычно нужен высокий recall;

если важнее не тревожить зря (ручная модерация, обзвон) — обычно нужен высокий precision.

F1-score

F1 — баланс precision и recall (в одном числе).

Где:

и — метрики выше;

формула устроена так, что F1 становится низким, если одна из двух метрик проваливается.

ROC-AUC и PR-AUC (когда модель выдаёт вероятности)

Многие классификаторы выдают вероятность класса 1. Тогда можно менять порог решения и строить кривые качества.

ROC-AUC показывает, насколько хорошо модель в среднем ранжирует объекты так, чтобы «1» были выше «0».

PR-AUC (Precision-Recall AUC) часто более информативна при сильном дисбалансе классов.

Практическое правило:

если класс 1 редкий (аномалии, мошенничество) — PR-AUC обычно полезнее ROC-AUC.

Справка в документации:

Метрики классификации в scikit-learn

Log loss (когда важны вероятности)

Если вам важно, чтобы вероятность была калиброванной (например, 0.8 действительно означает «примерно 80% случаев»), используют log loss.

Интуитивно:

сильно штрафует уверенные ошибки (когда модель говорит «почти 1», а правда 0).

Регрессия: метрики для числовых предсказаний

MAE и MSE/RMSE

MAE (mean absolute error) — средняя абсолютная ошибка; проще интерпретировать в единицах таргета.

MSE штрафует большие промахи сильнее (из-за квадрата).

RMSE — корень из MSE, снова в единицах таргета.

Практика выбора:

если большие ошибки особенно опасны — часто используют RMSE;

если важна «типичная» ошибка и устойчивость к выбросам — часто используют MAE.

показывает, какую долю разброса таргета модель объясняет по сравнению с наивным предсказанием средним.

Важно:

высокий не гарантирует, что ошибка в абсолютных единицах приемлема;

при неправильной валидации тоже может быть «обманчиво хорошим».

Справка в документации:

Метрики регрессии в scikit-learn

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

Метрики бессмысленны без правильной схемы проверки.

Train/validation/test

Классическая схема:

Train: обучение модели.

Validation: выбор гиперпараметров, сравнение вариантов, подбор порога.

Test: финальная проверка один-два раза в конце.

Критически важно:

test не используют как «рабочий инструмент» для постоянного подбора.

!Разбиение данных помогает честно измерять качество и не подглядывать в будущее

Кросс-валидация

Если данных мало, качество на одном разбиении может сильно зависеть от удачи. Тогда используют k-fold кросс-валидацию:

делим данные на частей;

раз обучаем модель, каждый раз оставляя одну часть на проверку;

усредняем метрику.

Практический смысл:

получаем более устойчивую оценку;

можем сравнивать модели честнее.

Справка в документации:

Кросс-валидация в scikit-learn

cross_val_score в scikit-learn

Стратификация

Если в классификации классы несбалансированы, разбиение должно сохранять долю классов.

в train_test_split для этого используют stratify=y;

в кросс-валидации — стратифицированные схемы.

Временные данные

Если вы прогнозируете будущее по прошлому, нельзя перемешивать строки случайно.

Корректная идея:

train — ранние даты;

validation — более поздние;

test — самые поздние.

Иначе вы легко получите утечку «из будущего».

Групповая валидация (когда есть зависимые объекты)

Если в данных есть группы, которые нельзя разрывать между train и test (например, один пользователь имеет много строк), важно делать разбиение по группам.

Почему:

иначе модель может «узнавать пользователя», а не решать задачу.

Переобучение: как его увидеть и что с ним делать

Что такое переобучение в терминах метрик

Простой симптом:

метрика на train заметно лучше, чем на validation/test.

Частые причины:

слишком сложная модель для объёма данных;

слишком много шума в признаках;

утечка или неправильная схема валидации.

Диагностика: не только «смотреть на число»

Практичный набор действий:

Сравнить качество train и validation.

Посмотреть матрицу ошибок и понять какие ошибки доминируют.

Проверить признаки на утечки (принцип «точки во времени» из статьи про данные).

Построить простую baseline-модель и сравнить.

Как снижать переобучение

Основные рычаги (в порядке, который часто эффективнее всего):

Исправить валидацию и убрать утечки.

Упростить модель.

- для дерева ограничить max_depth, увеличить min_samples_leaf.

Добавить регуляризацию.

- для линейных моделей: Ridge/Lasso или настройка C в логистической регрессии.

Собрать больше данных или улучшить разметку.

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

Связь с предыдущей статьёй:

регуляризация — это системный способ «наказать сложность» и снизить разрыв между train и validation.

Минимальный пример: оценка классификации в scikit-learn

Ниже пример того, как обычно выглядит базовая оценка, когда модель выдаёт классы и вероятности.

Полезная документация:

sklearn.metrics

Типичные ошибки новичка при оценке качества

Выбирать метрику, не учитывая стоимость ошибок.

Радоваться высокому accuracy при редком классе.

Подбирать гиперпараметры, постоянно глядя на test.

Делать случайное разбиение во временных задачах.

Случайно обучить препроцессинг на всём датасете до разбиения (скрытая утечка).

Что дальше

Теперь у вас есть инструменты, чтобы:

выбрать метрику под задачу;

организовать честную проверку;

распознавать переобучение и понимать, что с ним делать.

Дальше в практической части курса логично перейти к системному улучшению моделей:

анализ ошибок (какие объекты модель путает);

подбор порога и работа с дисбалансом;

настройка гиперпараметров на validation или через кросс-валидацию.

Ансамбли и бустинг: Random Forest и градиентный бустинг

Зачем нужны ансамбли

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

Теперь добавим важный практический слой: ансамбли.

Ансамбль — это подход, когда мы объединяем несколько моделей и получаем итоговое предсказание “вместе”. Главная идея простая:

одна модель может ошибаться на одних объектах, другая — на других;

если объединить их правильно, итог будет стабильнее и чаще точнее.

Два самых популярных семейства ансамблей для табличных данных:

bagging (усреднение многих моделей, обученных “параллельно”) → Random Forest

boosting (последовательное улучшение ошибок) → градиентный бустинг

!Сравнение логики Random Forest и градиентного бустинга

Почему одиночное дерево часто “нестабильно”

Дерево решений умеет ловить нелинейности и взаимодействия признаков, но у него есть слабость:

небольшие изменения в данных могут сильно изменить структуру дерева;

глубокие деревья легко переобучаются.

Ансамбли деревьев обычно решают обе проблемы, но разными способами.

Random Forest

Идея: много “средних” деревьев вместо одного “идеального”

Random Forest строит много деревьев решений и объединяет их ответы:

в классификации обычно используется голосование (или усреднение вероятностей);

в регрессии обычно используется усреднение предсказанных чисел.

Чтобы деревья получались разными (а значит, ансамбль выигрывал от разнообразия), Random Forest добавляет два источника случайности:

bootstrap: каждое дерево обучается на случайной подвыборке объектов (обычно с возвращением)

случайное подмножество признаков: при каждом разбиении дерева рассматривается не весь набор признаков

Идея “почему это работает”:

одиночное дерево имеет высокую вариативность (сильно зависит от данных)

усреднение многих разных деревьев снижает вариативность и делает качество стабильнее

Ключевые гиперпараметры Random Forest

n_estimators — сколько деревьев строим

max_depth — максимальная глубина дерева

min_samples_leaf — минимальное число объектов в листе

max_features — сколько признаков рассматривать при разбиении

bootstrap — использовать ли bootstrap-подвыборки

Практические ориентиры:

увеличение n_estimators обычно улучшает качество и стабильность, но замедляет обучение и инференс

ограничения (max_depth, min_samples_leaf) помогают контролировать переобучение и ускоряют модель

max_features управляет “разнообразием” деревьев: меньше признаков → деревья более разные

Плюсы и минусы Random Forest

Плюсы:

сильный baseline почти для любой табличной задачи

неплохо работает “из коробки”, без тонкой настройки

устойчивее одиночного дерева

часто менее капризен к масштабированию числовых признаков, чем линейные модели и kNN

Минусы:

может уступать градиентному бустингу по качеству на сложных табличных данных

может быть тяжёлым по памяти и времени на больших данных

интерпретируемость ниже, чем у одного дерева (хотя важности признаков помогают)

Важности признаков: полезно, но осторожно

У Random Forest часто смотрят feature importance.

Как это использовать правильно:

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

как инструмент диагностики, не как “истину”

Почему осторожно:

коррелирующие признаки могут “делить важность” между собой

признаки с большим числом уникальных значений иногда получают завышенную важность в деревьях

Если нужна более надёжная оценка вклада признаков, часто используют permutation importance.

Градиентный бустинг

Идея: строим модель “шаг за шагом”, исправляя ошибки

Бустинг — это ансамбль, где модели обучаются последовательно:

сначала первая модель делает предсказания и ошибается

затем следующая модель учится исправлять именно эти ошибки

и так далее

На практике чаще всего базовые модели в бустинге — небольшие деревья (неглубокие), которые называют слабыми учениками.

Что означает “градиентный”

Градиентный бустинг связывает идею “исправления ошибок” с оптимизацией функции потерь.

На интуитивном уровне:

у нас есть функция потерь, которая измеряет, насколько плохи предсказания

мы добавляем деревья так, чтобы уменьшать эту ошибку

Один из способов записать общую форму модели:

Расшифровка каждого элемента:

— признаки объекта (то, что подаём на вход)

— итоговое предсказание модели для объекта

— число шагов бустинга (сколько деревьев добавили)

— предсказание -го дерева для объекта

— learning rate (скорость обучения), то есть насколько сильно каждое дерево влияет на итог

Смысл формулы: итог — это сумма вкладов многих маленьких деревьев.

Почему бустинг часто даёт лучшее качество на табличных данных

последовательное исправление ошибок позволяет “доточить” модель

бустинг хорошо ловит сложные взаимодействия признаков

есть сильные механизмы контроля переобучения через настройки и раннюю остановку

Ключевые гиперпараметры градиентного бустинга

n_estimators — сколько деревьев добавляем

learning_rate — насколько сильный вклад каждого дерева

max_depth или аналоги (например, max_leaf_nodes) — сложность каждого дерева

subsample — доля объектов для обучения очередного дерева (стохастический бустинг)

Практическая связка:

меньше learning_rate обычно требует больше n_estimators

слишком большие деревья и слишком много итераций повышают риск переобучения

Как бустинг переобучается и как это лечат

Типичный сценарий:

на train качество растёт долго

на validation качество сначала растёт, затем перестаёт улучшаться и ухудшается

Основные рычаги:

уменьшить max_depth (сделать деревья слабее)

уменьшить learning_rate

включить subsample меньше 1.0

использовать раннюю остановку по validation

Важно: ранняя остановка должна смотреть на validation, а test использоваться только в конце, как мы обсуждали в статье про оценку качества.

Random Forest vs градиентный бустинг

| Критерий | Random Forest | Градиентный бустинг | |---|---|---| | Как строится | параллельно (bagging) | последовательно (исправляем ошибки) | | Типичный baseline | очень сильный и стабильный | часто сильнее по качеству, но капризнее | | Риск переобучения | обычно ниже при разумных ограничениях | выше без настройки и early stopping | | Настройка | часто проще | чаще требует подбора параметров | | Скорость обучения | может быть тяжёлым при большом числе деревьев | часто тяжелее, особенно при большом числе итераций |

Как выбирать в первом приближении:

если хотите быстрый, стабильный старт и меньше тонкой настройки — начните с Random Forest

если хотите выжать качество на табличной задаче и готовы к подбору параметров — пробуйте градиентный бустинг

Практика в scikit-learn: минимальные пайплайны

Ниже примеры продолжают идею из прошлых статей: готовим данные через Pipeline и честно оцениваем на validation/test.

Random Forest для классификации

Градиентный бустинг для классификации

В scikit-learn есть несколько реализаций. Для больших данных часто удобнее HistGradientBoosting*.

Практическое замечание про препроцессинг:

one-hot кодирование может сильно увеличить число признаков

для деревьев это часто допустимо, но иногда начинает “тормозить”

на широких one-hot данных логистическая регрессия может быть быстрее, а бустинг может потребовать аккуратной настройки

Как честно сравнивать ансамбли

Свяжем с прошлой статьёй про метрики и валидацию. Минимальный корректный протокол сравнения:

Выбираете метрику под задачу (например, ROC-AUC или F1).

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

Строите baseline (например, логистическая регрессия или простое дерево).

Строите Random Forest.

Строите градиентный бустинг.

Сравниваете на validation (или через кросс-валидацию), а test используете в конце.

Типичные ошибки новичка с ансамблями

Оценивать качество на тех же данных, на которых обучали.

Подбирать параметры, постоянно глядя на test.

Ставить слишком сложные деревья в бустинге и удивляться переобучению.

Игнорировать утечки: ансамбли часто усиливают эффект утечки и дают “подозрительно идеальные” метрики.

Сравнивать модели без одинакового пайплайна подготовки данных.

Полезные источники

Ensemble methods в scikit-learn

RandomForestClassifier в scikit-learn

GradientBoostingClassifier в scikit-learn

HistGradientBoostingClassifier в scikit-learn

Практический ML-проект: пайплайн, интерпретация, деплой основы

Зачем нужна эта статья

В предыдущих статьях курса мы разобрали:

какие бывают ML-задачи и ограничения;

как готовить данные и избегать утечек;

базовые модели и ансамбли;

как обучать, регуляризовать и честно оценивать качество.

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

!Карта практического ML-проекта от данных до деплоя и мониторинга

Минимальный набор артефактов ML-проекта

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

Что должно быть зафиксировано

Постановка задачи: что предсказываем, в какой момент времени, и как используем предсказание.

Метрика и правило принятия решения: что оптимизируем и какой порог/топ-N используем, если модель выдаёт вероятности.

Схема валидации: случайное/стратифицированное/временное/групповое разбиение.

Пайплайн подготовки: как обрабатываем пропуски, как кодируем категории, какие признаки считаем.

Версия данных: откуда данные, за какие даты, какой фильтр объектов.

Версия модели и параметры: тип алгоритма и ключевые гиперпараметры.

Практическая мысль: если через месяц вы не можете повторить обучение и получить сравнимый результат, это не пайплайн, а разовый эксперимент.

Воспроизводимый пайплайн в scikit-learn

Главный принцип из статьи про данные: все преобразования обучаются на train и одинаково применяются к validation/test. Самый надёжный способ не ошибиться — использовать Pipeline и ColumnTransformer.

Шаблон пайплайна

Ниже пример для табличной классификации: пропуски, кодирование категорий, модель. Такой объект можно обучать, валидировать и деплоить как единое целое.

Что здесь важно:

препроцессинг внутри пайплайна, значит меньше риск утечки;

random_state даёт воспроизводимость (насколько это возможно для конкретного алгоритма);

пайплайн можно сохранить и применять на новых данных без ручных шагов.

Полезная документация:

Pipelines and composite estimators

ColumnTransformer

Эксперименты без хаоса

Минимальная дисциплина, которая резко ускоряет прогресс:

сохранять параметры модели и метрики в таблицу (хотя бы CSV);

фиксировать схему разбиения и сиды;

сравнивать модели только при одинаковом протоколе валидации.

Если нужен более системный учёт экспериментов, часто используют:

MLflow Tracking

Интерпретация и проверка здравого смысла

Интерпретация нужна не только для объяснимости. Она помогает ловить ошибки данных, утечки и «читерские» признаки.

Быстрые проверки перед углублением

сравните с простым baseline, чтобы понимать, есть ли реальный выигрыш;

проверьте, что качество на train не «подозрительно идеально» относительно validation/test;

посмотрите ошибки: какие группы объектов модель системно путает.

Глобальная интерпретация

#### Линейные модели

Если у вас логистическая регрессия или линейная регрессия, коэффициенты — хороший старт. Но помните:

коэффициенты сравнимы только при сопоставимом масштабе числовых признаков;

one-hot создаёт много бинарных признаков, и интерпретация становится «по категориям».

#### Важности признаков в деревьях и ансамблях

У деревьев/лесов/бустинга часто смотрят feature_importances_, но это нужно трактовать осторожно:

коррелирующие признаки могут «делить» важность;

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

Более универсальный подход — permutation importance: насколько падает качество, если перемешать значения признака.

Документация:

Permutation feature importance

#### Partial Dependence

Если вы хотите увидеть, как в среднем меняется предсказание при изменении одного признака, используют partial dependence. Это особенно полезно для коммуникации с бизнесом, но требует аккуратности при сильной корреляции признаков.

Документация:

Partial dependence plots

Локальная интерпретация

Локальная интерпретация отвечает на вопрос: почему конкретному объекту модель дала такой прогноз.

Один из популярных инструментов — SHAP. Его важно воспринимать как диагностику, а не абсолютную истину.

SHAP documentation

Деплой основы: как применить модель в реальности

Деплой — это не «залить модель». Это сделать так, чтобы предсказание было:

корректным (те же преобразования, что на обучении);

стабильным (версионирование);

наблюдаемым (логирование и мониторинг).

Контракт инференса: что подаём на вход

До кода определите контракт:

какие поля приходят на вход (имена, типы, допустимые значения);

что делать с пропусками;

что возвращаем (класс, вероятность, число);

допустимая задержка ответа (важно для онлайн-API).

Практический совет: если можно деплоить весь Pipeline, это снижает риск расхождения препроцессинга между обучением и продом.

Сохранение модели

Самый простой вариант для scikit-learn — joblib.

Документация:

Model persistence

Что важно версионировать вместе с моделью:

файл модели;

список входных колонок и их типы;

версию кода и версию библиотек;

версию данных и схему разбиения.

Онлайн-деплой: минимальный API (FastAPI)

Сценарий: вам нужно получать признаки по запросу и отдавать прогноз за миллисекунды/сотни миллисекунд.

Документация:

FastAPI

Pydantic

Batch-скоринг

Сценарий: вы раз в день/час считаете прогнозы для многих объектов и записываете в таблицу.

Плюсы:

проще инфраструктурно;

легче контролировать воспроизводимость и стоимость.

Минусы:

прогноз не «в моменте», а с задержкой.

Что мониторить после запуска

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

технические метрики: время ответа, доля ошибок сервиса;

качество данных: доля пропусков, доля новых категорий, сдвиг распределений;

бизнес-метрики: то, ради чего модель внедряли;

качество модели: если есть отложенная разметка, считать метрики на свежих данных.

Идея из статьи про ограничения ML: мир меняется, поэтому модель может «устареть» даже без ошибок в коде.

Практический чек-лист проекта

| Этап | Что сделать | Типичная ошибка | |---|---|---| | Постановка задачи | зафиксировать объект, момент предсказания, метрику | признаки используют информацию из будущего | | Данные | описать поля и источники, проверить пропуски и дубликаты | «грязные» данные дают ложный прогресс | | Валидация | выбрать правильное разбиение (время/группы/стратификация) | случайное перемешивание во временной задаче | | Пайплайн | собрать Pipeline целиком (prep + model) | препроцессинг обучен на всём датасете | | Интерпретация | проверить важности и ошибки на группах | поверить «подозрительно высоким» метрикам | | Деплой | определить контракт входа/выхода, версионировать | несовпадение схемы данных в проде | | Мониторинг | следить за данными, качеством и бизнес-эффектом | думать, что «один раз обучили и забыли» |

Куда двигаться дальше

Если вы освоили этот контур, следующий практический шаг — делать проект итеративно сильнее:

подбирать гиперпараметры через кросс-валидацию;

работать с дисбалансом классов и порогом;

улучшать признаки, а не только модель;

выстраивать цикл переобучения и мониторинга как регулярный процесс.