Фичи и утечки данных (data leakage)

На табличных данных признаки (features) решают больше, чем выбор модели. Разбираем преобразования фичей, target encoding и утечку данных (data leakage) — из-за неё AUC 0.99 оффлайн превращается в 0.6 в проде.

Интуиция

Смена алгоритма на табличных данных обычно даёт доли процента, а одна хорошо придуманная фича — проценты и десятки процентов. Модель видит мир только через признаки: если в них нет сигнала, никакой бустинг его не выдумает. Поэтому инженерия признаков (feature engineering) — это перевод знаний о задаче на язык чисел, который понятен модели.

Но у этой силы есть тёмная сторона: чем изобретательнее фичи, тем легче случайно протащить в них информацию, которой в момент предсказания ещё не существует. Это и есть утечка данных — главный источник «слишком хороших» моделей.

Как это работает: виды преобразований

• Числовые. Масштабирование (standardization/min-max) — чтобы градиентные методы сходились, а расстояния в kNN имели смысл. Логарифм — для признаков с тяжёлым хвостом (доход, цена: log(1 + x) сжимает миллионы к разумной шкале). Биннинг (binning) — разбить непрерывный признак на корзины, чтобы линейная модель поймала нелинейность.
• Категориальные. One-hot encoding — по бинарной колонке на каждую категорию; взрывается на высококардинальных признаках (тысячи городов → тысячи колонок). Target encoding — заменить категорию средним значением таргета по ней; компактно и мощно, но это микро-утечка таргета, если считать среднее без кросс-валидационной схемы (out-of-fold).
• Даты. День недели, месяц, праздник/выходной, время с последнего события — календарь несёт сезонность почти любого человеческого поведения.
• Агрегаты по истории. «Средний чек за 30 дней до заявки», «число заказов за неделю» — окно должно заканчиваться строго в момент предсказания, ни днём позже.

Утечка данных: четыре сценария

Утечка (data leakage) — это когда фича «подглядывает» в будущее или прямо в таргет. Модель на такой фиче выглядит гениально на валидации и разваливается в проде, где будущего ещё нет. Четыре классических сценария:

• Прямая утечка таргета. Поле заполняется ПОСЛЕ события, которое мы предсказываем: «дата дефолта», «статус одобрения», «число звонков коллекторов». В историческом датасете оно есть, в момент заявки — нет.
• Временная утечка. Random split временных данных: строки из будущего попадают в train, и модель «учится на будущем» — например, запоминает уровень цен следующего месяца.
• Утечка через предобработку. Масштабирование, отбор фичей или target encoding посчитаны на всём датасете до сплита — статистики теста просочились в обучение.
• Дубликаты между train и test. Одна и та же строка (или почти одна) в обеих частях — модель «узнаёт» ответ вместо того, чтобы обобщать.

Главный симптом один: подозрительно высокая оффлайн-метрика и провал после деплоя. Если AUC вдруг 0.99 — сначала ищи утечку и только потом радуйся. Истории на эту тему одинаковы во всех компаниях: модель предсказания оттока «обнаруживает», что лучший признак ухода клиента — обнулённый тариф (который проставляют при закрытии договора), а модель диагностики по снимкам учится узнавать метку сканера реанимационного отделения вместо болезни. В обоих случаях сигнал настоящий, просто он появляется вместе с ответом или после него.

Как защититься

• Для временных данных — только сплит по времени: train строго раньше test (подробнее — в теме про временные ряды).
• Вся предобработка живёт внутри пайплайна и делает fit только на train: scaler.fit(X_train), а не scaler.fit(X).
• Target encoding — только по out-of-fold схеме: среднее для строки считается по фолдам, в которых этой строки нет.
• Аудит фичей: для каждой — источник, момент появления значения, ответ на вопрос «известна ли при предсказании?». Слишком важная фича в feature importance — повод для подозрения, а не для гордости.