Как научить языковую модель читать транзакции: превращаем историю платежей в базу знаний

Меня зовут Дмитрий Валов, я тимлид команды «Инструменты для банка (агенты)» в Sber AI Lab — Центре практического искусственного интеллекта Сбера.

Большие языковые модели (LLM) научились отвечать на вопросы, писать код и анализировать документы. Логично спросить: «А может ли одна универсальная модель заменить зоопарк специализированных систем, которыми банк описывает своих клиентов?» Сегодня под каждую задачу — отток, кредитный риск, NBA — заводится отдельный пайплайн: свой набор фичей поверх истории транзакций, своё обучение, свои перетренировки при каждом изменении. Данные об одном и том же клиенте растаскиваются по разным системам и плохо переиспользуются. Сложнее всего — сопровождение и актуализация: стоит появиться новому источнику или фиче, как модель приходится переобучать, иначе она просто не умеет ими пользоваться.

LLM выглядит идеальным кандидатом на роль единого интерфейса к этим данным: данные переводятся в текст, и новый источник достаточно дописать в промпт на инференсе, без переобучения. Но есть проблема: если просто скормить модели историю транзакций, она справляется заметно хуже специализированных моделей. В нашей работе FinTRACE мы разобрались, почему так происходит, и предложили способ это починить — не дообучая модель на огромных размеченных датасетах, а перестраивая то, что именно мы ей показываем.

Статья принята на SIGIR 2026.

В чём, собственно, проблема

Возьмём типичную строку из истории платежей: 2024-01-15, Grocery, 82.40, POS. Для человека это «купил продукты в магазине у дома». Для языковой модели — почти бессмысленный набор токенов.

Дело в том, что предсказательный сигнал в транзакциях спрятан не в словах, а в закономерностях: насколько регулярно человек тратит, какая у него дисперсия трат, концентрируется ли он на одних и тех же категориях или распыляется по сотне разных. Коды категорий и идентификаторы мерчантов у каждого банка свои и не несут устойчивого «лингвистического» смысла. Если просто сериализовать таблицу в текст и засунуть в промпт, то получится читаемо, но семантически пусто: модель не вытащит из этого ничего полезного.

Мы проверили это на эксперименте и получили картину, которая хорошо описывает весь «затык»:

• Готовые LLM (GPT-4o, gpt-oss) в режиме 0/4/16 примеров упираются в потолок около 0,30 MCC и выше не растут.

• Специализированные модели (TabPFN, CatBoost, CoLES) пробивают 0,48 MCC, но только при полной разметке, то есть когда у вас есть тысячи меток.

Между «потолком LLM» и «полом специализированных моделей» зияет разрыв. Назовём его разрывом обобщаемости: либо у вас гибкий, но слабый языковой интерфейс, либо сильная, но прожорливая на разметку специализированная модель. Хочется получить и то, и другое.

MCC (коэффициент корреляции Мэтьюса) — метрика качества классификации, устойчивая к дисбалансу классов. В отличие от accuracy, её трудно «накрутить», просто предсказывая преобладающий класс, поэтому на скошенных банковских данных она честнее.

Главная идея: не текст, а структурированная база знаний

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

Поэтому вместо того чтобы превращать сырой лог транзакций в текст, мы создаём из него структурированную базу знаний (Knowledge Base, KB). По духу это ближе к онтологиям и нейросимвольным системам, чем к обычному prompt-инжинирингу: мы строим явный промежуточный слой поведенческих паттернов, который можно извлекать, комбинировать и переиспользовать между задачами.

Устройство базы знаний: три слоя

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

Слой 1. Feature essences — «сырые показатели»

Это числовые характеристики, посчитанные прямо из последовательности событий. Считаем мы их по пайплайну фич из нашей предыдущей работы LATTE. Примеры:

• inter_transaction_interval — средний интервал между операциями;

• spending_variance — дисперсия сумм трат;

• category_entropy — энтропия категорий (насколько разнообразны покупки);

• activity_period_days — длина активного периода клиента.

Таких показателей десятки, и сами по себе они «немые»: число category_entropy = 1.8 ничего не говорит модели без контекста.

Слой 2. Behavioral patterns — «черты поведения»

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

