Всем привет!

На связи команда Advanced Analytics GlowByte и сегодня мы разберем валидацию моделей. 
Иногда термин «валидация» ассоциируется с вычислением одной точечной статистической метрики (например, ROC AUC) на отложенной выборке данных. Однако такой подход может привести к ряду ошибок.

В статье разберем, о каких ошибках идет речь, подробнее рассмотрим процесс валидации и дадим ответы на вопросы:

1. на каком этапе жизненного цикла модели проводится валидация? Спойлер: это происходит больше одного раза;
2. какие метрики обычно применяются при валидации и с какой целью?
3. почему важно использовать не только количественные, но и качественные метрики?

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

Расширяем понятие валидации

Что не так с валидацией как вычислением одной точечной статистической метрики на отложенной выборке данных?

Аргумент против № 1: одна метрика не может учесть все аспекты качества модели. Качество модели измеряется не только предсказательной способностью, но и, например, стабильностью во времени.

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

Аргумент против № 3: точечная оценка может варьировать в зависимости от состава валидационной выборки, особенно это касается не сбалансированных выборок (с соотношением классов 1:50 или более значимым перекосом). Поэтому стоит дополнительно делать интервальные оценки.

Аргумент против № 4: актуальные данные могут отличаться от исторических, на которых была построена модель, поэтому валидацию стоит делать и на актуальном срезе данных.

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

Валидация и жизненный цикл модели 

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

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

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

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

На этапе внедрения проводится два вида проверок. 

1. Верификация — подтверждение качества модели на актуальном потоке данных и дополнительная проверка репрезентативности данных, использованных при разработке модели.
   
2. IT-валидация — аудит набора скриптов с реализацией модели посредством проверки кода на обработку пропусков, дубликатов и других артефактов данных для снижения риска неожиданного поведения модели. Дополнительно проверяется качество документирования кода. Для этого необходимо заранее подготовить спецификацию. Это документ, который полностью описывает применение модели (порядок запуска скриптов, шаги каждого алгоритма). Он необходим для синхронизации всех сторон (бизнес, разработчики модели, занимающийся внедрением IT-отдел). Когда у вас есть на руках спецификация, вы проверяете, соответствует ли ей код проекта, а также достаточно ли в коде комментариев для воспроизводимости.
   

На этапе эксплуатации развернутой модели проводятся регулярные проверки двух видов: мониторинг и валидация.

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

Методика валидации

Все используемые при валидации тесты можно разделить на две группы: количественные и качественные. 

В качестве артефакта по результатам валидации предоставляется отчет:

• перечень тестов, отвечающих за отдельные аспекты качества модели (речь о них пойдет далее);
  
• результат каждого теста в отдельности и интегрально по блокам в виде риск-зон.
  

Риск-зоны — это цветовая маркировка результатов тестов, с помощью которой проще оценивать результат всех тестов в совокупности. Для маркировки используем следующие цвета: красный — низкое качество модели и высокий риск при ее использовании; желтый — удовлетворительное качество; зеленый — хорошее качество.
 
Рассмотрим детальнее список тестов для моделей бинарной классификации на примере модели прогноза вероятности дефолта (PD-модели) по кредитному договору (подробнее о PD-моделях см. [1]).

Количественная оценка

К группе относятся расчеты метрик и статистические тесты, которые оценивают качество модели на разных этапах и разных уровнях (перечисляем не все, возможны и другие). 

1. Дискриминационная способность модели

После разработки модели первый вопрос, который интересует бизнес-заказчика: а насколько хорошо модель справляется со своей задачей? Если мы построили PD-модель, то этот вопрос звучит так: насколько хорошо модель отделяет клиентов, которые уйдут в дефолт, от тех, кто в дефолт не уйдет, и насколько лучше эта модель, чем случайное угадывание? 

Чтобы ответить на это вопрос, проводим тесты:

• коэффициент Джини (подробнее рассмотрен под катом);
• Information value;
• критерий Колмогорова–Смирнова.

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


2. Оценка стабильности

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

Примеры тестов:

• Population Stability Index (PSI);
• критерий Колмогорова–Смирнова.

3. Калибровка

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

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

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

• точность уровня калибровки по всему портфелю;
  
• биномиальный тест (подробнее рассмотрен под катом);
  
• критерий Хосмера–Лемешова.
  

4. Концентрация

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


Для проверки концентрации используется индекс Херфиндаля–Хиршмана как в целом по выборке, так и в разрезе отдельных сегментов.


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

• При положительной корреляции с качеством модели красный сигнал выставляется при значениях ниже первого порога (столбец «Красная»), желтый – при значениях от первого до второго (столбец «Жёлтая») порога, зеленый – при значениях выше второго порога.
• При отрицательной корреляции с качеством модели красный сигнал выставляется при значениях выше первого порога, желтый – при значениях от первого до второго порога, зеленый – при значениях ниже второго порога.

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


