{"id":13742,"url":"\/distributions\/13742\/click?bit=1&hash=ad37dcbaca11fe3e193e41b0a2c0db52ecf3ed929b6ae631cb8443dedbdf01e6","title":"\u0412 \u00ab\u0422\u0438\u043d\u044c\u043a\u043e\u0444\u0444 \u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0446\u0438\u044f\u0445\u00bb \u0442\u0435\u043f\u0435\u0440\u044c \u043c\u043e\u0436\u043d\u043e \u043a\u0443\u043f\u0438\u0442\u044c \u043f\u0440\u0435\u043c\u0438\u0430\u043b\u044c\u043d\u044b\u0435 \u043e\u043f\u0446\u0438\u043e\u043d\u044b","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}

Как и зачем управлять ML-моделями?

Это материал из цикла статей о MLOps и ModelOps от команды GlowByte Advanced Analytics.

В предыдущей статье 5 столпов MLOps мы рассказали о 5 ключевых аспектах, на которые стоит обратить внимание при построении ML платформ и выстраивании процессов ModelOps. Сегодня мы остановимся на одном из перечисленных аспектов, а именно расскажем о том, что такое жизненный цикл ML-моделей и почему важно уметь эффективно управлять им.

ЖЦМ или жизненный цикл модели — это совокупность всех этапов существования ML-модели: с момента осознания ее необходимости до вывода из эксплуатации.

Например, можно выделить следующие верхнеуровневые стадии ЖЦМ:

  1. Постановка задачи DS/ML: сведение и формализация решаемой бизнес-задачи к задаче построения модели машинного обучения или применения методов продвинутой аналитики;
  2. Подготовка данных: проектирование переменных и разработка витрины данных для обучения моделей ML и применения методов Data Science;
  3. Обучение модели: подбор архитектуры и параметров модели решающей поставленную задачу;
  4. Внедрение модели: постановка модели в промышленную эксплуатацию (как говорится, в PROD);
  5. Эксплуатация и мониторинг: применение модели для принятия решений в рассматриваемой бизнес-задачи и контроль качества этих решений;
  6. Изменение или вывод: пересмотр модели в связи с изменением условий ее применения или вывод её из эксплуатации.

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:

Подключайтесь!

0
Комментарии
Читать все 0 комментариев
null