В данном материале мы переводим статью от Google, разбираем их опыт внедрения и видения MLOps практик в Machine Learning.

MLOps: Continuous delivery and automation pipelines in machine learning

В статье обсуждаем техники и подходы для осуществления и автоматизации continuous integration (CI), continuous delivery (CD) и continuous training (CT) для Machine Learning систем.

DS и ML становятся основными возможностями для решения сложных проблем в разных сферах. В данный момент для успешного применения Machine Learning подходов нам доступны:

Различные датасеты: Большие, маленькие, платные, открытые.
Относительно недорогая вычислительная мощность.
Специальные ускорители для ML на различных платформах (в cloud, девайсах итд)
Быстрый прогресс в различных областях исследований: NLP, CV, рекомендательные системы.

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

Статья предназначена для Data Scientist'ам и ML Engineer'ам, кто хотел бы применить принципы DevOps в ML системах (MLOps).

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

Data Scientist может реализовать и обучить модель с хорошей точностью, на каком-то датасете, учитывая его особенности. В то время как реальный челлендж состоит в построении интегрированной ML системы и ее непрерывном использовании в продакш среде. Компания Google описывает свой опыт решения проблем в ML сервисах в этой статье.

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

Рисунок 1. Элементы ML системы. Hidden Techincal Debt in Machine Learning Systems.

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

Для разработки и управления такими системами можно применить DevOps принципы к ML системам (MLOps). В статье описаны концепции, которые следует учитывать при настройке MLOps среды в ваших проектах в области анализа данных, такие как CI, CD, CT в ML.

Обсуждаются следующие темы:

DevOps vs MLOps
Шаги разработки ML моделей
Уровень зрелости MLOps в проекте

DevOps vs MLOps

DevOps - это популярная практика в управлении крупномасштабным ПО. Такая практика дает преимущества в виде сокращении времени цикла разработки, увеличения скорости развертывания системы, и повышает ее стабильность. Чтобы добиться этих преимуществ, вводятся две концепции в разработке ПО:

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

В тоже время ML системы отличаются от других ПО следующими моментами: "То как должна выглядеть команда для успешного внедрения MLOps практик"

Team skills: В ML проекте команда обычно состоит из DS или ML researcher'ов, которые сфокусированы на изучении данных, разработке моделей и экспериментах. Эти участники команды могут не быть "скилловыми software инженерами".
Develop: ML носит экспериментальный характер. Приходится пробовать разные подходы, методы, алгоритмы, конфигурации, пытаясь найти подходящую. Челлендж состоит в том, чтобы отслеживать, что работало, а что нет, сохраняя воспроизводимость, при этом максимизируя переиспользованность кода.
Testing: Тестирование ML системы, более обширная задача, к типичным unit и интеграционным тестам добавляется валидация данных, model evaluation и этап model validation.
Deployment: В ML системах деплой - это не просто обновление обученной модели как инференс сервиса. В ML системах может потребоваться поэтапный деплой пайплайна для автоматического обучения и развертывания инференс сервиса. Этот пайплайн усложняет работу и требует автоматизации шагов, которые перед деплоем делаются вручную data scientist'ом для обучения и валидации модели.
Production: На этом этапе нам потребуется наблюдение за моделью, отслеживание ее деградации и состояния в продакшн среде. Также требуется отслеживать статистику в данных и производительность, чтобы иметь возможность рассылать уведомления или откатывать версию, когда что-то идет не по плану.

ML и другое ПО схожи в continuous integration(CI) актуальной версии кода, модульного тестирования, интеграционного тестирования и continuous delivery(CD). Но с некоторыми отличиями для ML систем:

CI - теперь это не только тестирование, валидация кода и компонентов, но еще и тестирование и валидация данных, схем данных и моделей.
CD - теперь это не просто пакет или сервис, а система (ML training pipeline), который должен автоматически разворачивать другой сервис(имеется в виду поднимать инференс сервер)
CT - это новая сущность, уникальная для ML, суть ее в автоматическом переобучении и сервинге моделей.

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

Data Science steps for ML

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

Data Extraction: Вы выбираете и собираете релевантные данных из разных источников.
Data analysis: Подготавливается exploratory data analysis(изучение данных), чтобы понять и выявить нужные данные для построения ML моделей. Этот процесс ведет к следующему:
1. Понимание схем данных и характеристик, которые ожидает модель.
2. Определение подготовки данных и проектирование функций, необходимых для модели.
Data preparation: Деление на обучающий, тестовый и валидационный наборы данных, применение преобразований, аугментаций итд. Результатом данного шага являются данные, полученные в подготовленном формате.
Model training: Data scientist реализовывает различные подходы к обучению с подготовленными на предыдущем шаге данными, чтобы получить несколько моделей. Также он может перебирать различные гиперпараметры, для получения лучшей модели. Результатом данного шага является натренированная модель.
Model evaluation: Процесс подсчета метрик на тестовом наборе данных. Результатом данного шага является набор метрик, описывающий качество работы модели.
Model validation: Процесс принятия модели для развертывания, ее сравнение с предыдущей моделью, анализ производительности.
Model serving: Прошедшая этап валидации модель деплоится в выбранное окружение, деплоймент может быть:
1. Микросервисы с REST API для выполнения предсказаний.
2. Модель встроенная в какое-то устройство, например мобильное.
3. Часть системы прогнозирования
Model Monitoring: Отлеживаются производительность и некоторые метрики качества, чтобы можно было инициализировать новый этап в ML процессе.

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

