Модель розходиться з бектестом: де ламається MLOps у трейдингу
Бектест майже завжди рівніший за живу торгівлю — питання в тому, наскільки.
Розходження закладається ще на навчанні: ознаки рахуються за даними, які на той момент ще не були доступні, склад інструментів береться за «тими, хто вижив», а витрати на виконання в розрахунок не потрапляють. Модель показує красиву криву там, де в неї просто не було шансу помилитися.
На живому ринку змінюється сам режим, а не лише дані. Просідає ліквідність усередині дня, зростає затримка між сигналом і виконанням, велика заявка рухає ціну проти нас.
Модель, навчена на трендовій ділянці, у боковику втрачає точність, і причина не в ринку, а в тому, що розгортання не відстежує зміну режиму.
Ручні перерахунки параметрів добивають картину. Гіперпараметри підкручують перед вечірньою сесією, ознаки перезбирають скриптом на локальній машині, ваги оновлюють копіюванням файлу, а реєстр версій моделей на кшталт MLflow так і не заводиться.
Через тиждень уже ніхто не відновить, яка версія моделі та який набір ознак дали сигнал у конкретній угоді — ні для розбору, ні для відкату.
«Найдорожче тут — не збиток за однією угодою, а неможливість пояснити результат», — каже наш інженер, який виводив такі системи в робочу експлуатацію.
Щоб розходження з бектестом стало керованою величиною, а не сюрпризом, розбираємо, де саме ламається MLOps у трейдингу і як це закривається.
Що дає керований життєвий цикл торгової моделі
Контроль версій моделей перестає бути папкою з файлами за датами. Кожен артефакт пов'язаний з версією коду, складом навчальної вибірки, набором гіперпараметрів і середовищем — із журналу видно, з чого зібрано конкретну версію, і її можна підняти заново на іншому вузлі. Це фундамент, на якому тримаються інші ефекти.
Відтворюваність навчання виводить розходження між прогонами з розряду загадок. Якщо модель під час перевірки показує не ті метрики, що під час навчання, причина шукається в трьох відомих місцях: дані, середовище, порядок подавання прикладів. Повторний запуск дає той самий результат, і спірні експерименти не доводиться переробляти з нуля.
Час до випуску моделі скорочується завдяки передбачуваному шляху: нова версія проходить ті самі ворота якості, що й попередня, а викладка в торговий контур — відпрацьовану процедуру, а не разову ручну операцію. Рутинний випуск перестає бути подією і займає хвилини замість днів.
Зниження відмов торгівлі — наслідок прямої перевірки сумісності: розходження набору ознак між навчанням і роботою на живих даних, дрейф вхідних розподілів і невідповідність версій ловляться на вході, а не в момент виставлення ордера.
Розбір інциденту йде за журналом рішень — видно, яка версія спрацювала, на яких даних і чому фільтр пропустив або відхилив сигнал.
Зібраний MLOps-контур робить життєвий цикл моделі перевірюваним: будь-яку версію можна перезібрати, порівняти із сусідньою і відкотити, не переписуючи торгову логіку.
Режими роботи MLOps-контуру в трейдингу: порівняння варіантів
Режими MLOps-контуру розрізняються тим, де зберігаються дані, де обчислюється модель і хто відповідає за випуск нової версії в роботу.
Повний цикл на стороні підрядника запускається швидше, розгортання в контурі замовника знімає питання щодо периметра даних, гібридний контур балансує обидві вимоги, а автоматичний випуск потрібен там, де модель помітно зміщується між перерахунками.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повний цикл на нашій стороні | Немає власної команди й потужностей, потрібен швидкий вихід на робочі сигнали, дані допустимо передавати | Передавання даних зовнішнім каналом, чутливі дані виносити не можна, час реакції на збій ділиться між сторонами |
| Розгортання у вашому контурі | Дані не покидають периметр, є вимоги безпеки, важлива низька затримка сигналу | Потрібні власні обчислювальні ресурси й чергова зміна, оновлення йдуть через погодження, частина експлуатації залишається на вашій команді |
| Гібридний контур | Навчання й експерименти зручніше вести в нас, розрахунок сигналів — у вас, ознаки можна знеособити | Потрібна синхронізація версій ознак і моделей, відтворюваність результату підтверджувати складніше |
| Автоматичний випуск із контролем дрейфу | Моделі перенавчаються регулярно, дані йдуть потоком, потрібен передбачуваний цикл оновлення | Потрібні метрики якості на робочих даних і автовідкат, пороги дрейфу калібруються під конкретний ринок |
Вибір рідко буває бінарним. Пакетний перерахунок закриває щоденне навчання й перезбирання ознак, а потоковий перерахунок вмикають точково — там, де затримка сигналу справді впливає на результат.
На практиці робоча конфігурація для більшості задач — гібридний контур з автоматичним випуском і контролем дрейфу.
Етапи впровадження контуру: аудит даних, схема, налаштування, передача
Перш ніж розгортати контур, ми відновлюємо фактичну картину: звідки надходять котирування, як обчислюються ознаки, де губиться історія виконання заявок.
Без цього моніторинг перетворюється на спостереження за випадковими метриками, а розходження між перевіркою на історії та живим потоком випливає вже на реальних позиціях.
- Аудит даних і торгових журналів — звіряємо джерела котирувань, глибину історії та повноту записів про виконання, шукаємо розриви й розходження між логами майданчика та внутрішнім обліком.
- Схема контуру — фіксуємо, де живуть дані, ознаки, моделі й сигнали, як розділені навчання та виконання, які відмови вважаються допустимими.
- Версіонування моделей і ознак — кожна торгова модель прив'язана до набору даних і параметрів, відкат до попередньої версії проходить без перезбирання всього контуру.
- Налаштування моніторингу — якість сигналів, затримка розрахунку, частка відхилених заявок і дрейф розподілу ознак; оповіщення прив'язані до порогів, а не до факту падіння процесу.
- Перевірка на історії — прогін на накопичених даних: звіряємо поведінку моделі з еталоном, дивимося стійкість до зміни режиму ринку та до пропусків у потоці.
- Перевірка на живому потоці — тіньовий режим: модель рахує сигнали, але заявки не надсилає; порівнюємо з робочою логікою й дивимося, як поводиться моніторинг під навантаженням.
- Передача контуру — документація за схемою, регламенти перенавчання й відкату, розбір інцидентів із вашою командою та порядок подальшого супроводу.
Артефакти передачі: конфігурації, регламенти, схеми доступу
Проєкт вважається зданим не тоді, коли модель показала метрику на історичних даних, а коли контур живе без авторів. Тому в кінці роботи ми передаємо пакет артефактів, за яким інша команда зможе експлуатувати й розвивати систему. Що залишається у замовника на руках:
- Реєстр моделей і версій — навчальний період, набір ознак, метрики на відкладеній вибірці та статус кожної версії: у контурі, у резерві або знята.
- Конфігурації контуру — параметри розрахунку ознак, розклади перенавчання, пороги захистів і ліміти; розгортаються з репозиторію без ручних правок.
- Політики доступу — ролі за середовищами: хто випускає модель, хто змінює ліміти, хто лише читає журнали.
- Регламент випуску й відкату — обов'язкові перевірки перед публікацією, критерії зупинки та порядок повернення до попередньої версії за лічені хвилини.
- Журнали аудиту — хто, коли і на якій підставі змінював модель, дані або обмеження; вивантаження для внутрішнього контролю.
- Документація контуру — схема потоків даних, зовнішні залежності, точки відмови та відповідальні за кожен вузол.
- Інструкції для чергової зміни — що робити при розходженні метрик з очікуваними, як зупинити торгівлю і кого оповістити.
Пакет синхронізовано з робочим контуром: зміна в репозиторії відображається в документації, тому через пів року знання не доводиться збирати з листування.
Кейс: розходження моделі та фактичного виконання угод
До впровадження сигнали рахувала одна версія моделі, а заявки йшли за артефактом, вивантаженим до останнього перенавчання. Версії розходилися на кілька діб, і це випливало вже у відкритій позиції: сигнал на вихід є, угода не закрита.
Звірку журналу сигналів із журналом виконання робили вручну — розбір одного торгового дня займав 3-4 години й майже не покривав нічні сесії.
Що змінили в контурі MLOps
Модельний контур зібрали навколо реєстру версій MLflow: кожне збирання отримує незмінний номер, і той самий номер іде в сигнал і в заявку — розходження ловиться на вході, а не в позиції.
Контроль перевели на відтворення сесії: історичний зріз даних і фактичні угоди порівнюються автоматично, розбіжності позначаються із зазначенням версії моделі та набору параметрів.
Відкат — перемикання вказівника в реєстрі, без перезбирання й ручної правки конфігурацій на сервері виконання.
Метрики до і після
- Частка сигналів без парної угоди: 4-6% → 0.2%
- Розбір торгового дня: 3-4 години вручну → 10-15 хвилин за готовим звітом
- Повернення до попередньої версії моделі: близько доби → хвилини
- Покриття звіркою: лише денна сесія → усі сесії, включно з нічними
Розбір інциденту перестав залежати від того, хто вів зміну. Розходження відтворюється на тих самих даних і тією самою версією моделі — замість пошуку винного ланки команда отримує конкретний крок, на якому розійшлися сигнал і виконання угоди.
Чим відрізняється тіньовий випуск моделі від канареечного?
Різниця в тому, куди потрапляє відповідь моделі. Під час тіньового випуску копія бойового трафіку йде на нову версію, але її сигнали нікуди не надсилаються: розрахунок іде паралельно, а ми звіряємо передбачення двох версій на тому самому потоці даних.
Під час канареечного випуску частину живого трафіку — спочатку 1%, потім 5, 25 і 100 — обслуговує нова версія, і її рішення вже впливають на портфель.
Тіньовий режим піднімаємо зеркалюванням трафіку, наприклад через Istio, і він відповідає на питання «модель рахує так само коректно?»: чи сходяться розподіли сигналів, як змінилася латентність інференсу, скільки відмов на рідкісних інструментах.
Обмеження чесне — тіньовий прогін не перевіряє зв'язку з виконанням: ордери, ліміти ризику, обробку часткового виконання й повторних заявок.
Канареечний випуск перевіряє саме це, тому він іде другим. Поступове включення версії прив'язуємо до метрик: просадка щодо еталонної версії, частка відхилених ордерів, розходження передбачень із фактичним результатом.
Автоматичний відкат спрацьовує за порогом, а не за дзвінком чергового — інакше версія залишається в бою, поки хтось дивиться графіки.
Типові помилки під час порівняння режимів випуску: вмикати канарейку відразу, минаючи тіньовий етап; звіряти версії на різних вікнах ринку — за спокійного й волатильного режиму це різні розподіли; не фіксувати еталонну версію, через що незрозуміло, що саме погіршилося.
Окрема пастка — спільний для двох версій набір ознак: перерахували його під нову модель, і відкат уже не повертає минулу поведінку.
На практиці порядок такий: тіньовий прогін на кількох торгових сесіях, потім канарейка з кроком за часткою трафіку й автоматичним поверненням. Обидві ступені працюють на одному конвеєрі підготовки даних — інакше розходження версій не відокремити від розходження самих даних.
Технічні сумніви: дрейф даних, затримки, доступи, відкат
Перед стартом команди перевіряють чотири речі: що буде з моделлю при зміні режиму ринку, скільки триває шлях від сигналу до заявки, як відкотити версію, хто може втрутитися в систему.
Як ви відстежуєте дрейф даних?
Порівнюємо розподіл вхідних ознак і якість прогнозів на ковзному вікні з еталонним профілем навчальної вибірки. Розходження вище порога запускає перенавчання й оповіщення, а не тиху деградацію. Профіль, вікно й поріг лежать у конфігурації — правило відтворюване.
Як тримаєте затримку застосування моделі?
Базові розрахунки ознак ідуть заздалегідь, у момент рішення залишається лише легкий розрахунок прогнозу.
Затримку вимірюємо за перцентилями, а не за середнім, і тримаємо бюджет на всьому ланцюжку «дані — сигнал — заявка»: джерело котирувань, що відстало, позначає сигнал неактуальним, і в ринок він не йде.
Як відкотити версію моделі?
Модель, схеми ознак і конфігурація версіонуються одним набором. Відкат — повернення до попереднього набору артефактів однією командою, без перезбирання; тіньовий прогін на історії підтверджує коректність. Глибина зберігання розрахована на відкат на кілька кроків назад.
Як влаштовані доступи й аудит?
Права розділені за ролями: розробник не виводить модель у бій самотужки, запуск потребує підтвердження. Навчання, викатка й ручні правки параметрів потрапляють у незмінний журнал з автором і часом.
Обговорімо контур під ваш торговий процес і команду
Оцінка проєкту в MLOps для торгового контуру залежить не від кількості моделей, а від того, як сигнал проходить шлях від розрахунку до заявки і де на цьому шляху залишилися ручні кроки. Тому обговорення задачі починаємо з розбору поточного виконання, а не з презентації. Щоб повернутися з чіткою оцінкою, корисно мати під рукою:
- перелік стратегій: які моделі працюють, на яких даних навчаються і як часто перенавчаються;
- поточний шлях сигналу від розрахунку до виставлення заявки — з вузькими місцями та ручними діями;
- джерела даних: котирування, новинні та альтернативні потоки, їхній обсяг і частоту оновлення;
- вимоги до затримки й допустимого простою в години торгів;
- регламент ризику: ліміти, автостопи, хто має право зупинити контур;
- інфраструктуру: власні потужності або хмару, ізоляція середовищ, порядок видавання доступів і хто приймає результат.
У відповідь надсилаємо карту контуру: збирання й підготовка даних, навчання й перевірка моделі, викладка в торговий контур, спостереження й відкат на попередню версію.
До неї — план впровадження за етапами: що робимо першим, які артефакти передаємо в кожній точці приймання, які залежності залишаються на стороні замовника. План приходить документом з етапами, строками, зонами відповідальності та переліком ризиків.
Перший крок — технічна сесія на 45–60 хвилин з інженером, який буде вести проєкт: розбираємо потік даних і регламент ризику, домовляємося про критерії готовності. Опишіть задачу у вільній формі — повернемося з оцінкою та планом робіт.
