Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Профили пользователей по банковским операциям научились строить без отдельного вызова LLM для каждого клиента. В пока не рецензированном препринте CyberAgent приведены числа, которые получили сами авторы: на внедрении число целей для модели сократилось почти на три порядка. Если транзакции многих клиентов повторяются, расходы теперь определяет число общих паттернов, а не размер клиентской базы.
Вместо истории клиента модель читает повторяющийся паттерн
Обычная схема передаёт LLM всю историю пользователя и получает описание его демографии, поведения или жизненной ситуации. Число вызовов растёт вместе с базой, а одинаковое поведение модель может описать разными словами, что мешает искать и объединять аудитории.
Новая схема сначала выделяет паттерны, которые встречаются у многих пользователей. Паттерном может быть один товар или сочетание покупок в заданном временном окне. Например, набор из детского питания, подгузников и кроватки даёт больше оснований предположить рождение ребёнка, чем любой из этих товаров отдельно.
Конвейер состоит из трёх этапов. Resolve очищает названия товаров и контрагентов от брендов, упаковки и другого шума; при необходимости обращается к веб-поиску, а для неинформативных позиций может отказаться от вывода. Profile один раз вызывает LLM для каждого уникального паттерна и получает фиксированные категории, свободные текстовые признаки и оценку того, насколько часто признак встречается среди покупателей этого паттерна.
На этапе Tag текстовые признаки превращаются в общий словарь. Система строит векторные представления фраз, объединяет близкие варианты алгоритмами UMAP и HDBSCAN, затем просит LLM дать каждому кластеру короткое название. В результате оператор ищет пользователей по устойчивым тегам, а не по непредсказуемым формулировкам модели.
Профиль конкретного человека собирается из всех паттернов, которым соответствует его история. Если уже известный паттерн появляется у нового клиента, повторный вызов LLM не нужен: система использует сохранённые признаки. При обновлении базы модель обрабатывает только ранее не встречавшиеся паттерны.
Качество сохранилось, хотя модель перестала видеть полную историю
Метод проверили на публичном корпусе Open e-commerce с анкетами пользователей. Количественную оценку проводили только для демографических признаков и жизненных событий, которым нашлись соответствующие ответы в анкете. Истории представлены наборами покупок внутри временных окон, а точные временные метки конвейер не использует.
Базовым вариантом служила LLM, которая читала исходную историю каждого пользователя. Та же модель-оценщик получала либо эту историю, либо профиль из базы и отвечала по одинаковой форме. Качество измеряли через AUC — показатель того, насколько уверенно система ставит пользователя с нужным признаком выше пользователя без него.
По AUC профиль из паттернов статистически не отличался от результата по исходной истории на всех проверенных признаках. Оценки распространённости также отделяли положительных пользователей от отрицательных, хотя работа не трактует их как откалиброванные вероятности.
В банке конвейер работает для десятков миллионов клиентов и сократил число входов для LLM почти на три порядка по сравнению с обработкой каждого пользователя. Рабочая база начиналась примерно со 149 тегов и расширялась в ходе эксплуатации.
Направление платежа меняет смысл одного контрагента. Компания, которая оказывает услуги по уходу за домом, детьми и пожилыми, у исходящего платежа указывает на клиента таких услуг, а у входящего — на сотрудника или подрядчика. Один справочник контрагентов без направления операции потерял бы эту разницу.
Архитектуру стоит менять там, где поведение повторяется
Работа меняет планы команд с большой базой и повторяющимися транзакциями. Единицей кэширования становится не пользователь, а смысловой паттерн: рост аудитории почти не добавляет вызовов, пока новые клиенты покупают уже известные товары и услуги. Это также делает формулировки одинаковыми для пользователей с похожим поведением.
Почти трёхпорядковое сокращение относится к числу целей для LLM, а не автоматически к итоговому счёту за всю систему. В бюджет также входят очистка названий, возможный веб-поиск, поиск частых сочетаний, построение векторных представлений и кластеризация. Их стоимость зависит от конкретных данных и инфраструктуры.
Редкие покупки могут не пройти порог частоты, хотя именно они иногда несут самый сильный сигнал. Для таких случаев подходит гибридная схема: основную базу обрабатывать через паттерны, а пользователей с важными редкими позициями отправлять в отдельный контур персонального анализа.
Границы проверки тоже влияют на решение. Эксперимент охватывает только признаки, сопоставимые с анкетой Open e-commerce, а один и тот же тип LLM создаёт профиль и оценивает его; возможную склонность модели предпочитать собственные формулировки отдельно не измеряли. Для продукта с другой моделью, языком или структурой операций потребуется собственная проверка.
В банковском внедрении транзакции обрабатываются внутри инфраструктуры организации. Однако выводимые признаки всё равно требуют правил доступа и использования: даже профиль без исходных операций может повлиять на то, кому покажут предложения по жилью, работе или финансовым продуктам.
Источники
Иллюстрация: рисунок из статьи «From "Who Is This User?" to "What Does This Purchase Mean?": A Deployed Pipeline for Semantic User Profiling at Bank Scale», Ryota Mitsuhashi, Tetsuro Morimura, Hirotake Ito, CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
