Нет ещё в мире IT-вайтбука по MLOps. Нет вайтбука — нет однозначного способа «сделать хорошо, а плохо не делать». Время экспериментов и открытий.

Привет, я Юрий Карев. В ВТБ руковожу командой, которая занимается созданием процессов и стандартов моделирования машинного обучения. И, помимо прочего, работаю с командой как раз над таким экспериментом: мы создаём в ВТБ MLOps-конвейер. По сути, делаем ту самую инструкцию: как правильно реализовать MLOps на практике. Одну из множества: уверен, наши конкуренты всё делают по-своему и тоже получают уникальный ценный опыт. Но этот пост — о нас. О том, как мы подошли к теме MLOps, как продали её бизнесу, чего уже достигли, какие трудности у нас были и как мы их преодолевали. Интересно? Проходите под кат, не стесняйтесь.

Что такое MLOps и в чём польза

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

К слову, 20 декабря вышел новый выпуск подкаста «Деньги Любят Техно. Сезон Data Science», где мы с ML Brand Director Яндекса Петром Ермаковым обсудили, для чего сегодня применяется MLOps и в каких задачах без него не обойтись завтра. Поговорили о том, помогает ли MLOps бизнесу развивать Data Science или, наоборот, мешает, а также в чём заключается роль специалиста по ML и как специализации будут дробиться в будущем. Наконец, кто всем этим должен заниматься и где этому учат. Если интересно, предлагаю послушать.

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

Как ВТБ пришли к работе над MLOps-практиками — и что они могут нам дать

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

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

Актуальный и простой пример для банков: насколько вероятно берущий кредит клиент перестанет его выплачивать через пару месяцев? Влияет ли на эту вероятность, например, то, как дисциплинированно клиент оплачивает свою сотовую связь?

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

По мере того как в ВТБ появлялись новые направления бизнеса, росло желание использовать в разных бизнес-процессах машинное обучение. А с ним и желание внедрить MLOps-практики. 

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

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

Чем мы аргументировали для бизнеса своё предложение создать MLOps-конвейер? Если его внедрить: 

• уменьшится Time2Market вывода моделей в ПРОМ, их можно будет быстрее начать использовать в процессах;

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

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

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

Бизнес хотел от MLOps-практик снижения издержек на развитие и внедрение ИИ-технологий в условиях «экспоненциального» роста использования моделей в процессах банка. Превратить выкатку моделей в рутину без особых затрат денег и времени с низким уровнем риска. 

Этапы нашей работы над MLOps

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

После определения Workflow мы создали систему управления моделями, которая, в частности, осуществляет трекинг этого Workflow. Создание системы заняло 9 месяцев; опытное использование, выявление практических недостатков, доработки — ещё около года. При этом само внедрение происходило стандартным образом в рамках IT-систем: с использованием обычных DevOps-подходов и инструментов, имевшихся на тот момент. 

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

Сейчас команда на следующем этапе: описав архитектуру, мы начинаем собственно разработку. Так как у ML есть ещё и специфический эффект неумолимого снижения качества со временем, в ходе разработки нам предстоит также создать ветку конвейера повторного обучения и дообучения (Continuous Training) в промышленном контуре. Это необходимо, чтобы сохранять качественные и количественные показатели модели на должном уровне.

Команда, которая создаёт MLOps в ВТБ

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

MLOps-практики и их успешное внедрение стоят на трёх китах: бизнес, IT и Big Data-технологии. Соответственно, у нас три основных типа ролей и прослоек между ними тоже три. Помимо уже знакомой связки «бизнес-IT», есть менее типичные «IT-Big Data» и «бизнес-Big Data». 

Изначально, создавая команду, мы отталкивались именно от профессий Data Scientist и Data Engineer. Позже, чтобы обеспечить успешную работу команды, ромашку пришлось дополнять: 

• бизнес-партнерами на стыке с бизнесом — чтобы обеспечить полное управление ожиданиями бизнес-заказчика. Не только по самой модели, но и по ее техническому внедрению в процесс (бизнес-Big Data). 

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

По мере развития мы также поняли, что у ML-архитекторов и и Data Analyst (бизнес-аналитиков данных) тоже свой специфический функционал. Пока их функции включены в типовые роли MLOPS-инженеров и дата-инженеров соответственно. Но по мере масштабирования и роста зрелости команд, вероятно, потребуется выделять их как отдельные роли.

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

Команда у нас двухуровневая. Есть кроссфункциональная команда (КФК), верхний уровень: она осуществляет общую координацию по задаче. Типичная кроссфункциональная команда состоит из тимидов — Data Scientist, Data Engineer, MLOps Engineer — и бизнес-партнера, который направляет команду. Иногда в КФК включается и тимлид IT-команды. Если требуется какая-то доработка специфической ИТ-платформы. Например, для AutoML-задач. 

У каждого тимлида есть команда нижнего уровня: от 4 до 10 человек. На них распределяются задачи на день, спринт и так далее. При этом тимлид в сторонке не стоит — он играющий тренер и также берёт часть задач как исполнитель. 

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

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

