Использовали ли вы hyperparameter tuning в проектах

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

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

Как отвечать

Стройте рассказ на своём проекте: задача, модель, метрика, данные. Затем каркас:

• что подбирали: для градиентного бустинга learning_rate, max_depth или num_leaves, min_child_samples, регуляризацию, долю подвыборки строк и признаков. Число деревьев чаще не перебирают, а ограничивают через early stopping;
• чем: GridSearchCV годится для двух-трёх параметров. Когда их больше, RandomizedSearchCV при том же бюджете обычно находит область не хуже. Дальше байесовский поиск через Optuna с прунингом неудачных попыток, для распределённого подбора Ray Tune;
• схема валидации: для временных рядов TimeSeriesSplit, для данных с группами GroupKFold, предобработка внутри Pipeline, чтобы она обучалась только на фолде. Финальная оценка на отложенном тесте, который в подборе не участвовал;
• результат: метрика до и после в ваших единицах, например MAE или ROC AUC, и сколько времени заняли эксперименты.

Приводите свои реальные цифры и честно говорите, если прирост был скромным. Обычно так и бывает: хорошие признаки и чистые данные дают больше, чем тюнинг, и понимание этого ценят. Трекинг экспериментов в MLflow или W&B тоже стоит упомянуть.

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

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

Отчитываются метрикой на той валидации, на которой подбирали параметры, и выдают её за итоговое качество.

Запускают сетку по шести параметрам на тысячи комбинаций, не посчитав бюджет.

Берут случайный KFold для прогноза спроса, и будущее утекает в обучение. Метрика отличная, а в продакшене модель проваливается.