Каждый день склады обрабатывают тысячи транспортных накладных. FedEx, UPS, DHL, USPS, региональные перевозчики — у каждого свой макет, размеры шрифтов и расположение полей. На накладке FedEx номер отслеживания может быть сверху, а на DHL — посередине. Обратный адрес у одного перевозчика выровнен по левому краю, у другого — по центру.

Ручной ввод данных медленный и подвержен ошибкам. Одна переставленная цифра — и посылка потеряна. Умножьте это на 5 000 отправлений в день — становится понятно, почему логистические компании тратят миллионы на автоматизацию.

Мы разработали систему для чтения транспортных накладных. В статье — как она устроена.

Система использует PaddleOCR — мощный OCR-движок с открытым исходным кодом — и дополняется пользовательским слоем обнаружения объектов. Этот слой превращает «сырой» текст в структурированные данные. В итоге система принимает фото любой накладной и возвращает чистый JSON с номерами отслеживания, адресами, информацией о перевозчике и типе доставки.

Код написан на Python. Модель обнаружения обучается менее чем за час. Система работает даже на CPU.

PaddleOCR за 10 строк

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

В приведённом ниже коде используется класс PaddleOCR() в стиле версии 2.x, который по-прежнему работает в PaddleOCR 3.x для базового использования. В версии 3.x некоторые параметры изменены (например, удалён show_log, аргументы det/rec из ocr.ocr() убраны). Зафиксируйте версию paddleocr<3.0, если нужно сохранить старое поведение.

Запуск OCR на транспортной накладной

Мы запустили PaddleOCR (PP-OCRv5, май 2025) на сгенерированной накладке FedEx Express. Ниже — фактический вывод:

Пятнадцать строк, все с уверенностью выше 0.96. PaddleOCR хорошо справляется с распознаванием текста. Он нашёл все адреса, номера отслеживания, поля с весом. Пропущены «FEDEX» и «EXPRESS» — они находятся в белом тексте на чёрной плашке, что сложно для OCR. Для скрипта из десяти строк без обучающих данных — достойный результат.

Вот как выглядят ограничивающие рамки PaddleOCR на чистой накладной. Каждый зелёный многоугольник — обнаруженная текстовая область.

PaddleOCR надёжно работает на чистых, хорошо освещённых накладных. Проблемы начинаются, когда условия далеки от идеала.

Мы протестировали: результаты в 7 сценариях

Чтобы протестировать PaddleOCR в реальных условиях, мы создали семь сценариев: чистые сканы, повёрнутые накладные, частично закрытые, выцветшие, помятые и сцена с несколькими накладными — три посылки на одном столе.

Особенно выделяются два результата.

Распознавание текста оказалось лучше, чем ожидалось. Даже на выцветшей накладной (контраст снижен до 40%) все поля прочитаны корректно. На повёрнутой накладной (смещение на 15 градусов) встроенный классификатор угла исправил ориентацию и нашёл весь текст. Узкое место — не в самом OCR.

Сцена с несколькими накладными — прямое доказательство проблемы. Три накладные дали 53 строки текста. Адрес JOHN SMITH с первой накладной оказался рядом с номером отслеживания ROBERT CHEN со второй, вперемешку с почтовым индексом MARIA GARCIA с третьей. Распутать такой вывод с помощью регулярных выражений невозможно. Нельзя понять, какой адрес к какой посылке относится.

53 строки. Три посылки. Ноль структуры. Адреса перемешаны без разделителей. Это худший вариант проблемы сплошного массива текста — и он возникает каждый раз, когда в кадр попадает больше одной накладной.

Визуализация проблемы: PaddleOCR нашёл 53 текстовые области на трёх накладных. Весь текст смешан. Определить, какая коробка к какой посылке, невозможно.

Проблема сплошного массива текста

PaddleOCR возвращает текст. Весь текст. В порядке чтения — сверху вниз и слева направо. Но он не понимает, что означает каждый фрагмент.

Какая строка — номер отслеживания? Какие строки — адрес получателя? Где заканчивается адрес отправителя и начинается вес?

