Оптимизация гиперпараметров Optuna и Ray Tune — опыт HPO

Оптимизация гиперпараметров: где именно теряется качество модели

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

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

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

Третье — ручные итерации. Каждый цикл «поменяли параметр, перезапустили обучение» не оставляет истории: непонятно, какая конфигурация дала какой результат и на каком разбиении. Воспроизводимость обучения ломается, и повторить удачный запуск через месяц уже не получается.

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

Что даёт системная оптимизация гиперпараметров при обучении

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

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

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

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

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

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

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

Как выбирать режим под задачу

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

Этапы внедрения цикла подбора параметров модели

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

1. Аудит контура обучения. Разбираем подготовку данных, фиксацию разбиений на выборки, расчёт целевой метрики и длительность одного прогона. На выходе — карта узких мест и оценка, сколько испытаний реально проходит параллельно.

2. План экспериментов. Согласуем базовую линию, диапазоны и шаг по каждому параметру, бюджет прогонов и правило остановки. Отдельно отмечаем побочные метрики, чтобы модель не выбиралась по одному числу.

3. Настройка поиска. Поднимаем планировщик (например, Optuna), включаем раннюю остановку заведомо слабых прогонов и журнал испытаний. Каждый прогон сохраняет конфигурацию, разбиение и артефакт модели — результат воспроизводится одним запуском.

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

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

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

Артефакты на выходе: конфигурации, отчёты, регламенты

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

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

Каждый пункт проверяем вместе с вашей командой: запускаем поиск на вашей стороне, сверяем журнал и метрики. Если что-то не воспроизводится — это наша зона ответственности, а не «вопрос к среде».

Кейс: как сократили перебор конфигураций в разы

В одном из проектов по распознаванию документов подбор конфигурации модели держался на ручном переборе: инженер задавал значения, запускал обучение и по журналу решал, куда двигаться дальше. На одну задачу уходило 40–60 запусков, подбор растягивался на неделю, а разброс итогового качества между запусками на одних и тех же данных доходил до восьми процентов — результат зависел от того, кто и в каком порядке перебирал параметры.

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

После внедрения на подбор уходит 12–18 запусков вместо 40–60: цикл сам отсекает слабые ветки и не тратит на них обучение. Разброс качества между запусками сократился с восьми до двух процентов, время подбора — с недели до одного дня, а откат к предыдущей конфигурации занимает минуты, потому что рядом лежат её параметры, метрики и версия данных, на которой они получены.

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

Чем байесовский подбор отличается от случайного перебора

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

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

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

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

Ограничения метода: шумные метрики, дорогие запуски, переобучение

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

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

Как понять, что отбор подстроился под валидацию?

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

Обсудим задачу: подберём режим поиска под вашу модель

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

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

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