Обучение XGBoost, LightGBM, CatBoost на табличных данных

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

Обучение модели на табличных данных идёт быстро: градиентный бустинг сходится за минуты, а на проверочной выборке метрики выглядят убедительно. Разрыв обнаруживается позже — качество модели после запуска падает не из-за алгоритма, а из-за того, как собраны признаки и разделены данные.

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

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

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

Что даёт выстроенный контур: сроки, устойчивость, классы отказов

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

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

Доля автоматических решений растёт за счёт калибровки: порог срабатывания подбираем так, чтобы в автоматику уходили уверенные ответы, а спорные — в ручной разбор с понятной причиной. Так уходит отдельный класс отказов — молчаливые ошибки, когда модель отвечает уверенно там, где данных не хватает. Градиентный бустинг на табличных данных, включая CatBoost, даёт вклад признаков, по которому видно, что именно поехало.

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

Способы построения: пакетный, потоковый и гибридный контур

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

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

Требования к инфраструктуре растут вместе с частотой: пакетному контуру достаточно ночного окна и хранилища срезов, потоковому нужны буфер событий и сервис контроля качества модели. На старте мы прогоняем оба сценария на исторических данных и сравниваем метрику на отложенном периоде — это показывает, даёт ли поток реальный прирост или достаточно пересборки раз в сутки.

Обучение модели: этапы инженерной работы от данных до передачи

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

1. Разбор данных и постановка цели. Определяем, что предсказываем, на каком горизонте и какая ошибка дороже — пропуск события или ложное срабатывание. Смотрим пропуски, дубли, смещение между периодами выгрузок.
2. Схема признаков. Собираем таблицу признаков и для каждого фиксируем момент, на который он известен, чтобы модель не заглядывала в будущее. Агрегаты по окнам считаем только по прошедшим событиям.
3. Базовая линия. Сначала простое правило или линейная модель — она показывает, сколько пользы даёт усложнение. Дальше градиентный бустинг на табличных данных, подбор параметров по валидации.
4. Перекрёстная проверка. Разбиваем выборку по времени, а не случайно: случайное разбиение на временных данных даёт завышенную метрику. Смотрим разброс качества по фолдам — нестабильность видно до вывода в эксплуатацию.
5. Анализ ошибок и устойчивости. Разбираем важность признаков и качество по сегментам, подбираем порог срабатывания под реальную стоимость ошибок заказчика.
6. Вывод решения в эксплуатацию. Сервис инференса, контракт входа и выхода, версия модели и её артефакты, журнал предсказаний, мониторинг дрейфа и откат на предыдущую версию.
7. Передача. Документация по признакам и регламенту переобучения, воспроизводимый пересчёт от выгрузки до модели — команда заказчика может обновлять решение без нас.

Что передаём на руки: конфигурации, схемы, регламенты

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

• Конфигурации обучения — файлы с гиперпараметрами, схемой кросс-валидации, зафиксированным зерном генератора и перечнем версий библиотек. Повторный прогон на тех же данных даёт ту же метрику, а не «примерно похожую».
• Схема контура — откуда приходят данные, где готовятся признаки, где считается предсказание, как результат попадает в учётную систему. Со схемой видно, какой участок упадёт первым при отказе источника.
• Описание признаков — по каждому: смысл, тип, источник, правило обработки пропусков, кодировка категорий, диапазон допустимых значений. Без этого через полгода никто не сможет добавить признак, не сломав соседние.
• Регламент контроля качества — какие метрики считаются на отложенной выборке, с какой периодичностью, при каком расхождении запускается переобучение. Порог фиксируется заранее, а не подгоняется под текущий результат.
• Журнал решений — почему выбрана эта модель, какие конфигурации проверялись и почему отклонены, какие признаки ушли из набора. Он экономит месяцы, когда к задаче возвращается новый инженер.
• Регламент обновления и отката — как выпускается новая версия, где хранятся предыдущие, за какое время возвращаемся на рабочую. Обновление перестаёт быть событием с риском.

К каждому артефакту привязан владелец на вашей стороне — на приёмке разбираем не папки, а действия: обучить модель заново, объяснить предсказание, откатить версию. Опишите задачу — вернёмся с оценкой и планом комплекта под ваш контур.

