Каково было соотношение классов в данных?

Что проверяют

Работали ли вы с настоящими данными или собирали модели на учебных наборах, где классы поровну. Вопрос почти всегда часть цепочки про ваш проект, и следом спрашивают, что вы с перекосом сделали, как выбирали метрику и порог. Заодно проверяют, помните ли вы цифры своего проекта.

Как отвечать

Начните с конкретики: назовите реальное соотношение своего проекта, например 1 к 40 или 2,5% целевого класса, и скажите, на какой выборке считали. Дальше разверните каркас:

• как измеряли: доля класса на обучении, на отложенной части и отдельно в проде, менялась ли она со временем;
• как делили выборку: стратифицированное разбиение, а для задач с временной структурой разбиение по времени, иначе редкий класс расползается между фолдами и валидация врёт;
• метрики: accuracy при таком перекосе бесполезна, информативнее PR-AUC и пара precision и recall в рабочей точке, а ROC-AUC на сильном дисбалансе выглядит оптимистично;
• что делали: веса классов (class_weight="balanced", scale_pos_weight в XGBoost), подбор порога по валидации под нужную полноту, focal loss, реже пересэмплирование;
• о чём помнили: SMOTE и андерсэмплинг меняют априорное распределение и ломают калибровку вероятностей, применять их можно только к обучающей части внутри фолда;
• бизнес-сторона: цена пропуска против цены ложной тревоги, именно она задаёт рабочую точку.

Ответ нужен из своего опыта, а не по шаблону: назовите, что попробовали и что не сработало. Признание «пересэмплирование дало плюс к метрике, но не улучшило поведение на проде, и мы вернулись к весам и порогу» звучит сильнее гладкого рассказа.

Где спотыкаются

Отвечают «данные были несбалансированные» без единой цифры. Такой ответ не отличить от отсутствия опыта.

Сразу называют SMOTE как универсальное решение и применяют его до разделения выборки. Получается утечка, отличная валидация и провал на проде.

Хвалятся точностью 97% там, где целевой класс занимает 3%. Модель, всегда отвечающая «нет», даёт столько же.