Гайд по трекингу экспериментов в ML

de91e7dab69403307680f13151663549.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Артефакты

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

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

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

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

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

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

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

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

Воспроизводимость прошлых экспериментов позволяет нам надежно тестировать новые гипотезы. И если у вас есть баг в эксперименте, то при перезапуске он будет присутствовать во всех экспериментах. Разве это не стабильность? (шутка)

Воспроизводимость прошлых экспериментов позволяет нам надежно тестировать новые гипотезы. И если у вас есть баг в эксперименте, то при перезапуске он будет присутствовать во всех экспериментах. Разве это не стабильность? (шутка)

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

Инструменты, https://www.trail-ml.com/blog/first-steps-experiment-tracking 

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

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

Приятно видеть, что культура использования трекинга растет. Между тем разработчики инструментов гибко адаптируются к новым тенденциям в мире и используют их в маркетинге, например фичи для работы с LLM. Источник для построения графика star-history.com

Приятно видеть, что культура использования трекинга растет. Между тем разработчики инструментов гибко адаптируются к новым тенденциям в мире и используют их в маркетинге, например фичи для работы с LLM. Источник для построения графика star-history.com

Ранее я использовал 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 и инициализировать объект Task в скрипте. ClearML автоматически соберет информацию по потреблению ресурсов, запишет все логи, добавит в реестр моделей сохраняемые чепоинты и тд. Самое прекрасное, что под таской может быть что угодно — на скрине препроцессинг данных (референс к Airflow). Графики интерактивные и их можно редактировать.

Достаточно установить ClearML и инициализировать объект Task в скрипте. ClearML автоматически соберет информацию по потреблению ресурсов, запишет все логи, добавит в реестр моделей сохраняемые чепоинты и тд. Самое прекрасное, что под таской может быть что угодно — на скрине препроцессинг данных (референс к Airflow). Графики интерактивные и их можно редактировать.

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

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

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

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

4baf89f8c69967e2e40c73adef903113.png

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

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

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

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

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

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

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

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

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

Заключение

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

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

© Habrahabr.ru