кредитный скоринг машинное обучение

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

Сейчас все очень много говорят про искусственный интеллект и его применение во всех сферах работы компании. Однако есть некоторые области, где еще с давних времён главенствует один вид модели, так называемый «белый ящик» — логистическая регрессия. Одна из таких областей – банковский кредитный скоринг.

Для этого есть несколько причин:

В этом посте мы расскажем о том, как при построении скоринга мы отказались от внешних data mining пакетов в пользу open source решения в виде Python, увеличили скорость разработки в несколько раз, а также улучшили качество всех моделей.

Процесс построения скоринга

Классический процесс построения скоринговых моделей на регрессии выглядит так:

Он может меняться от компании к компании, но главные этапы остаются постоянными. Нам всегда необходимо производить биннинг переменных (в отличие от парадигмы машинного обучения, где в большинстве случаев нужно лишь категориальное кодирование), их отсев по Information Value (IV), и ручную выгрузку всех коэффициентов и бинов для последующей интеграции в DSL.
Такой подход к построению скоринговых карт отлично работал в 90-е, однако технологии классических data mining пакетов сильно устарели и не позволяют использовать новые методики, такие как, например, L2-регуляризация в регрессии, которые позволяют значительно улучшить качество моделей.

В один момент в качестве исследования мы решили воспроизвести все этапы, которые аналитики делают при построении скоринга, дополнить их знаниями Data Scientist’ов, а также максимально автоматизировать весь процесс.

Улучшение в Python

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

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

В Python загрузить из базы собранные данные можно с помощью pymysql.

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

Теперь начинается самой важный этап в скоринге для регресии – необходимо написать WOE-binning для числовых и категориальных переменных. В открытом доступе мы не нашли хороших и подходящих для нас вариантов и решили написать сами. За основу числового биннинга взяли эту статью 2017 года, а также эту, категориальный написали сами с нуля. Результаты получились впечатляющими (Gini на тесте поднимался на 3-5 по сравнению с алгоритмами биннинга внешних data mining программ).

После этого можно посмотреть на графиках или таблицах (которые мы потом запишем в excel), как переменные разбились по группам и проверить монотонность:

Отдельно была написана функция для ручного биннинга, которая полезна, например, в случае с переменной «версия ОС», где все телефоны на Android и iOS были сгруппированы вручную.

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

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

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

Далее строилась регрессия и оценивались её метрики на кросс-валидации и тестовой выборке. Обычно все смотрят на коэффициент Gini (хорошая статья про него тут).

Когда мы удостоверились в том, что качество модели нас устраивает, необходимо записать все результаты (коэффициенты регрессии, группы бинов, графики стабильности Gini и переменных и т.д.) в excel. Для этого удобно использовать xlsxwriter, который может работать как с данными, так и с картинками.

Примеры листов экселя:

Итоговый excel в конце еще раз смотрится менеджментом, после чего отдаётся в IT для встраивания модели в продакшен.

Как мы увидели, почти все этапы скоринга можно автоматизировать так, чтобы аналитикам не нужны были навыки программирования для построения моделей. В нашем случае, после создания данного фреймворка от аналитика требуется лишь собрать данные и указать несколько параметров (указать целевую переменную, какие колонки удалить, минимальное количество бинов, коэффициент отсечения для корреляции переменных и т.д), после чего можно запустить скрипт на python, который построит модель и выдаст excel с нужными результатами.
Конечно же, иногда приходится исправлять код под нужды конкретного проекта, и одной кнопкой запуска скрипта при моделировании не обойдешься, однако даже сейчас мы видим качество лучше, чем у применяемых на рынке data mining пакетов благодаря таким техникам как оптимальный и монотонный биннинг, проверка на корреляцию, RFE, регуляризированная версия регрессии и т.д.

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

Источник

Решение задачи кредитного скоринга в студии Microsoft Azure Machine Learning

Резюме

Постановка задачи

Банк запрашивает кредитную историю заявителя в трех крупнейших российских кредитных бюро. Нам предоставляется выборка клиентов Банка в файле SAMPLE_CUSTOMERS (CSV). Выборка разделена на части «train» и «test». По выборке «train» известно значение целевой переменной bad — наличие «дефолта» (допущение клиентом просрочки 90 и более дней в течение первого года пользования кредитом).

В файле SAMPLE_ACCOUNTS (CSV) предоставлены данные из ответов кредитных бюро на все запросы по соответствующим клиентам. Формат данных из ответа бюро – информация о счетах человека, передаваемая другими банками в данное бюро. Подробно формат данных описан в файле ACCOUNT_DATA_FORMAT.

