Проблема: «Слепая зона» в гатах приемки
Анализ десяти популярных руководств по квантованию (включая EdgeGate и oneuptime) выявил системную ошибку: все они используют для принятия решения о выпуске сборки метрики, не зависящие от порога принятия решения (threshold). Стандартная формула — «INT8 accuracy ≥ FP32 accuracy − 1%» — игнорирует тот факт, что квантование меняет распределение скоростей (embeddings), а не только их ранжирование.
Если модель проходит по Top-1 или Precision@10, инженеры считают её годной. Однако эти метрики «порог-независимы» (threshold-free). Они показывают, кто вернулся первым, но не то, насколько изменилась уверенность модели в этом выборе. В результате сборка с деградировавшей кривой ошибок (DET) может быть одобрена, хотя реальные показатели безопасности упали.
Доказательство: Эксперимент с ArcFace и Hailo
Автор провел аудит на задаче верификации лиц с использованием предобученного энкодера ArcFace, квантованного до int8 через инструментальный набор Hailo. Сравнение проводилось на отложенной выборке (held-out test set) с использованием фиксированного порога, полученного на fp32-модели.
На первый взгляд, падение точности минимально:
| Метрика | FP32 (Baseline) | INT8 (Quantized) | Изменение |
|---|---|---|---|
| Precision@10 | 0.978 | 0.972 | -0.006 |
| Rank-1 | 0.990 | 0.985 | -0.005 |
Стандартный гат пропустил бы эту модель. Однако при использовании того же числового порога, что и для fp32, произошли критические изменения в ошибках:
- False Accept Rate (FAR): вырос с 30 до 104 ложных срабатываний на 10 000 пар (интерпостеров). Это рост в 3.5 раза (дельта +0.0074).
- False Reject Rate (FRR): вырос с 582 до 745 ложных отказов на 10 000 пар (подлинных пользователей).
Важно отметить: это не просто сдвиг рабочей точки вдоль одной кривой. Кривые DET (Detection Error Tradeoff) для fp32 и int8 не совпадают. Ни один порог на кривой int8 не позволяет достичь того же уровня FAR/FRR, что и на fp32. Модель стала объективно «менее различимой».
Почему это важно для индустрии
Проблема усугубляется тем, что в индустрии биометрии и RAG-систем порог (threshold) часто является константой в конфигурационном файле, которая не пересчитывается при каждом новом билде. Если гат приемки не проверяет FAR/FRR при фиксированном пороге, компания рискует выпустить продукт с непредсказуемо высоким уровнем ложных срабатываний.
Стандарт NIST FRVT Part 3 (NISTIR 8280) прямо указывает, что отчетность «при фиксированных ложноположительных ошибках» скрывает excursions (скачки) в реальных показателях. Для продакшена же важна не метрика при идеальном пороге, а поведение при жестко заданном пороге.
Решение: Два новых числа
Автор предлагает не отказываться от текущих метрик, а дополнить их двумя простыми измерениями, которые занимают всего один день работы:
- Зафиксировать порог (threshold), полученный на fp32-модели.
- Измерить FAR и FRR на отложенной выборке для int8-модели при этом фиксированном пороге.
Только так можно увидеть, не «развалилась» ли кривая решений модели после квантования. Отсутствие этих метрик в чеклистах — не оплошность, а структурный пробел, который легко закрыть, но который пока стоит компаниям реальных инцидентов безопасности.
Источник: Towards Data Science ↗