Modelops что это

ModelOps на практике: переходим от отверточной сборки к конвейеру по управлению моделями

Привет хабр! Меня зовут Артем Глазков, я работаю консультантом в российском подразделении компании SAS. Сегодня я хочу рассказать про операционализацию аналитики на практическом примере проекта, который я сделал совместно с моим коллегой Иваном Нардини для крупной итальянской сырьевой компании. Я постараюсь сфокусироваться на наиболее важных деталях и преимуществах подхода ModelOps.

Согласно независимым исследованиям, операционализация аналитики является ключевым трендом развития в области Искусственного Интеллекта. Необходимо научиться не только строить точные модели машинного обучения, но и организовать эффективное управление их жизненным циклом. Без этого модель рискует навсегда застрять внутри стен ‘лаборатории данных’. Практика показывает, что именно там остаются более половины разработанных моделей. Это означает, что время и усилия, затраченные на создание таких моделей, так и не были компенсированы полезным эффектом от их применения.

После внедрения задача инструментов управления жизненным циклом моделей заключается в том, чтобы постоянно поддерживать модель в форме. Мир вокруг модели меняется — в отсутствие настроенного процесса контроля качества работы модели рано или поздно точность ее работы упадет ниже приемлемого значения. Инструменты мониторинга моделей позволяют своевременно выявить потребность в дообучении. Обновленная модель сможет увидеть новые закономерности в данных и правильно их учесть. В результате, удастся обеспечить стабильно высокое качество работы модели на этапе эксплуатации, а значит получить больше практической пользы от каждой разработки.

Строим мост между средами создания и применения моделей

Архитектурная схема сценария ModelOps

Операционализация моделей охватывает три среды: разработку, управление и применение моделей. В сценарии, о котором пойдет речь сегодня, были представлены:

Средой разработки моделей, где производится обучение модели с помощью библиотеки Tensorflow.
Средой управления моделями, в которой мы использовали компоненты аналитической платформы SAS Viya: SAS Model Manager и Workflow Manager.
Средой эксплуатации, в которой осуществляется применение (скоринг) модели. В данном случае был использован RedHat OpenShift (OKD), размещенный на облачном кластере AWS.

Делай раз, делай два, делай три: из чего состоит жизненный цикл модели

Этапы жизненного цикла модели машинного обучения

Рассмотрим этапы жизненного цикла модели в нашем сценарии:

Разработчик модели строит модель машинного обучения. В нашем случае модель обучалась на табличных данных, ее задача относится к бинарной классификации. Модель должна отличать условно ‘плохих’ клиентов от ‘хороших’ и помогать компании принимать правильные решения. Для разработки используется библиотека машинного обучения по выбору пользователя – в данном случае 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

Задача таска Build – создать Docker образ используя артефакты моделей, полученные на прошлом этапе, и базовый контейнер для скоринга моделей Tensorflow. Технически на этом этапе происходит следующее:

Создание окружения
Загрузка Docker образа Tensorflow
Запуск контейнера Tensorflow
Копирование модели внутрь контейнера Tensorflow
Commit готового для скоринга контейнера Tensorflow в локальный Docker репозиторий

Авторизацию в OpenShift Registry с помощью необходимых реквизитов
Присвоение нужного значения тэга образу
Выполнение Push для образа внутри OpenShift окружения

На всех важных этапах система отправляет уведомления ответственным сотрудникам корпоративном мессенджере MS Teams

В результате этих действий модель из репозитория SAS Model Manager внедряется на сторону OpenShift Kubernetes и становиться доступной для эксплуатации. Можем начинать скоринг.

Процесс эксплуатации моделей в OKD с логированием ответов на входящие запросы

Держим руку на пульсе: этап эксплуатации модели

После этапа внедрения рабочий процесс переходит к стадии эксплуатации. Эта часть процесса не менее важная. Именно на этапе эксплуатации мы получаем полезный экономический эффект от предиктивных моделей.

Детальное представление этапа эксплуатации модели

На этапе эксплуатации, каждый запрос, который отрабатывает модель, фиксируется в базе данных. Эта информация в дальнейшем пригодится для задач мониторинга, аудита и дообучения алгоритма.

В соответствии с установленным таймером производиться расчет метрик качества работы моделей. В случае, если качество модели снижется ниже приемлемых значений, будет произведена процедура дообучения модели на новых данных. В результате новая версия алгоритма будет зарегистрирована в репозитории моделей.

