Из статей узнаете о следующем:
- О среде разработки моделей машинного обучения;
- Об управлении данными для ML и концепции FeatureStore;
- Связи MLOps с DevOps и о внедрении ML Моделей;
- Мониторинге ML моделей;
- Калибровке, переобучении, дообучении и пр;
- Основах управления Жизненным Циклом Моделей.
Бизнес собирает петабайты данных для использования в Data Science проектах, но это не гарантирует прибыль. Единого понимания, как работать с ML-приложениями, еще нет, хотя у многих компаний есть обнадеживающие пилоты и удачные эксперименты, превратить их в стабильную ценность для бизнеса не всегда получается и многие компании не могут превратить обнадеживающие пилоты и удачные эксперименты в стабильную ценность для бизнеса. Причина — не изъяны технологий ML, и даже не слабая квалификация специалистов, а отсутствие проторенной дороги от среды экспериментов в промышленную эксплуатацию (как вариант — “от теста в продакшн”). Концепция MLOps такую дорогу прокладывает операционализацией работы с моделями, систематизацией внедрения и автоматизацией всего что только можно в жизненном цикле моделей.
На какие вопросы отвечает 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`а и доставки его до всех контуров. В свою очередь, выстроенный бизнес-процесс и единый портал сокращают время на коммуникацию и менеджмент проектов.
Что делать после внедрения модели? Понятно, что ЖЦМ не заканчивается на внедрении. На промышленной среде придется присматривать за качеством поступающих данных, за степенью деградации самой модели и за инфраструктурой, на которой работает модель. При падении качества, модель необходимо откалибровать или обучить заново на новых данных. А при наличии проблем с серверной частью, мы хотим своевременно обнаружить их и проинформировать ответственных лиц. Для этого стоит выстроить дашборд мониторинга (а лучше — полноценную систему), который бы включал в себя все метрики, влияющие на работоспособность модели и на бизнес в целом.
Мы выделяем 5 основных столпов, на которых стоит MLOps
- Контур анализа данных и моделирования — системы и технологии, связанные с разработкой моделей машинного обучения и датасетов для обучения/применения/эксплуатации. Управление вычислительными ресурсами, разграничение доступа и поддержка большого количества современных фреймворков для разработки моделей;
- Среда применения моделей — сама среда, в которой запускается код моделей, пайплайны обработки данных связанные с ML и процессы принятия решений на основе моделей машинного обучения;
- Управление переменными (Feature Store) — технология, упрощающая взаимодействие между Data Scientist и Data Engineer. Первый больше не собирает данные самостоятельно, а “заказывает” датасеты; второй же приобретает инструмент автоматической сборки этих заказов, вместо постоянных выгрузок ad-hoc;
- Система управления ЖЦМ и модельным риском — единая платформа для работы всех ролей, связанных с разработкой моделей;
- Технологии эксплуатации моделей — система мониторинга всего и вся, пульсометр, что проверяет “здоровье” модели и сигнализирует об угрозах ее “жизни”. А также система повторного обучения, дообучения и калибровки, которая может реанимировать умирающую модель.
- Платформа AB тестирования;
- AutoML;
- Система автоматизации процесса разработки;
- Система отслеживания модельных экспериментов;
- Платформа валидации и аудита моделей;
Пока вы ждете продолжения, приходите общаться в наше NoML Community и заглядывайте на эфиры в CH https://www.joinclubhouse.com/club/noml.