Walk-forward аналіз стратегії: де ламається тест на історії
Однократний прогін на історії майже завжди закінчується однаково: параметри підбираються під конкретну ділянку минулого і на ній же показують рівну криву. Стратегія виходить на живий ринок — і та сама логіка входу дає просідання, якого не було в жодному тестовому сценарії.
Помилки в коді може не бути взагалі: підгонка й оцінка йшли на одних і тих самих даних, тому тест перевіряв пам'ять, а не правило.
Метод walk-forward розриває цей зв'язок. Ряд угод ріжеться на послідовні вікна: на першому стратегія оптимізується, на наступному — лише перевіряється, потім вікно зсувається і цикл повторюється.
Параметри жодного разу не «бачать» ділянку, на якій їх оцінюють, а підсумок складається із серії незалежних прогонів замість одного вдалого підбору — схема докладно розібрана у Пардо.
Сенс не в гарній кривій, а в розкиді між вікнами. Якщо дохідність і глибина просідання тримаються на зсунутих відрізках, стійкість результату підтверджена: видно, як логіка переживає тренд, боковик і різкий розворот.
Якщо показники розсипаються від зсуву вікна на один крок — це переоптимізація параметрів, і ціна такого відкриття на тесті неспівмірна з ціною на робочому рахунку.
Далі розбираємо, як це закривається: як нарізати вікна і скільки тримати в кожному, які метрики рахувати за серією прогонів, де проходить межа між робочим просіданням і ознакою нестійкості.
Що дає walk-forward аналіз стратегії на практиці
Один прогін за історичними даними відповідає на питання «яку дохідність стратегія показала на минулому відрізку» — і мовчить про те, що буде на нових даних.
Налаштування, підібрані під конкретний період, часто тримаються рівно до першого зсуву ринку: у звіті цифра гарна, а на живому рахунку йде серія збиткових угод.
Walk-forward аналіз влаштований інакше. Історія ріжеться на послідовні вікна: на одному параметри підбираються, на наступному перевіряються наосліп, потім вікно зсувається вперед і процедура повторюється.
На виході — не одна цифра, а ряд незалежних результатів: видно розкид дохідності між вікнами і те, як він змінюється з часом.
З цього розкиду читаються робочі речі. Частка хибних сигналів показує, скільки входів стратегія відкрила б на даних, яких не бачила під час налаштування.
Стійкість стратегії перевіряється зміною ринкового режиму — тренд, боковик, сплеск волатильності — і видно, в якому з них логіка розвалюється. Якщо параметри стрибають від вікна до вікна, а результат тримається на одному вдалому відрізку, це підгонка, а не робоче правило.
Виживаність на нових даних — головний критерій. Коли результат у перевірних вікнах зіставний з навчальними і не залежить від одного періоду, стратегію можна переносити в реальну торгівлю з передбачуваною поведінкою.
У цьому і вимірюваний сенс walk-forward аналізу: не «підняти дохідність», а відділити стійку поведінку від випадкового збігу.
Порівняння схем перевірки: ковзне вікно та його альтернативи
Схема перевірки визначає, скільки історії бачить модель у момент рішення і на якому відрізку рахується результат. Помилка у виборі коштує дорожче за невдалі параметри: стратегія впевнено проходить перевірку, а на живих даних розходиться з нею.
Схеми прогону розрізняються двома речами — чи росте вікно навчання і як часто модель перенавчається.
Нижче — варіанти, між якими реально обирають на старті. Вибір фіксується до першого прогону: підміна схеми після перегляду результатів перетворює перевірку на підгонку.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Ковзне вікно | нестабільний ринок, стратегії з навчанням на історії | більше прогонів, вищий час рахунку |
| Однократна перевірка | швидкий відбір гіпотез, прикидка перед глибоким розбором | один відрізок історії, високий ризик підгонки |
| Розширюване вікно | довга історія, стійкий режим ринку | стара історія тисне на модель, вага свіжих даних падає |
| Перехресна перевірка | порівняння моделей на коротких рядах | перемішування порушує порядок часу і заносить майбутнє в навчання |
На практиці схеми комбінують: однократною відкидаємо явно слабкі гіпотези, ковзним вікном перевіряємо фіналістів. Перехресну перевірку беремо лише там, де порядок спостережень не важливий.
Як проходить впровадження системи перевірки стратегій
Впровадження системи перевірки стратегій починається не з коду, а з домовленості про те, що вважається достовірним результатом.
Поки правила перевірки не зафіксовані, гарний графік дохідності залишається предметом віри, тому роботу ведемо етапами — від аудиту даних до приймання контуру.
- Аудит даних. Звіряємо джерела між собою, шукаємо пропуски, розриви, дублі та сплески, перевіряємо торговий календар. На виході — звіт про придатність рядів і перелік ділянок, які потрібно відновити або виключити.
- Схема перевірки. Фіксуємо параметри walk-forward аналізу: вікно навчання, вікно перевірки, крок зсуву, горизонт утримання позиції. Відбір іде лише на навчальному вікні — інакше результат завищений.
- Налаштування прогонів. Задаємо комісії та прослизання, правила ребалансування, обмеження за ліквідністю, журналювання кожного кроку. Прогін має відтворюватися з тих самих вхідних файлів.
- Контрольні прогони. Пропускаємо через контур явно слабкі та явно стійкі стратегії — система зобов'язана впевнено їх розрізняти. Якщо випадковий набір правил проходить відбір, шукаємо помилку в схемі.
- Приймання контуру. Звіряємо результати на незалежному наборі даних, перевіряємо відтворюваність, фіксуємо регламент оновлення рядів і передаємо документацію вашій команді.
Після приймання контур розширюється без переробки: нові ринки, горизонти та правила відбору додаються за незмінної схеми перевірки.
Конфігурації, регламенти та документація контуру перевірки
Замовник отримує не звіт з гарними кривими, а робочий контур walk-forward аналізу, який його інженери можуть запустити, змінити й переперевірити без нас.
Тому в передачу входить не лише код, а й усе, що робить результат відтворюваним: конфігурації прогонів, правила доступу, регламенти та документація. Нижче — перелік того, що залишається в команди замовника.
- Файли конфігурацій прогонів — довжина вікна навчання і вікна перевірки, крок зсуву, набір інструментів, комісії та прослизання, обмеження на розмір позиції. Кожен прогін однозначно прив'язаний до версії конфігурації, тому результат завжди можна повторити.
- Схема розкладки артефактів — де лежать угоди, метрики по кожному вікну, криві дохідності та зведення; як ім'я папки пов'язане з версією конфігурації та набором даних.
- Політики доступу — ролі та права: хто змінює параметри, хто лише запускає прогін, хто переглядає результати. Окремо — журнал змін конфігурацій з автором і причиною правки.
- Регламент переперевірки — як часто запускається перевірка на свіжих даних, які події вважаються підставою для позапланового прогону (зміна режиму ринку, просідання за порогом, зростання частки відхилених угод).
- Набір еталонних прогонів — зафіксовані результати на незмінному історичному відрізку. Порівняння з ними показує, що після правок контур рахує по-старому, а не «тихо» розійшовся.
- Документація контуру — опис кожного параметра: що він означає, у яких межах змінюється і як його зміна відображається на метриках. З переліком типових помилок і ознак, за якими їх розпізнати.
- Інструкції з передачі та відновлення — покроковий запуск з нуля на чистому середовищі, порядок дій при збої, де дивитися журнали виконання і як відкотитися на попередню версію конфігурації.
- Критерії приймання — список перевірок, за якими команда замовника приймає контур: збіг метрик з еталоном, успішний запуск силами своїх інженерів, відтворюваність на іншому наборі даних.
Поки інженер замовника не запустить прогін самостійно і не отримає метрики, що збігаються з еталонними, контур ми не вважаємо переданим — це і є межа приймання.
Кейс: як перезбирання схеми перевірки прибрало хибні сигнали
Замовник — команда, що торгує стратегією на кількох криптовалютних парах. Перевірка будувалася на одному довгому відрізку історії: параметри підбиралися на всіх даних, і на них же рахувався підсумок. На папері крива зростала рівно, а в торгівлі одразу після запуску пішли серії збиткових тижнів.
Що показав розбір
Причина розпалася на три частини. Між навчальним і перевірним вікнами не було зазору, тому індикатори на межі навчання підглядали вперед. Відбір параметрів ішов по всій історії, включно з тією її частиною, яка потім слугувала перевіркою.
Режими ринку — тренд, боковик, різкі рухи — не розмічалися, і конфігурація, стійка на тренді, мовчки ламалася в боковику.
Метрики до і після
Схему перезібрали як walk-forward аналіз на Backtrader: ковзні вікна навчання і перевірки з фіксованим кроком, зазор між ними, відбір параметрів лише за навчальною частиною, прогін по відрізках, що не перетинаються, урахування витрат і прослизання.
До перезбирання перевірку проходили 8 вікон із 10, а розходження з реальною торгівлею сягало 34%. Після підтвердження отримали 3 вікна з 10 — решту відбраковували до виходу в ринок, зате розходження впало до 7%, а повний цикл перерахунку скоротився з шести годин до сорока хвилин.
Що робити, якщо стратегія вже торгує на реальному рахунку
Якщо стратегія вже торгує на реальному рахунку, зупиняти її заради перевірки не потрібно і ризиковано: пауза рве накопичену статистику і залишає відкриті позиції без управління.
Контур walk-forward аналізу ставиться поряд з бойовою системою і працює на тому самому потоці ринкових даних, не надсилаючи жодної заявки. Живий рахунок при цьому продовжує торгувати у звичайному режимі.
Перший етап — тіньові прогони. Перевірювана версія отримує ті самі котирування і ті самі затримки виконання, що й працююча, але її рішення лише записуються в журнал.
За кілька тижнів набирається вибірка угод, яку можна зіставити з тим, що зробила б нова логіка на тому самому відрізку ринку.
Звірка з історією закриває другу половину задачі. Ми проганяємо walk-forward по минулих вікнах і порівнюємо не підсумкову дохідність, а розподіл: частку прибуткових угод, середнє і максимальне просідання, час утримання, поведінку на спокійних і волатильних ділянках.
Розходження з живою торгівлею вище заданого порогу майже завжди означає зсув у моделі — підглядання в майбутнє при розрахунку ознак або різницю в джерелі даних.
Впровадження без зупинки йде сходинками: тіньова копія, потім паралельний рахунок з мінімальним обсягом, далі переведення частки капіталу і повний.
На кожній сходинці заздалегідь заданий критерій відкату: якщо метрики розходяться з очікуваними, версія знімається, а робочий рахунок продовжує торгувати. Перевірка не створює простою і не вимагає тимчасово йти з ринку.
Технічні сумніви: дані, режими та стійкість
Інженерні сумніви щодо walk-forward аналізу зазвичай стосуються не самого методу, а входу: якість даних, довжина вікна, повторюваність прогону. Нижче — відповіді на питання, які спливають при проєктуванні стенда, до написання першого рядка логіки.
Як обробляємо пропуски в котируваннях?
Ділимо за природою: календарні пропуски, розриви ліквідності, збої джерела. Свічки не інтерполюємо — відновлена ціна на ринку не існувала і завищує метрики.
Бар отримує прапорець якості, стратегія пропускає його або закриває позицію за правилом з конфіга, однаковим на навчанні і на відкладеній ділянці.
Як обираємо горизонт перевірки?
Прив'язуємо до числа незалежних вікон, а не до довжини історії. Вікно накриває повний цикл зміни режиму, інакше оцінка ловить одну фазу. Беремо 8–12 послідовних вікон: навчання на одному, перевірка на наступному, крок уперед. Так видно, деградує стратегія чи тримається.
Що з відтворюваністю результатів?
Фіксуємо знімок даних з контрольною сумою, параметри, зерно генератора і версії залежностей; прогін іде в ізольованому середовищі. Звіт збирається лише з цих вхідних, тому повторний запуск дає ту саму криву, а розходження пояснюється конкретною зміною.
Як ураховуємо зміну режиму ринку?
Ковзне вікно перенавчає модель на свіжих даних — цим walk-forward аналіз і відрізняється від єдиної перевірки на всій історії. Метрики рахуємо за режимами окремо: тренд, боковик, висока волатильність. Видно, де стратегія ламається і який запас міцності потрібен.
Обговоримо вашу задачу: зберемо контур перевірки під ваші дані
Оцінка задачі з walk-forward аналізу починається з вихідних даних, а не із загальних побажань: за ними видно, який контур перевірки взагалі має сенс збирати.
Опишіть, як формується сигнал, на якій історії він перевіряється, з якою частотою надходять дані і які витрати виконання ви закладаєте. Цього достатньо, щоб розбір задачі зайняв одну розмову, а не листування на тиждень.
Що надіслати разом з описом:
- вивантаження історії — угоди, котирування або ознаки, у тому вигляді, у якому вони є у вас;
- правила входу і виходу та список параметрів, які ви перебираєте;
- поточну схему перевірки: навчальне і тестове вікно, крок зсуву, число прогонів;
- метрики рішення — дохідність, просідання, частка прибуткових періодів;
- обмеження: затримка виконання, комісії, ліміти за обсягом, заборона на короткі позиції;
- як фіксуються результати прогонів і порівнюються між собою конфігурації.
Далі повертаємося з оцінкою і планом робіт: етапи, строки за кожним етапом, склад контуру — генератор вікон, правила відбору параметрів, звіт про стійкість і протокол відтворення прогонів.
Якщо по ходу розбору видно, що даних не вистачає або постановка веде до перенавчання, скажемо про це до старту, а не в середині робіт.
