Mlops

Всем привет! Я CV-разработчик в КРОК. Уже 3 года мы реализуем проекты в области CV. За это время чего мы только не делали, например: мониторили водителей, чтобы во время движения они не пили, не курили, по телефону не разговаривали, смотрели на дорогу, а не сны или в облака; фиксировали любителей ездить по выделенным полосам и занимать несколько мест на парковке; следили за тем, чтобы работники носили каски, перчатки и т.п.; идентифицировали сотрудника, который хочет пройти на объект; подсчитывали всё, что только можно.

Я все это к чему?

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

Моделируем ситуацию

Представим, что мы устроились в молодую компанию N, деятельность которой связана с ML. Работаем мы над ML (DL, CV) проектом, потом по каким-либо причинам переключаемся на другую работу, в общем делаем перерыв, и возвращаемся к своей или чужой нейроночке.

1. Наступает момент истины, нужно как-то вспомнить на чем ты остановился, какие гиперпараметры пробовал и, самое главное, к каким результатам они привели. Может быть множество вариантов, кто как хранил информацию по всем запускам: в голове, конфигах, блокноте, в рабочей среде в облаке. Мне довелось видеть вариант, когда гиперпараметры хранились в виде закомментированных строк в коде, в общем полет фантазии. А теперь представьте, что вы вернулись не к своему проекту, а к проекту человека, который покинул компанию и в наследство вам достался код и модель под названием model_1.pb. Для полноты картины и передачи всей боли, представим, что вы еще и начинающий специалист.
2. Идем дальше. Для запуска кода нам и всем кто будет с ним работать необходимо создать окружение. Часто бывает, что и его нам в наследство также по каким-то причинам не оставили. Это тоже может стать нетривиальной задачей. На этот шаг не хочется тратить время, не так ли?
3. Тренируем модель (например, детектор автомобилей). Доходим до момента, когда она становится очень даже ничего самое время сохранить результат. Назовем ее car_detection_v1.pb. Потом тренируем еще одну car_detection_v2.pb. Некоторое время спустя наши коллеги или мы сами обучаем ещё и ещё, используя различные архитектуры. В итоге формируется куча артефактов, информацию о которых нужно кропотливо собирать (но, делать мы это будем позже, у нас ведь пока есть более приоритетные дела).
4. Ну вот и всё! У нас есть модель! Мы можем приступать к обучению следующей модели, к разработке архитектуры для решения новой задачи или можем пойти попить чай? А деплоить кто будет?

Выявляем проблемы

Работа над проектом или продуктом это труд многих человек. А с течением времени люди уходят и приходят, проектов становится больше, сами проекты становятся сложнее. Так или иначе, ситуации из описанного выше цикла (и не только) в тех или иных комбинациях будут встречаться от итерации к итерации. Все это выливается в трату времени, путаницу, нервы, возможно в недовольство заказчика, и в конечном счете в упущенные деньги. Хоть все мы обычно ходим по старым граблям, но полагаю, что никто при этом не хочет раз за разом переживать эти моменты.

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

• удобно хранить результаты работы;
• сделать простым процесс вовлечения новых сотрудников;
• упростить процесс развертывания среды разработки;
• настроить процесс версионирования моделей;
• иметь удобный способ валидации моделей;
• найти инструмент управления состоянием моделей;
• найти способ доставки моделей в production.

Видимо необходимо придумать workflow, который бы позволял легко и удобно управлять этим жизненным циклом? У такой практики есть название MLOps

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

Можете почитать, что обо всем этом думают ребята из Google. Из статьи понятно, что MLOps, довольно, объемная штука.

Далее в своей статье я опишу лишь часть процесса. Для реализации я воспользуюсь инструментом MLflow, т.к. это open-source проект, для подключения необходимо небольшое количество кода и есть интеграция с популярными ml-фреймворками. Вы можете поискать на просторах интернета другие инструменты, например Kubeflow, SageMaker, Trains и т.д., и возможно, подобрать тот, который лучше подходит под ваши нужды.

