Всем читателям Хабра привет! На связи дата сайентисты стрима разработки моделей для корпоративного сегмента банка ВТБ — Андрей Бояренков, Иван Кондраков, Станислав Арешин и Андрей Трушин.

В этой статье мы хотим поговорить про конкретный кейс разработки процесса AutoML для моделей оценки вероятности дефолта клиентов (PD) в рамках экспресс-продуктов малого бизнеса. Расскажем, как выстроен наш процесс, как мы к этому пришли, с какими проблемами столкнулись, как их решили и как в дальнейшем планируем тиражировать на другие продукты банка.

Когда нужен AutoML

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

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

AutoML как автоматизация всего сквозного процесса моделирования

AutoML можно рассматривать в разных вариантах. Самое простое решение — интегрировать возможность автоматического построения модели в библиотеку разработки. Например, в нашем стриме разработки моделей для корпоративного сегмента реализованы и активно развиваются две библиотеки: Scorekit для построения линейных моделей и Autobinary для «деревянных» моделей. По Autobinary наши коллеги ранее публиковали цикл статей (1 часть; 2 часть; 3 часть), советуем ознакомиться!

В обеих библиотеках есть методы для оптимизации процесса разработки: auto_logreg и FullLearnPipeline соответственно. Безусловно, это облегчает разработку, позволяет в короткие сроки получить хорошее бейзлайн решение. Но это всего лишь первый шаг к выстраиванию сквозного процесса.

Часто мы видим, что многие двигаются по пути, когда для бизнес-аналитиков разрабатывается NoCode инструмент для построения моделей определенного сегмента с использованием определенного алгоритма, что позволяет не ждать, когда освободится разработчик. И тут в нашем стриме тоже есть опыт создания подобных решений как на библиотеке Scorekit, так и на Autobinary. Однако, эти инструменты скорее предназначены для быстрой проверки гипотез и не подходят для реализации промышленного решения.

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

Создание витрин по каждому домену данных, единой широкой витрины с лонг-листом факторов и целевой переменной

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

Для моделирования были выбраны следующие домены данных: «Кредитная история», «Транзакционные данные» (как ИП и как физического лица), «Арбитражные дела».

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

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

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

Реализация runner скрипта для обучения и калибровки моделей на основе конфигурационного файла

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

Текущий процесс основан на логистической регрессии по стандартному пайплайну: предобработка данных, однофакторный анализ, WOE биннинг, многофакторный анализ.

Однако, создание PD (Probability of Default) модели довольно кастомная задача, необходимо в процессе учесть все требования заказчика. Для этого мы подготовили runner скрипт с конфигурационным json файлом, в котором можно настроить каждый шаг пайплайна моделирования. Мы можем влиять на процесс отбора факторов: варьировать параметры биннинга, отсечки по метрикам PSI (Population stability index), p-value, корреляции и т.д.

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

• Строится логрег скора на таргет, коэффициент b приравнивается полученному коэффициенту при скоре, коэффициент a, затем подбирается солвером для попадания в ЦТ при фиксированном b;

• Рассчитываются веса наблюдений и строится логрег скора на таргет с весами, a и b приравниваются коэффициентам логрега;

• Коэффициенты рассчитываются минимизацией заданной функции через вызов scipy.optimize.minimize (fun = fun, x0 = x0, args = args, method='nelder-mead').

Следующий неотъемлемый шаг разработки — валидация модели. Мы подготовили определенный набор тестов, основные из них: тесты на стабильность gini по выборкам, монотонность биннинга, тест Колмогорова-Смирнова, корреляции, VIF (Variance inflation factor). По каждому тесту модели автоматически валидируются, по ним проставляются сигналы (зеленый, желтый, красный), формируется отчет и добавляется к перечню артефактов.

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

По итогу отработки скрипта формируется архив со следующим перечнем артефактов моделей:

• статистика по данным (описательные статистики, динамика таргет рейта, динамика флагов доступности доменов данных, информация по дублям и т.д.);

• актуальные срезы данных (ИНН, отчетная дата, таргет, дата последнего обновления) для возможности восстановить вычисления спустя некоторое время;

• отчеты о разработке (по однофакторному и многофакторному анализу);

• отчеты по калибровке;

• отчеты о валидации;

• рассчитанный финансовый эффект;

• json и py файлы моделей;

• логи процесса обучения.

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

Методология расчета финансового эффекта и ее имплементация

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

Финансовый эффект рассчитывается по новым разработанным моделям на основе заявок и выдач по предыдущим версиям моделей, включая текущую модель. Оценки финансового эффекта вновь разработанной модели и текущей модели производятся на основе дефолтов, по которым при рассматриваемом уровне одобрения (AR — Approval Rate) выдача не была бы произведена.

Расчет финансового эффекта производится по формуле

где в качестве LGD (Loss given default) и EAD (Exposure at default) — используются средние % суммы по портфелю от бизнес-аналитиков, N – сумма выдач на основе данных по бизнес-плану, k — коэффициент, который рассчитывается как отношение суммы дефолтных выдач, для которых PD разработанной модели > cut-off по заданному уровню одобрения (AR), к общей сумме исторических выдач.

Оценка эффекта осуществляется следующим образом:

1. Отбираются все заявки и созревшие выдачи;

2. Производится скоринг данной выборки (возможно использовать выборку для обучения новой модели);

3. Определяются cut-off по PD (Probability of Default) для каждого уровня одобрения от 0% до 100% с заданным шагом, например, 5%;

