Привет, Хабр! Я работаю в команде Devim, которая развивает систему принятия решений в отношении заемщиков кредитов. Накопилось достаточное количество практических знаний в этой сфере, поэтому решил с вами поделиться частью.

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


Рассмотрим два сценария:

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

Итак, вот несколько способов сломать скоринговую модель.

Сценарий 1

Способ №1 — внести изменения на сайт

• Изменить дизайн страницы выбора суммы и срока кредита
  
• Изменить дефолтное значение сумма/срок кредита при заходе на сайт
  

Способ №2 — создать отдел маркетинга

Необходимо, чтобы в МФО был создан отдел маркетинга. При очень частом появлении новых кредитных продуктов, изменении процентных ставок, маркетинговых акций «первый займ бесплатно», скоринговые модели не смогут адекватно работать длительный период.

Сценарий 2

Способ №3 — уничтожить данные (желательно платные)

• Перезатереть данные кредитной истории клиента от предыдущих обращений
  
• Перезатереть данные анкеты клиента от предыдущих обращений
  

Способ №4 — сделать отличающийся интерфейс ввода данных в разных каналах подачи заявки и устройствах (онлайн, оффлайн, Android, Iphone)

Способ №5 — добавить сценарий заполнения поля базы данных и не задокументировать это

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

Способ №6 — нанять data science специалиста

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

Разберем более подробно каждый способ.

Дизайн страницы выбора суммы и срока кредита

Вот так выглядит главная страница сайта, где клиент выбирает сумму и срок кредита. Обратите внимание на количество вкладок и диапазон сумм на каждой вкладке.
 

После того, как первую и вторую вкладку объединили в одну, часть заявок из диапазона 2-10к переместилось в диапазон 11-20к. Для бизнеса это хорошо с точки зрения среднего чека.


Распределение запрашиваемых сумм до и после изменений
Справа — крупный масштаб

По историческим данным, собранным во время работы старой версии сайта, в данных есть линейно отрицательная зависимость между запрашиваемой суммой займа и вероятностью невозврата. По клиентам, запросившим суммы 11-20к, вероятность невозврата меньше. Даже при ручном андеррайтинге наблюдается более высокий уровень одобрения. Это подтверждает гипотезу о том, что заемщики, подававшие заявку со второй вкладки, в среднем лучше. Для обученной модели это означает, что запрос суммы 11-20к характеризует заемщика как хорошего. Однако, после объединения вкладок уровень одобрения при ручном рассмотрении у таких заявок снизился, а вероятность невозврата возросла. Модель же продолжила считать таких заемщиков как хороших, что привело к снижению качества скоринга в этом диапазоне. Решением проблемы было перестроение модели на тех же данных, но без признака «сумма».
 
По займам, которые успели выдать старой моделью на новой версии сайта, проводился разбор ошибок модели. Большая часть из них была связана с тем, что заемщик с очень плохой кредитной историей должен был получить отказ, но указав сумму 20000 получал «накрутку» к своему скору и получал одобрение на минимальную сумму 2-3к.
 
Наличие связи между большой запрошенной суммой и низкой вероятностью невозврата странно. Есть предположение, что бОльшие суммы запрашивают люди с более высоким уровнем дохода. А на отдельную вкладку 11-20к (возможно) переходили люди, которым действительно нужна была именно такая сумма и они знали, что смогут ее погасить.

Дефолтное значение сумма/срок кредита при заходе на сайт

Давайте рассмотрим как влияет значение бегунка «сумма» на распределение запрашиваемых сумм. При заходе на сайт, значение слайдера выбора суммы установлено на 7000 р. — картинка слева, 8000 р. — картинка справа.



Видно, что количество запросов на кредит какой-то определенной суммы (7к или 8к) сильно возрастает, если установить бегунок по умолчанию на это значение.

При наличии зависимости между сдвигом бегунка (осознанного выбора нужной заемщику суммы) и риском невозврата, модель, основанная на деревьях, найдет эту зависимость в данных в признаке сумма займа. Даже без создания специального признака «совпадает ли выбранная сумма со значением бегунка по умолчанию». Алгоритм создает правило «если сумма больше 6к, но меньше 8к — заемщик плохой». В случае изменения дефолтного значения бегунка на сайте,  это правило будет работать некорректно. Решением проблемы является отказ от использования этого признака, либо создание дополнительного признака — «совпадает ли выбранная сумма со значением бегунка по умолчанию».

При анализе новой модели, которая не использует признак «сумма займа», мы построили зависимость среднего скора от суммы займа.
 


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

Перезатереть данные кредитной истории клиента

При подаче заявки на кредит в бюро кредитных историй направляется платный запрос. В ответе содержится подробная информация о том, как клиент выплачивал другие кредиты, допускал ли просрочки, размер, тип кредитов и т.д. Довольно часто клиенты берут займ в МФО больше, чем один раз. При повторном обращении в бюро также направляется запрос, т.к. финансовое положение заемщика могло измениться. Архитектор баз данных, андеррайтеры и другие лица, которые каким-либо образом работают с кредитной историей, решают, что хранить кредитную историю о предыдущих обращениях не имеет смысла, т.к. она занимает место на жёстком диске, а смотреть ее никто не будет. Создают две таблицы ORDERS и CLIENTS. В ORDERS записываются данные о заявке, в CLIENTS — о клиенте. КИ помещается в таблицу CLIENTS. При каждом новом обращении КИ перезаписывается. Для датасаентиста это означает, что он получает смещенную выборку для обучения. В базе остаются КИ о клиентах, которые либо взяли займ один раз и не вернули. Либо взяли один раз и не стали постоянными клиентами. Информация о первой заявке самых ценных клиентов, которые стали постоянными, недоступна.

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