MLOps level 0: Ручной процесс

Во многих командах есть data scientist'ы и ml researcher'ы, которые могут строить и обучать хорошие state-of-the-art модели, но их процесс построения и деплоя этих моделей полностью ручной. Это считается базовым уровнем зрелости, уровнем 0. На следующей диаграмме показан "workflow" этого процесса.

Рисунок 2. Ручные шаги для сервинга модели как инференс сервера.

Характеристики

Следующие список характеристик отражает MLOps level 0 процесс:

Ручной, скриптовый интерактивный процесс: Каждый из стандартных шагов выполняется вручную, требуется ручное исполнение кода, и ручной обмен данными между шагами. Процесс обычно исполняется какими-то "экспериментальными" скриптами, исполняемым в ноутбука(jupiter) data scientist'ом, пока достаточная по метрикам модель не будет обучена.
Disconnect between ML and operations: Процесс делит data scientist'ов, кто разрабатывает модели и инженеров, кто их сервит. DS передает инженеру модель в виде артефакта, команде инженеров. Это может выглядеть как обновление модели на каком-то хранилище(S3, итд) или загрузка в model registry. Далее инженеры, которые будут деплоить эту модель, делают новую "фичу" доступной пользователям, с минимальной задержкой, что может привести к training serving skew.
Infrequent release iterations: Процесс предполагает, что команда data scientist'ов менеджерит какое-то количество моделей, а частота их обновления не очень понятна. Меняться может архитектура модели или просто переобучение на новых данных.
No CI: Поскольку предполагаются какие-то изменений в реализации, CI игнорируется. Обычно тестирование кода, это запуск ноутбуков или каких-то скриптов. Эти скрипты или ноутбуки, исполняющие эксперимент добавляются в source-controlled и выдают артефакты в виде моделей и наборов метрик.
No CD: Так как нет версионированного деплоя моделей.
Deployment refers to a prediction service: Этот процесс касается только деплоя обученной модели как "предикшн сервиса", это может быть микросервис с REST API например, а не деплой ML системы.
Lack of active performance monitoring: Отсутствие активного мониторинга производительности. Процесс не анализирует работу модели, который требуется для отслеживания деградации модели.

Команда инженеров может иметь свои настройки и конфигурации API, тестирования, деплоймента, включая нагрузочное тестирование. Также продакшн ML может проходить этап A/B тестирования или онлайн эксперименты, перед тем как принять на себя весь трафик.Challenge

Challenge

MLOps level 0 выстроен и применяется во многих компаниях. Такого ручного ''data-scientist-driven'' процесса может быть достаточно, когда модели относительно редко обновляются. На практике модели могут "ломаться" в продакшн среде после деплоя. Это может происходить по разным причинам, подробнее можно почитать в статье why machine learning models crash and burn in production.

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

Actively monitor the quality of your model in production: Мониторинг позволяет вам отследить падения производительности и деградацию модели. Он действует как сигнал к новой итерации переобучения модели на новых данных.
Frequently retrain your production models: Чтобы отследить изменяющиеся паттерны или другие изменения в данных, необходимо периодически обучать модель на новых данных.
Continuously experiment with new implementations to produce the model: Постоянно пробовать что-то новое, подходы архитектуры итд.

Практики MLOps для CI/CD и CT полезны для решения этого ручного процесса. Развернув контейнер с ML ситемой вы можете включить этапы CT и настроить CI/CD для быстрого тестирования, сборки и деплоя новых версий ML пайплайна. Эти "фичи" обсудимдалее.

MLOps Level 1

Суть Level 1 во внедрении шага Continuous Training, автоматизацией ML пайплайна. Это даст нам возможность настроить Continious Delivery до продакшн сервиса. Чтобы автоматизировать процесс, используя новые данные для переобучения модели нужно предложить автоматизированные шаги подготовки данных, обучения и валидации моделей, а также настроить пайплайн триггеры и менеджмент метаданных.

Схема 1. Схематичное представление автоматизированного пайплайна CT.

В следующем списке выделены характеристики настройки Level 1.

