Если посмотреть, как строили рекомендательные системы лет пять назад, можно увидеть одну и ту же схему, включающую коллаборативную фильтрацию или ALS для кандидатов, градиентный бустинг сверху, офлайн‑метрики NDCG/MAP и A/B‑тесты.

Схема рабочая, и она до сих пор находится в продакшене как минимум у половины представителей индустрии. Но за последние пару лет в исследованиях и практике крупных компаний произошел заметный сдвиг: от пайплайна из отдельных кусков к цельным последовательным моделям пользователя, от классической коллаборативной фильтрации к генеративным рекомендерам, а также от наивного A/B‑тестирования к контрфактуальной оценке.

Отличия рекомендации оффера от рекомендации товара

Давайте сразу обозначим специфику домена, ведь она определяет добрую половину архитектурных решений. Большая часть публичных индустриальных кейсов в статьях про RecSys, включая архитектурные подходы вроде HSTU, написана для видеолент и маркетплейсов, в то время как перед банковскими офферами стоит принципиально другая задача. Нельзя просто взять архитектуру VK Видео или Wildberries и перенести ее в банк.

У VK Видео и Wildberries в каталоге находятся миллионы и миллиарды позиций, а интенсивность обращений достигает десятков тысяч запросов в секунду. Там реальная проблема заключается в том, чтобы быстро найти релевантные объекты среди огромного множества вариантов, поэтому для подобных платформ подходят генеративные рекомендеры вроде HSTU [1] с миллиардами параметров, где объемы данных и трафика окупают такой масштаб.

У банка есть лишь десятки или сотни офферов для каждого клиента. Задача поиска кандидатов здесь почти не возникает, поскольку практически весь каталог и без того помещается в отбор. Основная сложность заключается не в поиске, а в правильной сортировке и фильтрации немногочисленных вариантов с учетом бизнес‑ограничений.

В видеоленте почти каждое взаимодействие дает сигнал, будь то досмотр, пропуск, повторный просмотр или скорость прокрутки. Этого достаточно, чтобы обучать модель почти в реальном времени и активно исследовать пространство рекомендаций с помощью бандитов. Например, в промышленной работе Kuaishou по оптимизации удержания пользователей в коротких видео с помощью обучения с подкреплением [2] такое исследование безопасно проводится прямо внутри одной сессии из‑за большого количества сигналов.

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

Показ одного нерелевантного видео или товара практически ничего не стоит, поскольку пользователь просто пролистает его, а платформа даже выиграет от управляемой диверсификации выдачи. Индустрия много вкладывает именно в работы по диверсифицированному переранжированию на видеоплатформах [3] и контекстным бандитам для холодного старта контента [4]. Показ клиенту неподходящего кредитного продукта влечет за собой репутационный и регуляторный риски, такие как навязанные продажи и непосильная закредитованность.

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

На Wildberries или Ozon значительная часть трафика идет через поисковый запрос, поэтому гибридный поиск (BM25 плюс поиск по эмбеддингам) одновременно разбирает запрос и персонализирует выдачу. У банка запрос от клиента чаще всего отсутствует, так как система сама решает, какой оффер предложить, не опираясь на явный ввод от пользователя.

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

При ранжировании на Taobao [5] или JD.com [6] используется не чистая релевантность, а смешивание органической выдачи с рекламными местами через аукционные механизмы, которые балансируют релевантность и доход площадки. У классического банковского RecSys такая третья сторона обычно отсутствует.

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

Это прямая иллюстрация того, о чем говорят как обзоры по регулированию ИИ в финансах [7], так и работы по интерпретируемости кредитных моделей [8]. Получается, что фильтры по риск‑скорингу должны жестко отсекать неподходящие офферы еще на этапе отбора кандидатов, а не быть просто одним из признаков, который ранкер учится взвешивать сам.

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

Как строили раньше

Классическая архитектура последних лет, описанная в вакансиях и большинстве обзоров, использует двухстадийный пайплайн из независимых кусков:

Отбор кандидатов. Применяются коллаборативная фильтрация (ALS/implicit) или иногда двухбашенная нейросеть, при этом эмбеддинги пользователя и оффера помещаются в векторную БД, а кандидаты извлекаются через приближенный поиск ближайших соседей (HNSW).
Ранжирование. Кандидаты (обычно десятки или сотни) переранжируются градиентным бустингом (LightGBM/CatBoost) в постановке Learning to Rank, чаще всего с использованием LambdaMART с попарной или списочной функцией потерь.
Гибрид с полнотекстовым поиском. OpenSearch/Elasticsearch отдает кандидатов через BM25 с учетом фильтров по бизнес‑правилам, а сверху их дорабатывает ML‑ранкер либо через rescoring pipeline (плагин ml‑commons в OpenSearch), либо во внешнем сервисе.
Признаки пользователя. Используются вручную сконструированные агрегаты, включая RFM‑метрики, долю трат по категориям и сезонность, а также выполняется большой объем ручной подготовки признаков в PySpark.
Оценка. Рассчитываются офлайн‑метрики NDCG@k/MAP@k/Recall@k, после чего проводится A/B‑тест по простой схеме «контроль против теста» с оценкой разницы долей конвертировавшихся клиентов через t‑тест.

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

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

