Что вам стоит попробовать: Правильный подход к тестированию систем видеоаналитики

Привет, Хабр!

Мы - команда пресейл инженеров NtechLab. Мы занимаемся тем, что помогаем нашим потенциальным клиентам и партнерам познакомиться с нашими решениями, научиться ими правильно пользоваться для достижения поставленных бизнес задач (слишком официально получилось, да). В рамках нашего корпоративного блога мы будем публиковать статьи в рубрике “Байки от нашего пресейла” (рабочее название, предложения в комментах приветствуются), в которых будем делиться веселыми и поучительными примерами из нашей практики. Правда, первая статья получилась достаточно серьезной, но зато очень важной для понимания основных ошибок, которые допускают компании на этапе тестирования систем видеоаналитики и делают наши рабочие будни сложными. Дальше будет веселее :)

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

Пилотный проект – тоже проект

Если бы можно было поставить палатку с бесплатными пробниками нашего ПО в ближайшем торговом центре, мы бы непременно так и сделали. Какой бизнес откажется от клиентов, которые собственноручно убедились в качестве продукта? 

К сожалению, система видеоаналитики, это не еще один корпоративный мессенджер или сервис ведения заметок, разобраться с которым может каждый. Получив такой пробник, неподготовленный клиент просто не сможет им никак воспользоваться. Чтобы провести тест системы видеоаналитики, эту систему нужно сначала создать. И, как вы понимаете, далеко не каждый готов пойти на связанные с этим расходы. 

Чтобы вы лучше понимали “масштабы бедствия” стоит рассказать, что в нашей практике были пилотные проекты, которые продолжались 1,5 - 2 года. И далеко не все такие проекты завершились внедрением системы в прод, т.е., фактически, ресурсы заказчика были потрачены впустую.

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

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

К чему готовиться?

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

Попытайтесь максимально очертить круг задач которые вы хотите решить. Задача которая звучит как “Аналитика посетителей торгового центра” не имеет решения, потому что каждый участник процесса будет понимать её абсолютно по-своему. Лучше всего будет, если вы разобьете большую задачу по масштабной видеоаналитике на некоторое множество более мелких, таких как:

• контроль входа в помещение;

• анализ потока посетителей на входе для получения аналитики;

• контроль тревожного списка;

• контроль посещения VIP-гостей;

• поиск лиц в видеоархиве.

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

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

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

На пилотный проект без понятных метрик были потрачены силы и средства на закупку и монтаж оборудования, выделение времени персонала, но результат просто невозможно было оценить. Клиент (департамент) не смог защитить такой проект для своего внутреннего заказчика. Так проект без понятных целей и метрик просто съел ресурсы компании. Конечно, отрицательный опыт - это тоже опыт.

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

Признаками хорошего пилота является наличие описанной методики испытаний, в которой обозначены цели, условия, порядок и методы испытания, а также критерии оценки. Если вы хотите сделать по-взрослому, на этот счёт существует целый ГОСТ 34.603–92 «Информационная технология. Виды испытаний автоматизированных систем», в котором можно найти много полезного. В случае если вы выбираете поставщика из нескольких вендоров и хотите сравнить эффективность нескольких систем для решения своей задачи, то есть провести сравнительное тестирование, то создать такой документ тоже не составит труда (указанный ГОСТ не регламентируют такой вид испытаний как сравнительные испытания). Не забудьте поставить участников в одинаковые условия. Для систем распознавания лиц, как правило, это означает одновременную работу на одних и тех же видеопотоках и одних и тех же эталонных фотографиях статистов, загруженных в базу данных системы. Даже отличие в освещённости может сильно влиять на качество распознавания. Согласованный всеми участниками документ сильно поможет при решении возможных споров, а Протокол испытаний, полученный в результате испытаний, будет основным документом, который поможет при принятии решений уже в коммерческой части переговоров.

Важным условием для проведения тестовых испытаний системы является оценка возможностей имеющейся материально-технической базы. И речь идет не только о наличии оборудования, которое отвечает требованиям ПО, но и о самом пространстве, в рамках которого оборудование должно будет функционировать. Этот аспект отлично иллюстрирует один из наших проектов по распознаванию в общественном транспорте, где пространственные ограничения были определяющим вектором его реализации. Аппаратное обеспечение должно было работать в условиях минусовых температур и быть максимально компактным, желательно без механических движущихся частей. NUC’и мини-PC не подходят, здесь нужны Edge решения вроде промышленных ПК или специально “упакованных” NVIDIA Jetson или других одноплатников. 

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

Очень важно проверить, что рекомендации по выбору оборудования полностью соблюдены, и в самый ответственный момент не обнаружится, что в сервер напихали вдвое больше видеокарт, чем может выдержать его блок питания (а мы как-то потратили почти неделю с привлечением разработки и QA для анализа причины того, что наш софт на топовой видеокарте еле-еле работал). Или, что вместо производительного физического сервера запрашиваемой конфигурации вам предоставили виртуальную машину с 2 vCPU и 4GB RAM на нем для тестирования с 20 камерами (да-да, такой пример действительно у нас был с одним заграничным партнером). Или что сотня FullHD камер подключены к системе через офисный интернет пропускной способностью в десяток мегабит в секунду.

Стоит подумать и о человеческих ресурсах, доступных для развертывания и обслуживания системы, назначить ответственных. Всегда лучше договориться о поддержке вендора или партнера, потому что разобраться в короткие сроки со всеми нюансами работы систем достаточно сложно. Как правило, вендоры идут на это и оказывают всестороннюю поддержку пилота. Есть ли у вас собственные компетентные специалисты, которые полностью разберутся в документации и обеспечат оптимальные условия работы? Сможете ли вы самостоятельно выстроить процессы для пополнения базы данных? От этого тоже зависит, как себя будет чувствовать тестовая установка и какие результаты система покажет в итоге.

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

