Precision, recall и F1: как понять метрики классификации

Почему три почти одинаковых числа на самом деле отвечают на три разных вопроса

Когда человек впервые сталкивается с precision, recall и F1, он обычно видит три похожих метрики и пытается запомнить их как таблицу определений. Из-за этого смысл быстро теряется. На практике эти три числа полезнее читать как три разных угла зрения на одну и ту же классификацию. Precision отвечает за чистоту срабатываний модели. Recall отвечает за полноту нахождения нужного класса. F1 пытается собрать оба измерения в одно число, когда нужно контролировать баланс.

Если смотреть на них не как на термины, а как на последствия решений, все становится проще. Представь антифрод: лишняя блокировка раздражает клиента, но пропущенная мошенническая операция стоит денег. Или медицину: ложная тревога неприятна, но пропустить реальный случай опасно. В каждом из этих сценариев разные ошибки имеют разную цену, а значит и метрики становятся не просто математикой, а частью стратегии.

Где precision важнее recall, а где наоборот

Precision критичен там, где дорого ошибочно говорить «да». Например, если модель отправляет дорогой ручной аудит или автоматически блокирует действия пользователя. Низкий precision означает, что среди всех положительных срабатываний слишком много ложных. Recall важнее там, где критично ничего не пропустить. Это часто задачи риска, безопасности, медицины, поиска редких событий. Если recall низкий, значит модель упускает значительную долю того, что действительно нужно было найти.

Отсюда видно, почему нельзя выбрать одну метрику «на все случаи». Вопрос всегда в цене ошибки. Хорошая практика — сначала проговорить бизнесовую цену false positive и false negative, а уже потом смотреть на набор метрик.

Почему F1 удобна, но не универсальна

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

Как смотреть на эти метрики в реальной работе

Практически всегда полезно смотреть на метрики вместе и рядом с матрицей ошибок. Если precision высокий, а recall низкий, модель осторожна и пропускает часть позитивных случаев. Если recall высокий, а precision низкий, модель агрессивна и часто ошибается. Если обе метрики средние, возможно, проблема вообще не в пороге, а в признаках или в постановке задачи. То есть цифры — это не финал, а вход в диагностику поведения модели.

from sklearn.metrics import precision_score  # считаем точность положительных срабатываний
from sklearn.metrics import recall_score  # измеряем полноту найденных положительных объектов
from sklearn.metrics import f1_score  # получаем сводный баланс между двумя метриками
from sklearn.metrics import confusion_matrix  # смотрим матрицу ошибок для интерпретации

y_true = [1, 0, 1, 1, 0, 0, 1, 0]  # реальные классы объектов
y_pred = [1, 0, 1, 0, 0, 1, 1, 0]  # ответы модели после выбранного порога

print('precision', round(precision_score(y_true, y_pred), 3))  # проверяем чистоту положительных сигналов
print('recall', round(recall_score(y_true, y_pred), 3))  # смотрим, сколько positives модель не упустила
print('f1', round(f1_score(y_true, y_pred), 3))  # получаем общий баланс precision и recall
print(confusion_matrix(y_true, y_pred))  # читаем структуру ошибок напрямую по матрице

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