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

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

______________________________________________

Текст большой, поэтому вам понадобится навигация:

— Что такое MLOps
— Уровни зрелости MLOps: самые известные модели
— Основные процессы MLOps

• Experimentation, или процесс проведения экспериментов
• Feature engineering, или разработка фичей
• Automated ML Workflow
• Serving и мониторинг моделей
• Project initiation, или инициализация проекта

— Артефакты MLOps
— MLOps как информационная система
_______________________________________________

Что такое MLOps?

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

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

Определение и его пояснение

Единого и согласованного определения MLOps пока не существует. Многие авторы пытались его дать, но одновременно понятное и системное определение найти было очень сложно.

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

MLOps is an engineering discipline that aims to unify ML systems development(dev) and ML systems deployment(ops) to standardize and streamline the continuous delivery of high-performing models in production.

Выделим ключевые части определения MLOps:

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

Получается, что MLOps — это своего рода DevOps для ML-моделей.

История появления MLOps

Легко поверить, что подобная инженерная дисциплина зародилась в недрах большой IT-компании. Так что можно довериться версии, что MLOps, как осмысленный подход, зародился в Google, где Д. Скалли (D. Sculley) пытался спасти свои нервы и время от рутинных задач вокруг вывода ML-моделей в прод. Теперь Скалли широко известен как «The Godfather of MLOps» — одноименный подкаст легко найти в интернете.

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

Результатом его работы стала статья «Hidden Technical Debt in Machine Learning Systems», которая вышла в 2015 году на конференции NeurIPS. Именно дату публикации этой статьи можно считать точкой отсчета существования MLOps.

Если вам интересна тема статьи, присоединяйтесь к нашему сообществу «MLечный путь» в Telegram. Там мы вместе обсуждаем проблемы и лучшие практики организации production ML-сервисов, а также делимся собственным опытом. А еще там раз в неделю выходят дайджесты по DataOps и MLOps.

Уровни зрелости MLOps: самые известные модели

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

Модель GigaOm

Одна из самых подробно описанных и во многом понятных моделей — от аналитической фирмы GigaOm. Из всех моделей она больше всего приближена к Capability Maturity Model Integration (CMMI). Это набор методологий совершенствования процессов в организациях, который также состоит из пяти уровней — от 0 до 4.


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

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

Модель Google

Стоит отметить, что в Google также есть своя модель уровней зрелости MLOps. Резонно сказать, что она появилась одной из первых, лаконична и состоит из трех уровней:

level 0: Manual process,
level 1: ML pipeline automation,
level 2: CI/CD pipeline automation

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

Модель Azure

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

level 0: No MLOps,
level 1: DevOps but no MLOps,
level 2: Automated Training,
level 3: Automated Model Deployment.
level 4: Full MLOps Automated Operations.

Все выделенные модели сходятся примерно в одном: на нулевом уровне у них — отсутствие каких бы то ни было ML-практик, а на последнем — автоматизация MLOps-процессов. В центре всегда что-то свое, что так или иначе связано с постепенной автоматизацией процессов. У Azure это автоматизация процесса обучения, а потом и деплоя моделей.

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

Как описать все процессы, связанные с понятием MLOps? Удивительно, но трем немцам — авторам статьи «Machine Learning Operations (MLOps): Overview, Definition, and Architecture» — удалось даже заключить их в одну схему. Они провели настоящее исследование и описали концепцию MLOps очень подробно.


При первом знакомстве она может пугать — на ней много элементов, взаимодействующих друг с другом. При этом на ней можно найти многие характеристики упомянутых уровней зрелости. Как минимум автоматизированные пайплайны, CI/CD, Monitoring, Model Registry, Workflow Orchestration и Serving Component.

Теперь попробуем разобрать по кусочкам эту схему и рассказать о каждом более подробно.

Основные процессы MLOps

Главными частями схемы являются горизонтальные блоки, внутри которых описаны процедурные аспекты MLOps (им присвоены буквы А, B, С, D). Каждый из них предназначен для решения конкретных задач в рамках обеспечения бесперебойной работы ML-сервисов компании. Для простоты понимания схемы лучше начать не по порядку.

Experimentation, или процесс проведения экспериментов

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

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

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

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

Представленный на схеме блок С описывает процесс проведения ML-экспериментов.


В его состав входят следующие этапы:

• data analysis,
• data preparation and validation,
• model training,
• model validation,
• model export.

