Precision и recall важны не как учебные формулы, а как язык, на котором продукт договаривается с моделью о цене ошибок.
Глава приземляет тему на пороги, ложные срабатывания, пропуски и сценарии, где выбор метрики напрямую меняет пользовательский опыт и операционные последствия.
На интервью она помогает быстро и понятно объяснить trade-off между типами ошибок и показать, что настройка модели всегда связана с контекстом задачи, а не с абстрактным максимумом качества.
Практическая польза главы
Практика проектирования
Переводите знания о метриках precision/recall и оценке качества ML-систем в архитектурные решения по data flow, model serving и контрольным точкам качества.
Качество решений
Оценивайте систему через метрики модели и платформы одновременно: precision/recall, latency, drift, стоимость и операционные риски.
Interview articulation
Структурируйте ответ как цепочку data -> model -> serving -> monitoring, показывая где возникают ограничения и как вы ими управляете.
Trade-off framing
Явно фиксируйте компромиссы по метриках precision/recall и оценке качества ML-систем: скорость экспериментов, качество, explainability, resource budget и сложность поддержки.
Источник
Precision и recall на пальцах
Исходный пост, на котором основана эта глава.
Precision и recall показывают разные стороны качества классификатора. Precision отвечает за качество позитивных срабатываний, recall - за полноту обнаружения. В реальных системах почти всегда приходится выбирать компромисс между этими метриками.
Формулы на простом языке
Precision (точность)
Из всего, что модель пометила как positive, сколько действительно positive.
Precision = TP / (TP + FP)
Recall (полнота)
Из всех реально positive, сколько модель смогла найти.
Recall = TP / (TP + FN)
Визуализация: Вася, овцы и волк
Вася держит баланс между ложными тревогами и пропущенными волками.
TP
17
Вася крикнул и волк реально был
FP
10
Ложная тревога: «волк», но это не волк
FN
13
Волк был, но Вася промолчал
TN
60
Тишина и волка действительно нет
Метрики при текущем пороге
Порог в продакшене: пошагово
Шаг 1. Зафиксируй цену ошибок
Переведи FP и FN в деньги, нагрузку на поддержку и репутационные риски. Без этого порог выбирается вслепую.
Шаг 2. Сформулируй операционную цель
Например: FN <= 5% при FP <= 15%. Такой контракт связывает метрики с требованиями продукта.
Шаг 3. Проверь качество по сегментам
Сравни метрики по языкам, типам клиентов и периодам, чтобы не скрыть локальную деградацию.
Шаг 4. Пересматривай порог регулярно
После релиза следи за drift и пересчитывай рабочий порог на свежих данных, а не только на train/test.
Когда precision/recall недостаточно
PR-AUC
Когда: Когда сравниваешь несколько моделей в диапазоне порогов.
Лучше отражает качество ранжирования positives при дисбалансе классов.
F-beta score
Когда: Когда FN заметно дороже FP.
Позволяет явно усилить важность recall через параметр beta.
Калибровка вероятностей
Когда: Когда confidence используется как продуктовый триггер.
Снижает резкие скачки качества после обновлений модели и данных.
Если цена пропуска выше цены ложной тревоги, используйте F-beta c beta > 1: метрика усилит вклад recall при выборе порога.
Где что важнее
Code review ассистент
Precision: Высокая | Recall: Средняя
Ложные тревоги быстро приводят к усталости и игнорированию рекомендаций.
Медицинский скрининг
Precision: Средняя | Recall: Очень высокая
Критично не пропустить реальные случаи заболевания (FN дороже FP).
Антифрод в платежах
Precision: Высокая | Recall: Высокая
Нужно балансировать: не блокировать лишние транзакции и не пропускать мошенничество.
Практические рекомендации
Всегда фиксируй цену FP и FN для конкретного продукта до выбора порога.
Показывай precision/recall вместе с confusion matrix, а не в отрыве друг от друга.
Проверяй метрики отдельно по сегментам (клиенты, типы данных, языки), чтобы не скрывать деградацию.
Для review-ассистентов чаще выгодно держать precision выше, чтобы сохранить доверие пользователей.
Типичные ошибки
Смотреть только на accuracy при сильном дисбалансе классов.
Сравнивать модели по precision без контроля recall (и наоборот).
Фиксировать порог один раз и не пересматривать его после изменения данных.
Игнорировать пользовательскую реакцию на ложные срабатывания в продакшене.
Связанные главы
- AI Engineering (short summary) - Практика evaluation и product-level валидации AI-систем.
- AI Engineering Interviews (short summary) - Частые вопросы и сценарии вокруг качества ML/AI решений.
- Machine Learning System Design (short summary) - Подробный разбор метрик, ошибок модели и lifecycle ML-систем в проде.
- ML-платформа в Т-Банке - Как метрики качества используются в платформенной практике.
- Эволюция SRE: внедрение AI-ассистента в Т-Банке - Реальный кейс, где precision/recall влияют на операционную надёжность.