Ветви – всё, что вам нужно наша благосклонная рамка версионирования ML

Ветви - идеальная благосклонная рамка версионирования ML, которая вам нужна

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

Краткое изложение

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

Введение

При управлении решениями машинного обучения различные аспекты решений часто распределены по нескольким платформам и местоположениям, таким как GitHub для кода, HuggingFace для моделей, Weights and Biases для отслеживания, S3 для копии всего и т. д.

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

Это легко выйти из-под контроля.

Image by author

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

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

Нам приходилось управлять тем, какая двоичная модель обучалась с каким обучающим кодом на каких данных клиента, какая модель запускается на каком клиенте с каким кодом вывода и т. д.

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

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

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

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

В этой статье я продемонстрирую фреймворк, который заменяет сложность переключения между инструментами на Git, систему, которую уже используют практически все команды МО.

Цель состоит в упрощении и снятии преград при начале каждого этапа рабочего процесса в МО, имея все в одном месте и управляемое Git.

Наши требования

  1. Простой рабочий процесс, который легко приостанавливать, возвращаться к работе и настраивать под изменяющиеся коммерческие и разработческие потребности. Он также должен поддерживать воспроизводимость и позволять осуществлять постфактум запросы, такие как “На каких данных была обучена моя модель?”
  2. Эффективное использование данных и кода, с акцентом на согласованность, управление и аудит. – Стремитесь использовать данные и код максимально возможно и использовать функции Git, такие как фиксации, проблемы и теги.
  3. Консолидация всех различных аспектов решения МО важна. Часто отслеживание экспериментов, мониторинг моделей в продакшене, онлайн- и офлайн-эксперименты разделены с обучением и выводом решения. Здесь мы стремимся объединить их под одним зонтиком, чтобы легко переключаться между ними.
  4. Следовать лучшим практикам Git и МО, таким как раннее и общедоступное разделение данных, тестирование и простое сотрудничество для различных инженеров МО.

Основные понятия

Каждое изменение – это фиксация Git: Это включает загрузку данных, создание фичей, переопределение модели, слияние результатов измерения экспериментов, мониторинг модели и, естественно, изменение кода.

Активные ветви: Обычной практикой является использование разных ветвей для разработки и продукции. Однако здесь мы можем пойти дальше. Это означает, что вы можете переключиться на ветку и иметь все необходимые данные, код, модели, документы, README-файлы и карточки моделей с метриками в одном месте.

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

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

Слияние в качестве рабочего процесса: Они используются для объединения ветвей. Код объединяется обычным образом, а модель обычно заменяет существующую модель. При объединении данных они обычно добавляются. Чтобы получить новые данные, они “притягиваются” из другой ветви путем копирования.

Слияние данных может быть таким простым, как копирование файлов или добавление их к списку JSON. В более сложных случаях вы можете объединять базы данных sqlite.

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

Типы ветвей

Изображение от автора

Главная ветвь

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

СОВЕТ: Начиная с четкого определения бизнес-проблемы, определения желаемого результата, идентификации целевых значений или меток и способа их получения, а также создания метрик и требований для оценки, мы можем обеспечить успешный запуск проекта и создать место для включения и сотрудничества.

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

В качестве альтернативы отслеживание может быть выполнено в другой ветви.

Такой подход очень прост в начале, и по мере изменения потребностей можно легко перейти к серверу MLflow или платформе отслеживания, такой как Weights and Biases, с минимальными изменениями.

Ветви данных

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

Рекомендуется всегда коммитить (загружать) в ветвь raw. Это создает источник истины, место, которое никогда не изменяется и не удаляется, так что мы всегда можем отслеживать, откуда и какие данные поступают. Это также позволяет легко создавать новые потоки, а также проводить аудиты и контроль.

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

Вы можете использовать другую чистую ветвь, где существуют только чистые данные. Например, поврежденные изображения или пустые текстовые файлы, которые были загружены в ветвь raw, не появляются в ветви clean.

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

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

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

Изображение от автора

