Частые ловушки в экспериментах машинного обучения — рассказываем, что следует знать
Привет, Хабр! Я Павел Куницын, главный специалист по анализу данных и машинному обучению в ПГК Диджитал. Мы занимаемся разработкой цифровых продуктов в сфере железнодорожных грузоперевозок: интерактивной карты вагонного парка, оптимизатора ремонтов и других решений. В большинстве из них мы применяем машинное обучение.
О том, как мы подходим к этому, я и мои коллеги рассказываем в нашем блоге на Хабре. Например, мы работаем с MLflow, который помогает анализировать результаты и вести учет экспериментов. Но несмотря на доступную автоматизацию, на этапе экспериментов могут возникать определённые сложности. Расскажу о наиболее частых проблемах.
Проблема первая: утечка данных
Проблема утечек данных входит в топ-10 проблем Data Science и затрагивает сотни, если не тысячи, научных материалов и ML-моделей. Утечка данных возникает, когда дата-сайентист допускает ошибку на этапе обучения модели. Например, использует для обучения данные, имеющие лишь опосредованное отношение к целевой задаче, которую будет решать нейросеть. Или одновременно применяет и обучающие, и валидирующие данные для обучения модели.
Допустить подобную ошибку куда проще, чем кажется, на первый взгляд. Одна из распространенных причин возникновения такого рода утечек — неосторожное использование целевой переменной или признака, построенного на её основе (например, target encoding). В экспериментальной среде такие признаки могут давать высокие метрики качества, но в проде фича становится недоступной, и модель теряет способность делать прогнозы.
Решение. Использовать целевую переменную с осторожностью, чтобы избежать переобучения, и ответственно подходить к подсчету качества на тестовой выборке. Для построения моделей можно использовать данные, основанные на значениях целевой переменной, но нужно обязательно учитывать, что в тестовой выборке должны использоваться только данные из обучения.
Что почитать по теме:
«Don«t Push the Button! Риски утечек данных в МО». Исчерпывающая статья итальянских ученых о причинах утечек на этапе препроцессинга и не только. Например, противоречивая или ложная информация в тренировочном датасете.
«Data Science: The Hard Parts». Справочник от O«Reilly, в котором собраны лучшие практики и навыки, которыми должен обладать дата-сайентист. Отдельная глава посвящена утечкам данных и тому, как им противостоять.
«Теория информации и ML. Прогноз». Пост на Хабре, автор которого разбирает несколько видов data leakage: утечка через подбор гиперпараметров, утечка данных из будущего и другие нюансы.
Проблема вторая: версионирование
В машинном обучении важно отслеживать историю экспериментов: какие данные использовались, какие параметры были выбраны, какая версия кода и окружения применялась. Когда модель отдает непредсказуемые ответы, нужно посмотреть, на каких данных она обучалась, но конкретный срез найти не всегда получается.
Решение. Можно фиксировать версии используемых данных и делать связку модели в проде с ее обучающей выборкой. С этим могут помочь DvC и другие инструменты, либо своя реализация практик контроля версий артефактов.
Что почитать по теме:
«DVC, FDS, Kart и Dolt для версионирования данных». Моя статья на Хабре о профильных open source инструментах: что они умеют и как мы их используем.
«Начать работу с DVC». Руководство для начинающих. Авторы, которые по совместительству являются разработчиками FDS, стартуют с базовых концепций.
«Путь Тьюринга». Это — электронный справочник с чек-листами и схемами для команды дата-сайентистов. Материал всеобъемлющий, но в нем есть отдельная глава про версионирование данных.
Проблема третья: вычислительные ресурсы
Когда команда дата-сайентистов пробует новую библиотеку или алгоритм, случается, что инфраструктура компании оказывается не способна их «переварить» (например, у выделенной на задачу инфраструктуры может не хватать вычислительных ресурсов).
Возникнуть эта проблема может уже после согласования бюджета и вычислительных ограничений на проект. Размеры моделей и их требования к ресурсам могут значительно возрасти на финальных этапах разработки.
Решение. Оно достаточно очевидно — на предпроектной проработке проводить оценку ресурсов с учетом возможного роста размеров моделей. Оценку можно провести на ограниченной выборке, а также изучить опыт других компаний.
Что почитать по теме:
»39 рекомендаций по построению ML-систем». Чек-лист с лучшими практиками. Они касаются коллаборации, масштабирования алгоритмов и других тем.
Проблема четвертая: ограничения области значения прогнозируемой переменной
Например, такой алгоритм как случайный лес не сможет в качестве прогноза вернуть значение, которого не было в обучающей выборке. Этот факт может привести к серьёзной ошибке, если в проде на вход модели попадет какое-то новое наблюдение или «выброс». В этом случае даже простая модель линейной регрессии имеет преимущество перед более продвинутым алгоритмом.
Решение. Необходимо учитывать особенности работы используемых алгоритмов и строить модель, которая будет устойчивой к новым наблюдениям. Для проверки устойчивости модели можно делать замеры на искусственных выбросах, писать для этого тесты. Затем мониторить качество в проде и анализировать ошибки. Многие могут быть связаны с выбросами, которые ML-система не умеет обрабатывать.
Проблема пятая: нелогичный прогноз модели
В отличие от дерева решений, другие модели могут возвращать значения, которых не было в обучении. Таким образом, можно столкнуться с ситуацией, когда величины, которые по определению не могут быть отрицательными (например, время или объем продаж) или слишком большими (как, например, рост человека), выходят за границы.
Решение. Добавить дополнительные проверки параметров и результатов, которые генерируют модели. Также стоит проводить анализ ошибок на тестовых выборках. Можно собрать статистику по наблюдениям, на которых были допущены ошибки, и попытаться найти закономерности между ними. Такой подход поможет выбрать правильную стратегию по улучшению модели.
Что почитать по теме:
«Различные оттенки неправды». Авторы этой научной работы попытались повысить производительность нейросети, обучив её исключительно на неправильных ответах. Идея заключалась в том, чтобы научить систему ИИ отличать факты различной степени «неправильности».
«Как анализировать и находить ошибки в LLM-приложениях». Пошаговое руководство от основателя площадки TechTalks, посвящённой архитектуре ПО и работе с данными.
Проблема шестая: несоответствие метрик задаче
Это подходящее место, чтобы напомнить: машинное обучение — не серебряная пуля. Вполне возможны (и вероятны) ситуации, когда для решения поставленной задачи будет достаточно построить грамотный SQL-запрос к базе данных. В общем, помним про первое правило машинного обучения: «Начинайте без машинного обучения».
Но если приняли решение работать с ML, стоит обратить внимание на метрики качества. Довольно частой ошибкой в этом контексте является использование некорректных бенчмарков при проведении экспериментов. Например, мы прогнозируем количество дней до выбытия вагона в ремонт — решаем задачу регрессии. Однако для бизнеса более важным критерием качества может быть не ошибка в днях, а факт поломки в конкретном месяце, и коллеги ориентируются на метрики задачи классификации.
Решение. Не забывать согласовывать с бизнесом ожидания по результатам, и в соответствии с этим выстраивать систему оценки качества. При необходимости можно вообще переформулировать задачу.
Что почитать по теме:
«ML для прогнозирования спроса на ж/д: экономическое обоснование». Мой коллега Леонид Зверев рассказал, как мы помогаем прогнозировать спрос на подвижные составы. Какие подходы работают и как мы улучшаем результаты.
Разумеется, это не все нюансы, связанные с проведением ML-экспериментов. О других характерных сложностях я как-нибудь расскажу в следующих материалах.