Новая модель будет отправлена на валидацию – процесс возвращается на этап ‘approve champion model’. В случае успешной проверки происходит внедрение, эксплуатация, мониторинг и так далее. Таким образом, цикл операционализации будет продолжается до тех пор, пока бизнес-задача, которую решает модель будет оставаться актуальной.

Заключение

В этой статье был рассмотрен пример построения процесса операционализации моделей машинного обучения. Детали, шаги, роли процесса могут варьироваться, но стоит выделить пять ключевых функциональных требований к системам ModelOps:

Наличие репозитория моделей, для хранения, сравнения и версионирования моделей, обеспечения всеми необходимыми метаданными
Наличие интеграции со средами применения моделей для сокращения Time-to-Market внедрения моделей в эксплуатацию
Наличие возможностей валидации моделей для снижения модельного риска
Наличие выстроенной методики мониторинга качества моделей на этапе эксплуатации, для обеспечения стабильно высокого качества работы
Наличие инструмента оркестрации рабочих процессов, включая запуск пайплайнов внедрения и получения согласований от различных ролей пользователей системы

Репозиторий с кодом для сценария ModelOps
Сервис мгновенной оценки зрелости процессов ModelOps
Информация о системе SAS MRM для оценки модельного риска

Артефакты MLOps: данные, модель, код

Эта инструкция — часть курса «Выстраиваем работу с ML».

Смотреть весь курс

Изображение записи

Если регулярно читать статьи на тему MLOps, начинает формироваться определенное восприятие контекста. Так, авторы текстов в основном пишут про работу с тремя типами артефактов:

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

обучения на качественных датасетах новых версий ML-моделей,
доставки обновленных версий моделей в конечные клиентские сервисы для обработки входящих запросов.

Теперь детализируем эти аспекты.

Данные

Концептуальная схема MLOps

Если внимательно посмотреть на схему, которую мы подробно рассматривали в предыдущем тексте, то можно найти следующие «источники данных»:

Streaming data,
Batch data,
Cloud data,
Labeled data,
Feature online DB,
Feature offline DB.

Весьма спорно называть этот список источниками, но концептуальная задумка, кажется, ясна. Есть данные, которые хранятся в большом количестве систем и по-разному обрабатываются. Все они могут потребоваться для ML-модели.

Что делать, чтобы нужные данные попадали в ML-систему:

использовать инструменты и процессы, которые позволят забирать данные из источников, формировать из них датасеты, расширять их новыми фичами, которые затем сохраняются в соответствующих базах для общего использования.
внедрить инструменты мониторинга и контроля, потому что качество данных может меняться.
добавить каталог, который упростит поиск по данным, если их стало много.

В итоге у компании может появиться полноценная Data Platform с ETL/ELT, шинами данных, объектными хранилищами и прочими Greenplum.

Ключевой аспект использования данных в рамках MLOps: автоматизация подготовки качественных датасетов для обучения ML-моделей.

Платформа обработки данных Selectel

Инфраструктура для хранения и обработки больших данных, сделанная по вашим меркам.

Модель

Теперь поищем на схеме артефакты, имеющие отношение к ML моделям:

ML model,
Prod ready ML model,
Model Registry,
ML Metadata Store,
Model Serving Component,
Model Monitoring Component.

По аналогии с данными нужны инструменты, которые будут помогать:

искать лучшие параметры ML-моделей за счет проведения множества экспериментов,
сохранять лучшие модели и достаточное количество информации о них в специальные реестр (чтобы в дальнейшем можно было воспроизвести результат экспериментов),
организовывать доставку лучших моделей в конечные клиентские сервисы,
осуществлять мониторинг качества их работы, чтобы при необходимости автоматически запускать обучение новых моделей.

Ключевой аспект работы с моделями в рамках MLOps: автоматизация процесса переобучения моделей для достижения лучших качественных метрик их работы с клиентскими запросами.

Код

С кодом проще всего: он как раз автоматизирует процессы работы с данными и моделями.

На нашей схеме можно найти упоминание:

data transformation rules,
feature engineering rules,
data pipeline code,
model training code,
ML workflow code,
model serving code.

Можно только добавить infrastructure as a code (IaaC), с помощью которого поднимается вся необходимая инфраструктура.

Следует отметить, что иногда бывает дополнительный код для оркестрации, особенно если в команде используется несколько оркестраторов. Например, Airflow, который запускает DAG в Dagster.

Инфраструктура для MLOps

На схеме мы видим несколько типов используемой вычислительной инфраструктуры:

data processing computational infrastructure,
model training computational infrastructure,
model serving computational infrastructure.

