Настройка аналитики: ложные тревоги и точность

Это инженерная рекомендация, а не юридическая консультация. Уточняйте детали у квалифицированного юриста.

Кратко

Любая видеоаналитика делает два рода ошибок – поднимает тревогу, когда ничего не произошло (ложная тревога), и молчит, когда событие было (пропуск) – и обнулить оба сразу нельзя, поэтому «точность» – это ручка, которую вы выставляете, а не одно число, которое может пообещать вендор. Эта ручка – порог уверенности: опустите его – поймаете больше реальных событий, но утонете в ложных тревогах; поднимите – ложные прекратятся, но вы начнёте пропускать. Куда её поставить – бизнес-решение, зависящее от цены каждой ошибки на вашем объекте и от человеческого предела, о котором покупателям почти не рассказывают: оператор, заваленный шумом, перестаёт верить системе и отключается от неё – отказ «сказки про волков», который не лечится никакой точностью модели. Эта статья объясняет компромисс precision/recall простым языком, рычаги, которыми реальный оператор срезает ложные тревоги, не слепнув, почему редкие события математически тяжелы и как держать человека в контуре, чтобы система оставалась и эффективной, и защитимой.

Почему это важно

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

Честная отправная точка: точность – это диапазон, а не число

Начнём с того, что выбросим слово, которое губит проекты видеонаблюдения: «точность», употреблённое так, будто это один процент, выбитый на коробке. Это не так. Любая аналитика – детекция объектов, правило пересечения линии, сверка лица, оценка аномалии – выдаёт по каждому увиденному объекту число уверенности, а порог решает, какие из них станут тревогами. Сдвиньте порог – и та же камера, та же модель, та же сцена дадут другую «точность». Так что вендор, заявивший, что детектор «точен на 98%», не сказал вам почти ничего полезного: он не назвал ни порог, ни сцену, ни освещение, ни то, какую из двух ошибок эти 98% прячут.

Ошибок, которые может сделать аналитика, ровно две, и назвать их – вся основа дальнейшего. Первая – ложноположительное срабатывание (false positive), оно же ложная тревога: система говорит «человек!», когда это была тень, кошка или росчерк фар. Вторая – ложноотрицательное (false negative), оно же пропуск: реальный человек прошёл, а система промолчала. Рядом – два способа оказаться правым: истинно положительное (true positive – реальное событие, верно помеченное) и истинно отрицательное (true negative – ничего не было, верно промолчали). Эти четыре клетки называют матрицей ошибок (confusion matrix), и любое заявление о точности – это всего лишь арифметика над ними.

Нажмите, чтобы увеличить

Из этих четырёх клеток выходят те самые два числа, что важны, и причина, почему одного никогда не хватало. Precision (точность срабатываний) спрашивает: из всех тревог, что система подняла, сколько были реальны? Запишем как precision = истинно положительные ÷ (истинно положительные + ложноположительные). Высокий precision значит: когда система кричит «волк», волк обычно есть. Recall (полнота, она же чувствительность) спрашивает обратное: из всех реальных событий сколько система поймала? Запишем как recall = истинно положительные ÷ (истинно положительные + ложноотрицательные). Высокий recall значит: мало реальных событий проскальзывает мимо. У системы может быть прекрасный precision и ужасный recall (она тревожит, только когда абсолютно уверена, – права, когда говорит, но молчит почти всегда) или прекрасный recall и ужасный precision (тревожит на всё – не пропускает ничего реального, но хоронит его в шуме). Единственное число, которым их объединяют, – F1-мера, среднее гармоническое precision и recall: полезно как сводка, бесполезно как замена пониманию того, что из двух вам на самом деле важно.

Ручка: почему нельзя максимизировать оба сразу