Первое желание — использовать регулярные выражения. Это работает, но частично.

Регулярное выражение может находить номера отслеживания FedEx. Но не сработает для UPS (1Z), DHL (10 цифр), USPS (20–22 цифры). Писать отдельное выражение для каждого перевозчика — кошмар с точки зрения поддержки. И это только одно поле.

С адресами ещё сложнее. Надпись «SHIP TO:» есть на одних накладных, на других — «DELIVER TO:», а где-то адрес без заголовка. Строк может быть две, три или пять — в зависимости от страны.

Вот ключевая мысль: OCR извлекает текст. Обнаружение объектов извлекает смысл.

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

OCR возвращает плоский список. Слой обнаружения объектов организует тот же текст в размеченные поля.

Ниже — реальный результат из теста. Слева — необработанный список из PaddleOCR, справа — те же данные, организованные моделью обнаружения.

Почему универсального обнаружения недостаточно

У PaddleOCR уже есть детектор текста. Почему бы не использовать его?

Он находит любые текстовые области — вокруг слов, строк, абзацев. Это помогает найти, где есть текст, но не даёт понимания, что это за текст. Для детектора рамка вокруг «John Smith» выглядит так же, как вокруг «Memphis, TN 38118». Оба — просто «текст».

А что насчёт SAM? SAM выделяет области по визуальным границам, но не понимает структуру документа. Он может выделить штрихкод по контрасту, но не отличит адрес получателя от отправителя, если шрифт и фон одинаковы.

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

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

Хорошо обученная модель, например D-FINE или RT-DETR, справляется с повёрнутыми накладными, частичным перекрытием и разным качеством печати — потому что видела такие примеры на этапе обучения.

Пайплайн с этапа обнаружения

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

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

Фактический вывод пайплайна

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

Каждое поле размечено. Даже с неидеальными рамками пайплайн выдаёт структурированный результат за 3,6 секунды на CPU. Сравните с 15 необработанными строками из PaddleOCR. Тот же текст, но теперь каждый фрагмент имеет метку.

Визуализация показывает, что происходит на каждом этапе. Каждая область вырезается, передаётся в PaddleOCR, текст выводится справа с оценкой уверенности.

Этот вывод показывает, почему модель обнаружения так важна. Обратите внимание на результаты [LOW] и [BAD]: «CME ELECTRONICS INC» вместо «ACME» (рамка срезала первую букву), лишняя «J» в номере отслеживания (захватила край штрихкода), пустое поле веса (смещение рамки). Это ошибки точности разметки, а не OCR. Обученный детектор с более свободными рамками исправил бы все три случая. Именно такие детали настраиваются при разметке и обучении.

Обучение детектора в Datature

Шаг 1: Сбор изображений

Соберите 80–120 фотографий транспортных накладных. Возьмите разные службы доставки, углы съёмки, освещение, состояния: чистые, мятые, заклеенные лентой, надорванные. Снимайте той же камерой, что будет использоваться в работе. Если на складе — стационарная камера, снимайте ею. Если сотрудники — используйте телефоны.

Разнообразие важнее объёма. 100 разнородных изображений обучат лучше, чем 500 одинаковых снимков одной накладки FedEx. Полезные аугментации: поворот, изменение яркости, имитация размытия.

Шаг 2: Загрузка и разметка

Загрузите изображения в Datature Nexus и создайте восемь классов:

• tracking_number
• recipient_name
• recipient_address
• sender_name
• sender_address
• carrier
• service_type
• barcode

Нарисуйте плотные рамки вокруг каждого поля. Они должны полностью захватывать текст, но оставлять минимум пустого пространства.

После разметки 20–30 изображений включите разметку с поддержкой модели. Она начнёт предлагать рамки. Вам останется проверять и исправлять. Это сокращает время разметки вдвое.

Общее время на разметку 100 изображений — около 2 часов.

Шаг 3: Обучение

