Привет, Хабр! На связи команда Lenta tech (ИТ-бренд «Группы Лента»). В 2025 году мы протестировали видеоаналитику полок в восьми супермаркетах Москвы. Стационарные камеры следили за напитками, водой и молочными продуктами: если товар заканчивался, сотрудник получал сигнал и подходил к полке. Технология показала себя отлично, в пилоте это сэкономило до 40% времени, которое раньше уходило на выкладку, и мы начали думать о том, как начать использовать ее еще чаще и получить максимум пользы. Первостепенной задачей, конечно же, оставалась видеоаналитика товаров и цен.

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

1. О нашем роботе пока знают только в Москве (а однажды это решение может оказаться в крупнейших «Гипер Лентах» по всей России);

2. Хакатон до сих пор остается наиболее ярким способом поиска талантов, тех самых CV/ML-инженеров, которые не станут ограничиваться известными методами и смогут предложить удобное и реализуемое решение.

Так мы собрали кейс для Lenta Tech Life Hack. Дальше мы покажем, как устроили задачу: какие данные дали участникам, какой результат хотели увидеть, зачем ввели ограничения и где решения чаще всего ломались после детекции.

Почему это оказалось сложнее, чем просто «найти ценник»

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

Самый частый подход выглядел так:

На этапе детекции ценников решения чаще всего сбоили: цена распознавалась частично, название товара читалось с ошибками, артикул терялся, QR не декодировался, а несколько кадров одного и того же ценника превращались в дубли в итоговой таблице.

Как мы сформулировали задачу для участников

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

Результатом работы пайплайна должен был стать .csv, где каждая строка соответствует одному уникальному ценнику. В ней нужно было заполнить поля с самого ценника: название товара, цены, штрихкод, размер скидки, SKU, дату печати, код зоны выкладки, цвет, координаты рамки и timestamp кадра. Отдельно — извлечь данные из QR-кода: barcode, несколько ценовых полей, оптовые пороги, акционную цену и код акции.

Отдельно мы описали ограничения. В хакатонах часто хочется пойти коротким путем: взять сильный внешний OCR, прогнать через него кадры и быстро собрать демо. В нашем кейсе такой путь не подходил — участникам необходимо было заранее думать о среде для запуска и развертывания модели. Решение должно было представлять собой пайплайн, который можно развернуть в локальном контуре компании с учетом всех внутренних требований к безопасности и контролю над данными. Отсюда возникли два требования: локальный запуск и разумная нагрузка на инфраструктуру. Поэтому нам подходили любые модели и библиотеки с открытым кодом при условии локального развертывания, в отличие от внешних онлайн-сервисов и облачных API. Также приветствовалась оптимизация под rknn int8, то есть под формат, близкий к edge-запуску.

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

Что показал первый тур

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

По технологическому ландшафту распознавания данных картина получилась предсказуемой:

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

Как работает распознавание с видео

Если упростить, задача состоит из нескольких уровней:

1. Видео нужно превратить в набор полезных наблюдений 

Мы заметили у некоторых решений «наивный» подход – взять каждый n-й кадр и прогнать через детектор. Он работает как baseline, но быстро упирается в качество. В одном кадре ценник может быть смазан, в другом – перекрыт товаром, в третьем – хорошо виден, но под углом. Поэтому более устойчивые решения обрабатывали видео как последовательность. Они не пытались угадать лучший кадр сразу, а собирали несколько наблюдений одного и того же ценника. Для этого использовались трекинг, top-K кропов, best-frame scoring и мультикадровая агрегация. 

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

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

2. Ценник нужно найти как объект

На этом этапе чаще всего использовались YOLO/Ultralytics и OpenCV. YOLO брали из-за скорости, зрелой экосистемы и относительно простого запуска. В отдельных решениях встречались и другие детекторы, например RTMDet/MMDetection, но самым популярным остался YOLO-подход.

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

3. Кроп нужно подготовить к чтению

