Задача распознавания ценников с видео, снятого на движущегося робота в магазине, разбивает наивный пайплайн «детекция + OCR» в ноль. Смаз от движения, блики на глянцевой бумаге, дубликаты кадров и десятки форматов ценников превращают академические 95% accuracy в бизнес-провал. На хакатоне Lenta Tech команды столкнулись с реальными условиями: робот движется по проходу, камера снимает под углом, освещение меняется от стеллажа к стеллажу. Результат распознавания должен попасть в систему контроля выкладки, где ошибка в цене или названии товара - это штраф для ритейлера.
Решение - многоэтапный пайплайн, который компенсирует дефекты съёмки и добавляет избыточность для валидации. Семь последовательных стадий: детекция ценников, трекинг в видеопотоке, выбор лучшего кадра для каждого экземпляра, ректификация геометрии с повышением разрешения, зональный OCR, декодирование QR-кода как второго источника данных и финальная кросс-проверка через каталоговый поиск с fuzzy-сопоставлением. Каждый этап решает конкретную проблему, а связка QR + каталог даёт бизнес-метрики, на которые можно опираться при промышленном внедрении.
Этот материал - практическое руководство для ML-инженеров и продакт-менеджеров, которые проектируют видеоаналитику в ретейле. Разбираем архитектуру пайплайна, ограничения edge-развёртывания (rknn int8, лицензионная чистота библиотек) и критерии, по которым заказчик принимает результат.
Почему простая детекция + OCR не работает на видео с робота
Условия съёмки на реальном объекте разрушают базовые допущения, на которых строятся бенчмарки OCR. Робот движется со скоростью 0.5-1 м/с, камера закреплена на подвижной платформе - вибрация и инерция дают смаз даже при короткой выдержке. Ценники напечатаны на глянцевой бумаге, и при определённом угле падения света от стеллажных ламп половина кадра засвечена бликом. Один и тот же ценник попадает в кадр 15-20 раз, пока робот проезжает мимо, и только 2-3 кадра из этой серии пригодны для распознавания. Добавьте к этому пять форматов ценников в одном магазине: стандартные 60x40 мм, крупные акционные стикеры, желтые ценники с перфорацией, термоэтикетки с весового оборудования и узкие полоски на торце полки.
Наивный подход - взять YOLOv8 для детекции и Tesseract для OCR - даёт около 60-70% правильно распознанных ценников в таких условиях. Для бизнеса это означает, что каждый третий ценник потребует ручной проверки оператором. При масштабе сети в сотни магазинов и частоте обновления раз в неделю ручная валидация съедает весь выигрыш от автоматизации. Детальный разбор того, как строятся production-пайплайны с quality gates и обратной связью, мы давали в статье о четырёх этапах пайплайна RAG - принцип многоуровневой валидации универсален.
Ключевые проблемы, которые ломают простой пайплайн:
- Смаз и расфокус. Движение робота и вибрация платформы делают часть кадров нечитаемыми. Мелкий текст на ценнике (6-8 pt) размывается до полной неразличимости символов.
- Блики. Глянцевая поверхность ценника работает как зеркало для стеллажного освещения. Локальная засветка маскирует 20-40% площади, часто попадая на поле с ценой.
- Дубликаты кадров. Один физический ценник присутствует на 15-20 кадрах. Без трекинга система выдаст 15 противоречивых результатов для одного стикера.
- Вариативность форматов. Разные размеры, ориентация, расположение полей. Модель, обученная на одном формате, проваливается на других.
- Ошибки OCR на границах полей. Название товара «заезжает» на поле цены, артикул путается с весом - без зонирования потери точности достигают 15-20%.
Хакатон Lenta Tech дал командам именно такие исходные данные: видео с робота, несколько форматов ценников, требование выдать структурированный результат с названием, ценой и артикулом. Решения, пытавшиеся обойтись одной моделью, показали accuracy ниже 70%. Победители выстроили пайплайн из семи этапов - его архитектуру и разбираем дальше.
Архитектура промышленного пайплайна: 7 этапов от видео до валидных данных
Пайплайн проектируется как конвейер, где каждый этап получает на вход выход предыдущего и добавляет свой уровень очистки данных. Связность этапов критична: сбой на ранней стадии каскадно разрушает всё последующее распознавание. Семь стадий выглядят так:
- Детекция ценников - находим все ценники на кадре, определяем bounding box и класс формата.
- Трекинг - связываем детекции одного физического ценника между кадрами, присваиваем уникальный ID.
- Выбор лучшего кадра - для каждого ID отбираем кадр с максимальной читаемостью по метрикам резкости и отсутствия бликов.
- Ректификация и суперрезолюция - выравниваем геометрию кропа и повышаем разрешение мелкого текста.
- Зональный OCR - разбиваем ценник на смысловые зоны и распознаём каждую отдельно.
- Декодирование QR - извлекаем артикул или ссылку из QR-кода как эталонный идентификатор.
- Каталоговая валидация - сверяем OCR-результат с каталогом товаров через fuzzy-поиск и кросс-проверку полей.
Эта архитектура избыточна с точки зрения академической метрики - на чистых сканах документов хватило бы первых двух этапов. В условиях реального магазина избыточность становится необходимостью: каждый этап закрывает свой класс ошибок, и только их комбинация выводит accuracy на уровень, пригодный для бизнес-использования. О том, как аналогичный подход к многоэтапной валидации работает в document understanding, читайте в нашем разборе открытых OCR-моделей 2026 года.
Детекция ценников и трекинг: как не потерять ни один стикер
Детектор ценников - это YOLOv8-m, дообученный на датасете из пяти форматов ценников, характерных для сети «Лента». Размер модели выбран как компромисс между точностью (mAP@0.5 около 0.94 на тестовой выборке) и скоростью инференса (25-30 FPS на NVIDIA Jetson Orin Nano в FP16). Модель детектирует bounding box и классифицирует формат ценника: стандартный, акционный, весовой, узкий полочный, термоэтикетка. Класс формата используется на этапе зонального OCR для выбора правильного шаблона разбиения.
Трекинг реализован через ByteTrack - легковесный трекер, который связывает детекции по IoU и Kalman-фильтру без пересчёта эмбеддингов. Выбор ByteTrack обусловлен скоростью: на edge-устройстве каждый миллисекундный каскад имеет значение. Трекер присваивает уникальный ID каждому ценнику и ведёт его от первого появления в кадре до выхода из зоны видимости. На выходе получаем треклет - последовательность кадров с одним ID.
Проблема перекрытий решается через порог IoU 0.5: если два ценника перекрываются более чем наполовину, более старый трек сохраняет приоритет. Ложные срабатывания отсекаются минимальной длиной треклета - ценник должен присутствовать минимум на 5 кадрах, чтобы попасть в обработку. Это отсекает случайные детекции на текстуре упаковки и бликах.
Выбор лучшего кадра: избавляемся от смаза и бликов
Для каждого треклета вычисляются три метрики качества на каждом кадре. Резкость оценивается через дисперсию лапласиана (Laplacian variance) - пороговое значение 100 отделяет читаемые кадры от смазанных. Наличие бликов детектируется анализом гистограммы в верхнем квартиле яркости: если более 15% пикселей кропа имеют яркость выше 240, кадр считается засвеченным и штрафуется. Угол съёмки оценивается через соотношение сторон bounding box: сильное отклонение от ожидаемого aspect ratio формата ценника говорит о съёмке под острым углом.
Итоговая метрика - взвешенная сумма трёх компонент с весами 0.5 на резкость, 0.3 на отсутствие бликов и 0.2 на угол. Для каждого ID сохраняется кадр с максимальной метрикой. Этот подход отсекает 80-85% кадров треклета и оставляет один, наиболее пригодный для OCR. На выходе этапа получаем набор уникальных ценников с одним кропом на каждый.
Ректификация и суперрезолюция: готовим кроп для OCR
Кроп ценника с выбранного кадра редко бывает идеально фронтальным. Угол съёмки и перспективные искажения превращают прямоугольный ценник в трапецию, что снижает точность OCR на 10-15%. Ректификация решает эту проблему через поиск четырёх углов ценника внутри bounding box с помощью легковесного keypoint-детектора (MobileNetV2 + регрессия координат) и применения гомографии для выравнивания.
После выравнивания мелкий текст - артикул, вес, состав - часто остаётся на грани читаемости. Суперрезолюция повышает разрешение кропа в 2-4 раза. Используется облегчённая версия ESRGAN, оптимизированная под int8-квантизацию для edge-устройств. Модель обучена специально на тексте мелкого кегля (6-10 pt) и показывает прирост accuracy OCR на 8-12% по сравнению с бикубической интерполяцией. Инференс на Rockchip RK3588 в rknn int8 занимает 40-60 мс на кроп 200x300 пикселей - приемлемо для пайплайна, где на ценник отводится 200-300 мс общего бюджета.
Зональный OCR: извлекаем текст по шаблону
Ценник - это структурированный документ с фиксированным расположением полей внутри каждого формата. Зональный подход разбивает кроп на смысловые области: название товара, цена, цена за единицу, артикул, вес, акционная информация. Разбиение выполняется по шаблону, привязанному к классу формата, который определил детектор на первом этапе. Шаблон задаёт относительные координаты зон и их ожидаемый тип данных.
OCR применяется к каждой зоне отдельно через PaddleOCR - выбран за скорость на CPU (ONNX Runtime) и лицензию Apache 2.0, критичную для промышленного внедрения. Зонирование даёт два преимущества. Первое - контекстная валидация: в зоне цены допустимы только цифры, точка и знак рубля, любая буква сигнализирует об ошибке распознавания. Второе - снижение путаницы между полями: артикул не попадёт в название, вес не смешается с ценой. Общий прирост accuracy от зонального подхода составляет 12-18% по сравнению со сплошным OCR всего кропа.
Второй источник данных: декодирование QR-кодов
Значительная часть ценников в крупных сетях содержит QR-код с артикулом товара или ссылкой на карточку в каталоге. Этот код - эталонный идентификатор, который не зависит от качества съёмки и ошибок OCR. Декодирование выполняется библиотекой ZBar (лицензия LGPL, допустима для внутреннего использования без раскрытия кода) параллельно с OCR.
QR-код на ценнике обычно расположен в правом нижнем углу, его размер 15x15 мм. Даже при частичном повреждении или блике ZBar восстанавливает данные благодаря избыточности кодирования Рида-Соломона. Выход декодирования - строка с артикулом или URL, из которого артикул извлекается регулярным выражением. Этот идентификатор становится ключом для точного поиска в каталоге на этапе валидации.
Случаи отсутствия QR-кода - около 20-30% ценников, в основном весовые этикетки и узкие полочные форматы - обрабатываются через fallback на fuzzy-поиск только по названию. Наличие QR резко повышает уверенность в результате: точное совпадение артикула с каталогом даёт confidence 0.95+, тогда как fuzzy-поиск по названию - 0.7-0.85 в зависимости от уникальности наименования.
Поствалидация: каталоговый поиск и кросс-проверка полей
Финальный этап пайплайна сверяет распознанные данные с эталонным каталогом товаров. Каталог загружается локально на edge-устройство как SQLite-база с полями: артикул, название, цена, вес, категория. Объём каталога для стандартного супермаркета - 15-30 тысяч SKU, что умещается в 50-80 МБ и не требует сетевых запросов.
Стратегия валидации двухуровневая. Если QR-код дал артикул, выполняется точный lookup в каталоге - это занимает доли миллисекунды и даёт однозначный результат. Для ценников без QR запускается fuzzy-поиск по названию товара через RapidFuzz (лицензия MIT) с порогом схожести 85%. RapidFuzz вычисляет нормализованное расстояние Левенштейна и возвращает топ-3 кандидатов из каталога. Если схожесть с лучшим кандидатом выше 90% и цена из OCR совпадает с каталожной в пределах допустимой дельты (5% для учёта акций и региональных отклонений), результат принимается автоматически.
Кросс-проверка полей добавляет ещё один уровень защиты. Цена из OCR сравнивается с ценой из каталога. Вес из OCR сверяется с каталожным. Если QR дал артикул, но цена из OCR расходится с каталогом более чем на 5%, система помечает ценник флагом «требует проверки» - возможно, цена не обновлена на стеллаже. Это и есть бизнес-метрика: не просто «распознано правильно», а «распознано и соответствует актуальным данным». Стратегия разрешения конфликтов: при наличии QR приоритет у каталожных данных, при отсутствии QR и схожести названия 85-90% - ручная проверка оператором.
Промышленное внедрение: edge, лицензии и бизнес-метрики
Развёртывание пайплайна в магазине накладывает жёсткие ограничения, которые не видны на этапе прототипирования. Облачные сервисы исключены: видеопоток с 4-8 камер робота генерирует 50-100 Мбит/с, и передача этого объёма в облако через WiFi магазина нестабильна и дорога. Локальный запуск на edge-устройстве - единственный практичный вариант.
Целевое железо - Rockchip RK3588 или NVIDIA Jetson Orin Nano. Обе платформы имеют NPU для инференса нейросетей и достаточный CPU-ресурс для OCR и fuzzy-поиска. Модели детекции, keypoint-детектора и суперрезолюции конвертируются в формат rknn int8 через toolkit Rockchip. Квантизация в int8 снижает точность детекции на 1-2% mAP, но ускоряет инференс в 3-4 раза по сравнению с FP16. Замеры на RK3588: детекция YOLOv8-m int8 - 12 мс, keypoint-детектор - 8 мс, суперрезолюция ESRGAN-tiny int8 - 45 мс. Суммарное время на один ценник - около 150 мс, что позволяет обрабатывать поток 6-7 ценников в секунду на одном устройстве.
Лицензионная чистота библиотек - критичное требование для ритейлера с юридическим отделом. Пайплайн собран из компонентов с разрешительными лицензиями: PaddleOCR (Apache 2.0), ONNX Runtime (MIT), RapidFuzz (MIT), ZBar (LGPL - допустима для внутреннего использования, не требует открытия кода продукта). Модели обучаются на собственных данных или публичных датасетах с явно указанной лицензией. Отказ от GPL-библиотек и моделей с неясным происхождением страхует от юридических рисков при масштабировании на сотни магазинов.
Бизнес-метрики, по которым заказчик оценивает результат, отличаются от академических. На хакатоне Lenta Tech ключевыми были:
- Доля полностью распознанных ценников - все поля (название, цена, артикул) извлечены и прошли валидацию. Целевое значение - 85%+.
- Количество корректировок вручную - ценники, требующие проверки оператором. Заказчик готов терпеть 10-15% ручной работы, но не 30%+.
- Время обновления стеллажа - от проезда робота до появления данных в системе контроля выкладки. Целевое значение - менее 5 минут на стеллаж.
- Ложные срабатывания по цене - самая дорогая ошибка. Ценник с неверной ценой, прошедший валидацию, ведёт к штрафу. Допустимый уровень - менее 0.5%.
Пайплайн, выстроенный по описанной архитектуре, на хакатоне показал 87% полностью распознанных ценников и 0.3% ошибок в цене. Это уровень, при котором автоматизация окупается: сокращение ручного аудита на 70% при сохранении качества данных, достаточного для compliance-проверок. Подходы к автоматизации через AI-агентов, аналогичные тем, что мы разбирали в кейсе Microsoft Fara1.5-27B, подтверждают тренд на перенос сложной логики принятия решений на edge-устройства.
Практический вывод для команд, которые проектируют похожие системы: не оптимизируйте один этап до идеала. Распределите бюджет точности по всему пайплайну. Хороший трекинг и выбор кадра дают больше прироста, чем замена OCR-движка. Избыточность в виде QR и каталога - не дополнительная фича, а страховка от краевых случаев, которые в production возникают постоянно. И главное - договаривайтесь о бизнес-метриках до начала разработки. Accuracy 95% на тестовом датасете не впечатляет заказчика, если каждый двадцатый ценник в магазине показывает чужую цену.