Привет, я Андрей Качетов, Head of ML Operations в Альфа-Банке. Отвечаю за опромышливание всех ML-моделей в банке, строю новую платформу MLOps, а также формирую единый подход для работы с модельными данными (Feature Store).

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

Зачем нам нужен MLOps?

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

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

Здесь и появляется необходимость в конвейере. 

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

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

 Результат в MLOps обеспечивается совокупностью факторов:

• качество входных данных (зависит от Дата-Инженеров – Data Engineers, DE);

• разработка ML-модели (зависит от «моделистов» — Data Scientists и DS);

• разработка и развертывание ML-решения (за это отвечают ML-инженеры);

• управление инфраструктурой (здесь «правят» DevOps-инженеры).

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

Схематично платформа для автоматизированной разработки ML может выглядеть так. 

 С такими платформами работают DS, DE и MLE «в комплексе».

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

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

• ML Engineer разворачивает модели машинного обучения в промышленной среде.

Отчасти ML-инженеры – это специалисты на стыке между моделистами (DS) и разработчиками. У нас в команде MLOps их сегодня 6. Но так было не всегда.

Как было до экосистемы?

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

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

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

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

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

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

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

Как строилась экосистема ML в банке

Ускорить разработку и развертывание ML-моделей помогла созданная с нуля платформа, на которой можно:

• вести трекинг ML-экспериментов;

• оптимизировать параметры ML-моделей;

• создавать и запускать пайплайны;

• и организовывать инференс (код исполнения).

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

Для этого у нас сейчас есть:

• СРМ или MDP (Model Development Platform — Среда Разработки Моделей): новый флагман модельной разработки в банке, база для модельной разработки в банке.

• СИМ (Система Исполнения Моделей): оптимизирует и ускоряет процессы вывода моделей в промышленную эксплуатацию, включая их тестирование (в проме сейчас уже 60 моделей).

• Feature Store (в едином хранилище Hadoop — более 100 ТБ данных), как настоящий маркетплейс фичей, которые используется моделями машинного обучения и аналитиками банка.

Это наша экосистема ML в банке.

Все три системы разрабатывались параллельно. СИМ разрабатывали с участием команды вендора, а MDP и FS – силами внутренних команд.

СИМ: Система Исполнения Моделей

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

Обсуждались все детали: 

• что будет делать подрядчик (решили, что берёт на себя всю разработку системы);

• каким должно быть архитектурное решение;

• что использовать из лучших практик с рынка с минимальными издержками (какие фреймворки, какие подходы, какой софт);

• какие функциональные области необходимы;

• как и кем будут настраиваться стенды (подрядчик или внутреннее ИТ, на ком лидерство) и пр. 

Параллельно шёл тендер на выбор поставщика услуг. 

Ещё важно учесть, что сама по себе СИМ никому не нужна, если с ней не могут работать. Поэтому чуть больше квартала ушло на то, чтобы встроить СИМ в IT-процессы банка. Зато сейчас, когда СИМ уже в проме, любой пользователь внутри банка может запросить результат вычисления ML-модели и применить его в своем процессе. Доступ к разработанным моделям предоставляется по API-сервису: запрос к модели идет через определенный URL (в него включено имя приложения и версия API), и она даёт на него ответ. 

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

После запуска СИМ скорость внедрения моделей теперь составляет 3-4 недели. Новая цель — ускориться еще больше и дойти до показателя в 4-5 рабочих дня.

СРМ: Среда Разработки Моделей

Среда разработки моделей (MDP) — программно-аппаратный комплекс для разработки и обучения моделей ML. В СРМ есть всё для разработки: Kubernetes, фреймворки, библиотеки, хранилка, Jupiter Notebook, VS-код, пайплайны CI/CD через Jenkins, Cassandra для горячего хранения. В этой среде можно подключиться к единому хранилищу данных (КХД), разработать, запустить и протестить код, который будет работать в бою также — ведь среды разработки и исполнения полностью идентичные.

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

Платформа разрабатывалась внутренней командой. Решение было построено примерно за 8 месяцев — на базе единого JupiterHub и MLflow. Ещё несколько месяцев занял процесс выстраивания сквозного технологического единения систем с СРМ. Наша среда разработки просто космолет, и чтобы он полетел надо его тонко настроить. 

