Де ламається стандартний прогноз: коли потрібен фінансовий Transformer
Класичний збій виглядає так: модель показує рівну якість прогнозу на спокійній ділянці ринку — низька помилка, стійкий сигнал, — а через кілька днів після зміни режиму її передбачення розходяться з фактом у рази.
Помилка зростає не плавно, а ступенем: зміна волатильності, ліквідності або поява нового типу вхідних даних ламає звичні залежності, а модель продовжує працювати за логікою минулого режиму.
Причина — у природі даних. Фінансові ряди нестаціонарні: змінюється не лише розкид значень, а й самі зв’язки між ознаками, і дрейф ознак іде швидше, ніж цикл перерахунку.
Поки команда готує новий набір і перенавчає модель, значущість частини входів уже змістилася — а перевірка на історичному зрізі цього не показує, бо відбувалася на тому самому режимі, на якому навчали.
Лінійні моделі та бустинги на лагах програють тут першими: вони фіксують локальні залежності й погано переносять їх на зміну режиму.
Фінансовий Transformer тримає довгий контекст і зважує різнорідні сигнали — угоди, котирування, текстові потоки — через увагу, а не через жорсткий набір лагів.
Але архітектура сама по собі дрейф не лікує: якість прогнозу тримається на контурі, який помічає зміну режиму й перебудовує навчання під неї.
Розбираємо, як це закривається: режимозалежна валідація, контроль дрейфу ознак і перенавчання за подією, а не за календарем.
Що дає фінансовий Transformer у задачах прогнозу
Класичні моделі на ковзному вікні бачать лише останні точки ряду — подія з розтягнутою реакцією для них невидима. Механізм уваги в архітектурі Transformer зіставляє всю доступну історію одразу й зважує, які минулі інтервали справді пояснюють поточний рух. Довгі залежності в часі стають ознакою, а не шумом.
Стійкість до зміни режиму тримається на донавчанні, а не на перезбиранні набору ознак.
Коли волатильність і ліквідність поводяться інакше, ніж на навчальній ділянці, оновлення на свіжому вікні достатньо, щоб якість повернулася до робочого рівня — це години роботи інженера замість тижнів.
Швидкість перенавчання — прямий наслідок: нові дані додаються невеликими кроками, тому перерахунок під змінений ринок займає години, а не місяці, і не потребує заново розмічати історію.
Мультимодальні дані збираються в один контур: числові ряди, тексти розкриттів і календар подій потрапляють у спільний простір ознак. Сигнал, який не підтверджується другим джерелом, гаситься — частка хибних сигналів скорочується, а не зростає разом із числом входів.
Перевіряємо це на чесному розділенні за часом: навчання на минулому, оцінювання на майбутньому, без витоку даних. Дивимося частку хибних спрацювань на відкладеному відрізку, розкид метрики при зсуві вікна навчання й час до відновлення якості після зміни режиму.
Режими навчання та виведення: порівняння підходів
Вибір режиму впирається не в якість на демонстраційній вибірці, а в обсяг і розмітку даних, вимоги до затримки відповіді та пояснюваності рішення.
Фінансові ряди короткі, нестаціонарні, з рідкісними дорогими подіями — тому донавчання попередньо навченої моделі й ансамбль із деревами дають різний профіль помилок, і «найкращого» варіанта без контексту не існує.
Нижче чотири варіанти, між якими реально обирають на старті. Обмеження вказані ті, що проявляються на живих даних: перенавчання на короткому вікні, втрата пояснюваності, зростання часу виведення разом із числом моделей в ансамблі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Навчання з нуля | Довга історія, стійкі закономірності, є ресурс на розмітку | Потрібні великий обсяг даних і час; на коротких вибірках нестабільно, рідкісні події провалюються |
| Донавчання попередньо навченої моделі | Є базова модель на близьких за природою даних, потрібен швидкий вихід на робочу якість | Чутливе до зсуву розподілу; потрібен контроль перенавчання на малій вибірці й відкат до базової версії |
| Ансамбль із деревами рішень | Змішані й табличні ознаки, важлива пояснюваність внеску ознак | Слабший на послідовностях і тексті; довше виведення, більше моделей у супроводі |
| Класичні статистичні моделі | Потрібен прозорий базовий рівень і швидкий перерахунок на коротких рядах | Не вловлюють нелінійні зв’язки, швидко впираються в стелю якості |
Режим обирають за метрикою на відкладеному періоді, а не за якістю на навчанні, і заздалегідь фіксують правило відкату.
Донавчання й ансамбль не виключають одне одного: дерева беруть табличні ознаки, фінансовий Transformer — послідовність, а порівняння підходів іде на одному наборі перевірок.
Етапи впровадження: від аудиту даних до передачі моделі
На фінансових рядах ціна помилки в порядку етапів вища, ніж у більшості задач машинного навчання: модель, навчена на перемішаних даних, показує гарну метрику на валідації й розвалюється на живому потоці.
Тому фінансовий Transformer збираємо строго за кроками, де кожен наступний спирається на результат попереднього.
-
Аудит історичних даних. Дивимося глибину історії, пропуски, розриви сесій, корпоративні дії та зміни регламентів. Якщо інструмент торгувався не весь період, це фіксується в розмітці, а не затирається середнім.
-
Схема ознак. Визначаємо, які поля йдуть на вхід, з якими лагами та вікнами агрегації. Кожну ознаку перевіряємо на доступність у момент прийняття рішення — інакше вона приносить у модель майбутнє.
-
Налаштування навчання. Розбивка строго хронологічна, без випадкового перемішування. Підбираємо довжину контексту й регуляризацію під реальний дисбаланс подій.
-
Валідація моделі на відкладеному періоді. Останній відрізок історії тримаємо недоторканим до фіналу й додатково проганяємо ковзне вікно — так видно, чи деградує якість із часом.
-
Контроль витоків даних. Зсуваємо ознаки, прибираємо підозрілі, порівнюємо метрику до й після. Різкий провал — вірна ознака, що модель спиралася на підказку з майбутнього.
-
Передача та моніторинг. Віддаємо ваги, конфігурацію, скрипти розрахунку й набір метрик, за якими відстежується дрейф. Далі модель живе за регламентом перенавчання.
Артефакти проєкту: конфігурації, схеми та регламенти
Після здачі проєкту в замовника залишається не лише навчена модель, а й артефакти, за якими її можна відтворити, перевірити й перенавчити без участі авторів. Без них фінансовий Transformer перетворюється на чорну скриньку: прогнози йдуть, а пояснити чи полагодити їх нікому. Склад фіксуємо на старті й передаємо за актом.
- Конфігурація навчання — параметри архітектури, розмір ембедингів, число шарів і голів уваги, розклад швидкості навчання, відбір ознак, зафіксовані генератори випадкових чисел.
- Схема підготовки даних — конвеєр від сирих вивантажень до тензорів: правила роботи з пропусками й викидами, асинхронність звітності, нормалізація, нарізка вікон, захист від витоку майбутніх значень.
- Регламент перенавчання — тригери (дрейф вхідних розподілів, просідання метрик на відкладеному періоді), періодичність, порядок приймання нової версії перед заміною робочої.
- Опис метрик якості — якість ранжування, точність і повнота за класами, калібрування ймовірностей, порівняння з базовою моделлю на тому самому періоді.
- Документація моделі — карта ознак, призначення блоків, межі застосовності й відомі обмеження: на яких режимах ринку модель не перевірялася.
- Реєстр версій та інструкції команді — яка збірка зараз у роботі, чим відрізняється від попередньої, як відкотитися й як підняти середовище з нуля.
Кейс: прогноз ліквідності до та після впровадження
Прогноз ліквідності в цьому кейсі будувався за внутрішньоденними потоками: залишки на рахунках, вхідні та вихідні платежі, сезонність закриття періодів і податкових виплат.
Попередня модель спиралася на коротке вікно історії та ознаки, зібрані аналітиками вручну, тому на зміні режиму ринку й у дні пікових платежів точність помітно просідала.
Що було до впровадження
Частка помилкових сигналів трималася близько 18%: система видавала хибні сплески потреби в ліквідності й водночас пропускала реальні.
Аналітики виправляли вручну в середньому 40 прогнозів на тиждень, а перенавчання на нових даних займало майже два тижні — на момент оновлення сам режим уже змінювався, і помилки поверталися.
Що змінили й що вийшло
Ми перейшли на фінансовий Transformer з увагою за кількома горизонтами, реалізований на PyTorch: модель бачить і хвилинні потоки, і тижневий контекст, а не усереднене вікно.
Донавчання поставили на потік — оновлення на свіжих даних займає години замість тижнів, із перевіркою на відкладених періодах за принципом ковзного вікна.
Окремо закрили ризик перенавчання на нових даних: у перевірку додали аномальні дні — піки виплат і розриви ліквідності — і модель відбирається за стійкістю на них, а не за середньою помилкою.
Як підсумок: частка помилкових сигналів знизилася до 6%, число ручних правок аналітиків — до 7 на тиждень, а хибні сплески, через які раніше тримали надлишковий запас, майже зникли.
Що робити, якщо вже розгорнуто класичний прогнозний контур
Класичний прогнозний контур рідко можна просто вимкнути: на його виході висять регламентні звіти, ліміти й уже погоджені рішення.
Тому нову модель на Transformer ставлять поруч, а не замість — працююча система залишається джерелом істини, поки нова доводить якість на реальних даних, а не на історичних зрізах.
Інтеграція із наявною системою зводиться до однієї точки підключення: адаптер збирає ознаки з тих самих джерел і віддає обом моделям однаковий вхід, а прогнози приводить до спільної схеми з горизонтами й підписами рядів. Контракт для вітрин і сервісів рішень при цьому не змінюється.
Далі вмикається паралельний розрахунок у тіньовому режимі: обидві моделі рахуються на одному зрізі даних, і кожен прогноз зберігається з міткою джерела, часу розрахунку й набору ознак.
Це дає коректне порівняння прогнозів — помилка за кожним горизонтом, поведінка на викидах і розривах ряду, частка сигналів, які нова модель пропустила або знайшла зайвими.
Поступовий перехід іде за сегментами, а не за всім портфелем одразу: спочатку категорії з низькою чутливістю, де помилка не тягне за собою регламентних наслідків.
Зворотний відкат тримається на тому, що класичний контур не демонтовано й продовжує писати свої прогнози — перемикач повертає розрахунок на нього в межах одного циклу, без відновлення даних з архіву.
Саме тому такий перехід перестає бути ризиком для поточних розрахунків: нова модель спочатку доводить стійкість на вашій історії, і лише потім бере на себе частку навантаження.
Опишіть, як влаштований ваш прогнозний контур сьогодні, — повернемося з оцінкою та планом поетапного включення.
Обмеження моделі та контроль якості прогнозу
Архітектура Transformer тримає довгі залежності в ряду, але не знімає головних обмежень моделі. Фінансовий ряд нестаціонарний: зміна режиму волатильності ламає прогноз, який на історії виглядав стійким.
Пропуски — вихідні, зупинки торгів, затримки публікацій — не заповнюємо середнім: модель отримує маску відсутності й відрізняє справжній нуль від пропуску. Викиди гасить стійка функція втрат.
Перенавчання ловимо не випадковим розбиттям, а перевіркою ковзним вікном: навчання лише на минулому, перевірка — на наступному відрізку. Контроль прогнозу ведемо за горизонтами — помилка на день і на місяць розходиться в рази, і одна усереднена метрика це приховує.
Що робити при зміні ринкового режиму?
Модель не універсальна: при зсуві режиму якість падає. Тому в контур входить донавчання на свіжому вікні й ансамбль версій різних періодів — провал однієї версії не проходить у підсумковий прогноз.
Як модель відрізняє пропуск від нуля?
Через маску відсутності та календарні ознаки. Нульова дохідність і відсутність торгів — різні сигнали; якщо змішати, модель вивчить хибний зв’язок.
Як виявляється перенавчання?
За розривом помилки на навчальному й відкладеному відрізку та за числом епох без поліпшення. Рання зупинка й регуляризація — частина базової конфігурації, а не аварійний захід після провалу.
Що з моніторингом після передачі?
Передаємо дашборд: метрики за горизонтами, частка пропусків, дрейф вхідних розподілів, алерти за порогами й регламент донавчання з відкатом на попередню версію моделі.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Щоб оцінка проєкту спиралася на факти, а не на припущення, до старту нам потрібен мінімум за вихідними даними. Нижче — що варто описати або надіслати: цього достатньо, щоб повернутися з планом робіт, а не із загальними словами.
- Постановка: який сигнал або прогноз потрібен, на якому горизонті, що вважаємо помилкою першого та другого роду.
- Дані: джерела котирувань, угод, звітності й текстів, глибина історії, частота надходження, пропуски та корпоративні події.
- Цільова змінна: як формується правильна відповідь, хто і за яким правилом її розмічає.
- Умови роботи моделі: пакетний режим або потік, допустимий час відгуку, вимоги до відтворюваності й аудиту розрахунків.
- Інфраструктура та доступи: де лежать дані, які політики розмежування прав, чи допустиме винесення за периметр.
- Критерії приймання: метрики якості, схема перевірки на відкладених періодах, поріг, за якого рішення йде в роботу.
У відповідь ви отримуєте оцінку проєкту з розбивкою за етапами, план робіт із залежностями й строками, склад команди та перелік ризиків. Окремим блоком — що робимо з якістю даних: де чистимо, чим доповнюємо, де даних об’єктивно не вистачає і це змінює будову моделі.
Наступний крок — опишіть задачу у вільній формі: мета, дані, обмеження. Обговоримо її з інженерами, поставимо уточнювальні запитання й повернемося з оцінкою та планом робіт.
