Розпізнавання емоцій за обличчям у застосунку: де ламається точність
Розпізнавання емоцій за обличчям у мобільному застосунку ламається не на моделі, а на вхідних даних. У лабораторії обличчя рівне, світло рівне, кадр повний — точність розпізнавання емоцій виглядає переконливо.
У реальному сценарії людина знімає себе на фронтальну камеру в метро, у кафе, біля вікна: половина обличчя в тіні, голова повернута на 30-40 градусів, кадр стиснутий кодеком до артефактів.
Модель отримує не обличчя, а його бліду копію — і впевнено видає «нейтрально» там, де людина роздратована.
Далі помилки детекції емоцій накопичуються по ланцюжку. Спочатку детектор обличчя втрачає рамку на повороті або при частковому перекритті — рука, окуляри, волосся. Потім вирівнювання по очах дає зсув, і ключові точки сідають повз брови та куточки рота.
Модель класифікує вже викривлену геометрію, і на виході — систематичний зсув в одну-дві емоції, а не випадковий шум. Продукт при цьому ухвалює рішення: змінює сценарій, показує контент, пише в аналітику.
Ціна такої помилки залежить від сценарію. У розвазі це роздратування користувача, у навчанні — неправильний зворотний зв'язок, у медицині чи наймі — репутаційний і юридичний ризик.
Аналіз обличчя на пристрої додає своє обмеження: не можна просто взяти важчу модель, бо вона не вміщається в бюджет батареї та часу відгуку на телефоні.
Окрема проблема — різні камери. Одна й та сама людина на різних пристроях дає різний розподіл яскравості та контрасту, а модель навчена на усередненому датасеті.
Без калібрування під потік камери точність розпізнавання емоцій просідає саме на тих пристроях, яких не було у навчальній вибірці.
Розбираємо, як це закривається: передобробка кадру, контроль якості входу, донавчання під реальні умови зйомки та чесна оцінка точності на живих обличчях, а не на тестовому наборі.
Що дає вбудоване розпізнавання емоцій і як вибрати режим роботи
Розпізнавання емоцій у застосунку — це завжди компроміс між якістю моделі, затримкою відгуку та автономністю пристрою. Нижче — три режими, між якими реально обирають на старті проєкту, і що кожен дає за метриками.
Обробка кадру на пристрої
Модель працює локально, кадр не залишає телефон. Затримка відгуку — 40-90 мс на кадр, що вкладається в живий відгук інтерфейсу. Клас відмов вузький: деградація лише на слабких пристроях, де модель не проходить за пам'яттю.
Батарея витрачається помітніше — інференс гріє камеру та процесор, тому сесії обмежують за тривалістю.
Серверний аналіз емоцій
Кадр або набір ключових точок іде на сервер, модель там важча й точніша на складних ракурсах і слабкому світлі. Затримка відгуку зростає до 300-700 мс і залежить від каналу — на мобільній мережі розкид ширший.
З'являється клас відмов, якого немає на пристрої: обрив зв'язку, таймаут, недоступність сервісу. Натомість навантаження на батарею падає, а модель оновлюється без релізу застосунку.
Гібридний режим
Швидка оцінка йде на пристрої, спірні кадри — на сервер. Затримка відгуку залишається в межах 100-150 мс для більшості сцен, частка збоїв знижується, бо за недоступності сервера застосунок продовжує працювати на локальній моделі. Це дорожче в розробці: дві моделі, синхронізація версій, логіка перемикання.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| На пристрої | Приватність критична, офлайн-сценарії, живий відгук | Точність нижча на складних ракурсах, витрата батареї |
| На сервері | Потрібна максимальна точність, модель часто оновлюється | Залежність від мережі, затримка відгуку вища |
| Гібрид | Масовий продукт з різними пристроями | Складніша підтримка, дві моделі в проді |
MediaPipe дає готові моделі для локального інференсу — на них зручно перевіряти, чи вкладається задача в бюджет затримки на пристрої, перш ніж будувати серверну частину.
Перед вибором режиму ми знімаємо профіль реальних пристроїв аудиторії та рахуємо, яка частка користувачів проходить за затримкою й пам'яттю. Далі рішення ухвалюється за цифрами, а не за смаком.
Як ми впроваджуємо аналіз емоцій: етапи інженерної роботи
Розпізнавання емоцій у мобільному застосунку — це не підключення готової бібліотеки, а інженерний цикл: модель потрібно навчити на репрезентативних даних, умістити в бюджет пристрою та перевірити на живих людях у реальних умовах зйомки.
Нижче — як ми вибудовуємо цю роботу, щоб результат не розвалювався на першому ж пристрої зі слабкою фронтальною камерою.
- Аудит сценарію та цільових емоцій. Визначаємо, які стани справді потрібно розрізняти (радість, нейтральність, утома, роздратування) і за яких умов користувач дивиться в камеру. Зайві класи роздувають модель і знижують точність на ключових — тому список фіксуємо до старту.
- Збір набору кадрів. Формуємо датасет із різним освітленням, ракурсами, віковими та етнічними групами, в окулярах і без. Дисбаланс за цими ознаками — головна причина, чому модель «працює в розробника» і помиляється в частини користувачів.
- Розмітка та валідація даних. Кадри розмічають кілька фахівців, спірні випадки виносимо на узгодження. Частку розбіжностей тримаємо низькою — інакше модель вчиться на шумі.
- Навчання та оптимізація під пристрій. Модель навчаємо, потім стискаємо під обмеження мобільного заліза: квантизація, полегшена архітектура. Мета — робота в реальному часі без перегріву та просадки батареї.
- Перевірка на пристрої. Проганяємо на реальних моделях телефонів, а не лише в емуляторі: заміряємо затримку відгуку, споживання ресурсів, поведінку за поганого світла та в русі.
- Тестування на живих людях. Збираємо фокус-групу та звіряємо передбачення моделі з оцінкою незалежних спостерігачів. Рахуємо частку збігів за кожним класом емоцій окремо.
- Передача документації. Віддаємо замовнику опис моделі, інструкцію з оновлення, схему збору нових даних і регламент контролю якості — щоб система розвивалася без нас.
Кожен етап закінчується вимірюваним критерієм: частка вірних спрацювань, затримка відгуку, стабільність на слабких пристроях. Якщо показник не досягнуто — повертаємося на попередній крок, а не «докручуємо» на око. Такий цикл займає передбачуваний час і дає систему, яку можна підтримувати роками.
Опишіть ваш сценарій — повернемося з оцінкою термінів і планом робіт за кожним етапом.
Чим відрізняється аналіз емоцій на пристрої від серверного?
Розпізнавання емоцій можна виконувати двома способами: безпосередньо на телефоні або на сервері, куди надходить кадр. Різниця не в моделі, а в тому, де відбувається обчислення і що перетинає межу пристрою.
Під час аналізу на пристрої кадр не залишає телефон: модель працює локально, назовні надходить лише результат — мітка емоції та впевненість. У серверному варіанті кожен кадр або стиснута послідовність надходять мережею, обробляються в дата-центрі та повертаються відповіддю.
Приватність даних обличчя — перше, що змінюється. Локальна обробка знімає питання зберігання біометрії: немає чого витікати, бо зображення не залишало пристрій, а згода користувача стосується лише самого факту аналізу.
У серверній схемі з'являється канал передавання, сховище кадрів і обов'язок їх захищати — це окремий контур відповідальності, який потрібно закривати шифруванням, строками зберігання та розмежуванням доступу.
Затримка та робота без мережі розходяться ще сильніше. Локальний висновок укладається в десятки мілісекунд і не залежить від якості зв'язку — емоція розпізнається в момент, коли людина ще дивиться в камеру.
Сервер додає час на передавання кадру та відповідь, а за слабкого каналу чи в метро аналіз просто зупиняється. Якщо сценарій потребує відгуку в реальному часі або роботи офлайн, серверна схема починає програвати за визначенням.
Вартість трафіку та навантаження теж різна. Постійне надсилання кадрів — це потік даних від кожного активного користувача, який зростає лінійно з аудиторією і потребує масштабування серверів під пік.
Локальний аналіз переносить обчислення на пристрій користувача: витрати на інфраструктуру перестають зростати разом із кількістю встановлень, а сервер потрібен лише для агрегованої статистики.
Гібридна схема бере найкраще з обох: базові емоції обчислюються на пристрої для миттєвої реакції та офлайн-режиму, а на сервер надходять знеособлені ознаки або спірні випадки для уточнення та оновлення моделі.
Так зберігається приватність даних обличчя, працює розпізнавання без мережі, а важкі сценарії залишаються керованими. Вибір між аналізом на пристрої чи на сервері — це питання того, що важливіше в продукті: відгук і приватність чи гнучкість моделі.
Кейс: розпізнавання емоцій у застосунку — метрики до та після
Замовник прийшов із готовим застосунком, де розпізнавання емоцій працювало «в середньому»: на тестових записах усе виглядало пристойно, а в реальних умовах користувачі скаржилися на затримку й на те, що застосунок плутає нейтральне обличчя з усмішкою.
Хибні спрацювання сягали 34% — майже кожне третє визначення емоції було неправильним, а обробка кадру займала до 900 мс, через що інтерфейс помітно відставав від людини.
Що було до
Застосунок проганяв повний кадр із камери через одну модель на пристрої, без відсіювання облич і без урахування освітлення. За слабкого світла й у профіль точність падала ще сильніше, а на бюджетних пристроях кадри просто пропускалися.
Підтримка отримувала потік однотипних звернень, і команда не розуміла, де саме втрачається якість — на детекції обличчя чи на класифікації емоції.
Що змінили
Розділили задачу на два етапи: спочатку швидкий детектор знаходить обличчя та ключові точки, потім компактна модель класифікує емоцію вже за вирівняним фрагментом.
Додали відсіювання за якістю кадру — розмиті та занадто темні кадри не йдуть у класифікацію, а позначаються як непридатні. Ввели поріг упевненості: якщо модель не набирає його, застосунок не показує емоцію взагалі, замість того щоб угадувати.
Що стало
| Метрика | До | Після |
|---|---|---|
| Частка правильних спрацювань | 66% | 91% |
| Хибні спрацювання | 34% | 9% |
| Час обробки кадру | до 900 мс | 180–220 мс |
| Звернення в підтримку за темою | потік скарг | поодинокі |
Зростання точності дала не «розумніша модель», а нормальний конвеєр: вирівнювання обличчя та відсіювання сміттєвих кадрів прибрали більшу частину помилок ще до класифікації. Затримка впала завдяки тому, що важка модель працює з маленьким фрагментом, а не з повним кадром.
MediaPipe — на ньому побудовано детектор облич і ключових точок; класифікатор емоцій навчено окремо під наші дані й він працює на пристрої, без надсилання кадрів на сервер.
Що якщо точність почне падати на нових пристроях? Метрики знімаються на потоці, а не разово: якщо частка правильних спрацювань просiдає, це видно з логів до того, як підуть скарги.
Що з приватністю? Кадри не залишають пристрій, на сервер ідуть лише знеособлені лічильники якості — це знімає більшу частину питань на погодженні.
Чи можна відкотити зміни? Так, конвеєр зібрано за етапами, і кожен вимикається окремо — повернення до попередньої поведінки не потребує перезбирання застосунку цілком.
Опишіть свою задачу — повернемося з оцінкою та планом: які метрики знімати, де вузькі місця і що дасть найбільший приріст точності.
Сумісність, міграція та відкат: що обговоримо перед стартом
Розпізнавання емоцій вбудовується в уже працюючий застосунок, а не замінює його: модель підключається окремим модулем, наявні екрани, авторизація та аналітика не переписуються.
Сумісність із застосунком перевіряємо за цільовими версіями операційних систем і класами пристроїв — на слабких моделях частина обчислень переходить на серверну сторону, щоб камера не гальмувала інтерфейс.
Якщо у вас уже є власна модель або розмітка даних, міграція моделі відбувається через проміжний шар: старі та нові передбачення деякий час обчислюються паралельно, і перемикання відбувається без зупинки сервісу.
Що якщо якість на реальних користувачах виявиться нижчою за тестову? Ми закладаємо план відкату: попередня версія моделі залишається доступною, перемикання між ними — керований параметр, а не перезбирання застосунку. Відкат повертає попередню поведінку за хвилини, без випуску нової версії в магазини.
Як бути з доступом до наших даних та інфраструктури? Доступи та ролі розводимо за принципом мінімально необхідного: інженери отримують доступ до середовища розробки, продакшн-контури залишаються під вашим контролем, усі дії логуються.
Відеопотік обробляється на пристрої там, де це можливо, — на сервер надходять лише ознаки, а не самі кадри.
Чи можна обкатати на частині користувачів, перш ніж вмикати всім?
Так. Модуль викочується поетапно на вибрану частку аудиторії, метрики якості та стабільності порівнюються з контрольною групою, і лише після цього охоплення розширюється. Такий самий механізм слугує страховкою під час відкату.
На руки ви отримуєте:
- конфігурації збирання та параметри підключення моделі для кожного середовища;
- схеми потоків даних: де обчислюється ознака, що надходить на сервер, що залишається на пристрої;
- політики доступу та ролі для інженерів, аналітиків і вашої служби безпеки;
- документацію з міграції моделі та процедури відкату з покроковими перевірками;
- опис метрик якості та дашборд для їх відстеження;
- інструкцію з оновлення моделі без випуску нової версії застосунку.
Опишіть вашу поточну архітектуру та обмеження — повернемося з оцінкою та планом робіт.
