Привет, я Андрей Качетов, Head of ML Operations в Альфа-Банке. Отвечаю за опромышливание всех ML-моделей в банке, строю новую платформу MLOps, а также формирую единый подход для работы с модельными данными (Feature Store).
В статье, без картинок с «бесконечностями» Ops’ов, расскажу, как может выглядеть полноценный конвейер MLOps, что может уметь и немного о том, как мы пришли к максимальной автоматизации процесса вывода моделей в промышленную эксплуатацию.
Зачем нам нужен 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-экспериментов;
оптимизировать параметры 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-моделей в пром.
Аналитики — используют эталонные данные для целей бизнес-аналитики и оптимизации процессов.
Ключевые вехи разработки экосистемы 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 выходят в ОПЭ и готовятся к эксплуатации. |
Как это всё работает, или Сценарии использования СИМ, СРМ и Feature Store
Допустим, DS понял, какая модель нужна и для каких бизнес-задач, посетил Feature Store и выбрал для себя нужные данные.
Если чего-то не хватило — дозапросил их у DE, чтобы тот собрал недостающие данные и поместил их также в Feature Store.
Дальше DS провёл исследование в MDP, подобрал алгоритм и подготовил код модели.
Если с кодом всё ок, то в этот момент DS ставит задачу на ML-инженера по выводу готовой модели в СИМ, на постоянный расчет.
ML-инженер проводит код ревью, и если с моделью все ок, DS отправляет её к тестировщикам и деплой.
Модель проходит функциональное, интеграционное и нагрузочное тестирование, и если на всех этапах отрабатывает корректно, выходит в прод.
А если обнаруживаются какие-либо ошибки — отправляется на корректировки и доработки, после чего ещё раз тестируется.
Участие людей в этом процессе, благодаря новой платформе, стало минимальным. В целом, конвейер работает отлично, с его помощью выводится 50 моделей в квартал.
Что будет дальше?
Следующие наши шаги и планы на ближайшее будущее:
Подключение все большего числа пользователей к СИМ. Будет наращен объём данных, используемый моделями для работы, чтобы повысить точность их вычислений. А увеличение ресурсных мощностей системы позволит получать ответы за доли секунды, что значительно сократит время на принятие решений.
Создание контура тестирования моделей с промышленными данными. Здесь необходимы, помимо технологических, и определённые организационные шаги, с внесением изменений в существующие производственные процессы банка. А значит, вопрос — какая часть на деле займет больше времени.
Автоматизировать процессы обучения, дообучения и внедрения в пром новой версии модели на базе AutoML (тоже наша собственная разработка).
И, сделать мир ML лучше, конечно же :)
Если есть вопросы — пишите в комментариях, обязательно отвечу. Если захотите связаться и/или узнать больше деталей — оставлю контакты: Телега и Линкедин.
Рекомендованные статьи:
Как улучшить ключевые метрики банка за счет кассовых чеков ОФД?
Нейросетевой подход к моделированию транзакций расчетного счета
Нейросетевой подход к кредитному скорингу на данных кредитных историй
Как и зачем мы начали искать бизнес-инсайты в отзывах клиентов с помощью машинного обучения
Как мы заняли первое место в хакатоне ВК «Машинное обучение на графах», где не было графов
Как я участвовал в соревновании по машинному обучению и занял второе место (и почему не первое)
Знакомство с Apache Airflow: установка и запуск первого DAGа
Как я занял 13 место из 3500+ участников и стал Kaggle Competition Master
Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.
