«У модели ROC-AUC 0.95, а в проде она бесполезна» — знакомая история для всех, кто ловил фрод или отток. Причина почти всегда одна: класс, который вы ищете, очень редкий, а ROC-AUC этого будто не замечает. Разберу, почему так, и когда честнее смотреть на PR-AUC.
Что показывает ROC-AUC простыми словами?
ROC-кривая строится по двум величинам при разных порогах: доля верно пойманных положительных (recall, он же TPR) против доли ложных тревог среди отрицательных (FPR). AUC — площадь под этой кривой, число от 0 до 1.
Интуиция такая: возьмём случайный положительный пример и случайный отрицательный. ROC-AUC — это вероятность, что модель присвоит положительному больший скор, чем отрицательному. 0.5 — модель угадывает как монетка, 1.0 — идеальное разделение.
Метрика удобная: не зависит от выбранного порога и от того, какую долю занимает положительный класс. Но именно эта «независимость от доли» и создаёт ловушку.
Чем PR-AUC отличается от ROC-AUC?
PR-кривая строится в других осях: precision (какая доля из того, что модель назвала положительным, действительно положительная) против recall (какую долю всех положительных мы поймали). PR-AUC — площадь под ней.
Ключевая разница в том, что PR-AUC вообще не использует истинно-отрицательные примеры (TN) в расчёте precision. А их-то при дисбалансе подавляющее большинство. ROC-AUC через FPR = FP / (FP + TN) «разбавляет» ложные срабатывания огромным знаменателем TN и делает их визуально незаметными. PR-AUC этого разбавления не делает — precision честно падает, как только растёт число ложных тревог.
Почему при дисбалансе классов ROC-AUC вводит в заблуждение?
Возьмём антифрод: на 100 000 транзакций 100 мошеннических (0.1%). Допустим, модель на пороге ловит 90 фродов (recall 90%), но заодно помечает 2000 честных транзакций как подозрительные.
Считаем FPR: 2000 ложных из 99 900 честных — это всего 0.02. На ROC-кривой точка близко к идеалу, ROC-AUC получится высоким. А теперь precision: из 2090 помеченных транзакций реальный фрод — только 90. Precision = 90 / 2090 ≈ 4.3%. То есть 96% срабатываний модели — ложные. Служба, которая будет разбирать эти алерты, захлебнётся.
ROC-AUC показал «отлично», PR-AUC показал бы «плохо». И PR-AUC был прав: при редком классе важно не «как мало ложных тревог относительно моря отрицательных», а «как много мусора среди того, что модель реально предлагает разобрать».
Какую метрику выбрать для своей задачи?
Правило, которым пользуюсь:
- Классы примерно сбалансированы (условно от 20/80 и ровнее) — ROC-AUC нормально работает и удобен для сравнения моделей.
- Положительный класс редкий и именно он важен (фрод, отток, дефолт, редкое заболевание, клик по объявлению) — смотрите PR-AUC, он отражает реальную боль.
- Нужна одна цифра для отчёта, но класс редкий — берите PR-AUC или average precision, а ROC-AUC оставьте как второстепенный.
И главное: обе метрики агрегируют качество по всем порогам, а в проде вы работаете на одном конкретном пороге. Поэтому после выбора модели всё равно фиксируйте precision и recall на рабочем пороге — это то, что почувствует бизнес. Про то, как метрика связана с деньгами, я писал в разборе продуктовых метрик.
Как объяснить выбор метрики на собеседовании?
Интервьюер редко хочет услышать определение — он хочет увидеть, что вы понимаете контекст. Сильный ответ звучит так: «Класс редкий, поэтому accuracy бесполезен, а ROC-AUC будет оптимистично завышен из-за огромного числа истинно-отрицательных. Я смотрю на PR-AUC и на precision/recall на рабочем пороге, потому что цена ложной тревоги здесь высокая».
Дальше почти всегда идёт follow-up: «А если пропустить фрод дороже, чем побеспокоить честного клиента?» — и тут вы говорите про сдвиг порога в сторону recall и про то, что F-beta с beta > 1 взвешивает recall выше precision. Такие связки «метрика → порог → цена ошибки» ценятся куда выше, чем формула наизусть.
Потренировать подобные вопросы можно в банке вопросов для аналитика — там разборы идут именно в логике «почему», а не «что». А проверить руками, как расходятся ROC-AUC и PR-AUC на дисбалансе, удобно в Python-тренажёре на scipy и sklearn.