Идея. Классические декодеры штрихкодов (ZXing, ZBar) быстры и бесплатны, но «слепнут» на реальных снимках — при дефектах печати, деформации упаковки, тенях, бликах и смазывании. Коммерческие SDK (Scandit, Dynamsoft) эти проблемы решают, но стоят дорого и закрыты. Идея проекта — не заменять классический декодер нейросетью, а достраивать его нейросетевым «вторым эшелоном»: код сначала пытаются прочесть обычным способом, и только если это не удалось, включается искусственный интеллект, который находит код на кадре, вырезает его и восстанавливает повреждённую модульную структуру до состояния, пригодного для чтения тем же стандартным декодером.

Краткое описание. Разработано веб-приложение с гибридной клиент-серверной архитектурой для распознавания QR-кодов и DataMatrix. Клиентская часть (Vue 3 + Quasar) захватывает кадр с камеры устройства или принимает загруженный файл и выполняет первичное декодирование прямо в браузере библиотекой @zxing/browser — без обращения к серверу и без задержки. При неудаче и включённом «умном режиме» кадр уходит на сервер (Python, FastAPI), где отрабатывает каскадный конвейер:

локализация (YOLO26-nano) → декодирование фрагмента → коррекция (U-Net + ResNet50) → финальное декодирование

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

Научно-технические задачи (решены в рамках работы):

1. Подготовка данных. Автоматизация подготовки, очистки и балансировки датасетов изображений штрихкодов. Исходная коллекция (~12 000 фотографий чеков и маркированных товаров от предприятия-партнёра) оказалась непригодной для прямого обучения: разнородное разрешение, дисбаланс классов, нечитаемые кадры. Разработаны:
   • метод синтетической генерации образцов DataMatrix на основе реальных QR-кодов с сохранением перспективы и фона (компенсация дисбаланса: 3 000 синтетических QR и 6 000 DataMatrix);
   • метод каскадного автоматического аннотирования ансамблем классических декодеров (zxing-cpp → pyzbar → pylibdmtx → OpenCV QRCodeDetector) с предварительным CLAHE, гарантирующий достоверность разметки. Из 20 249 изображений достоверную разметку получили 15 078.
2. Локализация. Дообучение легковесной модели семейства YOLO (YOLO26-nano, вход 640×640, два класса — QR и DataMatrix) для точного и быстрого выделения области штрихкода и изоляции его от фонового шума (текст чека, элементы упаковки, посторонние объекты).
3. Коррекция. Обучение модели сегментации и восстановления на базе U-Net с энкодером ResNet50 (вход 384×384), переводящей повреждённый фрагмент в бинарную маску модулей. Для неё разработана составная функция потерь: L = w_bce·L_BCE + w_dice·L_Dice + w_edge·L_Edge + w_ssim·L_MS-SSIM (веса 1,0 / 1,0 / 1,0 / 0,5), объединяющая бинарную кросс-энтропию, двустороннюю меру Дайса (по модулям и по фону), граничный член на основе оператора Собеля и многомасштабную меру структурного сходства MS-SSIM.
4. Интеграция. Объединение нейросетевых модулей и алгоритмов обработки в веб-приложение с гибридной архитектурой и его развёртывание в контейнеризированной среде (Docker, docker-compose).

• считывание повреждённой маркировки с деформированной упаковки без ручного ввода кода;
• распознавание кода по фотографии из галереи без установки отдельного мобильного приложения;
• массовая (пакетная) обработка накопленных изображений из папки;
• ведение истории сканирований с возможностью разбора каждого случая;

Раздел пакетной обработки. Массовое распознавание изображений из выбранной папки. Для каждого файла последовательно применяется клиентское декодирование, а при неудаче серверный конвейер. По ходу работы отображается прогресс и сводная статистика с разбивкой по этапам: сколько кодов прочитал браузерный декодер, сколько потребовало локализации YOLO, сколько восстановила U-Net и сколько осталось нераспознанными. Это делает раздел ещё и инструментом экспериментальной оценки.

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

Краткосрочные (техническая оптимизация):

• Экспорт моделей в ONNX — ускорение инференса и существенное уменьшение размера Docker-образа за счёт отказа от тяжёлых зависимостей PyTorch;
• квантование и дистилляция моделей для инференса непосредственно на мобильных устройствах — часть конвейера уходит на клиент, серверная нагрузка падает ещё сильнее;
• миграция на PostgreSQL и переход к нескольким рабочим процессам инференса для горизонтального масштабирования.

Среднесрочные (расширение функциональности):

• расширение набора поддерживаемых форматов штрихкодов (Aztec, PDF417, линейные коды EAN/Code128);
• увеличение объёма реальных обучающих данных, в том числе за счёт кадров, накопленных самой системой в разделе статистики, — заложен естественный контур дообучения;
• модуль геометрической ректификации (устранение сильных перспективных искажений перед коррекцией) — по результатам анализа именно они остаются основной причиной оставшихся отказов;
• расширение API: пакетный серверный эндпоинт, вебхуки, аутентификация и разграничение доступа.

