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

В этой статье мы рассмотрим процесс автоматического переобучения моделей ML в продакшене, используя инструменты MLOps. Обсудим интеграцию таких инструментов, как AirFlow и Spark, с CI/CD пайплайнами, а также создание конфигурационного модуля, позволяющего разработчикам сосредоточиться на моделях, не углубляясь в инфраструктурные детали.

Обычно DevOps пайплайны строятся на основе CI/CD инструментов, таких, как сборка образов и деплой на Kubernetes. Однако в контексте машинного обучения требуются более специфичные инструменты, такие, как AirFlow и Spark.

Для интеграции Spark с Kubernetes мы используем специальные операторы, которые управляют запуском SparkApplication и созданием Spark сессий в рамках Pod. AirFlow работает с DAG — ацикличными графами, описываемыми на Python. Эти технологии имеют свои способы запуска: от отдельных манифестов Kubernetes до скриптов на Python.

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

DS создают конфигурационный файл в своём репозитории для работы с нашим модулем. В файле указывается информация о модели: время и интервал запуска DAG-ов, параметры для Spark-сессии, версия Python для запуска модели и другие параметры для обучения, выкладки и мониторинга. Задача модуля — взять пользовательскую конфигурацию, создать на её основе Spark Application, DAG и разместить всё это в AirFlow Scheduler в рамках пайплайна, написанного на Jenkins.

Untitled — Jenkins пайплайн генерации манифестов и DAG

Процесс начинается с загрузки кода и его тестирования. После проверок кода происходит сборка окружения модели и сохранение архива с ним в S3 хранилище.

Вы возможно удивитесь и спросите «А где Docker образы?». Здесь мы отказались от стандартного подхода со сборкой Docker-образов в пользу хранения tar.gz архивов по следующим причинам:

Скорость: сборка и загрузка архива занимает меньше времени, чем создание и загрузка больших Docker-образов.
Отладка: имея архив с окружением, можно легко его скачать, например, в JupyterLab, создать новое окружение и протестировать модель.

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

Теперь у нас есть готовое окружение для работы модели, DAG для AirFlow и манифест для запуска SparkApplication в кластере. Мы можем запустить обучение.

В рамках DAG используем популярный Spark Operator, который создает Spark сессии и ожидает их завершения.

Первая таска запускает сессию Spark: в Kubernetes создаётся сущность Spark Application, манифест которой был передан в Scheduler на предыдущем этапе. Spark Application создает Pod, в котором начинается обучение модели.
Вторая таска Spark Wait отслеживает состояние Spark Application после его создания.

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

Давайте ещё раз посмотрим верхнеуровнего, что происходит.

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

Если у нас запущен пайплайн по обучению, то в DAG запускается обучение и последующая проверка качества. Если у нас запущен пайплайн инференса, то запускается соответствующий скрипт. Аналогичное происходит и с мониторингом. Параметры для всех DAG-ов и SparkApplications выставляются в зависимости от того, что указано в конфигурации от DS.

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

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

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

В последних версиях MLFlow были добавлены тэги и алиасы для разных версий модели. Тэги в MLFlow позволяют добавлять метаданные к моделям и их версиям для их описания и классификации, что облегчает поиск и управление. Алиасы служат для создания удобных ссылок на конкретные версии моделей, что упрощает переключение между ними и управление их состояниями (например, production, staging).

Логика промоутера проста:

Если модель обучена качественно, ставится тэг success и выставляется алиас с названием стенда, который не может повторяться для других версий одной модели и четко помечает актуальную. Далее запускается пайплайн выкладки и копирование окружения в S3 хранилище на следующем стенде.
Если модель не проходит проверку качества, она помечается тэгом failed, но продолжает существовать.

Untitled — Жизненный цикл моделей на средах

У нас есть четыре среды: разработка MDP (model development platform), две для тестирования SIM (system of inference models) INT/LT и продакшн SIM Prom. На среде разработки DS создают модель и запускают её обучение. После проверки качества промоутер запускает инференс и параллельно отправляет окружение на следующий стенд.

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

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

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

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

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

Автопереобучение моделей в Production