Вот механизм под всем этим. Современный детектор не выдаёт «человек / не человек». Он выдаёт число уверенности – скажем, от 0 до 1, насколько он уверен. Чтобы превратить это число в тревогу, нужен порог: порог уверенности. Всё выше порога становится тревогой; всё ниже – игнорируется. Этот единственный порог – главная ручка всей системы.

Теперь смотрите, что делает ручка. Опустите порог – скажем, с 0,7 до 0,3 – и вы примете более слабые, менее уверенные детекции. Поймаете больше реальных событий (recall растёт), но впустите и больше мусора (precision падает, ложных тревог больше). Поднимите порог к 0,9 – и наоборот: мусор исчезнет (precision растёт), но слабые-но-реальные детекции уйдут под линию и станут пропусками (recall падает). Вы не улучшаете и не ухудшаете модель – модель фиксирована. Вы скользите по уже заложенной в ней кривой компромисса, выбирая, как разделить её неизменный объём ошибок между ложными тревогами и пропусками.

Нажмите, чтобы увеличить

Кривая, которая это рисует, – кривая precision-recall (близкий родственник – ROC-кривая): отложите precision против recall, проходя порогом по всему диапазону, и увидите меню рабочих точек, которые предлагает модель. Мечта – recall 100% и precision 100%, угол справа сверху – на кривой не лежит ни у одного реального детектора в реальной сцене. Это и есть точная техническая причина, по которой весь раздел запрещает фразу «100% точности»: она описывает несуществующую точку. Существует кривая, и настройка – это выбор той единственной точки на ней, что верна для вашего объекта. Сводное число вроде mean average precision (mAP) описывает качество всей кривой, но внутренности модели за ним – архитектуры и обучение, решающие, насколько хороша может быть кривая, – относятся к слою инженерии моделей, разделу AI for Video Engineering, а не сюда. Здесь мы выбираем рабочую точку и живём с ней.

Выбор рабочей точки: всё зависит от цены ошибки

Если нельзя иметь оба, нужно решить, какую ошибку вы можете терпеть, – а это целиком зависит от того, сколько каждая ошибка стоит на вашем конкретном объекте. Это и есть суждение, которое отличает понимающего настройку от читающего спецификацию.

Возьмём две системы на противоположных полюсах. Первая – периметр подстанции или ЦОДа. Здесь пропуск (реальный нарушитель, которого система проигнорировала) – катастрофа, а ложная тревога – десять секунд взгляда охранника на экран. Цена пропуска намного больше цены ложной тревоги, поэтому настраиваемся на recall в первую очередь: ставим порог низко, принимаем, что будут шумные тревоги, и добавляем шаг проверки (человек или вторая аналитика), чтобы их отфильтровать. Лучше гоняться за десятью тенями, чем пропустить одного человека на заборе.

Вторая – подсчёт людей в ритейле для отчёта о трафике. Здесь пропуск – один несосчитанный покупатель из тысяч, статистически невидимый, а поток ложных счётов тихо портит число, которому доверяет команда мерчандайзинга. Цены перевёрнуты, поэтому настраиваемся на precision или на баланс и миримся с редким пропуском. Та же технология, противоположная установка ручки, потому что цена ошибки указывает в другую сторону. Урок тот, который покупатели чаще всего упускают: универсально «правильного» порога нет. Верная рабочая точка – свойство вашего сценария, а не камеры, и хороший интегратор ставит её осознанно, а не отгружает вендорский дефолт 0,5.

Нажмите, чтобы увеличить

Почему редкие события математически беспощадны

Внутри даже очень хорошего детектора прячется ловушка, и она ловит команды, рассуждающие из одной точности: когда искомое редкое, ложные тревоги хоронят настоящие, как бы точно ни звучала система. Это ловушка базовой ставки (base-rate fallacy), иногда называемая парадоксом ложноположительных, и это арифметика, а не пессимизм.

