![](https://habrastorage.org/getpro/habr/upload_files/22d/7d1/ecf/22d7d1ecfdcdb0ffacbac8d2d2f6b956.png)
Нет ещё в мире 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-конвейера Типовая архитектура MLOPS-конвейера](https://habrastorage.org/getpro/habr/upload_files/480/0bb/e1b/4800bbe1ba5a5cb24ba820d233e10a11.png)
Как видите, структура и компоненты 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-практик.