Представлено на NVIDIA GTC Berlin руководителем исследований в Revolut Антоном Репушко и ведущим специалистом по данным Амеем Баокаром

Всего восемь месяцев назад на NVIDIA GTC 2026 компания Revolut представила PRAGMA — семейство базовых энкодер-моделей для последовательностей банковских событий, предварительно обученных на 26 миллионах анонимизированных историй пользователей и разработанных в сотрудничестве с NVIDIA.

В то время это был исследовательский прорыв: единый предварительно обученный бэкбон продемонстрировал относительный прирост качества в шести прикладных задачах по сравнению с традиционными бейзлайнами. Однако первый вопрос от коллег по индустрии касался вовсе не архитектуры модели. Всех интересовало: как на самом деле запустить базовую модель для десятков миллионов пользователей в реальном времени и в условиях строгих банковских регуляций?

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

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

Почему нельзя просто взять и развернуть чекпойнт

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

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

Хотя пакетная оценка (batch scoring) в ночное время подходит для ежедневных решений, онлайн-оценка в путях обработки транзакций в реальном времени (таких как обнаружение мошенничества и мгновенный кредит) требует совершенно иной инженерной дисциплины. Три главных узких места отделяют исследовательский чекпойнт от производственного движка:

Доставка данных: прием и выдача токенизированных историй с ультранизкой задержкой.
Экономика инференса: обеспечение быстрого и экономически эффективного инференса на GPU для десятков задач.
Нормативное управление: обеспечение неизменяемости, аудируемости и гарантий резервного копирования.

Проблема 1: Прием и выдача канонического представления

PRAGMA была обучена на данных активности, поступающих из полудюжины базовых систем: изменяемых основных гроссбухов (core ledgers), выдающих частичные события, неизменяемой фронтенд-телеметрии, ежедневных выгрузок из хранилищ и периодических снимков пользователей.

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

Для решения этой задачи мы создали специальную внутреннюю платформу данных, которая асинхронно принимает клиентскую активность, нормализует ее в каноническую схему PRAGMA, восстанавливает изменяемые транзакции до полных состояний и предварительно токенизирует историю.

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

Ключевые инженерные решения

Реконструкция состояния перед токенизацией: события основного гроссбуха поступают в виде частичных дельт. Токенизация дельт напрямую сделала бы входные данные модели опасно чувствительными к времени доставки событий. Наша специализированная платформа поддерживает актуальное полное состояние по каждой транзакции в операционном хранилище, применяя детерминированные правила слияния до того, как произойдет токенизация.
Бюджеты актуальности по каналам: вместо внедрения единого монолитного SLA, которое приводило бы к постоянным сбоям пайплайнов, эта внутренняя платформа получает данные на основе независимых маркеров прогресса (например, карточные транзакции видны в течение секунд; изменения профиля пользователя экспортируются в течение часов). Задержка в одном канале никогда молча не портит другой.
Усеченные горячие окна: платформа также поддерживает многомесячную историю быстрых данных (hot history). Эксперименты с усечением доказали, что обслуживание 6-месячного окна по сравнению с полной многолетней историей не приводит к какому-либо существенному снижению качества модели, что дало нам математически обоснованную границу емкости.
Жесткие SLA по задержке: запрос на оценку получает временную шкалу событий и снимок профиля (до ~1300 токенов на канал). Наша платформа ориентирована на двузначный миллисекундный SLA чтения p99 при бюджете сквозного инференса менее секунды.
Поведенческая неизменяемость: логика токенизатора имеет версии и является неизменяемой. Данные для обслуживания физически разделены по версиям токенизатора; новые версии заполняются параллельно, проверяются на паритет и активируются через псевдоним указателя (pointer alias).
Явная проверка контекста: если требуемые контекстные каналы отсутствуют, система быстро завершает работу с ошибкой, а не выдает молча усеченную последовательность. (Для оценки в рамках транзакции шлюз токенизирует только входящее триггерное событие на лету и добавляет его к полученной истории пользователя).

