Выбор модели и подбор гиперпараметров

Один-единственный гиперпараметр - learning rate - может определить, сойдется ли модель за 10 минут или не сойдется никогда. Найти правильную комбинацию из миллионов возможных вариантов - это как искать иголку в стоге сена. Но есть умные способы это сделать.

• **Рекомендательные системы Netflix и Spotify** - подбор гиперпараметров ансамблей из десятков моделей определяет качество рекомендаций для миллионов пользователей, и разница в 0.1% метрики транслируется в миллионы долларов выручки
• **Autonomous driving (Waymo, Tesla)** - нейросети для распознавания объектов имеют сотни гиперпараметров, и Bayesian Optimization позволяет находить оптимальные конфигурации за дни вместо месяцев полного перебора
• **Kaggle-соревнования** - топ-решения почти всегда используют Optuna или подобные инструменты для подбора гиперпараметров, и разница между 1-м и 100-м местом часто определяется именно качеством тюнинга

Предварительные знания

• Feature Engineering

От перебора по сетке к обучению самого поиска

Десятилетиями grid search был способом подбора по умолчанию: задаёшь несколько значений для каждого параметра и перебираешь все комбинации. Просто и исчерпывающе, но масштабируется ужасно. В 2012 Джеймс Бергстра и Йошуа Бенжио опубликовали статью 'Random Search for Hyper-Parameter Optimization' и показали неочевидное: случайный поиск обычно обыгрывает перебор по сетке при одинаковом бюджете вычислений. Причина в том, что реально важны лишь один-два гиперпараметра, а случайная выборка проверяет гораздо больше различных значений именно этих важных параметров. В том же году Джаспер Снук, Юго Ларошель и Райан Адамс ввели байесовскую оптимизацию в широкий обиход работой 'Practical Bayesian Optimization of Machine Learning Algorithms', где гауссовский процесс моделирует целевую функцию и осознанно выбирает каждую следующую точку. К 2017 году Лиша Ли с коллегами предложили Hyperband, рассматривающий подбор как задачу распределения ресурсов: слабые конфигурации отсеиваются рано, чтобы бюджет тратился там, где это важно. Каждый шаг уводил область от слепого перебора к стратегиям поиска, которые учатся на собственных результатах.

Grid Search

Гиперпараметры - это настройки модели, которые задаются **до обучения** и не меняются в процессе. Например, learning rate в градиентном спуске, количество деревьев в Random Forest, C и gamma в SVM. В отличие от весов модели (которые оптимизируются автоматически), гиперпараметры нужно подбирать вручную или с помощью специальных методов. **Grid Search** - самый простой и прямолинейный подход: задаём набор возможных значений для каждого гиперпараметра и проверяем *все* комбинации.

Главное преимущество Grid Search - **гарантия**: он найдет лучшую комбинацию из всех заданных значений. Вы точно не пропустите оптимум *в пределах сетки*. Поэтому Grid Search остаётся стандартом для задач с 2-3 гиперпараметрами и небольшими сетками значений.

**Проблема размерности Grid Search:** Количество комбинаций растет **экспоненциально** с числом гиперпараметров: - 2 параметра по 5 значений = 25 комбинаций - 3 параметра по 5 значений = 125 комбинаций - 5 параметров по 5 значений = 3125 комбинаций - 10 параметров по 5 значений = 9 765 625 комбинаций С 5-fold cross-validation каждая комбинация - это 5 обучений. Для 10 параметров получаем ~50 миллионов обучений модели. Если одно обучение занимает 1 секунду, перебор займёт **полтора года**.

Grid Search хорошо работает для задач с **2-3 гиперпараметрами** и когда у вас есть представление об их диапазонах. Но для моделей с большим количеством параметров (градиентный бустинг - 5-8 параметров, нейросети - десятки) полный перебор становится непрактичным. Кроме того, Grid Search страдает от ещё одной проблемы: он тратит одинаковое время на все параметры, даже если некоторые из них почти не влияют на результат.

**Частая ошибка: подбор гиперпараметров на тестовой выборке.** Нельзя использовать test set для выбора гиперпараметров - это приводит к утечке информации (data leakage). GridSearchCV использует cross-validation на train set, а test set остаётся нетронутым для финальной оценки. Если вы подбираете параметры по test set, ваша оценка качества будет завышена.