Анализ данных, имеющихся в рамках задачи

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

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

• провести ADHoc-исследование с помощью Jupyter или Superset,
• стандартный EDA (Exploratory Data Analysis).

Лучшее понимание данных можно получить только в купе с семантическим и структурным анализом.

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

Формирование качественного датасета

Когда появилась уверенность в имеющихся данных, необходимо продумать правила их предобработки. Даже если есть большой набор подходящих данных, нет гарантии, что в нем нет пропусков, искаженных значений и т.д. Здесь в пору упомянуть термин «качество входных данных» и известную фразу «Garbage in — garbage out».

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

Обучение и валидация ML-модели

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

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

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

Сохранение кода и гиперпараметров в репозитории

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

Ключевая цель процесса экспериментирования — model engineering, что подразумевает выбор наилучшего алгоритма реализации задачи (best algorithm selection) и подбор наилучших гиперпараметров модели (hyperparameter tuning).

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

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

Feature engineering, или разработка фичей

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

В качестве новых фичей могут выступать:

• для табличных данных: произвольные преобразования уже существующих признаков объектов — например, X^2, SQRT(X), Log(x), X1*X2 и др.,
• исходя из предметной области: индекс массы тела, количество просроченных платежей по кредиту за год, оценка фильма на «Кинопоиск» и др.

Страждущие могут изучить хорошую книгу на тему работы с признаками.


Посмотрим на часть схемы, которая относится к Feature engineering.

Блок B1 направлен на формирование набора требований к преобразованию имеющихся исходных данных и получение из них фичей. Причем расчет самих фичей происходит из этих самых предобработанных и очищенных данных по тем «формулам», которые ввел ML-разработчик.

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

Непосредственно процесс добавления новых фичей в данные описывается блоком B2 и включает в себя:

• connect to raw data.
• data extraction,
• data transformation and cleaning,
• feature engineering,
• data ingestion.

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

Очистка и преобразование данных. Этот этап практически полностью перекликается с аналогичным шагом в блоке проведения экспериментов (С) — data preparation. По сути, уже на этапе первых экспериментов появляется понимание, какие данные и в каком формате нужны для обучения ML-моделей. Остается только правильно генерировать и проверять новые фичи, но сам процесс подготовки данных для этого хочется максимально автоматизировать.

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

Добавление результата. Итог выполнения предыдущих действий добавляется к датасету. Чаще всего фичи добавляются в датасет порциями (batch), чтобы уменьшить нагрузку на базы. Но иногда необходимо делать это на лету (streaming), чтобы ускорить выполнение бизнес-задач.

Полученные фичи важно использовать максимально эффективно: сохранять и переиспользовать в задачах других ML-разработчиков компании. Для этого в схеме есть Feature store. По-хорошему, он должен быть доступен внутри компании, отдельно администрироваться и версионировать все попадающие в него фичи. В самом Feature store есть две части: online (для streaming-сценариев) и offline (для batch-сценариев).

Собрали для вас подборку текстов про Machine Learning:

→ Каким должен быть Feature Store, чтобы оптимизировать работу с ML-моделями
→ ONNX Runtime, OpenVINO и TVM: обзор инструментов для ускорения ML-моделей
→ Как переехать на Kubeflow в качестве ML-платформы?

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

Automated ML Workflow

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

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


Для эффективной работы production ML-системы важно следить за inference-метриками модели. Как только они начинают проседать, модель нужно либо дообучить, либо заменить новой. Чаще всего это происходит из-за изменения входных данных (data drift). Например, есть бизнес-задача, в которой модель умеет распознавать хлеб на фотографиях, а ей на вход подается такое. Песики в примере — для баланса:


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

К слову, это не самый выдуманный сценарий. Есть реальная отсылка в кинематографе:

Теперь к более реальным примерам. Рассмотрим рекомендательную систему маркетплейса.

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

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

Дальше — крики менеджеров и требования восстановить все к завтрашнему дню, которые ни к чему не приводят. Почему? Недостаточно данных о новых предпочтениях покупателей, поэтому даже новую модель не сделаешь. Можно, конечно, взять какой-нибудь базовый алгоритм генерации рекомендации (item based collaborative filtering) и добавить в production. Так рекомендации будут хоть как-то работать, но это лишь временный «костыль».

