Что такое data leakage при обучении модели — использование при построении модели информации, которой не будет в момент прогноза. Документация scikit-learn формулирует это так: утечка возникает, когда сведения, недоступные во время предсказания, применяются при обучении. Разберём виды утечки, паспорт доступности признаков и проверяемые признаки дефекта.
Утечка при обучении и разглашение данных
Это два разных события, и путать их дорого. Утечка при обучении — статистическая проблема: модель получает доступ к сведениям из будущего или из проверочной части, из-за чего оценка качества становится недостоверно высокой. Разглашение данных — инцидент приватности: персональные сведения попали туда, где их видеть не должны. Первое ломает валидацию, второе ломает доверие и подпадает под регуляторику.
Документация scikit-learn описывает утечку через доступность в момент прогноза. AWS Prescriptive Guidance добавляет вторую грань: утечка случается, когда модель обучают на признаках, недоступных в продакшене в момент вызова инференса. Обе формулировки указывают на одно — признак должен существовать в тот момент, когда модель делает предсказание.
Практический вывод прост: разбираясь с утечкой, вы отвечаете на вопрос «мог ли этот столбец существовать в момент прогноза». Разбираясь с разглашением, вы отвечаете на вопрос «кто имеет право видеть эти значения». Это разные вопросы, разные владельцы и разные меры защиты.
Частая ошибка новичка — считать, что высокая метрика подтверждает корректность. Она подтверждает только то, что модель хорошо воспроизвела закономерность в проверочной выборке. Если в выборку просочилась информация из будущего, метрика будет высокой и при этом бесполезной.
Целевая утечка: признаки должны существовать в момент прогноза
Целевая утечка — самый прямолинейный вид. В признаки попадает столбец, который прямо или косвенно содержит ответ. Классический пример: прогнозируем отказ от заказа, а среди признаков оказывается refund_issued_at — дата возврата. Возврат оформляют после отказа, значит в момент прогноза этого значения ещё нет.
Проверка строится на одном вопросе к каждому столбцу: когда появляется это значение в реальной жизни? Если позже момента прогноза — столбец убирают. Если раньше — оставляют. Косвенная утечка сложнее: столбец сам по себе безобиден, но коррелирует с целевой переменной через цепочку событий. Например, final_status в CRM обновляется после закрытия заказа, и его наличие в признаках равносильно подсказке.
Документация AWS называет ещё один источник: наборы с избытком дублирующихся образцов. Если один и тот же заказ попал и в обучение, и в проверку, модель узнаёт его, и метрика растёт без реального обобщения. Google для разработчиков формулирует критерий честной проверки: честная проверка требует новых примеров и исключения дубликатов обучающих данных.
Порядок действий для целевой утечки:
- Выписать для каждого признака момент его появления в бизнес-процессе.
- Сравнить этот момент с моментом прогноза.
- Убрать признаки, появляющиеся позже.
- Перепроверить оставшиеся на косвенную связь с целевой переменной.
- Зафиксировать решение в паспорте доступности.
Паспорт доступности: четыре заполненные строки
Паспорт доступности — таблица, где для каждого признака указано время появления и решение. Ниже учебный пример для прогноза отказа от заказа в момент 2026-01-10T10:00Z. Значения условные и приведены как образец заполнения.
| Признак | Время появления | Решение |
|---|---|---|
| order_total | 2026-01-10T09:59Z | можно |
| customer_age | 2026-01-10T09:00Z | можно |
| refund_issued_at | 2026-01-12T12:00Z | нельзя |
| final_status | 2026-01-15T00:00Z | нельзя |
Разбор строк. order_total известен за минуту до прогноза — признак допустим. customer_age известен за час — тоже допустим. Даты refund_issued_at и final_status позже момента прогноза, поэтому оба признака исключаем.
Такой паспорт полезен тем, что решение видно без обсуждения. Когда признак возвращают в модель, вопрос «почему он здесь» получает ответ из таблицы. Заполняйте паспорт до обучения; подозрительно высокая метрика дополнительно даёт повод проверить его заново.
Учебный пример можно сохранить как текстовый файл и вести рядом с кодом. Формат не важен: важна колонка с временем появления, потому что именно она превращает спор о признаках в проверяемое решение.
Тестовая выборка и fit препроцессинга
Вторая крупная категория — утечка через предобработку. Документация scikit-learn даёт прямое правило: сначала разделите данные на обучающую и тестовую части, в особенности до любых шагов предобработки. И второе правило из того же источника: никогда не вызывайте fit на тестовых данных.
Почему это критично. Масштабирование, заполнение пропусков, кодирование категорий и отбор признаков — все эти шаги считают статистики по данным. Если посчитать среднее и стандартное отклонение по всему массиву, тестовая часть повлияет на преобразование обучающей. Модель получит косвенную информацию о тестовых значениях.
Правильный порядок для одного преобразования:
split -> fit_transform(X_train) -> transform(X_test)
Неправильный порядок, который встречается чаще всего:
fit_transform(весь X) -> split
Во втором случае статистики посчитаны по объединённым данным, и проверка перестаёт быть честной. Ошибка опасна тем, что код работает, метрика выглядит прилично, а расхождение с продакшеном обнаруживается позже.
Отбор признаков подчиняется тому же правилу. Если вы выбираете признаки по корреляции с целевой переменной на всём массиве, тестовая часть участвует в выборе. Документация scikit-learn относит это к утечке наравне с предобработкой. Отбор проводят внутри обучающей части, а на тестовую применяют уже зафиксированное решение.
Pipeline и кросс-валидация
Pipeline в scikit-learn собирает предобработку и модель в один объект. При кросс-валидации это даёт конкретное преимущество: преобразования пересчитываются внутри каждого фолда на обучающей части фолда, а на проверочную часть применяются только через transform. Ручной код с предварительным масштабированием всего массива такого поведения не даёт.
Схема работы Pipeline при кросс-валидации:
- Данные разбиваются на фолды.
- В каждом фолде препроцессоры выполняют fit_transform на обучающей части, а конечная модель обучается через fit.
- Проверочная часть проходит transform препроцессоров, затем модель делает предсказания.
- Метрика считается на проверочной части.
- Статистики преобразований не переносятся между фолдами.
Такой порядок убирает целый класс ошибок, связанных с предобработкой. Он не защищает от целевой утечки: если refund_issued_at лежит среди признаков, Pipeline спокойно его использует. Он не защищает и от групповой утечки, когда один клиент попал в разные фолды. Pipeline закрывает вопрос предобработки, остальные виды утечки требуют отдельных решений.
Документация Microsoft по автоматизированному ML описывает смежную проблему: одна и та же валидационная выборка используется на каждой итерации настройки, из-за чего модель подстраивается под неё и оценка смещается. Google для разработчиков называет это изнашиванием: тестовые и валидационные наборы теряют свежесть при повторном использовании. Практический вывод — держать отдельный тестовый набор, который открывают редко.
Группы, повторы и время в split
Случайное разбиение подходит не для всех данных. Документация scikit-learn описывает GroupKFold как вариант K-fold, который следит за тем, чтобы одна группа не оказалась одновременно в обучающей и проверочной частях. GroupShuffleSplit работает как комбинация ShuffleSplit и LeavePGroupsOut и генерирует случайные разбиения, где подмножество групп удерживается для каждой проверки.
Учебный пример: один клиент имеет два заказа. Если оба заказа попали в разные части разбиения, модель может запомнить клиента и показать завышенную метрику. GroupKFold и GroupShuffleSplit дают повод рассмотреть групповое разбиение по идентификатору клиента. Документация GroupKFold уточняет: каждая группа появляется в тестовой части ровно один раз за все фолды, а число различных групп должно быть не меньше числа фолдов.
Временные данные требуют отдельного подхода. Документация scikit-learn подчёркивает: модель для временных рядов важно оценивать на будущих наблюдениях, наименее похожих на те, что использовались при обучении. Случайное перемешивание строк здесь ломает смысл проверки, потому что модель увидит будущее.
Сводка по выбору схемы разбиения:
| Ситуация | Схема | Что защищает |
|---|---|---|
| Независимые объекты | KFold | Базовое разбиение |
| Один объект в нескольких строках | GroupKFold | Групповая утечка |
| Нужны случайные разбиения по группам | GroupShuffleSplit | Групповая утечка |
| Временной порядок | Разбиение по времени | Утечка из будущего |
Схема разбиения снижает риск, но не гарантирует отсутствие всех утечек. После выбора схемы стоит вернуться к паспорту доступности и проверить признаки ещё раз.
Признаки дефекта: высокая метрика и проверки
Высокая метрика сама по себе не доказывает утечку. Она может отражать реальную закономерность в данных. Доказательством служат проверяемые признаки дефекта, которые можно найти в коде и данных.
Список проверок, которые дают конкретный ответ:
- Сверьте метрику на тестовой части с метрикой на продакшене. Большой разрыв указывает на проблему.
- Проверьте, вызывается ли fit на тестовых данных. Документация scikit-learn называет это прямым нарушением.
- Просмотрите список признаков на столбцы, появляющиеся после момента прогноза.
- Посчитайте долю дубликатов между обучающей и тестовой частями.
- Проверьте, не пересекаются ли группы между частями разбиения.
- Убедитесь, что отбор признаков проводился внутри обучающей части.
- Сравните распределения признаков в обучении и в продакшене.
Каждая проверка даёт наблюдаемый результат: число, список столбцов, долю пересечений. Такой результат можно обсудить и исправить. Ощущение «метрика слишком хорошая» обсуждению не поддаётся.
Отдельно стоит проверить порядок операций в коде. Схема split -> fit_transform(X_train) -> transform(X_test) читается глазами за несколько секунд и снимает подозрения по предобработке. Схема с fit_transform до разбиения требует переписывания.
Частые вопросы
Чем data leakage отличается от разглашения персональных данных?
Утечка при обучении — статистическая проблема: модель получает информацию из будущего или из проверочной части, и оценка качества становится недостоверной. Разглашение данных — инцидент приватности, когда персональные сведения оказались у того, кто не должен их видеть. Первое ломает валидацию, второе подпадает под регуляторные требования.
Что такое целевая утечка простыми словами?
В признаки попадает столбец, значение которого становится известно после момента прогноза. Пример — дата возврата при прогнозе отказа от заказа: возврат оформляют позже, значит в момент предсказания этого значения нет. Такой признак даёт модели подсказку и завышает метрику.
Почему нельзя делать fit на тестовой выборке?
Fit считает статистики по данным: среднее, стандартное отклонение, границы категорий. Если посчитать их по объединённому массиву, тестовая часть повлияет на преобразование обучающей. Документация scikit-learn называет вызов fit на тестовых данных прямым нарушением.
Когда нужен GroupKFold?
Когда один объект встречается в данных несколько раз. Если заказы одного клиента попали в разные части разбиения, модель может запомнить клиента. GroupKFold следит за тем, чтобы группа не оказалась одновременно в обучающей и проверочной частях.
Высокая метрика всегда означает утечку?
Нет. Высокая метрика может отражать реальную закономерность. Признаками дефекта служат проверяемые вещи: разрыв между тестовой и продакшен-метрикой, вызов fit на тестовых данных, столбцы с временем появления после прогноза, дубликаты между частями, пересечение групп.