Привет, я Андрей Качетов, Head of ML Operations в Альфа-Банке. Отвечаю за опромышливание всех ML-моделей в банке, строю новую платформу MLOps, а также формирую единый подход для работы с модельными данными (Feature Store). В статье, без картинок с «бесконечностями» Ops’ов, расскажу, как может выглядеть полноценный конвейер MLOps, что может уметь и немного о том, как мы пришли к максимальной автоматизации процесса вывода моделей в промышленную эксплуатацию. Не говоря за ритейлеров или телеком-операторов, использование машинного обучения в банковских процессах — мастхэв, который приносит вполне осязаемую пользу, например, предсказывает вероятность дефолта.  Однако важна ещё и скорость «приземления» таких прогнозов и оценок на конкретные бизнес-процессы. Если компания может быстро обновлять модели, то она может быстрее реагировать на изменения рынка и поведения игроков, корректировать соответственно модели и стимулировать в итоге рост если не прибыли, то выручки. Time2Market сейчас во главе угла любой инновации.  Здесь и появляется необходимость в конвейере.  Автоматизация — традиционный способ повышать производительность команд разработки, а также оптимизировать издержки, снижать риски инцидентов и повышать устойчивость систем. Такой конвейер и есть MLOps — комплексное управление жизненным циклом моделей машинного обучения в промышленной эксплуатации (в продакшене). Если брать совсем грубо, то MLOps — это использование и некоторая адаптация DevOps-подходов применительно к работе с ML — процесс непрерывной поставки или промышленного развертывания моделей. DevOps — процесс непрерывной разработки ПО  MLOps = Machine Learning (Машинное обучение) + DevOps Процесс беспрерывной накатки кода в промышленную среду. Автоматизированное управление жизненным циклом ПО. Разработка (Development) + эксплуатационное сопровождение (Operations). Стандартизация непрерывной поставки/разработка и промышленное развертывание моделей 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-моделей; создавать и запускать пайплайны; и организовывать инференс (код исполнения).  Ну, и главное, — обеспечить возможность для переиспользования или воспроизведения обучения. Важно, чтобы процесс разработки моделей был стандартизирован на стороне 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 — это и система, и новая парадигма непрерывной доставки данных для разработки моделей. В неё входят 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-моделей в пром. Аналитики — используют эталонные данные для целей бизнес-аналитики и оптимизации процессов. Ключевые вехи разработки экосистемы ML кратко. Сентябрь 2021 — старт разработки СИМ выбранным вендором.  Ноябрь 2021 — обсуждение концепции Feature Store. Выбирая из разных вариантов (от Open Source решений до полностью кастомной разработки), сначала решили пропилотировать решение Feast с открытым кодом.  Декабрь 2021 — старт эксперимента с Open Source решением Feast — предшественником Feature Store. Неудачных экспериментов, как известно, не бывает, любой результат засчитывается — здесь мы столкнулись  с некоторыми сложностями с приземлением готового решения под свои потребности и бизнес-задачи.  Январь 2022 — запуск собственной разработки СРМ (будущей MDP). Февраль 2022 — проектирование необходимой инфраструктуры, закупка «железа» — bare-metal серверы с GPU. Закупка проходила не без проблем, удалось в итоге, как и всем, получить и запустить его только к сентябрю 2022. На серверах стоит Kubernetes, Jupiter, Grafana и т.д., которые настроены так, чтобы они могли работать с серверами, с GPU, с видеокартами, со средой для DS, как для разработки, так и для внедрения. Март 2022 — по итогам того самого декабрьского эксперимента решили отказаться от рыночных решений и вендорской разработки в пользу создания собственной платформы Feature Store. Чтобы точно соответствовать всем выявленным потребностям бизнес-пользователей.  Июль 2022 — СИМ выходит в опытно-промышленную эксплуатацию (ОПЭ), на dev среду начинают заезжать первые модели, выявлены и дорабатываются недочеты системы.  Октябрь 2022 — миграция команд DS на новую инфраструктуру ML. Ноябрь 2022 — СИМ переходит в промышленную эксплуатацию. Декабрь 2022-январь 2023 — СРМ и Feature Store выходят в ОПЭ и готовятся к эксплуатации. Допустим, DS понял, какая модель нужна и для каких бизнес-задач, посетил Feature Store и выбрал для себя нужные данные.  Если чего-то не хватило — дозапросил их у DE, чтобы тот собрал недостающие данные и поместил их также в Feature Store.  Дальше DS провёл исследование в MDP, подобрал алгоритм и подготовил код модели.  Если с кодом всё ок, то в этот момент DS ставит задачу на ML-инженера по выводу готовой модели в СИМ, на постоянный расчет. ML-инженер проводит код ревью, и если с моделью все ок, DS отправляет её к тестировщикам и деплой.  Модель проходит функциональное, интеграционное и нагрузочное тестирование, и если на всех этапах отрабатывает корректно, выходит в прод. А если обнаруживаются какие-либо ошибки — отправляется на корректировки и доработки, после чего ещё раз тестируется.  Участие людей в этом процессе, благодаря новой платформе, стало минимальным. В целом, конвейер работает отлично, с его помощью выводится 50 моделей в квартал. Следующие наши шаги и планы на ближайшее будущее: Подключение все большего числа пользователей к СИМ. Будет наращен объём данных, используемый моделями для работы, чтобы повысить точность их вычислений. А увеличение ресурсных мощностей системы позволит получать ответы за доли секунды, что значительно сократит время на принятие решений. Создание контура тестирования моделей с промышленными данными. Здесь необходимы, помимо технологических, и определённые организационные шаги, с внесением изменений в существующие производственные процессы банка. А значит, вопрос — какая часть на деле займет больше времени. Автоматизировать процессы обучения, дообучения и внедрения в пром новой версии модели на базе AutoML (тоже наша собственная разработка). И, сделать мир ML лучше, конечно же :) Если есть вопросы — пишите в комментариях, обязательно отвечу. Если захотите связаться и/или узнать больше деталей — оставлю контакты: Телега и Линкедин.  Рекомендованные статьи: Как улучшить ключевые метрики банка за счет кассовых чеков ОФД? Нейросетевой подход к моделированию транзакций расчетного счета Нейросетевой подход к кредитному скорингу на данных кредитных историй Как и зачем мы начали искать бизнес-инсайты в отзывах клиентов с помощью машинного обучения Багатон как в первый раз Как мы заняли первое место в хакатоне ВК «Машинное обучение на графах», где не было графов Как я участвовал в соревновании по машинному обучению и занял второе место (и почему не первое) Как мы участвовали в чемпионате по DS длиной 3,5 месяца Классификация кассовых чеков Знакомство с Apache Airflow: установка и запуск первого DAGа Не принимай оффер в Data Science, пока… Как я занял 13 место из 3500+ участников и стал Kaggle Competition Master Подкасты, книги, курс: подборка интересного по Data Science «Бесполезные» доклады о том, как кочегарить, инференсить и моделировать LTV: как прошёл Data Science Meet Up #2 Как перестать волноваться и полюбить хакатоны Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.  Head of ML Operations в Альфа-Банке