Получается, в идеале процесс должен быть выстроен так, чтобы без указки менеджеров, на основании метрик, запускался процесс переобучения или экспериментирования с разными моделями. А лучшая в итоге замещала текущую в production. На схеме это Automated ML Workflow Pipeline (блок D), который запускается по триггерам в каком-либо инструменте оркестрации.


Это, пожалуй, самый нагруженный участок схемы. В работе блока D участвуют сразу несколько ключевых сторонних компонентов:

• Workflow orchestrator component, отвечающий за запуск пайплайна по заданному расписанию или событию,
• Feature Store, из которого берутся данные по необходимым для модели фичам,
• Model Registry и ML metadata store, куда помещаются модели и их метрики, полученные по завершении работы запущенного пайплайна.

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

• export model,
• push to model registry.

Остальные этапы идентичны описанным выше.

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

Чаще всего, в рамках кода запускаются различные ML-инструменты, внутри которых происходит выполнение этапов пайплайна, например:

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

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

В общем случае AutoML работает так:

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

По сути, AutoML проделывает все те манипуляции, которые проделывал бы условный Junior/Middle Data Scientist в кругу более-менее стандартных задач.

С автоматизацией немного разобрались. Далее необходимо организовать доставку новой версии модели в production.

Serving и мониторинг моделей

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

Если добавить деталей, то с момента получения файла с ML-моделью есть несколько вариантов развития событий. Команда может пойти:

• написать весь код для поднятия RESTfull-сервиса,
• реализовать всю обвязку вокруг него,
• собрать все это в Docker-образ,
• где-то потом из этого образа поднять контейнер,
• как-то его смасштабировать,
• организовать сбор метрик,
• настроить алертинг,
• настроить правила, по которым будут выкатываться новые версии модели,
• много еще чего.

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

• Inference Instance/Service,
• Inference Server,
• Serving Engine.

Inference Instance, или Inference Service, представляет собой конкретную ML-модель, подготовленную для получения запросов и генерации ответных предсказаний. Фактически такая сущность может представлять собой под в кластере Kubernetes, в котором есть контейнер с необходимой ML-моделью и технической оснасткой для ее работы.

Inference Server является создателем Inference Instances/Services. Существует множество реализаций Inference Server. Каждая может работать с определенными ML-фреймворками, преобразуя обученные в них модели в готовые — для обработки входных запросов и генерации предсказаний.

Serving Engine выполняет главные управленческие функции. От него зависит, какой Inference Server будет задействован, сколько копий полученного Inference Instance нужно запустить и каким образом выполнять их масштабирование.

В рассматриваемой схеме такой детализации компонентов model serving нет, но обозначены схожие аспекты:

• компонент CI/CD, который занимается развертыванием готовых для работы в проде моделей (можно считать его одной из версий Serving Engine),
• Model Serving, который в рамках доступной ему инфраструктуры организует схему генерации предсказаний для ML-моделей, причем и для потокового, и для пакетного сценариев (можно считать его одной из версий Inference Server).

В качестве примера законченного стека для Serving можно ссылаться на стек от Seldon:

• Seldon Core является Serving Engine,
• Seldon ML Server является Inference Server, который подготавливает доступ к модели по REST или gRPC,
• Seldon MLServer Custom Runtime является Inference Instance — примером оболочки для любой ML-модели, экземпляр которой необходимо запустить для генерации предсказаний.

Существует даже стандартизированный протокол для реализации Serving, поддержка которого де-факто является обязательной во всех подобных инструментах. Он называется V2 Inference Protocol и разработан несколькими крупными игроками рынка — KServe, Seldon, Nvidia Triton.

Serving vs Deploy

В различных источниках можно встретить упоминание инструментов для «Serving and Deploy» как единого целого. Однако важно понимать разницу в назначении обоих. Это дискуссионный вопрос, но в этой статье будет так:

• Serving — про создание API модели и возможность получить от нее предсказания, то есть в итоге — получение единичного инстанса сервиса с моделью внутри.
• Deploy — распространение инстанса сервиса в нужном количестве для обработки входящих запросов (можно представлять replica set в деплойменте Kubernetes).

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

Не стоит забывать, что метрики работы моделей должны отслеживаться, иначе не получится вовремя решать возникающие проблемы. Как именно отслеживать метрики — большой вопрос. Компания Arize AI на этом построила целый бизнес, но и Grafana с VictoriaMetrics никто не отменял.

