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