Автоматичне перенавчання моделей: де ламається прогноз
Крипторинок перемикає режим швидше, ніж модель машинного навчання встигає адаптуватися.
Волатильність, ліквідність і кореляції між інструментами перебудовуються за лічені дні, а прогноз продовжує спиратися на закономірності попереднього режиму — і впевнено видає сигнали там, де їх уже немає.
Дрейф даних відбувається у двох шарах. Спочатку зміщуються вхідні розподіли: ознаки, які раніше розділяли зростання й падіння, втрачають розділювальну здатність.
Потім проявляється дрейф концепції — сам зв’язок ознак із розподілом дохідностей стає іншим, і закономірність, на якій будувався сигнал, перетворюється на шум.
Найнебезпечніше те, що старіння моделі майже не видно за історичними метриками. Якість сигналу падає не обвалом, а поступово: частка прибуткових угод знижується на кілька відсотків, просідання підростає, а на контрольній вибірці картина залишається благополучною.
Ручне донавчання запізнюється на тижні — поки аномалію помітять, зберуть свіжі дані та перевірять гіпотезу, ринок встигає змінити режим ще раз.
Розбираємо, як перенавчання перетворюється з ручної операції на керований процес: за якими ознаками ловити дрейф, що вважати тригером запуску і як перевіряти, що оновлена модель справді краща за попередню.
Ефект від регулярної актуалізації прогнозу
Коли перенавчання запускалося вручну раз на квартал, модель продовжувала торгувати за закономірностями минулого режиму.
Зміна волатильності ламала прогноз непомітно: частка помилкових сигналів зростала поступово й виявлялася вже за просіданням, а аналітик вручну звіряв ознаки та метрики, замість того щоб розбирати причини розбіжностей.
Керований цикл змінює картину. Перенавчання запускається за тригером — дрейф розподілу ознак, падіння метрики на свіжому вікні, надходження нового обсягу даних.
Версія публікується лише після перевірки на відкладеному відрізку, де виключено витік майбутніх значень, і лише якщо перевищує поточну за цільовою метрикою та за стійкістю на різних ринкових режимах.
У вимірюваних величинах це виглядає так: час реакції на зміну режиму — один цикл навчання замість тижнів очікування; розкид якості між вікнами падає, і прогноз перестає бути вдалим лише на одному типі ринку; частка помилкових сигналів знижується завдяки відсіюванню версій, які не пройшли поріг; навантаження на аналітика зміщується з ручних прогонів на розбір відхилень.
Реєстр версій тут — не формальність. MLflow зберігає для кожної версії набір даних, параметри й метрики, тому зміни пояснювані, а повернення до попередньої версії займає хвилини.
Це прибирає окремий клас відмов — модель не «виїжджає» мовчки, а підсумок циклу можна порівняти з попереднім.
Режими оновлення моделі: порівняння підходів
Ринок змінює режим швидше, ніж модель старіє «природним чином»: зміщується розподіл ознак і дохідностей, і модель, навчена на минулому режимі, починає систематично помилятися.
Від способу оновлення залежить затримка між зміною режиму та реакцією системи, а також ризик, який ми беремо на себе в момент підміни ваг.
Чотири схеми, між якими реально обирають під час побудови автоматичного перенавчання моделей:
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Планове оновлення | Режими змінюються повільно, потік стабільний | Період задається навмання: між перенавчаннями модель торгує застарілими залежностями |
| Запуск за дрейфом | Розбіжність розподілів і падіння якості на свіжих даних | Потрібен налаштований детектор і поріг, інакше хибні спрацювання та зайві прогони |
| Потокове донавчання | Важлива реакція в межах годин | Підлаштування під шум останніх угод, «забування» ранніх закономірностей |
| Повне перезбирання | Змінюється набір ознак або логіка сигналу | Довгий цикл, не рятує за швидкого розвороту ринку |
Будь-який режим замикається на вікно перевірки: нова версія оцінюється на відкладеному відрізку свіжих даних і в тіньовому режимі на живому потоці, і лише потім отримує частку капіталу. Попередні ваги зберігаються, тому відкат займає хвилини.
Конвеєр перенавчання: від сигналу дрейфу до випуску моделі
Перенавчання — не регламент «раз на тиждень», а замкнений конвеєр із точками контролю: сигнал про деградацію надходить із даних, а рішення про випуск ухвалюється за метриками на однакових для старої та нової версії періодах.
Без версіонування артефактів і передбачуваного відкату такий цикл перетворюється на некерований експеримент на живому капіталі.
- Розбір поточного циклу. Фіксуємо вікно історичних даних, склад ознак, метрику якості сигналів і подію, за якою взагалі запускається перенавчання.
- Виявлення дрейфу. Порівнюємо розподіл ознак і якість сигналів на свіжому відрізку з еталонним: зсув режиму ринку видно раніше, ніж падіння метрики за закритими угодами.
- Підготовка вибірки. Перезбираємо набір під актуальний режим, прибираємо витоки майбутніх даних, приводимо частку рідкісних подій до їхньої реальної частоти.
- Перевірка версії. Кандидат іде на відкладений період і стрес-сценарії — різкий обвал, зупинка торгів; дані та параметри навчання фіксуємо в MLflow.
- Канарковий випуск. Нова версія отримує обмежену частку сигналів, стара торгує далі: обидві оцінюються на одному ринку, тому порівняння коректне.
- Відкат моделі. Поріг за просіданням і розбіжністю з очікуваною поведінкою повертає попередню версію автоматично — за хвилини, а не за торгову сесію.
Комплект постачання: конфігурації, схеми та регламенти
Комплект постачання зібрано так, щоб автоматичне перенавчання моделей жило всередині вашої інфраструктури, а не в листуванні з підрядником. Передаємо не лише код, а й те, що зазвичай залишається в головах: звідки брати дані, коли модель вважається деградованою і як її відкотити.
- Конфігурація циклу навчання — розклад і тригери: дрейф вхідних розподілів, просідання метрики на відкладеній історії. Поріг допуску моделі до торгівлі задано явно і змінюється без правки коду.
- Схема даних — джерела й частота збору, нормалізація, обробка пропусків і викидів, перевірки цілісності на вході. Сирі та агреговані ряди лежать окремо — перерахунок не потребує повторного вивантаження.
- Документація ознак — економічний сенс, вікно розрахунку, джерело й поведінка в аномальних умовах для кожної. Плюс порядок додавання нової ознаки без зупинки циклу.
- Журнал версій моделі — зв’язка моделі з набором даних, версією коду, гіперпараметрами та складом ознак; метрики на даних, яких модель не бачила, і автор запуску. Будь-яка версія відтворювана.
- Регламент відкату — умови спрацювання, хто вирішує, перемикання на попередню збережену версію, цільовий час повернення та перевірка після. Запобіжник зупиняє торгівлю при розбіжності прогнозу з фактом.
- Регламент спостереження та чергування — які показники дрейфу дивляться, з якою періодичністю, кому йдуть оповіщення і що перевірити при розбіжності.
Після передачі ваші інженери самі запускають перенавчання та змінюють склад ознак; наша участь потрібна лише на складних змінах логіки.
Кейс: як зросла стійкість прогнозу на зміні режиму
Стратегія торгувала на десятках інструментів, а модель перенавчали вручну — раз на квартал, за розкладом.
Поки ринок стояв в одному режимі, якість прогнозу трималася; при зміні режиму — стрибку волатильності та розпаді звичних кореляцій — модель продовжувала спиратися на застарілі залежності, і частка помилкових сигналів за тиждень зростала з 8% до 19%.
Зібрали контур автоматичного перенавчання: детектор дрейфу порівнює розподіл вхідних ознак і якість на ковзному вікні з еталонним профілем, і при виході за поріг запускається навчання моделі-кандидата.
Нову версію спочатку ганяємо в тіньовому режимі поруч із робочою, і лише при зіставному або кращому результаті на відкладеному відрізку вона стає в бойовий контур; відкат на попередню версію — одна команда. Оркестрацію конвеєра тримаємо на Airflow.
Метрики до та після:
- частка помилкових сигналів на зміні режиму: 19% → 7%;
- час від виявлення дрейфу до версії в роботі: 3–5 діб → 4 години;
- аварійні втручання аналітика: 10–12 на місяць → 1–2.
Окремо прогнали історичні ділянки зі зміною режиму: нова версія виводиться раніше, ніж просідання стратегії стає помітним за рахунком.
Ручний контроль залишився лише на підтвердженні випуску тіньової гілки — стійкість стратегії тепер тримає контур, а не реакція чергового аналітика.
Чим відрізняється тригерна зміна моделі від планової?
Календарний розклад перенавчає модель за фіксованим інтервалом, без огляду на стан ринку. Сильна сторона — передбачуваність: обчислювальні ресурси плануються заздалегідь, кожен цикл відтворюваний, відкат на попередню версію відпрацьований.
Слабке місце — затримка реакції: якщо режим змінився незабаром після чергового циклу, модель працює на застарілих залежностях до наступного вікна, і якість сигналів деградує непомітно.
Тригерна зміна спирається на ознаку дрейфу — розбіжність передбачень із фактом і зсув розподілу вхідних даних на ковзному вікні. Поки відхилення нижче порога спрацювання, модель не чіпають; коли сигнал стійко його перевищує, запускається перенавчання.
Затримка реакції вимірюється годинами, а не тижнями, але платити за це доводиться налаштуванням чутливості.
Головний ризик — хибні спрацювання. Різкий ринковий викид і справжня зміна режиму на короткому вікні виглядають однаково, тому кожна подія тягне за собою зайвий цикл навчання та ризик підлаштувати модель під шум.
Лікується це вимогою стійкості: відхилення має триматися кілька вікон підряд, поріг на повернення в норму задається окремо й нижче, між перенавчаннями діє мінімальний інтервал.
Тригер виграє там, де режими змінюються рідко, але різко, а застаріла модель дорого коштує за якістю сигналів. Календар сильніший при плавній еволюції ринку, дорогому циклі навчання та жорстких вимогах до відтворюваності — планова зміна простіше перевіряється на історичних даних.
Робоча схема зазвичай гібридна: рідкісне календарне вікно як страховка, тригер за дрейфом як основний контур.
Технічні сумніви, які варто зняти до старту
Перед передачею циклу навчання на супровід інженерна команда замовника ставить п’ять питань. Вони не про якість моделі на історії, а про те, що станеться з нею на живих даних через місяць.
Як ви перевіряєте підгонку під історію?
Метрику вважаємо на відкладеному відрізку, який модель не бачила, і порівнюємо з ковзним вікном. Розрив між навчанням і перевіркою тримаємо у звіті — його зростання видно раніше, ніж він стане збитком.
Що відбувається із затримкою даних?
Кожну ознаку помічаємо моментом, коли вона реально доступна, а не моментом події. Навчання йде на тому самому потоці, що й торгівля, тому затримка не маскується.
Як перевіряються гіпотези?
Гіпотеза — окрема гілка з фіксованим вікном даних і однією метрикою. Порівнюємо на спільному періоді, інакше різницю з’їдає зміна режиму ринку.
Як переглядаються ознаки?
Перегляд — планова процедура за розкладом і за тригером падіння метрики. Новий набір проходить той самий контур перевірки, попередній залишається для відкату.
Як забезпечити відтворюваність навчання?
Версіонуємо дані, конфігурацію та код — прогін повторюється в тій самій точці. Інакше покращення не відрізнити від випадкового пересіву.
П’ять відповідей і є каркасом регламенту, за яким навчання передається на супровід.Обговоримо задачу: з чого починається робота
Щоб повернутися з оцінкою та планом робіт, на першій розмові нам достатньо розібрати шість речей — готове технічне завдання на цьому етапі не потрібне, питання ставимо ми.
- Постановка задачі. Яке рішення ухвалює модель і що залежить від його якості: розмір позиції, момент входу, відмова від угоди. Чим ясніший зв’язок між прогнозом і дією, тим точніше визначимо, що саме перенавчати.
- Поточний цикл навчання. Як модель оновлюється зараз: за розкладом, вручну чи не оновлюється взагалі. Шукаємо розрив у контурі — підготовка даних, навчання, перевірка, викладка в торгову логіку.
- Перелік даних. Доступні джерела: котирування, стакан, угоди, новинний фон, метрики самого бота. Важливі глибина історії та пропуски — від цього залежить, на якому відрізку перевіряти стійкість.
- Критерії якості. Що вважаємо деградацією: просідання точності, зростання помилки на волатильних ділянках, зміну профілю угод. Фіксуємо метрики й пороги, за яких запускається перенавчання.
- Обмеження торгового контуру. Швидкість викладки нової версії, доступи до рахунку, вимоги до відкату на попередню модель, поведінка в моменти різких рухів.
- Точка приймання. Як переконаємося, що система працює: перевірка на відкладеному відрізку історії, тіньовий запуск поруч із поточною логікою, строк спостереження.
Після розмови ми письмово фіксуємо постановку задачі, критерії якості та план робіт за етапами — і повертаємося з оцінкою строків.