На выборке «train» необходимо построить модель, определяющую вероятность «дефолта», и проставить вероятности «дефолта» по клиентам из выборки «test».

Импорт набора данных в студию

Исходные данные представлены в формате CSV, однако студия правильно распознает CSV лишь с разделителями запятыми. Сохраним исходные файлы с информацией о клиентах SAMPLE_ACCOUNTS.CSV и SAMPLE_CUSTOMERS.CSV с требуемыми разделителями (для краткости SAMPLE_ACCOUNTS.csv был сохранен как Sdvch.csv) и загрузим их в azure.

Первичная обработка

SAMPLE_ACCOUNTS содержит 280942 строк и 28 столбцов, в каждой строке указана информация по одному кредиту. В столбце с идентификаторами клиентов содержится 50000 уникальных значений, значит каждому клиенту может соответствовать несколько строк. Отметим, что некоторые кредиты повторяются, а значения некоторых полей отсутствуют. Содержимое столбцов будет раскрыто далее в ходе решения задачи.

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

Первый скрипт, по сути, состоит из идей решения, о котором шла речь ранее. Вкратце расскажем их.
Шаг 1. Выкинем дублирующиеся кредиты (строки) из набора данных, оставив строку с самой последней информацией. Для этого определим набор столбов, который будет выступать в качества ключа, это: tcs_customer_id, open_date, final_pmt_date, credit_limit, currency (id, дата открытия кредита, предполагаемая дата последнего платежа, кредитный лимит, валюта); столбец inf_confirm_date (дата подтверждения информации по кредиту) будет определять, какой из дубликатов остается.

Шаг 2. Обработаем колонки: pmt_string_84m (своевременность платежей), pmt_freq (код частоты платежей), type (код типа договора), status (статус договора), relationship (тип отношения к договору), bureau_cd (код бюро, из которого получен счет). Посчитаем количество каждого уникального значения для каждого клиента и запишем эти значения в новые столбцы.

Шаг 3. Преобразуем поле fact_close_date, в котором содержится дата последнего фактического платежа, чтобы в нем содержалось только 2 значения: 0 — не было последнего платежа, 1 — последний платеж был.

Шаг 4. Переведем все кредитные лимиты к рублям. Для простоты берется курс 2013 года.

Шаг 5. Заполним пробелы в данных 0 и выполним заключительную группировку (с суммированием) по клиенту, при этом выкинем столбцы bki_request_date, inf_confirm_date, pmt_string_start, interest_rate, open_date, final_pmt_date, inf_confirm_date_max. Это значения дат и выплачиваемый процент с кредита.

Ниже приведен полученный набор данных.

Остановимся подробнее на втором скрипте. Мы предлагаем не просто просуммировать все кредитные лимиты для каждого клиента, а разделить всю сумму на две части: активный кредитный лимит, со значением статуса 00, и закрытый — со всеми другими статусами. Также введем еще один столбец с отношением суммарного активного лимита к — закрытому, если сумма закрытого лимита равна нулю, то поле заполним буквой A. Код второго скрипта приведен ниже.

Обработка средствами Azure

С помощью двух блоков «Add Columns» соединяем базы полученные в результате обработка скриптами с файлом SAMPLE_CUSTOMERS.

Далее делим выборку на две части с помощью блока «Split Data». Выбираем режим регулярного выражения и ставим условие на колонку «sample_type», нам нужны строки со значением «train».

С помощью блока «Project Columns» выбираем остающиеся для обработки колонки. Будем сравнивать два набора данных: слева со всеми полученными столбцами (кроме sample_type, он везде одинаковый «train»), справа без нашей модификации, то есть с исключением столбцов активного, закрытого лимита и их отношения (и sample_type).

Теперь добавим в проект еще одну пару модулей «Split Data». На этот раз используем псевдослучайное разделение строк на две части с заданным полем «random seed». Это нужно для того, чтобы разделение выборки на две части происходило одинаково для левой и правой базы. Процентное соотношение для обучения и тестирования 85% и 15%. Это объясняется тем, что в нашем случаем база с 50000 клиентами уже была поделена на две выборки train и test. По идее, мы должны были бы обучатся на 100% базы train и проставить результат в test, но поскольку мы обучаемся и тестируем на train, то соотношение было выбрано более благоприятным, чем обычное 75/25 или 80/20.