Выберите архитектуру. Для накладных хорошо подходят YOLOv8 и RT-DETR. YOLOv8 быстрее, RT-DETR лучше с нерегулярными макетами. Datature позволяет выбрать и автоматически настраивает параметры.

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

Шаг 4: Экспорт и развёртывание

Экспортируйте модель в ONNX или TorchScript. Код пайплайна использует интерфейс Ultralytics YOLO, но можно подставить любую модель, выдающую рамки с метками. Для периферийных устройств, например Raspberry Pi, экспортируйте в TFLite и оптимизируйте под оборудование.

Дальнейшее развитие

Пайплайн «обнаружение + OCR» — это база. Вот что можно добавить:

Декодирование штрихкодов

Пайплайн уже находит области штрихкодов. Подключите pyzbar или python-zxing, чтобы декодировать одномерные и двумерные штрихкоды. Сравните значение с номером отслеживания из OCR — это дополнительная проверка. Если не совпадают, помечайте накладную на ручную проверку.

Валидация адресов

Передавайте извлечённый адрес получателя в API валидации (USPS, Google Geocoding, SmartyStreets). Если адрес не проходит проверку, вы обнаружили ошибку до того, как посылка уйдёт не туда.

Интеграция с WMS

Большинство систем управления складом (WMS) принимают JSON через REST API. Структурированный вывод пайплайна напрямую сопоставляется с полями WMS. Настройте вебхук или пакетную обработку, чтобы исключить ручной ввод.

Пакетная обработка

Для высоконагруженных сценариев запускайте пайплайн в пакетном режиме. Получайте изображения, помещайте в очередь, обрабатывайте параллельно. Модель обнаружения работает со скоростью 30+ кадров в секунду на GPU — одна машина может обрабатывать тысячи накладных в час. Узкое место — PaddleOCR; запуск нескольких OCR-процессов параллельно решает проблему.

Не только транспортные накладные

Тот же подход (обнаружение, обрезка, OCR, структурирование) применим к любым документам с полуформализованной структурой: промышленные таблички, счётчики, чеки, удостоверения. Меняются только классы обнаружения — пайплайн остаётся тем же.

Частые вопросы

Работает ли пайплайн на CPU?
Да. Модели PaddleOCR оптимизированы для CPU. Ожидайте 200–500 мс на накладную на современных процессорах (Apple M, Intel i7). Уменьшайте крупные изображения до ~1500 пикселей по длинной стороне. Для высокой пропускной способности GPU сокращает время до менее чем 100 мс.

Сколько изображений нужно для обучения?
Для 8 классов и 3–5 перевозчиков достаточно 80–120 изображений. Для 10+ перевозчиков или сильно повреждённых накладных — 200–300. Качество и разнообразие важнее количества.

Может ли PaddleOCR работать с рукописным текстом?
Базовые модели плохо справляются с рукописью. С печатным текстом — всё хорошо. Рукописные пометки распознаются с низкой уверенностью. Если они часто встречаются, дообучите модель или помечайте результаты с низкой уверенностью на проверку.

Работает ли с накладными не на английском?
PaddleOCR поддерживает более 80 языков. Укажите параметр lang при инициализации. Модель обнаружения не зависит от языка — она определяет визуальные области. OCR отвечает за распознавание. Для многоязычных складов можно запускать несколько движков параллельно или использовать многозадачный режим.

В заключение

OCR — это простая часть. Сложность в том, чтобы понять, где искать.

PaddleOCR хорошо распознаёт текст. Но он не понимает, что он означает. Пользовательская модель обнаружения, обученная на 80–120 размеченных изображениях, закрывает этот разрыв. Она указывает, где находится номер отслеживания, адрес, название перевозчика.

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

Материал подготовлен для будущих студентов курса«Компьютерное зрение».

Каждый день склады обрабатывают тысячи транспортных наклеек. FedEx, UPS, DHL, USPS, региональные перевозчики — у каждого свой макет, свои размеры шрифтов и расположение полей. На наклейке FedEx номер отслеживания может находиться наверху, а на наклейке DHL — посередине. Обратный адрес у одного перевозчика выровнен по левому краю, у другого — по центру.

