Разработка системы оптимизации гиперпараметров торговой AI-модели

Почему оптимизация гиперпараметров ломает торговую модель

Ручной перебор настроек выглядит безобидно: аналитик меняет число входов в позицию, горизонт удержания, порог срабатывания сигнала и лимит риска на сделку, прогоняет модель по одному и тому же историческому отрезку и оставляет комбинацию, где кривая доходности ровнее всего. За десятки прогонов находится набор, на котором просадка минимальна, а доля прибыльных сделок максимальна. Решение при этом принимается по прошлому, а не по тому, как параметры поведут себя на незнакомых данных.

Так подбор параметров превращается в переобучение торговой модели: она запоминает шум конкретного периода вместо закономерности. На новых данных метрики становятся нестабильными — число сделок падает, просадка выходит за границы, которые считались рабочими, сигналы срабатывают с задержкой, когда режим рынка уже сменился. Опаснее всего то, что поломка не видна сразу: первые недели модель торгует правдоподобно, и только накопленная статистика показывает, что настройки подогнаны под исчезнувший рынок.

Цена такой ошибки — не отдельная убыточная сделка, а доверие к модели и недели работы команды. Поэтому оптимизацию гиперпараметров мы разбираем как управляемую процедуру: с честным разделением данных, проверкой на скользящем окне и регламентом, по которому настройки пересматриваются. Как это закрывается — ниже.

Что даёт управляемый подбор параметров модели

Управляемый подбор параметров начинается с того, что перебор перестаёт быть ручным. Мы задаём пространство поиска, метрику отбора и бюджет прогонов, дальше поиск ведёт себя сам: бесперспективные комбинации отсекаются досрочно, ресурсы уходят в перспективные области. Время эксперимента сокращается с недель до часов, а ускорение подбора параметров достигается не урезанием поиска, а его структурой.

Ключевой эффект — качество прогноза вне обучающей выборки. Отбор идёт по отложенному периоду и схеме скользящего окна, а не по максимуму на истории, поэтому модель не подстраивается под шум отдельного отрезка. Расхождение метрики между обучением и проверочным периодом сжимается с двузначных процентов до единиц — это и есть устойчивость модели, которую видно на новых данных.

Повторяемость результата держится на протоколе: рядом с моделью сохраняются пространство поиска, зерно генератора, срез данных и лучшая конфигурация. Поиск ведём на Optuna с журналом испытаний — прогон воспроизводится по записи, а не по памяти инженера, и результат перестаёт зависеть от того, кто запускал эксперимент.

Подбор параметров становится инженерной процедурой с предсказуемым временем и проверяемым качеством, а не серией удачных запусков.

Режимы поиска параметров: сеточный, случайный, байесовский

Пространство параметров торговой модели почти никогда не бывает однородным: две-три оси задают результат, остальные лишь слегка его смещают. Поэтому режим перебора выбирают не по «мощности» метода, а по размерности пространства и стоимости одного обучения.

Вычислительные затраты растут как произведение числа значений по каждой оси, поэтому полный перебор оправдан только там, где осей мало и они разнонаправленно влияют на метрику.

На практике порядок такой: разведку делаем случайным поиском, уточнение — байесовским, а сеточный оставляем для финальной проверки узкой окрестности лучшей точки. Такой порядок сокращает число обучений в разы, а воспроизводимость обеспечивается фиксацией зерна генератора и версии набора данных.

Этапы построения контура оптимизации

Перебор гиперпараметров даёт разный результат на одних и тех же данных, если менять порядок подготовки признаков, схему разбиения и способ отбора конфигураций. Поэтому этапы оптимизации выстроены жёстко — от фиксации данных до регламента, по которому контур перезапускается без нашего участия.

