Об этом рассказал Алексей Рустамов из Loginom Company на встрече Data&Science в Яндексе. Его компания уже лет 20 занимается анализом данных, в частности, кредитным скорингом, на примере которого и строится рассказ. Оказалось, что основная причина низкого проникновения ML - недоверие заказчика к моделям. Но этого можно избежать.
Большая часть популярных задач машинного обучения связана с проблемами поиска, рекомендаций, обогащения данных, анализа изображений, перевода, и игр. С другой стороны, в России более 80% бизнеса - это "традиционная экономика": сырьё, транспорт, строительство, торговля, финансы, банкинг. Задачи у них иные - оптимизация запасов, управление рисками, производство, логистика, клиентская лояльность. И ситуация с анализом данных там достаточно плохая. Почему же имеющиеся потребности не покрываются уже доступными алгоритмами?
Для современных датасайнтистов важно построить модель посложнее и пооригинальнее, желательно с нейросетями, но бизнесу нужно иное - модель поинтерпретируемее. Определение data mining от Пятецкого-Шапиро - обнаружение в сырых данных ранее неизвестных , полезных, нетривиальных и интерпретируемых фактов, приносящих практическую пользу. Бизнес не готов применять чёрные ящики, потому что цена ошибки там очень большая, и доверять доверять системам там не очень могут.
Основа доверия- предсказуемость: осознание ограничений, понимание всех проделанных при построении модели шагов, аргументация каждого из них, тестируемость, и нормальное поведение модели в граничных и нестандартных случаях. Если не сделать систему предсказуемой, её не внедрить. Поэтому надо стараться делать из чёрных ящиков белые, или хотя бы серые. Разберём на примере кредитного скоринга, как это вообще возможно.
Сперва банки использовали для кредитования жёсткие правила, придуманные экспертами, и доверие им было высокое. Потом начали использовать generic модели - они обычно выдаются кредитным бюро, и доверие к ним определяется доверием к авторитету бюро. Следующий шаг - индивидуальные модели каждого банка и, возможно, кредитного продукта. Доверие тут появляется из-за того, что клиент очень тесно взаимодействует с исполнителем в процессе построения, и видит, как модель создаётся на его глазах. И последний этап развития - промышленное построение моделей - пользуется доверием уже не к отдельным формулам, а к процессу их подбора.
Вместе с формулой и кодом заказчику можно передавать паспорт скоринговой модели - доказательство её адекватности. Он документирует всю историю создания, а потом и использования модели. Это такой талмуд на десятки, а иногда и сотни страниц.
Как готовятся данные
- Описываем статистические показатели: пропуски, выбросы, аномалия, дубли. Описываем их с точки зрения бизнес-логики: недостоверные и несогласующиеся друг с другом данные.
- Исключаем некоторые атрибуты, если на то есть причины: плохая статистика, данные из будущего (например, поведенческие данные для аппликационного скоринга), несоответствие бизнес-требованиям. Для каждого атрибута надо предоставить объяснения.
- Обработка редких значений: можно исключить записи, можно работать как с пропусками, можно заменять по заранее оговоренному правилу. Для каждого случая главное объяснить, почему мы так делаем.
- Порождение атрибутов (feature engineering) - производные и агрегации имеющихся атрибутов, и кросс-характеристики. Все формулы и правила формирования каждого атрибута надо описать.
- Отдельно надо описать обязательные атрибуты (по требованиям документооборота, законодательства, бизнес-процессов, или "значимые" с точки зрения рисковиков банка - чтобы последние были уверены, что мы их учли).
- Очень важно определить и аргументировать целевую переменную (что такое вообще дефолт?). Есть случаи, когда заказчик считал оттоком одно, а клиент - другое, и уже построенная модель выкидывалась. Чтобы такого не происходило, целевую переменную надо фиксировать с самого начала.
- Получив данные, надо описать формирование обучающего и тестового множеств, и описать расписание фич и целевой переменной в разрезе этого разбиения.
Вот сколько всего нужно сделать и задокументировать, и это мы ещё даже не приступали к моделированию. Кажется, это очень отличается от того, как проходят соревнования на Kaggle.
О моделировании
Для моделирования можно отбирать атрибуты, опираясь, например, на корреляции, WoE, и IV. Последние две аббревиатуры - способы измерить, насколько классификатор с единственным категориальным признаком даёт лучше, чем модель без признаков вообще, с точки зрения правдоподобия.
Моделировать стоит с традиционного алгоритма - логистической регрессии, ибо она знакома рисковикам, легко интерпретируется, и её можно использовать как бейзлайн. Потом можно построить что-нибудь более сложное, скажем, градиентный бустинг над деревьями, но надо будет ещё доказывать, что он лучше логистической модели.
Уже построив модель, важно чётко описать логику выбора порога отсечения - это определяется исходя из бизнес-задачи. Впрочем, лично в моём опыте достаточно было строить скоринговую модель, которая хорошо ранжирует заёмщиков, а уж какую бизнес-логику на неё вешать, заказчику виднее.
Обучив классификатор, надо измерить его качество: джини, рок-аук, колмогоров-смирнов, и всё прочее. Чем больше разных метрик, тем лучше.
Построив модель, нужно сделать для неё и мониторинг - описать его регулярность, правила расчёта индикаторов, и логику оповещения в случае разных необычных обстоятельств. Если за этим не следить, модель может тихо умереть и никому не сказать. Были случаи, когда модель, потерявшая предсказательную силу, несколько лет продолжала функционировать, и в этом заказчик обвинил её создателя. Мониторинг нужен, чтобы такого не происходило, и доверие к модели сохранялось.
Финальная проверка - модель должна соответствовать экономическому смыслу, и не вызывать отторжения экспертов.
Итак, что повышает доверие:
- указание области применимости и ограничений модели
- объяснение всех преобразований данных (часто всякие кэглеры этим не занимаются, ибо привыкли работать с готовыми данными)
- правила обработки граничных случаев (чем больше подушек безопасности, тем лучше)
- объяснение логики отбора факторов
- объяснение самой подогнанной формулы, даже если это что-то сложнее линейной модели
- тестирование модели на отдельных кейсах
- расчёт индикаторов качества
- проверка на соответствие бизнес-логике
Доверие необходимо взращивать постепенно: от маленьких и понятных моделей и алгоритмов к большим и сложным, тогда цена ошибки не будет стоп-фактором.
Классический пример глупого провала - чатбот от Майкрософта, который меньше чем за сутки стал нацистом. Чтобы доверие к модели было, надо сначала придумать тесты и аргументы, которыми мы будем оперировать, и потом уже думать, как построить модель, которая бы этим требованиям удовлетворяла.
Один из вариантов убеждения заказчика - проверка на исторических данных. Другой вариант - A/B тесты (в банках говорят champion-challenger), это относительно дешёвый способ убедить людей в качестве применения модели, чтобы потом переключиться на новую модель полностью.
Q: Cколько признаков входит в типичную скоринговую модель, и какая у неё обычно предсказательная сила?
A: Типично в финальной модели используется не так много переменных: в обучении их могут быть сотни и тысячи (включая множество производных), но после довольно жёсткого отбора остаются 20-30 показателей. Приемлемые значения AUC для разных задач скоринга (аппликационный, коллекторский, поведенческий) - свои; они есть у нас на сайте.
Q: Есть ли в России законодательные ограничения на использование переменных, как в Америке?
A: Может быть и есть, но докладчик никогда с этим не сталкивался.
Q: Обязательно ли использовать логистическую регрессию?
A: Не обязательно, но её точно не следует выкидывать из рассмотрения.
Q: Как презентуются результаты модели заказчику?
A: Тот самый паспорт.
Q: И за счёт чего внешним компаниям удаётся побить имеющиеся у клиента модели?
A: Или за счёт низкой базы (у маленьких банков), или за счёт внешних данных и более качественной предобработки.
Другие доклады с того же мероприятия раскрыли несколько смежных тем:
- Как выбрать схему ценообразования ML-проекта? Стоит ли привязывать его стоимость к затратам или результату, или оставить фиксированной?
