Каков полный пайплайн обучения модели

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

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

Как отвечать

Идите по этапам и у каждого называйте инструмент и риск:

• постановка: какую бизнес-метрику двигаем, какая ML-метрика ей соответствует, какой бейзлайн (правило, константа, логистическая регрессия);
• данные: источники, разметка, версионирование (DVC или снапшоты в хранилище), проверка схемы и качества;
• разбиение: до любой предобработки. Временные данные делят по времени, пользовательские по группам (GroupKFold), иначе один и тот же человек окажется и в train, и в test;
• предобработка: пропуски, кодирование, масштабирование внутри sklearn.pipeline.Pipeline и ColumnTransformer, чтобы статистики считались только на train;
• обучение и подбор: кросс-валидация, подбор гиперпараметров (Optuna или GridSearchCV), учёт экспериментов в MLflow;
• оценка: метрики под задачу (ROC-AUC и PR-AUC при дисбалансе, MAE или RMSE в регрессии), сравнение с бейзлайном, разбор ошибок по сегментам. Отложенный test смотрят один раз, в самом конце;
• выкатка: регистрация модели, упаковка в сервис или батч-скоринг, A/B-тест или теневой режим;
• мониторинг: дрейф входных данных и предсказаний, задержка, качество на запоздавшей разметке, условие для переобучения.

Оркестрацию называйте ту, что использовали сами: Airflow, Kubeflow, Prefect или cron со скриптами.

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

Масштабируют признаки или считают target encoding по всему датасету до разбиения. Метрика на валидации завышена, а в проде качество проседает.

Считают, что тестовая выборка «предотвращает переобучение». Она только оценивает обобщение, а если по ней подбирать гиперпараметры, оценка перестаёт быть честной.

Заканчивают рассказ на accuracy. Без выкатки, мониторинга и плана переобучения это пайплайн эксперимента, а не модели.