Как проводили валидацию

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

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

Как отвечать

Разведите две части и расскажите про свой проект, со своими цифрами:

• валидация данных: проверки схемы, типов, диапазонов и доли пропусков до обучения. Инструменты: pandera, Great Expectations или собственные проверки через assert в пайплайне, плюс контроль дрейфа распределений между обучающими и свежими данными;
• схема разбиения: отложенная выборка, StratifiedKFold при дисбалансе классов, GroupKFold, если у одного клиента много строк, и TimeSeriesSplit или разбиение по дате, когда модель будет предсказывать будущее;
• метрики: выбраны от задачи. Для редкого класса ROC-AUC плюс PR-AUC, precision и recall на рабочем пороге, а не accuracy;
• анализ ошибок: метрики по сегментам (новые клиенты, регионы, каналы), разбор худших предсказаний, проверка калибровки, если важна сама вероятность;
• финальная проверка: тестовая выборка, которую не трогали при подборе гиперпараметров, а затем онлайн: A/B-тест или теневой запуск рядом с текущей моделью.

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

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

Говорят, что кросс-валидация «защищает от переобучения». Она только честнее оценивает качество, а от переобучения защищают регуляризация, более простая модель и больше данных.

Перемешивают данные со временем случайным k-fold. Модель видит будущее, метрика на валидации красивая, а в проде качество проседает.

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