Как строят сейчас

1. Единая последовательность событий пользователя

Ключевая идея последних лет [9] состоит в том, чтобы не описывать пользователя вектором агрегированных статистик, а представлять его как упорядоченную по времени последовательность событий. Эмбеддинг последнего события в этой последовательности как раз и служит представлением пользователя на текущий момент [10].

Именно так теперь строят продакшн‑системы крупные игроки. Показательным примером из банковской сферы является открытый фреймворк Perseus от Т‑Банка [11]. Вместо отдельной модели под каждый сервис там собирают в одну последовательность все клиентские события, включая транзакции, активации повышенного кэшбэка, действия с банковскими продуктами и шопинг, а затем обучают единый sequence backbone.

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

По данным Т‑Банка, такой подход дал прирост бизнес‑метрик от 3% до 17% в разных сценариях. Причем выигрыш был заметен даже для клиентов без единого взаимодействия с конкретным сервисом, потому что модель успевала выучить предпочтения из других доменов.

Похожую логику описывает исследовательская команда Revolut в свежем препринте PRAGMA [12]. Авторы прямо указывают, что большинство существующих работ по последовательным рекомендациям заточено под один домен данных.

Для компаний с разнородными источниками, таких как банк, необходима архитектура, которая изначально проектируется под множество типов событий и множество задач в рамках одной модели. Похожий путь для транзакционных данных описывает и работа LATTE [13].

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

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

Из готовых открытых инструментов именно под эту задачу стоит выделить pytorch‑lifestream (ptls) от Sber AI Lab [14]. Это открытая библиотека (лицензия Apache 2.0), созданная специально под сырые событийные логи вроде банковских транзакций и кликстрима. Она содержит реализацию CoLES (Contrastive Learning for Event Sequences) и еще нескольких self‑supervised методов обучения энкодера последовательностей поверх трансформера или RNN. Библиотека готова к практическому использованию.

Полученные эмбеддинги клиента можно сразу передавать в CatBoost или LightGBM как дополнительные признаки, что реализует сценарий использования эмбеддинга из sequence‑модели в качестве признака для бустинга, о котором шла речь выше. Основная проблема здесь, как и у любой модели на транзакциях, заключается в том, что у ptls нет и не может быть универсальных весов, которые можно скачать и сразу применить к данным другого банка. В данном случае открытым и пригодным для повторного использования является именно инструмент для обучения энкодера на ваших собственных данных, а не готовый чекпоинт.

Отдельно стоит сказать про графовые модели для сценария рекомендации кэшбэка и мерчантов. Не все из этого одинаково применимо. HGT и графовые связки с LLM (InstructGLM и подобные) существуют только как открытый код архитектуры, который нужно обучать с нуля на своих данных. Готовых весов под эти задачи никто, насколько мне известно, не публиковал. Да и заявленные модели ULTRA‑HSTU с открытыми весами от NVIDIA и Meta, а также генеративный поиск по семантическим ID (TIGER) на практике не имеют опубликованных обученных чекпоинтов.

У HSTU в открытом доступе представлены только код и архитектура для обучения с нуля, поскольку сама Meta не публикует веса, обученные на данных пользователей. Конфигурации HSTU на HuggingFace прямо помечены как заполненные случайными весами для тестов производительности и не являются результатом реального обучения.

Исключение, которое действительно можно взять и опробовать из коробки, называется OpenGraph от HKUDS [15]. Это открытая графовая модель с кодом и предобученными чекпоинтами в репозитории, специально спроектированная для zero‑shot переноса на новые, ранее не виденные графы без дообучения. Это не банковская модель, так как она обучена на общих графовых бенчмарках.

Однако сама идея единого графового трансформера, который можно сразу протестировать на новом графе «клиент, мерчант, продукт» без сбора отдельного датасета под каждый холодный сценарий, стоит того, чтобы прогнать ее как baseline на кэшбэк‑рекомендациях и холодном старте партнерских офферов до вложения ресурсов в обучение собственной GNN с нуля.

2. Объединение отбора и ранжирования

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

