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

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

В этой статье мы рассмотрим процесс автоматического переобучения моделей 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.

Процесс начинается с загрузки кода и его тестирования. После проверок кода происходит сборка окружения модели и сохранение архива с ним в 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, но продолжает существовать.

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

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

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

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

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

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