Чтобы сформулировать черты, мы раскладываем сырые показатели по трём осмысленным категориям, привязанным к структуре транзакционных данных:

Внутри каждой категории мы просим LLM отобрать один-два наиболее релевантных для задачи показателя. То есть модель работает не аналитиком данных, а «куратором»: она не считает признаки, а решает, на какие из них смотреть. Схематично промпт отбора выглядит так:

Категория: денежное поведение

Доступные показатели:

— spending_variance (дисперсия сумм трат)

— income_consistency (постоянство поступлений)

— avg_transaction_amount(средний чек)

Целевая задача: предсказание оттока клиента.

Выбери 1–2 показателя, наиболее информативных для черты «финансовая стабильность». Ответ — только имена показателей.

Слой 3. Downstream targets — «цели»

Это downstream-задачи: отток, дефолт, демографический атрибут. Они появляются в KB только тогда, когда есть размеченные данные. Если разметки нет — слой целей остаётся пустым, а KB всё равно полезна (об этом ниже).

Как связать слои: white-box правила

Три слоя нужно соединить, и связываем мы их не нейросетью-чёрным-ящиком, а white-box правилами. Для этого используем интерпретируемую модель AutoWoE (из нашего LightAutoML). Она извлекает явные зависимости между показателями, поведенческими чертами и таргетом, формируя граф, центрированный на целевом узле.

А дальше мы переводим извлечённые зависимости в человекочитаемые нечёткие правила, которые можно прямо вставить в промпт:

ЕСЛИ activity_period_days ≤ 70.5 → СИЛЬНЫЙ сигнал оттока

ЕСЛИ spending_variance высокая И behavioral_loyalty падает → ПОВЫШЕННЫЙ риск оттока

ЕСЛИ category_entropy низкая И income_consistency высокая → сигнал УДЕРЖАНИЯ (стабильный клиент)

В итоге на входе у модели больше не «простыня» из сотен строк транзакций, а компактный набор фактов и правил (до ~20 фактов на промпт), где явно сказано, как поведение связано с целью. Модель отвечает, опираясь на прослеживаемую цепочку доказательств, а не на сырые записи.

Почему именно правила, а не «больше чисел»

Что прирост дают именно правила, а не объём данных в промпте, мы проверили отдельной абляцией. Сравнили несколько способов наполнить промпт:

Вывод контринтуитивный, но показательный: добавление статистических подсказок (квантилей, важностей фич) не помогает — все варианты остаются на уровне базового zero-shot или даже ниже. Узкое место не в нехватке чисел, а в отсутствии явной семантической структуры, которая организует эти числа в связное «поведенческое досье». Как только мы даём модели именно структуру white-box знаний, MCC прыгает с 0,19 до 0,41.

Отдельно проверили стратегию отбора поведенческих черт:

Без white-box компонента (когда LLM сама строит KB по именам и распределениям фич) система буквально разваливается — MCC = 0,01. А вот случайный отбор черт всё ещё работает на удивление неплохо, если правила на месте. То есть главный источник силы — явные правила из white-box модели, а LLM-guided отбор лишь помогает приоритизировать самое информативное.

Три режима работы под разную доступность разметки

Базу знаний можно использовать по-разному в зависимости от того, сколько у вас меток.

Режим 1. Target-aware KB (разметка есть)

AutoWoE строит граф, центрированный на целевом узле: цель связана с информативными элементами KB через интерпретируемые ассоциации. На инференсе мы извлекаем релевантные элементы и правила, собираем структурированный промпт — и модель выдаёт обоснованный прогноз. Схематично промпт инференса:

Задача: предсказать отток клиента в ближайшие 3 месяца (метки: отток / удержание).

Поведенческие признаки клиента:

— financial_stability: низкая (spending_variance высокая)

— behavioral_loyalty: снижается

— activity_period_days: 58

Правила (из white‑box модели):

— ЕСЛИ activity_period_days ≤ 70.5 → сильный сигнал оттока

— ЕСЛИ spending_variance высокая И loyalty падает → повышенный риск

Дай ответ: метка + краткое обоснование строго на основе фактов и правил выше.

Конструкция заменяет построчную сериализацию транзакций на компактный набор графовых связей и нечётких правил.

