Постановка проблемы кредитного скоринга

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

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

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

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

Вкратце, деревья решений с градиентным усилением (GBDT) делят наших клиентов на группы по пороговым правилам и присваивают каждой группе постоянный балл. Высокий балл означает, что группа с большей вероятностью объявит дефолт; низкий балл указывает на надежных клиентов, которые вернут долг.

Проблема в том, что факторы со временем меняют свою силу – и даже свое значение.

Возьмем, к примеру, функцию «ровно три номера телефона в истории пользователя». Мы проверяли три года подряд: 2014, 2015, 2016. Средний уровень мошенничества в каждом году составлял 1%. Мы провели простую проверку роста: выбрали группу ровно с тремя телефонными номерами и рассчитали среднее целевое значение для каждого года. Результаты:

2014 г.: 1,5%
2015: 1%
2016: 0,5%

В 2014 году этот фактор был убедительным свидетельством более высокого риска мошенничества. В 2015 году он стал нейтральным. В 2016 году его полярность поменялась: он предложил более законного покупателя.

В следующий раз я расскажу о подготовке набора данных и о том, почему меня не устраивает Oracle PL/SQL.