Как устроен pipeline для бинарной классификации с большим количеством признаков и данных

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

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

Как отвечать

Пройдите по этапам и у каждого назовите решение, а не общее слово:

• данные: колоночный формат (Parquet), обработка через Spark или Polars, если в память не влезает. Выборку собирают по состоянию на момент события, чтобы в признаки не попало будущее;
• разбиение: для данных со временем делите по времени (out-of-time), а не случайно. Для кросс-валидации TimeSeriesSplit или StratifiedKFold, если классы сильно несбалансированы;
• препроцессинг: всё, что учится на данных (импутация, скейлинг, target encoding), живёт внутри Pipeline с ColumnTransformer и обучается только на трейне;
• признаки: категории с тысячами значений не раздувают в one-hot, а кодируют через target encoding по фолдам или отдают CatBoost как есть. Отбор: L1-регуляризация, permutation importance или SHAP, отсев константных и сильно коррелирующих;
• модель: на табличных данных базой служит градиентный бустинг (LightGBM, XGBoost, CatBoost), логистическая регрессия нужна как ориентир и ради интерпретируемости;
• оценка: ROC-AUC, а при редком положительном классе PR-AUC. Порог выбирают под стоимость ошибок для бизнеса, вероятности при необходимости калибруют;
• после релиза: мониторинг дрейфа признаков (PSI) и качества на размеченных данных, плановое переобучение.

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

Обучают скейлер или энкодер на всём датасете до разбиения. Метрика на валидации выходит завышенной, а в проде модель проседает.

Считают accuracy при доле положительного класса в пару процентов. Модель, которая всегда отвечает «нет», получает 98% и не находит ничего.

Делят случайно данные, где важен порядок во времени. Признаки, посчитанные с заглядыванием вперёд, дают красивую валидацию и провал на новых данных.