Feature Store

Feature Store — это и система, и новая парадигма непрерывной доставки данных для разработки моделей. В неё входят 3 компонента:

• FS ETL — единый процесс создания фичей.

• FS Registry — визуализация метаинформации о фичах.

• FS Datamart — единый интерфейс получения фичей (здесь реализован поиск и есть «витрина» доступных фичей).

Её разработка заняла чуть больше года, и ей полностью занималась внутренняя команда MLOps. На сентябрь 2021 года это всего 3 человека: два разработчика и техлид (которые начали продвижение проектов СИМ и СРМ). Сейчас «МЛОпсов» уже 21: это и ML-инженеры, и DevOps’ы, и QA, и тимлиды. 

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

На платформе Feature Store DS’ы могут просматривать все имеющиеся признаки «в одном окне» и подбирать для себя нужные, а не создавать повторно дубли. 

Такое переиспользование существенно ускоряет работу с данными, их качество теперь проверено (и по сути гарантировано). Ну, и общий time-to-market разработки ML-моделей улучшается — пока до 3-4 недель, но есть потенциал ускориться вообще до одной.

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

Основные потребители Feature Store в банке: 

• Дата-инженеры — выполняют расчёт фичей и создают широкую выборку фичей для моделей.

• DS-специалисты — работают с данными и подбирают фичи для моделей. Если нужной им фичи нет — «заказывают» её появление в хранилище.

• ML-инженеры — используют фичи для упрощения вывода ML-моделей в пром.

• Аналитики — используют эталонные данные для целей бизнес-аналитики и оптимизации процессов.

Как это всё работает, или Сценарии использования СИМ, СРМ и Feature Store

• Допустим, DS понял, какая модель нужна и для каких бизнес-задач, посетил Feature Store и выбрал для себя нужные данные. 

• Если чего-то не хватило — дозапросил их у DE, чтобы тот собрал недостающие данные и поместил их также в Feature Store. 

• Дальше DS провёл исследование в MDP, подобрал алгоритм и подготовил код модели. 

• Если с кодом всё ок, то в этот момент DS ставит задачу на ML-инженера по выводу готовой модели в СИМ, на постоянный расчет.

• ML-инженер проводит код ревью, и если с моделью все ок, DS отправляет её к тестировщикам и деплой. 

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

• А если обнаруживаются какие-либо ошибки — отправляется на корректировки и доработки, после чего ещё раз тестируется.

Участие людей в этом процессе, благодаря новой платформе, стало минимальным. В целом, конвейер работает отлично, с его помощью выводится 50 моделей в квартал.

Что будет дальше?

Следующие наши шаги и планы на ближайшее будущее:

Подключение все большего числа пользователей к СИМ. Будет наращен объём данных, используемый моделями для работы, чтобы повысить точность их вычислений. А увеличение ресурсных мощностей системы позволит получать ответы за доли секунды, что значительно сократит время на принятие решений.

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

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

И, сделать мир ML лучше, конечно же :)

Как связаться со мной и узнать больше деталей:

• https://t.me/andriazol 

• https://www.linkedin.com/in/andrew-kachetov-9740aa60/

Рекомендованные статьи:

• Как улучшить ключевые метрики банка за счет кассовых чеков ОФД?

• Нейросетевой подход к моделированию транзакций расчетного счета

• Нейросетевой подход к кредитному скорингу на данных кредитных историй

• Как и зачем мы начали искать бизнес-инсайты в отзывах клиентов с помощью машинного обучения

• Багатон как в первый раз

• Как мы заняли первое место в хакатоне ВК «Машинное обучение на графах», где не было графов

• Как я участвовал в соревновании по машинному обучению и занял второе место (и почему не первое)

• Как мы участвовали в чемпионате по DS длиной 3,5 месяца

• Классификация кассовых чеков

• Знакомство с Apache Airflow: установка и запуск первого DAGа

• Не принимай оффер в Data Science, пока…

• Как я занял 13 место из 3500+ участников и стал Kaggle Competition Master

• Подкасты, книги, курс: подборка интересного по Data Science

• «Бесполезные» доклады о том, как кочегарить, инференсить и моделировать LTV: как прошёл Data Science Meet Up #2

• Как перестать волноваться и полюбить хакатоны

Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.