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

Чому LSTM часові ряди дають збій на реальних даних

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

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

На перевірці така модель виглядає точною, бо в неї вже підмішано відповідь: похибка на живих даних виявляється в рази вищою за перевірочну.

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

Випадковий поділ на навчання й перевірку це маскує — сусідні за часом спостереження майже дублюють одне одного, тому перевірка підтверджує те, що модель уже бачила.

Третя причина — рідкісні, але значущі події: розриви, стрибки волатильності, зміна режиму. В історії їх одиниці, тому модель вчиться усереднювати хвіст розподілу й систематично недооцінює ризик саме там, де він критичний.

Далі розбираємо, як це закривається: послідовна валідація за часом, зазор між навчальним і перевірочним відрізком, режимні ознаки й постійний контроль на живому потоці.

Вимірюваний ефект: що змінюється в якості прогнозу

Якість прогнозу на LSTM ми вимірюємо не однією цифрою на відкладеній вибірці, а набором перевірок, повторюваних на різних ділянках історії. Точкою відліку слугує наївний прогноз «завтра буде як сьогодні»: якщо модель не обіграє його на потрібному горизонті, цінності в ній немає.

Якість на горизонті

• Похибка рахується окремо для 1–5 кроків уперед — видно, до якого моменту прогноз придатний для рішення, а де починається шум.
• Розкид похибки між вікнами валідації обмежений: метрика не роз'їжджається при зміні ділянки історії.
• Частка пропущених піків падає, хибних спрацювань стає менше — модель перестає згладжувати сплеск до середнього.

Зміна режиму та інтерпретація

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

Кожен пункт фіксуємо у звіті про валідацію разом із графіком похибки за вікнами — замовник бачить, де модель стійка, а де її показання варто переперевіряти.

Варіанти моделі прогнозу та їхні технічні обмеження

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

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

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

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

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

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

Артефакти та регламенти, які залишаються у замовника

Проєкт вважається зданим не коли метрика на відкладеному вікні влаштувала, а коли модель можна перенавчити й пояснити без нас.

Тому в приймання входить не лише код, а й усе, що робить поведінку ряду перевірюваною: зафіксовані дані, конфігурації середовищ і правила роботи з часовими зрізами.

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

Кожен артефакт приймається за фактом, а не за наявністю файлу: ми запускаємо навчання на вашій стороні й звіряємо метрики з еталонним прогоном. Якщо розходження виходить за обумовлений допуск, пункт доопрацьовується до здачі.

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

Замовник — дистриб'ютор з кількома сотнями позицій і вираженою сезонністю. Планування закупівель трималося на ручних правилах: історія продажів, коефіцієнт на попередній період, ручна правка під акції.

На горизонті двох тижнів це працювало, далі прогноз розходився з фактом, а піки — старт сезону, розпродаж, велике відвантаження — правило не бачило взагалі.

Що було до переробки

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

Що змінили і що вийшло

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

Додали календар промо, лагові ознаки та ковзні статистики, а якість рахуємо не загальною похибкою, а окремо за горизонтом і за піковими тижнями.

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

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

Що робити, якщо даних мало для навчання LSTM

Коротка історія — це насамперед перекіс між кількістю параметрів і обсягом спостережень: мережа запам'ятовує шум навчального відрізка й на відкладеній ділянці програє простій ковзній статистиці.

Тому починаємо не з архітектури, а з базової лінії — авторегресії або лінійної моделі на дохідностях. Якщо мережа не обіграє її на кількох послідовних вікнах, ускладнювати далі нічого: це нормальний інженерний висновок, а не провал.

Регуляризація за малої вибірки дає більше, ніж глибина. Залишаємо один шар, обмежуємо кількість прихованих блоків, вмикаємо проріджування між шарами й окремо на рекурентних переходах, обмежуємо норму ваг і зупиняємо навчання за валідаційною ділянкою, а не за кількістю проходів.

Допомагає й зміна представлення: замість цін подаємо прирости й оцінку волатильності, приведені до зіставного масштабу.

Перенесення навчання закриває дефіцит історії: попередньо навчаємо на довгих рядах схожих інструментів, потім доучуємо на короткому цільовому відрізку, заморожуючи частину шарів.

Прийом працює, поки режими зіставні — інакше мережа тягне за собою чужу динаміку, і це видно на перших же перевірочних вікнах.

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

Рідкісні події розбираємо окремо й оцінюємо за часткою правильних сигналів, а не за середньою похибкою. За короткої історії частіше виграє гібрид: базова модель задає рівень, мережа вчиться на її залишках.

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

Метрика на відкладеній вибірці не говорить, як LSTM-модель поведеться на живому потоці котирувань. Інженерна команда запитує по суті: чи є перенавчання, як ловиться дрейф, коли запускається перенавчання і що відбувається в режимі онлайн-прогнозу.

Як відстежується дрейф даних?

За входом порівнюємо розподіл ознак у поточному вікні з навчальним — індекс стабільності та критерій Колмогорова–Смирнова. За виходом стежимо за похибкою на накопиченому факті. Вихід за поріг запускає перенавчання, а контур продовжує рахувати на чинній версії.

Як часто перенавчаєте модель?

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

Що відбувається в режимі онлайн-прогнозу?

Ознаки рахуються на ковзному вікні, прогноз віддається з фіксованим бюджетом затримки, при деградації контур перемикається на резервну версію. У проді контролюємо похибку, частоту спрацювань і стабільність входів — проблема видна раніше, ніж її помітить бізнес.

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

Щоб повернутися з оцінкою та планом етапів, а не із загальними міркуваннями, нам потрібен від вас мінімум ввідних — їх вистачає, щоб розкласти роботу на блоки й визначити склад команди. Нижче те, що ми зазвичай уточнюємо на першій розмові про прогнозування часових рядів на LSTM.

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

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