Сегодня эта специализированная внутренняя платформа обслуживает начальную базу в 80 миллионов клиентов и спроектирована с расчетом на 3-кратное масштабирование, поддерживая до 10 000 событий на клиента.

Проблема 2: Высокоэффективный инференс на GPU

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

1. Динамическая замена LoRA (Ad-hoc Low-Rank Adapter)

Каждая прикладная задача работает на одном и том же общем базовом бэкбоне, соединенном с LoRA для конкретной задачи. Поскольку эти адаптеры корректируют только 2-4% основных параметров, их недорого обучать, хранить и менять по требованию. Бэкбон остается резидентным в памяти GPU; запуск или обновление задачи требует загрузки легковесного адаптера, а не развертывания всего экземпляра модели.

2. Многопользовательский динамический батчинг

Использование GPU для последовательностных нагрузок масштабируется напрямую вместе с размером батча. Наш слой обслуживания группирует запросы для обработки многопользовательских батчей (например, 40 пользователей на один запрос выполнения). Контракты чтения систем Revolut изначально созданы для обработки многопользовательских пакетных запросов, обеспечивая бесперебойную выдачу тысяч пакетных запросов в секунду.

3. Автоматизированное развертывание (AutoDL)

Мы оптимизировали управление жизненным циклом прикладных моделей в стандартизированный цикл экспериментов: сравнение замороженных эмбеддингов с линейными головами против тонкой настройки LoRA для различных размеров моделей. Конфигурация-победитель развертывается напрямую в унифицированную инфраструктуру без необходимости создания кастомных пайплайнов.

Эта инфраструктура лежит в основе AutoDL — внутренней платформы самообслуживания, позволяющей командам управлять выбором датасетов, тонкой настройкой, оценкой и развертыванием на общем бэкбоне без необходимости администрировать базовую ML-инфраструктуру.

Проблема 3: Нормативный комплаенс и интерпретируемость

Развертывание базовых моделей в регулируемых финансовых средах закономерно требует осознанной стратификации рисков:

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

Влияние на производство и парадигмы мультимодельных систем

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

Определение подписок в реальном времени и регулярных платежей в потоках обработки карт
Мгновенное принятие кредитных решений
Внутриигровые рекомендации продуктов с переходом от автономного пакетного скоринга к ранжированию в реальном времени

Понимание границ парадигмы: гибридное моделирование

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

Для решения этой задачи мы дополняем PRAGMA системой STRIDER, разработанной в сотрудничестве с Лабораторией банковской аналитики (The Banking Analytics Lab) при Университете Западного Онтарио и Университете Саутгемптона. STRIDER — это внутренняя табличная базовая модель, предварительно обученная исключительно на структурированных данных, в основном из наборов данных Revolut в разных странах, с основным упором на задачи кредитного риска и мошенничества.

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

Пять ключевых уроков для промышленных базовых моделей

Базовая модель в продакшене — это в первую очередь платформа данных, и только во вторую — модель. Большая часть производственной инженерии уходит на реконструкцию состояний, кэширование токенов и конвейеры обслуживания.
Токенизируйте один раз, обслуживайте везде. Вынесите все зависящие от пользователя преобразования, не влияющие на принятие решений, за пределы пути запроса в реальном времени.
Поведенческая неизменяемость обязательна. Неизменяемые версии токенизаторов и детерминистические конвейеры ввода являются предварительными условиями для регулируемого принятия решений.
Обслуживание на основе адаптеров обеспечивает устойчивую экономику. Единственный резидентный бэкбон с горячо заменяемыми адаптерами объемом 2–4% резко снижает маржинальные затраты на добавление новых сценариев использования.
Используйте мультимодельные архитектуры. Модели последовательностей, табличные модели и графовые сети имеют свои уникальные сильные стороны. Комбинируйте семейства моделей, вместо того чтобы вытягивать один бэкбон за пределы его естественных проектных границ.