Почему нельзя усреднить F1 по дням: пересчитываем метрику из ошибок

Дашборд показывает F1 классификатора за каждый день. Для недельного итога аналитик берёт среднее семи значений. График выглядит правдоподобно, но итог может сильно расходиться с F1, посчитанным по всем заявкам недели. Даже взвешивание дневных значений числом заявок не решает проблему в общем случае.

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

Какие числа следует хранить

Рассмотрим бинарную классификацию, где положительный класс означает заявку с нарушением. TP — нарушение найдено правильно. FP — обычная заявка ошибочно отправлена на проверку. FN — нарушение пропущено. Для такого отчёта F1 считается как 2 * TP / (2 * TP + FP + FN).

Число верно отклонённых обычных заявок в эту формулу не входит. Это уже объясняет, почему размер дня сам по себе не является правильным весом. Два дня с одинаковым потоком могут содержать разное число положительных случаев и давать совершенно разную цену ошибок.

Пример, где среднее особенно обманчиво

days = [
    {'tp': 1, 'fp': 0, 'fn': 0},
    {'tp': 0, 'fp': 0, 'fn': 99},
]

def f1(counts):
    denominator = 2 * counts['tp'] + counts['fp'] + counts['fn']
    return 2 * counts['tp'] / denominator if denominator else 0.0

daily_mean = sum(f1(day) for day in days) / len(days)
totals = {key: sum(day[key] for day in days) for key in ('tp', 'fp', 'fn')}
pooled = f1(totals)
print(round(daily_mean, 4), round(pooled, 4))
assert daily_mean == 0.5
assert round(pooled, 4) == 0.0198

В первый день модель нашла единственное нарушение и получила F1 = 1. Во второй пропустила 99 нарушений и получила ноль. Среднее дневных F1 равно 0,5, хотя за весь поток найдена только одна из ста положительных заявок. Общая метрика — примерно 0,0198.

Это не означает, что дневной график бесполезен. Он помогает найти момент поломки. Просто «среднее качество дня» и «качество на всех заявках периода» — разные показатели. Если бизнес действительно хочет давать каждому дню одинаковый вес, подпишите это правило отдельно.

Что делать с днями без положительного класса

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

При суммировании TP, FP и FN такой день ничего не добавит к общему знаменателю. Поэтому сохранять исходные количества особенно полезно: итог можно пересчитать по согласованному правилу, не пытаясь восстановить данные из округлённых процентов.

Для многоклассовой модели потребуется таблица таких количеств по каждому классу. Усреднение по классам и объединение по дням — разные операции. В отчёте должно быть понятно, считается ли общий micro-показатель или macro-среднее классов. Не смешивайте их только потому, что обе колонки называются F1.

Как проверить готовый дашборд

Выгрузите решения за два дня и сравните три расчёта: F1 каждого дня, среднее этих значений и F1 на объединённых строках. Последний должен совпасть с расчётом из суммарных TP, FP и FN. Сопоставляйте одни и те же версии модели, пороги и правила разметки, иначе общий результат описывает смесь разных процессов.

Рядом с F1 оставьте precision, recall и размеры потока. По одной метрике трудно понять, выросла очередь лишних проверок или увеличилось число пропущенных нарушений.

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