В результате увеличение объема вычислений и данных предсказуемо дает лучшее качество вместо выхода на плато, как это происходило с классическими архитектурами [16]. Похожие подходы уже работают в продакшене у Kuaishou (OneRec [17]) и Meituan, использующих вместо раздельных стадий единую модель, которая одновременно решает задачи отбора кандидатов и ранжирования.

Для банковского масштаба каталога, включающего сотни офферов вместо миллиардов видео, триллион параметров избыточен. Однако сама идея обучать единый sequence backbone, отдающий скор релевантности напрямую, вместо разделения отбора кандидатов и ранжирования по разным моделям с разными целевыми функциями вполне переносима. Судя по описанному выше опыту Т‑Банка, она уже работает на практике в среднем масштабе [18].

Отдельно интересен опыт Т‑Банка по совмещению трансформеров и градиентного бустинга. Если у вас уже есть сильные табличные признаки под конкретную задачу, бустинг поверх них пока чаще выигрывает у сквозного трансформера, однако эмбеддинг из sequence‑модели прекрасно работает как дополнительный признак для бустинга. То есть речь идет не об отказе от LightGBM, а о замене вручную сконструированных признаков выученными представлениями при сохранении бустинга в роли финального ранкера.

3. Гибридный поиск

По описаниям вакансий видно, что интеграция OpenSearch/Elasticsearch с ML‑ранжированием стала обязательным навыком, а текущая индустриальная практика [19], [20] сходится к трехступенчатой схеме:

Разреженный поиск. Применяется BM25 в OpenSearch плюс жесткие бизнес‑фильтры, включающие комплаенс, риск‑ограничения и ограничение частоты коммуникаций.
Плотный поиск. Выполняется через векторную БД (Qdrant/Milvus) с приближенным поиском по HNSW с использованием эмбеддингов клиента и оффера из sequence backbone.
Объединение и переранжирование. Результаты разреженного и плотного поиска объединяются. Самый устойчивый и воспроизводимый способ на сегодня такой же, как и в RAG‑системах, а именно Reciprocal Rank Fusion (RRF).
Этот метод не требует калибровки шкал между разнородными скорами в отличие от наивного линейного смешивания BM25-скора и косинусной близости, которые физически несравнимы. Поверх объединенного списка работает финальный ранкер, в качестве которого выступает либо градиентный бустинг с LTR‑функцией потерь, либо, для более сложных случаев с приоритетом семантики над простой релевантностью, кросс‑энкодер или LLM‑реранкер [21].
LLM‑реранкеры дают заметный прирост NDCG и MRR по сравнению с чистым BM25 или плотным поиском, но они на порядок дороже по времени отклика, поэтому применяются только к первым 20, 30 или 100 кандидатам после первой стадии, а не ко всему каталогу. Это стандартный компромисс между стоимостью и качеством, который стоит закладывать в архитектуру сразу.

4. Вид обучения

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

Обычно используется классический метод Inverse Propensity Scoring (IPS) из работы Joachims с соавторами [22], где клики взвешиваются обратно пропорционально вероятности увидеть позицию. Но недавние работы показывают несколько важных уточнений, которые стоит учитывать при проектировании пайплайна обучения:

Крупномасштабное исследование на данных Baidu [23] показало, что классические методы обучения без смещений, прекрасно работающие на бенчмарках, на реальных продакшн‑логах ведут себя заметно хуже заявленного, так как оценки вероятности показа оказываются более шумными, чем предполагает теория.
Новые подходы, такие как control‑function‑подход к коррекции смещения по позиции [24], не требуют точного знания модели кликов и переносятся на любой современный ранкер, что удобнее классического двухшагового IPS.
Отдельная линия работ разбирает trust bias, то есть доверие пользователя к верхним позициям само по себе независимо от релевантности, отдельно от чистого смещения по позиции [25]. Это два разных эффекта, и смешивать их некорректно.

Что это значит на практике для банка? Логи показов офферов уже смещены самим фактом того, что модель или бизнес‑правило показывали одни офферы чаще других. Если не работать с этим смещением явно хотя бы простым взвешиванием по логируемой вероятности показа, то ML‑ранкер со временем начинает воспроизводить и усиливать решения собственной предыдущей версии вместо оптимизации реальной ценности для клиента и бизнеса.

5. Контрфактуальная оценка

Последний слой, который часто недооценивают на этапе проектирования, относится к тому, как вообще оценивать полученный эффект. В подавляющем большинстве систем используется A/B‑тест с разбиением по клиенту и t‑тест на конверсиях. Это по‑прежнему золотой стандарт, но есть вещи, которые стоит учесть.

Например, большинство знает о работе Gilotte с соавторами [26], которая еще с 2018 года является стандартом индустрии и показывает, что можно оценить потенциальный бизнес‑эффект новой политики ранжирования по историческим логам еще до выкатки в живой A/B‑тест. Это не замена онлайн‑теста, а способ отсеять заведомо плохие варианты быстрее и дешевле.

