Точность и полнота кажутся школьной теорией ровно до тех пор, пока не приходится выбирать между ложной тревогой и опасным пропуском.
Глава переводит разговор о метриках из формул в рабочие решения: где ставить порог, когда подключать ручную проверку и как цена ошибки меняет архитектуру процесса.
Это хороший фундамент для антифрода, модерации, медицинского скрининга и любых систем, где важна не абстрактная оценка модели, а последствия её решений.
Практическая польза главы
Интуиция метрик
Понять разницу между ложной тревогой и опасным пропуском без тяжёлой математики.
Язык порогов
Связать выбор порога с ручной проверкой, поддержкой и правилами продукта.
Чёткий ответ
Коротко и убедительно объяснять на интервью, почему одной метрики почти никогда не хватает.
База для кейсов
Подготовить фундамент для антифрода, модерации, ранжирования и других прикладных ML-сценариев.
Источник
Разбор точности и полноты на простом примере
Короткий исходный пост, из которого выросла эта глава.
и отвечают на разные вопросы, и путать их дорого. Точность показывает, насколько можно доверять положительным срабатываниям модели; полнота — какую долю реальных положительных случаев она вообще находит. Пока порог не выбран, обе цифры абстрактны. Стоит его зафиксировать — и разговор сразу превращается в компромисс: каждый шаг к меньшему числу пропусков оплачивается ростом ложных тревог.
Формулы на простом языке
Точность
Из всех объектов, которые модель посчитала положительными, сколько действительно оказались положительными.
Precision = TP / (TP + FP)
Полнота
Из всех реально положительных случаев сколько модель действительно смогла найти.
Recall = TP / (TP + FN)
Когда нужен один общий ориентир, часто смотрят на . Удобно, но опасно: одна цифра прячет вопрос о том, какой тип ошибки для продукта дороже, а именно с него и стоит начинать.
Мини-словарик
Точность
Доля корректных положительных срабатываний среди всех случаев, которые модель пометила как положительные.
Полнота
Доля реальных положительных случаев, которые модель действительно смогла найти.
F1-мера
Один общий показатель, который объединяет точность и полноту через гармоническое среднее.
Ложноположительное срабатывание
Модель сработала как будто случай положительный, хотя на самом деле он отрицательный.
Ложноотрицательный результат
Положительный случай был, но модель его не заметила.
Истинно положительное срабатывание
Модель правильно нашла реальный положительный случай.
Истинно отрицательное срабатывание
Модель правильно оставила отрицательный случай отрицательным.
Интерактивный пример: Вася, овцы и волк
Вася решает, когда кричать «волк». В этой игрушечной выборке сто наблюдений, но волк действительно приходит лишь десять раз — положительный класс редкий. Низкий порог реже пропускает опасность ценой потока ложных тревог; высокий порог глушит тревоги, но всё чаще пропускает волка. Бесплатной середины тут нет — её приходится выбирать.
Вася держит рабочий баланс между лишней паникой и опасным пропуском волка.
Ниже показаны четыре исхода классификации: , , и .
TP
6
Вася поднял тревогу, и волк действительно пришёл.
FP
11
Ложная тревога: Вася крикнул «волк», хотя волка не было.
FN
4
Волк пришёл, но Вася промолчал.
TN
79
Вася молчал, и опасности действительно не было.
Метрики при текущем пороге
Порог в рабочей системе: пошагово
Шаг 1. Оцени цену двух ошибок
Разложи ложные тревоги и пропуски на деньги, нагрузку на поддержку, ручные проверки и репутационные риски.
Шаг 2. Зафиксируй рабочую цель
Например: доля пропусков не выше 5% при доле ложных срабатываний не выше 15%. Так метрики связываются с требованиями продукта.
Шаг 3. Проверяй качество по сегментам
Сравнивай метрики по типам клиентов, языкам, странам и периодам, чтобы локальная деградация не пряталась за средней цифрой.
Шаг 4. Пересматривай порог на свежих данных
Рабочий порог редко живёт вечно: после релиза его нужно пересчитывать на новых данных, а не только на train/test-выборках.
После релиза полезно следить за : смена данных или поведения пользователей быстро делает вчерашний порог неактуальным.
Когда пары метрик уже недостаточно
Если одной рабочей точки мало, полезно смотреть на всю кривую. показывает, насколько хорошо модель отделяет положительные случаи от отрицательных по всему диапазону порогов; ROC здесь расшифровывается как Receiver Operating Characteristic. особенно полезна, когда положительный класс редкий: она быстрее показывает цену ложных тревог на фоне девяноста спокойных наблюдений.
ROC-кривая
Ось X показывает долю ложных тревог, ось Y — долю найденных волков по всем порогам.
Текущий порог 50%: доля ложных тревог 12.2%, полнота 60.0%.
Площадь под ROC-кривой полезна как мера общей разделимости, но при редком волке может выглядеть оптимистичнее, чем это ощущается в продукте.
PR-кривая
Ось X показывает полноту, а ось Y — сколько из поднятых тревог действительно ведут к волку.
Текущий порог 50%: полнота 60.0%, точность 35.3%.
Базовый уровень точности здесь всего 10.0%: волк приходит лишь в 10 случаях из 100. Поэтому площадь под PR-кривой лучше показывает, есть ли у модели реальная ценность поверх случайного угадывания.
ROC AUC
Когда: нужно понять, отделяет ли модель волка от обычного шума по всему диапазону порогов, до выбора рабочей точки.
Даёт общую картину разделимости, даже если рабочий порог вы потом выберете отдельно.
PR AUC
Когда: положительный класс редкий, как здесь: волк приходит только в 10 случаях из 100.
Сильнее наказывает модель за лишние тревоги и лучше показывает реальную пользу при дисбалансе.
F-бета-мера
Когда: пропуск положительного случая обходится дороже лишней тревоги и это нужно зашить прямо в метрику.
Позволяет осознанно усилить вклад полноты через параметр beta.
Калибровка вероятностей
Когда: продуктовое действие зависит не от факта срабатывания, а от самой величины вероятности.
Помогает сделать вероятности ближе к реальности и стабильнее выбирать пороги.
Оранжевая точка на обоих графиках показывает текущий порог со слайдера. Сами площадь под ROC-кривой и площадь под PR-кривой при этом не меняются: это интегральные метрики по всему диапазону порогов, а не оценка одной выбранной точки.
Когда цена пропуска выше цены ложной тревоги, берите с beta > 1 — так метрика сама начинает ценить полноту дороже. А там, где действиями продукта управляют сами вероятности, отдельно следите за : без неё порог поплывёт вслед за смещением вероятностей.
Где какая метрика важнее
Ассистент для ревью кода
Точность: Высокая | Полнота: Средняя
Если система слишком часто ошибочно сигналит, команда быстро перестаёт ей доверять.
Медицинский скрининг
Точность: Средняя | Полнота: Очень высокая
Цена пропуска болезни обычно заметно выше цены лишней проверки.
Антифрод в платежах
Точность: Высокая | Полнота: Высокая
Нужно одновременно сдерживать ложные блокировки и не пропускать мошеннические операции.
Практические рекомендации
Сначала оцени цену ложной тревоги и цену пропуска, а уже потом выбирай рабочий порог.
Смотри на точность и полноту вместе с матрицей ошибок, а не как на две отдельные цифры.
Проверяй качество по сегментам, чтобы среднее значение не скрывало локальную деградацию.
При редком положительном классе добавляй площадь под PR-кривой к рабочему порогу, чтобы не переоценить качество из-за красивой ROC-кривой.
Типичные ошибки
Считать, что сама по себе достаточно описывает качество при сильном дисбалансе классов.
Сравнивать модели по одной метрике, не связывая её с ценой ошибок и матрицей исходов.
Один раз выставить порог и больше не возвращаться к нему после изменения данных, трафика или продукта.
Делать выводы только по площади под ROC-кривой и не проверять площадь под PR-кривой там, где редкий положительный класс и важна цена ложных тревог.
Связанные главы
- AI Engineering (short summary) - показывает, как оценка качества модели связывается с продуктовой ценностью и проверкой в реальных сценариях.
- AI Engineering Interviews (short summary) - собирает типовые вопросы про метрики, цену ошибок и аргументацию качества на интервью.
- Machine Learning System Design (short summary) - расширяет тему до системного уровня: метрики, ошибки модели, данные и жизненный цикл ML-систем.
- ML-платформа в Т-Банке - переносит вопрос качества моделей на уровень платформы: как продуктовым командам помогают держать метрики под контролем в большой компании.