Random Search

Random Search обходит экспоненциальный рост Grid Search: вместо перебора всех комбинаций мы **случайно сэмплируем** N комбинаций из пространства гиперпараметров. При этом значения не ограничены фиксированной сеткой - мы можем задать непрерывные распределения (например, C от 0.01 до 100 по логарифмической шкале) и случайно выбирать точки из них.

Ключевое открытие Bergstra и Bengio (2012): в большинстве задач ML **не все гиперпараметры одинаково важны**. Обычно 1-2 параметра сильно влияют на результат, а остальные - незначительно. Grid Search тратит одинаковое количество попыток на все параметры. Random Search за то же количество попыток исследует больше уникальных значений *важных* параметров, потому что каждая точка имеет уникальную координату по каждой оси.

**Почему Random Search эффективнее Grid Search (при том же бюджете):** Допустим, у нас 2 параметра, но только первый реально влияет на качество. - Grid Search 3x3 (9 точек): мы проверяем **3 уникальных значения** важного параметра - Random Search (9 точек): мы проверяем **9 уникальных значений** важного параметра В 3 раза больше информации о важном параметре при том же бюджете! Исследование Bergstra & Bengio показало: Random Search с 60 попытками находит решение в пределах 5% от оптимума с вероятностью 95%. Grid Search для такого же результата может потребовать сотни или тысячи точек.

**Когда что использовать?** Grid Search - когда параметров 2-3, и вы знаете разумные диапазоны. Random Search - когда параметров 4+, или вы не уверены в диапазонах, или бюджет вычислений ограничен. На практике Random Search - это **default-выбор** для большинства задач: он проще, быстрее и почти всегда находит решение не хуже Grid Search за долю времени.

Bayesian Optimization

Grid Search и Random Search не учатся на своих результатах - каждая следующая точка выбирается независимо от предыдущих. **Bayesian Optimization** работает принципиально иначе: после каждой попытки он строит **модель целевой функции** (surrogate model) и использует её для выбора следующей точки. Это Sequential Model-Based Optimization (SMBO) - каждый новый эксперимент информирован всеми предыдущими.

Surrogate model чаще всего - **Gaussian Process (GP)** или **Tree-structured Parzen Estimator (TPE)**. GP предсказывает не только среднее значение функции в каждой точке, но и **неопределенность** (доверительный интервал). Это позволяет балансировать между двумя стратегиями: **exploitation** (пробовать там, где модель предсказывает хороший результат) и **exploration** (пробовать там, где модель неуверена, потому что данных мало).

**Acquisition function - "где попробовать дальше?":** Acquisition function принимает surrogate model и возвращает следующую точку для оценки: - **Expected Improvement (EI)**: насколько данная точка предположительно *улучшит* текущий лучший результат. Учитывает и среднее предсказание, и неопределенность. - **Upper Confidence Bound (UCB)**: mean + beta * std. Параметр beta контролирует баланс exploration/exploitation. - **Probability of Improvement (PI)**: вероятность, что точка окажется лучше текущего лучшего. Проще EI, но склоняется к exploitation. На практике EI используется чаще всего - хороший баланс без ручной настройки.

**Когда использовать Bayesian Optimization?** Когда оценка модели дорогая (обучение нейросети - часы), параметров много (5+), и каждая попытка на счету. Bayesian Optimization за 20-50 попыток часто находит результат лучше, чем Random Search за 200. Минусы: сложнее в реализации, surrogate model добавляет overhead (для быстрых моделей типа Logistic Regression это может быть дороже, чем сами обучения), и работает хуже в очень высокомерных пространствах параметров (20+).

AutoML

Подбор гиперпараметров - лишь часть задачи. Полный ML pipeline включает предобработку данных, feature engineering, выбор модели, подбор гиперпараметров и ансамблирование. **AutoML** автоматизирует **весь pipeline**: от сырых данных до готовой модели. Идея: если мы умеем автоматически подбирать гиперпараметры, почему бы не автоматизировать и выбор самой модели, и способ обработки данных?