Project initiation, или инициализация проекта

Учитывая все написанное выше, получается, что ML-команда:

• формирует датасеты,
• проводит на них эксперименты над ML-моделями,
• разрабатывает новые фичи для расширения датасетов и улучшения качества работы моделей,
• сохраняет лучшие модели в Model Registry для дальнейшего переиспользования,
• настраивает процессы Serving и Deploy моделей,
• настраивает мониторинг моделей в production и автоматический процесс дообучения текущей или создания новых моделей.

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

В нем пять этапов:

• business problem analysis,
• designs architecture and technologies to be used,
• define ML problem from business goal,
• understand required data to solve problem,
• connect to raw data for initial data analysis.

Ход мыслей тут можно продемонстрировать на примере рассуждений IT-директора в компании. К нему приходит вдохновленный менеджер проекта и просит новую инсталляцию платформы для построения ML-системы. Если оба действуют в интересах компании, от IT-директора последуют уточняющие вопросы:

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

IT-директор валит, как препод в универе, зато сохранит деньги компании. Если ответить на все вопросы удалось, значит, необходимость в ML-системе реально есть.

Следующий вопрос: нужно ли делать в ней MLOps?

Зависит от задачи. Если нужно найти однократное решение, например, PoC (Proof of concept), то MLOps не нужен. Если важно обрабатывалось большое количество входящих запросов, то MLOps нужен. По сути, подход аналогичен оптимизации любого корпоративного процесса.

Чтобы обосновать необходимость MLOps перед руководством, нужно подготовить ответы на вопросы:

• что станет лучше,
• сколько денег сэкономим,
• нужно ли расширять штат,
• что нужно купить,
• где взять экспертизу.

А дальше снова сдавать экзамен IT-директору.

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

Чтобы убедить команду, стоит подготовить ответы на вопросы:

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

Промежуточный итог

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

Артефакты MLOps

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

• данные,
• модель,
• код.

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

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

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

Данные

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

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

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

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

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

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

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

Модель

Теперь поищем на схеме артефакты, имеющие отношение к 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 как информационная система

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

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

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

• hardware (железо),
• software (софт),
• data (данные),
• networks (сетевая связность)
• people (команда),
• procedures (процессы).

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

Чтобы детальнее описать всю сложность ML-платформы, необходимо рассмотреть каждый из элементов ИС.

Железо

Далеко не все участники рынка осознанно подходят к выбору аппаратного обеспечения для ML-системы. Особенно это заметно в разрезе выбора GPU. Часто используется то оборудование, на котором построен pipeline, — потом этот паттерн просто перетекает в следующие проекты. Впрочем, это не всегда плохо: например, это обосновано, если переписывать pipeline очень дорого.

Если у небольшой компании есть возможность купить себе сервер для ML, то в большинстве случаев она выберет машину с GPU потребительского сегмента (RTX 2000/3000).

Теперь разберем этот выбор:

• Для не самых ресурсоемких задач такие серверы подойдут.
• Если появляется потребность в большом количестве видеопамяти, сразу возникают сложности. Нужно учитывать, что в память должны поместиться модель и какое-то количество данных для нее. Можно подстроить размер порции данных для обучения или инференса, чтобы уложиться в отведенное место.
• Если вес модели достигает десятков гигабайт (например, компания разрабатывает голосовых роботов) и данные для нее необходимо доставлять, выбранный сервер точно не подойдет. Популярных альтернатив тут три: Nvidia Tesla A30 на 24 ГБ и Nvidia Tesla A100 на 40 и 80 ГБ. Если и этого мало, на помощь придет объединение нескольких GPU через NVLink или NVSwitch.

С памятью GPU немного разобрались. А как подбирать CPU и RAM?

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

CPU чаще всего нужен для предобработки и загрузки данных в RAM. В зависимости от специфики эксперимента могут задействоваться как все ядра CPU, так и малая часть. Некоторые для каждой высокопроизводительной GPU выделяют от 12 до 24 vCPU, а кому-то хватает и 8. Точное число ядер можно получить только экспериментами.

Дополнительную головную боль, опять-таки, привносит необходимость пользоваться GPU в Kubernetes, так как он де-факто является стандартом для реализации ML-систем. Головная боль заключается в необходимости (в понятиях Kubernetes) превратить GPU в доступный ресурс. Без этого пользоваться видеокартой будет невозможно. Для этого необходимо разобраться с Nvidia GPU Operator или его отдельным компонентом — Device Plugin. И раз до этого дошло, хорошо бы еще правильно аннотировать ноды лейблами. Даже не все Kubernetes-админы про такое слышали.