Но помимо этого есть более свежие работы по снижению дисперсии. Так, например, работа [27] формально показывает, что различные техники снижения дисперсии в A/B‑тестах (CUPED, CUPAC, ML‑RATE) математически эквивалентны офлайн‑оцениванию с двойной устойчивостью. То есть офлайн‑ и онлайн‑подходы к измерению эффекта на самом деле говорят об одном и том же, различаясь лишь уровнем доступа к данным.

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

Когда тестов много и они идут параллельно на разные продуктовые линии, полезно получать несмещенные оценки эффекта с помощью связи между политикой рандомизации и историческими политиками, а не считать все заново на каждом новом тесте [28], [29], [30].

Банковский RecSys 2026

Если сводить все сказанное в конкретную схему для банковских офферов:

Единый Event Hub. Выполняется приведение всех типов клиентских событий (транзакции, клики по офферам, активации кэшбэка, обращения в поддержку) к общему формату с явным временным протоколом, когда модель на инференсе видит только прошлое относительно момента предсказания.
Sequence backbone. Используется трансформер в духе SASRec или его более новые варианты. Формируется общий эмбеддинг клиента, повторно применяемый для отбора кандидатов, ранжирования и вспомогательных задач классификации или регрессии (например, предсказания оттока или склонности к дефолту при необходимости).
Отбор кандидатов. Применяются OpenSearch (BM25 плюс жесткие бизнес‑ и комплаенс‑фильтры) вместе с векторной БД (Qdrant/Milvus, HNSW) по эмбеддингам из backbone с последующим объединением через RRF.
Ранжирование. Используется градиентный бустинг (LightGBM/CatBoost) с LTR‑функцией потерь поверх табличных признаков и выученных эмбеддингов как дополнительных признаков с явной коррекцией смещения по позиции через IPS‑взвешивание логов.
Оценка. Рассчитываются офлайн‑метрики (NDCG@k, Recall@k), проводится офлайн‑оценка потенциального эффекта перед выкаткой, а также выполняется онлайн A/B‑тестирование с CUPED‑поправкой на предсказания модели до эксперимента для сокращения длительности теста.

Для улучшения восприятия свел все в одну таблицу:

Этап	Как строили раньше?	Как строят сейчас?	В чем разница?
1. Данные и признаки	Ручные агрегаты: RFM‑метрики, доля трат по категориям, сборка признаков вручную через PySpark под каждый продукт отдельно.	Единый Event Hub + Sequence backbone: трансформер, сжимающий все события пользователя (транзакции, клики, поддержка) в единый векторный эмбеддинг.	Вместо написания сотни ручных формул под каждый продукт применяется один трансформер, который учит универсальное представление клиента.
2. Отбор кандидатов	Коллаборативная фильтрация / ALS: независимые простые модели для поиска ближайших соседей.	Векторный поиск по эмбеддингам из backbone: поиск по Qdrant/Milvus с использованием векторов, созданных трансформером.	Кандидаты отбираются не просто по схожести прошлых покупок, а на основе всей хронологической последовательности действий.
3. Гибридный поиск	OpenSearch (BM25) + наивное линейное смешивание скоров или простые фильтры.	OpenSearch (BM25 + комплаенс/риски) + векторный поиск, объединенные через RRF.	Убрана проблема несравнимых шкал (когда нельзя корректно сложить BM25-скор и косинусное расстояние).
4. Ранжирование	Градиентный бустинг (CatBoost/LightGBM) на ручных признаках, обучение на сырых логах показов.	Градиентный бустинг, но на вход идут выученные эмбеддинги + применяется коррекция смещения по позиции (IPS).	Бустинг остался, но он больше не учится на искаженных (смещенных) данных и использует глубокие векторы вместо ручных фичей.
5. Оценка и тесты	Простой A/B‑тест (контроль vs тест, обычный t‑тест).	Контрфактуальная офлайн‑оценка перед выкаткой + A/B‑тест с CUPED‑поправкой.	Эффект проверяется еще до A/B‑теста по историческим логам, а сам A/B‑тест идет в разы быстрее за счет снижения дисперсии.

Заключение

Ни один из рассмотренных пунктов не отменяет то что уже используется, поэтому градиентный бустинг, OpenSearch и A/B‑тесты остаются на своих местах. Меняется то, что подается на вход бустингу (выученные представления вместо ручных агрегатов), как объединяется гибридный поиск (RRF вместо наивного линейного смешивания скоров) и как оценивается эффект с поправкой на смещение по позиции и с использованием офлайн‑методов.

References

Архитектура банковского RecSys