Офлайн OCR на складе: как это работает без облака

Что такое on-device OCR в операциях склада

Речь не про «распознать любой документ в облаке», а про чтение кодов и этикеток в привычном интерфейсе сотрудника.

On-device OCR — это пайплайн, в котором кадр с камеры телефона обрабатывается на самом устройстве: детекция области этикетки, распознавание символов или кода, сопоставление с правилами сценария и подсветка результата в UI мобильного приложения сотрудника (МПС).

В продуктовом контуре Zorky логика распознавания поставляется как часть SDK: команде заказчика не нужно обучать CV-модель с нуля. Задача интеграции — встроить модуль в существующее МПС и связать callback с вашим экраном поиска или инвентаризации.

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

Чем это отличается от «сканер в камере»

Простой скан штрихкода закрывает часть задач, но на складе часто встречаются повреждённые этикетки, нестандартная вёрстка и сценарии, где сотрудник ищет не «любой код», а совпадение с конкретным заказом или артикулом. On-device CV рассчитан на такие операционные сценарии, а не на замену всех ТСД разом.

Почему облачный OCR плохо ложится на склад

Облачный OCR подразумевает: кадр уходит на сервер, приходит ответ. На складе это ломается сразу по нескольким осям.

• Сеть — в зоне стеллажей и в подсобках покрытие нестабильно; каждый кадр как сетевой запрос превращает поиск в очередь на «подвисший» экран.
• Задержка — даже при связи RTT и очередь сервиса добавляют секунды; в операциях «найти и взять» это ощущается как торможение процесса.
• Данные — выгрузка кадров в облако меняет модель угроз и объём согласований с ИБ. Для многих сетей это лишний контур, если задачу можно решить локально.
• Стоимость и квоты — поток кадров со смены сотрудников — это не редкий документ, а непрерывный рабочий инструмент.

Когда облако всё же уместно

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

Как модель живёт на телефоне

Детали размеров и min OS уточняются на техдемо; ниже — архитектурный принцип без выдуманных цифр.

Модели для on-device сценариев подбираются компактными: они должны укладываться в память устройства и давать приемлемую задержку на типичных телефонах сотрудников. Конкретные размеры артефактов и требования к устройству уточняются на техдемо — публично мы не фиксируем minSdk, объём AAR и вес модели без подтверждения команды.

На Android распознавание опирается на нативный слой камеры и ускорения инференса (в архитектуре SDK — CameraX и NNAPI). На iOS — AVFoundation и Core ML / Vision. Общая бизнес-логика сценария живёт в Kotlin Multiplatform-модуле, чтобы Android и iOS не расходились правилами.

Обновление модели

Поставка и обновление модели — часть процесса релиза SDK. Канал доставки, целостность сборки и политика обновлений обсуждаются с командой МПС и ИБ на брифинге. Не стоит ожидать «тихого» обновления из произвольного облака без согласования контура заказчика.

Что синхронизируется, когда появляется сеть

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

Если площадка полностью без связи, распознавание продолжает работать локально. Синхронизация агрегатов — отдельный канал: его можно отложить, ограничить или согласовать под offline-first политику. Операционный разбор сценария склада — на посадочной «Склад без сети».

Что не должно блокировать UI

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

Практика внедрения на площадке

Интеграционный контур и роли команд описаны в материале про SDK для МПС. Для ИБ отдельно полезен разбор data flow на странице приватности — но для склада ключевой тезис один: инференс не требует сети.

1. Выбрать 1–2 сценария (например, поиск по коду на этикетке или инвентаризация участка).
2. Встроить SDK в тестовую сборку МПС вместе с командой заказчика.
3. Прогнать ограниченный запуск на согласованной площадке.
4. Сверить метрики и UX с критериями успеха; публикация цифр — только после согласования.

TODO: проверить у команды актуальные требования к устройству и канал обновления моделей перед фиксацией в договоре.

Типовые сбои и как их закладывать в UX

Даже при on-device OCR сценарий склада включает сбои, которые нельзя сваливать на «плохую модель». Этикетка затёрта, блик от лампы, сотрудник держит телефон слишком близко, код частично закрыт скотчем. Хороший UX заранее показывает, что делать: отодвинуть камеру, сменить угол, включить фонарик, перейти к ручному вводу.

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

На этапе техдемо полезно пройти чеклист среды: освещение стеллажа, высота этикеток, типы упаковки, доля повреждённых кодов. Это не бенчмарк «accuracy 99%», а карта рисков площадки. Цифры качества, если появятся, остаются во внутреннем отчёте до согласования публикации.

• Заложить fallback на ручной ввод в том же экране.
• Логировать технические статусы без записи кадров.
• Не смешивать «не распознано» и «нет сети» в одном сообщении пользователю.

Связь смены и поддержки

Если смена видит частые пустые результаты, нужен канал эскалации: фото этикетки в тикет поддержки площадки (уже вне контура Zorky) или вызов наставника. Продукт ускоряет поиск, но не заменяет операционный менеджмент качества маркировки.

Связь с ИБ и операциями

Для операций выгода on-device очевидна: поиск не останавливается без LTE. Для ИБ — другой плюс: кадры не становятся обязательным облачным потоком. Но конфигурация заказчика может добавить поля в синк. Именно поэтому data flow фиксируют на ИБ-брифинге, а не «по умолчанию из лендинга».

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

Итог: офлайн OCR на складе — это сочетание компактной модели на телефоне, встраивания в МПС и дисциплины вокруг того, что синхронизируется. Технические размеры моделей и требования к ОС остаются предметом техдемо, а не маркетингового абзаца. Командам полезно читать этот материал вместе со страницей SDK и офлайн-посадочной, чтобы не плодить противоречивые ожидания.

Перед пилотом согласуйте: какие устройства допускаются, кто обновляет сборку МПС, как фиксируются наблюдения смены. Без этого даже идеальный on-device пайплайн останется демонстрацией на чужой полке.