Метрики в Machine Learning: как понять качество модели

Почему разговор о модели почти всегда упирается не в алгоритм, а в метрику

Очень часто начинающий Data Scientist пытается сравнивать модели так, будто вопрос сводится к одному числу: у кого score выше, тот и победил. Но качественная работа с ML начинается раньше. Прежде чем сравнивать модели, нужно решить, что именно для нас означает хорошее качество. Ошибка одинаково ли дорогая во всех случаях? Нас больше волнует, чтобы модель не пропустила редкий положительный класс, или чтобы она не тревожила систему ложными срабатываниями? Без ответа на эти вопросы метрика превращается в красивую цифру без смысла.

Именно поэтому метрики нельзя учить как словарь терминов. Их нужно читать как формализацию бизнесового или исследовательского требования. Accuracy полезна, когда классы сбалансированы и ошибки примерно равны по цене. Precision важна, когда дорого ошибочно объявить объект положительным. Recall нужен, когда опасно пропустить настоящий положительный случай. F1 соединяет обе стороны и показывает, насколько хорошо удается держать баланс.

Почему одна и та же модель может выглядеть хорошей и плохой одновременно

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

Метрика — это язык компромисса. В нем не бывает универсально правильной цифры. Есть только правильное соответствие задаче. Поэтому опытный специалист не спрашивает «какая метрика лучше?», а спрашивает «какой тип ошибки здесь самый опасный?».

Формула, которая полезна почти каждому новичку

С математической точки зрения F1 — это гармоническое среднее. Оно сильнее наказывает перекос, чем обычное среднее. Если одна из величин провалилась, F1 тоже резко падает. В этом и смысл: модель не должна быть «удобной только наполовину».

Как думать о метриках в задачах Data Science

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

Как это выглядит в Python

from sklearn.metrics import accuracy_score  # считаем базовую долю верных ответов
from sklearn.metrics import precision_score  # измеряем точность положительных срабатываний
from sklearn.metrics import recall_score  # измеряем полноту нахождения положительного класса
from sklearn.metrics import f1_score  # считаем баланс между precision и recall

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

print('accuracy', round(accuracy_score(y_true, y_pred), 3))  # смотрим общую долю совпадений
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))  # получаем сводный баланс двух величин

Такой код полезен не потому, что его сложно написать, а потому что он заставляет увидеть расхождение между метриками. И именно это расхождение обычно и объясняет, почему одна и та же модель нравится инженеру, не нравится бизнесу и по-разному оценивается на разных порогах.