Частые ловушки в экспериментах машинного обучения — рассказываем, что следует знать

Я Павел Куницын, главный специалист по анализу данных и машинному обучению ^[1] в ПГК Диджитал. Мы занимаемся разработкой цифровых продуктов в сфере железнодорожных грузоперевозок: интерактивной карты вагонного парка ^[2], оптимизатора ремонтов ^[3] и других решений. В большинстве из них мы применяем машинное обучение.

О том, как мы подходим к этому, я и мои коллеги рассказываем ^[4] в нашем блоге на Хабре. Например, мы работаем ^[5] с MLflow, который помогает анализировать результаты и вести учет экспериментов. Но несмотря на доступную автоматизацию, на этапе экспериментов могут возникать определённые сложности. Расскажу о наиболее частых проблемах.

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

Проблема утечек данных входит в топ-10 проблем Data Science и затрагивает ^[6] сотни, если не тысячи, научных материалов и ML-моделей. Утечка данных возникает, когда дата-сайентист допускает ошибку ^[7] на этапе обучения модели. Например, использует для обучения данные, имеющие лишь опосредованное отношение к целевой задаче, которую будет решать нейросеть. Или одновременно применяет и обучающие, и валидирующие данные для обучения модели.

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

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

Что почитать по теме:

• «Don’t Push the Button! Риски утечек данных в МО ^[8]». Исчерпывающая статья итальянских ученых о причинах утечек на этапе препроцессинга и не только. Например, противоречивая или ложная информация в тренировочном датасете.

• «Data Science: The Hard Parts ^[9]». Справочник от O’Reilly, в котором собраны лучшие практики и навыки, которыми должен обладать дата-сайентист. Отдельная глава посвящена утечкам данных и тому, как им противостоять.

• «Теория информации и ML. Прогноз ^[10]». Пост на Хабре, автор которого разбирает несколько видов data leakage: утечка через подбор гиперпараметров, утечка данных из будущего и другие нюансы.

Проблема вторая: версионирование

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

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

Что почитать по теме:

• «DVC, FDS, Kart и Dolt для версионирования данных ^[11]». Моя статья на Хабре о профильных open source инструментах: что они умеют и как мы их используем.

• «Начать работу с DVC ^[12]». Руководство для начинающих. Авторы, которые по совместительству являются разработчиками FDS, стартуют с базовых концепций.

• «Путь Тьюринга ^[13]». Это — электронный справочник с чек-листами и схемами для команды дата-сайентистов. Материал всеобъемлющий, но в нем есть отдельная глава ^[13] про версионирование данных.

Проблема третья: вычислительные ресурсы

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

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

Решение. Оно достаточно очевидно — на предпроектной проработке проводить оценку ресурсов с учетом возможного роста размеров моделей. Оценку можно провести на ограниченной выборке, а также изучить опыт ^[14] других компаний.

Что почитать по теме:

• «39 рекомендаций по построению ML-систем ^[15]». Чек-лист с лучшими практиками. Они касаются коллаборации, масштабирования алгоритмов и других тем.

Проблема четвертая: ограничения области значения прогнозируемой переменной

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

Решение. Необходимо учитывать особенности работы используемых алгоритмов и строить модель, которая будет устойчивой к новым наблюдениям. Для проверки устойчивости модели можно делать замеры на искусственных выбросах, писать для этого тесты. Затем мониторить качество в проде и анализировать ошибки. Многие могут быть связаны с выбросами, которые ML-система не умеет обрабатывать.

Проблема пятая: нелогичный прогноз модели

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

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

Что почитать по теме:

• «Различные оттенки неправды ^[16]». Авторы этой научной работы попытались повысить производительность нейросети, обучив её исключительно на неправильных ответах. Идея заключалась в том, чтобы научить систему ИИ отличать факты различной степени «неправильности».

• «Как анализировать и находить ошибки в LLM-приложениях ^[17]». Пошаговое руководство от основателя площадки TechTalks, посвящённой архитектуре ПО и работе с данными.

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

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

Но если приняли решение работать с ML, стоит обратить внимание ^[18] на метрики качества. Довольно частой ошибкой в этом контексте является использование некорректных бенчмарков при проведении экспериментов. Например, мы прогнозируем количество дней до выбытия вагона в ремонт — решаем задачу регрессии. Однако для бизнеса более важным критерием качества может быть не ошибка в днях, а факт поломки в конкретном месяце, и коллеги ориентируются на метрики задачи классификации.

Решение. Не забывать ^[19] согласовывать с бизнесом ожидания по результатам, и в соответствии с этим выстраивать систему оценки качества. При необходимости можно вообще переформулировать задачу.

Что почитать по теме:

• «ML для прогнозирования спроса на ж/д: экономическое обоснование ^[20]». Мой коллега Леонид Зверев рассказал, как мы помогаем прогнозировать спрос на подвижные составы. Какие подходы работают и как мы улучшаем результаты.

Разумеется, это не все нюансы, связанные с проведением ML-экспериментов. О других характерных сложностях я как-нибудь расскажу в следующих материалах.