Доля брака изменилась: сколько ложных тревог даст прежняя ML-модель

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

Одна точность тревог относится к конкретному потоку

Представим контроль изделий по табличным измерениям станка. Модель решает, какие изделия передать сотруднику. Сначала измерим две величины отдельно: какую долю реальных дефектов она отправляет на проверку и какую долю годных изделий ошибочно задерживает. Первую величину называют TPR, или полнотой обнаружения дефектов, вторую — FPR, долей ложных срабатываний среди годных.

Допустим, проверка дала TPR 0,8 и FPR 0,02. Это означает, что система находит восемь дефектов из десяти и задерживает два годных изделия из ста. Из этих двух чисел ещё нельзя узнать долю настоящего брака среди задержанных. Нужна частота дефектов в производстве. Именно она определяет, сколько изделий каждого типа попадёт под соответствующее правило.

Если для тестирования специально собрали много дефектных изделий, доля брака в тесте может заметно превышать производственную. Такой набор полезен, чтобы увидеть разнообразные ошибки. Но переносить его precision в расчёт загрузки сотрудников напрямую нельзя. Удерживайте один и тот же положительный класс: в нашем случае это дефект, а сигнал модели означает дополнительную проверку.

Посчитаем очередь на десять тысяч изделий

Следующий пример использует только стандартный Python. Для каждого сценария он сначала вычисляет ожидаемое число дефектных и годных изделий, затем применяет измеренные TPR и FPR. Получаются ожидаемые количества, поэтому на других входах они могут быть дробными. Это план нагрузки, а не журнал уже обработанных изделий.

n = 10_000
tpr, fpr = 0.8, 0.02
for prevalence in (0.10, 0.01):
    bad = n * prevalence
    good = n - bad
    found = bad * tpr
    false_alarm = good * fpr
    missed = bad - found
    alerts = found + false_alarm
    precision = found / alerts if alerts else None
    print(f"defect_rate={prevalence:.0%} alerts={alerts:.0f} "
          f"true={found:.0f} false={false_alarm:.0f} "
          f"missed={missed:.0f} precision={precision:.1%}")
    assert abs(found + missed - bad) < 1e-9
    assert abs(alerts - found - false_alarm) < 1e-9

При 10% брака получится 980 тревог: 800 настоящих и 180 ложных. Precision равен 81,6%. При 1% брака тревог станет 278: 80 настоящих и 198 ложных. Теперь precision составляет 28,8%, хотя чувствительность модели и доля ложных срабатываний в расчёте совершенно одинаковы. Пропущенных дефектов соответственно 200 и 20.

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

Когда сценарий можно переносить на новую линию

Мы сохранили TPR и FPR. Это осмысленное допущение, когда изменилась преимущественно доля брака, а типы дефектов, измерительные приборы и диапазоны признаков остались сопоставимыми. При новой технологии производства модель может иначе различать даже годные и дефектные изделия. Тогда сначала нужна размеченная проверка на новой линии; подстановка новой частоты не исправляет изменившееся качество распознавания.

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

После этого можно обсуждать изменение порога. Для каждого кандидата измерьте пару TPR/FPR на валидации и повторите расчёт нагрузки. Выберите вариант, который одновременно укладывается в возможности проверки и требования к пропускам. Зафиксируйте порог до финального теста, а после запуска сравнивайте ожидания с созревшими метками и сохраняйте состав входящего потока.

Отдельно договоритесь, что считается ложной тревогой. Если сотрудник нашёл небольшой дефект, который по новым правилам больше не является браком, меняется определение целевого события. Тогда старые TPR и FPR относятся к прежней инструкции контроля. Перед сравнением периодов приведите метки к одному правилу или явно разделите версии требований к изделию. Иначе изменение политики качества будет выглядеть как поломка модели.

В эксплуатации полезно сопоставлять две оценки: долю тревог среди всех изделий можно получить немедленно, а долю брака среди них — после проверки. Если первая величина резко изменилась, откройте распределения измерений и журнал изменений линии. Если изменилась только вторая, проверьте состав дефектов и полноту разметки. Такой порядок диагностики позволяет быстрее отличить новую частоту брака от сбоя датчика или задержки результатов проверки.

В платном курсе «Табличные модели в продакшн» вы проходите подготовку данных, валидацию, обучение CatBoost/LightGBM и диагностику ошибок. Следующий полезный шаг после такого расчёта — собрать модель и отчёт метрик, с которым можно обосновать рабочий порог. Откройте программу курса и посмотрите маршрут от эксперимента до инференса.

Продолжить на практике

  • ML Engineer / Data Scientist: табличные модели в продакшн ↗

    Практический курс для тех, кто хочет получить навыки ML Engineer / Data Scientist на реальных табличных задачах. В курсе Вы не просто обучите CatBoost/LightGBM, а соберёте полноценный production-style пайплайн: подготовка данных, feature engineering (генерация признаков), корректная валидация, защита от leakage (утечек), тюнинг через Optuna, интерпретация через SHAP, batch-инференс и REST API для предсказаний.