Дисбаланс классов: как проверять модель на редких событиях

Дисбаланс классов означает, что примеры разных категорий встречаются с заметно разной частотой. Это обычная ситуация для поиска задержек, сбоев и других редких событий. Проблема состоит в том, что удобный общий показатель может скрыть плохую работу именно с нужной категорией.

Прежде чем менять состав данных, определите цену ошибок и рабочее ограничение. Сколько предупреждений способны проверить сотрудники? Какая доля реальных проблем должна быть найдена? Без этих условий увеличение одного показателя может перегрузить процесс ложными сигналами.

Начните с постоянного прогноза

В вымышленном наборе из 100 заказов десять задержаны, 90 выполнены вовремя. Правило «всегда считать заказ своевременным» получит accuracy 90% и пропустит все задержки.

Такой baseline полезен для первого сравнения. Он показывает, почему высокая доля верных ответов ещё не означает способность находить редкое событие.

Покажите число найденных задержек, пропусков и ложных предупреждений. Рядом можно использовать precision, recall и F1-score, явно назвав положительный класс и правила расчёта.

Сохраните независимую проверку

Проверочная часть должна отражать задачу будущего использования. Если редкое событие в ней искусственно сделать частым, некоторые показатели и нагрузка от предупреждений перестанут соответствовать рабочей ситуации.

В документации imbalanced-learn отдельно разбирается ошибка изменения состава всего набора до разделения на обучение и тест. Она может вызвать утечку информации и слишком оптимистичную оценку качества.

Сначала организуйте разделение, затем применяйте изменение состава только внутри соответствующей обучающей части. Если используется перекрёстная проверка, это правило действует на каждом её этапе.

Какие подходы сравнить

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

Добавление копий не создаёт новых независимых наблюдений. Синтетические примеры тоже зависят от выбранного способа построения и исходных данных. Редкие, но ошибочно размеченные строки могут получить чрезмерное влияние после такого усиления.

Поэтому сначала полезно проверить несколько реальных положительных случаев вручную. Убедитесь, что событие определено одинаково и что у каждого объекта завершилось нужное окно наблюдения.

Порог подбирается под действие

Модель с оценкой риска можно настраивать на разный объём предупреждений. Более низкий порог способен найти больше проблем, но одновременно увеличить число ложных тревог. Конкретный компромисс проверяют на данных.

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

Выбранный порог проверяется отдельно от данных, использованных для его подбора. При изменении частоты событий результат может потребовать повторной оценки.

Что включить в итоговый отчёт

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

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