1. Данные и границы применимости. Определяем, на каком периоде и в каком режиме рынка модель работает, где заканчивается пригодная для обучения история.
2. Метрика качества. Договариваемся, что считаем улучшением: доходность с поправкой на риск, просадка, доля прибыльных периодов. Одна метрика — цель, остальные — ограничения.
3. Валидация модели. Разбиение по времени: обучение на прошлом, проверка на следующем отрезке с зазором — иначе будущие данные затекают в обучение и метрика завышается.
4. Пространство поиска. Задаём, какие параметры и в каких границах двигаем, какие фиксируем; слишком широкий диапазон даёт случайные выбросы вместо устойчивого улучшения.
5. Журнал экспериментов. Каждый запуск фиксируется: параметры, версия данных и кода, метрики. Без журнала результат не повторить и не объяснить.
6. Отбор конфигурации. Берём не лучшую точку на одном отрезке, а устойчивую: держит метрику на нескольких разбиениях и не разваливается при небольшом сдвиге параметров.

Завершаем регламентом: периодичность переобучения, критерии остановки, правила отката на предыдущую конфигурацию. На выходе — не одна подобранная конфигурация, а процедура, по которой видно деградацию метрики и понятно, что с ней делать.

Конфигурации, схемы и регламенты на выходе

Смысл раздела — заказчик остаётся не с одним удачным набором настроек, а с полным набором материалов, по которым результат воспроизводится своими силами. Все артефакты складываются в один каталог эксперимента: конфигурация привязана к конкретному запуску, а регламенты описывают, что делать при следующем обновлении данных.

• Конфигурация модели — итоговый файл со значениями гиперпараметров, зафиксированный по конкретному запуску, а не «последняя удачная версия» на чьём-то ноутбуке.
• Карта параметров: какие настройки искали, какие зафиксировали заранее, каким шагом шли по каждой оси.
• Границы параметров — рабочие диапазоны и условия, при которых диапазон расширяется: смена горизонта данных, рост волатильности, смена режима рынка.
• Журнал эксперимента: последовательность запусков, отсеянные комбинации и причина отсева, чтобы повторный поиск не шёл по уже пройденному.
• Схема валидации — как отделяются настройки, подобранные на истории, от тех, что проверены на отложенном периоде.
• Регламент запуска: пошаговая инструкция воспроизведения поиска с нуля — какие данные, какие версии конфигураций, в каком порядке.
• Правила перезапуска после обновления данных: что пересчитывается автоматически, что требует ручного подтверждения, где точка отката к предыдущей конфигурации.

Без этих документов оптимизация гиперпараметров остаётся разовым результатом, который невозможно ни защитить, ни повторить. Передача сопровождается разбором с вашими инженерами: показываем, как менять границы параметров и не сломать воспроизводимость.

Кейс: подбор параметров торговой модели до и после

Модель работала на внутридневных данных, а её параметры — горизонт прогноза, глубина истории, порог входа, шаг отсечения позиции — задавались вручную. Каждую правку проверяли на одном историческом отрезке: если кривая росла, конфигурацию оставляли. Так накопилось около сорока наборов без внятного критерия выбора, и на новых данных результаты расходились в разы.

Мы заменили ручной перебор управляемым. Пространство поиска описали формально, с границами и шагом по каждому параметру, а историю разбили на последовательные отрезки — проверка всегда шла на следующем по времени окне, без заглядывания вперёд. Перебор вёл байесовский алгоритм Optuna: он не сканирует сетку целиком, а сужает область вокруг тех конфигураций, которые держат метрику вне выборки, а не только на обучающем отрезке.

Что показали замеры

• число проверенных конфигураций: около 40 вручную — свыше 600 за один прогон;
• коэффициент Шарпа вне выборки: 0,55 → 1,3;
• максимальная просадка: 26% → 12%;
• доля конфигураций, устойчивых на всех отрезках: 9% → 62%;
• разброс результата между окнами: сократился втрое.

Ключевым оказался не рост метрики, а устойчивость вне выборки. Раньше лучшая конфигурация на обучающем отрезке почти всегда рассыпалась на следующем — теперь отбор идёт по поведению на нескольких окнах, и в работу попадают параметры без резких провалов. Прогон воспроизводится одной командой, журнал испытаний сохраняется, поэтому любую версию модели можно сравнить с предыдущей и вернуться к ней без повторной ручной настройки.

Как оптимизация гиперпараметров влияет на переобучение?

