Data leakage

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

Ключевые тезисы

Типичные источники: масштабирование до сплита, признаки из будущего, дубликаты между train и test.
В временных рядах любое перемешивание — почти гарантированная утечка.
Симптом: офлайн-метрика заметно лучше, чем всё, что вы видите в проде.

2 подтем — раскройте любую, чтобы увидеть объяснение, формулы, примеры и интерактивные графики.

Пять типовых сценариев, покрывающих большинство реальных случаев.

Предобработка до разбиения: StandardScaler, отбор признаков или SMOTE, применённые ко всей выборке.
Признаки из будущего: «дата закрытия договора» в задаче предсказания оттока.
Прокси целевой переменной: сумма_страховой_выплаты при предсказании факта страхового случая.
Дубликаты между train и test: один и тот же клиент или почти одинаковые изображения.
Групповая утечка: несколько записей одного пациента разъехались по разным частям выборки.

Как это выглядит

ROC-AUC на кросс-валидации 0.98, в проде — 0.62. Разбор показывает: признак последний_платёж_дата заполняется только после того, как клиент ушёл.

Дисциплина, которая ловит утечку до релиза.

Для каждого признака ответьте: был бы он известен в момент предсказания?
Подозрительно высокая метрика — повод искать ошибку, а не радоваться.
Посмотрите на важности: один признак с важностью 0.9 почти всегда означает утечку.
Проверяйте пересечение групп между train и test явным кодом, а не на глаз.
Валидация по времени: обучаемся на прошлом, проверяемся на будущем — так же, как будет в проде.

фолд 1

фолд 2

фолд 3

фолд 4

фолд 5

обучение валидация

обучений модели5

доля валидации20%

схемаK-Fold

Число фолдов K5

Схема разбиения

Переключите схему на временную: валидация всегда идёт после обучающего периода, будущее не используется

Надёжность данных · Утечки и честная валидация