Реализация распознавания изображений в мобильном приложении

Почему распознавание изображений в приложении тормозит и ошибается

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

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

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

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

Что меняется после внедрения: точность, скорость, отказы

До внедрения распознавание в мобильном приложении работает «в целом»: объект на снимке вроде найден, но на кадрах с бликом, под углом или при слабом свете уверенность модели падает, и сценарий уходит на ручную правку. По отраслевым замерам на размеченных наборах точность распознавания по основным классам поднимается с 80–85 до 92–97% — и держится на потоке, а не только на демонстрационной выборке. Эти же данные приводятся в публичных прогонах MLPerf Mobile, то есть речь о воспроизводимой величине, а не об удачном единичном эксперименте.

Скорость обработки снимка становится предсказуемой: ответ по кадру приходит за 0,3–0,6 с прямо на устройстве, без ожидания сети. Это меняет сам сценарий — сотрудник наводит камеру и видит результат, не выходя из рабочего процесса, а очередь снимков обрабатывается параллельно с основной работой.

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

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

Режимы распознавания изображений: на устройстве или на сервере

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

Ниже — три режима в том виде, в каком мы закладываем их в архитектуру.

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

Этапы работ: аудит данных, схема, настройка, приёмка

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

1. Аудит данных. Разбираем архив снимков: объём, условия съёмки, распределение классов, противоречия в разметке. На выходе — карта проблем и понимание, каких примеров не хватает.
2. Подготовка выборки. Убираем дубликаты и битые файлы, дополняем редкие классы, фиксируем отложенную часть выборки, которая не участвует в обучении. Именно она даёт честную оценку результата.
3. Схема решения. Определяем, что считается на устройстве, а что на сервере, как обрабатывается низкая уверенность и что видит пользователь при неудачном распознавании.
4. Настройка и обучение. Дообучаем модель на подготовленных данных и следим за точностью по каждому классу отдельно, а не только за усреднённым показателем.
5. Интеграция в приложение. Встраиваем распознавание в пользовательский сценарий, замеряем время отклика и вес сборки, проверяем поведение при слабой сети и на старых устройствах.
6. Приёмка на реальных условиях. Прогоняем систему на свежих снимках из живого потока, сверяем метрики с зафиксированными в схеме, разбираем каждый класс ошибок.
7. Передача системы. Отдаём конфигурации, скрипты подготовки данных, описание метрик и порядок дообучения на новых примерах, чтобы команда заказчика могла развивать решение сама.

Набор поставки: схемы, политики доступа, регламенты разметки

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

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

Кейс: как сократили ручную проверку фотоснимков в учёте

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

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

Метрики снимали на отложенном наборе и на живом потоке приёмок. Точность распознавания артикула по снимку выросла с 91% до 98,6%, полнота — до 97%, доля снимков, ушедших на ручную проверку, упала с 100% до 7%. Среднее время приёмки партии сократилось с 45 до 6 минут: оператор смотрит не всё подряд, а только конфликтные кадры.

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

Что делать, если уже развёрнута сторонняя система обработки фото

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

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

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

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

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

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

Как распознавание ведёт себя при плохом ракурсе?

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

Как отсекаются ложные срабатывания?

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

Можно ли обработать кадр без отправки на сервер?

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

Обсудим задачу: что учесть до старта работ

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

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

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