Генетичний алгоритм замість ручного перебору параметрів
Ручна переоптимізація стратегії виглядає передбачувано: фахівець бере історичний ряд, запускає прогін, змінює поріг входу, знову рахує, рухає розмір позиції, потім рівень стопу.
Один цикл займає від десятків хвилин до годин, і за зміну перевіряються кілька десятків поєднань — при тому що простір параметрів вимірюється тисячами комбінацій.
Проблема не лише у швидкості. Пошук відбувається послідовно, а набір зрештою підганяється під останню ділянку історії: параметри, що спрацювали в попередньому режимі волатильності, ламаються при зміні тренду.
Додайте залежність від однієї людини — з її відходом логіку підбору ніхто не відновить, і оптимізацію починають заново.
Генетичний алгоритм замінює перебір еволюційним пошуком. Задаються межі параметрів, функція пристосованості та обмеження за ризиком, далі працює популяція наборів: сильні комбінації передають значення нащадкам, частина мутує, слабкі відсіюються.
За один запуск оцінюються тисячі поєднань, і пошук сходиться до області оптимуму, а не до випадкової вдалої точки.
Стійкість перевіряється не на одному відрізку: пристосованість рахується за кількома незалежними вікнами, тому відібрані параметри тримаються за різних режимів ринку. На виході — не одне «найкраще» число, а діапазон значень і межі, за якими стратегія деградує.
Переоптимізація стратегії стає регламентною процедурою: конфігурації та метрики наборів зберігаються, запуск повторюється за розкладом, а фахівець налаштовує критерії відбору замість ручного підбору.
Що змінюється після автоматичного підбору параметрів
Ручний перебір параметрів упирається в людину: один цикл підбору розтягується на дні, а знайдений набір тримається на одному вдалому відрізку історії. Щойно ринок змінює режим, стратегія йде в просідання — це і є ціна перенавчання, а не помилка в коді.
Автоматичний підбір параметрів переводить це в вимірюваний цикл. Генетичний алгоритм веде популяцію наборів, оцінює кожен на кількох незалежних вікнах історії та штрафує ті, чий результат тримається лише на одному вікні.
Швидкість підбору зростає з доби до десятків хвилин на тому ж контурі — гіпотези перевіряються десятками за день, а не однією за тиждень.
Ключова метрика тут — не пікова дохідність, а стійкість параметрів: частка наборів, що зберігають поведінку на позавибірковому відрізку.
Ми відбираємо «плато» — широкі області, де сусідні значення дають близький результат, — замість одинокого піку, який розсипається від найменшого зсуву.
Багатокритеріальний відбір тримає дохідність, просідання й стабільність одночасно: практично це реалізує NSGA-II, перевірений підхід, а не саморобна евристика.
Ефект оптимізації стратегії видно в цифрах: частка стійких наборів зростає з третини до двох третин, розкид результату між сусідніми прогонами звужується, а клас відмов «стратегія розвалилася після зміни режиму» зникає зі статистики.
Параметри перестають бути одноразовою знахідкою й стають відтворюваним результатом — той самий цикл дає зіставний набір.
Способи пошуку оптимуму: порівняння підходів
Розмірність простору параметрів задає метод пошуку.
Для стратегії з трьома-чотирма входами та вузькими діапазонами достатньо повного перебору, але щойно додаються пороги входу, інтервали утримання позиції та рівні ризику, число комбінацій зростає добутком варіантів за кожною віссю.
Один прогін на історичних даних займає секунди — перебір тисяч комбінацій перетворюється на години обчислень, а частка перевірених точок залишається мізерною.
| Метод | Коли підходить | Обмеження |
|---|---|---|
| Перебір за сіткою | 2-3 параметри, дискретні значення, потрібна повна карта чутливості | Число прогонів зростає як добуток кроків; на шести й більше осях бюджет обчислень вичерпується раніше, ніж сітка |
| Випадковий пошук | Багато параметрів, частина неперервні, число прогонів обмежене | Немає гарантії покриття областей; результат не відтворюється від запуску до запуску |
| Баєсівська оптимізація | Дорога оцінка одного прогону, до десяти параметрів | Погано масштабується на десятки вимірів і розривні цільові функції |
| Еволюційний пошук | Десятки параметрів, розриви й плато в цільовій функції, потрібно кілька рішень | Потребує налаштування відбору, мутації та розміру популяції; без контролю збіжності вироджується у випадковий пошук |
На практиці методи комбінують: перебір за сіткою звужує область, еволюційний пошук уточнює її всередині.
У функцію пристосованості додаємо штраф за просідання та малу кількість угод, а підсумок перевіряємо на кількох періодах історії — інакше знайдений оптимум виявиться підігнаним під один відрізок.
Впровадження: від постановки задачі до налаштування генетичного алгоритму
Оптимізація параметрів стратегії — це не «прогін по історії та вибір найкращого рядка», а інженерний процес із зафіксованими критеріями приймання.
Порядок етапів однаковий для торгових і для балансувальних задач: змінюється лише набір оптимізованих параметрів і вид цільової функції.
- Розбір стратегії. Фіксуємо, що взагалі підлягає пошуку (періоди індикаторів, пороги входу й виходу, розмір позиції), а що залишається жорстким обмеженням — правила управління ризиком не оптимізуються ніколи.
- Цільова функція стратегії. Беремо метрику, стійку до просідань, а не максимальну дохідність: наприклад, відношення дохідності до максимального просідання за обмеження на мінімальну кількість угод у вибірці.
- Підготовка даних. Історія ділиться на навчальний, валідаційний і контрольний відрізки; контрольний ізолюється від пошуку й відкривається рівно один раз — перед передаванням.
- Налаштування генетичного алгоритму. Задаємо розмір популяції, частки мутації та схрещування, число поколінь, елітизм, штрафи за переускладнення та за вихід параметрів за допустимі межі.
- Перевірка поза вибіркою. Найкращі рішення проганяються на контрольному відрізку та на зсунутих вікнах, плюс перевірка на чутливість: невелика зміна параметра не повинна ламати результат.
- Передавання. Фіксуємо дві-три конфігурації з близькими показниками, описуємо межі стійкості та оформлюємо звіт із відтворюваними запусками — ті самі вхідні дані дають той самий результат.
На виході замовник отримує не одне «ідеальне» налаштування, а набір стійких конфігурацій і розуміння, де починається деградація.
Що замовник отримує на руки після впровадження
Після виведення контуру в роботу ви отримуєте не набір скриптів, а комплект, за яким підбір параметрів відтворюється без авторів: від меж простору пошуку до правил, коли перенавчання запускається, а коли стратегію час зупиняти.
- Конфігурація системи підбору — файли запусків із простором пошуку: межі та крок за кожним параметром, розмір популяції, число поколінь, оператори мутації й відбору, фіксований seed для відтворюваності.
- Схема контуру розрахунків — звідки беруться історичні дані, де рахується пристосованість рішень, як результати складаються у сховище й що відбувається при падінні обчислювача в середині покоління.
- Набір метрик відбору — цільові функції та штрафи: дохідність, просідання, оборот, стійкість на відкладеному вікні. Зазначено, яка метрика провідна й які пороги відсікають вочевидь крихкі рішення.
- Правила доступу — ролі на запуск, правку конфігурації та перегляд результатів: що доступно аналітику, що лише власнику контуру, як логується зміна кожного параметра.
- Документація з оптимізації — опис логіки генетичного алгоритму, словник параметрів, розбір типових збоїв підбору та інструкція з додавання нових полів у простір пошуку.
- Регламент запусків — періодичність повторного підбору, вікно даних, умови зупинки та порядок порівняння нової конфігурації з тією, що вже працює.
- Передавання системи — навчання вашої команди на вашій інфраструктурі, чек-лист приймання й період супроводу після вводу.
Кейс: підбір параметрів стратегії до та після автоматизації
Параметри стратегії замовник підбирав вручну: аналітик правив значення, запускав прогін на історичних даних, порівнював криві й повторював цикл. Один захід займав два-три тижні, за цей час встигало пройти близько двохсот наборів — вузька смуга навколо стартової здогадки.
Відбирався набір із найкращою дохідністю на історії, і на нових даних він найчастіше розвалювався: ринок переходив в інший режим, а параметри залишалися підігнаними під минуле. Такий клас відмов надійніше закривати правилом відбору, ніж розбирати наслідки в бою.
Підбір перенесли в оптимізатор на генетичному алгоритмі: набір параметрів — хромосома, прогін на даних — оцінка пристосованості, далі схрещування й мутація найкращих особин.
Перебір побудували на зрілій бібліотеці еволюційної оптимізації DEAP — запуск не потребував написання движка з нуля.
Головна зміна в критерії відбору: пристосованість рахувалася не за одним прогоном, а за кількома послідовними відрізками історії, і рішення, що втрачає стійкість хоча б на одному, відсіювалося.
Цикл підбору скоротився з тижнів до однієї ночі, число перевірюваних наборів зросло з двохсот до десятків тисяч за запуск, а частка конфігурацій, що зберігають робочі метрики на нових даних, піднялася приблизно з чверті до двох третин.
Правила відбору, діапазони параметрів і журнали прогонів зберігаються, тому будь-який результат відтворюється й перераховується при наступному запуску.
Що робити, якщо підбір параметрів уже ведеться своїми силами?
Працюючий самописний підбір — це актив, а не борг: у ньому зашита логіка стратегії та особливості виконання. Ми не пропонуємо переписувати все — спочатку аудит: як формується функція пристосованості, як влаштовані відбір, схрещування й мутація та де контур втрачає стійкість.
Ключова точка аудиту — розділення даних: якщо параметри підбираються й оцінюються на одній історії, найкращий результат майже завжди виявляється підгонкою під шум.
Перевіряємо детермінізм прогону, наявність перевірочного періоду та те, чи враховує критерій відбору просідання, комісії й прослизання, а не лише дохідність.
Перенесення розрахунків виправдане не завжди: коли контур не масштабується за числом прогонів, рахує години там, де потрібні хвилини, або не вміє розпаралелити незалежні вікна.
В інших випадках простіше доопрацювати наявний підбір — додати перевірочний період, стійкість параметрів між вікнами та протоколювання прогонів.
Порівнюємо обидва контури на одному наборі даних, з однаковими комісіями, затримками виконання та одним критерієм якості. Дивимося не найкращий прогін, а розподіл за вікнами: розкид прибутку, максимальне просідання, частку вікон у плюсі, час розрахунку.
За будь-якого доопрацювання зберігаємо вашу функцію пристосованості, набір параметрів і правила виконання — це і є предметна цінність системи. Перебудовуємо інфраструктуру підбору: схему валідації, відбір, журналювання та відтворюваність прогонів.
Технічні сумніви та питання стійкості результату
Будь-яка оптимізація параметрів ризикує підгонкою під історичні дані: алгоритм чесно знаходить комбінацію, ідеальну на минулому відрізку, і вона розвалюється на нових даних.
Нижче — заперечення, які найчастіше виникають в інженерів, і те, як ми знімаємо їх процедурою, а не обіцянками.
Як відрізнити робочу стратегію від перенавченої?
Відбір ведемо на одному інтервалі, а перевірку — на контрольному відрізку, який не брав участі в пошуку. Додатково дивимося стійкість параметрів: якщо близькі комбінації дають різний результат, оптимум випадковий, і в роботу таке налаштування не йде.
Що робити зі зростанням числа параметрів?
Кожен новий параметр розширює простір пошуку та підвищує шанс підгонки. Обмежуємо розмірність, групуємо пов’язані параметри, частину фіксуємо за логікою стратегії та вводимо штраф за складність рішення. Параметри, що не впливають на результат, прибираємо — це обмеження методу, а не недоналаштування.
Як це вбудовується в поточний контур розрахунків?
Модуль оптимізації читає ті самі дані та віддає набір параметрів із метриками якості, логіку виконання ми не чіпаємо. Запуск за розкладом або вручну, результат версіонується, тому його завжди можна порівняти з поточними налаштуваннями й відкотитися до них.
Обговоримо задачу підбору параметрів вашої стратегії
Щоб оцінка та план робіт спиралися на ваші дані, а не на загальні припущення, достатньо кількох ввідних. Нижче — що надіслати для розбору; решту уточнимо в листуванні.
- Опис стратегії: логіка входу й виходу, які параметри підбираються, а які жорстко зафіксовані.
- Історія угод або котирувань у вихідному вигляді — таблиця, вивантаження з термінала, файл із бази.
- Межі допустимих значень за кожним параметром і крок, з яким їх можна змінювати.
- Метрика, яку вважаєте цільовою: дохідність з урахуванням ризику, просідання, частка прибуткових угод, стійкість за періодами.
- Вимоги до перевірки: як ділити дані на навчальне й контрольне вікна, скільки часу допустимо на один прогін підбору.
- Обмеження щодо розрахунку: де запускати пошук, чи потрібен паралельний перерахунок на кількох машинах.
У відповідь повернемо оцінку та план робіт, розбитий за етапами: підготовка даних, налаштування генетичного пошуку, перевірка результату поза навчальним вікном, розбір звіту, передавання.
Окремо назвемо параметри, чутливі до перенавчання, і покажемо, як їх зафіксуємо перед запуском підбору параметрів. Опишіть задачу оптимізації своїми словами — цього вистачить, щоб обговорити задачу оптимізації предметно й назвати терміни за кожним етапом.
