Data leakage в машинном обучении: как найти утечку

Data leakage возникает, когда при обучении или оценке используется информация, которой не будет в момент реального прогноза. Модель демонстрирует высокий offline-score, но после запуска качество резко падает.

Target leakage — признак прямо или косвенно содержит результат. Например, статус возврата нельзя использовать для прогноза возврата в момент покупки. Temporal leakage — в признаки попадает будущее: итоговый баланс месяца используется для решения в его начале.

Утечка бывает и между объектами: дубликаты, строки одного пользователя или соседние кадры видео оказываются по разные стороны случайного split. Модель узнаёт конкретный объект вместо общей закономерности.

Preprocessing тоже может подсматривать

Если заполнить пропуски медианой всей таблицы, масштабировать по всем данным или отобрать признаки по связи с target до split, validation повлияла на параметры преобразования. Разница может быть небольшой, но контракт оценки уже нарушен.

Сначала делите данные, затем fit-ите все обучаемые преобразования только на train. Pipeline помогает повторить эту дисциплину внутри cross-validation. Oversampling выполняют только в train-fold, иначе синтетические родственники одного объекта попадают в проверку.

Особенно внимательно проверяйте агрегаты: «число покупок пользователя» должно быть рассчитано только до timestamp прогноза, а не по всей его истории.

Чек-лист поиска утечки

Для каждого признака спросите: когда он появляется, из какой системы приходит и был ли доступен до решения? Постройте lineage от raw-события до матрицы признаков. Проверьте слишком сильные одиночные признаки, дубликаты и резкий разрыв между случайным и временным split.

Запустите простой baseline. Подозрительно идеальная метрика в сложной задаче — повод искать утечку, а не праздновать. Удаляйте группы потенциально опасных признаков и смотрите, как меняется качество. Сравнивайте offline-распределения с production shadow data.

Лечение — не просто удалить один столбец, а изменить момент формирования dataset и закрепить point-in-time correct pipeline. Тогда будущая информация не вернётся под новым названием.

Утечка из признака, который появился после покупки

Нужно предсказывать покупку до оформления заказа. Поле paid_at заполняется только после успешной оплаты. Даже если оно сильно улучшает validation score, в момент реального прогноза этого значения ещё нет. Это утечка доступности признака, которую не исправляет случайное перемешивание строк.

Запишите для каждого столбца источник и момент доступности. В учебном примере sessions_last_7d и country известны до прогноза, а paid_at и refund_status относятся к будущему.

available_before_prediction = {"sessions_last_7d", "country"}
selected_features = ["sessions_last_7d", "paid_at", "country"]
leaked = set(selected_features) - available_before_prediction
print(sorted(leaked))
assert leaked == {"paid_at"}

Эта проверка использует вручную составленный контракт доступности, а не волшебное определение утечек по названию поля. Признак с нейтральным именем тоже может содержать будущее. Препроцессинг обучают на train, а сохранённое преобразование применяют к validation/test. Рекомендации по предотвращению leakage.

Продолжите разбор: Переобучение и недообучение модели: как отличить.