После детекции появляется кроп ценника. Но и он не бывает идеальным. Его нужно повернуть, выровнять, иногда улучшить разрешение, убрать лишние области и подготовить к OCR. Для этого самыми частыми и эффективными методами стали ректификация изображений (Image Rectification) и суперрезолюция (Super-Resolution, SR). Это логично: робот снимает скорее как мобильная камера в реальном магазине, чем продвинутый сканер. Для человека разница между «3» и «8» может быть очевидной даже на смазанном кадре, а OCR легко ошибается. Иногда нескольких пикселей в цифре хватает, чтобы в таблицу попала другая цена.

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

Сильнее всего работала связка: выбрать лучший кадр → выровнять кроп → только потом отдавать его в OCR.

4. OCR читает поля, но не весь ценник целиком

В решениях встречались PaddleOCR, EasyOCR и Tesseract. PaddleOCR стал самым массовым вариантом. Мы заметили важную вещь: один OCR не решает задачу. Можно взять хороший OCR-движок и все равно получить слабую итоговую метрику, если не учитывать структуру ценника. 

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

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

На этом этапе полезны регулярные выражения, правила формата, словари, fuzzy-поиск и бизнес-валидация. Например, цена должна быть похожа на цену, дата – на дату, SKU – на артикул, а не на случайный набор символов.

5. QR и штрихкод помогают восстановить поля, которые OCR читает хуже

Отдельный слой – QR и штрихкоды. QR может содержать поля, которые сложнее или рискованнее читать визуально, поэтому его игнорировать точно нельзя. Если QR удалось декодировать, можно восстановить часть информации более надежно, чем через OCR. Например, barcode, несколько вариантов цены, акционные поля и оптовые пороги. 

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

Лучше думать о QR-коде как о втором источнике данных: OCR читает видимый текст, QR дает структурированные данные, а каталог помогает их сверить.

6. Каталог и SKU превращают OCR в бизнес-данные

Один из самых сильных паттернов в решениях, дошедших до финала – использование каталога, SKU и recovery-логики. Здесь идея тоже простая: распознавание не должно жить отдельно от товарного контекста. Если OCR прочитал название с ошибкой, но рядом есть штрихкод, SKU или фрагмент названия, можно сопоставить результат с каталогом и восстановить более корректное значение.

Это особенно важно для названий товаров. OCR может ошибиться в нескольких символах, перепутать кириллицу и латиницу, потерять часть строки или склеить слова. Но если в каталоге есть близкое название и совпадающий штрихкод, итоговую строку можно восстановить гораздо увереннее.

Поэтому лучший пайплайн собирал гипотезу из OCR, QR и каталога, а затем выбирал наиболее правдоподобный вариант.

Что изменилось в финале

В финале среднее качество выросло на 4,47 п.п. У нескольких команд качество подскочило резко: максимальные приросты по количеству распознанных полей составили +21,27 п.п. и +19,48 п.п. И тут самое интересное – за счёт чего метрика увеличилась. Стали заметно чаще появляться:

• трекинг и выбор лучших кадров;

• top-K кропы и best-frame scoring;

• QR-восстановление;

• каталоговый поиск;

• fuzzy matching;

• sanity-checks;

• crosscheck между OCR, QR и каталогом;

• recovery-логика;

• тесты бизнес-логики и smoke-tests;

• Docker/Compose или похожая упаковка.

Хакатон дал команде целую карту компонентов, из которых можно собирать промышленный MVP.

Что сработало лучше всего

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

Такой подход лучше соответствует природе задачи. Робот снимает один и тот же ценник несколько раз, сам ценник разбит на поля, часть значений зашита в QR, а часть можно проверить по каталогу. Поэтому выигрывает не самый эффектный OCR, а самый аккуратно собранный пайплайн.

 Из конкретных стеков хорошо показали себя:

• YOLO/Ultralytics для детекции – самый распространенный подход к поиску ценников, понятен, достаточно быстр и хорошо встраивается в пайплайн;

• OpenCV для предобработки – без базовой работы с кадрами, поворотами, кропами и геометрией задача быстро разваливается;

• PaddleOCR, EasyOCR и Tesseract как OCR-компоненты – именно как компоненты, а не как все решение целиком;

• QR/штрихкоды как дополнительный источник – способ восстановить структурированные поля и проверить результат OCR;

• Каталог/SKU/fuzzy-поиск – как показала практика, помогают превратить ошибочный OCR-вывод в товарную строку, которую можно сверить с реальными данными;

• Трекинг, top-K и best-frame selection – для движущегося робота это принципиально важнее, чем кажется на старте. Один плохой кадр может определить качество результата.

А что не сработало?

Первое – подход «найдем ценник, а дальше как-нибудь». Он массово встречался в первом туре. Такие решения могли выглядеть убедительно на демо, но в итоговом CSV быстро появлялись пропуски, дубли и ошибочные поля.

Второе – одиночный OCR без валидации. Даже хороший OCR ошибается на смазанных, бликующих и маленьких ценниках. Если после него нет проверки форматов, каталога, QR и восстановления полей, результат быстро становится непредсказуемым.

Третье – тяжеловесные VLM/GPU-контуры без понятной оценки ресурсов для эксплуатации. Больше половины команд финала использовали VLM или мультимодального арбитра, и в сложных случаях это действительно может помочь: модель видит и текст, и визуальную структуру ценника.

Но у такого подхода есть цена: железо, задержка, сложность локального запуска, зависимости, лицензии и воспроизводимость. Поэтому VLM – перспективное направление, но не автоматический путь в production. Для магазина нужно отдельно сравнивать качество с VLM и без него, замерять скорость на CPU/GPU/edge и понимать, сколько будет стоить обработка реального потока видео.

Почему нельзя сразу забрать лучшее решение в production

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

Остается несколько рисков:

• Во-первых, масштабирование. Финальная метрика не гарантирует работу на других камерах, освещении, типах ценников, планограммах и скоростях движения робота.

• Во-вторых, OCR все еще остается главным узким местом. Даже у сильных решений детекция часто выглядит увереннее, чем заполнение конкретных полей в CSV.

• В-третьих, ресурсоемкие модели нужно проверять отдельно. Если решение требует GPU, VLM, крупные индексы или сложную цепочку артефактов, его нужно бенчмаркать не только по качеству, но и по скорости, памяти, стоимости и надежности.

• В-четвертых, проблема воспроизводимости. Для промышленного пилота нужны фиксированные версии весов, каталогов, индексов, checksum, документация и один официальный сценарий запуска. В R&D это часто живет в нескольких конфигах и README, но для эксплуатации этого мало.

• И наконец, нужны лицензии. Часть популярных ML-библиотек и детекторов может иметь ограничения для коммерческого использования. Без проверки лицензий решение может не пройти в промышленный контур, даже если технически оно работает.

Как прошел финал

 Финал прошел в гибридном формате: основная защита состоялась очно в Москве, а часть участников подключалась онлайн. До этого этапа дошли 11 команд и 40 финалистов, которые представили экспертам Lenta Tech свои решения. Команды финалистов разбирали архитектуру своего пайплайна и показывали, как их подход может работать в реальном бизнес-контексте. Также трансляция мероприятия шла онлайн и все участники могли подключиться послушать решения и обсудить их в чате трансляции.

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

Что в итоге дал хакатон

Для нас Lenta Tech Life Hack стал способом собрать свежие идеи и показал, где проходит реальная граница сложности задачи.

До хакатона можно было подумать, что распознавание ценников с видео – это в основном детекция и OCR. После анализа решений стало понятно, что настоящий результат дает только связка видеоаналитики, трекинга, выбора лучших кадров, OCR, QR, каталога и поствалидации.

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