Переобучение — расхождение между качеством на истории и на данных, которых модель не видела. Оптимизация гиперпараметров его не лечит: она сдвигает точку, где модель начинает запоминать шум вместо закономерности. Граница проходит по устойчивости качества вне обучающего окна, а не по числу перебранных комбинаций.

Отделяет настройку от подгонки схема проверки. Для временных рядов кросс-валидация строится по хронологии: обучение на прошлом, проверка на следующем отрезке, затем окно сдвигается вперёд. Случайное перемешивание подмешивает в обучение будущее и даёт завышенную оценку, которая рассыпается на реальных данных.

Второй барьер — отложенная выборка. Последний по времени отрезок изолируется заранее и не участвует ни в переборе, ни в отборе признаков. Если заглядывать в него после каждой итерации, он становится частью обучающего набора, и оценка начинает отражать память о конкретных эпизодах рынка, а не обобщение.

Третий — регуляризация. Штраф за большие веса, ранняя остановка, сокращение глубины и сужение набора признаков работают в паре с перебором: чем жёстче ограничение, тем шире диапазон гиперпараметров, безопасный для качества. У торговой модели отдельно штрафуются частота сделок и чувствительность к издержкам.

Критерий на практике — не пик качества одной конфигурации, а разброс между периодами проверки и просадка относительно отложенной выборки. Если лучший набор обгоняет соседние значения, но на новом отрезке теряет больше всех, это подгонка под историю, а не настройка модели.

Технические сомнения перед стартом проекта

Перед стартом почти всегда звучат одни и те же инженерные вопросы: хватит ли данных, сколько будет идти обучение, что делать с моделью после вывода в эксплуатацию и как доказать, что улучшение не случайно. Ниже — прямые ответы, без обещаний «всё будет быстро».

Сколько ждать обучения и можно ли ускорить?

Поиск раскладывается в очередь задач на нескольких узлах, а слабые конфигурации снимаются досрочно, до полного прогона. Первый рабочий набор параметров видно уже после короткой серии запусков, дальше идёт уточнение вокруг лучшей области. Прогресс доступен по ходу поиска, а не только в конце.

Как понять, что улучшение метрики не случайно?

Запуск воспроизводим: фиксируются зерно генератора, версия данных и полная конфигурация, всё пишется в журнал экспериментов. Итоговая метрика считается на нескольких разбиениях, а разброс оценивается отдельно от среднего — конфигурации сравниваем по устойчивости, а не по одному удачному прогону.

Что с настройками, когда модель уже работает?

Конфигурация версионируется вместе с моделью, поэтому откат к предыдущему набору параметров занимает минуты. При сдвиге данных поиск перезапускается на свежем окне автоматически, а не правится вручную по интуиции. Мониторинг сравнивает фактическое поведение модели с ожидаемым и подаёт сигнал раньше, чем расхождение станет заметно по результату.

Обсудим задачу и вернёмся с планом работ

Чтобы вернуться с оценкой и планом, а не с общими словами, нам нужен минимум вводных: где живёт модель, на каких данных обучается и что считается успехом. Заявка в свободной форме — этого достаточно, уточняющие вопросы зададим сами.

Что полезно описать сразу:

• Задача и метрика: какую величину оптимизируем (доходность, риск, точность сигнала) и на каком горизонте она измеряется.
• Модель и окружение: класс модели, библиотека обучения, где запускается расчёт, нужен ли распределённый режим.
• Данные: источник котировок и признаков, глубина истории, доля пропусков, доступ выгрузками или через программный интерфейс.
• Пространство поиска: какие параметры уже подбираете вручную, их диапазоны и текущие значения.
• Ограничения: время на одну серию запусков, требования к воспроизводимости, защита от переобучения на исторических данных.
• Инфраструктура: свои вычислительные ресурсы или арендованные, есть ли учёт версий экспериментов и сохранение артефактов.
• Критерий приёмки: по какому сравнению на отложенном периоде поймём, что стало лучше.

По этому описанию мы возвращаемся с планом: как организуем поиск, как разделим выборку, как зафиксируем воспроизводимость и сколько итераций понадобится до старта работ.