В предыдущей статье 5 столпов MLOps мы рассказали о 5 ключевых аспектах, на которые стоит обратить внимание при построении ML платформ и выстраивании процессов ModelOps. Сегодня мы остановимся на одном из перечисленных аспектов, а именно расскажем о том, что такое жизненный цикл ML-моделей и почему важно уметь эффективно управлять им.
Например, можно выделить следующие верхнеуровневые стадии ЖЦМ:
NB: Важно сразу заметить, что в разных компаниях и подразделениях Data Science и ML могут значительно отличаться как сам набор этих этапов, так и детали их реализации.
Сам термин ЖЦМ и область управления моделями (Model Management и даже Model Governance) существуют достаточно давно, но сейчас в связи с активной адаптацией технологий ML и AI в самых разных областях и в связи с бурным развитием направлений MLOps и ModelOps вопросы управления ЖЦМ становятся актуальными как никогда ранее. Более того понимание технологических решений этих вопросов выходит на новый уровень.
Можно выделить три основных случая развития технологий для управления ЖЦМ в отдельно взятых ML/DS подразделениях и командах:
Зачастую в компаниях, где применяются ML решения, особенно там, где ML-команды только появились, нет инфраструктуры для ЖЦМ. Это становится проблемой с ростом количества моделей, сотрудников, запросов на построение моделей. Так как модель разрабатывает относительно новая ML-команда, модели обучаются вручную по прямому запросу, а каждое внедрение в PROD — отдельный сложный процесс. При этом отсутствует стандартизированный подход, а следовательно, увеличивается время разработки. Возникает ряд проблем — невоспроизводимость результатов из-за того, что не ведется документирование и несогласованность работы функциональных ролей.
Случай 2. Присутствуют отдельные ML-решения
В более продвинутых случаях некая инфраструктура все же есть, то есть какие-то ModelOps-решения практикуются, например, ведется библиотека всех моделей, настроены CI/CD-процессы вывода в PROD, рабочие панели мониторинга качества моделей обновляются на регулярной основе
Например, специалисты 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 Governance позволяет объединить и синхронизировать множество сервисов и построить единую экосистему для решения бизнес-задач с помощью ML/DS. И, конечно же, эту систему нужно постоянно развивать, чтобы не отставать от развития технологий.
Подводим итог
Итак, суммируя все, можно выделить плюсы и минусы подхода управления ЖЦМ.
Из плюсов: благодаря наличию такой системы мы получаем единую точку входа для всех вопросов связанных с ML/DS и аналитикой:
создание такой системы потребует существенных усилий:
Сейчас почти в каждой крупной компании уже ведется ML-разработка, модели широко применяются практически для всего и показывают эффективность. Как мы увидели, процесс контроля за старыми и разработки новых моделей можно сделать еще эффективнее с помощью управления ЖЦМ. Облегчение взаимодействия между командами, учет и мониторинг всех разработок ведет к грамотному распределению ресурсов, сокращению убытков, а следовательно и росту прибыли.