Как планируется валидация модели?

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

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

Как отвечать

Постройте ответ как план, который вы составляете на старте проекта, и опирайтесь на свой проект:

• метрика и порог успеха: сначала договоритесь, чем измеряется польза: ROC AUC, PR AUC, MAE или деньги на тысячу прогнозов, и какой результат нужен, чтобы модель имело смысл внедрять. Рядом держите бейзлайн: константу, простое правило или текущую модель;
• схема разбиения: повторяет боевые условия. Для независимых объектов StratifiedKFold, для данных во времени TimeSeriesSplit или разбиение по дате, для нескольких записей одного клиента GroupKFold, иначе один человек окажется и в обучении, и в проверке;
• отложенная выборка: тест, которого не касаются при подборе признаков и гиперпараметров. Если вы смотрели на тест десять раз, это уже валидация;
• проверка утечек: признаки, посчитанные после целевого события, скейлер или энкодер, обученный на всей выборке до разбиения. Лечится Pipeline внутри кросс-валидации;
• разрезы и стабильность: метрика по сегментам, разброс по фолдам, поведение на самом свежем периоде;
• онлайн: A/B-тест или теневой запуск и мониторинг дрейфа после выката.

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

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

Называют пропорцию вроде 70/15/15 как правило. Доли зависят от объёма и структуры данных, а на временных рядах случайное перемешивание даёт завышенную оценку.

Путают назначение выборок: подбирают гиперпараметры по тесту и потом выдают эту же цифру за итоговую оценку.

Говорят только про офлайн-метрики. Модель с хорошим AUC может не сдвинуть бизнес-показатель, поэтому без плана онлайн-проверки ответ выглядит незаконченным.