Дисбаланс классов — это ситуация, когда объектов одного класса в датасете намного больше, чем другого. Например, 98% легитимных транзакций и 2% мошеннических. На таких данных модель может показывать высокую accuracy, но плохо находить действительно важные редкие случаи.
Почему это проблема:
- модель учится “играть в большинство” и игнорирует миноритарный класс
- метрика accuracy становится обманчивой
- ошибки по редкому классу часто самые дорогие для бизнеса
Как понять, что данные несбалансированы 📊
Проверьте распределение классов ещё до обучения. Если разница кратная — это сигнал. Но важен и контекст: даже соотношение 90/10 может быть критичным, если нужно находить редкие события с высокой точностью.
Какие метрики использовать вместо accuracy
При дисбалансе смотрят на:
- Precision — сколько найденных положительных объектов действительно положительные
- Recall — сколько реальных положительных объектов модель нашла
- F1-score — баланс precision и recall
- ROC-AUC — общее качество ранжирования
- PR-AUC — особенно полезна при сильном дисбалансе
Основные методы обработки дисбаланса 🛠️
-
Undersampling
Уменьшение числа объектов мажоритарного класса.
Плюс: быстро и просто.
Минус: можно потерять полезную информацию. -
Oversampling
Увеличение числа объектов миноритарного класса.
Плюс: сохраняются данные большинства.
Минус: при простом копировании возможен переобучение. -
SMOTE и похожие методы
Создают синтетические примеры миноритарного класса, а не просто дублируют существующие.
Хорошо работают на табличных данных, но требуют аккуратной валидации. -
Class weights
Назначение большего веса редкому классу в функции потерь.
Часто это лучший первый шаг, особенно для логистической регрессии, SVM, деревьев и бустинга. -
Настройка порога классификации
По умолчанию модель может относить объект к классу “1” только при вероятности выше 0.5. Но для задач поиска редких событий порог часто снижают, чтобы поднять recall.
Важные практические правила ✅
- делайте oversampling/SMOTE только на train, не на всём датасете
- используйте stratified split при разбиении выборки
- сравнивайте модели по бизнес-метрикам, а не только по ML-метрикам
- проверяйте calibration probabilities, если работаете с вероятностями
- не применяйте методы “на автомате”: иногда достаточно class weights и правильного threshold
Что выбрать на практике
- для базового старта: `class_weight='balanced'`
- для табличных данных: попробовать SMOTE + кросс-валидацию
- для сильного дисбаланса: оптимизировать threshold под precision/recall
- для продакшна: оценивать не только качество, но и стоимость ошибок 💡
Главная идея: дисбаланс классов — не “проблема данных”, а особенность задачи. Побеждает не та модель, у которой выше accuracy, а та, которая лучше находит ценные для бизнеса случаи.
👀 Ниже по ленте — мягко рекомендую посмотреть подборку каналов про IT: там много полезного про ML, аналитику, разработку и карьеру.