Причем последнее используется как для проведения экспериментов, так и для переобучения моделей в рамках автоматизированных пайплайнов. Такой подход возможен, если утилизация вычислительной инфраструктуры имеет запас для одновременного выполнения этих процессов.

На первых этапах все задачи можно решать в рамках одной инфраструктуры, но в дальнейшем потребность в новых мощностях будет расти. В частности, из-за специфических требований к конфигурациям вычислительных ресурсов:

для обучения и переобучения моделей не обязательно использовать самые производительные GPU Tesla A100, можно выбрать вариант попроще — Tesla A30, также можно выбрать карты из линейки RTX A-Series (A2000, A4000, A5000).
для Serving у Nvidia есть GPU Tesla A2, которая подойдет, если ваша модель и порция данных для обработки не превышают размер ее видеопамяти; если превысят, выбирайте из GPU в первом пункте;
для обработки данных может вообще не понадобится видеокарта, так как этот процесс может быть построен на CPU; здесь, впрочем, выбор еще сложнее — можно рассмотреть AMD Epyc, Intel Xeon Gold или современные десктопные процессоры.

Сложности добавляет повсеместное распространение Kubernetes как инфраструктурной платформы для ML-систем. Все вычислительные ресурсы нужно уметь использовать в k8s.

Получается, большая схема про MLOps — лишь верхний уровень абстракции, с которым приходится иметь дело.

Reasonable и Medium Scale MLOps

После рассмотрения настолько обширной схемы и озвученных артефактов пропадает желание что-то подобное строить в собственной компании. Нужно выбрать и внедрить множество инструментов, подготовить необходимую для них инфраструктуру, научить команду со всем этим работать, а еще и поддерживать все вышеперечисленное.

В этом деле главное — начать. Не стоит внедрять сразу все компоненты MLOps, если в них нет бизнес-потребности. Руководствуясь моделями зрелости, можно создать базу, вокруг которой в дальнейшем будет развиваться ML-платформа.

Вполне вероятно, что для достижений бизнес-целей многие компоненты никогда и не понадобятся. Эта мысль уже активно продвигается в различных статьях про reasonable и medium scale MLOps.

Разница между MLOps и ModelOps

В завершение упомянем и ModelOps. Это он часть MLOps или это MLOps часть ModelOps? Вот статья, которая отлично отвечает на этот вопрос. Вообще The MLOps Blog от neptune.ai стоит регулярно читать — иногда там публикуют неплохие статьи.

В следующем тексте мы рассмотрим MLOps как информационную систему.

Что такое MLOps? Теоретический аспект

ModelOps: непрерывное управление
жизненным циклом модели

Внедряйте большее количество аналитических моделей
в бизнес в более сжатые сроки.

Джефф Алфорд, редактор SAS Insights

ModelOps – методика бесперебойной интеграции аналитических моделей в бизнес, когда модели, созданные командой аналитиков, реализуются в ИТ окружении компании в условиях внесения регулярных изменений и обновлений. Такой подход позволяет лидерам рынка применения ИИ в бизнесе получить существенное конкурентное преимущество.

Компании неуклонно расширяют практику применения моделей машинного обучения для принятия правильных и своевременных решений. Такие модели не ограничены количеством входных параметров, которые могут эффективно использовать, и способны обрабатывать огромные объемы структурированных и неструктурированных данных для выявления полезных паттернов.

Узнайте, что вы можете сделать для того, чтобы исправить ситуацию, когда более половины разработанных моделей так и не внедряются в бизнес.

Процесс регистрации, перетренировки, скоринга, интеграции, управления и мониторинга аналитических моделей будет занимать у вас всего несколько кликов в графическом интерфейсе.

Многие организации сталкиваются со сложностями при попытках встроить аналитические модели в бизнес. В среднем, только половина разработанных моделей впоследствии используется бизнесом для принятия решений, а процесс их внедрения занимает до 3-х месяцев. Трудоемкость процесса может приводить к росту операционных затрат и задержкам в получении практической пользы от моделей.

Качество работы моделей не постоянно, и падает с течением времени, что в отсутствии инструментов контроля приводит к их неэффективному использованию. Как и автомобилям, моделям нужно проходить регулярную процедуру технического обслуживания для обеспечения стабильного функционирования. Качество работы модели зависит не только от ее параметров, но и от входных данных, своевременности внесения доработок и перетренировки.

