Пропуск как сигнал: когда MissingIndicator помогает модели, а когда обманывает

В анкете клиента иногда нет данных о доходе. Команда заполняет его медианой, и модель больше не различает человека с настоящим медианным доходом и человека, который не указал доход. Если отказ отвечать связан с последующим поведением, сама пустота может быть полезным сигналом. Для этого рядом с заполненным числом добавляют индикатор: было ли значение пропущено.

Что именно добавляет индикатор

SimpleImputer(add_indicator=True) запоминает при fit, в каких входных полях были пропуски, и добавляет для них бинарные столбцы при transform. Он не создаёт индикатор для поля, полностью заполненного в обучении, даже если пропуск в нём появится позже. Это важно для контракта сервиса: размер выходной матрицы фиксируется обучающей схемой.

import numpy as np
from sklearn.impute import SimpleImputer

train = np.array([[1., 10.], [np.nan, 20.], [3., 30.]])
new = np.array([[np.nan, np.nan]])
imputer = SimpleImputer(strategy="median", add_indicator=True).fit(train)
print("обучающие признаки с пропусками:", imputer.indicator_.features_.tolist())
print("новая строка:", imputer.transform(new).tolist())
assert imputer.transform(new).shape == (1, 3)
assert imputer.transform(new)[0, -1] == 1

Первая колонка в train содержала пропуск, вторая была полной. Для новой строки с двумя пустыми значениями имьютер выдаёт два заполненных числа и один индикатор: всего три выхода. Второй пропуск заполняется медианой, но отдельного флага для него нет. Если нужно отслеживать пропуск в любом поле, используйте явно заданную схему индикаторов для всех полей и проверьте её вместе с моделью.

Когда сигнал превращается в ловушку

Индикатор помогает только если причина пропуска достаточно похожа в обучении и при использовании. Допустим, доход не указан потому, что клиент сознательно пропустил вопрос. Через месяц форму поменяли и поле перестало передаваться из-за ошибки API. Та же единица индикатора теперь означает поломку, а модель может трактовать её как прежний тип клиента. Поэтому рядом с качеством модели отслеживайте долю пропусков по полям и по источникам заявок.

Как и любую обработку данных, имьютер надо обучать только на train. Пропуски после релиза не должны менять сохранённую медиану и набор индикаторных колонок. Пример утечки при заполнении до разделения показывает, как тестовая строка может изменить статистику для train. Здесь другой вопрос: стоит ли сохранить информацию о факте отсутствия после корректного заполнения.

Сравните одинаковые фолды с индикатором и без него. Посмотрите ошибки отдельно для строк с пропуском и без него. Если улучшение есть только в историческом источнике, который скоро исчезнет, не рассчитывайте на его перенос. Если доля пропусков мала, оценка будет шумной; укажите число таких строк рядом с метрикой. Для некоторых моделей, например градиентного бустинга с собственной обработкой NaN, отдельный имьютер может быть не нужен — сравнивайте готовые пайплайны, а не отдельные компоненты.

При анализе эффекта индикатора не подменяйте прогноз причинным объяснением. Если пропуск дохода связан с определённым типом клиента, модель может использовать этот сигнал для оценки риска, но это не доказывает, что отказ назвать доход вызывает риск. Для решения о сборе данных полезнее спросить, можно ли безопасно и стабильно получать само значение и что произойдёт, если форма изменится.

На курсе «ML Engineer / Data Scientist: табличные модели в продакшн» вы проходите обработку пропусков, построение признаков, валидацию и контроль качества после выпуска. Это помогает решить, когда отсутствие поля несёт сигнал, а когда указывает на сбой данных. Откройте программу курса.