Разработка системы распознавания лиц: где теряется точность
Точность распознавания ломается не внутри модели, а на входе. Камера смотрит на поток сверху вниз, встречный свет из витрины пересвечивает половину кадра, зимой добавляются капюшон и шарф. Поток, который на тестовой выборке даёт ровный результат, на объекте превращается в лотерею.
Цена ошибки считается не в процентах, а в инцидентах. На проходной с тысячами проходов в сутки даже доли процента — это десятки случаев: турникет открывается перед чужим человеком или разворачивает сотрудника, который ходит этой дверью полгода. Первое — дыра в периметре, второе — очередь и ручные пропуска на ресепшене.
Поэтому разработка системы распознавания лиц начинается не с выбора модели, а с обследования точек установки. Инженер фиксирует высоту и угол камеры, дистанцию до лица, схему освещения и ширину прохода, оценивает качество съёмки в часы пик. Часть точек после этого меняет конфигурацию — оптика, подсветка, перенос камеры на уровень лица.
Пороги сравнения настраиваем под задачу: для биометрического контроля доступа допустимая доля ложных срабатываний на порядок строже, чем для учёта посещаемости. Даже сильные модели по независимым сравнительным испытаниям NIST FRVT теряют в разы при смене ракурса и освещения — решает не модель, а связка качества съёмки, сценария и порога.
Ниже разбираем, как это закрывается на этапе проектирования и что именно мы проверяем до ввода в эксплуатацию.
Эффект внедрения: скорость отклика, точность, отказы
Пропускную способность мерят не точностью модели на тестовой выборке, а числом людей, проходящих точку контроля в минуту при пиковой нагрузке. Время отклика системы — от появления лица в кадре до команды на проход — держат в долях секунды, поэтому человек идёт не останавливаясь, а несколько потоков не сливаются в очередь. Порог совпадения настраивают так, чтобы скорость прохода не проседала ни в утренний пик, ни в вечерний разъезд.
Снижение ошибок — это управляемый баланс двух классов: ложный пропуск чужого и ложный отказ своему. Пороги подбирают под сценарий — проходная, безбарьерный вход, касса — дополняют проверкой живости и пересматривают по логам, а не на глаз. Ориентируемся на независимые методики оценки вроде NIST FRVT: доля ложных срабатываний уходит на порядки вниз, а ручных проверок у охраны становится кратно меньше.
Отказоустойчивость закладываем с первого дня. Распознавание может считаться на самой камере, события буферизуются при потере связи и доезжают до сервера после её восстановления. Узлы контроля резервируются, и при отказе сегмента точка переходит в штатный резервный режим — время отклика на остальных не растёт.
Метрики снимаем до и после: пропускная способность точки в минуту, средний отклик, доля ложных пропусков, время восстановления после сбоя.
Режимы работы: сравнение подходов и ограничений
Режим работы определяется двумя вопросами: что именно сравнивает система — кадр с одним заранее известным шаблоном или с целой базой — и где идут вычисления. От ответа зависят требования к оборудованию на площадке, каналу связи и допустимой нагрузке на объект.
Ниже — четыре сочетания, между которыми реально выбирают на старте проекта. Они не исключают друг друга: чаще всего на объекте оставляют детекцию и проверку живости, а сопоставление выносят в защищённый контур.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Верификация один к одному | Доступ сотрудника на объект, сверка человека с документом, подтверждение операции | Нужен заранее зарегистрированный шаблон; при ошибке регистрации человек в систему не попадёт |
| Идентификация по базе | Поиск по сотрудникам и посетителям, контроль перемещений, аналитика посещаемости | Точность и время отклика зависят от размера базы; нужны чистка и дедупликация записей |
| Обработка на объекте | Площадки с узким каналом связи и без постоянного доступа в сеть | Число одновременных потоков ограничено устройством; обновление моделей требует доставки на каждый узел |
| Защищённый контур | Объекты, где кадры и шаблоны не должны покидать территорию | Нет внешней аналитики и автообновлений; обмен между площадками — только согласованными выгрузками |
На старте мы фиксируем, какие режимы действительно нужны, и проверяем их на пиковой нагрузке — очередь у турникета, поток посетителей в час пик. Если режим её не выдерживает, его меняют до запуска: переключение идентификации на верификацию или перенос вычислений на объект — это настройка, а не переделка проекта.
Этапы внедрения: от аудита условий до передачи
Порядок работ выстроен так, чтобы каждое следующее решение опиралось на замеры, а не на предположения. Ошибка в точке установки камеры или в пороге срабатывания всплывает уже в эксплуатации, когда переделка стоит дороже всего, — поэтому аудит и проверка на живых людях идут до включения системы в контур доступа.
- Аудит объекта. Считаем сценарии прохода: сколько человек в час, через рамку, турникет или свободный вход, есть ли поток на выход. Отдельно смотрим освещённость, высоту установки, ракурсы и засветку от окон. Результат — схема точек съёмки и требования к монтажу.
- Подбор оборудования. Камеры, вычислитель под распознавание и контроллеры доступа подбираем под посчитанный поток, а не по каталогу поставщика. Проверяем, что кадр на входе даёт достаточное качество лица в движении.
- Монтаж и калибровка. Настраиваем зоны детекции, отсекаем ложные срабатывания на отражениях, посторонних объектах и движении в соседнем коридоре. Регистрируем эталонные изображения сотрудников по единому регламенту съёмки.
- Настройка порогов. Порог совпадения, число кадров для подтверждения, реакция на неизвестного, задержка открытия — это баланс между пропуском своего и ложным допуском чужого. Значения фиксируем вместе с заказчиком и сохраняем как версию конфигурации.
- Тестовые сценарии. Прогоняем контрольные проходы: свои и не внесённые в базу, очки, головные уборы, слабое освещение, плотный поток. Считаем долю верных срабатываний и число ложных — при отклонении возвращаемся к порогам, а не «докручиваем» на глаз.
- Опытная эксплуатация. Запускаем на одной точке с оператором рядом, сверяем журнал событий с фактическими проходами и вносим правки по реальным данным.
- Передача в эксплуатацию. Отдаём документацию, регламент действий персонала и обучение смены, переносим систему на мониторинг и сопровождаем первые недели.
После передачи конфигурация остаётся управляемой: любое изменение порогов версионируется, откат к рабочему состоянию занимает минуты. Дальше развиваем контур по мере роста объекта — добавляем точки и сценарии без пересборки ядра.
Комплект поставки: схемы, конфигурации, регламенты
После сдачи у заказчика остаётся не только работающий контур, но и комплект документов, по которому систему можно эксплуатировать, расширять и передавать другой команде — без восстановления контекста по переписке и памяти разработчиков.
Комплект формируется параллельно с разработкой, а не дописывается в конце: к приёмке он описывает фактическую конфигурацию, а не проектную.
- Схемы размещения камер — точки установки, зоны перекрытия, рабочие углы обзора и требования к свету, чтобы распознавание работало в потоке, а не на тестовом кадре.
- Конфигурации системы — профили распознавания, пороги схожести, списки зон, сроки и глубина хранения событий и снимков.
- Политики доступа — роли операторов, разграничение по камерам и группам, журналирование запросов к базе и выгрузок.
- Регламенты реагирования — действия оператора при срабатывании, маршрут уведомлений, порядок фиксации ложного срабатывания.
- Техническая документация — описание архитектуры, инструкции по развёртыванию, обновлению и восстановлению после сбоя.
- Памятки для операторов — типовые действия и частые сбои, чтобы новый сотрудник выходил в смену без наставника.
- Протокол приёмки — тестовые сценарии и метрики точности, при которых система считается сданной.
Комплект снимает зависимость от подрядчика: расширение зон наблюдения и смена операторов идут по документу, а не по памяти.
Кейс: распознавание на проходной производственного объекта
Что было до
На проходной четыре турникета, смена — около двух тысяч человек, вход с улицы. Условия съёмки тяжёлые: контровый свет на восходе, пыль от цеха, зимой пар от дыхания, у половины смены — каски, маски и защитные очки. Прежний контроль доступа держался на картах: пропуска передавали, а на слабом освещении охрана открывала вручную. Точность распознавания на архивных записях не превышала 82%, в пик очередь на входе доходила до 10-12 человек.
Что изменили
Камеры Hikvision разнесли по двум ракурсам — фронтальному и под углом, с инфракрасной подсветкой и настройкой экспозиции под контровый свет. В базу сотрудник попадает по серии кадров, хранится числовой шаблон, а не фотография. Порог схожести подбирали на реальных сменах: важнее было не отклонить своего — от подмены защищает проверка живости, отсекающая маску или экран телефона. Решение о проходе принимает локальный контроллер, поэтому обрыв связи с сервером турникет не останавливает.
Что стало
Доля уверенных подтверждений с первого кадра выросла с 82% до 97% на том же составе смены, среднее время прохода сократилось с 8 секунд до 2. Проход по чужому пропуску не зафиксирован ни разу: каждое событие связано с кадром и записью в журнале. Отчёт о фактическом выходе на смену формируется автоматически, табель больше не сводят вручную. Схему затем тиражировали на вторую площадку — с поправкой на другой свет и другой поток людей.
Чем идентификация отличается от верификации на практике
Верификация отвечает на один вопрос: тот ли это человек, за кого он себя выдаёт. Кадр сравнивается с единственным шаблоном, привязанным к карте, логину или документу. Порог настраивают под цену ошибки: на проходной строже, при разблокировке мягче.
Идентификация ищет совпадение по всей базе, не зная, кого именно проверяют, — это поиск «один ко многим». Его точность зависит от качества галереи: размера, актуальности, дублей и того, насколько эталонные снимки похожи на реальный поток с камер. База в десятки тысяч записей и база в миллион — разные требования к индексам и разный уровень ложных срабатываний.
Отсюда и разная цена ошибок. Для верификации критичен ложный пропуск: сотрудник не проходит, очередь на входе растёт. Для идентификации опаснее ложное совпадение — система находит «похожего» и запускает действие по чужому профилю, поэтому порог поднимают, а кандидатов подтверждают вторым фактором.
Границы применимости задаёт сценарий. Контроль доступа, подтверждение личности при выдаче, вход в приложение — верификация: база маленькая и контролируемая. Поиск человека в архиве видеонаблюдения, сигнал по списку наблюдения, аналитика потока — идентификация, где заранее неизвестно, есть ли человек в базе.
Режим фиксируют до выбора модели и расстановки камер: от него зависят требования к базе, пороги и порядок разбора спорных случаев. Ошибка здесь не лечится настройкой — она возвращает проект к сбору и разметке данных.
Технические сомнения: свет, ракурс, отказоустойчивость
Инженерные сомнения поднимаются раньше юридических: выдержит ли распознавание свет из окна напротив, что делать с уже смонтированными камерами, где физически лежат шаблоны.
Что происходит при слабом освещении и неудачном ракурсе?
Кадр сначала проходит оценку качества — резкость, экспозиция, угол поворота головы. Слабый кадр не уходит на сравнение, а добирается по серии следующих; в тёмных зонах работают камеры с подсветкой. Порог уверенности настраиваем по точке: на проходной он жёстче, в зоне обзора мягче, чтобы события не терялись.
В каком виде хранятся биометрические шаблоны?
Изображения не сохраняются — в базе лежит числовой вектор, по которому лицо не восстановить. Шаблон привязан к человеку, а не к камере, поэтому замена оборудования не требует перезаписи базы. Доступ к хранилищу разграничен, а обращения к шаблонам фиксируются в журнале.
Система может работать в закрытом контуре, без выхода наружу?
Да: детекция, сравнение и хранилище разворачиваются на площадке заказчика и не обращаются во внешние сервисы. Обновления моделей приносятся на носителе и ставятся по регламенту, поэтому сеть остаётся изолированной. Это же снимает вопрос передачи биометрии третьим лицам.
Подойдут ли камеры, которые уже стоят на объекте?
Часть парка обычно подходит: важно, чтобы поток отдавался по открытому протоколу и в зоне распознавания хватало детализации лица. По остальным точкам даём схему — где достаточно поменять угол или объектив, где нужна замена. Инвентаризацию делаем до старта, чтобы не переделывать монтаж.
Обсудим задачу: какие данные нужны для оценки
Оценка проекта и план работ опираются на исходные данные, а не на общие формулировки. Ниже — то, что разбираем на обсуждении задачи; полный набор не требуется, пробелы закрываем на обследовании объекта.
- Сценарий и точка решения: где система сравнивает лицо — проходная, касса, терминал — и что происходит при совпадении и при отказе.
- Объём потока: число источников видео, распознаваний в сутки, пиковые часы, одновременные события в кадре.
- Качество съёмки: ракурсы, освещённость, движение в кадре, маски и головные уборы, примеры записей.
- Требования к точности: что критичнее — не пропустить своего или не впустить чужого, допустимая доля ложных срабатываний.
- Инфраструктура и данные: собственные серверы или закрытый контур, правила хранения биометрических шаблонов, сроки удаления.
- Интеграции: куда передаём результат — контроль доступа, учётная система заказчика, оповещение охраны — и какие интерфейсы уже есть.
- Рамки и сроки: согласия субъектов, ответственный за соответствие, фиксированная дата запуска, готовность к поэтапному внедрению.
После разговора возвращаемся с оценкой проекта: состав и этапы работ, требования к выборке для настройки и проверки, порядок внедрения — от пилотного участка к полному контуру. Если данных не хватает, предложим, как собрать их на ограниченном участке и подтвердить точность до масштабирования.