ModelOps позволяет моделям быстрее выбраться из стен «лаборатории» аналитиков и оперативно перейти к этапам валидации, тестирования и интеграции в ИТ-ландшафт, обеспечивая получение качественного результата на основе. Такой подход позволяет управлять моделями, масштабировать их применение для решения бизнес-задач и постоянно отслеживать метрики качества работы, выявляя и устраняя признаки деградации на ранних стадиях. Пакетное предложение ModelOps основано на общепринятых принципах DevOps. Это ключевой компонент для успешной реализации масштабируемой предиктивной аналитики в бизнесе. Стоит отметить, что практика разработки моделей отличается от принципов разработки программного обеспечения. Особенности этого подхода приведены далее в тексте.

ModelOps позволяет моделям быстрее выбраться из стен «лаборатории» аналитиков и оперативно перейти к этапам валидации, тестирования и интеграции в ИТ-ландшафт, обеспечивая получение качественного результата на основе.

Непрерывная оценка результатов

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

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

Далее на операционном уровне необходимо настроить регулярную оценку качества работы каждой модели. Поскольку им свойственно терять свою предиктивную силу со временем, модели нуждаются в перетренировке и повторной интеграции. Несколько советов для создания панели мониторинга производительности:

Для отдельных моделей (или классов моделей) установите целевые показатели и отслеживайте их на этапах разработки, валидации и интеграции. Это могут быть параметры, относящиеся к оценке статистических свойств входных данных или общие метрики качества работы модели на различных временных срезах.
Определите бизнес-показатели, на которые влияет работа модели. Например, сколько новых клиентов удалось привлечь благодаря использованию модели?
Отслеживайте различные параметры, относящиеся к свойствам входных данных: их размер, частоту обновления, локализацию, категоризацию и типизацию. Зачастую проблемы бывают связаны со структурой данных, их качеством, которые меняются на протяжении всего жизненного цикла.
Следите за тем, сколько вычислительных ресурсов используется моделями.

Описанные метрики оцениваются на этапе валидации – важной части жизненного цикла модели и неотъемлемом элементе концепции ModelOps. Некоторые совмещают понятия валидации и верификации, но при этом у этих понятий разный смысл.

На этапе верификации производится оценка того, как модель встроена в бизнес, и соответствие работы с ее назначением. Валидация нужна для того, чтобы убедиться, что модель показывает те результаты, на которые ориентируется бизнес. Оба понятия являются важной частью практики разработки и применения качественных моделей.

Три распространенные проблемы, решаемые с помощью подхода ModelOps.

Качество работы моделей начинает снижаться сразу после их разработки (иногда эффект заметен уже по итогам нескольких дней). Конечно, в различных случаях факторы, оказывающие влияние на производительность моделей, могут отличаться. Ниже приведены наиболее часто встречающиеся проблемы, с которыми сталкиваются компании.

Незначительные изменения в структуре и статических свойствах данных, которые сложно заметить или оценить их влияние в рамках традиционного подхода к аналитике, могут существенно повлиять на качество работы моделей машинного обучения.

В рамках концепции ModelOps важно правильно оценить входные данные для ваших моделей и ответить на следующие вопросы:

Какие источники данных планируются к использованию?
Могли бы вы объяснить клиенту, что причина принятого решения основывается на этих данных?
Используемые данные прямо или косвенно относятся к области, которая регулируется законами и нормативами?
Как вы решили вопрос баланса точности и стабильности модели?
Как часто добавляются или изменяются входные переменные для модели?
Насколько легко выполняется конструирование новых признаков для модели?

Время от разработки до внедрения модели

Поскольку длительность цикла разработки/внедрения модели может отличаться в зависимости от специфики компании, стоит исходить из оценки, сколько времени он сейчас занимает в вашей компании, а затем установить контрольные показатели для оценки результатов. Разбейте жизненный цикл модели на отдельные этапы, затем измерьте и сравните эти показатели для различных проектов, чтобы выявить сильные места и зоны роста. Оцените использование специального программного обеспечения для управления моделями, которое автоматизирует ручные действия.

Снижение качества работы во времени

Держите стабильность работы моделей под контролем. Эту проблему решает создание системного подхода к управлению моделями в вашей организации. Если все сотрудники вовлеченные в работу с моделями — от разработчиков до бизнес-пользователей, имеют понятную и зафиксированную зону ответственности за качество работы ваших моделей, то эти проблемы можно решить еще до того, как они повлияют на вашу прибыль.

Когда обновлять модели