Ручной ввод данных медленный и подвержен ошибкам. Одна переставленная цифра в номере отслеживания — и посылка потеряна. Умножьте это на 5 000 отправлений в день — становится понятно, почему логистические компании тратят миллионы на системы распознавания наклеек.

Мы разработали систему для чтения транспортных наклеек. В статье расскажу, как она устроена.

Система начинается с PaddleOCR (мощный движок распознавания текста с открытым исходным кодом), а затем дополняется пользовательским слоем обнаружения объектов, который преобразует «сырой» текст в структурированные данные. К концу этого руководства у вас будет рабочий пайплайн обработки (pipeline), который принимает фотографию любой транспортной наклейки и возвращает чистый JSON-объект с номерами отслеживания, адресами, информацией о перевозчике и типом доставки.

Код написан на Python, модель обнаружения обучается менее чем за час, а вся система при необходимости работает на CPU.

PaddleOCR за 10 строк

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

В приведённом ниже коде используется класс PaddleOCR() в стиле версии 2.x, который по-прежнему работает в PaddleOCR 3.x для базового использования. В версии 3.x некоторые параметры были изменены (например, удалён show_log, а аргументы det/rec из ocr.ocr() убраны). Зафиксируйте версию paddleocr<3.0, если вам нужно полностью сохранить старое поведение.

Запуск OCR на транспортной наклейке

Мы запустили PaddleOCR (PP-OCRv5, выпущен в мае 2025 года) на сгенерированной наклейке FedEx Express. Ниже приведён фактический вывод программы:

Пятнадцать строк, все с уверенностью выше 0.96. PaddleOCR хорошо справляется с распознаванием текста. Он нашёл все адреса, все номера отслеживания, все поля с весом. Пропущены «FEDEX» и «EXPRESS», потому что они находятся внутри белого текста на чёрной плашке — такие области сложнее для OCR-движков. Для скрипта из десяти строк без обучающих данных это весьма достойный результат.

Вот как выглядят ограничивающие рамки PaddleOCR на чистой наклейке. Каждый зелёный многоугольник — это обнаруженная область текста.

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

Посмотрим внимательнее на этот вывод.

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

Мы протестировали: результаты в 7 сценариях

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

Вот результаты:

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

Особенно выделяются два вывода.

Распознавание текста в PaddleOCR оказалось лучше, чем ожидалось.Даже на выцветшей наклейке (контраст снижен до 40%) все поля были прочитаны корректно. На повернутой наклейке (смещение на 15 градусов) встроенный классификатор угла исправил ориентацию и нашёл весь текст. Узкое место здесь не в самом OCR-движке.

Сцена с несколькими наклейками — это уже прямое доказательство проблемы.Три наклейки на одной поверхности дали 53 строки текста. Адрес JOHN SMITH с первой наклейки оказался рядом с номером отслеживания ROBERT CHEN со второй, вперемешку с почтовым индексом MARIA GARCIA с третьей. Распутать такой вывод с помощью регулярных выражений невозможно. Нельзя понять, какой адрес относится к какой посылке.

Вот что программа фактически вывела для сцены с несколькими наклейками:

53 строки. Три разные посылки. Ноль структуры. Адреса со всех трёх наклеек перемешаны без каких-либо разделителей. Это худший вариант проблемы сплошного массива текста, и он возникает каждый раз, когда в кадр камеры попадает больше одной наклейки.

Визуализация проблемы сплошного массива текста. PaddleOCR нашёл 53 текстовые области на трёх наклейках, лежащих на одной поверхности. Весь текст смешан, и понять, какая коробка к какой посылке относится, невозможно.

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

Проблема сплошного массива текста

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

Посмотрите на этот вывод ещё раз. Это просто плоский список. Какая строка здесь является номером отслеживания? Какие строки образуют адрес получателя? Где заканчивается адрес отправителя и начинается вес посылки?

Первое инстинктивное намерение — использовать регулярные выражения. И это работает, но лишь отчасти:

