Внедрение распознавания поз (Pose Estimation) в мобильное приложение

Распознавание поз в мобильном приложении: где теряется точность

Распознавание поз в мобильном приложении — это конвейер из трёх звеньев: кадр с камеры, модель, скелет на экране. Точность теряется не в самой модели, а на стыках — между кадром и расчётом, между соседними кадрами, между ожиданиями продукта и бюджетом времени на устройстве. Метрика на тестовом наборе при этом держится, а в руке пользователя скелет дрожит и уезжает.

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

Второй сбой — расхождение видеопотока и модели по времени. Очередь кадров растёт, расчёт идёт по устаревшему кадру, а разметка рисуется поверх текущего: скелет приезжает с задержкой и «плывёт» мимо тела. Для подсчёта повторов это потерянные фазы движения. Лечится отбрасыванием устаревших кадров по метке времени и разделением потока камеры и потока расчёта.

Третье — бюджет слабого устройства. Аппарат не тянет поток, греется и сбрасывает частоту, после чего приложение либо пропускает кадры, либо меняет класс модели на ходу. Мы заранее считаем, сколько времени остаётся на кадр, и задаём предсказуемую деградацию: реже расчёт, интерполяция между позами, честное поведение интерфейса. Разбираем, как это закрывается на практике.

Измеримый эффект: что меняется в продукте после внедрения

Первый эффект виден на глаз — задержка отклика. Пока разметка скелета шла по полному кадру, между движением человека и реакцией интерфейса копилась очередь из нескольких кадров: пользователь отставал от подсказки, а упражнение приходилось начинать заново. После перевода основной ветки на лёгкую модель по ключевым точкам задержка отклика сжалась до одного-двух кадров — интерфейс реагирует почти в момент движения, даже когда человек ускоряется.

Устойчивость к потере кадра — метрика, на которой обычно рассыпается прототип. Раньше один смазанный или перекрытый кадр обнулял историю, и счёт повторений уезжал. Теперь поза восстанавливается по временному окну: пропуск не сбрасывает траекторию, а доля потерянных кадров на быстрых движениях падает с единиц процентов до десятых долей. Замеры в MLPerf Mobile и наши прогоны на живых людях сходятся: лёгкие ветки держат точность там, где тяжёлые уже не успевают за движением.

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

Главное — снижение класса отказов: уходит массовая категория обращений «не распознаёт меня». Кадры с неполной фигурой, боковым светом или человеком, вошедшим в кадр частично, больше не дают ошибку: скелет достраивается по видимым точкам с оценкой достоверности, а спорная поза помечается мягко — предложением поправить положение, а не сообщением о сбое.

Режимы работы модели: на устройстве, в облаке, гибрид

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

Гибрид — не «средний» вариант, а переключаемая схема. Мы закладываем единый набор классов и общую постобработку, чтобы при переходе с облака на устройство точки не «прыгали». Само переключение задаётся условиями: доступность канала, заряд, тип упражнения.

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

Этапы внедрения: от аудита данных до передачи контура

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

1. Аудит данных. Смотрим, как реально снимают пользователи: ракурсы, освещение, перекрытия, длину сессий. На выходе — перечень сценариев, которые решение обязано отработать, и оценка объёма разметки.

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

3. Проектирование контура. Решаем, что считается на устройстве, а что на сервере, как приложение ведёт себя без сети и как обновлять модель, не выпуская новую версию.

4. Настройка модели. Дообучаем на своём корпусе, отдельно проверяем редкие позы и крайние ракурсы, следим, чтобы точность не проседала на слабых устройствах.

5. Оптимизация. Замеряем нагрев, расход батареи и задержку отклика на реальных аппаратах: точность, из-за которой телефон греется, в продукт не идёт.

6. Приёмочная проверка. Прогоняем согласованный набор сценариев и метрик, проверяем плохой свет и обрыв сети. Расхождение с порогом — возврат на нужный этап, а не «доработка на глаз».

7. Передача контура. Отдаём интеграционный код, схему контура, скрипты разметки и обучения, документацию по обновлению модели и чек-лист диагностики, обучаем команду заказчика.

Состав поставки: конфигурации моделей, схемы потоков, регламенты

Передаём не демонстрационный прототип, а рабочую поставку, с которой команда сопровождения живёт без нас. Каждый артефакт привязан к своему сценарию: обучение на новых данных, выкат обновления, откат, разбор инцидента на устройстве заказчика. Ниже — что физически остаётся у вас в репозитории и в базе знаний после сдачи.