Одними из самых сложных вопросов в практике применения машинного обучения в бизнесе являются внедрение моделей и поддержание их стабильной работы. Эта задача также связана с постоянным поиском новых данных, которые могут быть полезны для работы моделей и поддержания используемых данных в нужном формате.

Можно ли установить стандартное расписание для перетренировки любых моделей? Простой ответ «нет». Почему? Одной из причин является то, что модели теряют свои предиктивные свойства из-за различных факторов. Другая связана с тем, насколько сильно работа модели влияет на бизнес. Например, наиболее оперативного обновления требуют модели принятия решений, от которых напрямую зависит финансовый результат компании.

Вот почему важно сформулировать и регулярно отслеживать критерии качества работы ваших моделей.

Риск игнорирования ModelOps

Предиктивная способность аналитических моделей в сочетании с доступностью больших данных и наличием релевантных вычислительных мощностей будет и впредь служить источником важного преимущества в работе наиболее результативных организаций. Компании, которые окажутся не в состоянии использовать принципы ModelOps, столкнутся с растущими трудностями в масштабировании своих аналитических решений и могут отстать от более успешных конкурентов.

«АШАН» внедрил корпоративную ModelOps-платформу на открытых технологиях

Компания GlowByte завершила проект по внедрению корпоративной ModelOps-платформы на открытых технологиях в торговой сети «АШАН Ритейл Россия». Решение позволило специалистам Data Science создать среду для проектирования и ввода в промышленную эксплуатацию ML-моделей.

«Скорость и точность – это необходимое условие конкурентоспособности компании на рынке розничной торговли. Совместно с GlowByte мы реализовали проект по созданию единой среды для работы с большими данными, которая позволяет управлять ML-моделями, написанными на любом языке, – прокомментировал Максим Строгий, IT-директор «АШАН Ритейл Россия». – Благодаря проекту мы повысили эффективность Big Data, внедрив прогнозные и рекомендательные модели на основе машинного обучения. Отмечу гибкость и надежность платформы – мы быстро смогли перестроиться и адаптироваться к работе на новом ПО».

При построении архитектуры платформы команды руководствовались принципами MLOps-подхода к разработке ML-моделей. Это набор практик и технологий, которые объединяют Machine Learning, DevOps, Data Engineering и Model Governance в единую методологию создания, внедрения и эксплуатации моделей машинного обучения.

Платформа интегрирована с источниками данных ритейлера, развернута в VK Cloud и состоит из различных инструментов кластера Kubernetes. Это обеспечивает гибкость инструмента, эффективное управление имеющимися вычислительными ресурсами и быстрое масштабирование.

Система для хранения персистентных данных (GlusterFS + Heketi) развернута на отечественной операционной системе Astra Linux. ML-модели разрабатываются на языке Python посредством JupyterLab, а с помощью инструмента Gitlab CI/CD построен единый пайплайн вывода модели от стадии разработки до применения в продакшене.

Жизненным циклом ML-моделей специалисты Data Science управляют посредством Open Source-платформы на основе MLFlow. Она позволяет проводить различные эксперименты – логировать метрики и параметры модели, принимать решения о ее внедрении, выполнять ретроспективный анализ процесса изменения метрик и моделей. В качестве оркестратора применения ML-моделей используется Airflow.

«Благодаря MLOps-платформе, внедренной в торговой сети «АШАН Ритейл Россия», все ML-модели теперь разрабатываются на основе единого шаблона и имеют стандартизированный пайплайн продуктивизации для регламентного предсказания и автоматического переобучения, – сказал Александр Кухтинов, руководитель практики ModelOps GlowByte. – Сейчас на платформе отработан процесс вывода Python-моделей, но в целом гибкость инструмента позволяет работать с любыми моделями, в том числе R, Java, C/C++. Тестовые запуски показали снижение как time-to-market, так и времени на поддержание и переобучение модели, а это значит, что у дата-сайентистов и IT-подразделения появится возможность для решения большего количества задач».

Статья относится к тематикам: Крупные мировые ритейлеры, Устойчивое развитие
Поделиться публикацией:

Подписывайтесь на наши новостные рассылки, а также на каналы Telegram , Vkontakte , Яндекс.Дзен чтобы первым быть в курсе главных новостей Retail.ru.
Добавьте «Retail.ru» в свои источники в Яндекс.Новости

«АШАН» внедрил корпоративную ModelOps-платформу на открытых технологиях https://www.retail.ru

auchan, it, retailer, ашан, бизнес, продуктовый ритейл, технологии «АШАН» внедрил корпоративную ModelOps-платформу на открытых технологиях