Кейс: сократили срок подготовки решения и класс сбоев

Заказчик — сервис, где решение по каждой заявке принимал человек по чек-листу. Историческая разметка на табличных данных уже была, но первые попытки собрать модель упирались в одно и то же: признаки в обучении и в рабочем потоке считались по-разному, и качество на проверке не совпадало с качеством в работе. Из-за этого доля ручных разборов оставалась высокой, а подготовка очередной версии решения растягивалась на полтора-два месяца.

Что изменили

Собрали единый слой подготовки признаков: одна и та же логика расчёта работает и при обучении, и при выгрузке, а сам набор признаков версионируется. Модель обучали на градиентном бустинге для табличных данных — сравнивали несколько реализаций, включая CatBoost, на отложенной по времени выборке. Выбирали не по среднему качеству, а по устойчивости к сдвигу данных и калибровке вероятностей.

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

Что стало

• срок подготовки решения: с 6 недель до 10 рабочих дней — за счёт готового слоя признаков и повторяемого прогона обучения;
• доля ручных разборов: с 3 из 10 заявок до менее чем 1 из 10;
• класс отказов «расхождение между обучением и работой» не воспроизводился за всё время наблюдения;
• спорные случаи разбираются точечно: у каждой автоматической оценки есть объяснение по вкладу признаков, поэтому причина отказа видна без повторного прогона.

Чем отличается переобучение по расписанию от дообучения на потоке

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

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

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

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

Технические сомнения: данные, метрики, поддержка решения

Сомнения по таким проектам обычно касаются не выбора алгоритма, а данных и процесса вокруг него: хватит ли строк для обучения, чем измерять качество, что делать, если правильный ответ становится известен с задержкой. Ниже — как мы закрываем эти места до старта, чтобы результат не зависел от договорённостей «на словах».

Разметка и метрика фиксируются письменно до первой итерации обучения: схема разметки, правила спорных случаев, доля双-проверенных примеров, целевая метрика и её порог приёмки. Обучение ведём на градиентном бустинге — в том числе на CatBoost — потому что на табличных данных он даёт устойчивый результат там, где нейросети требуют на порядок больше размеченных примеров.

Как выбирается метрика качества?

Метрика выводится из решения, которое принимается по прогнозу. Если дорог пропуск целевого события — смотрим полноту, если дороги ложные срабатывания — точность; при сильном дисбалансе классов опираемся на площадь под кривой точность-полнота. Отдельно калибруем вероятности и подбираем порог срабатывания по матрице издержек, иначе модель с хорошей метрикой остаётся нерабочей в реальном процессе.

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

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

Кто поддерживает решение после запуска?

Передаём конфигурации обучения, версии датасетов и признаков, скрипты воспроизведения, регламент переобучения и мониторинг дрейфа — решение остаётся внутри вашего контура. Инженеры заказчика могут вести его самостоятельно; по договорённости подключаемся на изменения схемы разметки, новые источники данных или падение метрики ниже порога.

Обсудим задачу: что уточнить перед началом работ

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

Что уточняем на этом шаге:

• Цель и метрика. Какой результат считается полезным: доля верных срабатываний, полнота на редком классе, допустимая доля ложных тревог. От этого зависит порог срабатывания и способ валидации.
• Данные и разметка. Объём истории, число наблюдений и признаков, категориальные поля, пропуски, есть ли целевая метка и насколько она достоверна.
• Режим обновления. Пакетное переобучение по расписанию или по появлении новых данных, кто запускает цикл, какое окно истории берём и как фиксируем контроль качества после каждого прогона.
• Требования к контуру. Закрытый периметр без внешнего доступа, правила обращения с чувствительными полями, права ролей, журналирование запросов к модели.
• Интеграция и отчётность. Куда отдаём результат — в учётную систему, отчёт или внутренний сервис; нужны ли пояснения к предсказанию и выгрузка для аудита.
• Приёмка и ограничения. На чём проверяем — отложенная выборка, исторический прогон, пилот на живом потоке; кто подтверждает результат и какие окна работ согласованы.

Опишите задачу в этих границах — вернёмся с оценкой, планом внедрения и составом работ по этапам.