Точность и полнота кажутся школьной теорией ровно до тех пор, пока не приходится выбирать между ложной тревогой и опасным пропуском.
Глава переводит разговор о метриках из формул в рабочие решения: где ставить порог, когда подключать ручную проверку и как цена ошибки меняет архитектуру процесса.
Это хороший фундамент для антифрода, модерации, медицинского скрининга и любых систем, где важна не абстрактная оценка модели, а последствия её решений.
Практическая польза главы
Интуиция метрик
Понять разницу между ложной тревогой и опасным пропуском без тяжёлой математики.
Язык порогов
Связать выбор порога с ручной проверкой, поддержкой и правилами продукта.
Чёткий ответ
Коротко и убедительно объяснять на интервью, почему одной метрики почти никогда не хватает.
База для кейсов
Подготовить фундамент для антифрода, модерации, ранжирования и других прикладных 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-платформа в Т-Банке - показывает, как платформенная команда помогает командам работать с качеством моделей в большой компании.