Проговорим числа вслух – результат и правда удивляет почти всех с первого раза. Представьте оживлённый вход, где аналитика обрабатывает 50 000 детекций людей за день. Вы хотите помечать редкое событие – скажем, конкретного человека из списка наблюдения, – которое действительно случается раз 5 за тот день. Ваш детектор «точен на 99%», что звучит непробиваемо; читайте это как долю ложных срабатываний 1%. Теперь перемножьте. Ложноположительные: 1% от примерно 50 000 не-совпадений – это около 500 ошибочных пометок. Истинно положительные: 99% от 5 реальных событий – около 5 верных пометок. Значит, на экране оператора примерно 505 тревог, из которых реальны 5, – precision около 1%. Система «точна на 99%», и почти каждая поднятая тревога ошибочна, потому что реальное событие так редко, что даже крошечная доля ошибок, применённая к огромному числу не-событий, даёт куда больше ложных тревог, чем настоящих.

Нажмите, чтобы увеличить

Это не довод против аналитики; это довод о том, как разворачивать ту, что ищет редкое. Та же математика правит списками наблюдения по лицам (см. распознавание лиц в видеонаблюдении) и обученной детекцией аномалий, и поэтому обе нужно вести как слой сортировки, подсказывающий человеку, а не кнопку, которая действует сама. Precision повышают проверкой – вторая аналитика, подтверждающий датчик или оператор, который подтверждает до того, как что-то случится, – так, чтобы 5 настоящих событий нашлись, а 500 ложных не запустили реакцию. С базовой ставкой не поспоришь; её можно только обойти проектированием.

Реальность оператора: усталость от тревог – главный режим отказа

Теперь часть, о которой не пишут в спецификациях, и причина, почему настройка – проблема и человеческая, не только техническая. Система видеонаблюдения работает не в вакууме; она работает перед человеком, а у людей есть жёсткие пределы. Главный режим отказа развёрнутой аналитики – не модель с недостаточной точностью. Это усталость от тревог (alert fatigue): оператор, залитый ложными тревогами, перестаёт верить системе и начинает её игнорировать, так что, когда реальная тревога наконец приходит, она падает в поток шума, от которого оператор уже отключился. Это эффект «сказки про волков», и он смертельно опасен именно потому, что невидим: система «работает», тревоги срабатывают, а никто их не читает.

Числа за человеческим мониторингом отрезвляют. Человек, которого попросили смотреть на видеопотоки в поисках активности, теряет внимание быстро: широко цитируемая в сфере безопасности оценка гласит, что оператор пропускает до 45% активности на экране примерно после 12 минут непрерывного наблюдения и до 95% примерно после 22 минут – а рецензируемая литература о бдительности операторов CCTV подтверждает реальное, измеримое падение детекции в течение смены. Полевое наблюдение живых дежурных показало, что лишь около трети детекций приходились на проактивный просмотр оператором, а не на звонок или тревогу, наведшую его на экран. Люди плохо умеют смотреть на тихое видео и отлично – реагировать на надёжную тревогу, и в этом весь смысл существования аналитики и вся причина того, что система, которой нельзя верить, хуже, чем никакой.

Это переосмысляет, для чего нужна хорошая настройка. Вы настраиваете не для того, чтобы число на дашборде выглядело лучше. Вы настраиваете, чтобы получить поток тревог, которому оператор всё ещё будет верить на седьмом часу ночной смены. Система, дающая 1200 тревог в день, к обеду научит оператора её игнорировать; система, дающая 12 тревог в день, почти все реальные, удержит оператора реагирующим. Цель – не ноль ложных тревог (это невозможно), а достаточно мало, чтобы доверие выжило.

Рычаги: как реальный оператор срезает ложные тревоги

Так как же на деле дойти от 1200 шумных тревог до 12 надёжных, не ослепнув к реальным событиям? Не выкручивая главный порог вверх, пока шум не стихнет, – это выбрасывает recall и начинает прятать реальные вторжения. Вы доходите туда, складывая несколько фильтров, каждый из которых убирает категорию ложных тревог, почти не стоя вам реальных детекций. Думайте об этом как о каскаде: каждая ступень убирает шум, пропущенный предыдущей.

