Команда Advanced Analytics GlowByte запускает цикл статей посвященных MLOps. MLOps — это набор практик и технологий, которые объединяют Machine Learning, DevOps, Data Engineering и Model Governance в единую методологию создания, внедрения и эксплуатации моделей машинного обучения. MLOps помогает бизнесу развивать Data Science и внедрять качественные ML модели на 80% быстрее.
Из статей узнаете о следующем:
Бизнес собирает петабайты данных для использования в Data Science проектах, но это не гарантирует прибыль. Единого понимания, как работать с ML-приложениями, еще нет, хотя у многих компаний есть обнадеживающие пилоты и удачные эксперименты, превратить их в стабильную ценность для бизнеса не всегда получается и многие компании не могут превратить обнадеживающие пилоты и удачные эксперименты в стабильную ценность для бизнеса. Причина — не изъяны технологий ML, и даже не слабая квалификация специалистов, а отсутствие проторенной дороги от среды экспериментов в промышленную эксплуатацию (как вариант — “от теста в продакшн”). Концепция MLOps такую дорогу прокладывает операционализацией работы с моделями, систематизацией внедрения и автоматизацией всего что только можно в жизненном цикле моделей.
Во-первых, каждому разработчику нужна полноценная среда разработки, которая не ограничивает в технологиях и ресурсах. Время разработки на локальных машинах уходит. Компании смотрят в сторону выделенных серверов или кластеров с изолированными средами разработки (например: JupyterHub на k8s) или же на облачные технологии (например: Yandex DataSphere, Amazon SageMaker). Во-вторых, все репозитории моделей важно вести в одинаковой структуре, а модели вызывать единообразно. Это упростит взаимодействие в команде и позволит организовать единый автоматизированный CI/CD-процесс внедрения моделей.
Как выстроить сквозной жизненный цикл моделей (ЖЦМ)? Для начала вспомним, что в ЖЦМ участвует не только непосредственный разработчик модели (Data Scientist), но еще и инженер данных (Data Engineer), IT специалист (IT Engineer), специалист по операционализации (MLOps engineer) и сам бизнес-заказчик. ЖЦМ описывает взаимодействие между ролями участников процесса и внешними системами. Его можно представить в виде бизнес-процесса в BPMN-нотации. Шаг процесса — это конкретная задача конкретного специалиста. Например, для окончания разработки витрины данных для модели, необходимо наличие кода сборки витрины, ссылки на саму витрину и документации о разработке.
Как выстроить коммуникацию и взаимодействие между командами? Выстроив бизнес процессы, мы уже упростили взаимодействие между командами, но нужна система хранения артефактов и метаданных модели, чтобы разработчикам не приходилось искать информацию в почте или мессенджерах. Для этого подойдет единый портал, в котором будут храниться все данные конкретной модели, и этот портал должен наполняться в соответствии с течением бизнес процесса ЖЦМ. Для решения таких задач существует ряд решений (например: BPMN движки, Jira, таск-менеджеры и тд), однако ни одно решение не может закрыть все проблемы на 100%.
Как управлять моделями? Бизнес-заказчик хочет держать руку на пульсе ML-проектов, чтобы понимать статус разработки, управлять человеческими ресурсами и вовремя отменять нерентабельные проекты. Этого позволяет достичь реализация БП на каком-либо движке и объединение БП с системой хранения метаданных. Так мы получим одну точку входа для разработчиков и менеджмента.
Как сократить время доставки моделей в продакшн? Вопрос сложный и затрагивает многие этапы жизненного цикла моделей. MLOps-подход сокращает time-to-market моделей. Он позволяет структурировать процесс разработки и упаковки моделей. Используя DevOps методологию, мы выстраиваем автоматизированный CI/CD пайплайн сборки ML приложения из кода Data Scientist`а и доставки его до всех контуров. В свою очередь, выстроенный бизнес-процесс и единый портал сокращают время на коммуникацию и менеджмент проектов.
Что делать после внедрения модели? Понятно, что ЖЦМ не заканчивается на внедрении. На промышленной среде придется присматривать за качеством поступающих данных, за степенью деградации самой модели и за инфраструктурой, на которой работает модель. При падении качества, модель необходимо откалибровать или обучить заново на новых данных. А при наличии проблем с серверной частью, мы хотим своевременно обнаружить их и проинформировать ответственных лиц. Для этого стоит выстроить дашборд мониторинга (а лучше — полноценную систему), который бы включал в себя все метрики, влияющие на работоспособность модели и на бизнес в целом.
Однако помимо этих столпов есть и другие системы, связанные с MLOps:
Об этом мы подробно расскажем в следующих статьях этого цикла, где остановимся на готовых решениях и технологиях для реализации MLOps-подхода в широком смысле.
Пока вы ждете продолжения, приходите общаться в наше NoML Community и заглядывайте на эфиры в CH https://www.joinclubhouse.com/club/noml.