Распознавание документов: как сверить позиции входящей заявки после ИИ

Поставщик крепежа получает фотографию заявки. В первой строке стоят две упаковки винтов по пятьдесят штук, во второй — сто шайб, в третьей — шесть уголков. Если перенести только цифры, закупщик увидит два винта вместо ста. Таблица будет аккуратной, а комплект для сборки окажется неполным. Здесь польза автоматизации зависит от сохранённой единицы измерения и возможности быстро вернуться к исходной строке.

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

*Иллюстрация сортировки крепежа. Фотография не является исходной заявкой и не подтверждает количество деталей в примере.*

Начать стоит с переноса строк, а не с автоматического расчёта цены

У небольшого поставщика входящие заявки выглядят по-разному: текст письма, скан, фотография листа, выгрузка покупателя. Сотрудник тратит время на ручной перенос, но одновременно замечает пропуски и противоречия. Если поручить модели только извлечение текста, эта полезная проверка сама собой не сохранится. Её нужно оставить явным шагом между полученным результатом и расчётом.

Для первой пробы достаточно одной операции: перенести наименование, обозначение размера, количество, единицу и упаковку из трёх строк. Не нужно одновременно искать аналоги, подбирать поставщика, назначать цену и готовить письмо. Иначе при неверной сумме будет непонятно, на каком этапе появилось отклонение. У распознавания должен остаться собственный проверяемый результат: текст, сопоставимый с исходными строками.

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

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

Что действительно делает модель разметки

В официальном описании Azure Document Intelligence модель `prebuilt-layout` извлекает текст и структуру, включая таблицы. Это основание рассмотреть её для переноса заявки. Документация не обещает, что она понимает складскую упаковку конкретного поставщика или автоматически принимает коммерчески верное решение. Для доступа нужны соответствующие ресурсы и разрешение на обработку выбранных данных.

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

*Пример вкладки результата из документации Microsoft. Это демонстрационный интерфейс источника, не обработка нашей учебной заявки и не аккаунт поставщика.*

У входного файла должна быть понятная граница

Возьмём вымышленную заявку на крепёж для сборочного участка. В ней три позиции: «винт М6×40 — 2 упаковки по 50 шт.», «шайба М6 — 100 шт.», «уголок 40×40 — 6 шт.». Эти строки заданы нами для разбора, поэтому их можно использовать без клиентских реквизитов. В реальной работе разрешение на загрузку и состав передаваемых данных устанавливают до обращения к внешнему сервису.

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

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

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

Пять полей удерживают смысл позиции

Для нашего примера достаточно наименования, размера, количества, единицы и числа деталей в упаковке. У винта это соответственно «винт», «М6×40», «2», «упаковки», «50 шт.». Последнее поле не следует присоединять к размеру или терять как примечание. У шайбы и уголка упаковка в исходнике не указана, поэтому в соответствующем поле остаётся «не указано», а не придуманная фасовка.

В отдельной колонке сотрудник ставит ссылку на строку или номер позиции оригинала. Это не лишняя бюрократия: при вопросе о количестве не придётся повторно разбирать весь файл. Для короткой заявки достаточно «страница 1, строка 1». Если номер получен из автоматической структуры, его тоже сверяют: объединённые ячейки и переносы иногда меняют привычное деление таблицы.

*Винты в пакете и отдельные шайбы показывают разницу между видом изделия и способом его упаковки. Размер и число по фотографии не определяются.*

Ошибочный результат нужно показать целиком

Предположим, что модель вернула первую строку так: «винт М6×4О — 2 шт.», вторую — «шайба М6 — 100 шт.», третью — «уголок 40×40 — 6 шт.». Буква «О» вместо нуля выглядит почти незаметно. Гораздо опаснее потеря слов об упаковке: результат уменьшает требуемое количество винтов с двух упаковок до двух отдельных изделий. Именно эти отклонения должен увидеть проверяющий.

Это намеренно составленный пример ошибки, а не утверждение о фактическом ответе Azure. Он нужен, чтобы заранее определить критерий приёмки. Даже если настоящий сервис в конкретном файле прочитает всё правильно, контроль упаковки останется полезным. Один удачный результат не показывает, как процесс поведёт себя при плохом снимке, новой форме заявки или сокращении единиц.

