UiPath Document Understanding помогает принимать PDF и сканы из рабочих процессов, распознавать текст, определять тип документа, извлекать реквизиты и таблицы, проверять сомнительные значения с участием оператора и передавать структурированный результат в дальнейшую автоматизацию. Основные инструменты сосредоточены вокруг создания схемы данных, загрузки примеров, автоматической разметки, обучения классификаторов и экстракторов, контроля метрик, публикации модели и обработки исключений.

Работа строится как управляемый конвейер. Сначала в проекте задают типы документов и поля, затем загружают репрезентативные файлы. Система оцифровывает страницы, предлагает классификацию и предварительные значения, а специалист подтверждает или исправляет разметку. После обучения качество проверяют по метрикам, выбранное состояние моделей фиксируют в версии проекта и подключают к процессу через готовые активности, Studio Web, Studio Desktop либо API.

Главные разделы проекта отражают этот цикл. В Build находятся наборы документов, схема полей, рекомендации и экран аннотации; в Measure показываются оценки классификации и извлечения; Publish отвечает за версии и развёртывание; Monitor используется для наблюдения за обработкой и результативностью. Отдельно настраиваются OCR, доступ пользователей, теги, исключения для дообучения и правила, определяющие, когда документ можно пропустить без ручной проверки.

Как устроен рабочий проект

Стартовый экран показывает список проектов с поиском, сортировкой и датой создания. Для нового проекта задают понятное имя, выбирают управляемый сценарий построения моделей и при необходимости раскрывают расширенные параметры OCR. Здесь же указывается метод распознавания, адрес OCR-службы и режим Apply OCR on PDFs. Значение Auto полезно для смешанного потока: текстовый слой нативного PDF извлекается напрямую, а растровые фрагменты и страницы без текста передаются на распознавание. Принудительный OCR оправдан только тогда, когда встроенный текстовый слой повреждён, содержит неверную кодировку или не соответствует видимой странице.

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

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

Загрузка документов и организация обучающего набора

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

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

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

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

Типы документов и схема извлекаемых данных

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

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

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

Оцифровка PDF, сканов и изображений

Оцифровка формирует машинно-читаемое представление страницы: текст, строки, слова, координаты и служебную информацию. Для нативного PDF система может извлечь текст напрямую, что быстрее и обычно точнее OCR. Для скана распознавание становится обязательным. Гибридные PDF требуют комбинированной обработки, потому что часть страницы содержит текстовый слой, а подписи, печати, логотипы или вложенные изображения остаются растровыми. Режим Auto как раз предназначен для такого смешанного содержимого.

В API и основных облачных операциях используются PNG, JPG/JPEG, PDF и TIF/TIFF. Пакет IntelligentOCR в классических процессах дополнительно принимает GIF, JPE и BMP. Перед загрузкой важно сохранить читаемое разрешение и не увеличивать изображение искусственно: интерполяция не возвращает потерянные детали. Для изображений действуют границы размера, а крупные пакеты обрабатываются асинхронно. Если документ превышает лимит страниц или объёма, его делят на логические части до вызова, но сохраняют идентификатор пакета, чтобы затем собрать результат.

UiPath Document OCR подходит как базовый выбор и получает регулярные улучшения. Версия CPU оптимизирована для вычисления без графического ускорителя. Extended Languages OCR рассчитан на широкий набор языков и особенно полезен для кириллицы, греческого алфавита, китайского, корейского, вьетнамского, тайского и индийских письменностей. Критерий выбора — не название языка в списке, а контрольный прогон на собственных документах: отдельно оценивают обычный текст, мелкий шрифт, рукопись, таблицы и строки с похожими символами.

Типичные ошибки OCR проявляются в путанице O и 0, I и 1, запятой и точки в суммах, потере знака минус, слиянии соседних колонок и неверной ориентации. Их нельзя полностью исправить повышением порога уверенности: высокий порог лишь чаще отправит документ на проверку. Более эффективна комбинация качественного изображения, подходящего OCR, нормализации формата и бизнес-правил. Например, контрольная сумма, допустимый диапазон дат или сверка итогов строк обнаруживает ошибку, которую уверенность распознавания не заметила.

