Инструменты для автоматического тестирования качества детекции на разных моделях камер — чек‑лист и аудит

1. Цель проверки: что именно мы должны получить на выходе

Главная цель аудита — определить объективное качество детекции в реальных условиях для каждой модели камеры и получить список приоритетных доработок. Это значит: собирать воспроизводимые метрики, фиксировать условия съёмки и отличия в аппаратной части, и формировать план исправлений с оценкой влияния на бизнес‑цель.

Проверка не должна ограничиваться «показывает/не показывает». Мы измеряем падающую точность в разных условиях (освещение, угол обзора, удаление объекта), стабильность метрик между камерами одной модели и различиями между моделями. Результатом становится сводка: текущие проблемы, их причина и приоритет исправления.

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

2. Зоны аудита, которые обязательно покрыть

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

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

Зоны, связанные с ПО: предобработка (освещённость, баланс белого), параметры инференса (пакетирование, прерывание), постобработка (NMS, трекинг), и логирование. Каждая из этих зон должна иметь набор проверок и ожидаемых результатов, чтобы локализовать проблему.

• Аппаратные параметры камеры
• Качество и параметры видеопотока
• Модель и конфигурация инференса
• Пару‑строчные проверки постобработки и трекинга
• Механизмы логирования и сбора метрик

3. Критерии качества по каждой зоне: что измерять и почему

Для аппаратной зоны измеряем совпадение разрешения, битрейта и FPS с эталоном, устойчивость автоэкспозиции и частоту смены настроек. Эти критерии объясняют, почему одна и та же модель детектора даёт разный результат на разных камерах: отличия в яркости или подавлении шума искажают признаки.

Для видеопотока и предобработки фиксируем уровень шума (SNR), динамический диапазон, артефакты компрессии и частоту ключевых кадров. Эти параметры влияют на распознавание мелких объектов и на стабильность детекции при движении.

Для модели и инференса критерии — latency, FPS на устройстве, стабильность порогов детектора, доля пропущенных объектов и ложных срабатываний по классам. Для постобработки — адекватность NMS, тотальные пропуски при наложении объектов, и корректность трекинга при пересечении путей.

• Аппаратная повторяемость параметров
• SNR и артефакты сжатия
• Latency и стабильность инференса
• Классовая точность и ложные срабатывания
• Корректность NMS и трекинга

4. Тестовые сценарии и набор камер: как сформировать репрезентативный сэмпл

Набор камер должен покрывать реальные модели, которые используются в проекте, с разными характеристиками: низкое/высокое разрешение, разные профильные объективы, вариации компрессии и различные прошивки. Для каждой модели описываем сценарии съёмки: дневной, ночной, контровой свет, дождь/влажность, движение камеры (ветром).

Тестовые сценарии включают статические сцены и динамические: разные удалённости объектов, пересечение групп людей, появление мелких объектов, заход/уход объектов, частые пересечения. Для каждого сценария готовим эталонную разметку (ground truth) и правила подсчёта метрик.

Важно включать edge‑кейсы: сильные бликовые источники, пересвет, ночной шум, частая смена экспозиции и сильная компрессия. Эти ситуации дают большую долю проблем в боевых системах и часто не проявляются в лабораторных данных.

• Список моделей камер с их параметрами
• Перечень сценариев съёмки и погодных условий
• Разметка ground truth для каждого сценария
• Edge‑кейсы (блики, пересвет, сильная компрессия)

5. Настройка автоматического теста и инфраструктура

Автоматизация теста состоит из трёх слоёв: сбор данных (capture), обработка и инференс, агрегирование результатов и отчётность. На уровне capture автоматизировано собираются куски видео с метками условий съёмки и метаданными камеры. Желательно сохранить оригинал и версию с реальной компрессией.

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

Агрегатор собирает детекшены и сравнивает их с эталоном, рассчитывает метрики и формирует дашборды. Логи и сырые данные хранятся так, чтобы можно было воспроизвести конкретный этап. Рекомендуется запуск тестов по расписанию и при изменении модели или конфигураций камер.

