Чому оптимізація торгової стратегії ламається на реальних даних
Підбір параметрів на історії майже завжди дає гарну криву: на графіку минулих років стратегія впевнено зростає, а на живому рахунку той самий код поводиться інакше.
Причина в тому, що оптимізація торгової стратегії підбирає значення під конкретний відрізок минулого, а не під механіку ринку — при перенавчанні на історії параметри кодують шум, якого більше не буде.
Перше джерело помилки — якість історичних даних.
В архівах трапляються пропуски на різких рухах, ціни за останньою угодою замість реальної глибини книги заявок, делістингові пари просто відсутні — і на такій вибірці тестується стратегія, яка в реальності торгувала б іншим інструментом.
Друга втрата — виконання. Прослизання угод і комісії з'їдають частину прибутку, якщо рахувати за ціною сигналу, а не за фактичною ціною угоди.
Розбіжність у часі виконання додає розрив між моментом появи сигналу й постановкою заявки: поки дані доходять до виконавця, ціна встигає піти, і частина угод закривається гірше за розрахункову.
У сумі виходить розрив між історією та реальністю: відібрані параметри не переносяться на нові умови, обсяг вибірки маскує перенавчання, а розбіжність у часі виконання робить результати невідтворюваними. Розбираємо, як це закривається.
Що змінюється в роботі: просадка, відгук, стійкість
Перебір параметрів ведемо не вручну, а через Optuna: однаковий набір даних, фіксоване зерно генератора, той самий спосіб розрахунку результату. Інакше прогони непорівнювані, і налаштування перетворюється на підгонку під один вдалий відрізок історії.
- Зниження просадки. Максимальна просадка скорочується, але важливіше друге — стискається час відновлення: рахунок повертається до попередніх максимумів за дні, а не тижні.
- Час відгуку на ринок. При зміні режиму — стрибку волатильності або звуженні різниці між цінами купівлі та продажу — параметри беруться з уже перевіреної області й перераховуються за хвилини, а не підбираються заново.
- Стійкість торгової логіки. Перевіряємо на відкладеному відрізку й на кількох режимах ринку: логіка, яка тримає результат поза вибіркою, не розсипається на першому нетиповому тижні.
- Контроль ризику на угоду. Ризик заданий часткою від капіталу, обсяг позиції рахується від поточної волатильності — серія з восьми збиткових угод поспіль перестає вибивати з допустимого рівня.
- Виконання й розриви даних. Частка скасованих і невиконаних заявок падає — вхід враховує ліквідність, а не лише сигнал. Пропуск свічок або перезапуск сервісу не ламає стан: позиція відновлюється з останнього знімка, дублі не відкриваються.
Кожен пункт вимірюємо до і після на одному й тому самому наборі даних, тому у звіті видно, яка саме правка дала зсув.
Режими налаштування стратегії: порівняння підходів
Режим налаштування визначає, звідки беруться значення параметрів стратегії і як швидко вони змінюються. На практиці обирають між трьома контурами: повний прогін по архіву угод, підстроювання прямо в живому режимі та комбінація обох.
Порівнюємо їх за трьома речами — скільки триває перерахунок, як поводиться результат на відкладеній ділянці історії та що відбувається при зміні режиму ринку.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Підбір параметрів на історії | Повторювані режими ринку, є довгий архів угод і запас часу на прогін | Підгонка під минулі дані: набір тримається, поки статистика ринку не змістилася. Разовий перерахунок — і знову потрібен новий прогін |
| Адаптивне підстроювання в живому режимі | Режими змінюються часто, горизонт утримання позиції короткий | Реакція на шум і «тремтіння» параметрів, зростання кількості угод та витрат. Помилка в правилі перерахунку тиражується на весь потік |
| Гібридний контур виконання | Довгий горизонт: потрібна і стійкість базового набору, і відгук на зміну режиму | Складніше в супроводі: потрібні коридори дрейфу, журнал змін і точка повернення до попереднього набору |
Межі задаємо явно: історія дає базові значення й коридор, у межах якого живому контуру дозволено рухати параметри, а вихід за межу зупиняє торгівлю до ручного розбору. Перерахунок робимо за розкладом, а не на кожному тіку.
Етапи впровадження: від аудиту даних до передачі
Порядок робіт однаковий і для стратегії, яку тільки збирають на історичних даних, і для вже працюючої системи: спочатку переконуємося, що дані описують реальність, потім — що модель виконання заявок їй відповідає, і тільки після цього випускаємо в роботу.
- Аудит журналів угод. Звіряємо вивантаження зі звітами майданчика за часом, обсягом, ціною, комісіями та частковими виконаннями, прибираємо дублікати й розриви, відновлюємо пропущені інтервали. Підсумок — набір даних, розбіжність якого з брокерським звітом пояснювана й відтворювана.
- Реконструкція схеми виконання заявок. Описуємо, як ордер потрапляв у книгу заявок, де виникало прослизання, як оброблялися відмови і скільки часу минало від сигналу до угоди. Без цього результат на історії не переноситься на живий рахунок.
- Формалізація правил стратегії. Вхід, вихід, розмір позиції, ліміти ризику й умови зупинки фіксуємо як однозначні правила — їх можна перевірити рядок за рядком, а не «за логікою автора».
- Складання контуру перевірки. Ті самі дані, витрати й код для всіх прогонів: версіонуємо набори й параметри, щоб будь-який результат відтворювався повторно.
- Підбір параметрів на навчальному відрізку з обмеженням кількості комбінацій, що перебираються — інакше вибрані значення описують шум, а не закономірність.
- Перевірка на незалежному відрізку. Дані не беруть участі в підборі; додатково перевіряємо стійкість зі зсувом вікна й за підвищених витрат. Стратегія, яка тримається лише на одному інтервалі, у роботу не йде.
- Виведення в експлуатацію та передача. Налаштовуємо контроль ризику, журналювання й повідомлення про відхилення, прописуємо регламент зупинки, передаємо команді замовника документацію й конфігурації та супроводжуємо перші робочі прогони.
Пакет передачі: конфігурації, політики, регламенти
Робота закінчується не звітом, а набором артефактів, з якими команда замовника далі живе сама.
Конфігурація торгового контуру зберігається в репозиторії з контролем версій, зміни проходять перевірку, а не правляться руками на сервері — тому будь-яку версію стратегії можна розгорнути повторно й отримати зіставний результат на тому самому історичному відрізку.
- Конфігурація торгового контуру: точки підключення до біржі, робочі інтервали, список інструментів, ліміти на обсяг позиції та кількість одночасних заявок.
- Політики доступу до біржових ключів: торгові ключі без права виведення коштів, окремий контур лише для читання для збору даних, строк життя ключа та порядок ротації.
- Правила розподілу ризику: максимальна частка капіталу на позицію, денний і тижневий стоп, поведінка системи при розриві зв'язку з біржею.
- Регламент перегляду параметрів: що перевіряємо за розкладом, а що — за тригером (просадка глибша за розрахункову, зміна режиму волатильності), хто ухвалює рішення і де воно фіксується.
- Документація зі стратегії: логіка входу й виходу, перелік параметрів із допустимими межами, відомі обмеження та умови виведення стратегії з роботи.
- Журнали вимірювань: збережені прогони на історичних відрізках, метрики до і після зміни параметрів, позначка про те, яка версія конфігурації стояла в робочому режимі.
Такий пакет дозволяє передати супровід іншій команді або повернутися до стратегії через місяці — без розбору логів і відновлення логіки з пам'яті.
Кейс: просадка втричі менша при тому самому обороті
Що було до
Замовник торгував за набором правил, який жив у нотатках: вхід за відчуттям «назріває рух», стоп переносився вручну, якщо ціна «має розвернутися», утримання позиції нічим не обмежувалося.
На історії це давало максимальну просадку 26%, але окремі місяці закривалися в плюс — слабке місце не виглядало проблемою. Повторити результат удруге було неможливо: причини входів не фіксувалися, а ручні правки на живому рахунку розходилися з тестовим прогоном.
Що змінили
Вхід формалізували: сигнал приймається після закриття бара й підтвердження старшого таймфрейму, а не за торкання рівня. Перенесення стопа замінили трейлінгом за волатильністю — множник підбирався за розкидом ціни, а не за бажанням зберегти позицію.
Утримання обмежили горизонтом: якщо рух не підтверджується за задану кількість барів, позиція закривається за правилом, а не за настроєм.
Чим підтверджено
Кожен прогін рахувався в Backtrader і потрапляв до журналу вимірювань: набір параметрів, дата, просадка, профіт-фактор, кількість угод, частка виходів за стоп-правилом. Навчальний і утриманий відрізки ділили заздалегідь, тому підгонка під історію відсіювалася одразу.
Просадка знизилася з 26% до 9% при тому самому обороті, профіт-фактор зріс з 1.1 до 1.4, близько 40% сигналів відсікає фільтр входу. Ручні втручання прибрано, а перегляд набору після зміни режиму ринку займає години замість днів.
Чим перевірка на історії відрізняється від реального часу?
Архівний розрахунок іде за вже закритими свічками: ціна угоди відома заздалегідь, заявка виконується миттєво й повністю. У живій торгівлі між сигналом і угодою минає час, ціна встигає піти, а частина обсягу залишається невиконаною.
Звідси й береться розбіжність архіву та живої торгівлі — і майже завжди вона складається не на користь стратегії.
Перше джерело — затримка виконання. Вона складається з ділянок: розрахунок сигналу, надсилання заявки, постановка в чергу, підтвердження угоди.
На спокійному ринку ці частки секунди непомітні, але на різкому русі відрив фактичної ціни від розрахункової стає систематичним, а не випадковою перешкодою — модель раз за разом входить гірше, ніж передбачала.
Друге джерело — комісії та прослизання. Комісія біржі списується з кожної угоди і в архівному розрахунку часто просто не закладена.
Прослизання залежить від глибини книги заявок: велика заявка сама зсуває ціну, і на тонкому ринку фактична ціна угоди помітно гірша за ту, за якою модель «здійснила» угоду на графіку.
Контроль розбіжності ставиться до виведення стратегії в роботу, а не після. Модель проганяється з тими самими обмеженнями, що й живий контур: затримка, комісія, межа обсягу однієї заявки, скасування невиконаного залишку.
Потім журнал живих угод звіряється з архівним прогоном на тому самому інтервалі — рахуємо частку виконаних заявок, середній відрив ціни угоди від розрахункової та різницю підсумкового результату.
Поки розбіжність укладається в допуск, стратегія працює обмеженим обсягом і допуск перевіряється повторно. Якщо його порушено, перераховуються параметри й правила входу, а не «підкручується» історія під потрібний результат.
Обмеження та ризики: дані, комісії, прослизання
Формально стратегія може показувати стійкий результат на історії, але на реальну торгівлю це переноситься не автоматично. Архіви майданчиків містять пропуски: години простою, обриви потоку угод, різні інтервали свічок на одному інструменті.
Якщо логіка зав'язана на обсяг і кількість угод, такі діри спотворюють перевірку — вона бачить ліквідність, якої на той момент не було.
Друге обмеження — мінливість умов самого майданчика: тарифи, мінімальний крок ціни, правила округлення й скасування заявок змінюються, і минула конфігурація втрачає сенс.
На тонких парах додається прослизання: заявка виконується за ціною гіршою за очікувану, а широка різниця між купівлею та продажем з'їдає частину прибутку ще до входу в позицію. І жоден прогін на історії не гарантує дохідності — це перевірка гіпотези, а не обіцянка результату.
Як зрозуміти, що стратегія перенавчена на історію?
Ознака — результат різко падає при невеликому зсуві параметрів або на сусідньому інтервалі свічок. Перевіряємо на відрізку, який не брав участі в підборі, і дивимося на розкид, а не на найкращий прогін.
Що робити з пропусками в архіві майданчика?
Позначаємо їх як розрив і не заповнюємо вигаданими значеннями — інакше перевірка порахує неіснуючі угоди. На ділянках з обривами стратегія не оцінюється, а підсумок рахуємо за покритою часткою періоду.
Обговоримо задачу: що надіслати і як ми повернемося з планом
Щоб оптимізація параметрів торгової стратегії дала відтворюваний результат, а не підгонку під минуле, потрібні вихідні дані для розрахунку. Нижче — мінімальний набір, що покриває більшість задач; якщо чогось немає, скажіть одразу — підкажемо, чим замінити.
- Правила входу й виходу в поточній редакції: індикатори, умови спрацювання, логіка стопів і фіксації прибутку.
- Архів угод за період: вивантаження з термінала або з біржі в машинозчитуваному вигляді, з мітками часу та обсягом позиції.
- Обмеження за ризиком: допустима просадка, максимальна частка депозиту в одній позиції, ліміт на кількість угод.
- Перелік майданчиків та інструментів: спотовий чи строковий ринок, доступні пари, глибина історичних даних.
- Вимоги до виконання: ручний запуск, сигнали чи автоматична торгівля, допустима затримка реакції.
- Критерій успіху: метрики, за якими ви приймаєте результат — відношення дохідності до просадки, частка прибуткових угод, стійкість поза навчальною вибіркою.
Далі порядок співпраці простий: розбираємо надіслане, перевіряємо повноту історії та коректність розмітки угод, за потреби повертаємо список уточнень. Потім готуємо оцінку й план робіт — етапи, що перевіряємо на кожному, які метрики фіксуємо як критерій приймання.
Опишіть задачу у вільній формі й додайте те, що є під рукою, — повернемося з оцінкою та планом робіт і одразу скажемо, яких даних не бракує.