Автоматическая классификация входящего потока

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

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

Современный процесс поддерживает разделение много-документных пакетов. Обучаемый splitter определяет границы поддокументов и одновременно назначает тип. Это особенно полезно для ипотечных комплектов, страховых дел и архивов, где один PDF объединяет десятки форм. Ошибки разделения и ошибки классификации следует измерять отдельно: модель может правильно распознать тип страниц, но неверно провести границу, либо выделить документы верно, но перепутать их классы.

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

Извлечение реквизитов и таблиц

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

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

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

Генеративные экстракторы особенно полезны для свободного текста, сложной верстки, рукописи и полей, положение которых трудно предсказать. Однако генеративный результат должен проходить проверку по схеме и бизнес-правилам. Модель может дать правдоподобное, но отсутствующее в документе значение. Для критических реквизитов следует требовать координаты или доказуемую связь с исходным фрагментом, а документы с противоречием отправлять оператору.

Экран аннотации и подтверждение полей

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

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

Меню Extractions view меняет способ просмотра результатов. Merge by column удобно для небольшой таблицы, когда целый столбец помещается на экране; Merge by row помогает проверять широкие таблицы по строкам; Only confirmed оставляет только подтверждённые значения; режим с предсказаниями показывает то, что модель нашла без ручной метки. Переключение вида не изменяет данные само по себе, но помогает обнаруживать систематические пропуски и разрывы строк.

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

Таблицы, строки на нескольких страницах, флажки и подписи

Таблица размечается по колонкам, а значения одной логической строки объединяются. Выделив ячейки строки, пользователь нажимает Group или Enter. Группы подсвечиваются зелёной рамкой, а разобранная таблица отображается в нижней части экрана. Для однострочных позиций группировка может быть необязательной, но итоговый табличный вид всё равно нужно сверить. Если значения распределились неверно, строку группируют явно.

Многострочная позиция может занимать несколько визуальных строк: длинное описание переносится, а количество и сумма остаются справа. Её нужно связать как одну логическую запись. Строка может продолжаться и на следующей странице; тогда элементы выбирают с Ctrl и объединяют Enter. Без этой операции модель может создать две позиции, потерять описание или присоединить сумму к соседнему товару.

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

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

Активное обучение и рекомендации

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

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

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

Запуск и контроль обучения

Обучение каждого классификатора и экстрактора запускается отдельно. Кнопка Start Training доступна в статусной метке модели, на странице Split & Classify для соответствующего классификатора и на странице аннотации типа документа для экстрактора. Счётчик изменений показывает объём новых подтверждений после предыдущего обучения. Это помогает не запускать модель после одной косметической правки и не забывать о большой накопленной партии.

После запуска статус проходит через Queued и состояние обучения, затем показывает Trained, обновлённый результат, время и сведения о базовой модели. Нельзя сравнивать два запуска только по одной общей цифре: состав тестовой выборки, схема и движок могли измениться. Для производственного решения смотрят на precision, recall, F1, ошибки по полям и долю документов, ушедших на ручную проверку.

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

Метрики в разделе Measure

Project score объединяет оценки классификатора и экстракторов всех типов. Шкала помогает быстро увидеть проблемную область: Poor соответствует низкому диапазону, затем идут Average, Good и Excellent. Это ориентир, а не гарантия соответствия бизнес-требованиям. Для автоматической оплаты счёта даже высокий общий балл недостаточен, если модель иногда ошибается в банковских реквизитах. Для архивной индексации допустимый риск может быть выше.

В Classification доступны Factors и Metrics. Factors объясняет влияние размера и качества набора и предлагает действия. Metrics показывает число обучающих и тестовых документов, precision, accuracy, recall и F1 для каждого типа. Precision отвечает на вопрос, насколько чисты предсказания класса, recall — сколько реальных документов класса найдено. При несбалансированном потоке accuracy может выглядеть высокой, даже если редкий класс почти всегда пропускается.

