Чому оптимізація гіперпараметрів ламає торгову модель
Ручний перебір налаштувань виглядає безневинно: аналітик змінює кількість входів у позицію, горизонт утримання, поріг спрацювання сигналу та ліміт ризику на угоду, проганяє модель по одному й тому самому історичному відрізку й залишає комбінацію, де крива дохідності найрівніша.
За десятки прогонів знаходиться набір, на якому просадка мінімальна, а частка прибуткових угод максимальна. Рішення при цьому ухвалюється за минулим, а не за тим, як параметри поводитимуться на незнайомих даних.
Так підбір параметрів перетворюється на перенавчання торгової моделі: вона запам'ятовує шум конкретного періоду замість закономірності.
На нових даних метрики стають нестабільними — кількість угод падає, просадка виходить за межі, які вважалися робочими, сигнали спрацьовують із затримкою, коли режим ринку вже змінився.
Найнебезпечніше те, що поломка не видна одразу: перші тижні модель торгує правдоподібно, і лише накопичена статистика показує, що налаштування підігнані під зниклий ринок.
Ціна такої помилки — не окрема збиткова угода, а довіра до моделі та тижні роботи команди. Тому оптимізацію гіперпараметрів ми розбираємо як керовану процедуру: з чесним розділенням даних, перевіркою на ковзному вікні та регламентом, за яким налаштування переглядаються. Як це закривається — нижче.
Що дає керований підбір параметрів моделі
Керований підбір параметрів починається з того, що перебір перестає бути ручним. Ми задаємо простір пошуку, метрику відбору та бюджет прогонів, далі пошук поводиться сам: безперспективні комбінації відсікаються достроково, ресурси йдуть у перспективні області.
Час експерименту скорочується з тижнів до годин, а прискорення підбору параметрів досягається не урізанням пошуку, а його структурою.
Ключовий ефект — якість прогнозу поза навчальною вибіркою. Відбір іде за відкладеним періодом і схемою ковзного вікна, а не за максимумом на історії, тому модель не підлаштовується під шум окремого відрізка.
Розходження метрики між навчанням і перевірочним періодом стискається з двозначних відсотків до одиниць — це і є стійкість моделі, яку видно на нових даних.
Повторюваність результату тримається на протоколі: поруч із моделлю зберігаються простір пошуку, зерно генератора, зріз даних і найкраща конфігурація.
Пошук ведемо на Optuna з журналом випробувань — прогін відтворюється за записом, а не за пам'яттю інженера, і результат перестає залежати від того, хто запускав експеримент.
Підбір параметрів стає інженерною процедурою з передбачуваним часом і перевірюваною якістю, а не серією вдалих запусків.
Режими пошуку параметрів: сітковий, випадковий, байєсівський
Простір параметрів торгової моделі майже ніколи не буває однорідним: дві-три осі задають результат, решта лише злегка його зміщують. Тому режим перебору обирають не за «потужністю» методу, а за розмірністю простору та вартістю одного навчання.
Обчислювальні витрати зростають як добуток кількості значень за кожною віссю, тому повний перебір виправданий лише там, де осей мало і вони різноспрямовано впливають на метрику.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Сітковий пошук | 2–3 параметри з малою кількістю значень, потрібна наочна карта відгуку моделі | Кількість запусків зростає добутком осей; на шести й більше осях основна частина навчань іде на заздалегідь слабкі комбінації |
| Випадковий пошук | Простір високої розмірності, частина осей майже не впливає на результат | Немає гарантії покриття областей; без фіксації зерна генератора результат не відтворюється |
| Байєсівський пошук параметрів | Навчання дороге, а кількість запусків обмежена | Потребує зіставної оцінки якості; на шумних або зміщених оцінках сходиться в локальний оптимум |
На практиці порядок такий: розвідку робимо випадковим пошуком, уточнення — байєсівським, а сітковий залишаємо для фінальної перевірки вузької околиці найкращої точки.
Такий порядок скорочує кількість навчань у рази, а відтворюваність забезпечується фіксацією зерна генератора та версії набору даних.
Етапи побудови контуру оптимізації
Перебір гіперпараметрів дає різний результат на одних і тих самих даних, якщо змінювати порядок підготовки ознак, схему розбиття та спосіб відбору конфігурацій.
Тому етапи оптимізації вибудовані жорстко — від фіксації даних до регламенту, за яким контур перезапускається без нашої участі.
- Дані та межі застосовності. Визначаємо, на якому періоді й у якому режимі ринку модель працює, де закінчується придатна для навчання історія.
- Метрика якості. Домовляємося, що вважаємо покращенням: дохідність із поправкою на ризик, просадка, частка прибуткових періодів. Одна метрика — ціль, решта — обмеження.
- Валідація моделі. Розбиття за часом: навчання на минулому, перевірка на наступному відрізку із зазором — інакше майбутні дані затікають у навчання й метрика завищується.
- Простір пошуку. Задаємо, які параметри й у яких межах рухаємо, які фіксуємо; занадто широкий діапазон дає випадкові викиди замість стійкого покращення.
- Журнал експериментів. Кожен запуск фіксується: параметри, версія даних і коду, метрики. Без журналу результат не повторити й не пояснити.
- Відбір конфігурації. Беремо не найкращу точку на одному відрізку, а стійку: тримає метрику на кількох розбиттях і не розвалюється за невеликого зсуву параметрів.
Завершуємо регламентом: періодичність перенавчання, критерії зупинки, правила відкату на попередню конфігурацію. На виході — не одна підібрана конфігурація, а процедура, за якою видно деградацію метрики й зрозуміло, що з нею робити.
Конфігурації, схеми та регламенти на виході
Сенс розділу — замовник залишається не з одним вдалим набором налаштувань, а з повним набором матеріалів, за якими результат відтворюється власними силами.
Усі артефакти складаються в один каталог експерименту: конфігурація прив'язана до конкретного запуску, а регламенти описують, що робити за наступного оновлення даних.
- Конфігурація моделі — підсумковий файл зі значеннями гіперпараметрів, зафіксований за конкретним запуском, а не «остання вдала версія» на чиємусь ноутбуці.
- Карта параметрів: які налаштування шукали, які фіксували заздалегідь, яким кроком ішли за кожною віссю.
- Межі параметрів — робочі діапазони та умови, за яких діапазон розширюється: зміна горизонту даних, зростання волатильності, зміна режиму ринку.
- Журнал експерименту: послідовність запусків, відсіяні комбінації та причина відсіювання, щоб повторний пошук не йшов уже пройденим.
- Схема валідації — як відокремлюються налаштування, підібрані на історії, від тих, що перевірені на відкладеному періоді.
- Регламент запуску: покрокова інструкція відтворення пошуку з нуля — які дані, які версії конфігурацій, у якому порядку.
- Правила перезапуску після оновлення даних: що перераховується автоматично, що потребує ручного підтвердження, де точка відкату до попередньої конфігурації.
Без цих документів оптимізація гіперпараметрів залишається разовим результатом, який неможливо ні захистити, ні повторити. Передача супроводжується розбором із вашими інженерами: показуємо, як змінювати межі параметрів і не зламати відтворюваність.
Кейс: підбір параметрів торгової моделі до та після
Модель працювала на внутрішньоденних даних, а її параметри — горизонт прогнозу, глибина історії, поріг входу, крок відсікання позиції — задавалися вручну. Кожну правку перевіряли на одному історичному відрізку: якщо крива зростала, конфігурацію залишали.
Так накопичилося близько сорока наборів без виразного критерію вибору, і на нових даних результати розходилися в рази.
Ми замінили ручний перебір керованим. Простір пошуку описали формально, з межами та кроком за кожним параметром, а історію розбили на послідовні відрізки — перевірка завжди йшла на наступному за часом вікні, без заглядання вперед.
Перебір вів байєсівський алгоритм Optuna: він не сканує сітку цілком, а звужує область навколо тих конфігурацій, які тримають метрику поза вибіркою, а не лише на навчальному відрізку.
Що показали заміри
- кількість перевірених конфігурацій: близько 40 вручну — понад 600 за один прогін;
- коефіцієнт Шарпа поза вибіркою: 0,55 → 1,3;
- максимальна просадка: 26% → 12%;
- частка конфігурацій, стійких на всіх відрізках: 9% → 62%;
- розкид результату між вікнами: скоротився втричі.
Ключовим виявилося не зростання метрики, а стійкість поза вибіркою. Раніше найкраща конфігурація на навчальному відрізку майже завжди розсипалася на наступному — тепер відбір іде за поведінкою на кількох вікнах, і в роботу потрапляють параметри без різких провалів.
Прогін відтворюється однією командою, журнал випробувань зберігається, тому будь-яку версію моделі можна порівняти з попередньою й повернутися до неї без повторного ручного налаштування.
Як оптимізація гіперпараметрів впливає на перенавчання?
Перенавчання — розходження між якістю на історії та на даних, яких модель не бачила. Оптимізація гіперпараметрів його не лікує: вона зсуває точку, де модель починає запам'ятовувати шум замість закономірності. Межа проходить за стійкістю якості поза навчальним вікном, а не за кількістю перебраних комбінацій.
Відокремлює налаштування від підгонки схема перевірки. Для часових рядів крос-валідація будується за хронологією: навчання на минулому, перевірка на наступному відрізку, потім вікно зсувається вперед.
Випадкове перемішування підмішує в навчання майбутнє й дає завищену оцінку, яка розсипається на реальних даних.
Другий бар'єр — відкладена вибірка. Останній за часом відрізок ізолюється заздалегідь і не бере участі ні в переборі, ні у відборі ознак.
Якщо заглядати в нього після кожної ітерації, він стає частиною навчального набору, і оцінка починає відображати пам'ять про конкретні епізоди ринку, а не узагальнення.
Третій — регуляризація. Штраф за великі ваги, рання зупинка, скорочення глибини та звуження набору ознак працюють у парі з перебором: що жорсткіше обмеження, то ширший діапазон гіперпараметрів, безпечний для якості. У торгової моделі окремо штрафуються частота угод і чутливість до витрат.
Критерій на практиці — не пік якості однієї конфігурації, а розкид між періодами перевірки та просадка щодо відкладеної вибірки. Якщо найкращий набір обганяє сусідні значення, але на новому відрізку втрачає найбільше, це підгонка під історію, а не налаштування моделі.
Технічні сумніви перед стартом проєкту
Перед стартом майже завжди лунають ті самі інженерні запитання: чи вистачить даних, скільки триватиме навчання, що робити з моделлю після введення в експлуатацію і як довести, що покращення не випадкове. Нижче — прямі відповіді, без обіцянок «усе буде швидко».
Даних менше, ніж хотілося б, — оптимізація гіперпараметрів взагалі має сенс?
Має, але змінюється стратегія пошуку. Розріджений байєсівський пошук витягує робочу конфігурацію з десятків запусків замість тисяч, а заздалегідь слабкі області відсікаються за проміжними метриками. Обов'язкова умова — відкладена вибірка, яку пошук не бачить до фінального заміру.
Скільки чекати навчання і чи можна прискорити?
Пошук розкладається в чергу завдань на кількох вузлах, а слабкі конфігурації знімаються достроково, до повного прогону. Перший робочий набір параметрів видно вже після короткої серії запусків, далі йде уточнення навколо найкращої області. Прогрес доступний у процесі пошуку, а не лише в кінці.
Як зрозуміти, що покращення метрики не випадкове?
Запуск відтворюваний: фіксуються зерно генератора, версія даних і повна конфігурація, усе пишеться в журнал експериментів.
Підсумкова метрика рахується на кількох розбиттях, а розкид оцінюється окремо від середнього — конфігурації порівнюємо за стійкістю, а не за одним вдалим прогоном.
Що з налаштуваннями, коли модель уже працює?
Конфігурація версіонується разом із моделлю, тому відкат до попереднього набору параметрів займає хвилини. За зсуву даних пошук перезапускається на свіжому вікні автоматично, а не правиться вручну за інтуїцією.
Моніторинг порівнює фактичну поведінку моделі з очікуваною й подає сигнал раніше, ніж розходження стане помітним за результатом.
Обговоримо задачу і повернемося з планом робіт
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібен мінімум ввідних: де живе модель, на яких даних навчається і що вважається успіхом. Заявка у вільній формі — цього достатньо, уточнювальні запитання поставимо самі.
Що корисно описати одразу:
- Задача й метрика: яку величину оптимізуємо (дохідність, ризик, точність сигналу) і на якому горизонті вона вимірюється.
- Модель і середовище: клас моделі, бібліотека навчання, де запускається розрахунок, чи потрібен розподілений режим.
- Дані: джерело котирувань і ознак, глибина історії, частка пропусків, доступ вивантаженнями або через програмний інтерфейс.
- Простір пошуку: які параметри вже підбираєте вручну, їхні діапазони та поточні значення.
- Обмеження: час на одну серію запусків, вимоги до відтворюваності, захист від перенавчання на історичних даних.
- Інфраструктура: власні обчислювальні ресурси чи орендовані, чи є облік версій експериментів і збереження артефактів.
- Критерій приймання: за яким порівнянням на відкладеному періоді зрозуміємо, що стало краще.
За цим описом ми повертаємося з планом: як організуємо пошук, як розділимо вибірку, як зафіксуємо відтворюваність і скільки ітерацій знадобиться до старту робіт.