Для обучения модели будем использовать двухклассовое повышенное дерево принятия решений (двухклассовый бустинг) со стандартными значениями. Также добавляем модули «Train Model» и «Score Model». В «Train Model» указываем искомый столбец для прогнозирования bad.

Визуализация левого блока «Score Model».

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

На следующем скрине приведена визуализация блока «Evaluate Model», то есть результаты прогнозирования. Синия линия соответствует левой базе данных (со всеми полученными столбцами), красная — правой (с исключением столбцов с активным, закрытым лимитом и их отношением).

Заключение

Учитывая распределение мест проведенного турнира,

Источник

Оценка моделей кредитного скоринга

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

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

Используемые сегодня метрики оценки алгоритмов машинного обучения, такие как TPR (True Positive Rate), ROC-AUC (площадь под кривой ошибок, Receiver Operating Characteristic — Area Under Curve) или PR-AUC, обычно носят общий характер и не учитывают различий в значимости ошибок в случае конкретных применений алгоритмов. Например, в финансовой области при решении задачи скоринга — поиска банком ответа на вопрос о выдаче кредита или отказе в выдаче. Оценка модели скоринга проводится по результатам оценки с помощью конкретных моделей потенциальных заемщиков, обратившихся за кредитом в банк. Результатом для банка по каждому выданному кредиту является либо возврат кредита с процентами (банк получил прибыль), либо дефолт заемщика (банк получил убытки). Если по результатам работы модели было принято решение об отказе в предоставлении кредита, то банк ничего не заработал.

В сфере определения кредитных рисков применяются метрики: TPR — доля верно определенных дефолтных заемщиков; FPR (False Positive Rate) — доля неверно определенных надежных заемщиков. Для описания взаимосвязи этих метрик часто используется ROC-кривая (для хорошей модели кривая лежит в левому верхнем углу координатного пространства TPR-FPR, а график случайной модели — это прямая под углом 45 градусов). Площадь под кривой (ROC-AUC [1]) позволяет количественно оценить качество классификатора (ROC-AUC случайной модели равно 0,5): чем выше значение ROC-AUC, тем лучше оцениваемая модель (максимально возможное значение метрики равно 1).

Кроме того, часто используются: коэффициент корреляции Мэтьюса (MCC), оценивающий качество предсказания, который применяется, когда один из двух классов заемщиков (дефолтных и надежных) намного больше другого; и критерий Колмогорова — Смирнова (KS). Чем выше значение метрики KS, тем лучше модель разделяет дефолтных и надежных заемщиков. Площадь под графиком зависимости KS от параметра разбиения обозначается как KS-AUC.

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

Предлагаемая метрика качества (Метрика Прибыли) позволяет оценить финансовый результат банка и определяется как отношение фактически получаемого банком результата при использовании модели к максимально возможному результату:

где FP (False Positive) — количество надежных компаний, которым модель не выдала кредит, FN (False Negative) — количество дефолтных компаний, которым модель выдала кредит, и TN (True Negative) — количество надежных компаний, которым модель выдала кредит. Результат банка при использовании модели вычисляется как процент D от всех надежных заемщиков, которым модель выдала кредит, минус доля потерь при дефолте LGD [2] от всех дефолтных заемщиков, которым модель также выдала кредит. Максимально возможный финансовый результат определим так, что во всех случаях, когда заемщик не попал в дефолт, модель выдала кредит (банк получил прибыль) и при этом во всех случаях, когда заемщик попал в дефолт, модель кредит не выдала (банк ничего не потерял). Чем больше значение Метрики Прибыли, тем выше качество модели. Если Profit = 1, то модель имеет максимально возможную прибыль.

Данная метрика зависит от параметра разбиения. Площадь под графиком зависимости метрики от параметра разбиения обозначим Profit-AUC. При выполнении некоторых условий этот показатель полностью совпадает с KS-AUC, а сама Метрика Прибыли пропорциональна коэффициенту MCC. Принципиальное отличие от других метрик — это наличие необходимых условий (например, математическое ожидание дохода должно быть нулевым).

Для демонстрации эффективности Метрики Прибыли рассмотрим выборку из 1 млн заемщиков, данные по которым взяты из бухгалтерской отчетности Росстата за 2012–2019 годы [3], и сравним различные метрики качества. В Росстате имеется информация по финансовой отчетности предприятия за каждый год, и можно составить финансовую историю по каждой компании-заемщику (наличие метки дефолт).

