Как за месяц создать систему учета посещаемости на базе распознавания лиц

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

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

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

Предыстория

Трудно рассказать эту историю, не объяснив коммерческие условия проекта, напрямую связанные с количеством пользователей в системе.

В КОНЦЕ КОНЦОВ, НЕВОЗМОЖНО ПРАВИЛЬНО МАСШТАБИРОВАТЬ ТЕХНОЛОГИЮ БЕЗ УЧЕТА СПРОСА.

SierraOne — компания, основанная Мохаммедом Фитури в 2019 году. Она использует искусственный интеллект и компьютерное зрение для решения проблем бизнес-операций. В начале 2021 года в компанию SierraOneобратилась Regency Group Holding (RGH), крупнейшая фирма по продаже недвижимости в Катаре, с просьбой заменить локальную систему отпечатков пальцев RGH на облачную систему распознавания лиц.

Требования

Условием сделки была поставка рабочего прототипа в главный офис в течение 30 дней. Он должен был иметь:

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

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

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

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

Бэкенд

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

Этот сервер отвечал за работу некоторых сервисов искусственного интеллекта, разработанных для мониторинга программ (классификация транспортных средств, обнаружение объектов и т. д.). Наш план заключался в создании модуля “посещаемости” поверх уже работающей системы во фронтенде и бэкенде.

Новый модуль наследовал из уже работающей системы конфигурацию сети, цикл развертывания, схему базы данных, пользовательский интерфейс дашборда и, самое главное,AI Jobs Manager. Это сэкономило много времени.

ПРИМЕЧАНИЕ. ЭТО ТАКЖЕ ПОСЛУЖИЛО ОТЛИЧНЫМ ШАБЛОНОМ ДЛЯ УСТАНОВКИ И СЭКОНОМИЛО ВРЕМЯ ПРИ ВЫБОРЕ ТЕХНОЛОГИИ.

Зеленые секции — это то, что было добавлено в инфраструктуру для поддержки модуля посещаемости.

Модуль посещаемости добавил в бэкенд-систему 3 элемента.

• Способ получения событий посещаемости.
• ИИ-модель распознавания лиц.
• Способ отображения этих событий.

Вся система уже была настроена, и с точки зрения кода нужно было только добавить в нее модуль посещаемости в бэкенд Django и дашборд ReactJS. Бэкенд отвечал за получение событий о посещаемости, хранение их в БД и выдачу указаний Jobs Producer подготовить их для ИИ. Задача дашборда — показывать результаты этого взаимодействия в реальном времени по мере поступления событий. Для этого использовался WebSocket API, управляемый Django Channels.

Jobs Producer создавал задание, сохранял его в очереди, управляемой Redis, и отправлял на выполнение в совершенно новый сервис распознавания лиц.

Оставалось только создать сервис распознавания лиц и запустить его в AI Jobs Manager.

ИИ-сервис

Нам нужна была модель искусственного интеллекта для распознавания человека по изображению его лица. Здесь пригодилась пользовательская реализация FaceNet, применяемая нами в прошлом (да здравствует повторное использование!).

У модели была одна задача — при получении изображения лица возвратить встраивание этого лица. Встраивание — это математическое (векторное) представление лица, созданное моделью.

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

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

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

Теперь полученные результаты нужно было отобразить на дашборде.

Мобильное приложение

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

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

УСТРОЙСТВО, КАК И ЛЮБОЕ ВЗАИМОДЕЙСТВИЕ С НИМ, ДОЛЖНО БЫЛО БЫТЬ ОТЛАЖЕННЫМ И БЕСПРОБЛЕМНЫМ.

Приложение должно было хорошо выполнять две задачи:

• фиксировать события максимально точно;
• регистрировать сотрудников быстро и безотказно.

Следовательно, успешным будет тот программный продукт с минимальной функциональностью, который удовлетворит этим двум спецификациям. Мы выбрали ReactNative, потому что на тот момент еще не имели собственного оборудования.

Захват событий

Регистрация входа/выхода происходила два раза в день (а иногда и больше). Мы разработали приложение таким образом, чтобы для его функционирования требовалось минимальное вмешательство пользователя.

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

Регистрация

При ежедневной регистрации входа/выхода изображения лица человека могут отличаться. Таким образом, регистрационные изображения человека должны хорошо отображать его лицо и иметь как можно больше общего со всеми его/ее ежедневными изменениями.

Чтобы достичь этого, пришлось установить некоторые ограничения, применяемые ко всем регистрационным изображениям, возникающим в системе. Было выработано 3 правила.

1. Лицо не должно быть слишком далеко или слишком близко к камере.
2. Лицо должно быть зафиксировано прямо, без наклона в какую-либо сторону.
3. Лицо должно быть хорошо освещено, а не снято в темном месте.

Для достижения 1 и 2 пунктов мы использовали функцию Google Face Detection, чтобы получить лицо на самом устройстве. API Face Detection предоставил информацию о трех углах поворота лица. Это позволило определить, в каком положении расположено лицо и как далеко оно находится от камеры. Мы использовали эту информацию для выдачи соответствующих сообщений пользователю в момент регистрации в системе.

Обратная связь оказалась очень оперативной, так как все работало на самом устройстве, что обеспечило быстрый и простой пользовательский опыт.

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

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

Эти три правила обеспечили отличное качество регистрационных изображений, а также упростили процесс регистрации.

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

Аппаратное обеспечение и установка

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

Кроме того, у нас было мало времени! Главное было начать как можно скорее, поэтому мы мгновенно выбрали подходящее устройство. На тот момент у каждого из нас был iPad, что и помогло принять решение.

Спустя неделю у нас была базовая реализация распознавания лиц, работающая на iPad.

На этом этапе мы поняли, что не сможем продавать iPad каждому из наших клиентов по мере их увеличения. Нужно было переходить на более дешевое устройство, и мы выбрали планшет Android. Благодаря ReactNative это был менее дорогостоящий шаг.

Планшет Android оказался неподходящим вариантом. Цена устройства все еще была слишком высока, и мы продолжили поиски не очень громоздкого и достаточно дешевого девайса. И тогда мы подумали: а что если напечатать чехол для планшета на 3D-принтере?

К сожалению, 3D-печать большого чехла оказалась слишком сложной: нам пришлось бы печатать несколько частей и собирать их вместе. Если бы мы и разобрались с этим, то на печать одного чехла ушло бы слишком много времени. Затем нам в голову пришла другая идея, а именно заменить планшет телефоном Android.

3D-печать для телефона была намного проще, чем для планшета, не говоря уже о том, что мы бы сэкономили столько средств благодаря одному устройству.

Конечно, были и минусы использования телефона, но они не имели значения. Все это было сделано для прототипа, который мы должны были представить в конце месяца. Мы знали, что со временем перейдем на что-то более надежное (и перешли).

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

Наша технология отлично работала, и мы установили первое устройство в головном офисе, как и было оговорено.

Все прошло отлично! Наш прототип был установлен, и система смогла зарегистрировать 40 сотрудников без проблем. Ничто не мешало им проходить регистрацию на входе и выходе, и наш локальный сервер не подвел.

Заключение

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

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