Какие альтернативы grid search для подбора гиперпараметров существуют

Что проверяют

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

Как отвечать

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

• random search: RandomizedSearchCV в sklearn, вместо списков задаются распределения, например scipy.stats.loguniform для learning rate и регуляризации. При том же числе запусков пробует больше разных значений каждого важного параметра, это показали Bergstra и Bengio в 2012 году;
• байесовская оптимизация: суррогатная модель предсказывает качество по параметрам, а следующую точку выбирает функция приобретения вроде expected improvement. Ходовая реализация: TPE в Optuna и Hyperopt. Выигрывает, когда одно обучение стоит дорого;
• successive halving и Hyperband: много конфигураций запускаются на малом бюджете (эпохи, доля данных, число деревьев), дальше продлеваются только лучшие. В sklearn это HalvingRandomSearchCV, он пока экспериментальный и требует импорта enable_halving_search_cv, в Optuna HyperbandPruner;
• ASHA и BOHB: асинхронная версия отсева для кластера и сочетание байесовского подхода с Hyperband, обе есть в Ray Tune;
• эволюционные методы: например CMA-ES для непрерывных пространств, в Optuna это CmaEsSampler.

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

Где спотыкаются

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

Задают learning rate или C равномерной сеткой вроде 0.1, 0.2, 0.3. Такие параметры живут на логарифмической шкале, и равномерная сетка тратит почти все точки на один порядок.

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