Что хотят услышать интервьюеры:

Нужно тестировать систему на данных, максимально близких к продакшену, а не только на офлайн-датасете. Обычно это делают через shadow mode, canary, A/B-тесты и мониторинг качества по бизнес-метрикам и техническим метрикам. Важно уметь контролировать риски: безопасность, задержки, дрейф данных и влияние на пользователей.

Определение:

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

Обычно сравнивают несколько режимов:

офлайн-оценку на исторических данных;
shadow mode, где модель получает реальный трафик, но не влияет на ответ пользователю;
canary release, когда новую версию получают только часть трафика;
A/B-тест, когда сравнивают две версии по метрикам качества и продуктовым метрикам.

Пример использования:

Допустим, есть система идентификации пользователя по устройству и поведению. Новую версию модели сначала запускают в shadow mode: она обрабатывает весь входящий трафик, но решения старой системы остаются в проде. Затем часть трафика переводят на новую модель в canary, например 5%, и сравнивают:

точность идентификации;
false positive / false negative;
задержку ответа;
долю ручных разборов;
бизнес-метрики, например конверсию или количество блокировок.

# Псевдокод: сравнение старой и новой модели на live-трафике
for event in stream:
    pred_old = old_model.predict(event)

    # shadow mode: новая модель считает прогноз, но не влияет на пользователя
    pred_new = new_model.predict(event)

    log({
        "user_id": event.user_id,
        "pred_old": pred_old,
        "pred_new": pred_new,
        "features": event.features,
        "label": event.true_label if event.has_label else None
    })

# Позже по логам считаем качество:
# - precision/recall
# - latency p95/p99
# - drift
# - impact on business metrics

Пояснение кода:

Код показывает типичный подход к тестированию без риска для пользователей.

Поток событий поступает в обе модели.
Старая модель продолжает определять поведение системы в проде.
Новая модель работает в shadow mode и только пишет свои предсказания в лог.
В лог сохраняются прогнозы, признаки и, если они доступны, истинные метки.
Потом офлайн анализируют записи и сравнивают версии по качеству и задержкам.
Если новая версия стабильна, её можно постепенно включать на небольшой процент трафика.

Если код не нужен, сам процесс можно разложить как: сначала безопасный прогон на реальном потоке, затем сравнение логов, потом ограниченный rollout, затем полноценный запуск.

Ключевые моменты:

Реальный трафик нужен, чтобы увидеть поведение системы на данных, которые не покрывает офлайн-выборка.
Самый безопасный старт — shadow mode, потому что он не влияет на пользователей.
Для продакшен-проверки важны не только ML-метрики, но и latency, стабильность, стоимость и бизнес-эффект.
Нужны механизмы контроля рисков: canary, rollback, лимиты по трафику и мониторинг деградации.
Для систем идентификации особенно важно отслеживать false positive, false negative и качество на сегментах пользователей.
Без корректной разметки и логирования реальный трафик не даст полезной оценки качества.

Как тестировать систему идентификации в реальном трафике?