Если вы когда-либо пытались извлечь структурированные данные из коносамента универсальным OCR-сервисом, вы уже знаете итог: это не работает. Во всяком случае, ненадёжно. А при соблюдении требований международной торговли «ненадёжно» равнозначно «никак».
В Atlas Verify мы обрабатываем тысячи торговых документов: коносаменты, органические и фитосанитарные сертификаты, сертификаты происхождения, коммерческие счета, упаковочные листы и десятки других. На раннем этапе мы оценили все крупные OCR-платформы рынка. Все провалили одинаковый тест: дайте им документ, на котором они специально не обучались, и результат будет от неполного до опасно неверного.
Эта публикация объясняет, почему мы создали собственный процесс обработки документов, что делает торговые документы особенно сложными и какие инженерные принципы направляют наш подход.
Проблема разнообразия документов
Большинство OCR-сервисов оптимизировано для узкого набора типов документов. Google Document AI отлично работает со счетами и чеками. AWS Textract хорошо обрабатывает структурированные формы. Azure Form Recognizer можно обучить на собственных шаблонах. Но международная торговля создаёт ошеломляющее разнообразие документов.
Только в нашей системе мы работаем с более чем 35 отдельными типами документов. Коносамент совершенно не похож на органический сертификат. Фитосанитарный сертификат USDA почти не имеет структурного сходства с сертификатом ЕС. Уведомление о прибытии одной судоходной линии может быть структурированным PDF с аккуратными таблицами, а другой — сканированным факсом с рукописными пометками.
Ключевое понимание состоит в том, что каждый тип документа имеет собственную схему — определённый набор полей, важных для проверки соответствия. Коносамент требует отправителя, получателя, уведомляемую сторону, номера контейнеров, название судна, порты погрузки и выгрузки и описания сырья. Органический сертификат требует орган сертификации, название хозяйства, NOP ID, сертифицированные продукты и даты действия.
Универсальные OCR-инструменты не понимают этих схем. Они извлекают текст. Могут выявлять таблицы. Но не знают, что строка «MEDU4107760» — номер контейнера, а «NOP ID: 7880315519» — критический идентификатор, который нужно проверить по USDA Organic Integrity Database. Без понимания схем OCR — лишь дорогое преобразование текста.
Почему «достаточно хорошо» опасно
В большинстве программных приложений точность 95% превосходна. При соблюдении торговых требований это риск ответственности.
Рассмотрим номер контейнера. Стандартный формат (ISO 6346) — четыре буквы, затем семь цифр, последняя из которых контрольная. Если OCR неверно прочитает один символ — «0» станет «O», «8» станет «B» — номер контейнера недействителен. Последующие системы, пытающиеся отследить контейнер, не вернут результатов, и цепочка проверки незаметно разорвётся.
Тот же принцип действует для NOP ID, кодов HS, номеров IMO и дат сертификации. Ошибка одного символа может полностью изменить смысл. Код HS 0901.11 (кофе, нежареный, с кофеином) в отличие от 0901.12 (кофе, нежареный, без кофеина) вызывает другие ставки пошлин, нормативные требования и профили риска.
Наша архитектура
Наш процесс обработки документов имеет три этапа, каждый предназначен для максимальной точности в специфических задачах торговой документации.
Этап 1: Классификация документа — До извлечения каких-либо данных мы определяем тип документа. Эта классификация определяет применяемую схему извлечения, искомые поля и способ проверки результатов.
Этап 2: Извлечение с учётом схемы — После классификации мы применяем модель извлечения для конкретного типа, которая точно знает искомые поля и их типичное расположение. Это принципиально отличается от универсального OCR, извлекающего всё и оставляющего интерпретацию пользователю.
Этап 3: Перекрёстная проверка — Извлечённые данные автоматически сопоставляются с внешними источниками. Номера контейнеров проверяются по API судоходных линий. NOP ID — по USDA Organic Integrity Database. Коды портов — по World Port Index. Этот этап выявляет и ошибки OCR, и мошеннические данные.
Полученные уроки
После обработки десятков тысяч торговых документов стали очевидны несколько принципов:
1. Специализированный подход лучше универсального. Каждая попытка использовать общий OCR-сервис требовала такой последующей обработки, что на исправление результата мы тратили больше инженерного времени, чем потратили бы на собственное решение.
2. Классификация — основа. Неверное определение типа документа приводит к ошибкам на всех последующих этапах. Мы много вкладываем в точность классификации, поскольку от неё зависит всё дальнейшее.
3. Проверка важнее извлечения. Извлечь номер контейнера полезно. Подтвердить, что это настоящий контейнер на настоящем судне в правильном порту, — вот что действительно важно для соблюдения требований.
4. Структурированный вывод обеспечивает автоматизацию. Цель — не оцифровать документы для чтения человеком. Она в создании машиночитаемых структурированных данных, напрямую поступающих в автоматизированные процессы проверки.
Создание надёжного процесса обработки документов международной торговли действительно сложно. Документы разнообразны, требования к точности предельно высоки, а последствия ошибок значительны. Но это и основа: каждая создаваемая нами возможность проверки зависит от способности точно читать и понимать документы, сопровождающие товары по мировым цепочкам поставок.