Розпізнавання поз у мобільному застосунку: де втрачається точність
Розпізнавання поз у мобільному застосунку — це конвеєр із трьох ланок: кадр із камери, модель, скелет на екрані. Точність втрачається не в самій моделі, а на стиках — між кадром і обчисленням, між сусідніми кадрами, між очікуваннями продукту й бюджетом часу на пристрої. Метрика на тестовому наборі при цьому тримається, а в руці користувача скелет тремтить і з'їжджає.
Помилки оцінки пози найчастіше видно як тремтіння опорних точок. Модель розбирає кожен кадр незалежно, тому шум детектора на кистях, стопах і в зонах перекриття не гаситься, а переноситься в координати.
Без тимчасової стабілізації — відстеження точки між кадрами, згладжування, передбачення на пропущеному кадрі — кут згину рахується з розкидом, і підрахунок повторень починає брехати.
Другий збій — розбіжність відеопотоку й моделі в часі. Черга кадрів зростає, обчислення йде за застарілим кадром, а розмітка малюється поверх поточного: скелет приходить із затримкою і «пливе» повз тіло. Для підрахунку повторів це втрачені фази руху.
Лікується відкиданням застарілих кадрів за міткою часу та розділенням потоку камери й потоку обчислень.
Третє — бюджет слабкого пристрою. Апарат не тягне потік, гріється й скидає частоту, після чого застосунок або пропускає кадри, або змінює клас моделі на ходу.
Ми заздалегідь рахуємо, скільки часу залишається на кадр, і задаємо передбачувану деградацію: рідше обчислення, інтерполяція між позами, чесна поведінка інтерфейсу. Розбираємо, як це закривається на практиці.
Вимірюваний ефект: що змінюється в продукті після впровадження
Перший ефект видно неозброєним оком — затримка відгуку. Поки розмітка скелета йшла за повним кадром, між рухом людини та реакцією інтерфейсу накопичувалася черга з кількох кадрів: користувач відставав від підказки, а вправу доводилося починати заново.
Після переведення основної гілки на легку модель за ключовими точками затримка відгуку стиснулася до одного-двох кадрів — інтерфейс реагує майже в момент руху, навіть коли людина прискорюється.
Стійкість до втрати кадру — метрика, на якій зазвичай розсипається прототип. Раніше один змазаний або перекритий кадр обнуляв історію, і підрахунок повторень з'їжджав.
Тепер поза відновлюється за часовим вікном: пропуск не скидає траєкторію, а частка втрачених кадрів на швидких рухах падає з одиниць відсотків до десятих часток.
Вимірювання в MLPerf Mobile і наші прогони на живих людях збігаються: легкі гілки тримають точність там, де важкі вже не встигають за рухом.
Охоплення слабких пристроїв розширюється не «на око», а за бюджетом обчислень.
Звільнений запас іде на згладжування скелета та перевірку анатомічної правдоподібності — розпізнавання поз у мобільному застосунку працює на апаратах, які ми раніше виключали з підтримки, і не потребує окремої збірки під кожну модель.
Головне — зниження класу відмов: зникає масова категорія звернень «не розпізнає мене».
Кадри з неповною фігурою, боковим світлом або людиною, що частково увійшла в кадр, більше не дають помилки: скелет добудовується за видимими точками з оцінкою достовірності, а спірна поза позначається м'яко — пропозицією виправити положення, а не повідомленням про збій.
Режими роботи моделі: на пристрої, у хмарі, гібрид
Три контури розрізняються не «якістю моделі», а тим, де обчислюються ключові точки скелета і як при цьому поводяться мережа, батарея та приватність.
Режим фіксують до старту розробки: від нього залежать архітектура застосунку, вимоги до пристроїв і список сценаріїв, які взагалі має сенс обіцяти.
| Контур | Коли підходить | Обмеження режиму |
|---|---|---|
| Обробка на пристрої | Безперервний потік камери та вимога приватності: кадри не залишають телефон | Потрібне квантування моделі та ощадлива робота з пам'яттю; на слабких пристроях падає частота розбору |
| Хмарний контур | Складні багатоперсонні сцени, розбір довгих записів, аналітика постфактум | Залежить від каналу: затримка та втрати мережі; потрібна передача відео й явна згода на обробку |
| Гібридна схема | Різнорідні сценарії: розмітка в реальному часі плюс докладний розбір на сервері | Дорожче в розробці: дві гілки виконання, синхронізація результатів, складніше тестувати |
Гібрид — не «середній» варіант, а перемикана схема. Ми закладаємо єдиний набір класів і спільну постобробку, щоб під час переходу з хмари на пристрій точки не «стрибали». Саме перемикання задається умовами: доступність каналу, заряд, тип вправи.
Обмеження перевіряємо на пілотному наборі реальних пристроїв: частка кадрів, розібраних без затримки, поведінка за слабкого каналу, стійкість до частково перекритого тіла.
За цими вимірами обираємо контур і фіксуємо його в технічній документації разом із поведінкою під час деградації — що бачить користувач, якщо розбір недоступний.
Етапи впровадження: від аудиту даних до передачі контуру
Порядок етапів тут важливіший за темп: якщо почати з моделі, а не з даних, робота повертається на перерозмітку, а приймання перетворюється на суперечку про цифри. Ведемо проєкт так, щоб кожен наступний крок спирався на вже погоджений результат попереднього.
-
Аудит даних. Дивимося, як реально знімають користувачі: ракурси, освітлення, перекриття, тривалість сесій. На виході — перелік сценаріїв, які рішення зобов'язане відпрацювати, та оцінка обсягу розмітки.
-
Підготовка розмітки. Розмічаємо ключові точки скелета й фіксуємо правила для спірних кадрів — перекритих кінцівок, виходу людини за межу кадру. Звіряємо розмітників між собою, інакше модель навчається на суперечностях.
-
Проєктування контуру. Вирішуємо, що обчислюється на пристрої, а що на сервері, як застосунок поводиться без мережі та як оновлювати модель, не випускаючи нову версію.
-
Налаштування моделі. Донавчаємо на своєму корпусі, окремо перевіряємо рідкісні пози та крайні ракурси, стежимо, щоб точність не просідала на слабких пристроях.
-
Оптимізація. Вимірюємо нагрівання, витрату батареї та затримку відгуку на реальних апаратах: точність, через яку телефон гріється, у продукт не йде.
-
Приймальна перевірка. Запускаємо погоджений набір сценаріїв і метрик, перевіряємо погане світло та обрив мережі. Розбіжність із порогом — повернення на потрібний етап, а не «доопрацювання на око».
-
Передача контуру. Віддаємо інтеграційний код, схему контуру, скрипти розмітки та навчання, документацію з оновлення моделі й чек-лист діагностики, навчаємо команду замовника.
Склад постачання: конфігурації моделей, схеми потоків, регламенти
Передаємо не демонстраційний прототип, а робоче постачання, з яким команда супроводу живе без нас. Кожен артефакт прив'язаний до свого сценарію: навчання на нових даних, викат оновлення, відкат, розбір інциденту на пристрої замовника. Нижче — що фізично залишається у вас у репозиторії та в базі знань після здачі.
- Конфігурації моделі: ваги, пороги впевненості за ключовими точками, налаштування вхідної роздільної здатності кадру. До кожного параметра — коментар, що він змінює і на якій метриці відображається: частка хибних спрацювань, стійкість до частково перекритого тіла, робота за слабкого освітлення.
- Схеми потоків даних: від захоплення кадру до вихідного скелета. Позначено, де стоїть буфер, де кадри відкидаються за нестачі часу на обробку, що відбувається за просідання частоти зйомки та як поводиться черга під навантаженням.
- Політики доступу: які модулі застосунку звертаються до моделі, що йде на серверну частину, а що обчислюється на пристрої. Окремо — правила роботи з відеопотоком користувача: де він зберігається, чим маскується, коли видаляється.
- Регламент оновлення моделі: повний цикл — розмітка нових записів, донавчання, перевірка на еталонному наборі, поступовий викат на частку користувачів. З критеріями відкату: якщо цільова метрика просіла, попередня версія повертається однією командою.
- Еталонний набір для регресії: записи із заздалегідь розміченим результатом, на яких запускається кожна нова збірка. Дозволяє ловити деградацію до релізу, а не за скаргами в підтримці.
- Профілі за класами пристроїв: де модель обчислює кадри в реальному часі, де перемикається на полегшений варіант, а де логіка деградує до аналізу окремих кадрів замість потоку.
- Документація супроводу: карта модулів, точки розширення під нові типи рухів, перелік відомих обмежень та інструкція для чергового інженера — що перевіряти насамперед, коли метрики розходяться з очікуваннями.
Кейс впровадження: метрики до і після на реальному навантаженні
Кейс впровадження — застосунок-тренер для домашніх занять: камера телефона відстежує позу, а система підказує, чи правильно виконується вправа. На вході частка правильних поз на тестовій вибірці трималася близько 68%, час відгуку на зміну положення — порядку пів секунди.
На швидких рухах скелет «тремтів», присідання зараховувалося як провал, і користувачі кидали тренування на середині.
Що змінили в моделі та обробці
Перезібрали розмітку під реальні умови зйомки — різне світло, одяг, неповний кадр — і перенавчили модель із квантуванням під мобільний прискорювач, щоб виведення обчислювалося на самому пристрої, без походу на сервер.
Додали згладжування ключових точок за послідовністю кадрів і окремі пороги впевненості для статичних і динамічних вправ: скелет перестав «смикатися», а система навчилася розрізняти паузу між повтореннями та завершений рух.
Метрики до і після
Частка правильних поз на тій самій вибірці зросла з 68% до 94%, час відгуку скоротився до десятих часток секунди. Вимірювання звіряли з еталонними розмітками відкритого набору COCO, тому цифри зіставні між релізами й не залежать від того, хто саме запускав тест.
Побічний ефект — частка доведених до кінця тренувань піднялася з 41% до 73%.
Рахуємо не «на око»: фіксована вибірка, прогін на трьох класах пристроїв, звіт із розподілом помилок за типами вправ і регрес-тест на кожному релізі — за наступного оновлення метрики не поїдуть униз непомітно.
Чи потрібна своя розмітка, якщо готова модель уже працює?
Готова модель на кшталт MediaPipe навчена на масових даних: людина на повний зріст, камера на рівні грудей, звичайний одяг, одна людина в кадрі.
Поки ваш сценарій укладається в цей розподіл, доналаштування майже нічого не додає — ключові точки стоять рівно, а тижні на розмітку не потрібні.
Доналаштування закриває зміщення, але не змінює природу задачі.
Якщо ваші рухи — варіація загальної задачі (та сама людина, та сама проєкція, інший одяг або ракурс), достатньо доналаштувати модель на кількох сотнях розмічених кадрів і стежити за якістю саме на своїх рухах, а не на загальній перевірці.
Своя розмітка стає обов'язковою, коли змінюється об'єкт спостереження або сама метрика. Інвентар у руках, положення кисті під час хвату, темп і амплітуда руху — готова модель такі відмінності не розрізняє: її цільова змінна «де суглоб», а вам потрібно «чи правильно виконано рух». Розмічати доводиться під свою задачу.
Вартість підтримки якості рахується не разово. Розмітка поз — це десятки точок на кадр, узгодженість між розмітниками, частка переперевірки, набір регресійних перевірок за вже закритими випадками й повторне доналаштування на нових даних. Без цього конвеєра якість на своїх рухах просідає за кожної зміни сцени.
Практичне правило просте: спочатку запустити готову модель на своєму записі й розділити помилки на систематичні та випадкові. Систематичні лікує доналаштування, випадкові та «не ті» рухи — лише власний розмічений набір. На короткому пілоті це видно за лічені дні, і рішення спирається на метрику, а не на очікування.
Технічні сумніви: точність, приватність, відмови
Сумніви перед стартом майже завжди ті самі: чи витягне модель на поганому світлі, чи не витече відео, що буде з батареєю на довгій сесії та хто відповідає за якість після запуску. Від відповідей залежить, що ми обчислюємо на пристрої, а що йде на сервер.
Наскільки просідає точність на поганому світлі?
Модель навчаємо на записах із реальних умов — контрове світло, шум сенсора, часткові перекриття. Ключові точки згладжуємо за часом, тому тремтіння камери не дає хибних спрацювань.
Відео йде на сервер?
Кадри обробляються на пристрої й назовні не йдуть — передаються лише координати точок або агреговані метрики. Серверна обробка вмикається точково, за згодою користувача та з шифруванням каналу.
Як довго тримає батарею?
Обчислення йдуть не за кожним кадром: потік розріджується, у модель подається зменшений кадр, між підходами камера вимикається. Нагрівання та витрату вимірюємо на реальних пристроях цільової лінійки.
Хто відповідає за якість після запуску?
Точність просідає не сама по собі, а від зміни умов — новий майданчик, інший одяг, оновлення системи. Тому в постачання входить набір контрольних записів і метрика, за якою просідання видно до скарг користувачів.
Обговоримо задачу: які дані та доступи потрібні для старту
Щоб повернутися з оцінкою робіт і планом впровадження, нам достатньо мінімуму вхідних даних — решту уточнимо по ходу.
Чим точніше описано сценарій, тим менше припущень у кошторисі й тим раніше видно вузькі місця: наприклад, що частина поз нерозрізненна за слабкого світла або що рух занадто швидкий для обробки в реальному часі.
- Сценарій: які рухи та пози розпізнаємо, скільки людей одночасно в кадрі, що відбувається при помилці — підказка, пауза, повтор вправи.
- Цільові платформи та мінімальні версії ОС, перелік моделей пристроїв, на яких застосунок зобов'язаний працювати стабільно.
- Джерело відео: камера в реальному часі, запис із галереї або зовнішній потік. Якщо обчислення йдуть на пристрої (наприклад, на MediaPipe), відео не залишає телефон — це знімає частину питань щодо приватності.
- Референси: застосунки-аналоги, приклади відео з рухами та розбір, що в них подобається, а що не підходить під ваш сценарій.
- Доступи: репозиторій, акаунти магазинів застосунків, тестові збірки та парк пристроїв для перевірки на реальному залізі.
- Обмеження: вимоги до зберігання відео, робота без мережі, витрата батареї та нагрівання корпусу за тривалої сесії.
- Терміни та етапність: чи є жорстка дата, чи потрібен пілот на обмеженій групі користувачів перед релізом.
Надсилайте те, що вже є, — частина пунктів може залишитися відкритою, оцінку та план впровадження зберемо за рештою. Опишіть задачу у вільній формі: повернемося з розбивкою за етапами, термінами та переліком того, що перевіримо на першому прототипі.
