Highload MLOPs: ускорение и автоматизация / Павел Николаев (Альфа банк)

Выступление посвящено обзору централизованной платформы машинного обучения Альфа-Банка, которая, по мнению докладчика, является лучшей на рынке. Спикер имеет 15-летний опыт работы в банковской сфере, начиная с Райффайзенбанка. Ключевым достижением в ранней карьере стала разработка комплексной модели принятия решений для физических лиц в UniCredit, которая функционирует уже более десяти лет.

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

Инфраструктура банка отличается централизованным подходом: около 85% всех моделей Альфа-Банка работают в данной экосистеме. Она включает централизованный Data Lake Hub, который мигрирует на решение S3, а также Feature Store (супермаркет фичей). Над ними располагается MDP (Model Development Platform) — единая среда для разработки, где работают 95% дата-сайентистов банка.

В качестве примера рассматривается стандартная бизнес-модель склонности юридического лица к использованию бизнес-карт. Эта модель использует около 500 факторов (фичей) на лонг-листе, а в шорт-лист для инференса уходит 14 фичей. Объем обучающей выборки составляет порядка 40 ГБ, а таргет-рейт крайне мал, менее 1%.

Основная цель проекта — сокращение Time to Market, где банк, по оценкам консультантов, является лидером, внедряя пакетные и онлайн-модели в среднем за 2-3 дня. При этом сохраняется высокий уровень качества и отказоустойчивости, так как системы относятся к уровню Mission Critical. Вторая важная цель — экономичное расходование ресурсов, поскольку нет возможности вкладывать столько же средств в "железо", сколько конкуренты.

Уровень стабильности моделей и отказоустойчивости — это 2-й уровень Mission Critical систем.

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

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

Разработка базовой модели через бейзлайн теперь является обязательной историей для любой стандартной модели. Если качество автоматически разработанной модели устраивает, дата-сайентист может не продолжать собственную разработку. Бейзлайн также используется как инструмент альтернативного моделирования для валидации.

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

Автоматический инструмент можно хоть переобуть. Здесь мы протестировали это на реальных данных на примере похожей модели склонности четыре раза в год.

Несмотря на гордость за каскадные модели пакетного вывода, существуют серьезные нюансы, связанные с использованием Apache Airflow. Основные минусы включают проблемы с ролевой моделью и Active Directory, что затрудняет нормальную изоляцию DAG. Это приводит к риску изменения расписания одного хаба человеком из другого хаба моделирования.

Супер-пупер каскадная библиотека, реализованная на Airflow, оказалась очень тяжелой в поддержке, неповоротливой, и ее работа сопровождается проблемами с отказоустойчивостью. Хранение логов и списка DAG на едином сетевом хранилище (PVC Long Horn) несет высокие риски при масштабировании.

Техлиды прорабатывают переход на Argo Workflow, который позволяет конфигурировать DAG через YAML-файлы, что проще, чем работа с огромной библиотекой Airflow. Argo также упрощает постановку на шедулер через UI и, что критически важно, обеспечивает более простую работу с деплоем на предыдущие версии (откат).

Для упрощения деплоя и масштабирования внедрена многоконтурная среда (Dev, Load Test, Integration Test, Prod). Ранее модель собиралась целиком, что приводило к переполнению артефактов и зависаниям. Сейчас используется выделение базовых образов, привязанных к версии Python (например, 3.8 для лучшей работы со Spark DataFrame).

В отличие от пакетных моделей, где важен вывод большого количества моделей, для онлайн-моделей принятия решений (например, выдача кредита) критична многомодульность. Стандартная практика — строить несколько моделей в зависимости от источников данных (внешние кредитные истории, арбитражи). Это позволяет убрать модуль, если источник данных выходит из строя, не переобучая весь ансамбль.

Реализация многоуровневой архитектуры онлайн-моделей выполнена как набор микросервисов в Kubernetes. Каскады управляются через Argo, а архитектура задается через Python SDK FastAPI. Обмен данными между микросервисами происходит через брокер сообщений. Выбор пал на Redis вместо RabbitMQ, поскольку микросервисы обмениваются маленькими сообщениями (результатами работы).

Redis отвечает за многопоточность, асинхронность и работу в фоновом режиме. Классная библиотека.

В среде разработки (MDP) возникает проблема конкуренции за ресурсы, поскольку каждый дата-сайентист хочет выделенное железо, что приводит к простоям. Для решения этой проблемы был доработан стандартный Spawner JupyterHub. Изначально были только профили (Малый, Средний, Большой), но они не позволяли точно выделять ресурсы, например, 60 ГБ RAM.

Доработка позволила выбирать точное значение ресурсов ползунками. Видеокарты Tesla также делятся пополам, наиболее удобный объем для работы с LLM составляет 40 ГБ. Стандартный объем для 80% задач — 16 виртуальных CPU и 200 ГБ оперативной памяти. Для более требовательных задач используются выделенные ноды в общем кластере.

Текущая проблема заключается в необходимости полной перезагрузки JupyterHub для внедрения изменений в настройках (например, новых версий Python или правил распределения видеокарт), что сложно согласовать при наличии 200 пользователей. Рассматриваются два пути: глубокое сохранение сессий по примеру Сбера или написание собственного UI с переходом на Argo, что кажется более перспективным.

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

Мы как инфраструктура предоставляем пайплайн, чтобы он мог свои методы применять автоматизированно.

В части оптимизационных алгоритмов (суррогатная оценка качества, метаоптимизация) пока используются базовые библиотеки. В будущем планируется использование LLM для автоматизации разметки данных, где ручные асессоры будут сверять результаты, а также для автоматизации Code Review, что уже пилотируется.