**Популярные AutoML-фреймворки:** **Auto-sklearn** - надстройка над scikit-learn. Использует Bayesian Optimization (SMAC) + meta-learning (учится на предыдущих датасетах, какие модели обычно работают лучше). Строит ансамбли из лучших моделей. **H2O AutoML** - корпоративный уровень. Распределенные вычисления, автоматический stacking и blending. Поддерживает GBM, XGBoost, Deep Learning, GLM. **Google Cloud AutoML / Vertex AI** - облачный сервис. Поддерживает таблицы, изображения, текст, видео. Использует Neural Architecture Search (NAS) для подбора архитектуры нейросетей. **FLAML (Microsoft)** - быстрый и легковесный. Экономичный по вычислениям, хорошо работает с ограниченным бюджетом.

**Neural Architecture Search (NAS)** - отдельное направление AutoML для нейросетей. Вместо фиксированной архитектуры (количество слоев, размеры, типы соединений) NAS автоматически **проектирует архитектуру нейросети**. Google использовал NAS для создания EfficientNet - семейства моделей, которые превосходят вручную спроектированные архитектуры при меньших вычислительных затратах. Но NAS требует огромных ресурсов: оригинальный NASNet использовал 500 GPU в течение 4 дней.

**AutoML - сильный инструмент, но не серебряная пуля.** AutoML не заменяет понимание данных. Он не знает бизнес-контекст: какие признаки имеют смысл, какие метрики важны, какие ограничения у production-системы (latency, память, интерпретируемость). AutoML может найти лучшую модель по accuracy, но выбрать модель с 100ms latency вместо 1ms - а для вашего сервиса это критично. Понимание задачи, данных и ограничений остаётся за инженером.

Итоги

• **Grid Search:** полный перебор всех комбинаций гиперпараметров - гарантирует лучший результат в пределах сетки, но количество комбинаций растет экспоненциально (v^p), что делает его непрактичным при 4+ параметрах
• **Random Search:** случайная выборка из пространства параметров - за тот же бюджет исследует больше уникальных значений важных параметров, чем Grid Search, и работает с непрерывными распределениями вместо фиксированных списков
• **Bayesian Optimization:** строит surrogate model целевой функции и выбирает следующую точку на основе предыдущих результатов (exploration vs exploitation) - за 20-50 попыток часто превосходит Random Search за 200 попыток
• **AutoML:** автоматизирует весь pipeline от предобработки до ансамблирования - как и обещали в начале, вместо поиска иголки в стоге сена руками, мы можем поручить эту работу алгоритмам, которые ищут систематично и учатся на каждой попытке

Связанные темы

Подбор гиперпараметров связывает вместе оценку моделей, оптимизацию и production-деплой:

• Cross-Validation — Фундамент для оценки гиперпараметров: Grid Search, Random Search и Bayesian Optimization используют cross-validation для честной оценки каждой комбинации параметров без утечки данных
• Оптимизаторы (SGD, Adam) — Learning rate - один из главных гиперпараметров оптимизаторов. Подбор lr и других параметров (momentum, weight decay) через Bayesian Optimization может ускорить сходимость нейросетей в разы
• Feature Engineering — AutoML автоматизирует не только подбор модели, но и feature engineering - создание и отбор признаков. Правильные features часто важнее правильных гиперпараметров
• MLOps Pipeline — В production подбор гиперпараметров интегрируется в CI/CD pipeline: автоматический ретюнинг при дрифте данных, эксперимент-трекинг (MLflow, W&B) для логирования результатов

Вопросы для размышления

• Если Random Search эффективнее Grid Search в большинстве случаев, почему Grid Search до сих пор широко используется? В каких ситуациях детерминированность и полнота перебора важнее эффективности?
• Bayesian Optimization балансирует exploration и exploitation. Как эта дилемма проявляется в других областях - например, при выборе ресторана (ходить в проверенный vs пробовать новый) или при найме сотрудников?
• AutoML автоматизирует рутинные части ML pipeline. Какие аспекты ML-инженерии принципиально не поддаются автоматизации, и почему?

Связанные уроки

• ml-42-feature-engineering — Тюнинг идёт после подготовки признаков
• ml-44-cross-validation — Cross-validation оценивает каждую конфигурацию
• ml-28-optimizers — Learning rate - ключевой гиперпараметр
• ml-45-mlops-pipeline — Тюнинг автоматизируется в пайплайнах
• prob-04-bayes — Байесовская оптимизация направляет поиск
• stat-26-experimental-design