Extraction Measure разбивается по типам документов. В Factors отображаются рекомендации по объёму и аннотациям, в Dataset — количество страниц и размеченного материала, в Metrics — качество извлечения. Поле с низким качеством не всегда требует больше документов: сначала проверяют, одинаково ли оно размечено и присутствует ли в достаточном числе примеров. Для таблиц отдельно анализируют строки, колонки и ошибки группировки.

Метрики следует дополнять эксплуатационными показателями: straight-through processing, среднее время проверки, доля исправленных полей, количество обработанных документов и оценка сэкономленного времени. Если точность растёт, но время оператора не уменьшается, вероятно, пороги отправляют слишком много уверенных документов на проверку или интерфейс задачи перегружен ненужными полями.

Публикация моделей и версии проекта

Раздел Publish фиксирует выбранное состояние моделей в версии проекта. Это снимок, который можно подключить к процессу и тестировать независимо от дальнейшей разметки. При создании задают имя, описание и выбирают включаемые модели. Затем версию развёртывают, чтобы она стала доступна активностям и API. Такой порядок защищает производственный процесс от незавершённых экспериментов в Build.

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

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

Быстрый процесс в Studio Web

Extraction Automation Builder позволяет начать с одного документа. Пользователь загружает PDF, JPG или PNG, проверяет автоматически определённый тип, при необходимости раскрывает дополнительные настройки, задаёт имя процесса и выбирает, нужна ли проверка извлечённых данных. После Create Workflow открывается Studio Web с заранее собранной последовательностью действий. Для быстрого старта действуют ограничения по размеру файла, числу страниц и символам в имени.

Шаблон обычно включает получение файла из Storage Bucket, фиксацию статуса, Extract Document Data, Validate Document Data и запись результата. Его нельзя оставлять без адаптации: нужно настроить источник, формат выходных данных, обработку исключений, повторные попытки и маршрутизацию. Для пакетного процесса добавляют диспетчер, который создаёт отдельный элемент работы или задание на файл, чтобы сбой одного документа не останавливал всю очередь.

При запуске процесс может приостановиться на задаче Action Center. Оператор назначает действие себе, проверяет поля и завершает форму; затем автоматизация возобновляется. В правой панели Studio Web виден ход выполнения и извлечённые значения. Такой тест удобен для проверки схемы, но производственный результат следует сохранять в системе учёта или журнале вместе с идентификатором документа, версией модели и статусом валидации.

Проверка человеком и обработка исключений

Human in the loop нужен не для просмотра каждого документа, а для контролируемой обработки неопределённости. Правила отправки учитывают уверенность поля, критичность, наличие обязательных значений и бизнес-проверки. Например, счёт можно пропустить без человека, если номер заказа найден, итог совпадает с суммой строк, поставщик известен, банковские реквизиты не изменились и все критические поля выше установленного порога. Один низкоуверенный необязательный комментарий не должен блокировать процесс.

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

Исправленные документы могут собираться как Exceptions for review. В списке доступны имя файла, статус, число страниц, версия проекта, дата обработки, количество извлечённых и исправленных полей, а также валидатор. Документы не добавляются в обучение автоматически: специалист проверяет качество исправлений и решает, включать ли пример. Это защищает набор от случайных операторских ошибок и необычных файлов, которые не должны определять поведение модели.

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

Подключение через активности и API

DocumentUnderstanding.Activities используется в Studio Web, Studio X и Studio Desktop и подходит для кроссплатформенных процессов. IntelligentOCR ориентирован на Windows-проекты и предоставляет классический набор областей классификации, извлечения и обучения. Выбор пакета влияет на совместимость и структуру проекта. Новую автоматизацию разумно строить на более прямом пакете DocumentUnderstanding, а существующий процесс с Taxonomy Manager и Validation Station мигрировать только после тестирования эквивалентности.

