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

Что проверяют

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

Как отвечать

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

Дальше разделите задачи:

• ранжирование: модель должна ставить надёжных клиентов выше рискованных. Стандарт индустрии здесь ROC AUC и производный от него коэффициент Джини Gini = 2 * AUC - 1, иногда статистика KS. Эти метрики не зависят от порога и позволяют сравнивать модели;
• решение: на выбранном пороге важны доля одобренных заявок (approval rate) и доля дефолтов среди одобренных (bad rate). «Точно выявить тех, кому выдавать» на языке метрик означает высокую точность по классу хороших клиентов, то есть низкий bad rate;
• калибровка: если вероятность дефолта (PD) идёт в ценообразование и расчёт ожидаемых потерь EL = PD * LGD * EAD, нужна не только верная сортировка, но и правильные вероятности. Их проверяют через log loss, Brier score и калибровочные кривые.

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

Где спотыкаются

Называют accuracy. При доле дефолтов в несколько процентов модель, одобряющая всех подряд, получает высокую accuracy и при этом бесполезна.

Говорят, что ROC AUC «не зависит от дисбаланса», и на этом останавливаются. При редком классе AUC может выглядеть высоким при слабой точности, поэтому рядом смотрят PR-кривую и метрики на рабочем пороге.

Забывают про особенности данных: исход известен только по одобренным заявкам (проблема reject inference), а проверять модель нужно на более позднем периоде (out-of-time), а не на случайном разбиении.