Сервис по автоматической разработке и внедрению нейронных сетей в банковской сфере

Нейросети в банковских задачах

Эволюция кредитного скоринга в Альфа-Банке. До 2005 года в компании решение о выдаче или невыдаче кредита принималось вручную. В 2005 году появились нейросети, которые работают с логистическими регрессиями. В 2017 году компания перешла к моделям градиентного бустинга, а в 2022 году нейронные сети впервые значимо и стабильно превзошли их по точности прогноза.

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

Чтобы строить бустинговые модели, данные нужно агрегировать. Например, брать сумму трансакций за последний месяц или самую большую трансакцию за последний месяц. Если же использовать нейросетевые подходы, то можно проводить минимальную предобработку и подавать данные на вход модели as is.

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

По состоянию на конец 2023 года наиболее проработанные источники данных:

• Карточные трансакции
• Трансакции расчётного счёта, например оплата ЖКХ или обучения
• Кредитные истории

Нейросетевые модели на этих данных уже успешно применяются в основных банковских задачах:

• Кредитный скоринг ФЛ/ЮЛ
• Склонность к продуктам ФЛ
• Предсказание оттока ФЛ

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

Почему плохо разрабатывать модели вручную

Мы оказались перед выбором: продолжить создавать модели вручную или попытаться автоматизировать этот процесс.

Чтобы понять недостатки ручной разработки, рассмотрим жизненный цикл модели. Разработчикам нужно:

• Определить тип задач — бинарная классификация, многоклассовая классификация, регрессия или Uplift
• Собрать выборку с целевой переменной
• Собрать данные из N доменов (карточные трансакции, чеки, кредитные истории)
• Обучить модель на каждом домене
• Обучить метамодель
• Вывести N+1-модель в промышленную среду

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

Для внедрения модели нужно:

• Переписать её код на некоторый шаблон
• Провести код-ревью
• Провести функциональное нагрузочное тестирование, чтобы убедиться в отказоустойчивости и стабильности моделей
• Собрать Docker-образ с кодом
• Выкатить образ в промышленную среду

Чтобы повторить процесс для каждого домена данных, потребуется 3–4 недели и силы 2–3 дата-сайентистов.

Появляются проблемы:

• Формат работы дата-сайентиста становится скучным и унылым. Вместо того чтобы писать код, нужно снова и снова переписывать одни и те же архитектуры и оттачивать мастерство вывода BarPlot в Matplotlib.
• У дата-сайентистов не остаётся времени на проведение полноценных исследований. Максимум — склонировать репозиторий и сравнить работу его архитектуры с имеющейся.

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

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

При этом был ряд ограничений: сделать это быстро, минимизируя использование ресурсов дата-сайентистов и команд сопровождения, а также избавить DS от рутинной механической работы.

Сервис ANNA

В 2023 году разработали MVP такого сервиса — ANNA.

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

Что нужно иметь для использования сервиса. Пользователь должен предоставить тип задачи, метрику, которая больше всего соответствует решаемой задаче, и выборку обучения. В выборке мы задали стандарт из трёх полей: идентификатор клиента, дата сбора данных и целевая переменная в задаче.

Компоненты сервиса ANNA. Основные компоненты сервиса: данные, модельный код, бэкенд и пользовательский интерфейс. Дальше разберём подробнее эти компоненты.

Данные для нейросетей

Данные нужны для автоматического обучения моделей. Из-за большого объёма и частого обновления их предобработка и подготовка к обучению моделей занимает много времени.

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

В случае карточных трансакций это витрина с полями «идентификатор клиента», «временная дата», «временная метка транзакции» и «N закодированных фичей, которые описывают транзакцию».

В итоге получается автоматизированная подготовка данных.

Пайплайны обучения, инференса и ретроинференса

