Как тестировать систему идентификации в реальном трафике
Что проверяют
Умеете ли вы оценивать модель там, где нет готовой разметки, а ошибка стоит денег или доступа пользователя. Интервьюер ждёт shadow-режим, работу с запаздывающими метками и понимание двух типов ошибок. Уточняют обычно так: «Где вы возьмёте ground truth в проде?»
Как отвечать
Начните с того, что считается ошибкой. У системы идентификации их две: ложный допуск (FAR, чужого приняли за своего) и ложный отказ (FRR, своего не узнали). Порог двигает их в разные стороны, поэтому качество описывают парой или кривой: TAR при фиксированном FAR, DET-кривая, EER. Бизнес выбирает рабочую точку, например FAR не выше 0,1%, и дальше вы следите за FRR.
Этапы выхода в реальный трафик:
- shadow mode: новая модель получает копию запросов, считает ответ и пишет в лог, но решений не принимает. Сравниваете с текущей системой и разбираете расхождения;
- канарейка: малая доля трафика с автоматическим откатом по guardrail-метрикам (доля отказов, обращения в поддержку, латентность p99);
- A/B: только если ложный допуск не критичен, иначе группа с худшей моделью становится дырой в защите.
Ground truth приходит с задержкой: чарджбэки, жалобы, повторные попытки, ручная разметка. Отправляйте на разметку стратифицированную выборку, включая скоры около порога, иначе увидите только очевидные случаи.
Отдельно мониторинг: дрейф признаков (PSI, сдвиг распределения скоров), метрики по сегментам (платформа, регион, новые пользователи), латентность в пиковые часы.
Где спотыкаются
Отвечают про нагрузочное тестирование в JMeter или Locust. Это проверка производительности сервиса, а не качества идентификации на живых данных.
Считают accuracy на несбалансированных данных. При доле мошенников 0,5% модель, которая пропускает всех, покажет 99,5%.
Смотрят только общую метрику. Средний FRR в норме, а в одном сегменте, например на старых Android-устройствах, отказы выросли в разы, и эти пользователи просто уходят.