Интерфейс ввода данных в разных каналах подачи заявки

При подаче заявки на кредит клиент заполняет анкету, в которой указывает ежемесячный доход. Давайте посмотрим, как выглядит распределение значений дохода в зависимости от канала подачи заявки. По х — id заявки, по у — доход.



На сайте установлен выпадающий список. А когда заявка приходит из партнерской сети, поле может быть заполнено произвольным значением. Аналогичная ситуация происходит при заполнении заявки в оффлайн — офисе. Если не заметить этот факт при разработке скоринговой модели, то модель будет оценивать вероятность невозврата с использованием признака «доход» в зависимости от того, в каком соотношении были данные каналов партнеры/сайт/оффлайн в тренировочном наборе. Решение проблемы — не использовать признак «доход». Либо делать дискретизацию значения признака для канала «партнеры» и «оффлайн» в такие же интервалы, как указано на сайте (что не очень хорошо, т.к. способ ввода все-таки другой). Или же делать на сайте поле ввода и ждать, пока накопятся данные.

Отдел маркетинга

В компании несколько продуктов:
PDL займы — кредиты на сумму от 2 до 20к, которые нужно закрыть одним платежом.
Installment займы — займы на сумму от 21 до 100к. В момент, когда клиент подает заявку, в зависимости от того, новый это клиент или повторный, от региона и прочих факторов, маркетинг определяет, какой продукт ему можно и нужно дать. В параметры продукта входят минимальные/максимальные суммы и сроки займов. Изначально, определение продукта проводилось после скоринга. Т.е. в скоринговую модель подавались суммы и срок, указанные клиентом. В какой-то момент определение продукта начало происходить до скоринга. И указанные клиентом данные автоматически подменялись на «нужные» и подавались в скоринг. Это привело к ухудшению качества скоринга. Решение проблемы — возврат к прежней логике определения продукта.

Ошибки data science специалиста

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



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

Давайте посмотрим, как выглядит частотное распределение цели займа в срезах онлайн/оффлайн.

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

Вернемся к признаку «сумма займа». Специалист по анализу данных решает использовать сумму займа из заявки на кредит. В качестве метода был выбран алгоритм, основанный на деревьях решений (случайный лес / градиентный бустинг). После первых экспериментов с моделями по графику feature importances выяснилось, что признак «сумма займа» самый сильный. Интуитивно более сильные признаки не вышли в топ. После анализа возможных причин, было установлено, что поле «сумма займа» перезаписывается после одобрения займа. Это происходит в случаях, когда кредитный специалист одобряет меньшую и «неровную» сумму займа. Таким образом в данные закрался data leak, который так часто встречается в соревнованиях по анализу данных. Решение проблемы — дополнительное поле в БД, в которое пишется изначально указанная сумма.
 
Но и это еще не все. Давайте посмотрим на частотность «неровных» сумм займа в зависимости от канала заявки.
 

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

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

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

Заключение

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

1. Берите данные под полный контроль, старайтесь выстроить end-to-end систему. Чем короче путь от исходного источника данных до вашего сервиса со скоринговой моделью, тем лучше. Любая прослойка в виде дополнительных сервисов предобработки / хранения данных только навредит.
   
2. Проводите анализ признаков во времени. Это можно сделать с помощью графика scatter plot, по оси х — id записи. А также путем анализа среднего значения признака во времени. Train и test лучше разделять и по времени, и по объектам (клиентам).
   
3. Обращайте внимание на нелогично сильные признаки. Возможно, в них утечка.
   
4. Проводите анализ линейной взаимосвязи признака и целевой переменной (даже при построении нелинейных моделей). Направление тренда должно быть логичным.
   
5. Если хочется получить логичные взаимосвязи и устойчивую модель, дискретизируйте денежные переменные до целых значений. Бывает, что корреляция с другими признаками закрадывается в «неровность сумм» или в копейки.
   
6. Проводите анализ данных и качества моделей в различных срезах. Диапазон сумм, сегмент клиентов, источник заявки — онлайн/оффлайн. Старайтесь добиться примерно одинакового качества модели в каждом срезе. В случае значительных изменений соотношений срезов в трафике, будет ухудшение показателей, т.к. качество модели было изначально оптимизировано под более крупные сегменты.
   
7. Избегайте автообновления моделей при появлении новых данных. В этом случае будет легче проводить ретро анализ причин ошибок модели (в статье не раскрыто, возможно, в будущем).
   
8. Использование данных анкеты дает не сильный прирост в качестве к варианту использования только данных бюро. Поэтому использовать этот источник лучше на последних этапах, когда выстроена внутренняя инфраструктура сбора и хранения данных.
   
9. Налаживайте коммуникации с другими отделами. Каждый отдел (не только программистов-разработчиков) должен иметь журнал изменений, в котором отражены все изменения с кратким описанием и датой. Даже те, которые на первый взгляд кажутся абсолютно неважными для скоринга. Журнал изменений поможет выявить причинно-следственные связи.
   

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