4. Определяется количество и сумма выдач, по которым был зафиксирован дефолт, и которые были одобрены предыдущими версиями моделей, но получили бы отказ по рассматриваемой модели (новой модели AutoML) по каждому уровню одобрения (Approval Rate);

5. Рассчитывается коэффициент k как отношение суммы дефолтных выдач к общей сумме выдач;

6. Рассчитывается итоговое значение финансового эффекта по формуле: ФЭ=N*k*LGD*EAD;

7. Сравнивается итоговое значение финансового эффекта вновь разработанной модели AutoML и текущей модели при одном и том же уровне одобрения (Approval Rate).

Таким образом, в результате формируется таблица следующего вида при шаге уровня одобрения (Approval Rate) в 5%:

*Расчет производился на синтетических данных для иллюстрации

Интеграция с общебанковским сервисом AutoML и с платформой исполнения моделей (ПИМ)

Итак, почти все необходимые наработки готовы. Теперь необходимо объединить все и превратить этот процесс в промышленный. У нас в банке есть команда, занимающаяся опромышливанием AutoML и у них есть свой сервис. Также в процессе задействована платформа исполнения моделей (ПИМ). Ключевым этапом для построения сквозного процесса автоматического моделирование является настройка и отладка взаимодействия между этими сервисами.

Взаимодействие между ПИМ и сервисом AutoML настроено через Rest API. Запуск обучения происходит в ПИМ через Rest запрос к сервису AutoML с передачей конфигурационного файла. Сервис AutoML инициирует SQL запрос через Hive Connector для получения данных из промышленной широкой витрины. Затем внутри сервиса поднимается контейнер с runner скриптом. Модели запускаются на обучение, полученные артефакты обучения в виде архива передаются обратно в ПИМ через S3.

Разработка User Interface (UI)

Из NoCode решений мы поняли, что пользовательский интерфейс — очень удобный инструмент для аналитики полученных результатов как со стороны DS, так и со стороны аналитиков от заказчика, поэтому для данного проекта также было решено разработать свой кастомный UI.

Интерфейс реализован в контуре ПИМ, так как это стартовая и финишная точка всего нашего процесса. Ниже описан функционал, который мы заложили в наш UI:

• Инициализация процесса. Инициализация процесса происходит через UI по триггеру от разработчика/заказчика. На этом этапе также передается конфигурационный файл;

• По результатам построения моделей в UI визуализируются артефакты обучения моделей;

• Есть возможность выгрузить необходимые отчеты;

• Есть отдельное хранилище с результатами предыдущих запусков процесса;

• Реализован функционал выбора итоговых моделей и передача на промышленное тестирование и внедрение.

Бизнес или аналитики могут самостоятельно посмотреть аналитику по данным, на разницу в Джини по моделям, на результаты расчета финансового эффекта и выбрать модель которая интересна, а затем прямо из UI запустить ее внедрение.

Реализация процессов автоматического тестирования на промышленных данных и процесса автоматического внедрения

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

Чтобы было понятно, как мы считаем факторы, расскажем коротко о том, как устроен скоринг. Скоринговый конвейер малого бизнеса (СКМБ) подает Rest запрос в ПИМ с данными по заявке для расчета скора. К заявочной информации также прилагается внешняя и внутренняя кредитная история. Формат json файлов совпадает с тем форматом, на котором считалась кредитная история для широкой витрины, соответственно, можно переиспользовать скрипты расчета факторов и на лету из запроса СКМБ автоматически рассчитать необходимые для модели фичи. Что касается остальных доменов, они обновляются в проме ежемесячно, поэтому в ПИМ регулярно делаются репликации актуальных срезов этих витрин, а уже из них факторы модели универсальным селектом подтягиваются к заявке по ИНН и отчетной дате.

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

Итоговый процесс AutoML

Мы постарались максимально подробно описать, как на практике мы вели наш проект, теперь давайте еще раз резюмируем: как в итоге по шагам выглядит промышленный процесс AutoML.

1. Раз в месяц осуществляется запрос на разработку по расписанию либо вручную пользователем;

2. Загружается файл конфигурации для обучения модели. Из широкой витрины через Hive Connector загружаются все заявки, выдачи, дефолты и факторы;

3. Запускается runner скрипт для обучения моделей;

4. Артефакты обучения возвращаются в UI;

5. Аналитик со стороны заказчика анализирует результаты моделей. Для того чтобы принять решение о внедрении AutoML модели в прод Джини модели >3% в абсолюте + экономия на дефолтах, т.е. каким из дефолтных клиентов мы отказали бы по новой модели;

6. По решению заказчика выбирается модель, которая отправится на внедрение;

7. Проводится доп.тестирование — сравниваем, что не совершили ошибок при внедрении;

8. 3–4 недели модель работает в Shadow режиме, чтобы понять, что все метрики соответствуют тем, которые были на разработке (AR, средний PD);

9. Если все ок, заказчик переключает процесс принятия решений на обновленную модель.

Пройдя этот путь, наша команда пришла к следующим выводам:

• Ускорение разработки модели происходит в разы, так как позволяет провести полный цикл разработки модели от анализа исходных данных до валидации и подготовки кода для применения. Если раньше разработка и внедрение модели занимали от 3 до 6 месяцев, сейчас мы можем сделать это в течение 5 дней;

• В результате автоматизации рутины разработки теперь можно больше времени уделять RnD задачам;

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

• Данный процесс планируем тиражировать на другие направления: модели оценки кредитных рисков/модели по комплаенсу, модели CRM/жизненного цикла клиента.

Спасибо за уделенное время! Если появились вопросы – welcome в комментарии, мы обязательно на все ответим. Еще увидимся!