Для предсказания дефолтов были использованы две наиболее распространенные модели классификации в задаче кредитного скоринга: SGDClassifier [4] и CatBoostClassifier [5]. Можно использовать любой другой алгоритм машинного обучения, позволяющий оценить вероятность дефолта для каждой компании, однако указанные модели максимально универсальны и чаще других показывают высокое качество классификации, в свзи с чем многие крупные банки сегодня их используют. SGDClassifier — это модель логистической регрессии со стохастическим градиентным спуском (для подсчета градиента ошибки на каждом шаге берется некоторое подмножество от общего количества объектов). За счет этого скорость обучения модели машинного обучения сильно сокращается, а итоговое качество мало отличается от полноценного классификатора. Модель CatBoostClassifier использует принцип бустинга: строится несколько моделей, каждая из которых пытается исправить ошибки предыдущих моделей. В данном случае в качестве базовой модели используется дерево решений.

Для всех метрик рассмотрим доходность по кредитам D = <15%, 20%, 25%>, долю потерь при дефолте заемщика LGD = 80%.

По ROC-кривой невозможно сказать, какой из алгоритмов — SGD или Catboost — лучше: площади под графиками практически совпадают, а сами графики пересекают друг друга.

Рис. 1. ROC-кривые для моделей SGD и Catboost. Штриховая линия — ROC-кривая для случайного классификатора

На рис. 2 приведены результаты по Метрикам Прибыли и коэффициенту MCC. Видно, что модель SGD предсказывает прибыль выше, чем модель Catboost, а значит, выбрав модель SGD, банк заработает больше, но прибыль не будет максимальной. При кредитовании под 15% разница практически незаметна (0,2% от значения максимальной прибыли), однако при условии 20% разница будет уже 1,7% от максимально возможного заработка. Также можно заметить, что максимум коэффициента MCC достигается примерно в том же диапазоне, что и максимум для прибыли при 15% кредитования.

Рис. 2. MCC и Метрики Прибыли для модели SGD (а) и модели Catboost (б) (точками указаны максимальные значения метрик)

Рис. 2. MCC и Метрики Прибыли для модели SGD ( а ) и модели Catboost ( б ) (точками указаны максимальные значения метрик)

Таким образом, согласно Метрике Прибыли, лучшей является модель кредитного скоринга SGDClassifier, предсказавшая более высокую доходность при одинаковых процентных ставках и потерях при дефолте, несмотря на небольшой проигрыш, получаемый при оценке на широко применяемой сегодня метрике ROC-AUC. Другими словами, при использовании модели SGDClassifier финансовая организация получит на 6% больше прибыли при кредитовании под 20% и на 1,2% больше при кредитовании под 15%, чем при использовании модели Catboost.

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

Литература

2. Пеникас Г., Алескеров Ф., Андриевская И. и др. Анализ математических моделей Базель II. — Litres, 2018.

3. Федеральная служба государственной статистики. Открытые данные. URL: http://www.gks.ru/opendata/dataset (дата обращения: 01.08.2020).

4. Tsuruoka Y., Tsujii J., Ananiadou S. Stochastic gradient descent training for l1-regularized log-linear models with cumulative penalty // Proceedings of the Joint Conference of the 47th Annual Meeting of the ACL and the 4th International Joint Conference on Natural Language Processing of the AFNLP. — 2009. — С. 477–485.

5. Prokhorenkova L. et al. CatBoost: unbiased boosting with categorical features // Advances in neural information processing systems. — 2018. — С. 6638–6648.

Источник

Как мы ломали скоринговую модель. Машинное обучение на практике

Привет, Хабр! Я работаю в команде Devim, которая развивает систему принятия решений в отношении заемщиков кредитов.
Расскажу о проблемах, с которыми мы столкнулись в процессе разработки скоринговых моделей и о том, как мы их решали.

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

№1 — Внести изменения на сайт

До изменений	После изменений

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

Распределение запрашиваемых сумм до и после изменений:

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

По займам, которые успели выдать старой моделью на новой версии сайта, проводился разбор ошибок модели. Большая часть из них была связана с тем, что заемщик с очень плохой кредитной историей должен был получить отказ, но указав сумму 20000 получал «накрутку» к своему скору и получал одобрение.

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

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

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

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

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

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

№2 — Слишком часто создавать новые продукты

№3 — Уничтожить данные (желательно платные)

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

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

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

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

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

№5 — Перезаписывать данные заявки после ее рассмотрения. Просачивание данных из будущего

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

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

№6 — Недостаточный анализ данных

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

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

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

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

Давайте посмотрим на частотность «неровных» сумм займа в зависимости от канала заявки.

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

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

Заключение

Источник