Введение
Естественным источником информации в банке о покупках клиента являются карточные транзакции – любые операции, проводимые по дебетовым или кредитным картам. При этом денежные операции клиента не ограничиваются транзакциями, проводимыми с помощью карт. Оплата ЖКХ, оплата образования, крупные покупки и другие денежные переводы – это примеры транзакций, которые никак не привязаны к карте клиента, но при этом они ассоциируются с другой банковской сущностью – расчетным счетом.
Про то, как мы в Альфа-Банке применяем карточные транзакции в моделировании, мы уже рассказывали в этом посте. Логичным развитием идеи использования карточной транзакционной истории клиента является использование данных, которые содержатся в клиентской истории транзакций расчетного счета. В область применения этих данных входит любая задача, где необходимо по клиенту банка предсказать некоторую целевую переменную.
Задача кредитного скоринга была выбрана первой мишенью для применения данных ввиду наибольшей прибыльности. Под задачей кредитного скоринга мы понимаем задачу бинарной классификации, в которой требуется предсказать, уйдет ли клиент в дефолт. Метрикой оценки качества является ROC-AUC.
Разработанный подход для решения задачи кредитного скоринга в дальнейшем легко переносим и на прочие банковские задачи: модели склонности, оттока и дохода.
Описание и предобработка данных
Каждая банковская карта привязана к расчетному счету, таким образом, множество карточных транзакций является подмножеством транзакций расчетного счета клиента. Возникает логичный вопрос — можно ли построить одну общую модель на транзакциях расчетного счета, включая карточные транзакции, и тем самым избавиться от дополнительной модели на карточных транзакциях?
Простой ответ: нет.
Основная мотивация заключается в том, что карточные транзакции содержат в себе значительно больше признаков по сравнению с произвольной транзакцией расчетного счета. Для карточной транзакции генерируется множество дополнительных признаков за счет того, что мы имеем привязку к терминалу, mcc-код покупки, место покупки и прочее. Транзакции расчетного счета имеют более бедное признаковое описание, но при этом терять информацию, хранимую в них, не хочется. В связи с этим мы приняли решение разрабатывать две отдельные модели на непересекающихся наборах данных: модель на карточных транзакциях и модель на транзакциях расчетного счета за исключением карточных.
Так какие же данные содержатся в произвольной транзакции расчетного счета?
Во-первых, это сумма транзакции, а также дата ее совершения. Дата является источником обогащения дополнительными признаками для каждой транзакции, к тому же с помощью нее операцией сортировки выстраивается правильная последовательность истории совершения транзакций клиентом. В силу более сложной организации процессов хранения всех совершаемых транзакций по расчетному счету на данный момент отсутствует информация о времени транзакции, что влияет как на отсутствие дополнительных признаков, связанных со временем, так и на корректную сортировку, если клиент совершал несколько транзакций в течение одного дня.
Отличительной особенностью транзакций расчетного счета от карточных транзакций является то, что клиент может выступать как отправителем, так и получателем транзакции, а иногда даже и тем, и другим, так, например, происходит в случае переводов самому себе. При сборе транзакционной истории мы берем транзакции всех типов, а также формируем дополнительный признак, сигнализирующий о «направлении» транзакции относительно клиента.
Перечисленных данных было бы крайне недостаточно для построения качественной модели. К счастью, с каждой транзакцией расчетного счета также ассоциируется текстовое поле: описание транзакции. Так выглядят примеры этих описаний:
Оплата ЖКХ ЛС 460000 Иванов Иван Иванович г. Иваново, ул. Кара01N 36 2100 4070281073120000000000000000 30101810000000000000
Снятие, ремонт и установка топливного бака на Мерседес А000АА11 НДС 200 2000 4070281073120000000000000000 30101810000000000000
Оплата за дизайн рекламной продукции (календари, ручки, пакеты, кружки01N
Оплата за отопление за Октябрь 2021 г. по счету N 1 от 01.10.2021 (01N280000 2200 4070281073120000000000000000 30101810000000000000
Как видно, информация, содержащаяся в этом тексте, может быть крайне полезна: она является неструктурированным аналогом mcc-категорий. Несмотря на более бедное признаковое описание, нельзя определенно утверждать, что транзакции расчетного счета содержат в себе меньше информации, чем карточные транзакции, просто эта информация менее структурирована и записана в едином текстовом поле.
Обработка описаний
Метод пристального взгляда и наше упорство привело нас к выводу, что в описаниях действительно содержится много важной информации о транзакции. Остается открытым вопрос, как использовать эту информацию по максимуму при моделировании.
Ввиду особенностей формирования данных описаний можно тщательно разобраться в этих процессах формирования и достать информацию либо в виде различных регулярных выражений, либо найти источники, из которых было «склеено» данное описание, и использовать уже эти данные как обычные категориальные признаки.
К сожалению, этот подход упирается в следующие основные ограничения:
Огромное количество бизнес-процессов банка, по-разному относящихся к логике формирования описания транзакции
Внешнее влияние на формирование данного поля. Например: произвольный пользовательский текст
Мы выбрали более простой и дата сайенс-ориентированный подход - обрабатывать описание как произвольный сырой текст. При этом все действия по предобработке направлены на решение похожей задачи: выделение важной информации, содержащейся в описании.
Предобработка описания:
Замена всех токенов, содержащих цифру, на специальный «unknown» токен <unk_tok>.
Во многих описаниях присутствуют цифры – это различные номера договоров, номера счетов, даты. Это шумная информация, которую мы решили заменить одним общим токеномВыделение токенов с фамилией и замена на <fio_tok>.
Часто в описаниях встречаются ФИО людей, это также шумная информация. Мы находим ФИО в описаниях и заменяем на специальный токен. Токены, относящиеся к ФИО, мы выделяем с помощью клиентской базы и проверки с помощью библиотек для морфологического анализа.Лемматизация оставшихся токенов.
Все оставшиеся токены приводятся к начальной форме.Замена непопулярных токенов на специальный токен <unpop_token>.
Словарь популярных токенов мы предварительно формируем, подсчитывая частоты токенов на большом корпусе описаний, предобработанных шагами 1-3. Применяя порог по частоте, мы получаем набор из 40к популярных токенов.
Вот как выглядит результат предобработки для представленных выше описаний:
оплата жкх unpop_tok unk_tok fio_tok fio_tok fio_tok иваново unpop_tok кара unk_tok
снятие ремонт установка топливный unpop_tok unpop_tok мерседес unk_tok unpop_tok unk_tok ндс unk_tok
оплата unpop_tok дизайн рекламный продукция календарь ручка пакет кружок unk_tok
оплата unpop_tok отопление unpop_tok октябрь unk_tok unpop_tok счет unk_tok unpop_tok unk_tok
Мы обработали достаточно большой корпус описаний и получили 100 миллионов уникальных предобработанных описаний, содержащие 40 тысяч уникальных токенов. Для этого корпуса мы обучили word2vec-модель, где для каждого токена выучили эмбеддинг размера 50.
Набор таких эмбеддингов для каждого описания, по сути, и есть набор признаков, которые мы сконструировали из наших описаний, пригодных для дальнейшего моделирования.
Кластеризация описаний
На нескольких примерах выше мы увидели, что в описаниях может действительно содержаться полезная информация. Мы провели дополнительное исследование с целью выяснить, какого рода информация может содержаться и интерпретируема ли она после нашей обработки. На корпусе предобработанных описаний мы запустили модель тематического моделирования с 35 основными и 10 фоновыми темами. Для каждой из тем строится распределение на токенах.
Темы получились достаточно интерпретируемые, исходя из топ-токенов, входящих в них. Вот примеры таких тем:
Таким образом, в описаниях действительно содержится полезная информация, содержащая в себе данные о целях и различных деталях покупки.
Архитектура модели
Шаблонную схему модели на транзакциях можно представить следующим образом:
Схема модели наследует идеи из моделей обработки естественного языка. В качестве элементов последовательности, иначе токенов, в текстовых задачах выступают слова, различные n-граммы, отдельные символы и другие возможные производные. Для токенов есть широкий набор модельных подходов для получения численных представлений – эмбеддингов, которые затем идут на вход модели обработки текста.
Наша схема повторяет шаги текстовых моделей: в качестве токенов у нас выступают транзакции, модель на транзакции преобразует транзакции в эмбеддинги, для которых уже можно применять те же модели, что применяются в текстовых задачах.
Модель на транзакции
Рассмотрим подробнее введенную нами модель на транзакции. На вход она принимает транзакционные признаки, а на выходе формирует релевантный эмбеддинг. Транзакция состоит из набора категориальных и вещественных признаков, а также из текстового описания. Как из всего этого получить один общий эмбеддинг?
Эмбеддинг транзакции можно представить как совокупность эмбеддингов всех составляющих ее признаков.
Для набора категориальных признаков мы используем подход Entity Embeddings: для каждого категориального признака строится матрица размера число уникальных значений признака x размер эмбеддинга, которая в соответствие каждому значению признака ставит его численное представление. Все значения этой матрицы являются обучаемыми параметрами нейросети, которые учатся вместе со всей сетью. Благодаря такому подходу мы доверяем выбор осмысленных значений эмбеддинга нашей модели, которая подберет их оптимальным образом для решения конкретной задачи.
Такой подход позволяет нам обрабатывать категориальные признаки, в дополнение к ним нас есть еще и вещественные признаки, а также текстовое описание. Необходимо понять, как мы можем получить эмбеддинг для них.
Вещественные признаки можно представить как категориальные с помощью процедуры бакетизации. Вещественная ось разбивается на заданное число промежутков – бакетов, пронумерованных слева направо. Категориальным признаком, соответствующим вещественному в данном случае, является номер бакета, в который попадает вещественное значение.
Для текстового описания мы уже имеем предобученную word2vec-модель, которая умеет отдельному токену сопоставлять эмбеддинг. Таким образом, предобработанное текстовое описание, можно представить как набор эмбеддингов токенов, его составляющих. Эмбеддинг описания можно получить из последовательности эмбеддингов его токенов. В базовом случае его можно получить простым покоординатным усреднением эмбеддингов токенов. В более сложном варианте это может быть модель, параметры которой учатся вместе со всей нейронной сетью.
Обобщив все вышесказанное, можем представить модель на транзакции следующей схемой:
Основная модель
Теперь нам остается определиться с Основной моделью, обозначенной на общей схеме. Классической архитектурой для обработки последовательностей являются рекуррентные нейронные сети, мы используем двунаправленные GRU-сети.
На выходе рекуррентной сети мы используем все скрытые состояния, для их агрегации мы используем глобальные max- и mean-пулинги по размерности длины последовательности. Впоследствии идет несколько скрытых слоев и на выходе мы имеем предсказание модели.
Применение
Помимо представленной модели на транзакциях расчетного счета, у нас есть вышеупомянутая модель на карточных транзакциях, а также бустинг, работающий на табличных данных. Все 3 модели решают задачу кредитного скоринга.
Зачем нам столько моделей для одной задачи? Дело в том, что каждая из моделей работает на своем независимом домене данных и по-своему его эффективно обрабатывает. Использовать всю информацию от моделей в финальном предсказании можно с помощью взвешивания отдельных предсказаний всех 3 моделей.
При моделировании мы смотрим на ROC-AUC, но более широкое распространение в банке имеет метрика Джини: Увеличение значения Джини позволяет банку выдавать больше кредитов при неизменном уровне риска. Рост числа выдач напрямую влияет на увеличение прибыли. Благодаря этой связи при расчете финансового эффекта от модели каждый пункт Джини конвертируется в деньги.
Исторически бустинг был основной моделью кредитного скоринга, так как работает на большом домене различных табличных данных, удобных для обработки методами классического машинного обучения. Набор данных настолько широк, что даже включает в себя транзакционные признаки, правда, в виде агрегатов. Благодаря богатому набору данных бустинг индивидуально имеет приличное качество. Критерием качества транзакционных моделей является прирост метрики, получаемой от взвешенного предсказания 3 моделей по сравнению со значением метрики бустинга. Этот прирост обеспечивается непосредственно за счет обработки всей транзакционной истории без потери информации с помощью нейросетей.
Ограничением транзакционных моделей является необходимость наличия транзакционной истории у клиента банка. В связи с этим естественной областью применения модели в кредитном скоринге являются вторичные предложения, которые формируются для действующих клиентов банка. На вторичных предложениях обе транзакционные модели дают прирост в 3 Джини, внося равный вклад.
Представленный подход обработки транзакционной истории продемонстрирован на примере решения задачи кредитного скоринга, но легко переносится на большое множество банковских задач, где необходимо по клиенту предсказать некую целевую переменную: модели оттока, дохода, склонности и прочее. За счет того, что мы построили универсальный кодировщик транзакционной истории, все что нам необходимо — это взять новый датасет, выбрать правильный лосс и заново обучить нейронную модель с той же архитектурой.
Что почитать по теме
https://habr.com/ru/company/alfa/blog/551130/
https://habr.com/ru/company/alfa/blog/573332/
https://habr.com/ru/company/alfa/blog/587040/