Как тестировать компьютерное зрение на своём объекте, а не на демо-видео

Почему чистый демо-ролик обманывает

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

Глубже проблема “потока неизвестных классов”. В демо оператор сам выбирает объекты, поэтому всё в кадре относится к известным классам. В проде мир открыт: softmax-классификатор не умеет говорить “не знаю” — он распределяет вероятность по известным классам и выдаёт самый вероятный с той уверенностью, какую даёт геометрия. Это тихая ошибка классификации: неверный ответ выглядит так же, как уверенный верный. Лечится это архитектурно, а не добавлением разметки: калибруйте пороги уверенности и давайте незнакомым входам путь, отличный от ближайшего известного класса, — например очередь на ручную проверку.

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

• Дрейф освещения — самый недооценённый отказ: тестируйте рассвет, сумерки, искусственный и контровой свет отдельно.
• Перекрытия и подмена ID портят все последующие кадры в трекинге, а не только момент перекрытия.
• Незнакомым объектам нужен явный путь “неизвестно” или низкой уверенности, иначе они молча уйдут в ближайший класс.
• Производительность на краю — системная задача: измеряйте весь конвейер под тепловой нагрузкой, а не модель на чистом стенде.

Соберите эталонный набор со своих камер

Полезный набор для валидации — это небольшая матрица условий, а не одна длинная запись. Начните с того, чтобы сформулировать задачу в измеримых терминах. “Определять людей” недостаточно; “считать людей, пересекающих этот вход в каждом направлении, исключая персонал” даёт записи конкретный смысл. Зафиксируйте класс или состояние цели, зону действия правила, минимальную длительность события и то, что должно происходить по результату.

Затем соберите образцы нормальных, сложных, ошибочных и переходных ситуаций. Нормальные задают типичную нагрузку и базовое поведение. Сложные — ночь, блики, дождь, толпа, перекрытия, дальние цели, смаз от движения — проверяют условия, в которых признак теряется быстрее всего. Ошибочные и спорные фрагменты не удаляйте, а размечайте: они показывают, что менять — ракурс, бизнес-правило, модель или процесс проверки. Переходные моменты — смена дня и ночи, перезапуски сцены, смена профиля потока — проверяют восстановление системы.

Снимайте с реальных рабочих камер и стремитесь, чтобы основная часть набора приходилась на настоящие условия объекта, а не на постановочные сцены. Разнесите съёмку минимум на три камеры, несколько дней и смен: набор за один день на одной камере даёт завышенные метрики, которые рушатся на второй камере в сумерках. Для каждого кадра фиксируйте метаданные — ID камеры, время, место, смену, погоду и применённую обработку: без них вы не сможете связать регресс с конкретным источником и стратифицировать тест. Удаляйте дубликаты и делите валидацию по дням или сценам, а не по кадрам случайно, иначе кадры, снятые через секунду после обучающих, утекут в тестовую выборку.

• Охватите минимум три камеры или условия съёмки, чтобы тест не зависел от одного устройства.
• Не менее 80% набора — реальные кадры с объекта; публичные или синтетические данные только для редких пробелов.
• Каждый кадр должен нести камеру, время и место до начала разметки.
• Убирайте дубликаты и делите выборку по дням или сценам, чтобы не протекала валидация.

Измеряйте на входе модели, по условиям и классам

Оценивайте кадр на том разрешении, которое реально видит модель, а не на большом мониторе видеостены. Цель, которая выглядит ясно в VMS, может потерять различающий признак после декодирования, ресайза и кропа. Записывайте ширину и высоту цели в пикселях на входе модели в ближней, средней и дальней зоне сцены, а также ракурс, позу, частоту перекрытий, смаз и сжатие. Универсального порога в пикселях нет: номерные знаки, каски, люди и состояния занятости требуют разного объёма признака, поэтому используйте замеры для сравнения зон, а затем прогоняйте модель на этих образцах.