"Cтроим" MLOps на примере использования инструмента MLFlow

MLFlow это платформа с открытым исходным кодом для управления жизненным циклом ml моделей (https://mlflow.org/).

MLflow включает четыре компонента:

• MLflow Tracking закрывает вопросы фиксации результатов и параметров, которые к этому результату привели;
• MLflow Project позволяет упаковывать код и воспроизвести его на любой платформе;
• MLflow Models отвечает за деплой моделей в прод;
• MLflow Registry позволяет хранить модели и управлять их состоянием в централизованном хранилище.

MLflow оперирует двумя сущностями:

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

Все шаги примера реализованы на операционной системе Ubuntu 18.04.

1. Разворачиваем сервер

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

• backend store отвечает за хранение информации о зарегистрированных моделях (поддерживает 4 СУБД: mysql, mssql, sqlite, and postgresql);
• artifact store отвечает за хранение артефактов (поддерживает 7 вариантов хранения: Amazon S3, Azure Blob Storage, Google Cloud Storage, FTP server, SFTP Server, NFS, HDFS).

В качестве artifact store для простоты возьмем sftp сервер.

• создаем группу
  

  $ sudo groupadd sftpg
  

• добавляем пользователя и устанавливаем ему пароль
  

  $ sudo useradd -g sftpg mlflowsftp$ sudo passwd mlflowsftp 
  

• корректируем пару настроек доступа
  

  $ sudo mkdir -p /data/mlflowsftp/upload$ sudo chown -R root.sftpg /data/mlflowsftp$ sudo chown -R mlflowsftp.sftpg /data/mlflowsftp/upload
  

• добавляем несколько строк в /etc/ssh/sshd_config
  

  Match Group sftpg ChrootDirectory /data/%u ForceCommand internal-sftp
  

• перезапускаем службу
  

  $ sudo systemctl restart sshd
  

В качестве backend store возьмем postgresql.

$ sudo apt update$ sudo apt-get install -y postgresql postgresql-contrib postgresql-server-dev-all$ sudo apt install gcc$ pip install psycopg2$ sudo -u postgres -i# Create new user: mlflow_user[postgres@user_name~]$ createuser --interactive -PEnter name of role to add: mlflow_userEnter password for new role: mlflowEnter it again: mlflowShall the new role be a superuser? (y/n) nShall the new role be allowed to create databases? (y/n) nShall the new role be allowed to create more new roles? (y/n) n# Create database mlflow_bd owned by mlflow_user$ createdb -O mlflow_user mlflow_db

Для запуска сервера необходимо установить следующие python пакеты (советую создать отдельное виртуальное окружение):

pip install mlflowpip install pysftp

Запускаем наш сервер

$ mlflow server  \                 --backend-store-uri postgresql://mlflow_user:mlflow@localhost/mlflow_db \                 --default-artifact-root sftp://mlflowsftp:mlflow@sftp_host/upload  \                --host server_host \                --port server_port

2. Добавляем трекинг

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

Для примера я создал небольшой проект на github на Keras по сегментации всего, что есть в COCO датасете. Для добавления трекинга я создал файл mlflow_training.py.

Вот строки, в которых происходит самое интересное:

def run(self, epochs, lr, experiment_name):        # getting the id of the experiment, creating an experiment in its absence        remote_experiment_id = self.remote_server.get_experiment_id(name=experiment_name)        # creating a "run" and getting its id        remote_run_id = self.remote_server.get_run_id(remote_experiment_id)        # indicate that we want to save the results on a remote server        mlflow.set_tracking_uri(self.tracking_uri)        mlflow.set_experiment(experiment_name)        with mlflow.start_run(run_id=remote_run_id, nested=False):            mlflow.keras.autolog()            self.train_pipeline.train(lr=lr, epochs=epochs)        try:            self.log_tags_and_params(remote_run_id)        except mlflow.exceptions.RestException as e:            print(e)

Здесь self.remote_server это небольшая обвязка над методами mlflow.tracking. MlflowClient (я сделал для удобства), с помощью которых я создаю эксперимент и запуск на сервере. Далее указываю куда должны сливаться результаты запуска (mlflow.set_tracking_uri(self.tracking_uri)). Подключаю автоматическое логирование mlflow.keras.autolog(). На данный момент MLflow Tracking поддерживает автоматическое логирование для TensorFlow, Keras, Gluon XGBoost, LightGBM, Spark. Если вы не нашли своего фреймворка или библиотеки, то вы всегда можете логировать в явном виде. Запускаем обучение. Регистрируем теги и входные параметры на удаленном сервере.

Пара строк и вы, как и все желающие, имеете доступ к информации о всех запусках. Круто?

3. Оформляем проект

Теперь сделаем так, чтобы запустить проект было проще простого. Для этого добавим в корень проекта файл MLproject и conda.yaml.
MLproject

name: flow_segmentationconda_env: conda.yamlentry_points:  main:    parameters:        categories: {help: 'list of categories from coco dataset'}        epochs: {type: int, help: 'number of epochs in training'}        lr: {type: float, default: 0.001, help: 'learning rate'}        batch_size: {type: int, default: 8}        model_name: {type: str, default: 'Unet', help: 'Unet, PSPNet, Linknet, FPN'}        backbone_name: {type: str, default: 'resnet18', help: 'exampe resnet18, resnet50, mobilenetv2 ...'}        tracking_uri: {type: str, help: 'the server address'}        experiment_name: {type: str, default: 'My_experiment', help: 'remote and local experiment name'}    command: "python mlflow_training.py \            --epochs={epochs}            --categories={categories}            --lr={lr}            --tracking_uri={tracking_uri}            --model_name={model_name}            --backbone_name={backbone_name}            --batch_size={batch_size}            --experiment_name={experiment_name}"

MLflow Project имеет несколько свойств:

• Name имя вашего проекта;
• Environment в моем случае conda_env указывает на то, что для запуска используется Anaconda и описание зависимостей находится в файле conda.yaml;
• Entry Points указывает какие файлы и с какими параметрами мы можем запустить (все параметры при запуске обучения автоматически логируются)

conda.yaml

name: flow_segmentationchannels:  - defaults  - anacondadependencies:  - python==3.7  - pip:    - mlflow==1.8.0    - pysftp==0.2.9    - Cython==0.29.19    - numpy==1.18.4    - pycocotools==2.0.0    - requests==2.23.0    - matplotlib==3.2.1    - segmentation-models==1.0.1    - Keras==2.3.1    - imgaug==0.4.0    - tqdm==4.46.0    - tensorflow-gpu==1.14.0

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

4. Запускаем обучение

Клонируем проект и переходим в директорию проекта:

git clone https://github.com/simbakot/mlflow_example.gitcd mlflow_example/

Для запуска вам необходимо установить библиотеки

pip install mlflowpip install pysftp

Т.к. в примере я использую conda_env на вашем компьютере должна быть установлена Anaconda (но и это можно обойти установив все необходимые пакеты самостоятельно и поигравшись с параметрами запуска).

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

$ mlflow run -P epochs=10 -P categories=cat,dog -P tracking_uri=http://server_host:server_port .

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

5. Оцениваем результаты обучения

После окончания обучения мы можем перейти в браузере по адресу нашего сервера http://server_host:server_port

Здесь мы видим список всех экспериментов (слева вверху), а также информацию по запускам (посередине). Мы можем посмотреть более подробную информацию (параметры, метрики, артефакты и какую-то доп. информацию) по каждому запуску.

По каждой метрике мы можем наблюдать историю изменения

Т.е. на данный момент мы можем анализировать результаты в "ручном" режиме, также вы можете настроить и автоматическую валидацию при помощи MLflow API.

6. Регистрируем модель

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

После того как мы дали имя нашей модели, у нее появляется версия. При сохранении другой модели с этим же именем, версия автоматически повысится.

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

У нас также имеется удобный доступ ко всем моделям

и их версиям

Как и в предыдущем пункте все операции можно сделать при помощи API.

7. Деплоим модель

На данном этапе у нас уже есть натренированная (keras) модель. Пример, как можно её использовать:

class SegmentationModel:    def __init__(self, tracking_uri, model_name):        self.registry = RemoteRegistry(tracking_uri=tracking_uri)        self.model_name = model_name        self.model = self.build_model(model_name)    def get_latest_model(self, model_name):        registered_models = self.registry.get_registered_model(model_name)        last_model = self.registry.get_last_model(registered_models)        local_path = self.registry.download_artifact(last_model.run_id, 'model', './')        return local_path    def build_model(self, model_name):        local_path = self.get_latest_model(model_name)        return mlflow.keras.load_model(local_path)    def predict(self, image):        image = self.preprocess(image)        result = self.model.predict(image)        return self.postprocess(result)    def preprocess(self, image):        image = cv2.resize(image, (256, 256))        image = image / 255.        image = np.expand_dims(image, 0)        return image    def postprocess(self, result):        return result

Здесь self.registry это опять небольшая обвязка над mlflow.tracking.MlflowClient, для удобства. Суть в том, что я обращаюсь к удаленному серверу и ищу там модель с указанным именем, причем, самую последнюю production версию. Далее скачиваю артефакт локально в папку ./model и собираю модель из этой директории mlflow.keras.load_model(local_path). Всё теперь мы можем использовать нашу модель. CV (ML) разработчики могут спокойно заниматься улучшением модели и публиковать новые версии.

В заключение

Я представил систему которая позволяет:

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

Данный пример является игрушечным и служит точкой старта для выстраивания вашей собственной системы, которая, возможно, будет включать в себя автоматизацию оценки результатов и регистрации моделей (п.5 и п.6 соответственно) или вы добавите версионирование датасетов, или может ещё что-то? Я пытался донести мысль, что вам нужен MLOps в целом, MLflow лишь средство достижения цели.

Напишите какие проблемы, с которыми вы сталкивались, я не отобразил?
Что бы вы добавили в систему, чтобы она закрывала ваши потребности?
Какие инструменты и подходы используете вы, чтобы закрыть все или часть проблем?

P.S. Оставлю пару ссылок:
github проект https://github.com/simbakot/mlflow_example
MLflow https://mlflow.org/
Моя рабочая почта, для вопросов ikryakin@croc.ru

У нас в компании периодически проводятся различные мероприятия для ИТ-специалистов, например: 8-го июля в 19:00 по МСК будет проходить митап по CV в онлайн-формате, если интересно, то можете принять участие, регистрация здесь .

В 2018 году в профессиональных кругах и на тематических конференциях, посвященных AI, появилось понятие MLOps, которое быстро закрепилось в отрасли и сейчас развивается как самостоятельное направление. В перспективе MLOps может стать одной из наиболее востребованных сфер в IT. Что же это такое и с чем его едят, разбираемся под катом.

Что такое MLOps

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

Иными словами, это способ превращения методов и технологий машинного обучения в полезный инструмент для решений задач бизнеса.

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

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

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

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

• определение бизнес-идеи;
  
• обучение модели;
  
• тестирование и внедрение модели в бизнес-процесс;
  
• эксплуатация модели.
  

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

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

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

Как заставить модели работать и приносить прибыль

В качестве примера, на котором мы продемонстрируем применение подхода MLOps, возьмем ставшую классической задачу роботизации чата поддержки банковского (или любого другого) продукта. Обычно бизнес-процесс поддержки с помощью чата выглядит следующим образом: клиент вводит в чате сообщение с вопросом и получает ответ специалиста в рамках заранее определенного дерева диалогов. Задача автоматизации такого чата обычно решается с помощью экспертно определенных наборов правил, очень трудоемких в разработке и сопровождении. Эффективность такой автоматизации, в зависимости от уровня сложности задачи, может составлять 2030%. Естественно, возникает идея, что более выгодным является внедрение модуля искусственного интеллекта модели, разработанной с помощью машинного обучения, которая:

• способна обработать без участия оператора большее количество запросов (в зависимости от темы, в некоторых случаях эффективность может достигать 7080%);
  
• лучше адаптируется под нестандартные формулировки в диалоге умеет определять интент, реальное желание пользователя по не четко сформулированному запросу;
  
• умеет определять, когда ответ модели адекватен, а когда в качестве осознанности этого ответа есть сомнения и нужно задать дополнительный уточняющий вопрос или переключиться на оператора;
  
• может быть дообучена автоматизированно (вместо группы разработчиков, постоянно адаптирующих и корректирующих сценарии ответов, модель дообучает специалист по Data Science, применяя соответствующие библиотеки машинного обучения).
  

Как заставить такую продвинутую модель работать?

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

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

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

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

Новый процесс новые вызовы

Исчерпывающий ответ на принципиальный вопрос бизнеса о том, насколько ML-модели применимы для решения задач, общий вопрос доверия к ИИ это один из ключевых вызовов в процессе развития и внедрения подходов MLOps. Первоначально бизнес скептически воспринимает внедрение машинного обучения в процессы сложно полагаться на модели в тех местах, где ранее, как правило, работали люди. Для бизнеса программы представляются черным ящиком, релевантность ответов которого еще надо доказать. Кроме того, в банковской деятельности, в бизнесе операторов связи и других существуют жесткие требования государственных регуляторов. Аудиту подвергаются все системы и алгоритмы, которые внедрены в банковские процессы. Чтобы решить эту задачу, доказать бизнесу и регуляторам обоснованность и корректность ответов искусственного интеллекта, вместе с моделью внедряются средства мониторинга. Кроме того, существует процедура независимой валидации, обязательная для регуляторных моделей, которая соответствует требованиям ЦБ. Независимая экспертная группа проводит аудит результатов, полученных моделью с учетом входных данных.

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



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

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

Весь цикл требует большого количества высококвалифицированных специалистов. В определенной точке развития и степени проникновения ML-моделей в бизнес-процессы оказывается, что линейно масштабировать число специалистов пропорционально росту количества задач становится дорого и неэффективно. Поэтому возникает вопрос автоматизации процесса MLOps определение нескольких стандартных классов задач машинного обучения, разработка типовых пайплайнов обработки данных и дообучения моделей. В идеальной картине для решения таких задач требуются профессионалы, одинаково хорошо владеющие компетенциями на стыке BigData, Data Science, DevOps и IT. Поэтому самая большая проблема в индустрии Data Science и самый большой вызов при организации процессов MLOps это отсутствие такой компетенции на имеющемся рынке подготовки кадров. Специалисты, удовлетворяющие таким требованиям, в настоящий момент единичны на рынке труда и ценятся на вес золота.

К вопросу о компетенциях

В теории все задачи MLOps можно решать классическими инструментами DevOps и не прибегать к специализированному расширению ролевой модели. Тогда, как мы уже отметили выше, дата-сайентист должен быть не только математиком и специалистом по аналитике данных, но и гуру всего пайплайна на его плечи ложится разработка архитектуры, программирование моделей на нескольких языках в зависимости от архитектуры, подготовка витрины данных и деплоймент самого приложения. Однако создание технологической обвязки, реализуемой в сквозном процессе MLOps, занимает до 80% трудозатрат, а это значит, что квалифицированный математик, которым является качественный Data Scientist, будет только 20% времени посвящать своей специальности. Поэтому разграничение ролей специалистов, осуществляющих процесс внедрения моделей машинного обучения, становится жизненно необходимым.

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

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

Что уже сейчас сделано нашей командой

Мы не так давно начали строить структуру компетенций и процессы MLOps. Но уже сейчас в стадии тестирования MVP находятся наши проекты по управлению жизненным циклом моделей и по применению моделей как сервис.

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

Вопросы на будущее

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

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

От ответов на эти вопросы во многом будет зависеть, насколько быстро MLOps раскроет свой потенциал полностью.