Ключевая активность Extract Document Data ссылается на проект и опубликованную версию. Она возвращает структурированный результат и может генерировать тип данных для удобного обращения к полям. Classify Document определяет класс, а Validate Document Data создаёт этап проверки. В классическом фреймворке те же задачи разбиты на Digitize Document, Classify Document Scope, Data Extraction Scope и Presentation Station.

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

Ошибки API следует разделять на постоянные и временные. Неверный project ID, classifier ID, неподдерживаемый формат или превышение лимита страниц требуют исправления запроса. Недоступность приватного skill, ограничение скорости и временный сбой допускают повтор с экспоненциальной задержкой. Ответ 429 нельзя обрабатывать частым немедленным повтором, иначе клиент продлевает перегрузку.

Предварительно обученные типы документов

Каталог готовых типов охватывает коммерческие, финансовые, страховые, налоговые, логистические, медицинские и удостоверяющие документы. Среди них счета, чеки, заказы на покупку, банковские выписки, коносаменты, упаковочные листы, платёжные извещения, счета за коммунальные услуги, паспорта, ID-карты, формы ACORD, CMS 1500, UB04, W-2, W-9 и семейство американских налоговых форм. Готовую модель можно вызвать через публичную конечную точку, активность или REST API без первоначального обучения.

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

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

Практический сценарий: обработка счетов

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

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

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

Практический сценарий: страховые и анкетные формы

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

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

Практический сценарий: банковские выписки и финансовые документы

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

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

Мониторинг процесса и оценка результата

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

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

Для управляемой эксплуатации задают контрольные пороги. Например, падение straight-through processing на несколько дней запускает анализ, а рост ошибок критического поля блокирует продвижение новой версии. Не следует автоматически переобучать модель по всем исправлениям: сначала проверяют, не связано ли отклонение с разовой плохой партией сканов.

Роли, доступ и совместная работа

Управление доступом разделяет обязанности. Администратор Document Understanding управляет правами на уровне tenant и проектов; Automation User может находить и использовать модели для оцифровки, классификации, извлечения и проверки; Data Annotator размечает документы и редактирует поля, но не публикует версии; Developer управляет содержимым проекта; Model Trainer работает с наборами и обучением; Viewer только просматривает.

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

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

Данные, безопасность и региональные ограничения

Документы, отправленные сервису, используются для оцифровки, классификации, извлечения и передачи в компоненты проверки. Организация должна заранее определить допустимый регион, срок хранения, правила удаления и категории данных. Для некоторых сценариев доступны customer-managed keys: собственный ключ позволяет контролировать шифрование и отзыв доступа. Поддержка конкретных моделей с CMK может отличаться, поэтому это проверяют до выбора архитектуры.

Не все возможности одинаково доступны в Automation Cloud, Public Sector, Dedicated и Automation Suite. Различаются генеративные модели, регионы, интерфейсы мониторинга и варианты развертывания. Проект, который должен работать в регулируемой среде, проектируют по матрице доступности, а не по демонстрации из другой платформы. Особенно важно проверить, где выполняется генеративная обработка и разрешены ли соответствующие регионы.

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

Лимиты, квоты и потребление

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

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

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

Типичные ошибки и способы исправления

Документ не загружается

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

OCR возвращает пустой или искажённый текст

Смотрят, не является ли страница слишком маленькой, обрезанной, повернутой или размытой. Затем сравнивают OCR-движки на контрольной странице. Для нативного PDF проверяют Apply OCR on PDFs: повреждённый текстовый слой может мешать, а принудительный OCR иногда даёт лучший результат. После смены движка повторно тестируют извлечение, потому что координаты слов изменятся.

Классификатор путает два типа

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

Таблица разваливается на строки

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

Новая версия проекта не используется процессом

Проверяют, опубликована и развёрнута ли версия, выбран ли правильный project ID и version в активности, а также доступ процесса к tenant. При переносе между организациями ID меняется, даже если имя совпадает. Перепубликация модели без обновления конфигурации процесса не переключает ссылку автоматически.

Слишком много задач ручной проверки