• Pipeline: capture → preprocess → inference → aggregator
• Версионирование моделей и конфигураций
• Хранение оригинальных видеопотоков и логов
• Автозапуск тестов и триггеры по изменению

6. Метрики: что считать, как интерпретировать и сравнивать

Набор метрик должен включать точность (precision), полноту (recall), F1 по классам, средняя точность (mAP) с IoU порогами, latency инференса и стабильность результатов между запусками. Метрики нужно считать по кадрам и по событиям (например, появление/исчезновение объекта).

Интерпретация метрик зависит от задачи: для охраны важнее минимизировать false negatives, для аналитики трафика — точность размеров и класса. Сравнение между моделями камер делаем по нормализованным условиям: те же сценарии и одинаковая конфигурация обработки.

Таблица с примерами порогов полезна как отправная точка для обсуждения, но пороги следует адаптировать под проект. Для принятия решения важно смотреть не только среднее значение метрик, но и распределение по сценарию и классам объектов.

Таблица: ключевые метрики и примерные пороговые значения

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

7. Критичные ошибки, которые чаще всего портят результаты

Неправильная нормализация или масштабирование изображения — частая причина, когда модель «не видит» объекты на конкретных камерах. Это случается при автоматическом ресайзе, при котором меняется соотношение сторон или происходит сдвиг контраста.

Игнорирование компрессии и артефактов кодека приводит к резкому падению точности: модель обучена на более чистых кадрах и не справляется с блоковыми артефактами или отсутствием ключевых кадров. Часто это проявляется только на реальном оборудовании.

Отсутствие версионирования конфигураций инференса и параметров NMS приводит к тому, что при изменении параметров результат меняется непредсказуемо. Ещё одна критичная ошибка — отсутствие мониторинга дельты метрик между релизами модели.

• Неправильный ресайз и нормализация
• Игнорирование компрессии и пропуск кадров
• Неслежение за версионированием конфигураций
• Отсутствие логирования и возможности воспроизвести ошибку

8. Приоритизация: как выбрать первые шаги по исправлению

Приоритизация делается по трём параметрам: влияние на бизнес‑метрику, вероятность исправления и трудозатраты. Сначала решаем крупные проблемы с высоким влиянием и низкой стоимостью исправления — например, корректировка предобработки или смена конфигурации NMS.

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

В результате получаем backlog с приоритетами: срочные исправления (оперативные), среднесрочные (оптимизация и переобучение) и долгосрочные (смена аппаратуры или архитектуры). Для каждой задачи указываем метрику, которую она должна улучшить.

• Критерии приоритизации: влияние / вероятность / трудозатраты
• Срочные правки: предобработка, NMS, фиксы логики
• Среднесрочные: дообучение модели, оптимизация инференса
• Долгосрочные: смена камер, архитектурные изменения

9. Итоговый чек‑лист запуска аудита (конкретные проверки)

Чек‑лист — набор конкретных действий, которые можно выполнить и зафиксировать. Он включает: подготовка списка моделей камер, сбор видеопотоков по сценариям, разметка эталона, настройка конвейера, запуск прогонов, сбор метрик и анализ дельт. Каждое действие должно иметь ответственного и артефакт (лог, отчёт).

Приведённый ниже чек‑лист служит шаблоном для запуска: от подготовки до приоритизации задач. После первого прогона важно провести ретроспективу и адаптировать чек‑лист под специфику проекта — добавить специфичные сценарии и пороги.

Чек‑лист оформляется в виде трекера задач и дашборда метрик. Рекомендуется автоматизировать сбор результатов и уведомления об отклонениях для оперативного реагирования.

• Составить перечень камер и их конфигураций
• Собрать видеопотоки по заранее описанным сценариям
• Подготовить и проверить разметку ground truth
• Запустить унифицированный pipeline и зафиксировать конфигурации
• Собрать precision/recall/mAP/latency по всем сценариям
• Проанализировать результаты и составить backlog исправлений

Частые вопросы