Разработка AI-модели на Transformer для финансовых данных

Где ломается стандартный прогноз: когда нужен финансовый Transformer

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

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

Линейные модели и бустинги на лагах проигрывают здесь первыми: они фиксируют локальные зависимости и плохо переносят их на смену режима. Финансовый Transformer держит длинный контекст и взвешивает разнородные сигналы — сделки, котировки, текстовые потоки — через внимание, а не через жёсткий набор лагов. Но архитектура сама по себе дрейф не лечит: качество прогноза держится на контуре, который замечает смену режима и перестраивает обучение под неё.

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

Что даёт финансовый Transformer в задачах прогноза

Классические модели на скользящем окне видят только последние точки ряда — событие с растянутой реакцией для них невидимо. Механизм внимания в архитектуре Transformer сопоставляет всю доступную историю сразу и взвешивает, какие прошлые интервалы действительно объясняют текущее движение. Длинные зависимости во времени становятся признаком, а не шумом.

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

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

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

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

Режимы обучения и вывода: сравнение подходов

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

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

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

Этапы внедрения: от аудита данных до передачи модели

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

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

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

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

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

5. Контроль утечек данных. Сдвигаем признаки, убираем подозрительные, сравниваем метрику до и после. Резкий провал — верный признак, что модель опиралась на подсказку из будущего.

6. Передача и мониторинг. Отдаём веса, конфигурацию, скрипты расчёта и набор метрик, по которым отслеживается дрейф. Дальше модель живёт по регламенту переобучения.

Артефакты проекта: конфигурации, схемы и регламенты

После сдачи проекта у заказчика остаётся не только обученная модель, но и артефакты, по которым её можно воспроизвести, проверить и переобучить без участия авторов. Без них финансовый Transformer превращается в чёрный ящик: прогнозы идут, а объяснить или починить их некому. Состав фиксируем на старте и передаём по акту.

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

Кейс: прогноз ликвидности до и после внедрения

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

Что было до внедрения

Доля ошибочных сигналов держалась около 18%: система выдавала ложные всплески потребности в ликвидности и одновременно пропускала реальные. Аналитики правили вручную в среднем 40 прогнозов в неделю, а переобучение на новых данных занимало почти две недели — к моменту обновления сам режим уже менялся, и ошибки возвращались.

Что изменили и что получилось

Мы перешли на финансовый Transformer с вниманием по нескольким горизонтам, реализованный на PyTorch: модель видит и минутные потоки, и недельный контекст, а не усреднённое окно. Дообучение поставили на поток — обновление на свежих данных занимает часы вместо недель, с проверкой на отложенных периодах по принципу скользящего окна.

Отдельно закрыли риск переобучения на новых данных: в проверку добавили аномальные дни — пики выплат и разрывы ликвидности — и модель отбирается по устойчивости на них, а не по средней ошибке. Как итог: доля ошибочных сигналов снизилась до 6%, число ручных правок аналитиков — до 7 в неделю, а ложные всплески, из-за которых раньше держали избыточный запас, почти исчезли.

Что делать, если уже развёрнут классический прогнозный контур

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

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

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

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

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

Ограничения модели и контроль качества прогноза

Архитектура Transformer держит длинные зависимости в ряду, но не снимает главных ограничений модели. Финансовый ряд нестационарен: смена режима волатильности ломает прогноз, который на истории выглядел устойчивым. Пропуски — выходные, остановки торгов, задержки публикаций — не заполняем средним: модель получает маску отсутствия и отличает настоящий ноль от пропуска. Выбросы гасит устойчивая функция потерь.

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

Как модель отличает пропуск от нуля?

Через маску отсутствия и календарные признаки. Нулевая доходность и отсутствие торгов — разные сигналы; если смешать, модель выучит ложную связь.

Как выявляется переобучение?

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

Что с мониторингом после передачи?

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

Обсудим задачу: вернёмся с оценкой и планом работ

Чтобы оценка проекта опиралась на факты, а не на предположения, до старта нам нужен минимум по исходным данным. Ниже — что стоит описать или прислать: этого достаточно, чтобы вернуться с планом работ, а не с общими словами.

• Постановка: какой сигнал или прогноз нужен, на каком горизонте, что считаем ошибкой первого и второго рода.
• Данные: источники котировок, сделок, отчётности и текстов, глубина истории, частота поступления, пропуски и корпоративные события.
• Целевая переменная: как формируется правильный ответ, кто и по какому правилу его размечает.
• Условия работы модели: пакетный режим или поток, допустимое время отклика, требования к воспроизводимости и аудиту расчётов.
• Инфраструктура и доступы: где лежат данные, какие политики разграничения прав, допустим ли вынос за периметр.
• Критерии приёмки: метрики качества, схема проверки на отложенных периодах, порог, при котором решение уходит в работу.

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

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