Подробнее о выборе архитектуры для нашего MLOps-конвейера

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

Теперь эту команду ждал долгий процесс описания архитектуры и проектирования. При проектировании мы старались придерживаться классических практик построения MLOps-конвейера. Они хорошо описаны и общедоступны в интернете: Google, Amazon SageMaker, Microsoft Azure, Databriсks, Neptune.ai. 

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

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

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

Как видите, структура и компоненты MLOps-конвейера значительно сложнее, чем у хорошо всем известного DevSecOps-конвейера. Это комбинация автоматизированных процессов управления моделями, кодом и данными. Сокращенно — ModelOps+Devops+DataOps. 

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

Создать контур разработки и тестирования моделей с промышленными данными

Для легализации такого контура пришлось получать разъяснения Банка России и вносить изменения в стандарты производственных процессов ВТБ. Зато мы, наконец-то, получили свободу использования любых инструментов и фреймворков для разработки ML-моделей. Не потеряв возможности применения их на промышленных данных без обезличивания или синтетических данных (как это происходит у стандартного разработчика ПО в банке).

Создать отдельную инфраструктуру для хранения технических артефактов модели 

Это было необходимо в связи со значительным объемом артефактов и необходимостью версионирования (веса моделей, выборки для разработки, обучения и валидации и так далее). Сейчас мы рассматриваем варианты реализации на базе S3 Ceph и DVC. В части DevSecOps проделали большую работу, чтобы расщепить модель на код и бинарные артефакты, и запустить для них параллельные конвейеры. Стандартный DevSecOps «не понимает», что такое “веса модели”. Получается, что подобные бинарные артефакты, иногда весящие гигабайты, создают дополнительную нагрузку на конвейер и репозитории ПО.

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

В неё входят JupyterHub, AirFlow, TensorBoard, Codeserver (VS code web) и Openshift. Мы собираемся автоматизировать сборку и развертывание прототипа модели. Исследуем варианты фреймворков, которые можно для этого использовать: MLFlow или Seldon. Выбранные технологии позволяют соответствовать критериям воспроизводимости результатов работы модели и на раннем этапе диагностировать качество сервиса модели. 

Стандартизировать процесс разработки моделей на стороне DS

Важный аспект конвейера: нужно, чтобы проект разработки строго соответствовал согласованной структуре, код соответствовал критериям PEP8, проходил автоматическую проверку (линтинг) и был задокументирован.

Бесшовно интегрировать этапы разработки и прототипирования моделей с процессами продуктивизации

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

Построить конвейер данных

Мы планируем постепенный переход от практики использования широких и специализированных витрин к промышленному решению Feature Store, которое сейчас у нас разрабатывается. Переход от управления жизненным циклом витрин к управлению ЖЦ каждой фичи модели позволит переиспользовать наработки DE/DS, ускорить процесс Feature Engineering, снизить стоимость эксплуатации модели за счет переиспользования фичей и удаления неиспользуемых фичей из промышленного контура.

Автоматизировать процессы повторного обучения, дообучения и внедрения в ПРОМ новой версии модели

Эти пайплайны обучения и внедрения будут реализованы на базе промышленной AutoML-платформы собственной разработки. 

Интегрировать управление и оркестрацию MLOps-конвейера в систему управления моделями

В промышленной эксплуатации в ВТБ уже есть система управления моделями, и для нас важно интегрировать в неё функционал MLOps-конвейера. 

На данном этапе детальная архитектура конвейера находится на стадии разработки и зависит от результатов продолжающихся R&D-исследований. 

Настоящее нашего проекта: уходим от магии к ресайклингу

Переходим от планирования к воплощению нашей архитектуры в жизнь. В части ML-задач еще предстоит постепенно ломать представление, в первую очередь, заказчиков о создании ML-систем. Для них это своего рода искусство и магия, к которой неприменимы никакие стандарты разработки ПО. Придется свыкаться с мыслью, что внедрение AI-составляющей в системы — обычная практика, и ее можно (и нужно) поставить на поток. Мы не отбираем элемент творчества у Data Science. Просто избавляем его от рутины тех задач, которые могут делать инженеры и конвейеры.

Второй серьёзный перелом в работе Data Science — все наработки по моделям мы будем максимально переиспользовать. От признаков до конвейеров. Не должно быть моделей, в которых толково разбирается лишь один уникальный бесценный специалист.

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

Почему? MLOps, как и DevOps, не может работать без соблюдения ряда правил и соответствующей культуры создания продукта. Так что ещё одна из наших командных задач — привить эту культуру всем и каждому.

Планы на будущее

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

Более глобальная цель — инициализировать MLOps-конвейер и цепочку сквозного деплоймента в ПРОМ. Модель, наконец-то, будет разворачиваться автоматически, как и любой софт у айтишников. 

Когда мы этой цели достигнем, обязательно напишем об этом на Хабре. А пока — задавайте свои вопросы, оставляйте комментарии, делитесь опытом в сфере MLOps-практик.