• Конфигурации модели: веса, пороги уверенности по ключевым точкам, настройки входного разрешения кадра. К каждому параметру — комментарий, что он меняет и на какой метрике отражается: доля ложных срабатываний, устойчивость к частично перекрытому телу, работа в слабом освещении.
• Схемы потоков данных: от захвата кадра до выходного скелета. Отмечено, где стоит буфер, где кадры отбрасываются при нехватке времени на обработку, что происходит при просадке частоты съёмки и как ведёт себя очередь под нагрузкой.
• Политики доступа: какие модули приложения обращаются к модели, что уходит на серверную часть, а что считается на устройстве. Отдельно — правила работы с видеопотоком пользователя: где он хранится, чем маскируется, когда удаляется.
• Регламент обновления модели: полный цикл — разметка новых записей, дообучение, проверка на эталонном наборе, постепенная выкатка на долю пользователей. С критериями отката: если целевая метрика просела, предыдущая версия возвращается одной командой.
• Эталонный набор для регрессии: записи с заранее размеченным результатом, на которых прогоняется каждая новая сборка. Позволяет ловить деградацию до релиза, а не по жалобам в поддержке.
• Профили по классам устройств: где модель считает кадры в реальном времени, где переключается на облегчённый вариант, а где логика деградирует до анализа отдельных кадров вместо потока.
• Документация сопровождения: карта модулей, точки расширения под новые типы движений, перечень известных ограничений и инструкция для дежурного инженера — что проверять в первую очередь, когда метрики расходятся с ожиданиями.

Кейс внедрения: метрики до и после на реальной нагрузке

Кейс внедрения — приложение-тренер для домашних занятий: камера телефона отслеживает позу, а система подсказывает, верно ли выполняется упражнение. На входе доля верных поз на тестовой выборке держалась около 68%, время отклика на смену положения — порядка половины секунды. На быстрых движениях скелет «дрожал», приседание засчитывалось как провал, и пользователи бросали тренировку на середине.

Что изменили в модели и обработке

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

Добавили сглаживание ключевых точек по последовательности кадров и отдельные пороги уверенности для статичных и динамичных упражнений: скелет перестал «дёргаться», а система научилась различать паузу между повторениями и завершённое движение.

Метрики до и после

Доля верных поз на той же выборке выросла с 68% до 94%, время отклика сократилось до десятых долей секунды. Замеры сверяли с эталонными разметками открытого набора COCO, поэтому цифры сопоставимы между релизами и не зависят от того, кто именно прогонял тест.

Побочный эффект — доля доведённых до конца тренировок поднялась с 41% до 73%. Считаем не «на глаз»: фиксированная выборка, прогон на трёх классах устройств, отчёт с распределением ошибок по типам упражнений и регресс-тест на каждом релизе — при следующем обновлении метрики не поедут вниз незаметно.

Нужна ли своя разметка, если готовая модель уже работает?

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

Донастройка закрывает смещение, но не меняет природу задачи. Если ваши движения — вариация общей задачи (тот же человек, та же проекция, другая одежда или ракурс), достаточно донастроить модель на нескольких сотнях размеченных кадров и следить за качеством именно на своих движениях, а не на общей проверке.

Своя разметка становится обязательной, когда меняется объект наблюдения или сама метрика. Инвентарь в руках, положение кисти при хвате, темп и амплитуда движения — готовая модель такие различия не различает: её целевая переменная «где сустав», а вам нужно «правильно ли выполнено движение». Размечать приходится под свою задачу.

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

Практическое правило простое: сначала прогнать готовую модель на своей записи и разделить ошибки на систематические и случайные. Систематические лечит донастройка, случайные и «не те» движения — только собственный размеченный набор. На коротком пилоте это видно за считанные дни, и решение опирается на метрику, а не на ожидание.

Технические сомнения: точность, приватность, отказы

Сомнения перед стартом почти всегда одни и те же: вытянет ли модель на плохом свете, не утечёт ли видео, что будет с батареей на длинной сессии и кто отвечает за качество после запуска. От ответов зависит, что мы считаем на устройстве, а что уходит на сервер.

Видео уходит на сервер?

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

Как долго держит батарею?

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

Кто отвечает за качество после запуска?

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

Обсудим задачу: какие данные и доступы нужны для старта

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

• Сценарий: какие движения и позы распознаём, сколько человек одновременно в кадре, что происходит при ошибке — подсказка, пауза, повтор упражнения.
• Целевые платформы и минимальные версии ОС, перечень моделей устройств, на которых приложение обязано работать стабильно.
• Источник видео: камера в реальном времени, запись из галереи или внешний поток. Если счёт идёт на устройстве (например, на MediaPipe), видео не покидает телефон — это снимает часть вопросов по приватности.
• Референсы: приложения-аналоги, примеры видео с движениями и разбор, что в них нравится, а что не подходит под ваш сценарий.
• Доступы: репозиторий, аккаунты магазинов приложений, тестовые сборки и парк устройств для проверки на реальном железе.
• Ограничения: требования к хранению видео, работа без сети, расход батареи и нагрев корпуса при длительной сессии.
• Сроки и этапность: есть ли жёсткая дата, нужен ли пилот на ограниченной группе пользователей перед релизом.

Присылайте то, что уже есть, — часть пунктов может остаться открытой, оценку и план внедрения соберём по остальным. Опишите задачу в свободной форме: вернёмся с разбивкой по этапам, сроками и перечнем того, что проверим на первом прототипе.