Мы перечислили тесты, применимые к моделям в разных доменных областях. Но могут быть метрики, которые отражают специфику конкретного продукта. Например, при моделировании операционных рисков может быть установлено дополнительное ограничение, связанное с пропускной способностью подразделения, проводящего расследования по признанным моделью подозрительными наблюдениям. После того как модель присвоила скоры всем пользователям, топ 1% или 5% пользователей по скору передается для проверки такому подразделению, другие пользователи не будут проверяться. Поэтому необходимо, чтобы максимальное число клиентов с y_true=1 попали в топ 1% или топ 5%.  

Также для отдельных моделей могут быть предусмотрены специфические тесты. Например, для LGD-моделей Loss Shortfall.

Качественные тесты

Не все аспекты качества модели можно оценить количественно, поэтому вместе с ними при валидации применяются качественные тесты. Что можно проверять с их помощью?

1. Качество документации модели. Для обеспечения воспроизводимости модели необходима хорошая документация.

Оценить качество документации можно, определив, насколько хорошо задокументированы:

• задачи, решаемые моделью; 
  
• пайплайн работы модели; 
  
• параметры модели и атрибуты для формирования прогноза.
  

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

2. Дополнительно можно проверить качество использованных при разработке данных: 

• обоснован ли выбор факторов модели (одномерный или многомерный анализ)?
  
• соответствует ли глубина исторических данных нормативным требованиям?
  
• соответствует ли определение целевого события нормативным требованиям?
  

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

Заказчик может дополнительно запросить интерпретацию модели: если это регрессионная модель, то коэффициенты факторов; если decision tree/decision list, то набор правил; если более сложные модели, то отчет интерпретаторов SHAP/LIME.

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

Model performance predictor (MPP)

В определенных задачах бывает необходимо прогнозировать события, которые произойдут спустя месяцы. Например, клиент  не выполнит свои обязательства по кредитному договору в течение года. Из-за этого лага возникает проблема: как понять, что модель стала хуже работать, до того как мы сможем увидеть это, до получения фактических значений целевого события? 


Для решения такой проблемы наряду с основной строится дополнительная модель — Model Performance Predictor (MPP) [6].

Схема обучения MPP-модели 

Для разработки MPP-модели используется тестовая выборка основной модели. Шаги по построению MPP-модели.

1. Для каждого наблюдения из тестовой выборки выполняется скоринг «основной» моделью.
   
2. На основе прогноза и истинного значения рассчитывается целевая метрика для каждого наблюдения: например, абсолютная ошибка для задачи регрессии или метрика G-score (аналог интегральной метрики Джини, рассчитываемый по координатам наблюдения на ROC-кривой) [7] для задачи бинарной классификации. 
   
3. Модель MPP обучается с использованием метрики из п. 2 в качестве целевого события (при этом используя те же атрибуты, что и основная модель).
   
4. Обученная MPP-модель в дальнейшем используется совместно с основной для предсказания метрик качества по наблюдениям, которые участвуют в скоринге. Согласно предсказанным MPP-моделью значениям целевых метрик определяется качество предсказаний основной модели.
   

Преимущества такого подхода:

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

Заключение

В завершение сформулируем принципы, которые гарантируют, что валидация модели будет эффективна: 

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

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

Бинарное целевое событие:
Небинарное целевое событие:Материал подготовили: Илья Могильников (EienKotowaru), Александр Бородин (abv_gbc)

Список использованных терминов и сокращений

• Дефолт – невыполнение обязательств по договору займа. Обычно дефолтом считается неоплата по договору в течение 90 дней.
• PD – probability of default – вероятность дефолта.
• EAD – exposure at default – кредитные обязательства по договору на момент дефолта. По сути, баланс на дату дефолта, где баланс = Тело долга + Просрочка.
• LGD – loss given default – доля EAD, которую клиент не возвращает на горизонте восстановления.
• Калибровка – мета-модель, предназначенная для корректировки прогноза основной модели в соответствии с актуальным уровнем дефолта (PIT – Point In Time) или уровнем дефолта за экономический цикл (TTC – Through The Cycle).

Ссылки

[1] ML и DS оттенки кредитного риск-менеджмента.
[2] Коэффициент Джини. Из экономики в машинное обучение.
[3] ML и DS оттенки кредитного риск-менеджмента | LGD, или Жизнь после дефолта.
[4] An introduction to the Poisson bootstrap. The Unofficial Google Data Science Blog.
[5] Yurdakul, Bilal. Statistical properties of population stability index. Western Michigan University, 2018.
[6] Ghanta S. et al. {MPP}: Model Performance Predictor. 2019 {USENIX} Conference on Operational Machine Learning (OpML 19).
[7] Котерева Д., Афанасьев С., Стародуб К. MPP-challenge: моделирование прогноза качества модели//Риск-менеджмент в кредитной организации, №4/2020.