LSTM для финансовых временных рядов: архитектура и валидация

Почему LSTM временные ряды дают сбой на реальных данных

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

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

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

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

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

Измеримый эффект: что меняется в качестве прогноза

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

Качество на горизонте

• Ошибка считается отдельно для 1–5 шагов вперёд — видно, до какого момента прогноз пригоден для решения, а где начинается шум.
• Разброс ошибки между окнами валидации ограничен: метрика не разъезжается при смене участка истории.
• Доля пропущенных пиков падает, ложных срабатываний становится меньше — модель перестаёт сглаживать всплеск до среднего.

Смена режима и интерпретация

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

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

Варианты модели прогноза и их технические ограничения

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

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

Порядок работы: от аудита данных до передачи модели

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

1. Аудит данных. Проверяем пропуски, дубликаты, разрывы в котировках, выходные и праздники, режимы торгов, дробления и корпоративные события. Фиксируем, что чистим, а что восстанавливаем — и почему.
2. Схема признаков и скользящее окно. Определяем глубину истории и шаг окна, набор лагов, производных и режимных признаков. Нормализацию считаем только по обучающему отрезку, иначе будущее протекает в прошлое.
3. Сборка и обучение LSTM. Базовая конфигурация с регуляризацией и ранней остановкой — как точка отсчёта, с которой сравниваются все дальнейшие варианты.
4. Настройка гиперпараметров. Число слоёв и блоков, размер окна, доля отключения, скорость обучения. Поиск идёт на валидационном отрезке, тестовый не открывается до конца.
5. Честная схема валидации. Скользящее окно с обучением на прошлом и проверкой на следующем периоде, без перемешивания. Метрики считаем по нескольким периодам, а не по одному удачному.
6. Проверка на устойчивость. Сдвиг периода, смена волатильности, стресс-тест на резких движениях. Модель обязана обходить наивный прогноз, иначе она бесполезна.
7. Передача модели. Веса, схема препроцессинга, скрипт запуска и переобучения, метрики по периодам, документация по воспроизведению — чтобы модель жила у вас, а не у нас.

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

Артефакты и регламенты, которые остаются у заказчика

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

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

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

Кейс: прогноз спроса до и после переработки модели

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

Что было до переработки

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

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

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

• ошибка на горизонте восемь недель: 23% → 11%;
• доля пропущенных пиков: 38% → 9%;
• ложные всплески: минус треть, избыточный запас по спокойным позициям сократился;
• подготовка прогноза: два дня ручной работы → двадцать минут расчёта.

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

Что делать, если данных мало для обучения LSTM

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

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

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

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

Технические сомнения: переобучение, дрейф и онлайн-прогноз

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

Как отслеживается дрейф данных?

По входу сравниваем распределение признаков в текущем окне с обучающим — индекс стабильности и критерий Колмогорова–Смирнова. По выходу следим за ошибкой на накопленном факте. Выход за порог запускает переобучение, а контур продолжает считать на действующей версии.

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

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

Что происходит в режиме онлайн-прогноза?

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

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

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

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

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