Это регулярное выражение находит номера отслеживания FedEx. Но оно не срабатывает для UPS (буквенно-цифровой формат 1Z). Не срабатывает для DHL (10-значный числовой формат). Не срабатывает для USPS (формат из 20-22 цифр). Писать отдельное регулярное выражение для формата номера отслеживания каждого перевозчика — это кошмар с точки зрения поддержки, и речь пока только об одном поле.

С адресами всё ещё хуже. Как понять, где начинается и заканчивается адрес получателя? Надпись «SHIP TO:» есть на одних наклейках и отсутствует на других. Где-то используется «DELIVER TO:», а где-то адрес просто напечатан без какого-либо заголовка. Строк адреса может быть две, три или пять — в зависимости от страны.

Вот ключевая мысль:OCR извлекает текст.Обнаружение объектов извлекает смысл.

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

Сам по себе OCR возвращает плоский список строк. Добавление слоя обнаружения объектов организует тот же самый текст в размеченные, структурированные поля.

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

Почему универсального обнаружения недостаточно

Может возникнуть вопрос: у PaddleOCR уже есть модель обнаружения текста. Почему бы не использовать её?

Встроенный детектор PaddleOCR находитлюбыетекстовые области. Он рисует рамки вокруг каждого слова, строки или абзаца, который видит. Это полезно, чтобы определить, где вообще есть текст, но не даёт понимания, что именно представляет собой каждая область. Для детектора рамка вокруг «John Smith» выглядит точно так же, как рамка вокруг «Memphis, TN 38118». И то и другое для него просто «текст».

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

LayoutLM и похожие модели понимания документов ближе к тому, что нам нужно. Они объединяют положение текста, его содержимое и визуальные признаки, чтобы классифицировать области документа. Но обучены они на стандартных бизнес-документах: счетах, чеках, формах. Транспортные наклейки, снятые складской камерой под углом, с бликами, с частичным перекрытием от скотча или упаковки — это уже другая задача. Кроме того, такие модели требуют заметных вычислительных ресурсов и могут работать слишком медленно для сценариев с высокой пропускной способностью.

Самый прямой путь — это пользовательская модель обнаружения объектов, обученная на ваших конкретных типах наклеек. Вы задаёте классы: номер отслеживания, адрес получателя, адрес отправителя, штрихкод, логотип перевозчика, тип доставки, вес, ссылочный номер; размечаете 80-120 изображений; обучаете модель; разворачиваете её. Детектор учится понимать, каквыглядиткаждое поле и где оно обычно расположено на наклейке, в том числе у разных перевозчиков и при разной ориентации.

Хорошо обученная модель обнаружения объектов, такая как D-FINE или RT-DETR, справляется с повернутыми наклейками, частичным перекрытием и разным качеством печати, потому что во время обучения увидела примеры всех этих условий.

Пайплайн с этапа обнаружения

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

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

Полный код пайплайна

Фактический вывод пайплайна

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

Каждое поле размечено. Даже с моделируемыми, то есть неидеальными, ограничивающими рамками пайплайн выдаёт структурированный результат за 3,6 секунды на CPU. Сравните это с 15 необработанными строками из PaddleOCR на том же изображении. Тот же текст, но теперь каждый фрагмент имеет своё название.

Эта визуализация точно показывает, что происходит на каждом этапе. Каждая обнаруженная область вырезается из наклейки, по отдельности передаётся в PaddleOCR, а извлечённый текст выводится справа вместе с оценкой уверенности:

Этот вывод также наглядно показывает, почему модель обнаружения так важна. Обратите внимание на результаты [LOW] и [BAD]: «CME ELECTRONICS INC» вместо «ACME» (ограничивающая рамка срезала первую букву), лишняя «J» в конце номера отслеживания (рамка захватила край штрихкода) и пустое поле веса (координаты рамки были немного смещены). Это ошибки точности разметки, а не ошибки OCR. Обученный детектор, который строит чуть более свободные рамки вокруг каждого поля, исправил бы все три случая. Именно такие детали настраиваются в процессе разметки и обучения в Datature.

Обучение детектора в Datature

