Привет, меня зовут Артем Валов, я ведущий специалист команды по анализу данных в Синимекс. В статье поделюсь, как и зачем проводить трекинг экспериментов в ML.  

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

Здесь не будет примеров кода, так как существует множество инструментов и еще больше документации и статей для них :)

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

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

Основные этапы экспериментов

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

1. Определение таргета и оценка модели

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

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

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

2. Подготовка данных

   • Сбор начальных данных
     Сбор сырых данных из различных источников. Проведение разведочного анализа данных (EDA). Анализ качества сырых данных.

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

3. Обучение модели

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

   • Подбор гиперпараметров
     Тюнинг параметров для оптимизации работы модели. Полезным инструментом для осуществления этой цели будут такие популярные библиотеки, как optuna или hyperopt.

Общие проблемы и вызовы

• Ручное оформление: перенос метрик из логов в блокноты, Excel или вики может быть трудоемким и подверженным ошибкам.

• Риски локального хранения: сохранение графиков и аналитики в локальной среде увеличивает риск потери полученных результатов.

• Разделенные модели и кодовые базы: сохранение моделей отдельно от кода со временем может послужить причиной несоответствий между ожидаемой и фактической работой модели.

• Перегруженные репозитории Git: регулярная отправка всех данных в Git может в итоге перегрузить систему и усложнить управление версиями.

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

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

• Ненадежным метрикам и моделям — полученным результатам будет сложно доверять.

• Неэффективной автоматизации — отсутствие автоматизации или ее наличие приводит к новым ручным процессам.

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

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

Что такое трекинг экспериментов в машинном обучении?

Если кратко, трекинг экспериментов в машинном обучении — это процесс, включающий:

• Сохранение = Хранение артефактов для воспроизводимости эксперимента.

• Организацию = Структурирование экспериментов с настраиваемым доступом.

• Анализ = Сравнение результатов и исследование изменений.

Артефакты

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

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

2. Модель и гиперпараметры
   Фиксируйте все параметры, которые могут повлиять на модель и метрики. Храните обученную модель, которую можно будет развернуть позже.

3. Наборы данных
   Вы можете хранить сырые данные и данные после предобработки, но будьте осторожны с ограничениями хранилищ. Если ваш код детерминирован и вы можете зафиксировать его изменения, то достаточно начальных данных для получения всех производных артефактов как промежуточных, так и для обучения.

4. Код и зависимости
   Очевидно, что изменения в методах обработки данных или архитектуре модели неизбежно приведут к новым результатам. Однако бывает, что зависимости также могут повлиять на результат. Особенно ценно иметь возможность быстро восстановить определенное окружение эксперимента, если ранее были конфликты или она могла измениться в ходе исследования. Что если система трекинга может зафиксировать зависимости, построить окружение и запустить другой эксперимент O_o? Но об этом позже.

5. Метрики и показатели
   Ранее мы обсуждали, какие метрики мы можем сохранять, но мы также можем записывать показатели, связанные с данными, как метрики качества данных — размеры, пропуски, дрейф и т. д. Вы когда-нибудь видели, что кто-то получил sota-результаты просто потому, что потерял 80% тестовых данных?

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

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

Инструменты для трекинга экспериментов в машинном обучении

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

Популярность  инструментов

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

Следует отметить, что многими крупными компаниями используется wandb, и ml-энтузиасты часто делятся результатами экспериментов в облаке. Я не использовал этот инструмент, поэтому не могу сравнивать на личном опыте, но вы всегда можете загуглить, почему A лучше, чем B, и наоборот.

На моем опыте, ClearML зарекомендовал себя как эффективный инструмент как в крупных производственных проектах, так и в небольших исследовательских проектах или хакатонах.

Почему мы используем ClearML

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

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

2. Мы занимались прогнозированием временных рядов для аптечных сетей. При разработке прототипа в блокнотах у нас перестали воспроизводиться результаты, но так как трекинг сохранил блокнот как артефакт, то мы быстро восстановили утраченную версию и проверили что было не так или что повлияло на новые результаты. Также для быстрой аналитики мы логировали «debug samples»: графики таргета и прогноза случайных рядов, лучших и худших по метрике — это давало понимание какие случаи требуют доработки и позволяло формулировать новые гипотезы. Соответственно такую же практику мы применяли для проектов CV и NLP, так как интерфейс работает с разными форматами данных.

3. В компании есть свой продукт для организации собеседований, возникла идея добавить ML для автоматизации и мы решили начать с парсинга резюме с помощью открытых LLM. Мы подготовили среду, промпт, скрипты, данные и метрики. Так как в большей степени мы занимались промпт инжинирингом, то решили использовать clearml.agent, чтобы запускать эксперименты напрямую из интерфейса и распределять их на доступные ноды без необходимости вручную клонировать проект, собирать среду и запускать скрипты.

4. На проекте по синхронизации губ для создания цифровых двойников мы тестировали разные open-source решения. Возникла необходимость оценить текущее время работы пайплайна и в случае оптимизации. ClearML логирует нагрузку RAM, CPU, GPU, диска, сети, что позволило быстро оценить текущие требования и потенциал ускорения.

Суммируя и дополняя:

• Удобное разделение команды и проектов, красивый UI с примерами использования из коробки.

• Достаточное автологирование и широкая поддержка фреймворков.

• Возможность логирования различных артефактов через автологирование или вручную (таблицы, графики, метрики), при этом можно сохранить почти любой объект как pickle или даже папку (об этом отмечается в документации). Также есть возможность использовать различные хранилища для артефактов, например S3. Модели при сохранении локально также загружаются в Model Registry автоматически (в зависимости от фреймворка).

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

• Единое версионирование данных и моделей с легким доступом.

• Интерфейс для обзора данных и оценки изменений.

• Некоторые команды используют clearml.pipeline в качестве альтернативы Airflow.

• Мониторинг потребления ресурсов (CPU, GPU, диск) — крайне полезно для оценки требований на этапах предобработки, обучения и инференса или поиска «узких» мест.

• Удаленное исполнение через clearml.agent — легко добавить новые вычислительные ресурсы для экспериментов, которые можно определять в очереди.

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

• Отзывчивые мейнтейнеры, у которых есть собственный канал в Slack.

• И многие другие функции, направленные на создание единой системы разработки, такие как настройка CI/CD, развертывание, создание встраиваемых отчетов и балансировка нагрузки на кластер (некоторые функции платные).

Что следует выбрать вам?

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

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

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

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

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

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

• Безопасность доступа и возможность обмена результатами — предоставление результатов внешней аудитории, клиентам или менеджерам.

• Дополнительные функции, такие как развертывание приложение, поддержка работы с LLM.

Заключение

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

Clearml: https://clear.ml/docs/latest/docs/, https://www.youtube.com/@ClearML