Софт

Разговор про программное обеспечение необходимо разделить на несколько частей:

• ML-специфичные программы,
• вспомогательные программы.

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

Процесс экспериментирования можно выстроить с помощью любого из решений:

• ClearML,
• Kubeflow,
• MLFlow,
• guild.ai,
• polyaxon и т.д.

Автоматизацию переобучения моделей можно реализовать с помощью:

• Kubeflow,
• ClearML,
• Airflow,
• Dagster,
• Prefect т.д.

Serving и Deploy моделей можно реализовать с помощью:

• Seldon Core,
• KServe,
• BentoML и т.д.

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

Получается, есть целый стек ML-компонентов, которые нужно уметь настраивать, поддерживать и эксплуатировать. Часть про «настраивать и поддерживать» требует использования вспомогательного ПО.

Например:

• Kubernetes — в качестве среды оркестрации контейнеров.
• KeyCloak — в качестве единой точки авторизации пользователей.
• Grafana, Prometheus, Loki — в качестве средств мониторинга и сбора логов.
• Traefik — в качестве средства управления трафиком кластера.
• Балансировщик нагрузки для входящих запросов в кластер и пр.

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

На изучение и настройку всего в рамках одной системы может уйти очень много времени и сил. Просто поставить на сервере ClearML не поможет.

Данные

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

Итак, данные для ML могут храниться в сложных архитектурах:

• Data Warehouse,
• Data Lake,
• Data Lakehouse,
• Data Mesh и т.д.

Чтобы построить их, требуется огромное количество ресурсов, так что в этой статье только про MLOps.

Сетевая связность

Сейчас кластеры Kubernetes довольно часто расположены у какого-нибудь провайдера. Есть команды, у которых in-house-инфраструктура, но и там она в отдельной серверной, достаточно удаленной от команды.

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

Получается, нужно придумывать различные сетевые архитектуры, чтобы данные передавались быстрее, или внедрять кэши в кластер. Если данные in-house, а вычислительные ресурсы у провайдера, то может потребоваться отдельный сетевой канал, чтобы сохранить производительности при такой распределенной архитектуре.

Процедуры

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

Тут вспоминается ITIL со своими лучшими практиками управления IT-сервисами, но альтернативы в мире MLOps пока нет. Если CRISP-DM уже выглядит устаревшим, то CRISP-ML пока недостаточно развит. Можно найти его перечень процессов, но подробного описания самих процессов недостаточно.

Для начала можно предложить подумать про следующие регламенты:

• версионирования кода (модели, эксперименты, workflows),
• версионирования датасетов,
• версионирования файлов моделей,
• версионирование environments,
• логирование метрик,
• использование инфраструктуры,
• мониторинга метрик моделей.

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

Команда

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

На сегодняшний день чаще всего задачи внедрения ML-систем отдают DevOps-специалистам. Если они отвечают за CI/CD, пусть еще и ML-пайплайны себе заберут. Естественно, у подхода есть минусы:

• деплой ML-моделей отличается от деплоя кода,
• Serving и Deploy требуют знаний специфических инструментов,
• нужно разбираться в Kubernetes на высоком уровне, а такие специалисты и без ML на вес золота,
• нужно использовать IaaС и дружить с Terraform,
• вишенкой на торте является процесс Continuous Training, который подразумевает написание Python-скриптов для автоматизации взаимодействия разных компонентов в оркестраторах.

Как минимум нашему DevOps-специалисту потребуется много времени на изучение всех процессов и технологий. В одной версии идеального мира MLOps-специалист — следующая стадия развития DevOps-инженера. Когда уже все Terraform-файлы написал, сконфигурировал с помощью Ansible и в Kubernetes через Argo CD запустил.


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

На данный момент идеальный MLOps-инженер представляется как «воин дракона»: ученик, учитель, data scientist, backend developer, ML-инженер, data-инженер, devops, software developer и остальное в одном человеке. Только где такого найти?

Если вы дошли до конца, вы сильный духом человек, который действительно интересуется ML и MLOps. Будем рады вам в комментариях! Напишите, что вам показалось непонятным, или дополните текст полезными ссылками.