Отправная точка в большинстве старых систем – простая детекция движения (часто называемая VMD, video motion detection), срабатывающая всякий раз, когда меняется достаточно пикселей. Это самая шумная аналитика на свете: дождь, снег, ветер в листве, ползущие тени, фары, насекомые на объективе и флаг на флагштоке – всё «движется». Объект на 40 камер на сыром движении легко даёт больше тысячи шумных тревог в день. Рычаги ниже превращают это в то, на что человек реально может смотреть.

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

Зона детекции (область интереса) ограничивает аналитику той частью сцены, что важна, – дверным проёмом, а не публичным тротуаром за ним. Фильтр направления тревожит только на нужное движение – на того, кто входит через односторонний выход, а не на обычный исходящий поток. Фильтр размера объекта, заданный быстрой калибровкой перспективы, чтобы система знала, насколько крупным выглядит человек вблизи и вдали, отбрасывает кошку на переднем плане и далёкую птицу. Требование задержки или удержания (dwell) – объект должен присутствовать, скажем, три секунды, прежде чем засчитается, – убивает мгновенные всплески, дающие удивительную долю ложных тревог. Расписание включает правило только тогда, когда оно должно быть включено (после рабочего дня, а не в течение него). А комбинация правил связывает их логикой AND: тревога, только когда человек находится в этой зоне в нерабочее время минимум три секунды. Каждое условие, которому событие должно удовлетворить, вычищает ещё один класс ложных тревог.

Нажмите, чтобы увеличить

Пройдём арифметику, потому что каскад – практическое сердце этой статьи. Начнём с 40 камер, дающих около 30 сырых тревог движения каждая в день: 40 × 30 = 1200 тревог в день, число, которое не прочтёт ни одна команда. Добавим классификацию объектов, убирающую примерно 90% не-человеческого и не-автомобильного шума: выживает около 120 в день. Добавим зоны детекции, расписание после рабочего дня и трёхсекундное требование dwell, которые вместе убирают примерно ещё 90% оставшегося: около 12 в день. Двенадцать просмотренных тревог, почти все реальные, – это система, которой оператор верит и на которую реагирует. Каскад дошёл туда, ни разу не понижая recall так, как это сделало бы грубое поднятие порога, потому что каждый фильтр бьёт по виду ложной тревоги, а не по общей уверенности модели. Ровно так же мир полиции решил ту же проблему в масштабе: юрисдикции, требующие подтверждённой тревоги перед выездом – по видео или второму сигналу, – срезали ложные выезды примерно на 90%, ведь проверка – это просто ещё одна ступень фильтра над печально шумным детектором.

Распространённые ошибки

Четыре ошибки настройки топят реальные внедрения. Первая – погоня за нулём ложных тревог выкручиванием порога, тихо уничтожающая recall: вы перестаёте видеть шумные тревоги и перестаёте видеть нарушителей. Вторая – настроить один раз и уйти, когда сцены меняются с сезонами (голые ветви зимой, густая листва летом), с новым освещением и новыми потоками, так что система, настроенная в марте, к июлю настроена неверно. Третья – настраивать число, которое никто не измерял: если вы не считаете ложные тревоги на камеру в день и не проверяете recall намеренными проходами, вы гадаете, а не настраиваете. Четвёртая, самая существенная, – принимать вывод аналитики за решение, а не за подсказку: позволять шумному детектору запускать реальное действие против человека без подтверждения человеком – и операционная, и юридическая ошибка, как объясняет следующий раздел.

Что стандартизировано – а что закрыто вендором

Если вы держите мультивендорный парк, нужно знать, какие части этой поверхности настройки переносимы, а какие закрыты на производителя камеры, – ведь здесь, как везде в видеонаблюдении, стандарт интероперабельности ONVIF гарантирует базу, а не полное равенство функций.