Приведённый выше пайплайн предполагает, что у вас уже есть обученная модель обнаружения (label_detector.pt). Вот как её создать.

Шаг 1: Сбор изображений

Соберите 80-120 фотографий транспортных наклеек. Возьмите разные службы доставки, разные углы съёмки, условия освещения и состояния наклеек: чистые, мятые, заклеенные лентой, частично надорванные. Снимайте на ту же камеру и в той же конфигурации, которая будет использоваться в рабочей среде. Если на складе используется стационарная верхняя камера, снимайте ею. Если сотрудники будут пользоваться камерами телефонов, собирайте изображения с телефонов.

Разнообразие важнее объёма. 100 разнородных изображений обучат модель лучше, чем 500 снимков одной и той же наклейки FedEx при одинаковом освещении. Из приёмов аугментации данных, которые помогают эффективнее использовать небольшой набор данных, для этой задачи наиболее полезны поворот, изменение яркости и имитация размытия.

Шаг 2: Загрузка и разметка

Загрузите изображения в Datature Nexus и создайте восемь классов разметки:

1. tracking_number
2. recipient_name
3. recipient_address
4. sender_name
5. sender_address
6. carrier
7. service_type
8. barcode

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

После того как вручную будут размечены 20-30 изображений, переходите к разметке с поддержкой модели. Модель начнёт предлагать ограничивающие рамки на основе того, чему уже успела научиться. Вам останется проверять и исправлять эти предложения, а не размечать всё с нуля. Это сокращает время разметки примерно вдвое.

Общее время разметки 100 изображений: около 2 часов.

Шаг 3: Обучение

Выберите архитектуру обнаружения. Для транспортных наклеек хорошо подходят и YOLOv8, и RT-DETR. YOLOv8 быстрее на этапе инференса, а RT-DETR лучше справляется с нерегулярными макетами. Datature позволяет выбрать один из этих вариантов и автоматически настраивает параметры обучения.

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

Шаг 4: Экспорт и развёртывание

Экспортируйте обученную модель в формате ONNX или TorchScript. Код пайплайна выше использует интерфейс Ultralytics YOLO, но вместо него можно подставить любую модель обнаружения, которая выдаёт ограничивающие рамки с метками классов. Для развёртывания на периферийных устройствах, например на Raspberry Pi, экспортируйте модель в TFLite и оптимизируйте её под целевое оборудование.

Пошаговое руководство по созданию моделей обнаружения с нуля доступно втуториалепо обнаружению объектов.

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

Если вы работаете с разными перевозчиками, используете складские камеры, имеете дело с разными углами съёмки, наклейками, попавшими под дождь или заклеенными скотчем, либо вам нужен надёжный структурированный вывод для последующей системы, пользовательская модель обнаружения оправдывает 2–3 часа на настройку.

Используйте это дерево решений, чтобы определить, требуется ли в вашем случае пользовательская модель обнаружения или достаточно готового OCR-решения «из коробки».

Стоит упомянуть и промежуточный вариант. Если у вас 2–3 формата наклеек и чистые сканированные изображения, может подойти сопоставление по шаблону: вы определяете, к какому перевозчику относится наклейка, и применяете специфичные для него правила разбора. Но как только добавляется съёмка камерой или четвёртый перевозчик, становится очевидно, что лучше было сразу использовать обнаружение.

Дальнейшее развитие

Пайплайн «обнаружение + OCR» — это база. Вот какие возможности можно добавить сверху.

Декодирование штрихкодов

Пайплайн уже определяет области со штрихкодами. Подключите к нему pyzbar или python-zxing, чтобы декодировать одномерные и двумерные штрихкоды. Сравнивайте полученное значение со значением номера отслеживания, извлечённым через OCR, — это даст дополнительную проверку. Если значения не совпадают, помечайте наклейку для ручной проверки.

Валидация адресов

Передавайте извлечённый адрес получателя в API почтовой валидации (USPS, Google Geocoding или SmartyStreets). Если адрес не проходит проверку, значит, вы обнаружили ошибку OCR до того, как посылка отправилась не туда.