Партнер пересылает нам этот скриншот вот с таким текстом:

“We have tried to install findface security server software on ubuntu 18.04 OS as per the installation documents but we are facing some difficulties to install the software. Requesting you to take remote access and install the software or send me a video of step by step installation.”

#facepalm

Ну или наш любимый “метод curl”. Многие партнеры хотят интегрироваться с нашим ПО посредством REST API. В документации почти для каждого метода API есть пример с использованием утилиты curl для выполнения нужного HTTP запроса. К сожалению, большое количество партнеров не знает про эту утилиту и воспринимает такие примеры как часть нашего ПО. Вот из последнего:

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

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

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

Что и как проверять?

Допустим, мы учли все технические нюансы и пилотный проект готов к запуску. Возникает закономерный вопрос: “А как понять, что видеоаналитика работает как надо и полностью решает поставленные задачи?” Следует проработать момент релевантных метрик, по которым будет производиться оценка. И в зависимости от сценария применения системы видеоаналитики, набор показателей будет сильно различаться от проекта к проекту.

СКУД - время задержки перед открытием турникета и общая пропускная способность. Обязательно проверьте работу в условиях очередей, когда много людей хотят пройти в турникет.  Обязательно задумайтесь о фроде и наличии у поставщика технологии Liveness. 

ВИДЕОНАБЛЮДЕНИЕ - точность работы в различных условиях. Например, простые условия для входа в супермаркет: хорошая освещённость, нет перекрытия лиц в виде масок,очков капюшонов, естественные наклоны головы. Люди естественным образом входят в магазин, при этом обычно никто из них не смотрит в камеры.

• % детекции в простых условиях

• % истинного распознавания в простых условиях 

• % ложного  распознавания в простых условиях

Пример сложных условий. Перекрытые лица: маски, очки, капюшон, кепка. Сильные повороты лица… человек смотрит в сторону. 

• % детекции в сложных условиях

• % истинного распознавания в сложных условиях 

• % ложного  распознавания в сложных условиях

АНАЛИТИКА 

Как может звучать KPI в аналитике? На первый взгляд, очевидными метриками являются, например, “точность определения возраста +-5 лет в 90% случаев”, “точность определения пола - 95%”. В целом, критерии нормальные, но являются достаточно академическими. Ответьте себе на вопросы “А устроит ли меня система аналитики, которая будет ошибаться с возрастом не в 90% случаев, а в 85%?”, “А нужна ли мне точность +/- 5 лет? Нужна ли мне для принятия бизнес решений такая детализация?”. Если вы ответили “нет”, то сначала решите, какие значения показателей нужны вам с точки зрения бизнес-задачи, а потом просто опишите их в KPI.

Определиться с методологией тестирования непросто, особенно, если приходится работать с технологиями распознавания впервые. Конечно, скорее всего, у поставщика ПО уже будет готовая ПМИ (Программа и Методика Испытаний), а вот необходимыми размеченными данными для максимально объективной оценки результатов уже придется заняться самостоятельно. Будет ли это контрольная группа людей, которые будут ходить под камерами для проверки качества работы тревожных списков, человек с “кликером” для проверки точности подсчёта посетителей, сотрудник с маской, очками, шапкой и прочими атрибутами для тестирования СКУД или же оператор, который вручную будет просматривать видео для получения точных значений, ко всему этому нужно быть готовым, и без этого не получится объективно оценить работу аналитики.

NIST - прекрасная лакмусовая бумажка для оценки серьезности алгоритмов вендора. Если вендор - участник NIST и находится хотя бы в сотне первых – это говорит об эффективности его алгоритма распознавания. Тестирование NIST проводится на очень больших объемах данных и, скорее всего, ваши объемы – это капля в море датасетов NIST, где точность алгоритмов различается в 6 знаке после запятой, а это значит, что вы не заметите разницу в работе этих алгоритмов на своих относительно небольших объемах фотографий. Но алгоритм, та или иная реализация глубоких нейронных сетей или NND, – это только часть системы. Если вы работаете с видео, алгоритм распознавания без хорошего детектора лиц на видео как мёртвому припарки. Если детектор не умеет находить и выбирать лучшее по качеству лицо человека на видео за те секунды, когда он проходит мимо камеры, то вам нечего отдавать вашему дорогому алгоритму из NIST. Даже если есть качественный, быстрый детектор и нейронная сеть из NIST это всё ещё технологии, а не продукт, который готов для решения ваших бизнес-задач. Оценивайте готовность продукта применительно к вашему бизнес-кейсу, а не технологию. Что вашему оператору в мониторной комнате от наличия прекрасного движка распознавания без удобного UI и алертов? Какая польза охраннику на входе в магазине, если он не может узнать нарушителя в ту же секунду, а сообщение по рации от оператора из мониторки пришло, когда нарушитель уже потерялся?

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

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

Очень частый пример такого рода ошибки - это тестирование системы распознавания лиц, которая должна работать в сложных условиях некооперативного распознавания на улицах, вокзалах и ТЦ, на публичных простых датасетах для распознавания лиц (например, LFW). Заказчик берет какое-нибудь open-source решение, прогоняет его на таком датасете и получает хороший результат. Потом делает то же самое с коммерческим ПО и получает такой же хороший результат. Далее делает вывод, что разницы в точности никаких, “тогда зачем платить больше?”. Думаю, не стоит объяснять, что происходит, когда такой заказчик выкатывает решение на реальные камеры...

Не слишком ли много заморочек?

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

P.S.

Если вы хотите больше узнать о совокупной стоимости владения для проектов с распознаванием, в нашем блоге есть статья на эту тему.