Быстрые эксперименты: Шаги процесса ML эксперимента согласованы. Переходы между шагами автоматизированы для проведения быстрых итераций эксперимента и повышенной готовности для перемещения пайплайна в продакшен среду.
Model CT to production: Модель автоматически обучается в продакшн среде, используя актуальные данные и пайплайн триггеры.
Экспериментально-операционная симметрия: реализация конвейера, которая используется в среде разработки или эксперимента, используется в среде подготовки и производства, что является ключевым аспектом практики MLOps для унификации DevOps.
Модульный код для компонентов и конвейеров: чтобы построить конвейеры ML, компоненты должны быть повторно используемыми, компонуемыми и потенциально совместно используемыми в конвейерах ML. Следовательно, хотя код EDA может по-прежнему находиться в записных книжках, исходный код компонентов должен быть модульным. Кроме того, в идеале компоненты должны быть помещены в контейнеры для выполнения следующих задач:
- Decouple the execution environment from the custom code runtime.
- Make code reproducible between development and production environments.
- Isolate each component in the pipeline. Components can have their own version of the runtime environment, and have different languages and libraries.
Apply models CD: ML пайплайн непрерывно доставляется в продакшн инференс сервер и обучается на новых данных. Шаг деплоинга модели, когда прошедшие валидацию модели переходят на шаг сервинга моделей и создания инференс сервисов.
Pipeline deployment: На Level 0 вы деплоили модель как инференс сервер. Level 1 подразумевает deploy всего training pipeline, который автоматически и рекурсивно раннится, while srving trained and validated models as prediction service.

Дополнительные компоненты

Обсудим компоненты, которые необходимо добавить в архитектуру для создания ML CT.

Валидация данных и модели

При деплоя ML пайплайна в продакшн один или несколько тригерров (Будут описаны позже) одновременно могут выполнять пайплайн. Пайплайн ожидает, что новые данные создадут новую, актуальную версию модели (как показано на Схеме 1). Следовательно в пайплайне требуются следующие этапы проверки данных и модели, чтобы гарантировать ожидаемое поведение:

Data validation: Этот шаг требует выполнения перед обучением модели, чтобы решить перейти ли к следующему шагу или остановить выполнение пайплайна. Решение принимается автоматически, если обнаружилось следующее:
- Data schema skews: Отклонения схемы данных, считаются отклонениями и аномалиями, что будет означать, что последующие шаги пайплайна получат данные, не соответствующие ожидаемым схемам. В этом случае следует остановка выполнения пайплайна, чтобы команда DS могла разобраться. Команда может выпустить исправление или обновление конвейера для обработки этих изменений в схеме. Отклонения схемы включают получение неожиданных функций, неполучение всех ожидаемых функций или получение функций с неожиданными значениями.
- Data values skew: Эти отклонения показывают изменения в статистических показателях данных, что означает, что паттерны в данных меняются, и необходимо затригерить обучение модели на новых данных.
Model validation: Шаг после успешного обучения модели на новых данных. Оцениваем модель до запуски в прод, имеет след этапы:
- Получение метрик на тестовом датасете, для понимания качества работы модели.
- Сравнение старой модели и новой. Убеждаемся что обновляться имеет смысл.
- Проверяем что производительность модели в допустимых пределах.
- Убедиться, что новая модель корректно работает в инфраструктуре.

Feature store

Еще один опциональный компонент для автоматизации level 1 ML пайплайна. Это централизванное хранилище, в котором вы стандартизируете определение, хранение и доступ к "фичам" обучения и сервинга. Feature store должно предоставлять API как для высокопроизводительного пакетного обслуживания, так и для обслуживания в реальном времени с малой задержкой для значений функций, а также для поддержки как обучения, так и обслуживания рабочих нагрузок. ****

Feature store поможет DS в следующем:

Искать и переиспользовать фичи для их сущностей, не создавая все заново.
Избегая схожих функций с разными определениями, сохраняя функции и их параметры.
Выдавать актуальные фичи.
Избежать перекосов в данных, используя feature store как источник данных для экспериментов, continuous training and model serving. Этот подход даст уверенность в том, что мы используем одни и те же фичи в ходе:
- Для экспериментов DS может получать себе данные.
- Этап Continuous training и automated ML training pipeline может получать обновленные данные.
- Для онлайн прогнозирования.

Metadata management

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

Версия выполняемого пайплайна и компонент.
Start, end time и сколько длилось выполнение каждого этапа пайплайна.
Pipeline Executor.
Пареметры, которые передаются пайплайну.
Указатели на артефакты, создаваемые каждым шагом пайплайна - расположение данных, результаты валидации, статистики. Отслеживание этих промежуточных output'ов помогает возобновить пайплайн с последнего шага, без повторного выполнения предыдущ.
Метри оценки модели для обучаещего и тестового наборов данных. Помогут сравнить старую и новые версии модели по записям.

ML Pipeline Triggers

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

По требованию: ручное выполнение пайплайна.
По расписанию: Размеченные данные кажд неделю попадают в feature store. Частота переобучения также может зависеть от того, как часто меняются паттерны в данных и сколько стоит переобучение.
По доступности новых данных: Появились данные → дообучаем.
При деградации модели: Настроено наблюдение за моделью.
При значительных изменениях в распределении данных: Какие-то статистические изменения в распределениях итд.

Challenge

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

Однако, вам также необходимо пробовать новые идеи и уметь быстро разворачивать эти ML компоненты. Если управляете несколькими ML пайплайнами в проде, то необходима настройка CI/CD для автоматизации build, test and deployment ML пайплайнов.

MLOps Principles