Анализируют, какие правила отправляют документы в Action Center. Часто порог установлен одинаково для критических и второстепенных полей либо проверка обязательна даже при выполненных бизнес-правилах. Порог калибруют по историческим ошибкам, улучшают слабые поля и исключают из формы значения, которые не влияют на решение.

Настройка качества без переобучения на шум

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

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

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

Сравнение UiPath Document Understanding с аналогами

Программа	Лучше подходит для	Главное ограничение
UiPath Document Understanding	Сквозных процессов, где извлечение связано с роботами, Action Center, Studio и Orchestrator	Требует настройки проекта, лицензии и экосистемы автоматизации
ABBYY Vantage	Корпоративного извлечения документов с готовыми skills и визуальной настройкой	Внедрение и лицензирование рассчитаны прежде всего на организации
Azure AI Document Intelligence	Приложений в Azure, которым нужны API предобученных и пользовательских моделей	Полный бизнес-процесс и human in the loop нужно собирать отдельно
Google Cloud Document AI	Облачных конвейеров в Google Cloud и специализированных processors	Оркестрация проверки и последующих действий зависит от внешних сервисов
Amazon Textract	Извлечения текста, форм, таблиц и финансовых документов в AWS	Разметку сложного процесса и пользовательский интерфейс проверки строят вокруг API
Nanonets	Быстрого запуска моделей извлечения и no-code интеграций для бизнес-команд	Контроль сложной RPA-логики уступает глубокой интеграции UiPath

UiPath стоит выбирать, когда документ является частью длинного процесса: письмо нужно принять, данные сверить с ERP, исключение показать сотруднику, затем обновить систему и сохранить аудит. ABBYY Vantage силён в корпоративном извлечении с визуальной настройкой. Azure, Google и AWS удобнее для разработчиков, уже работающих в соответствующем облаке и готовых самостоятельно строить оркестрацию. Nanonets подходит командам, которым важен быстрый no-code запуск. PDF Commander решает другую задачу — ручное редактирование и преобразование PDF — и не заменяет интеллектуальный конвейер извлечения.

Как спланировать внедрение

1. Определить бизнес-решение, которое будет принято по извлечённым данным, и выделить критические поля.
2. Собрать репрезентативный набор по источникам, языкам, макетам, качеству сканов и редким случаям.
3. Выбрать типы документов, схему, OCR и способ классификации; зафиксировать правила разметки.
4. Разметить первую партию, обучить модели и оценить их на отдельной выборке.
5. Настроить бизнес-проверки, пороги и маршрут Action Center только для неопределённых случаев.
6. Опубликовать версию, прогнать параллельный пилот и сравнить результат с ручной обработкой.
7. Включить мониторинг, регулярный разбор исключений, контроль потребления и процедуру отката.

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

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

Практические рекомендации по эксплуатации

• Храните идентификатор документа, project ID, версию модели, OCR и результат валидации в журнале процесса.
• Не заменяйте опубликованную версию без контрольного прогона на сохранённой выборке.
• Разделяйте технические исключения, ошибки качества изображения и бизнес-исключения.
• Проверяйте критические поля правилами и справочниками, а не только confidence score.
• Регулярно анализируйте исправления операторов, но добавляйте в обучение только проверенные примеры.
• Ограничивайте параллелизм API с учётом квот и используйте асинхронный режим для больших документов.
• Не храните ключи и персональные данные в открытых логах или настройках процесса.

Хорошо настроенный процесс постепенно сокращает ручную работу, но не стремится удалить человека любой ценой. Его цель — автоматически проводить предсказуемые документы, быстро показывать действительно сомнительные значения и оставлять проверяемый след решения. UiPath Document Understanding особенно полезен там, где распознавание должно сразу приводить к действию в другой системе, а не завершаться выгрузкой текста.

Ответы на практические вопросы

Можно ли использовать только готовую модель без обучения?

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

Нужно ли отправлять каждый документ оператору?

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

Можно ли обрабатывать один PDF с несколькими документами?

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

Как поступать с русскоязычными сканами?

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

Почему высокий Project score не гарантирует автоматическую обработку?

