Это материал из цикла статей о MLOps и ModelOps от команды GlowByte Advanced Analytics.
В предыдущей статье 5 столпов MLOps мы рассказали о 5 ключевых аспектах, на которые стоит обратить внимание при построении ML платформ и выстраивании процессов ModelOps. Сегодня мы остановимся на одном из перечисленных аспектов, а именно расскажем о том, что такое жизненный цикл ML-моделей и почему важно уметь эффективно управлять им.
ЖЦМ или жизненный цикл модели — это совокупность всех этапов существования ML-модели: с момента осознания ее необходимости до вывода из эксплуатации.
Например, можно выделить следующие верхнеуровневые стадии ЖЦМ:
- Постановка задачи DS/ML: сведение и формализация решаемой бизнес-задачи к задаче построения модели машинного обучения или применения методов продвинутой аналитики;
- Подготовка данных: проектирование переменных и разработка витрины данных для обучения моделей ML и применения методов Data Science;
- Обучение модели: подбор архитектуры и параметров модели решающей поставленную задачу;
- Внедрение модели: постановка модели в промышленную эксплуатацию (как говорится, в PROD);
- Эксплуатация и мониторинг: применение модели для принятия решений в рассматриваемой бизнес-задачи и контроль качества этих решений;
- Изменение или вывод: пересмотр модели в связи с изменением условий ее применения или вывод её из эксплуатации.
NB: Важно сразу заметить, что в разных компаниях и подразделениях Data Science и ML могут значительно отличаться как сам набор этих этапов, так и детали их реализации.
Сам термин ЖЦМ и область управления моделями (Model Management и даже Model Governance) существуют достаточно давно, но сейчас в связи с активной адаптацией технологий ML и AI в самых разных областях и в связи с бурным развитием направлений MLOps и ModelOps вопросы управления ЖЦМ становятся актуальными как никогда ранее. Более того понимание технологических решений этих вопросов выходит на новый уровень.
Можно выделить три основных случая развития технологий для управления ЖЦМ в отдельно взятых ML/DS подразделениях и командах:
- Полное отсутствие инфраструктуры для управления ЖЦМ;
- Задача управления ЖЦМ решена частично, то есть присутствуют отдельные подсистемы управляющие процессами моделирования на отдельных этапах ЖЦМ;
- Есть единая система управления ЖЦМ в виде решения класса Model Governance.
Случай 1. Полное отсутствие инфраструктуры для ЖЦМ
Зачастую в компаниях, где применяются ML решения, особенно там, где ML-команды только появились, нет инфраструктуры для ЖЦМ. Это становится проблемой с ростом количества моделей, сотрудников, запросов на построение моделей. Так как модель разрабатывает относительно новая ML-команда, модели обучаются вручную по прямому запросу, а каждое внедрение в PROD — отдельный сложный процесс. При этом отсутствует стандартизированный подход, а следовательно, увеличивается время разработки. Возникает ряд проблем — невоспроизводимость результатов из-за того, что не ведется документирование и несогласованность работы функциональных ролей.
Неупорядоченность, неформализованность и непрозрачность ЖЦМ ведут к отсутствию четкой структурированной работы с моделями и потере времени и денег.
Случай 2. Присутствуют отдельные ML-решения
В более продвинутых случаях некая инфраструктура все же есть, то есть какие-то ModelOps-решения практикуются, например, ведется библиотека всех моделей, настроены CI/CD-процессы вывода в PROD, рабочие панели мониторинга качества моделей обновляются на регулярной основе.
При этом подходе все еще есть вероятность упустить какие-либо события, происходящие с моделью. Отдельно взятые ML/MLOps-сервисы плохо синхронизированы и согласованы между собой. Процесс перевода модели из одного сервиса в другой долгий, сложный и ведется вручную.
Например, специалисты Data Science обучают модель и сохраняют артефакты в mlflow так, как им удобно, а разработчики бэкэнда осуществляют перенос модели в PROD в каком-то своем формате, к примеру, не поддерживающем работу композитной модели, то есть использующей результаты других подмоделей как признаки при обучении. В итоге им нужно каждый раз договариваться заново, а ведь каждая команда продолжает развитие в рамках своих технологий, и там постоянно что-то меняется.
Случай 3. Система управления ЖЦМ класса Model Governance
Все проблемы мы решаем созданием единой системы управления жизненным циклом моделей ML и продвинутой аналитики. В общем виде решение для ЖЦМ класса Model Governance характеризует следующее
Model Registry или библиотека моделей
Реестр моделей необходим для учета каждого разработанного алгоритма. Из реестра мы узнаем о хронологии появления моделей, версию модели, этап, на котором она сейчас находится. В реестре хранятся ссылки на всю связанную информацию и артефакты, такие как документация, датасеты, другие модели, и в целом все метаданные, например, модели могут иметь теги для фильтрации, поиска, объединения похожих алгоритмов в одну категорию.
Управление бизнес-процессами ЖЦМ
Верхнеуровневые этапы пайплайна можно разделить на детальные бизнес-процессы, которыми можно управлять из системы в BPMN-подобной нотации. Например, бизнес-процесс разработки модели описывает что и в каком порядке должны сделать участники команды разработки модели, автоматизирует процесс передачи релевантных данных внутри команды, позволяет зафиксировать по шагам все принятые решения, а бизнес-процесс эксплуатации модели описывает что делать, если качество модели сильно просело. Существует множество инструментов проектирования бизнес-процессов, например, одним из самых распространенных на сегодня является движок Camunda.
Прозрачная ролевая система
Чтобы сделать ЖЦМ более прозрачным, нужна четкая ролевая система, с помощью которой команда будет знать, кто за что отвечает. При таком подходе тимлид может назначать ответственных за ту или иную задачу, отслеживать статус выполнения задач и обращаться к нужному сотруднику за отчетом. Каждый член команды будет знать о своих задачах, которые могут быть собраны в одном месте.
Например, при переходе на этап подготовки данных для модели эта задача назначается человеку из команды с ролью Data Engineer. Сотрудник в свою очередь получает уведомление о новом назначении, он увидит новую задачу в тасклисте, там же у него будет возможность заполнить необходимые артефакты и перевести задачу в статус in progress/done.
А в больших командах и организациях становится важным вопрос разграничения прав доступа. Не каждый участник команды должен видеть информацию чувствительную для бизнеса и не каждый участник команды должен иметь право на внесение изменений в определенные артефакты и атрибуты модели.
Хранилище артефактов моделей
В процессе разработки моделей появляется большое количество артефактов. ЖЦМ решает задачу организации единого места хранения разнородных артефактов — от бизнес-решений (согласования документации, прохождение code review, принятия решений о внедрении и т.д.) и заканчивая техническими артефактами (pickle-файл модели, sql-скрипт сборки витрины), которые обычно хранятся в специализированных системах (Jira, git, DVC, простые файловые хранилища, локальные папки разработчиков).
Единый интерфейс для артефактов позволяет получить информацию о модели для любой роли-участника разработки в одном окне.
Интеграция со сторонними сервисами
Отличным решением для системы управления ЖЦМ станет разработка синхронизационного модуля, который будет отвечать за интеграцию с Jira, Wiki, Git, почтой, календарем и другими сервисами. Например, автоматическое создание и заполнение страницы на Wiki метаинформацией о модели или автозаведение задач в Jira и дедлайнов в календаре. При этом синхронизация может работать и в обратную сторону, то есть обновления в специализированных системах также могут интегрироваться с мастер-системой ЖЦМ.
Интеграция с MLOps-решениями
Это сделает процесс работы с ЖЦМ проще и удобнее. Например, запуск процессов CI/CD по кнопке, отображение экспериментов из mlflow, отображение дашбордов мониторинга.
Мониторинг качества бизнес-метрик
Важно отслеживать не только статистическое качество самой модели, но и бизнес-метрики применения конкретной модели в конкретных бизнес-задачах. Дашборды разработанного сервиса показывают успешность применения каждой модели на основных бизнес-показателях.
С помощью такой системы легко отслеживать каждый этап работы над моделью, понимать, на какой стадии она находится и кто в настоящий момент за нее отвечает. Помимо этого, появляется возможность считать время от постановки задачи до вывода в PROD, находить самые длительные места и оптимизировать их.
Также описанная система ЖЦМ позволяет существенно упростить работу и передачу информации внутри команд, например, новым сотрудникам легко погружаться в проект, имея доступ ко всем артефактам модели, а про работающую в PROD модель никогда не возникнет вопросов кто и зачем ее сделал.
Система станет не только единой точкой входа во все ML/MLOps-сервисы, но и удобным инструментом для всех ролей от разработчиков до менеджеров.
Процесс создания такой системы не так прост, как может показаться на первый взгляд, и сопряжен с многочисленными сложностями. Например, не всегда ясно, что считать единицей Model Registry: модель ML, или модель и связанные данные, или весь проект решения бизнес-задачи, который может содержать несколько моделей разных классов. Немаловажный и внушительный пласт работы заключается в выстраивании процессов взаимодействия между участниками процессов ЖЦМ, как внутри команды анализа данных так и между командами, например ИТ и бизнес-заказчиком.
Описанная система класса Model Governance позволяет объединить и синхронизировать множество сервисов и построить единую экосистему для решения бизнес-задач с помощью ML/DS. И, конечно же, эту систему нужно постоянно развивать, чтобы не отставать от развития технологий.
Подводим итог
Итак, суммируя все, можно выделить плюсы и минусы подхода управления ЖЦМ.
Из плюсов: благодаря наличию такой системы мы получаем единую точку входа для всех вопросов связанных с ML/DS и аналитикой:
- Интеграция всех ML/MLOps-сервисов в единую структуру;
- Версионирование всего что связано с аналитическими моделями ML/DS;
- Сквозной контроль над всеми этапами ЖЦМ.
Из минусов: создание такой системы потребует существенных усилий:
- Организационных (согласовать работу всех команд, участвующих в ML-процессах);
- Архитектурных (создать достаточно гибкую верхнеуровневую систему, в которую будет легко добавлять новые ML-сервисы в будущем);
- Технических (интегрировать множество разных сервисов в единую систему).
Сейчас почти в каждой крупной компании уже ведется ML-разработка, модели широко применяются практически для всего и показывают эффективность. Как мы увидели, процесс контроля за старыми и разработки новых моделей можно сделать еще эффективнее с помощью управления ЖЦМ. Облегчение взаимодействия между командами, учет и мониторинг всех разработок ведет к грамотному распределению ресурсов, сокращению убытков, а следовательно и росту прибыли.
Про ModelOps/MLOps и другие вопросы вокруг применения ML и продвинутой аналитики в реальных бизнес-задачах мы регулярно общаемся в нашем сообществе NoML:
- Канал новостей (https://t.me/noml_digest)
- Чат (https://t.me/noml_community)
Подключайтесь!