Архитектура моделей для обучения. Мы разрабатываем модели на последовательностях, каждый элемент которых описывается набором категориальных и вещественных признаков. Категориальные признаки отображаем в вектор с помощью Entity Embeddings. Векторные представления конкатенируем и подаём на вход кодировщику — это может быть рекуррентный слой или трансформер.

Поверх кодировщика работает полносвязный слой. Из него получаем числовой вектор, который можно считать эмбеддингом клиента по этому домену данных.

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

Мы стандартизировали код моделей и обернули его в библиотеку, которую можно использовать для решения новых задач, передав в неё набор конфигов. Технически это реализовано в виде веток и тегов на гите — при создании новой задачи в Git делаем ветку от master и создаём коммит. В нём передаются параметры задачи: тип и метрика. И уже внутри этой ветки для каждого нового запуска создаётся новый коммит с параметрами запуска, который помечается соответствующим тегом.

Бэкенд

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

Данные хранятся в виде витрин на Hadoop. Их можно использовать, если получить из Kubernetes доступ к Hadoop и выдать учётную запись с правами на чтение витрин.

Мы хотим обучать каскад моделей, но делать это последовательно долго. Нужно оркестрировать запуски, чтобы параллельно обучались сначала базовые модели, а после этого — модель смешивания. Для этого используем Airflow, который вдобавок позволяет задавать расписание запусков моделей.

Для сборки образов в Registry используем Jenkins. Он вытягивает код из Bitbucket, собирает образ и сохраняет его в хранилище. Затем создаёт и запускает соответствующий DAG в Airflow.

Для сохранения весов и других артефактов по модели используем MLFlow.

Функции бэкенда. В итоге реализовали бэкенд на FastAPI с базой на Postgres. Он:

• Хранит информацию о задачах, выборках и моделях
• Параметризует код для решения каждой конкретной задачи
• Запускает пайплайны в Jenkins
• Мониторит статус ранов в Airflow, чтобы корректно отображать статус разработки в интерфейсе
• Получает аналитику по моделям из MLFlow, чтобы корректно отображать её в интерфейсе

RabbitMQ. При использовании ANNA для каждого запроса поднимается под в Kubernetes. Если их число вырастет, ресурсы оркестратора закончатся. В итоге пользователи не смогут обучать модели в сервисе, потому что он не контролирует потребление ресурсов Kubernetes и Hadoop.

Решение — добавить в сервис очередь. Используем RabbitMQ, который будет запускать не более N ранов одновременно. Например, одновременно пришло шесть запросов, а размер очереди — три. Тогда пода в Kubernetes поднимутся для трёх запросов, а остальные будут ожидать освобождения ресурсов. Когда под завершится, из очереди забираем следующий запрос и запускаем его на Kubernetes. Таким образом, в сервисе ANNA обеспечили отказоустойчивую работу сервиса на ограниченном количестве ресурсов.

Пользовательский интерфейс

Интерфейс реализован на Vue.js и Nginx, обёртка над REST API. В планах — привлечь фронтендеров, чтобы они сделали интерфейс более доброжелательным и симпатичным.

Результаты

После внедрения сервиса появились:

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

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

Планы на будущее

Мы планируем развивать сервис:

• Добавить NAS — подбор оптимальной архитектуры для каждой конкретной задачи
• Интегрировать с другим сервисом Альфа-Банка Auto ML для бустингов
• Раскатать его на весь банк, чтобы другие команды без специальных компетенций в ML также могли пользоваться сервисом
• Внедрить в MMS (Model Management System)
• Ускорить обучение и инференс — внедрить кеширование и предобученные чекпойнты

Считаем, что трендом прикладных индустрий станет появление сервисов по автоматизации рутины, в компании такие уже появились:

• Сервис AutoML
• Сервис анализа внешних источников
• Сервис суммаризации
• Автоматическое обновление моделей чат-бота

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

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

Следить за развитием нашего проекта можно в телеграм-каналах Alfa Advanced Analytics и Нескучный Data Science.