Долгосрочные (продуктовые и интеграционные):

• интеграция с корпоративными системами предприятий — CRM, WMS, ERP через расширенный программный интерфейс; это основной путь монетизации и практического внедрения;
• прямая интеграция с национальной системой маркировки для валидации кодов маркировки;
• поставка в виде self-hosted-решения или SaaS с тарификацией по объёму обращений к нейросетевому контуру;
• вынесение обученных моделей в отдельный сервис инференса, переиспользуемый другими продуктами предприятия.

Актуальность

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

При этом в контролируемых условиях (равномерное освещение, планарная поверхность, высокое разрешение сенсора) распознавание — рутинная задача для классических библиотек, а в реальных производственных и торговых условиях оптическое считывание сталкивается с деформацией носителя, недостаточным или контрастным освещением, тенями, бликами и смазыванием из-за движения объекта или дрожания камеры. Разрыв между лабораторными и полевыми условиями — и есть предмет проекта. Количественно он измерен в работе: базовый декодер справляется менее чем с половиной реальных снимков (46,56 %).

Экономическая полезность

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

• Архитектурная разгрузка. Гибридная схема сама по себе является механизмом масштабирования: подавляющее большинство кадров декодируется в браузере пользователя и вообще не создаёт серверной нагрузки. Вычислительные ресурсы сервера расходуются только на «трудные» кадры — на тестовой выборке это составило около 53 % изображений, а до самого дорогого этапа (коррекции) дошло лишь 21 %.
• Каскадность конвейера. Каждый последующий, более затратный этап запускается только при неудаче предыдущего — стоимость обработки среднего запроса значительно ниже стоимости полного прохода.
• Контейнеризация. Docker и docker-compose обеспечивают воспроизводимое развёртывание; серверный контейнер по обработке запросов не хранит состояние, что допускает запуск нескольких реплик за балансировщиком.
• Гибкость по оборудованию. Сборка с CPU-версией PyTorch позволяет разворачивать систему на серверах без GPU; при наличии видеокарты автоматически задействуется CUDA. Это даёт вертикальное масштабирование «снизу вверх» без изменения кода.
• Экономичность по памяти. 1,5 ГБ видеопамяти при обеих загруженных моделях — на одну видеокарту помещается несколько экземпляров сервиса.

Способность к взаимодействию с другими системами

• REST API как основной контракт. Все функции доступны через HTTP-интерфейс с JSON, включая распознавание, историю, сведения о моделях и проверку работоспособности. Это стандартный, языко-независимый способ интеграции.
• Автогенерируемая спецификация OpenAPI (/docs) позволяет любой внешней системе получить машиночитаемое описание интерфейса и сгенерировать клиент автоматически — на любом языке.
• Валидация через Pydantic гарантирует строгие контракты запросов и ответов.
• Эндпоинт /health штатно интегрируется с системами оркестрации (Kubernetes, Docker Swarm) и мониторинга.
• Целевые интеграции — CRM, WMS и ERP предприятий; система изначально проектировалась как встраиваемый сервис распознавания, а не как замкнутое приложение. Клиентское веб-приложение при этом остаётся необязательным: предприятие может использовать только серверный API.

Мобильность

• Кроссплатформенность без установки. Система работает в любом современном браузере — на смартфоне, планшете, ноутбуке. Пользователю не нужно устанавливать приложение, проходить модерацию магазинов приложений или обновлять версии.
• Доступ к камере реализован через стандартный браузерный интерфейс getUserMedia, поддерживаемый всеми актуальными мобильными браузерами.
• Адаптивный интерфейс на базе Quasar — библиотеки, ориентированной на мобильные форм-факторы.
• Переносимость развёртывания. Контейнеры одинаково запускаются на локальном сервере предприятия, в частном облаке и у публичного провайдера; работа без GPU снимает требования к специализированному оборудованию.
• Перспектива edge-исполнения. Планируемые квантование, дистилляция и экспорт в ONNX позволят перенести модели непосредственно на мобильное устройство — вплоть до полностью офлайн-режима.

Обоснованность применяемых проектных решений

Все ключевые решения приняты по результатам явного сопоставления альтернатив с учётом сформулированных требований и ограничений разработки (6 ГБ видеопамяти, архитектура Pascal, необходимость работы без GPU в проде).

Выбор архитектуры локализации — YOLO26-nano. Одноэтапные детекторы предсказывают классы и координаты за один проход, обеспечивая скорость, необходимую для приемлемого времени отклика; минимальная модификация содержит наименьшее число параметров и обучается на доступном оборудовании. Работает в сквозном режиме без подавления немаксимумов, что упрощает развёртывание и снижает задержку. Альтернативы отклонены с обоснованием: Faster R-CNN — избыточная вычислительная сложность для детекции объектов малого числа классов; SSD — уступает в точности локализации малых объектов; DETR — требует существенно большего объёма данных и вычислительных ресурсов.

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

Позиционирование относительно аналогов

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