На размеченном наборе считайте точность и полноту отдельно по каждому классу и группе условий, а ложные срабатывания и пропуски — явными числами. Точность говорит, как часто алерт верен; полнота — какую долю реальных событий вы ловите. Они конкурируют, и точка настройки зависит от того, какой сбой дороже на вашем объекте. На инспекционной линии модель, настроенная ловить каждый дефект, будет чаще помечать годные детали; если каждое ложное срабатывание останавливает линию, допустимый потолок куда ниже, чем когда помеченная деталь уходит на переделку и очищается за секунды. Заявляйте достижимый диапазон при оговорённых условиях, а не одну цифру.

Следите и за калибровкой уверенности. Современные сети систематически переоценены, поэтому порог на сырых выходах может значить не то, что вы думаете. Там, где модель участвует в подсчёте, контроле доступа или близких к безопасности решениях, сравните заявленное распределение уверенности с реальной корректностью на своих записях и отправляйте хвост низкой уверенности человеку. Система, которая честно говорит “я не уверен”, в эксплуатации надёжнее той, что выдаёт уверенные неверные ответы, которые никто не отличит от верных.

• Измеряйте размер цели в пикселях на входе модели в ближней, средней и дальней зоне.
• Считайте точность и полноту по классам и условиям плюс отдельно ложные срабатывания и пропуски.
• Потолок ложных срабатываний определяйте тем, во что обходится алерт на вашей линии, а не точкой настройки вендора.
• Проверяйте, калиброваны ли баллы уверенности на ваших записях, прежде чем доверять порогу.

Два трека тестов: офлайн-модель и живая система

Офлайн-записи идеальны для сравнения поведения модели на повторяемых данных, но не заменяют тест живой системы. Полный конвейер должен декодировать реальный RTSP-поток, обрабатывать метки времени и переподключения, вести несколько камер одновременно и отдавать события и свидетельства с понятной задержкой. Разделение валидации на два связанных трека держит вопросы раздельно. Трек модели измеряет обнаружения, пропуски, ложные алерты и поведение по условиям на размеченных клипах. Трек системы — стабильность декодирования, сквозную задержку, нагрузку на вычислитель и память, хранение, вывод и восстановление после обрывов.

Производительность — главная ловушка. Детектор, который держит комфортный FPS на ненагруженной рабочей станции, часто проседает на краевом устройстве в поле: там он делит память с декодированием и предобработкой и троттлится от нагрева при длительной нагрузке. Когда устойчивый FPS падает ниже частоты кадров камеры, конвейер теряет кадры, а потерянные кадры рвут именно то, на что опираются трекинг и распознавание действий, — временную непрерывность. Значимая цифра — это устойчивая пропускная способность всего конвейера на целевом устройстве под реальной нагрузкой, а не пиковая скорость модели на чистом стенде. Замеряйте с подключённой камерой и прогретым устройством; если модель не держит FPS, уменьшите её или частоту инференса, а не выпускайте систему, которая молча теряет свидетельства.

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

• Трек модели: повторяемое качество обнаружений на размеченных записях по условиям.
• Трек системы: живое декодирование, сквозная задержка, параллельные потоки, хранение, вывод, восстановление.
• Проверяйте устойчивую пропускную способность под тепловой нагрузкой с реальной камерой.
• Манифест связывает каждый результат теста с камерой, клипом и метаданными потока.

Вводите поэтапно и доказывайте доверие до переключения

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

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

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

• IQ/OQ/PQ: монтаж, затем функции на границах, затем статистическая приёмка на реально-репрезентативных данных.
• Держите параллельный прогон “человек плюс система” от недели до двух до переключения.
• После запуска следите за распределением уверенности, срабатываниями по времени и пустыми кадрами.
• Планируйте дообучение и повторное обучение операторов, иначе доверие тихо уйдёт за квартал.

Заложите стоимость ложных срабатываний и доверие оператора

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

Доверие — живой операционный актив, который вы измеряете косвенно. Если операторы начинают игнорировать или глушить алерты, это сигнал о частоте и полезности алертов, а не о дисциплине. Сопровождайте каждый запуск живой стандартной операционной процедурой и периодическим повторным обучением и не считайте “никто не жалуется” доказательством, что всё в порядке, — это отсутствие инструментовки. Цель полевой валидации не идеальная цифра точности, а защищаемое утверждение о том, как система ведёт себя в условиях, с которыми реально столкнётся, с названными и инструментированными пробелами до того, как демо превратится в обязательство.