Стандарт ONVIF действительно стандартизирует конфигурацию правил. Его Analytics Service Specification определяет операции создания, чтения, изменения и удаления правил аналитики (CreateRules, GetRules, ModifyRules, DeleteRules), а его Annex A задаёт набор нормативных типов правил – детекторы линии, поля (зоны), праздношатания и подсчёт, – которые совместимое устройство выставляет наружу, а система управления видео (программная платформа, которая записывает и управляет камерами, называемая VMS) может настроить через ONVIF Profile M, профиль метаданных и аналитики. Так что нарисовать зону, поставить растяжку и читать получаемые события в принципе переносимо между совместимыми устройствами. Глубокий разбор этого интерфейса – в статье события, метаданные и интерфейс аналитики ONVIF.

Но сама ручка не стандартизирована. Конкретный порог уверенности, кривые чувствительности, модель калибровки сцены и качество детектора под ней – зависят от реализации, они живут в прошивке и SDK вендора, а не в интерфейсе ONVIF. Две ONVIF-совместимые камеры могут выставлять одни и те же типы правил и давать дико разную долю ложных тревог, потому что совместимость – про интерфейс, а не про точность. Чисто это держать так: ONVIF стандартизирует, как вы описываете правило; вендор решает, насколько хорошо правило на деле работает. За функциями сверх базы ONVIF вы лезете в SDK вендора – тема статьи проприетарные SDK камер за пределами ONVIF. Коммерческий обзор того, как профили ONVIF ложатся в систему безопасности, – в руководстве Фора Софт по профилям ONVIF в системах безопасности.

Рычаги настройки одним взглядом

Таблица – это набор инструментов оператора в одном виде. Каждый рычаг убирает свой класс ложных тревог; верная настройка складывает несколько, а не полагается на один главный порог.

Где здесь Фора Софт

Фора Софт строит софт для видеостриминга, реал-тайм-коммуникаций и компьютерного зрения с 2005 года – 250+ сданных проектов для 400+ клиентов, и видеонаблюдение и компьютерное зрение в центре этой работы. По настройке наша позиция – та самая «точность против производительности», что отстаивает эта статья: мы ставим рабочую точку по цене пропуска против цены ложной тревоги для каждой конкретной сцены, складываем классификацию, зоны, калибровку, dwell и расписание, а не опираемся на сырой порог, и измеряем ложные тревоги на камеру в день и recall намеренными проходами до и после. Редкую и биометрическую аналитику мы ведём как сортировку, подсказывающую человеку, а не как самостоятельный триггер, и встраиваем человека в контуре и аудит-след с самого начала – так что дежурная всё ещё верит тревогам в конце долгой смены, а система держит проверку.

Ключевые выводы

• Точность – это диапазон, заданный настройкой, а не одно число: любая аналитика меняет ложные тревоги на пропуски.
• Порог уверенности – главная ручка: вниз за recall (больше ложных), вверх за precision (больше пропусков).
• Выбирайте рабочую точку по цене каждой ошибки – recall для периметров, precision для подсчёта и списков.
• Редкие события запускают ловушку базовой ставки: «99% точности» может ошибаться почти на каждой тревоге – нужна сортировка плюс проверка.
• Главный режим отказа – усталость от тревог: настраивайте на поток, которому оператор поверит на седьмом часу, а не на ноль.
• Срезайте ложные тревоги, складывая фильтры (класс, зона, направление, размер, dwell, расписание), а не выкручивая порог.

Что почитать дальше

• Карта видеоаналитики: что может обнаружить система видеонаблюдения – каталог аналитик, точность которых вы настраиваете.
• Задержка и точность по уровням – как бюджет вычислений на краю и в облаке ограничивает доступную точность.
• Поведенческая аналитика: праздношатание, вторжение и зоны – где задаются правила зон, линий и dwell.