Общий балл усредняет несколько компонентов и не знает стоимость конкретной ошибки. Критическое поле может оставаться слабым, а редкий тип — недостаточно представленным. Решение принимают по полевым метрикам, бизнес-проверкам и пилотной статистике.

Что делать после смены макета поставщика?

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

Входной контроль до запуска распознавания

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

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

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

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

Бизнес-правила поверх результата модели

Confidence score показывает уверенность модели, но не подтверждает деловую корректность значения. Поэтому после извлечения выполняют отдельный слой правил. Номер счёта проверяют на допустимый шаблон и уникальность, дату — на разумный период, валюту — на справочник, а итог — на арифметику строк и налогов. Значение может быть распознано уверенно, но относиться к номеру заказа, а не к номеру счёта; перекрёстная проверка с контекстом выявляет такую ошибку.

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

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

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

Проектирование выходной структуры

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

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

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

При передаче результата в JSON или DataTable типы приводят явно. Денежные значения хранят числом и отдельным кодом валюты, даты — в согласованном формате и часовом поясе, логические отметки — как true, false или неизвестно. Форматированную строку оставляют рядом для отображения. Такое устройство предотвращает ошибки, когда запятая принимается за разделитель тысяч, день меняется с месяцем или незаполненный флажок ошибочно превращается в отрицательный ответ.

Пакетная обработка, очереди и повторные попытки

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

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

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

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

Интеграция с ERP, CRM и электронным архивом

Перед записью в целевую систему строят явную карту соответствия: поле проекта, бизнес-термин, тип в целевой системе, обязательность и правило преобразования. Например, SupplierName может использоваться только для отображения, а фактическим ключом служит найденный SupplierId. Карта предотвращает ситуацию, когда изменение подписи поля в проекте незаметно ломает интеграцию или подставляет текстовое название туда, где ожидается внутренний код.

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

Связь с исходником сохраняют во всех системах. В ERP записывают идентификатор обработки, в архиве — номер бизнес-объекта, а в журнале UiPath — оба значения. По этой связи можно открыть документ из карточки операции и найти операцию из журнала ошибки. Простое хранение имени файла недостаточно: одинаковые имена встречаются часто, а пользователь может переименовать вложение до поступления.

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

Регрессионное тестирование перед публикацией

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

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

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

Тесты должны охватывать не только модель. Проверяют создание Action Center задачи, права валидатора, корректность формы, тайм-аут ожидания, обработку отмены, передачу таблицы, запись в целевую систему и журналирование. Модель может выдавать правильные поля, но процесс потеряет строку таблицы из-за неверного преобразования DataTable или неверно обработает пустое значение.

Работа с языками, датами и числовыми форматами

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

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

Числа требуют различения десятичного и группового разделителя. Значение 1.234 может означать одну целую двести тридцать четыре тысячных или тысячу двести тридцать четыре. Подсказку дают валюта, локаль, количество знаков после разделителя и арифметика итогов. Нормализованное число вычисляют только после проверки, а оригинальную строку оставляют в результате для объяснения.

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

Обнаружение дрейфа и обслуживание моделей

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

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

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

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

Разбор сложных и составных PDF

Нативный PDF может содержать видимый текст, сканированные страницы, скрытый слой OCR и векторные элементы одновременно. Если встроенный текст соответствует изображению, его использование обычно сохраняет точные символы и ускоряет обработку. Если слой смещён или состоит из нечитаемых кодов, Apply OCR on PDFs переводят в режим, подходящий контрольному набору. Решение принимают после сравнения полей, а не только по тому, копируется ли текст в просмотрщике.

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

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

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

Итоговая рабочая модель

UiPath Document Understanding превращает обработку PDF и сканов в контролируемую систему: документ оцифровывается, получает тип, преобразуется в схему полей, проверяется правилами и при необходимости человеком, после чего результат становится входом для автоматизации. Эффективность зависит не от одной модели, а от качества набора, последовательной разметки, правильного OCR, разумных порогов, опубликованных версий и наблюдаемого процесса.

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