Режим 2. KB-grounded instruction tuning (дообучение без ручной разметки)

Каждый экземпляр target-aware KB мы превращаем в обучающий пример-тройку {инструкция, контекст, ответ} и используем как данные для дообучения. Модель учится по структурированному входу генерировать объяснение и финальный прогноз, то есть интернализует паттерны финансового рассуждения без ручной аннотации. Формат тройки:

{
  "instruction": "На основе поведенческих фактов и правил определи, уйдёт ли клиент.",
  "context": "financial_stability: низкая; activity_period_days: 58; правило:
              activity_period_days ≤ 70.5 → сильный сигнал оттока",
  "response": "Период активности 58 дней — ниже порога 70.5, стабильность низкая.
               Это сильный сигнал оттока. Метка: отток."
}

Размеченные данные автоматически превращаются в инструкционный датасет — никто не пишет аннотации руками.

Режим 3. KB при дефиците разметки (zero/few-shot)

Если разметки под целевую задачу мало или нет вообще, то мы переиспользуем заранее посчитанную KB без целевых связей — остаётся feature-центричный граф зависимостей между показателями, который не нужно перестраивать под каждую новую цель.

Самое интересное здесь — как этот граф достраивается до незнакомого таргета, которого не было при построении KB:

1. LLM отбирает фичи. По текстовому описанию новой задачи модель выбирает несколько показателей, которые, как она считает, связаны с таргетом.

2. White-box строит связи между фичами. Для отобранных показателей AutoWoE извлекает явные зависимости — получается граф связей между самими фичами, пока ещё без узла цели.

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

• Zero-shot: весь вышеописанный механизм работает прямо на инференсе, без обновления весов: модель адаптируется к задаче, опираясь на описание цели и извлечённые подграфы наиболее релевантных показателей.

• Few-shot: добавляем до 16 размеченных примеров и небольшую память self-reflection — пар «прошлый прогноз ↔ реальный исход». Модель сначала выдаёт черновой прогноз, потом пересматривает его, сверяясь с прошлыми успехами и провалами. Это лёгкий механизм адаптации без дообучения.

Что получилось

Тестировали на трёх публичных бенчмарках (Gender, Rosbank, DataFusion) и на внутреннем датасете Сбера. Zero/few-shot — на gpt-oss-120b, дообучение — на Llama-3-8B-Instruct, white-box правила — через AutoWoE, всё на кластере из 4× A100.

В low-supervision режиме:

• zero-shot MCC на Rosbank удвоился: с 0,19 до 0,38 — без какого-либо переобучения под задачу;

• с 16 примерами вырос до 0,40 MCC, обойдя и промпт-based, и эмбеддинг-based, и табличные бейзлайны;

• на DataFusion — лучший few-shot результат 0,77 F1/0,10 MCC, выше сильных табличных методов вроде TabPFN.

При knowledge-grounded дообучении (FinTRACE Instruct):

• 0,48 MCC на Rosbank — это уровень специализированной SOTA-модели CoLES (тоже 0,48), но без узкоспециализированной архитектуры;

• 0,53 на Gender, 0,12 на DataFusion;

• при этом общие языковые способности не деградируют — на MMLU модель держит те же 0,53, что и до дообучения.

Последний пункт важен. Обычные стратегии дообучения здесь подводят: NTP-тюнинг (LLM4ES) хоть и поднимает метрики на Rosbank, однако полностью теряет общие текстовые способности (текстовые навыки на MMLU падает в ноль), а обычный SFT не переносится на несбалансированный DataFusion и схлопывается до 0,00 MCC. FinTRACE Instruct закрывает разрыв до специализированных моделей и сохраняет универсальность LLM, что и было главной целью.

Вместо заключения

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

Самое приятное: подход не требует размечать тысячи примеров и не ломает общие способности модели. Структура важнее объёма данных — кажется, для транзакционной аналитики это работает.

Авторы статьи: Артем Сахно (Sber AI Lab), Даниил Томилов (Sber AI Lab), Юлиана Шахвалиева (Sber AI), Инесса Фёдорова (Sber AI), Дарья Рузанова (Sber AI), Омар Золоев (Sber AI Lab), Андрей Савченко (Sber AI Lab), Максим Макаренко (Sber AI Lab).