Чому бектестинг AI-стратегій ламається на реальних даних
Бектестинг AI-стратегії на історії майже завжди показує дохідність кращу, ніж подальша торгівля. Розрив виникає не через модель: прогін і живий ринок по-різному виконують одну й ту саму заявку.
В історії заявка закривається за ціною бару, на ринку — за тією, що залишилася в книзі заявок після всіх, хто прийшов раніше.
Не враховані витрати виконання тихо добивають результат. Комісія, спред, прослизання на обсязі та затримка між сигналом і відправленням заявки накопичуються на кожній угоді, і стратегія, яка в прогоні малює рівну криву, у реальних торгах іде в мінус.
Окремий рядок витрат у звіті важливіший за підсумкову дохідність: він показує, де система втрачає гроші, а не де їх обіцяє.
Третя причина — відсутність повторюваності експерименту. Якщо не зафіксовано зріз даних, склад інструментів, версію ознак і випадкові стани, два прогони однієї стратегії дають різні криві, і порівняння гіпотез втрачає сенс. Повторюваність тут не про зручність, а про те, чи можна взагалі довіряти висновку.
Зазвичай усе це впирається у вузьке місце розрахункового контуру: перебір параметрів триває годинами, перевірка на стійкість до зсуву вікна не вкладається в цикл дослідження, а розбіжність прогону й реальних торгів виявляється вже після запуску. Розбираємо, як це закривається на рівні архітектури платформи.
Що дає платформа: вимірюваний ефект на кожному етапі
Ефект платформи вимірюється, а не описується словами: кожен прогін залишає метрики, за якими видно, що змінилося. Нижче — чотири ділянки, де різниця помітна відразу після першого місяця роботи.
Час одного прогону
Кеш проміжних розрахунків і паралельний обрахунок інструментів стискають повний прогін портфеля з годин до десятків хвилин. Це змінює режим роботи: стратегію встигаєш прогнати на кількох станах ринку того самого дня, а не «до наступного тижня».
Відтворюваність результатів
Прогін фіксує версію коду, зріз даних, параметри, зерно генератора й оточення — повторний запуск дає ті самі метрики. Журнал експериментів ведемо в MLflow, тому видно, яка гіпотеза що дала і до якого стану коду її відкотити.
Швидкість перевірки гіпотез
Єдиний формат даних, готові шаблони стратегій і автозвіт скорочують шлях від ідеї до цифри до кількох годин. За день перевіряється 10–15 конфігурацій замість однієї-двох: слабкі гіпотези відкидаються до того, як у них вкладено розробку.
Усунені відмови й перенавчання
Відхід від ручних вивантажень прибирає розсинхрон даних і метрик, втрату артефактів і падіння на довгій історії: прогін або завершується цілком, або падає з діагностикою.
Перевірка на відкладеній вибірці та за кроками в часі відсікає стратегії, які добрі на історії й розсипаються на живих даних — поруч із дохідністю виводяться метрики стійкості.
Порівняння режимів бектестингу AI-стратегій: таблиця вибору
Вибір режиму прогону визначає не лише швидкість, а й те, які класи помилок ви взагалі побачите. Пакетний розрахунок обчислює всю історію одним проходом по матриці дохідностей — він годиться для грубого перебору гіпотез, але не відтворює порядок виконання заявок.
Розрахунок за подіями проганяє стрічку бар за баром і повторює реальний цикл: заявка, угода, комісія, прослизання.
Потоковий режим тримає стратегію в тому самому вигляді, у якому вона піде в торгівлю, тому тільки він чесно показує лаг відгуку моделі на нові дані. Режим бектестингу обирають під задачу, а не за замовчуванням — таблиця нижче.
| Режим прогону | Коли підходить | Обмеження режиму |
|---|---|---|
| Пакетний розрахунок | Первинний відсів сотень гіпотез і пошук закономірностей в ознаках на довгій історії | Не враховує чергу заявок і часткові виконання — результат виходить оптимістичнішим за реальний |
| Розрахунок за подіями | Фінальна перевірка перед виведенням: комісії, прослизання, ліміти, заборона коротких позицій | Повний перебір параметрів на великій історії триває годинами, вартість прогону зростає з кількістю подій |
| Потоковий режим | Перевірка реакції в реальному часі: лаг відгуку моделі, дрейф ознак, обрив каналу даних | Складніше відтворити: потрібен детермінований журнал вхідного потоку й повтор того самого вікна |
| Гібридний прогін | Потрібен і широкий пошук, і чесна оцінка: відсів пакетно, фінал — за подіями | Вимагає узгоджених визначень ознак у двох контурах, інакше результати не сходяться |
Як ми будуємо платформу: етапи інженерної роботи
Роботу починаємо не з коду, а з аудиту даних: звідки надходить історія котирувань, як обробляються пропуски, спліти й дивіденди, чи збігаються часові інтервали джерел.
Поки це не перевірено, стратегія гарно виглядає на історії та розходиться з реальними угодами — тому схему розрахунку для бектестингу й метрики фіксуємо письмово заздалегідь.
- Аудит даних. Звіряємо джерела, перевіряємо повноту історії, знаходимо діри й дублі, приводимо торгові календарі та часові пояси до одного вигляду. Підсумок — звіт про придатність даних і список обмежень.
- Схема розрахунку. Фіксуємо метрики, правила входу й виходу, облік комісій, затримок виконання та прослизання — щоб розрахунок не розходився з реальною торгівлею.
- Прототип на вузькому зрізі. Збираємо розрахунковий контур на одному інструменті й короткому періоді: гіпотеза перевіряється швидко, а помилки в логіці видно до масштабування.
- Налаштування оточення. Розгортаємо ізольовані середовища, налаштовуємо відтворюваність прогонів і зберігання результатів разом із параметрами запуску — будь-який розрахунок можна повторити й порівняти.
- Перевірка на контрольних наборах. Дані для перевірки відділяємо заздалегідь, дивимося стійкість на різних періодах і ринкових режимах, відсікаємо варіанти, які тримаються лише на перенавчанні під історію.
- Промисловий контур. Ставимо прогони за розкладом, додаємо звіти й оповіщення про розбіжності між очікуваною та фактичною динамікою — платформа працює без ручних запусків.
- Передача й навчання команди. Віддаємо документацію, доступи, розбір архітектури й проводимо спільні прогони на ваших задачах, щоб ваші фахівці могли змінювати стратегії та дані самостійно.
Що передаємо на руки: конфігурації, схеми, регламенти
Проєкт із бектестингу AI-стратегій вважаємо зданим не тоді, коли модель відпрацювала на демонстраційному наборі, а коли ваша команда відтворює будь-який прогін без нас.
Тому передаємо не презентацію з графіками, а робочий контур: конфігурації, схеми розрахунку, політики доступу й регламенти, за якими платформа живе далі.
- Конфігурації платформи — версіонований набір параметрів: джерела котирувань, вікна ребалансування, комісії та прослизання, обмеження на розмір позицій.
- Схеми розрахунку — конвеєр від завантаження даних до метрик: де обчислюються дохідність, просадка й оборотність, як виключається підглядання в майбутнє.
- Специфікація ознак — які ряди й похідні показники подаються в модель, як фіксуються версії ваг під час перенавчання.
- Політики доступу — ролі учасників, права на дані, запуск прогонів і правку конфігурацій, журнал дій.
- Документація — архітектура, локальний запуск, розбір типових збоїв з ознаками й порядком дій.
- Регламенти супроводу — періодичність перенавчання, контроль розбіжності тестового й робочого результату, відкат на попередню версію стратегії.
- Приймальні прогони — еталонні сценарії із зафіксованими результатами: після ваших правок видно, що розрахунок не розійшовся.
Розбираємо контур разом із вашою командою: інженер проходить по кожному артефакту й відповідає на запитання щодо розрахунків і доступів. Опишіть задачу — повернемося з оцінкою та планом.
Кейс: від розрізнених скриптів до єдиного розрахункового контуру
До: розрізнені скрипти
До переїзду розрахунок жив у десятках окремих ноутбуків Jupyter і локальних скриптів: у кожної стратегії свій набір історичних даних і свої проміжні вивантаження.
Прогін одного набору параметрів тривав близько шести годин і не вкладався в робоче вікно, тому перевірку запускали вночі, а правки вносили вже після.
Результат залежав від оточення: дві копії одного скрипта на різних машинах давали різну дохідність, і до третини чисел доводилося перевіряти вручну.
Після: єдиний розрахунковий контур
Зібрали єдиний розрахунковий контур бектестингу: одне джерело історичних даних із версіонуванням зрізів, незмінні оточення під кожен запуск і журнал параметрів, який однозначно відновлює будь-який прогін.
Важкі розрахунки розбили на незалежні задачі й розпаралелили, а результати складаються в спільне сховище разом зі зрізом даних і версією коду.
Час прогону скоротився з шести годин до сорока хвилин — гіпотезу перевіряють кілька разів на день, а не раз на добу.
Частка відтворюваних результатів зросла з 70 до 99%: той самий набір параметрів на тому самому зрізі дає той самий підсумок, а розбіжності пояснюються новими ринковими даними, а не оточенням.
Кількість спірних результатів, які розбирали вручну, впала майже в п'ять разів — порівняння стратегій іде за спільними метриками, а не за листуванням.
Що робити, якщо частина розрахунків уже автоматизована
Автоматизований розрахунковий контур — не перешкода, а точка опори: зазвичай у ньому вже є вивірені правила підготовки даних, масиви історичних котирувань і логіка виконання заявок.
Ми починаємо з інвентаризації — фіксуємо джерела даних, формати зберігання, розклад прогонів і те, які метрики команда вважає еталонними.
Після цього по кожному блоку вирішуємо окремо: переносимо як є, обгортаємо в тонкий шар сумісності або залишаємо на місці й лише підключаємося до нього.
Напрацювання при цьому зберігаються: індикатори, правила фільтрації, обробка пропусків і корпоративних подій переїжджають у новий контур без переписування логіки.
Ми приводимо їх до єдиного інтерфейсу, щоб рушій бектестингу AI викликав їх так само, як власні модулі, — інакше порівняння старих і нових результатів втрачає сенс.
Безшовне вбудовування перевіряється паралельним прогоном: попередній і новий контури рахують той самий історичний відрізок, а ми звіряємо криву дохідності, максимальну просадку, кількість угод і розподіл результатів за періодами.
Розбіжність вище обумовленого порога зупиняє перемикання — спочатку знаходимо причину. На практиці це найчастіше різне заповнення пропусків, момент обліку комісії або розходження в правилах перенесення позиції через ніч.
Переведення йде за стратегіями, а не цілком: до останнього кроку залишається можливість повернутися до попереднього розрахунку й порівняти обидві картини поруч.
Відтворюваність тримаємо на версіонуванні історичних даних і журналі всіх параметрів прогону — через місяць будь-який минулий результат піднімається й пояснюється без археології по скриптах.
Технічні сумніви інженерів перед стартом
Перед першим запуском інженер ставить одні й ті самі запитання: чи вистачить історії, де гарантія, що розрахунок правильний і чи не вийде гарна крива на минулих даних, яка розсиплеться на живому ринку.
Ці сумніви знімаємо до розробки — тут помилка в розрахунку коштує не бага, а неправильного рішення про запуск стратегії.
Нижче — короткі відповіді на технічні заперечення, які найчастіше випливають на етапі оцінки.
Історію доведеться чистити вручну?
Завантажувач приводить ряд до єдиного часового поясу, перераховує корпоративні дії та позначає пропуски, а не заповнює їх мовчки. Окремо підтягуємо делістинговані інструменти, інакше розрахунок зміщений у бік тих, що вижили.
Як зрозуміти, що стратегія не підігнана під минуле?
Навчальне й перевірне вікна розділені, ковзна перевірка йде за послідовними періодами, результат рахується лише на небачених даних. Комісії та прослизання закладені в розрахунок, а не у звіт.
Як підключаються біржові та брокерські джерела?
Працюємо і з потоковими підключеннями, і з вивантаженнями у файлах: схема полів, часовий пояс і точність позначки часу описані для кожного джерела. Дублікати відсікаються за ключем інструмент-час, розриви довантажуються, розбіжності між джерелами потрапляють у журнал.
Як ви переконуєтеся, що розрахунок коректний?
Є еталонні сценарії із заздалегідь відомою відповіддю — послідовність угод, комісії, дивіденди. Той самий прогін повторюємо незалежною реалізацією й звіряємо журнал угод, а на короткому вікні з живим ринком — розрахункові угоди з фактичними.
Обговоримо задачу й повернемося з оцінкою та планом
Для старту обговорення задачі достатньо описати її в термінах стратегій, даних і результату — тоді оцінка спирається на інженерну реальність, а не на загальні міркування.
Спеціально готувати пакет документів не потрібно: підійдуть вивантаження, нотатки аналітика або короткий опис ідеї.
- Стратегії. Логіка входу й виходу, набір інструментів, горизонт утримання позиції, правила управління ризиком, частота сигналів.
- Вихідні дані для оцінки. Які історичні ряди вже є, за який період і з якою деталізацією, у якому форматі та де лежать; якщо даних немає — з яких джерел їх брати й чи є до них доступ.
- Вимоги до звітності. Ключові метрики — дохідність, максимальна просадка, частка прибуткових угод; чи потрібні розрізи за періодами й інструментами і в якому вигляді звіт зручний вам.
- Критерії якості. Як відрізняємо робочу стратегію від підгонки під історію: перевірка на відкладеному періоді, ковзне вікно, порівняння з базовим сценарієм.
- Обмеження. Строки, доступи до даних та інфраструктури, розміщення — хмара або закритий контур, кількість одночасних прогонів.
- Користувачі та сценарії. Хто працює з платформою — аналітик, трейдер, ризик-менеджер: від цього залежать інтерфейс і розмежування прав.
Порядок подальших кроків однаковий: розбираємо ввідні, уточнюємо незрозуміле й повертаємося з планом робіт — етапи, склад, що знадобиться від вас на кожному. Якщо частина даних поки закрита, оцінимо за тим, що є, і окремо зазначимо, що вплине на строки.