💡 Совет по ML: Лучшие практики разработки модели в трех фазахМы используем наборы данных “train” и “validation” для обучения и оптимизации гиперпараметров модели. Затем мы используем объединенные наборы train и validation как обучающий набор для обучения нашей настроенной модели и оценки с использованием тестового набора данных только один раз. В конце концов, мы обучаем модель на всех данных и сохраняем ее как нашу модель.

Стабильные ветки

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

⚠️ В этих ветках нет написанного кода.

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

💡 Совет: Заранее выбрав имя тега, вы можете добавить информацию для отслеживания во время обучения в качестве параметра. Это гарантирует, что вы всегда сможете получить “снимок” модель-данные-код по данным отслеживания с помощью любого инструмента отслеживания.

После обучения только данные трекинга объединяются (копируются) в вашу основную ветку для отслеживания.

В наиболее простом случае это может быть файл текста JSON, содержащий гиперпараметры и результаты оценки. Затем этот файл добавляется в список в основной ветке. В случае использования MLflow это включает копирование экспериментов из папки mlruns в основную ветку.

Ветки разработки

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

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

💡 Инженеры ML и MLOps могут сотрудничать на этапах обучения и вывода.

Например, вы можете создать ветку dev/model, где разрабатывается базовая модель. Это может быть наиболее популярный класс для классификации или среднее/медиана для регрессии. Главное – настроить код, хорошо разобравшись в данных.

Когда все станет стабильным и тесты пройдут, мы создаем ветку stable/model, где обучаем и коммитим модель, код и данные вместе на удаленный репозиторий и ставим тег для этого коммита. Это быстро и легко делиться и позволит командам DevOps, бэкенда и фронтенда начать разработку и обмениваться обратной связью. Это также способствует проверке вновь обнаруженных требований в реальной среде как можно раньше.

Затем мы разрабатываем модель на ветке dev/model до простейшей модели, например, линейной регрессии, и когда она будет готова и пройдет тесты, мы можем объединить ее с веткой stable/model, где мы обучаем, коммитим и ставим тег релиза в продакшн.

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

Image by author

С этого момента у нас есть три варианта:

  • Мы можем переобучить модель, когда поступит больше данных, перенеся их в стабильную ветку.
  • Мы можем начать экспериментировать, используя инженерию признаков на ветке dev/linear-regression.
  • Мы можем создать новую ветку dev/new-approach для более сложных моделей.

Ветка мониторинга

При мониторинге модели нас интересует распределение данных, выбросы и распределения прогнозов.

В ветке мониторинга мы сохраняем запрашиваемые данные, коммитим тег и прогноз модели из продакшна в виде файлов.

💡 Вы можете использовать несколько ветвей мониторинга для каждой среды – dev, stable и prod.

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

Image by author

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

Ветка анализа

Научно-исследовательский анализ – это еще один аспект проекта, который часто выделяется в отдельный проект. Здесь собираются аналитический код и необучающие данные для данных специалистов.

Научный сотрудник может проверить и получить данные из ветви мониторинга для запуска анализа, A/B-тестов и других онлайн- и оффлайн-экспериментов. Они также могут использовать данные из ветви raw для этих целей.

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

💡 Совет: Общие онлайн-эксперименты:

Прямой тест – Сравнение текущей модели 99% с кандидатской моделью 1%.

Обратный тест – после объединения новой модели, оставляем 1% на предыдущей модели для проверки ожидаемого эффекта в обратном направлении.

При наличии метки модели в данных мониторинга вы можете определить каждое изменение потенциальной причины метрики.

Резюме

Image by author

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

Если вы хотите пообщаться или узнать больше, присоединяйтесь к нам на нашем discord или следите за нашим блогом.

Эпилог

Что касается моей проблемы с сервером, мы поддерживали “стабильную” ветвь для каждой соответствующей комбинации кода обучения и набора данных. После завершения обучения мы могли пометить фиксацию соответствующей меткой (<идентификатор клиента>-<инкрементальная версия>). Клиенты могли принимать самую последнюю метку, так же, как и любой другой выпуск.

При “отладке” клиента мы бы обращались к метке в определенный момент, чтобы просмотреть код и соответствующие данные. Мы также могли сопоставить данные мониторинга, используя ту же метку, которая была добавлена в данные мониторинга. Ноутбуки анализа можно найти на наших ветвях ds/client-id.