В сети есть множество постов и ресурсов, которые учат нас бороться с несбалансированностью классов (class imbalance) в задаче классификации. Обычно они предлагают методы сэмплирования: искусственно дублировать наблюдения из редкого класса, или выкинуть часть наблюдений из популярного класса. Этим постом я хочу прояснить, что «проклятие» дисбаланса классов – это миф, важный лишь для отдельных типов задач.
Начнём с того, что не все модели машинного обучения плохо работают с несбалансированными классами. Большинство вероятностных моделей слабо зависят от баланса классов. Проблемы обычно возникают, когда мы переходим к не-вероятностной или многоклассовой классификации.
В логистической регрессии (и её обобщениях – нейросетях) баланс классов сильно влияет на свободный член, но очень слабо – на коэффициенты наклона. Действительно, предсказанное отношение шансов 
из бинарной логистической регрессии меняется на константу при изменении баланса классов, и этот эффект уходит в свободный член 
.
В деревьях решений (и их обобщениях – случайном лесе и градиентном бустинге), дисбаланс классов влияет на меры неоднородности (impurity) листьев, но это влияние примерно пропорционально для всех кандидатов в очередную разбивку (split), и потому обычно не особо влияет на выбор разбивок.
С другой стороны, на не-вероятностные модели типа SVM дисбаланс классов может серьёзно влиять. SVM строит обучающую гиперплоскость так, что примерно одно и то же число положительных и отрицательных примеров находится на разделяющей полосе или на неправильной её стороне. Поэтому изменение баланса классов может повлиять это число, а значит, и на положение границы.
Когда мы используем вероятностные модели для бинарной классификации, всё ОК: во время обучения, модели не сильно зависят от баланса классов, а при тестировании мы можем использовать метрики, нечувствительные к балансу классов. Такие метрики (например, ROC AUC) зависят от предсказанных вероятностей классов, а не от «жёсткой» дискретной классификации.
Однако метрики типа ROC AUC не очень хорошо обобщаются для многоклассовой классификации, и мы обычно используем простую точность (accuracy) для оценки многоклассовых моделей. Точность имеет известные проблемы с дисбалансом классов: она основана на «жёсткой» классификации, и может полностью игнорировать редкие классы. Именно здесь многие практики обращаются к сэмплированию. Однако, если оставаться верным вероятностным предсказаниям, и использовать правдоподобие (оно же кросс-энтропия) для оценки качества модели, дисбаланс классов можно пережить и без сэмплирования.
Сэмплирование имеет смысл, если вам не нужна вероятностная классификация. В этом случае, истинное распределение классов для вас просто нерелевантно, и его можно искажать, как угодно. Представьте задачу, где вам не нужно знать вероятность того, что на картинке перед вами кошка, а только то, что эта картинка больше похожа на картинку с кошкой, чем на картинку с собакой. В такой постановке, для вас может быть желательно, чтобы кошки и собаки имели одинаковое число «голосов», даже если в обучающей выборке коты составляли подавляющее большинство.
В других задачах (типа выявления мошенничества, предсказания кликов, или моего любимого кредитного скоринга), на самом деле вам нужна не «жёсткая» классификация, а ранжирование: какие клиенты более склонны к мошенничеству, клику или дефолту, чем другие? В этом случае, баланс классов вообще не важен, поскольку пороги для принятия решений всё равно обычно выбираются вручную – исходя из экономических соображений типа ожидаемых потерь.
Впрочем, в таких задачах часто полезно предсказывать «истинную» вероятность мошенничества (или клика, или дефолта), и в этом случае сэмплирование, искажающее эти вероятности, нежелательно. Именно так строятся, например, модели вероятности дефолта для кредитного скоринга — на несбалансированных данных строится градиентный бустинг или нейронка, и потом ещё долго проверяется, что предсказанные вероятности дефолта в среднем совпадают с фактическими в различных разрезах.
Поэтому трижды подумайте, прежде чем переживать из-за дисбаланса классов и пытаться его «починить» — может быть, драгоценное время лучше потратить на feature engineering, подбор параметров, и другие не менее важные этапы вашего анализа данных.