Интеграция с WMS

Большинство систем управления складом (WMS, warehouse management system) принимают JSON через REST API. Структурированный вывод пайплайна напрямую сопоставляется с полями WMS. Настройте вебхук или пакетную обработку, чтобы передавать разобранные данные наклеек в WMS и исключить ручной ввод.

Пакетная обработка

Для высоконагруженных сценариев запускайте пайплайн в пакетном режиме. Непрерывно получайте изображения, помещайте их в очередь и обрабатывайте параллельно. Модель обнаружения работает со скоростью 30+ кадров в секунду на GPU, поэтому одна машина может обрабатывать тысячи наклеек в час. Узкое место — PaddleOCR; запуск нескольких OCR-процессов параллельно решает эту проблему.

Не только транспортные наклейки

Этот же подход (обнаружение областей, обрезка, OCR, структурирование) применим к любым документам с полуформализованной структурой. Промышленные таблички с серийными номерами и характеристиками. Счётчики коммунальных ресурсов с окнами показаний. Кассовые чеки с позициями. Государственные удостоверения с полями имени и даты. Меняются только классы обнаружения — сам пайплайн остаётся тем же.

Работает ли этот пайплайн на CPU?

Да. Модели PaddleOCR оптимизированы для выполнения на этапе предсказания (inference) на CPU. Ожидайте 200–500 мс на одну транспортную наклейку на современных процессорах (Apple серии M, последние Intel i7). Время увеличивается с ростом разрешения изображения и плотности текста, поэтому перед обработкой крупные изображения лучше уменьшать до ~1500 пикселей по длинной стороне. Для систем с высокой пропускной способностью (тысячи наклеек в час) использование GPU сокращает время инференса до менее чем 100 мс.

Сколько изображений нужно для обучения?

Для 8 классов полей и 3–5 типов перевозчиков достаточно 80–120 размеченных изображений, чтобы получить рабочую модель. Если нужно покрыть 10+ перевозчиков или обрабатывать сильно повреждённые наклейки, ориентируйтесь на 200–300. Качество и разнообразие данных важнее их количества. Включайте разные условия освещения, углы съёмки, состояния наклеек и типы перевозчиков.

Может ли PaddleOCR работать с рукописным текстом на наклейках?

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

Работает ли это с наклейками не на английском языке?

PaddleOCR поддерживает более 80 языков. Укажите параметр lang при инициализации движка. Модель обнаружения не зависит от языка, так как она определяет визуальные области, а не содержание текста. За распознавание языка отвечает этап OCR. Для многоязычных складов можно запускать несколько OCR-движков параллельно или использовать многозадачный режим PaddleOCR.

В заключение

OCR — это простая часть. Сложность в том, чтобы понять, где искать.

PaddleOCR хорошо распознаёт текст. Но он не понимает, что этот текст означает. Пользовательская модель обнаружения, обученная на 80–120 размеченных изображениях, закрывает этот разрыв. Она указывает PaddleOCR, где находится номер отслеживания, где адрес, где название перевозчика.

Вся система — это около 50 строк на Python. Модель обнаружения обучается за один вечер. Результат — структурированные, размеченные данные с каждой транспортной наклейки, проходящей через ваш склад, без ручного ввода и без хрупких решений на регулярных выражениях.

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

• 28 апреля в 20:00.«Как работают современные модели компьютерного зрения “из коробки”».Поговорим про Hugging Face, OpenCV и YOLO: что реально значит “запустить за 5 минут”, как устроен базовый inference-пайплайн и где заканчиваются возможности готовых моделей.Записаться
• 19 мая в 20:00.«Событийная видеоаналитика: превращаем отслеживание в бизнес-логику».Как из детекции и трекинга собрать рабочую аналитику: зоны, пересечения, время в области и превращение координат в понятные события и метрики.Записаться

Немного практики в тему — пройдитевступительный тест по компьютерному зрениюи узнаете, есть ли пробелы в знаниях.Бонус за прохождение теста:скидка 15%на курс.