Меня зовут Артем Глазков, я работаю консультантом в российском подразделении компании SAS. Сегодня я хочу рассказать про операционализацию аналитики на практическом примере проекта, который я сделал совместно с моим коллегой Иваном Нардини для крупной итальянской сырьевой компании. Я постараюсь сфокусироваться на наиболее важных деталях и преимуществах подхода ModelOps.
Согласно независимым исследованиям, операционализация аналитики является ключевым трендом развития в области Искусственного Интеллекта. Необходимо научиться не только строить точные модели машинного обучения, но и организовать эффективное управление их жизненным циклом. Без этого модель рискует навсегда застрять внутри стен ‘лаборатории данных’. Практика показывает, что именно там остаются более половины разработанных моделей. Это означает, что время и усилия, затраченные на создание таких моделей, так и не были компенсированы полезным эффектом от их применения.
После внедрения задача инструментов управления жизненным циклом моделей заключается в том, чтобы постоянно поддерживать модель в форме. Мир вокруг модели меняется — в отсутствие настроенного процесса контроля качества работы модели рано или поздно точность ее работы упадет ниже приемлемого значения. Инструменты мониторинга моделей позволяют своевременно выявить потребность в дообучении. Обновленная модель сможет увидеть новые закономерности в данных и правильно их учесть. В результате, удастся обеспечить стабильно высокое качество работы модели на этапе эксплуатации, а значит получить больше практической пользы от каждой разработки.
Архитектурная схема сценария ModelOps
Операционализация моделей охватывает три среды: разработку, управление и применение моделей. В сценарии, о котором пойдет речь сегодня, были представлены:
Платформа управления моделями должна быть доступной для максимально широкого профиля экспертизы пользователей, чтобы каждый имел возможность использовать удобный инструментарий (библиотеку, метод, язык разработки), а среда исполнения должна отвечать всем необходимым техническим требованиям. Еще одно частое требование к фреймворку по управлению моделями заключается в том, чтобы система умела работать с компонентами ML, развернутыми как в режиме on-premises, так и на стороне облачных провайдеров.
Этапы жизненного цикла модели машинного обучения
Рассмотрим этапы жизненного цикла модели в нашем сценарии:
На рынке представлено достаточно большое количество инструментов для операционализации аналитических моделей. Концептуально они могут быть разделены на две категории: первая — использование ПО Open Source, вторая – это коробочные решения enterprise-ready. Как правило в Enterpise решения входит набор интеграций, покрытие более широкого скоупа единым фреймворком, наличие встроенной поддержки.
В нашем случае мы остановились на втором варианте, и построили процесс ModelOps для всех этапов жизненного цикла модели с помощью аналитической платформы SAS Viya. Платформа состоит из большого количества модулей, но для нашей задачи важнее всего были два ее компонента:
Решения класса Business Process Model and Notation, имеют стандартизованное графическое представление, в котором процессы декомпозированы на отдельные функциональные блоки и объединены между собой по определённой логике.
Процесс операционализации модели в формате BPMN
SAS Workflow Manager поддерживает стандарт BPMN и подходит для графов как ацикличной (DAG) так и цикличной направленности. Поддержка обоих видов графов важна для операционализации аналитики, поскольку зачастую процессы имеют циклическую природу. В SAS Workflow Manager был воспроизведен процесс управления жизненным циклом моделей о который мы рассматривали на схеме выше.
Самыми полезными объектами BPMN для этого сценария оказались:
Процесс работы с SAS Model Manager начинается после того, как модель была разработана и зарегистрирована в репозитории. Первый раздел рабочего процесса в Workflow Manager – это этап внедрения, в результате которого модель становиться доступной для эксплуатации на стороне кластера OpenShift Kubernetes.
Графический интерфейс инструмента управления рабочими процессами в SAS Viya
В первом функциональном блоке процесса происходит инициализация переменных. Рабочий процесс получает все необходимые для работы параметры, такие как уникальный идентификатор проекта, границы значений KPI качества работы модели (в нашем случае — оцениваемый исходя из метрики Колмогорова-Смирнова) и предпочитаемый канал коммуникации (почта/мессенджер).
Далее следует этап в проверки модели со стороны валидатора на соответствие требованиям, основываясь на экспертном мнении сотрудника этой роли и действующим корпоративным стандартам. В случае успешного прохождения валидации в рамках этого функционального блока модели присвоится уникальный тэг который потребуется на этапе эксплуатации.
Чтобы осуществить перевод модели в режим эксплуатации процесс последовательно выполняет три сервисных таска:
Задача таска Prebuild – выгрузить скоринговый код модели, вмести со всеми необходимыми метаданными (включая конфигурацию окружения в YAML файле) с помощью программного интерфейса к репозиторию.
Задача таска Build – создать Docker образ используя артефакты моделей, полученные на прошлом этапе, и базовый контейнер для скоринга моделей Tensorflow. Технически на этом этапе происходит следующее:
Задача таска Deploy — выполнить Push контейнера с моделью на сторону кластера OpenShift. Технически шаги, которые выполняет система, включают в себя:
На всех важных этапах система отправляет уведомления ответственным сотрудникам корпоративном мессенджере MS Teams
В результате этих действий модель из репозитория SAS Model Manager внедряется на сторону OpenShift Kubernetes и становиться доступной для эксплуатации. Можем начинать скоринг.
Процесс эксплуатации моделей в OKD с логированием ответов на входящие запросы
После этапа внедрения рабочий процесс переходит к стадии эксплуатации. Эта часть процесса не менее важная. Именно на этапе эксплуатации мы получаем полезный экономический эффект от предиктивных моделей.
Детальное представление этапа эксплуатации модели
На этапе эксплуатации, каждый запрос, который отрабатывает модель, фиксируется в базе данных. Эта информация в дальнейшем пригодится для задач мониторинга, аудита и дообучения алгоритма.
В соответствии с установленным таймером производиться расчет метрик качества работы моделей. В случае, если качество модели снижется ниже приемлемых значений, будет произведена процедура дообучения модели на новых данных. В результате новая версия алгоритма будет зарегистрирована в репозитории моделей.
Новая модель будет отправлена на валидацию – процесс возвращается на этап ‘approve champion model’. В случае успешной проверки происходит внедрение, эксплуатация, мониторинг и так далее. Таким образом, цикл операционализации будет продолжается до тех пор, пока бизнес-задача, которую решает модель будет оставаться актуальной.
В этой статье был рассмотрен пример построения процесса операционализации моделей машинного обучения. Детали, шаги, роли процесса могут варьироваться, но стоит выделить пять ключевых функциональных требований к системам ModelOps:
По данным опроса крупных организаций поддержка этих функциональных возможностей имеет прямое влияние на экономический эффект от проектов, связанных с машинным обучением: компании, которые выстраивают правильный процесс операционализации получают более высокую отдачу от каждой разработанной модели. ModelOps позволяет перейти от ‘отвёрточной сборки’ моделей к ‘конвейерному подходу’, а значит масштабировать применение машинного обучения и аналитики для решения новых бизнес-задач.
Ссылки:
habr.com
Согласно независимым исследованиям, операционализация аналитики является ключевым трендом развития в области Искусственного Интеллекта. Необходимо научиться не только строить точные модели машинного обучения, но и организовать эффективное управление их жизненным циклом. Без этого модель рискует навсегда застрять внутри стен ‘лаборатории данных’. Практика показывает, что именно там остаются более половины разработанных моделей. Это означает, что время и усилия, затраченные на создание таких моделей, так и не были компенсированы полезным эффектом от их применения.
После внедрения задача инструментов управления жизненным циклом моделей заключается в том, чтобы постоянно поддерживать модель в форме. Мир вокруг модели меняется — в отсутствие настроенного процесса контроля качества работы модели рано или поздно точность ее работы упадет ниже приемлемого значения. Инструменты мониторинга моделей позволяют своевременно выявить потребность в дообучении. Обновленная модель сможет увидеть новые закономерности в данных и правильно их учесть. В результате, удастся обеспечить стабильно высокое качество работы модели на этапе эксплуатации, а значит получить больше практической пользы от каждой разработки.
Строим мост между средами создания и применения моделей
Архитектурная схема сценария ModelOps
Операционализация моделей охватывает три среды: разработку, управление и применение моделей. В сценарии, о котором пойдет речь сегодня, были представлены:
- Средой разработки моделей, где производится обучение модели с помощью библиотеки Tensorflow.
- Средой управления моделями, в которой мы использовали компоненты аналитической платформы SAS Viya: SAS Model Manager и Workflow Manager.
- Средой эксплуатации, в которой осуществляется применение (скоринг) модели. В данном случае был использован RedHat OpenShift (OKD), размещенный на облачном кластере AWS.
Платформа управления моделями должна быть доступной для максимально широкого профиля экспертизы пользователей, чтобы каждый имел возможность использовать удобный инструментарий (библиотеку, метод, язык разработки), а среда исполнения должна отвечать всем необходимым техническим требованиям. Еще одно частое требование к фреймворку по управлению моделями заключается в том, чтобы система умела работать с компонентами ML, развернутыми как в режиме on-premises, так и на стороне облачных провайдеров.
Делай раз, делай два, делай три: из чего состоит жизненный цикл модели
Этапы жизненного цикла модели машинного обучения
Рассмотрим этапы жизненного цикла модели в нашем сценарии:
- Разработчик модели строит модель машинного обучения. В нашем случае модель обучалась на табличных данных, ее задача относится к бинарной классификации. Модель должна отличать условно ‘плохих’ клиентов от ‘хороших’ и помогать компании принимать правильные решения. Для разработки используется библиотека машинного обучения по выбору пользователя – в данном случае Tensorflow. Отслеживание экспериментов в ходе разработки осуществляется с помощью open source инструмента MLFlow Tracking.
- Когда разработчик модели завершил этап экспериментов и определился с моделью-чемпионом, она регистрируется в репозитории SAS Model Manager с помощью библиотеки sasctl. Далее модель-чемпион проходит этап валидации. В случае успешного прохождения модель внедряется в среду Red Hat OpenShift (OKD). В результате разработанная модель в форме Google Tensorflow Serving Image начинает работать в рамках проекта OKD, созданном DevOps инженером.
- Devops инженер производит интеграцию контейнера с приложением, в которое приходят запросы на скоринг из внешней системы. Лог файлы и результаты скоринга модели записываются в базе данных.
- Результаты скоринга используются для запуска процедур оценки качества работы модели. Эта проверка производится на стороне SAS Model Manager. Результаты оценки ‘состояния здоровья’ модели и динамики профиля используемых данных система автоматически рассылает всем ответственным сотрудникам.
- В случае, если качество модели падает ниже приемлемого уровня, с помощью SAS Workflow Manager происходит запуск процедуры дообучения модели на новых данных. Статусы отработки процедур фиксируются в корпоративном мессенджере, в нашем примере это был Microsoft Teams.
- После того, как разработчик модели получит уведомление о готовности новой, дообученной версии алгоритма, модель вновь проходит этапы валидации, внедрения и эксплуатации. Ее жизненный цикл продолжается до тех пор, пока задача модели остается актуальной.
Что использовать для управления жизненным циклом моделей?
На рынке представлено достаточно большое количество инструментов для операционализации аналитических моделей. Концептуально они могут быть разделены на две категории: первая — использование ПО Open Source, вторая – это коробочные решения enterprise-ready. Как правило в Enterpise решения входит набор интеграций, покрытие более широкого скоупа единым фреймворком, наличие встроенной поддержки.
В нашем случае мы остановились на втором варианте, и построили процесс ModelOps для всех этапов жизненного цикла модели с помощью аналитической платформы SAS Viya. Платформа состоит из большого количества модулей, но для нашей задачи важнее всего были два ее компонента:
- SAS Model Manager, который является централизованным репозиторием моделей. В нем производится регистрация, валидация, внедрение в среду применения, мониторинг и версионирование моделей машинного обучения. Наличие открытых, задокументированных REST API позволяет получать доступ к артефактам и метаданным из программного интерфейса.
- SAS Workflow Manager, который выступает как оркестратор процесса. С помощью этого инструмента автоматизируются типовые задачи на всех этапах жизненного цикла. За счет интеграции с пользовательскими действиями обеспечивается синхронизация всех участников команды, задействованных в процессе ModelOps.
Как выглядит жизненный цикл модели в формате BPMN
Решения класса Business Process Model and Notation, имеют стандартизованное графическое представление, в котором процессы декомпозированы на отдельные функциональные блоки и объединены между собой по определённой логике.
Процесс операционализации модели в формате BPMN
SAS Workflow Manager поддерживает стандарт BPMN и подходит для графов как ацикличной (DAG) так и цикличной направленности. Поддержка обоих видов графов важна для операционализации аналитики, поскольку зачастую процессы имеют циклическую природу. В SAS Workflow Manager был воспроизведен процесс управления жизненным циклом моделей о который мы рассматривали на схеме выше.
Самыми полезными объектами BPMN для этого сценария оказались:
- Сервисные таски – функциональные блоки процесса со знаком шестеренки. На этих этапах происходит интеграция со сторонними сервисами, отработка скриптов, REST API, отправка уведомлений участникам процесса.
- User task – функциональные блоки с символом человека. В этих функциональных блоках происходит взаимодействие между пользователем и рабочим процессом. Взаимодействие происходит в графическом интерфейсе решения с помощью опросных форм, с учетом ролевой модели. Например, опросник по соответствию критериям валидации для пользователей группы ‘валидаторов’.
- Разветвление – функциональный блок со знаком X. В зависимости от значений переменных рабочего процесса (data objects) на выходе из этого блока процесс пойдет в определенном направлении исходящей из него ветви. Переменные рабочего процесса могут быть заданы вручную в опросниках User task или является результатом расчета в Service tasks.
- Подпроцессы – функциональные блоки бежевого цвета. С помощью этих блоков поддерживается вложенная структура процессов, что повышает управляемость и наглядность процесса.
Через тернии в прод: этап внедрения модели
Процесс работы с SAS Model Manager начинается после того, как модель была разработана и зарегистрирована в репозитории. Первый раздел рабочего процесса в Workflow Manager – это этап внедрения, в результате которого модель становиться доступной для эксплуатации на стороне кластера OpenShift Kubernetes.
Графический интерфейс инструмента управления рабочими процессами в SAS Viya
В первом функциональном блоке процесса происходит инициализация переменных. Рабочий процесс получает все необходимые для работы параметры, такие как уникальный идентификатор проекта, границы значений KPI качества работы модели (в нашем случае — оцениваемый исходя из метрики Колмогорова-Смирнова) и предпочитаемый канал коммуникации (почта/мессенджер).
Далее следует этап в проверки модели со стороны валидатора на соответствие требованиям, основываясь на экспертном мнении сотрудника этой роли и действующим корпоративным стандартам. В случае успешного прохождения валидации в рамках этого функционального блока модели присвоится уникальный тэг который потребуется на этапе эксплуатации.
Чтобы осуществить перевод модели в режим эксплуатации процесс последовательно выполняет три сервисных таска:
- Prebuild
- Build
- Deploy
Задача таска Prebuild – выгрузить скоринговый код модели, вмести со всеми необходимыми метаданными (включая конфигурацию окружения в YAML файле) с помощью программного интерфейса к репозиторию.
Задача таска Build – создать Docker образ используя артефакты моделей, полученные на прошлом этапе, и базовый контейнер для скоринга моделей Tensorflow. Технически на этом этапе происходит следующее:
- Создание окружения
- Загрузка Docker образа Tensorflow
- Запуск контейнера Tensorflow
- Копирование модели внутрь контейнера Tensorflow
- Commit готового для скоринга контейнера Tensorflow в локальный Docker репозиторий
Задача таска Deploy — выполнить Push контейнера с моделью на сторону кластера OpenShift. Технически шаги, которые выполняет система, включают в себя:
- Авторизацию в OpenShift Registry с помощью необходимых реквизитов
- Присвоение нужного значения тэга образу
- Выполнение Push для образа внутри OpenShift окружения
На всех важных этапах система отправляет уведомления ответственным сотрудникам корпоративном мессенджере MS Teams
В результате этих действий модель из репозитория SAS Model Manager внедряется на сторону OpenShift Kubernetes и становиться доступной для эксплуатации. Можем начинать скоринг.
Процесс эксплуатации моделей в OKD с логированием ответов на входящие запросы
Держим руку на пульсе: этап эксплуатации модели
После этапа внедрения рабочий процесс переходит к стадии эксплуатации. Эта часть процесса не менее важная. Именно на этапе эксплуатации мы получаем полезный экономический эффект от предиктивных моделей.
Детальное представление этапа эксплуатации модели
На этапе эксплуатации, каждый запрос, который отрабатывает модель, фиксируется в базе данных. Эта информация в дальнейшем пригодится для задач мониторинга, аудита и дообучения алгоритма.
В соответствии с установленным таймером производиться расчет метрик качества работы моделей. В случае, если качество модели снижется ниже приемлемых значений, будет произведена процедура дообучения модели на новых данных. В результате новая версия алгоритма будет зарегистрирована в репозитории моделей.
Новая модель будет отправлена на валидацию – процесс возвращается на этап ‘approve champion model’. В случае успешной проверки происходит внедрение, эксплуатация, мониторинг и так далее. Таким образом, цикл операционализации будет продолжается до тех пор, пока бизнес-задача, которую решает модель будет оставаться актуальной.
Заключение
В этой статье был рассмотрен пример построения процесса операционализации моделей машинного обучения. Детали, шаги, роли процесса могут варьироваться, но стоит выделить пять ключевых функциональных требований к системам ModelOps:
- Наличие репозитория моделей, для хранения, сравнения и версионирования моделей, обеспечения всеми необходимыми метаданными
- Наличие интеграции со средами применения моделей для сокращения Time-to-Market внедрения моделей в эксплуатацию
- Наличие возможностей валидации моделей для снижения модельного риска
- Наличие выстроенной методики мониторинга качества моделей на этапе эксплуатации, для обеспечения стабильно высокого качества работы
- Наличие инструмента оркестрации рабочих процессов, включая запуск пайплайнов внедрения и получения согласований от различных ролей пользователей системы
По данным опроса крупных организаций поддержка этих функциональных возможностей имеет прямое влияние на экономический эффект от проектов, связанных с машинным обучением: компании, которые выстраивают правильный процесс операционализации получают более высокую отдачу от каждой разработанной модели. ModelOps позволяет перейти от ‘отвёрточной сборки’ моделей к ‘конвейерному подходу’, а значит масштабировать применение машинного обучения и аналитики для решения новых бизнес-задач.
Ссылки:
- Репозиторий с кодом для сценария ModelOps
- Сервис мгновенной оценки зрелости процессов ModelOps
- Информация о системе SAS MRM для оценки модельного риска
ModelOps на практике: переходим от отверточной сборки к конвейеру по управлению моделями
Привет хабр! Меня зовут Артем Глазков, я работаю консультантом в российском подразделении компании SAS. Сегодня я хочу рассказать про операционализацию аналитики на практическом примере проекта,...
habr.com