Triage для контроля качества вместо обычной классификации

Я взял промышленный датасет по дефектам стальных пластин (7 типов дефектов) и решил задачу не как угадай класс, а как управление риском при ограниченном ресурсе QC

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

- проверять всё дорого/невозможно, - но пропуск критичных дефектов стоит ещё дороже.

Поэтому правильный вопрос звучит так:

> кого отправить на дополнительную проверку, если мы можем проверить только top-K% изделий?

Решение (decision-first)

1. Обучаю multiclass модель (CatBoost) на 7 типов дефектов. 2. Определяю “критичные” как сценарий: царапины (K_Scatch + Z_Scratch). 3. Строю риск для очереди QC: risk = P(K_Scatch) + P(Z_Scratch) 4. QC проверяет top-K% по risk.

Что получилось

На тесте доля критичных ≈ 29.8%. Triage даёт устойчивый lift относительно случайного отбора:

* K=5% → ловлю ~17% критичных (lift ~3.45×) * K=10% → ловлю ~34% критичных (lift ~3.36×) * K=15% → ловлю ~50% критичных (lift ~3.33×)

Это значит: при фиксированном бюджете QC я вытягиваю критичные дефекты в начало очереди существенно лучше случайного выбора.

Улучшения

Я проверил базовые технологии улучшения, которые часто используются в triage:

- отдельную binary модель “critical vs non-critical”, - усиление весов критичных классов.

На этом датасете прироста почти нет, оставляю простое решение, потому что оно не хуже.

Сейчас важно быстро проверить гипотезу и не усложнять систему без выгоды.

Где модель реально ломается

В error analysis видно две бизнес-опасные зоны:

- часть критичных царапин уезжает в Other_Faults с очень низким risk (опасные FN), - некоторые Other_Faults попадают в top-K с высоким risk и съедают очередь QC.

Отсюда требования к внедрению: мониторинг распределений risk и контроль доли Other в top-K как сигнал дрейфа.

Если интересно: полный разбор (decision framing → policy → метрики → эксперименты → error analysis → план внедрения) у меня в Full case.