Гайд по трекингу экспериментов в ML
Привет, меня зовут Артем Валов, я ведущий специалист команды по анализу данных в Синимекс. В статье поделюсь, как и зачем проводить трекинг экспериментов в ML.
Мы обсудим основы трекинга экспериментов в машинном обучении и расскажем, как вы можете упростить свой рабочий процесс с помощью правильных инструментов и практик. В заключение я также поделюсь опытом использования одного из инструментов и расскажу о его преимуществах.
Здесь не будет примеров кода, так как существует множество инструментов и еще больше документации и статей для них :)
Многие привыкли, что в качестве результата эксперимента достаточно метрик и просто сохранения обученной модели (чекпоинта), однако в современном мире машинного обучения ключевую роль в обеспечении воспроизводимости, надежности и эффективности играет трекинг экспериментов.
Для начала освежим в памяти основные этапы разработки решений использующих машинное обучение.
Основные этапы экспериментов
Большинство задач в мире машинного и глубинного обучения включают сбор данных, построение модели и оценку результатов. Для различных областей каждый этап может быть по-разному важным и трудоемким. Например, по опыту наших проектов, дата-сайентисты могут тратить до половины времени на подготовку данных и, как правило, результаты зависят в большей степени от качества датасета, чем от архитектуры модели, потому процесс работы с ними тоже важно фиксировать (похоже на варку кофе — можно использовать разные кофемашины, но вкус во многом зависит от зерен). Давайте кратко опишем основные шаги:
Определение таргета и оценка модели
Определение таргета
В первую очередь обсуждается что будет моделироваться в рамках эксперимента, так как от этого зависят подходы к решению и метрики оценки.Выбор метрик
Метрика — это внешний критерий качества, который зависит только от предсказанных меток и не зависит от процесса их получения. Метрики могут быть как критериями качества модели, так и конкретными оценками от клиента, важными для бизнеса (при этом они могут и противоречить интуиции, и быть в принципе некорректно поставленными, но это совсем другая история).Стратегия разбиения, выделение периода валидации
На этом этапе определяется стратегия разделения на обучающие, валидационные и тестовые наборы. В одних задачах может подойти случайное разбиение, а в некоторых случаях наборы могут быть разделены по времени.
Подготовка данных
Сбор начальных данных
Сбор сырых данных из различных источников. Проведение разведочного анализа данных (EDA). Анализ качества сырых данных.Преобразование и аугментация
Очистка и предобработка данных, чтобы сделать их пригодными для обучения модели. На этом этапе можно подумать и о том, как обогатить имеющийся набор данных с помощью генерации признаков и внешних источников.
Обучение модели
Выбор модели
Выбор подходящего алгоритма на основе вашей задачи. Удобней всего начать с базового варианта — быстрых и простых моделей или даже эвристик для отладки и получения первых метрик, а затем перейти к тестированию более продвинутых алгоритмов.Подбор гиперпараметров
Тюнинг параметров для оптимизации работы модели. Полезным инструментом для осуществления этой цели будут такие популярные библиотеки, как optuna или hyperopt.
Общие проблемы и вызовы
Ручное оформление: перенос метрик из логов в блокноты, Excel или вики может быть трудоемким и подверженным ошибкам.
Риски локального хранения: сохранение графиков и аналитики в локальной среде увеличивает риск потери полученных результатов.
Разделенные модели и кодовые базы: сохранение моделей отдельно от кода со временем может послужить причиной несоответствий между ожидаемой и фактической работой модели.
Перегруженные репозитории Git: регулярная отправка всех данных в Git может в итоге перегрузить систему и усложнить управление версиями.
Суммарно, подобные привычки могут привести к:
Недостаточной воспроизводимости — несогласованным результатам, которые будет трудно воспроизвести.
Ненадежным метрикам и моделям — полученным результатам будет сложно доверять.
Неэффективной автоматизации — отсутствие автоматизации или ее наличие приводит к новым ручным процессам.
Трудности доступа к результатам — сложности извлечения данных прошлых экспериментов. Примером этого может послужить ситуация «этот эксперимент был на компьютере Андрея, но он сейчас в отпуске))».
Обычно такие проблемы характерны для быстрого прототипирования, где тестируется много гипотез, но ошибки в ходе эксперимента в итоге могут дать ложное представление о дальнейшем развитии проекта, поэтому трекинг эксперимента должен присутствовать даже на начальных этапах, если это возможно.
Что такое трекинг экспериментов в машинном обучении?
Если кратко, трекинг экспериментов в машинном обучении — это процесс, включающий:
Сохранение = Хранение артефактов для воспроизводимости эксперимента.
Организацию = Структурирование экспериментов с настраиваемым доступом.
Анализ = Сравнение результатов и исследование изменений.
Артефакты
Для воспроизведения эксперимента нам нужны артефакты. Артефакты могут значительно варьироваться в зависимости от сложности пайплайна и целей моделирования. В большинстве случаев важно, чтобы команда работала с единой «точкой входа» для построения модели, если гипотезы строятся на уровне моделирования. Напротив, если нам нужно оценить новые признаки или наш набор данных расширился, важно иметь возможность быстро получить доступ к новой версии, не теряя предыдущие. Рассмотрим ниже что мы можем подразумевать под артефактами:
Описание эксперимента и метаданные
Важно описать, какую гипотезу мы тестируем в рамках эксперимента, чтобы не гадать через несколько месяцев, какова была цель или какие изменения были внесены.Модель и гиперпараметры
Фиксируйте все параметры, которые могут повлиять на модель и метрики. Храните обученную модель, которую можно будет развернуть позже.Наборы данных
Вы можете хранить сырые данные и данные после предобработки, но будьте осторожны с ограничениями хранилищ. Если ваш код детерминирован и вы можете зафиксировать его изменения, то достаточно начальных данных для получения всех производных артефактов как промежуточных, так и для обучения.Код и зависимости
Очевидно, что изменения в методах обработки данных или архитектуре модели неизбежно приведут к новым результатам. Однако бывает, что зависимости также могут повлиять на результат. Особенно ценно иметь возможность быстро восстановить определенное окружение эксперимента, если ранее были конфликты или она могла измениться в ходе исследования. Что если система трекинга может зафиксировать зависимости, построить окружение и запустить другой эксперимент O_o? Но об этом позже.Метрики и показатели
Ранее мы обсуждали, какие метрики мы можем сохранять, но мы также можем записывать показатели, связанные с данными, как метрики качества данных — размеры, пропуски, дрейф и т. д. Вы когда-нибудь видели, что кто-то получил sota-результаты просто потому, что потерял 80% тестовых данных?Логи и графики
Логи полезны для отображения выводов EDA, преобразования данных или трекинга процесса обучения. Графики могут быть частью метрик или служить дополнительной аналитикой, которая затем будет отражена в отчете (частое требование, например, для банков). По ним во многом ясно что «пошло не так» в рамках моделирования.
Можно просто «снимать метрики», но основная идея здесь заключается не только в оценке последствий эксперимента, но и в наличии контрольных точек для отладки, если будут обнаружены явные или скрытые проблемы. Будьте мудрыми и пробуйте. Логирование всего что есть — может быть трудным путем, поэтому следуйте своим потребностям.
Воспроизводимость прошлых экспериментов позволяет нам надежно тестировать новые гипотезы. И если у вас есть баг в эксперименте, то при перезапуске он будет присутствовать во всех экспериментах. Разве это не стабильность? (шутка)
Инструменты для трекинга экспериментов в машинном обучении
Это достаточная часть инструментов, но у них всех есть много общих функций. Самые популярные инструменты, вероятно, будут регулярно обновляться и поддерживаться. Некоторые трекеры изначально использовались для другой цели, например, DVC как система версионирования данных получила расширение для трекинга экспериментов.
Популярность инструментов
Ранее я использовал MLFlow и ClearML, и в настоящее время моя команда преимущественно использует ClearML. Для базовых задач, таких как логирование метрик и сохранение моделей, оба инструмента подходят. MLFlow проще настроить и сейчас предлагает новые функции, ориентированные на LLM и проектирование промптов. Если позволяют ресурсы, ClearML предоставляет более надежное и масштабируемое решение с огромным списком функций разработки.
Следует отметить, что многими крупными компаниями используется wandb, и ml-энтузиасты часто делятся результатами экспериментов в облаке. Я не использовал этот инструмент, поэтому не могу сравнивать на личном опыте, но вы всегда можете загуглить, почему A лучше, чем B, и наоборот.
На моем опыте, ClearML зарекомендовал себя как эффективный инструмент как в крупных производственных проектах, так и в небольших исследовательских проектах или хакатонах.
Почему мы используем ClearML
Прежде чем привести целый список фичей, приведу несколько ситуаций, которые нам помог разрешить ClearML:
У нас было несколько параллельных проектов у которых были свои ветки гипотез для проработки. В MLFlow нам не хватало группировки проектов и мы могли бы получить хаус из экспериментов, но в ClearML реализована иерархия, так что исследования можно проводить изолированно вплоть до каждого разработчика или гипотезы или пользоваться фильтрами. Кроме того, было удобно определить права доступа: какие эксперименты видят разработчики, менеджеры или стейкхолдеры.
Мы занимались прогнозированием временных рядов для аптечных сетей. При разработке прототипа в блокнотах у нас перестали воспроизводиться результаты, но так как трекинг сохранил блокнот как артефакт, то мы быстро восстановили утраченную версию и проверили что было не так или что повлияло на новые результаты. Также для быстрой аналитики мы логировали «debug samples»: графики таргета и прогноза случайных рядов, лучших и худших по метрике — это давало понимание какие случаи требуют доработки и позволяло формулировать новые гипотезы. Соответственно такую же практику мы применяли для проектов CV и NLP, так как интерфейс работает с разными форматами данных.
В компании есть свой продукт для организации собеседований, возникла идея добавить ML для автоматизации и мы решили начать с парсинга резюме с помощью открытых LLM. Мы подготовили среду, промпт, скрипты, данные и метрики. Так как в большей степени мы занимались промпт инжинирингом, то решили использовать clearml.agent, чтобы запускать эксперименты напрямую из интерфейса и распределять их на доступные ноды без необходимости вручную клонировать проект, собирать среду и запускать скрипты.
На проекте по синхронизации губ для создания цифровых двойников мы тестировали разные open-source решения. Возникла необходимость оценить текущее время работы пайплайна и в случае оптимизации. ClearML логирует нагрузку RAM, CPU, GPU, диска, сети, что позволило быстро оценить текущие требования и потенциал ускорения.
Суммируя и дополняя:
Удобное разделение команды и проектов, красивый UI с примерами использования из коробки.
Достаточное автологирование и широкая поддержка фреймворков.
Возможность логирования различных артефактов через автологирование или вручную (таблицы, графики, метрики), при этом можно сохранить почти любой объект как pickle или даже папку (об этом отмечается в документации). Также есть возможность использовать различные хранилища для артефактов, например S3. Модели при сохранении локально также загружаются в Model Registry автоматически (в зависимости от фреймворка).
Версионирование кода (включая блокноты) имеет ключевое значение для воспроизведения результатов и отладки.
Единое версионирование данных и моделей с легким доступом.
Интерфейс для обзора данных и оценки изменений.
Некоторые команды используют clearml.pipeline в качестве альтернативы Airflow.
Мониторинг потребления ресурсов (CPU, GPU, диск) — крайне полезно для оценки требований на этапах предобработки, обучения и инференса или поиска «узких» мест.
Достаточно установить ClearML и инициализировать объект Task в скрипте. ClearML автоматически соберет информацию по потреблению ресурсов, запишет все логи, добавит в реестр моделей сохраняемые чепоинты и тд. Самое прекрасное, что под таской может быть что угодно — на скрине препроцессинг данных (референс к Airflow). Графики интерактивные и их можно редактировать.
Удаленное исполнение через clearml.agent — легко добавить новые вычислительные ресурсы для экспериментов, которые можно определять в очереди.
Быстрые эксперименты — например, дублируете существующий эксперимент, меняете параметры или промпт и запускаете на свободной ноде. Благодаря отслеживанию зависимостей и изменений кода, система может создать докер-контейнер и провести эксперимент удаленно через agent.
Отзывчивые мейнтейнеры, у которых есть собственный канал в Slack.
И многие другие функции, направленные на создание единой системы разработки, такие как настройка CI/CD, развертывание, создание встраиваемых отчетов и балансировка нагрузки на кластер (некоторые функции платные).
Что следует выбрать вам?
Как и любой продукт, люди часто выбирают то, что более доступно, проще или знакомо. Вот некоторые аспекты, которые могут вам помочь:
Открытый код против коммерческого решения — open-source часто подходит для небольших команд, тогда как крупным компаниям требуется поддержка используемых решений и расширенные возможности.
Облачное или локальное развертывание — если у вас есть конфиденциальные данные, то предпочтительнее локальный сервис. Если у вас нет собственных ресурсов, можно использовать облако.
UI, удобство организации экспериментов и эстетичный интерфейс — у некоторых инструментов отсутствует иерархия проектов, и если самих проектов много, это может привести к хаосу.
Интеграция с вашими фреймворками — автологирование скорее приятный бонус, но в целом не критично, так как вы все равно можете сохранять артефакты вручную.
Поддержка командного взаимодействия — ролевая модель доступа и ограничение прав повышают безопасность и надежность (чтобы никто случайно не удалил важные результаты), улучшают структуру. Иногда сложно найти свои эксперименты в команде, не говоря уже о поиске среди всех возможных экспериментов.
Безопасность доступа и возможность обмена результатами — предоставление результатов внешней аудитории, клиентам или менеджерам.
Дополнительные функции, такие как развертывание приложение, поддержка работы с LLM.
Заключение
По мере того как инструменты развиваются и покрывают недостающие функции, имеет смысл составить список самых популярных и поддерживаемых, протестировать их на реальных задачах и выбрать тот, который лучше всего подходит вашим потребностям.
Clearml: https://clear.ml/docs/latest/docs/, https://www.youtube.com/@ClearML