Исправление возвращает каждое значение к основанию

Сотрудник открывает первую строку оригинала и записывает исправленное обозначение «М6×40». В количестве он оставляет две упаковки, а рядом сохраняет фасовку пятьдесят штук. Далее обычная таблица вычисляет 2 × 50 = 100 штук винтов. Модель не назначает этот пересчёт по догадке: основание для множителя уже присутствует в исходной строке, а сотрудник его подтвердил.

У шайб остаются сто штук, у уголков — шесть. Складывать эти числа в один показатель «206 единиц заказа» для закупки бессмысленно: разные изделия не заменяют друг друга. Получатель должен увидеть три отдельные позиции с собственными количествами. Если ему нужен показатель общего количества деталей для иной задачи, назначение такого итога объясняют отдельно и не подменяют им комплектность заявки.

*Измерительный инструмент напоминает о проверке обозначений. Кадр не подтверждает размер винта, точность измерения или соответствие нашей условной позиции.*

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

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

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

Сомнение в символе и отсутствие данных требуют разных действий

Если на снимке хорошо видны цифры, сотрудник может исправить перенос по оригиналу. Если правый край обрезан и фасовка не читается, такого основания нет. Система не должна дорисовывать привычное «по 50». В строке остаётся нерешённый вопрос, а обращение возвращается на уточнение. Знакомое наименование не делает неизвестное количество известным.

Похожая граница есть у размера. Обозначение «М6» не разрешает автоматически подставить длину, класс прочности, покрытие или стандарт. Для нашего учебного примера эти параметры намеренно не заданы. Поэтому проверенный список годится для предварительного внутреннего разбора, но ещё не означает, что можно отгружать любой винт М6×40. Коммерческое согласование характеристик остаётся отдельной работой.

Повторная проверка использует другой случай

После обнаружения ошибки с упаковкой полезно взять независимую учебную строку: «гайка М8 — 3 коробки по 20 шт.». Ожидаемый результат задают до запуска: три коробки, двадцать штук в каждой, шестьдесят штук после подтверждённого пересчёта. Это проверка того же риска на другом примере, а не повторение исправленного ответа, который сотрудник уже запомнил.

Второй случай должен включать и отрицательную границу: «гайка М8 — 3 коробки, фасовка не указана». Здесь пересчёт в штуки не принимают. Если процесс снова выдаёт шестьдесят, он использует привычный множитель вместо данных. Такое отклонение нельзя скрыть высоким процентом правильно перенесённых букв. Для этой задачи неверная единица важнее красивого общего показателя точности текста.

Для документов с отменённой строкой заранее определяют ещё одно правило. Если позиция зачёркнута, одного извлечённого текста недостаточно, чтобы понять действующее количество. Распознавание букв может быть верным, а смысл заказа — противоположным. Такой вариант возвращают человеку на разбор, не превращая зачёркнутое в активную закупку. Граница принятия связана с содержанием документов, а не только с качеством фотографии или уверенным видом полученной таблицы.

*Предметная иллюстрация ручной проверки. Человек в кадре не подтверждает вывод модели и не является участником описанного учебного разбора.*

Принятый список должен оставаться проверяемым при передаче

В нашем примере итоговая внутренняя запись выглядит так: винт М6×40 — две упаковки по пятьдесят, всего сто штук; шайба М6 — сто штук; уголок 40×40 — шесть штук. Первая позиция исправлена по оригиналу, две другие подтверждены без изменения. Дополнительно отмечено, что остальные характеристики крепежа требуют согласования до предложения или отгрузки.

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

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

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

Расчёт времени учитывает ручные исправления

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

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

*Иллюстрация подготовки поставки. Правильность комплекта устанавливают по проверенным позициям, а не по внешнему виду заполненной коробки.*

Пилот заканчивается решением о конкретной операции

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

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

Критерий остановки стоит определить заранее. Потерянная единица, выдуманная фасовка, неверная строка основания или неотличимая версия результата означают, что запись пока нельзя передавать как проверенную. Исправление конкретной строки не равно устранению причины. Следующий независимый случай должен показать, что контроль упаковки действительно работает, включая честное «не указано».

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

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

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