Всем привет! На связи снова команда прикладных исследований Альфа-Банка. Эта статья является третьей, и последней, в серии статей, посвященной нейросетевым подходам к решению задачи кредитного скоринга физических лиц в Альфа-Банке. Первые две статьи:
Здесь мы хотим рассказать о наших экспериментах с построением модели, объединяющей результаты нескольких других нейросетевых моделей. Результаты могут использоваться как применительно к задачам, аналогичным описываемой нами, так в более общих случаях. Например, если у вас есть готовые эмбеддинги из каких-то других моделей произвольной природы, либо даже просто табличные данные, и вы хотите выжать из них максимум качества, описанные нами подходы могут быть полезны.
Описание проблемы
Напомним, что в предыдущих публикациях мы рассказали про четыре компоненты нашей нейросетевой PD модели:
модуль на транзакциях расчётного счёта,
модуль на данных карточных транзакций,
модуль на данных кредитных историй,
графовая нейросеть на данных о связях клиентов.
Каждый из описанных модулей представляет, по сути, отдельную PD-модель, обученную на отдельном домене данных, но на общей целевой переменной. На выходе, помимо своего скорингового балла, модули формируют векторные представления клиента, исходя из специфики конкретного домена.
Встает вопрос — как смешать результаты всех модулей в один общий скоринговый балл?
На первый взгляд, напрашивается наиболее очевидный подход, состоящий в том, чтобы объединить скоры каждого модуля с помощью метамодели, например логистической регрессии. Однако такой подход не позволяет учесть взаимное влияние разных источников данных друг на друга.
Поэтому мы применяем другой подход, а именно строим общую нейросетевую модель, на вход которой подаются эмбеддинги с финального полносвязного слоя каждого из модулей.
Стоит заметить, что задачу построения общей нейросетевой модели на различных доменах данных можно было бы решать end-to-end, то есть строить одну общую модель. Но так мы бы потеряли гибкость при тестировании новых источников, хотя и избавились бы от необходимости поддерживать отдельные модули.
В итоге, мы решили пойти по пути поддержки нескольких модулей, но предпочли сохранить гибкость при добавлении новых данных в общую модель. При появлении нового источника мы строим новый модуль с архитектурой, подходящей под специфику данных, и переобучаем общую модель.
Архитектура модели
Как упоминалось выше, в качестве входа модель принимает эмбеддинги клиентов, полученные от отдельных модулей. При разработке общей модели мы проводили много экспериментов с архитектурой, и в итоге остановились на пайплайне, который на данный момент даёт лучший результат.
Идея финального решения довольно проста: берём внутренние представления клиентов из отдельных доменных моделей, объединяем их в один общий вектор и дальше рассматриваем каждый его элемент как отдельный численный признак. Для четырёх модулей это выглядит так:
ТРС: 64 признака;
КТ: 32 признака;
БКИ: 256 признаков;
Графовый модуль: 768 признаков.
На вход общей модели подаётся вектор из 1120 численных признаков.
Сразу оговоримся: общая модель обучается на всех клиентах, у которых есть хотя бы один из источников. Это важный момент, потому что в реальном пайплайне полнота данных между доменами отличается. Например, по БКИ пропусков существенно меньше, чем по транзакционным источникам.
Поэтому вопрос работы с отсутствующими доменами крайне критичен. Во всех экспериментах отсутствующие источники мы заполняли очень малым числом. Мы пробовали разные варианты обработки пропусков, но именно этот способ оказался наиболее устойчивым на практике.
Как мы пришли к лучшему решению?
Самый очевидный baseline для такой задачи — взять скоры отдельных модулей и объединить их с помощью простой метамодели, например логистической регрессии. Такой подход действительно работает и долгое время служил для нас отправной точкой.
Проблема в том, что скоры слишком сильно сжимают информацию. По сути, каждый модуль уже превращает богатое представление клиента в одно число, и дальше общая модель видит только эти несколько чисел. В таком виде она уже не может уловить более тонкие зависимости между доменами.
А ведь именно они здесь и важны. Один и тот же клиент может выглядеть надежно по одному источнику и заметно хуже по другому.
Если в общую модель передавать только финальные скоры, значительная часть этой структуры теряется.
Если же передавать внутренние эмбеддинги, то модель получает возможность учитывать нелинейные взаимодействия между источниками и строить уже действительно общее представление клиента.
В нашем случае переход от смешивания скоров логистической регрессией к разным архитектурам общих моделей на сырых или специально обработанных эмбеддингах дал следующие результаты, где уверенно побеждает TabM с PLE.
Если мы уже представили объединённый вектор эмбеддингов как набор численных признаков, то как именно их лучше подавать в табличную модель? Что это за обработки эмбеддингов?
PLE
Здесь хорошим решением оказался PLE — piecewise linear embeddings. Идея этого подхода подробно описана в работе «On embeddings for numerical features in tabular deep learning»: авторы показывают, что для табличных нейросетей представление численных признаков само по себе является важной степенью свободы, а piecewise linear encoding — один из сильных практических вариантов.
В нашем пайплайне PLE применяется к каждому численному признаку отдельно.
Для каждого признака на train-части данных строится по одной фиче decision tree с использованием таргета; листья этого дерева задают интервалы разбиения числовой оси.
Затем признак дискретизируется по этим интервалам, и полученное разбиение используется для piecewise linear encoding.
В нашей конфигурации для каждого признака используется разбиение на 48 бинов.
Все этапы построения границ выполняются только на train-части, без утечки информации в validation и OOT. Это соответствует target-aware binning в PLE, где бины задаются деревом по одному признаку и таргету, а затем используются для piecewise-linear кодирования.
Схематично это выглядит так:
Интуитивно здесь происходит полезная вещь: сырое значение признака перестаёт быть просто числом из непрерывной оси и начинает описываться с учетом того, как его области соотносятся с целевой переменной. Для эмбеддингов это оказалось особенно полезно.
Сам по себе переход от сырых эмбеддингов к PLE-преобразованию дал нам неплохой аплифт. Для табличной части это уже тот случай, когда улучшение нельзя назвать косметическим.
TabM
После слоя PLE-преобразований мы подаем данные в TabM. Здесь мы старались не изобретать свою архитектуру поверх хорошей статьи, а использовали имплементацию статьи без существенных изменений.
TabM предложен в работе «TabM: Advancing Tabular Deep Learning with Parameter‑Efficient Ensembling». Основная идея модели — объединить простую MLP‑подобную архитектуру с параметрически эффективным ансамблированием: модель генерирует несколько предсказаний на объект и учится использовать их совместно. Авторы показывают, что такой подход дает сильное сочетание качества и эффективности и делает TabM одним из наиболее практичных deep learning решений для табличных задач.
Для нашей постановки это оказалось очень удачным совпадением. На вход подаётся большое число плотных численных признаков, между которыми есть нетривиальные нелинейные взаимодействия. Именно в такой конфигурации TabM чувствует себя уверенно: модель хорошо работает с большим набором численных признаков и лучше обобщает на OOT, чем альтернативы, которые мы пробовали.
Отдельно подчеркнем, что гиперпараметры здесь оказались критически важны. Подбор проводился ручной серией экспериментов, и самым чувствительным параметром оказалось количество ансамблевых голов. Такжезаметное влияние оказывали ширина внутренних слоёв, dropout, learning rate и weight decay. В какой‑то момент стало понятно, что в этой части модели «поставить дефолты и надеяться на лучшее» не получится — хорошее качество пришлось буквально вымерять экспериментами. Например, на графике лосс подбора числа ансаблевых голов.
В итоге выбрали 32 головы и так постепенно для каждого параметра методом проб и ошибок для поиска оптимума.
Немного про ResNet
До перехода на TabM нашей production‑like общей моделью был табличный ResNet. Здесь мы опирались на работу «Revisiting Deep Learning Models for Tabular Data», в которой авторы показывают, что ResNet‑подобная архитектура является сильным и недооценённым baseline для табличных задач. В той же работе предложен и FT‑Transformer как адаптация Transformer‑подхода для табличных данных.
ResNet действительно оказался хорошим кандидатом. В нашем случае он обучался на эмбеддингах после стандартного scaling и числового препроцессинга, а затем был усилен за счёт PLE. Этот шаг дал baseline-модели ещё точку прироста.
Тем не менее, TabM оказался сильнее. Для production-like модели такого класса это уже вполне ощутимое отличие.
Что ещё пробовали
Раз уж речь зашла о предыдущей SOTA-архитектуре, логично коротко рассказать и о том, куда мы тоже ходили, но в итоге не остались.
Первый естественный вопрос был довольно прямолинейным: а что, если просто взять все эмбеддинги, представить их как обычные численные признаки и отдать CatBoost?
Ответ — работает, но не лучшим образом. CatBoost заметно уступил финальной архитектуре. На наш взгляд, проблема здесь в том, что при таком объёме данных и такой плотности признаков становится сложно одновременно раскрыть потенциал модели и при этом аккуратно контролировать переобучение. Плюс полноценный тюнинг такого решения оказался бы очень дорогим по времени и вычислениям.
Иными словами, «просто затолкать всё в бустинг» не получилось…
Мы также попробовали FT-Transformer из «Revisiting Deep Learning Models for Tabular Data». На бумаге это выглядело заманчиво: Transformer, да ещё и специально адаптированный под табличную постановку. Но в нашей задаче модель не зашла и оказалась слабее остальных кандидатов.
По нашей гипотезе, для такой постановки FT-Transformer оказался слишком тяжёлым и не лучшим образом работал именно на плотных эмбеддингах, полученных из доменных моделей. В результате он показал результат лишь немного лучше логистической регрессии на скорах и значительно уступил и бустингу, и более сильным нейросетевым кандидатам.
Итоговая архитектура
Если попробовать кратко сформулировать главный вывод наших экспериментов, он будет таким: для задачи смешивания доменных эмбеддингов решающим оказался не один конкретный компонент, а связка из нескольких удачных решений.
Во-первых, сама идея смешивать не финальные скоры, а внутренние представления клиентов, уже даёт модели существенно больше информации.
Во-вторых, эмбеддинги полезно сначала «перевести» в язык табличной модели. PLE здесь оказался хорошим промежуточным слоем между нейросетевыми представлениями и downstream-архитектурой.
И наконец, TabM удачно подхватил этот пайплайн. Модель хорошо справляется с большим количеством численных признаков, умеет моделировать их нелинейные взаимодействия и сохраняет устойчивость на OOT.
Именно поэтому финальный пайплайн...
...оказался для нас лучшим способом смешивания доменов.
Выводы и планы
Разумеется, история на этом не заканчивается.
Во-первых, сам модульный подход по-прежнему даёт нам важное преимущество в гибкости. Если появляется новый источник данных, мы можем построить отдельный специализированный модуль, получить из него эмбеддинги и затем переобучить common-модель, не ломая весь пайплайн целиком.
Во-вторых, пространство для развития остается и в самой общей модели. Здесь можно исследовать более сложные fusion-подходы, другие стратегии и подходы между доменами и варианты, в которых информация о наличии или отсутствии источника будет задаваться ещё более явно.
Если посмотреть на весь цикл статей целиком, то итоги получаются такими.
С одной стороны, специализированные доменные модели действительно умеют вытаскивать сильный сигнал из своих источников — будь то транзакции, кредитная история или граф связей. С другой — общий скор лучше строить как отдельную модель поверх внутренних представлений клиентов, так как в итоге выигрывает мультимодальное представление, где каждый компонент делает то, что у него получается лучше всего.
Также важно заметить, что указанный подход можно распространять на прочие задачи, не связанные с кредитным скорингом, например на задачи склонности к покупке продуктов банка, задачи противодействия мошенничеству, предсказания дохода, и прочим, чем мы планируем заняться в ближайшее время. О наших успехах и неудачах обязательно сообщим в последующих публикациях.