Cradl AI извлекает из PDF, сканов и изображений нужные поля, строки таблиц и реквизиты, проверяет сомнительные значения по порогам уверенности, передаёт исключения человеку и отправляет подтверждённый результат в JSON, Excel или подключённый сценарий автоматизации.

Работа строится вокруг агента: в разделе Builder задаются вход документа, узел Document AI, правила проверки, ветка Human review и конечный экспорт. Раздел Runs показывает каждую обработку и её события, а Insights помогает наблюдать объём, ошибки, долю автоматического прохождения и количество ручных исправлений.

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

Как устроен агент обработки документов

Агент объединяет схему извлечения и маршрут документа. На холсте видны карточки шагов, соединённые линиями: триггер принимает файл, Document AI формирует значения, проверки решают, можно ли продолжить автоматически, Human review получает исключения, а экспорт записывает результат в выбранную систему. Такое представление удобно тем, что ошибка относится к конкретному узлу, а не растворяется в длинной последовательности скрытых действий.

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

Верхняя часть Builder показывает название организации и агента, а также быстрые действия тестирования. Правую панель занимает конфигурация выбранной карточки. Состав настроек меняется вместе с узлом: у Document AI это модель, поля, таблицы и ограничение числа страниц; у Human review — исполнители и логика направления; у Excel — учётная запись, книга, таблица и сопоставление столбцов.

Связи на холсте отражают два исхода проверки. Метка AI validated ведёт по автоматической ветке, а If flagged отправляет документ на ручную проверку. После подтверждения обе ветки возвращаются к общему продолжению. Поэтому экспорт не приходится дублировать: он получает либо сразу одобренные значения, либо исправленный оператором набор.

Создание агента по характерному документу

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

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

На шаге интеграции задаётся, откуда будут приходить документы и куда пойдёт результат. Для первого знакомства допустимо оставить ручную загрузку, чтобы сосредоточиться на качестве извлечения. Когда схема стабилизирована, ручной триггер заменяют электронной почтой, Power Automate, n8n, Zapier, Make, API или другим доступным способом, а экспорт подключают к Excel, webhook либо внешнему сценарию.

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

Настройка полей в Document AI

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

Название поля становится частью выходной схемы, поэтому его лучше выбирать до подключения интеграций. Смена имени после настройки Power Automate, n8n или webhook потребует проверить выражения и сопоставления. Практичнее использовать короткие однозначные имена без дубликатов: Invoice number, Due date, Vendor, Total amount. Для таблиц столь же важно не создавать два столбца с почти одинаковым смыслом, иначе оператору будет сложно понять, какой из них исправлять.

Описание, или instruction, объясняет модели, какое значение требуется. Формулировка должна указывать место значения и его границы, а не повторять заголовок. Для общей суммы полезно уточнить, что нужен итог с налогами; для даты — какая именно дата из нескольких; для получателя — юридическое лицо, которому выставлен счёт. Чем меньше двусмысленности в инструкции, тем реже правдоподобное, но не то значение проходит в результат.

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

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

Инструкции, которые уменьшают неоднозначность

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

Даты особенно чувствительны к формату и языку. Если downstream-система ждёт машинный вид, извлечение можно дополнить formatter, приводящим дату к YYYY-MM-DD. При этом проверять нужно не только синтаксис, но и смысл: корректно сформированная дата выставления не заменяет дату оплаты. Для неоднозначных чисел полезно явно указать, какая валюта и какой десятичный разделитель ожидаются.

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

Проверки, форматирование и защитные правила

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

Базовое правило использует confidence score. Для каждого прогноза система показывает оценку уверенности от 0 до 100, а пользователь задаёт порог. Значение ниже порога помечается и отправляется по ветке проверки. Один общий порог удобен для первого теста, но в финансовом процессе лучше выделять рискованные поля: банковский счёт, сумма и срок оплаты требуют более строгого контроля, чем свободное описание строки.

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

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

Детерминированные правила дополняют вероятностную оценку. Сумма строк может сравниваться с итогом, налог — с разницей между нетто и брутто, поставщик — со справочником, номер заказа — с ERP. Cradl AI извлекает и маркирует данные, а сложное сопоставление часто удобнее выполнять в Power Automate, n8n или собственной системе, возвращая спорные случаи в ручной маршрут.

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

Runs: загрузка, очередь и разбор каждого запуска

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

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

Открытая запись запуска совмещает оригинал и AI response. Это важнее отдельного JSON: пользователь видит контекст, страницу и подсветку, а справа — структурированные значения. Для многостраничного файла доступны миниатюры или переходы между страницами. Если значение относится к таблице, строки можно разворачивать и проверять по столбцам.

Повторный запуск нужен после изменения схемы, порога или экспорта. Следует различать повтор модели и повтор всего маршрута: второй вариант способен снова отправить данные во внешнюю систему. Перед Rerun from start проверяют, не создаст ли Excel, ERP или webhook дубль. Для безопасного теста лучше использовать отдельную книгу, тестовый endpoint или идентификатор идемпотентности.

Ручная проверка Human review

Human review получает только документы или поля, которые не прошли автоматические условия. В интерфейсе оригинал расположен рядом с AI response, поэтому оператор не перепечатывает весь документ. Он сосредотачивается на отмеченных значениях, исправляет ошибку и подтверждает результат. Такой режим уменьшает монотонность по сравнению с полной повторной проверкой каждого поля.

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

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

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

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

Поддерживаемые документы и требования к качеству

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

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

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

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

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

Извлечение таблиц и повторяющихся строк

Табличное извлечение создаётся в Document AI как отдельная группа с набором столбцов. Такая модель подходит для позиций счёта, каталога товаров, банковских операций и строк заказа. В выходных данных каждая строка становится объектом, а столбцы — его свойствами. Это позволяет сохранить структуру при передаче в JSON или развернуть строки в Excel и базе данных.

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

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

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

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

Экспорт результата в JSON

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

Raw value сохраняет то, что было прочитано из документа, а value может отражать форматирование. Для аудита полезно записывать оба варианта вместе с documentId и runId. Если downstream-приложение принимает только итоговое значение, исходный вариант хотя бы временно сохраняют в журнале, чтобы объяснить, почему конкретная запись оказалась неверной.

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

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

Webhook: передача данных в собственную систему

В узле Webhook задаются HTTPS endpoint, метод и при необходимости заголовки. Test webhook отправляет пробный запрос, позволяя проверить доступность и структуру до включения маршрута. Получатель должен быстро вернуть успешный HTTP-код; длительную обработку лучше продолжать асинхронно после приёма, иначе повтор или тайм-аут создаст неопределённость.

Payload включает группы и поля с rawValue, value, confidence, page и name, а контекст содержит идентификаторы запуска и документа. Исходный файл в webhook не включается, поэтому получателю, которому нужен PDF, требуется отдельный механизм хранения или передачи. Нельзя предполагать, что JSON всегда сопровождается бинарным вложением.

Для проверки подлинности используются заголовки с временной меткой, nonce и подписью HMAC SHA-256. Получатель вычисляет подпись тем же секретом, сравнивает её безопасным способом и отклоняет слишком старую временную метку или повторный nonce. Проверка только IP-адреса недостаточна, а секрет нельзя записывать в открытый журнал.

Идемпотентность строят на runId или documentId в сочетании с типом события. Если endpoint получил повтор, он должен вернуть успех без создания второй бизнес-записи. Это особенно важно для счетов и заказов, где повторная вставка способна вызвать двойную оплату или дублирование строки в ERP.

При ошибке webhook сначала проверяют DNS, TLS-сертификат, доступность из интернета, разрешённый метод и обязательные заголовки. Затем смотрят код ответа и тело ошибки на принимающей стороне. Если тест проходит, а рабочие события нет, нужно убедиться, что документ достиг экспортного узла и не остался в очереди Human review.

Экспорт в Microsoft Excel

Excel-интеграция работает с учётной записью Microsoft 365 для работы или учёбы и файлами в OneDrive. Персональные учётные записи Outlook.com и Hotmail для этого сценария не подходят. После подключения панель показывает состояние Connected, а пользователь выбирает один из двух режимов: отдельная книга для каждого документа либо добавление строк в существующую таблицу.

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

Для единой книги заранее создают настоящую Excel Table командой Insert → Table. Обычный диапазон с заголовками не отображается как цель. В Cradl AI выбирают книгу, затем таблицу и сопоставляют каждую колонку с извлечённым полем. Несопоставленные столбцы остаются пустыми, поэтому после изменения схемы нужно снова открыть mapping.

Имена колонок Excel не обязаны совпадать с именами агента. Сопоставление позволяет направить Catalog Number в Product Id, а Effective Date — в Date. Это удобно, но создаёт скрытую зависимость: смена имени столбца в книге или поля в агенте может нарушить запись. Изменения следует проводить через тестовый файл и проверку итоговой строки.

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

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

Интеграция с Power Automate

Готовый коннектор Power Automate добавляет действие Extract data from document. В Cradl AI на узле Power Automate копируются Client Credentials, а в Microsoft создаётся connection. В действии выбирается агент, в поле Document передаются Content Bytes или Body предыдущего шага, а Title можно связать с именем файла.

Типовой поток начинается с When a file is created в OneDrive или с почтового триггера. Затем содержимое файла передаётся в Cradl AI, а выходные поля используются в Add a new row для Dataverse, Excel, SQL или SharePoint. Между извлечением и записью можно добавить проверку справочника, условие по сумме и ветку согласования.

Почтовый сценарий должен фильтровать вложения. У триггера включают Include Attachments и при необходимости Only with Attachments, затем в Apply to each обрабатывают каждый файл. Условие по Content-Type ограничивает поток PDF или разрешёнными изображениями. Без фильтра логотипы из подписи, контейнеры с файлами и служебные файлы будут расходовать объём и создавать лишние ошибки.

Ошибка 401 обычно указывает на неверные или отозванные Client Credentials. Ошибка 404 может означать, что выбранный агент недоступен текущему подключению или изменён идентификатор. После обновления учётных данных connection в Power Automate иногда нужно пересоздать, а не только сохранить действие.

Успешный HTTP-ответ ещё не доказывает правильность полей. В истории запуска Power Automate проверяют dynamic content и фактический JSON, а в Runs — документ и уверенность. Если значение присутствует в Cradl AI, но пусто в Dataverse, проблема чаще находится в mapping или типе столбца, а не в распознавании.

Связка с n8n, Zapier и Make

В n8n Cradl AI можно поставить между входным каналом документа и целевым приложением. Практический поток принимает письмо в Gmail, скачивает вложение, извлекает данные и добавляет строку в Google Sheets. У узла Cradl AI вводятся Client ID и Client Secret, затем выбирается агент. Входной канал легко заменить на OneDrive, Google Drive или webhook.

При mapping в n8n следует использовать выходные свойства value, а confidence и rawValue сохранять в отдельные колонки журнала. Выражение, обращающееся к полю по старому имени, вернёт null после смены имён в схеме. Поэтому обновление агента сопровождают тестом всех выражений и просмотром pinned data, а не только успешным выполнением узла.

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

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

API и учётные данные

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

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

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

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

Мониторинг качества через Insights

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

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

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

Мониторинг объёма помогает заранее заметить приближение лимита страниц. Один документ считается по числу обработанных страниц, поэтому рост многостраничных отчётов влияет сильнее, чем рост количества коротких чеков. Триггеры должны отклонять приложения, которые не нужны агенту, иначе служебные страницы расходуют ресурс без пользы.

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

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

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

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

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

Практический сценарий: заказы и каталоги

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

В каталоге главное испытание — большая таблица, переносы и неодинаковая плотность строк. Поля шапки, такие как дата действия и категория, извлекаются отдельно, а позиции — как table group. Экспорт в Excel требует заранее созданной Table и понятного решения, как хранить десятки строк одного документа.

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

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

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

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

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

Ограничения, которые важно учитывать

Cradl AI извлекает и маршрутизирует данные, но не предназначен для изменения текста, перестановки страниц, добавления подписи или ручной правки самого PDF. Когда задача состоит в редактировании документа, объединении файлов или аннотациях, нужен PDF-редактор. Результат Cradl AI — структурированные значения и управляемый процесс проверки, а не изменённая визуальная копия файла.

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

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

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

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

Защита данных, доступ и аудит

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

Срок хранения документов настраивают исходя из деловой и правовой необходимости. Чем дольше сохраняется оригинал, тем проще расследовать ошибку, но тем выше объём чувствительных данных. Если downstream-система уже хранит подписанный оригинал, в Cradl AI можно применять более короткий срок, сохраняя идентификаторы и журнал действий.

Передача защищается шифрованием, а интеграционные секреты регулярно меняют. Webhook проверяет HMAC, API-ключи не передаются в URL, Client Credentials не публикуются в скриншотах и инструкциях. Тестовые endpoints не должны принимать реальные персональные данные только потому, что их удобнее отлаживать.

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

Ошибки и способы устранения

Документ не появляется в Runs

Сначала проверяют триггер. При ручной загрузке смотрят, завершилась ли передача и поддерживается ли файл. Для почты проверяют адрес агента, фильтр, наличие вложения и ограничения отправителя. В Power Automate и n8n открывают историю внешнего потока: если действие до Cradl AI не выполнилось, искать запись в Runs бессмысленно.

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

Файл принят, но извлечение пустое или неполное

Открывают оригинал и убеждаются, что текст действительно виден, страницы не пусты и не защищены паролем. Затем проверяют page limit: продолжение документа могло не попасть в модель. У поля уточняют instruction и смотрят, есть ли ожидаемое значение в загруженном примере. Для таблицы проверяют, определена ли группа и её столбцы.

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

Слишком много документов уходит человеку

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

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

Excel не показывает книгу или таблицу

Проверяют тип учётной записи: требуется Microsoft 365 для работы или учёбы. Книга должна находиться в OneDrive и принадлежать пользователю либо быть доступной с нужным расширенным разрешением. Внутри нужен объект Table, созданный командой Insert → Table. Диапазон ячеек с цветными заголовками не заменяет таблицу.

После создания Table обновляют список, заново выбирают книгу и проверяют mapping. Если файл находится в SharePoint или Teams, может потребоваться Request additional access и согласие администратора Microsoft Entra. Пользователь также должен иметь право редактирования; доступ только для чтения не позволяет экспортировать строки.

Webhook получает ошибку или дубликаты

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

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

Power Automate возвращает 401 или 404

При 401 копируют актуальные Client Credentials из нужного узла, проверяют лишние пробелы и пересоздают connection. Секрет мог быть отозван после изменения доступа. При 404 сверяют агент и организацию: connection может быть создан в другом проекте. После исправления выполняют тест с маленьким разрешённым PDF и смотрят оба журнала.

Результат есть, но внешняя система получает null

Сравнивают JSON выхода с выражением mapping. После смены имени поля старый путь больше не существует. Также проверяют различие rawValue и value, регистр имени, вложенность табличной группы и тип целевого столбца. Строка даты может не записываться в поле даты без преобразования, хотя в Cradl AI она отображается правильно.

Таблица теряет строки или создаёт лишние

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

Сравнение Cradl AI с аналогами

Программа	Лучше подходит для	Главное ограничение
Cradl AI	Визуальной сборки потока извлечения, порогов уверенности, Human review и интеграций с автоматизацией	Не редактирует содержимое PDF и требует облачного аккаунта
ABBYY Vantage	Корпоративной классификации, OCR, обучаемых Document Skills и многошаговой обработки	Внедрение и проектирование навыков сложнее для небольшой задачи
Azure AI Document Intelligence	Разработки решений на Azure с готовыми и пользовательскими моделями для текста, таблиц и пар ключ–значение	Требует Azure-ресурсов и самостоятельной сборки прикладного процесса
Google Cloud Document AI	Облачных процессоров OCR, классификации, разделения и извлечения в инфраструктуре Google Cloud	Нужна настройка проекта, IAM и интеграционного кода
Rossum	Автоматизации транзакционных документов с проверкой оператором и обучением на исправлениях	Ориентирован прежде всего на корпоративные процессы и интеграции

Cradl AI разумно выбирать команде, которая уже использует n8n, Power Automate, Zapier или Make и хочет добавить управляемое извлечение с собственной очередью исключений. ABBYY Vantage подходит для более широкого корпоративного IDP с классификацией и навыками. Azure и Google удобны разработчикам, которые строят решение внутри соответствующего облака. Rossum стоит рассматривать для масштабных транзакционных потоков, где важны готовые процессы проверки и интеграция с учётными системами.

План внедрения без потери контроля

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

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

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

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

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

Как поддерживать схему после запуска

Любое изменение поля рассматривают как изменение контракта данных. Перед сменой имени ищут все mapping в Excel, Power Automate, n8n, webhook и API-клиентах. Новое поле сначала добавляют как необязательное, проверяют на тестовой среде и только потом делают обязательным. Удаление проводят после того, как потребители перестали к нему обращаться.

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

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

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

Рекомендованный порядок ежедневной работы

1. Проверить Runs и отфильтровать элементы со статусом ожидания или предупреждением.
2. Открыть очередь Human review и обработать сначала документы с финансовым или операционным приоритетом.
3. Сверить отмеченное поле с подсвеченной областью оригинала, при необходимости проверить соседнюю страницу.
4. Исправить значение в ожидаемом формате и убедиться, что табличные строки не потеряны и не задвоены.
5. Подтвердить документ и проверить появление экспортного события.
6. Разобрать повторяющуюся причину предупреждений: качество входа, instruction, порог, formatter или внешняя проверка.
7. Зафиксировать необычный пример в контрольном наборе без нарушения политики данных.

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

Проектирование выходной схемы до настройки интеграций

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

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

Имена полей лучше согласовать с потребителями JSON заранее. В Cradl AI они видны в настройках узла Document AI и затем используются в сопоставлениях экспорта. Для технических идентификаторов подходят устойчивые английские имена без пробелов, а понятные бизнесу подписи можно хранить в документации процесса. Важнее всего единообразие: если общая сумма называется totalAmount, не следует в соседнем агенте использовать invoiceTotal для того же смысла без причины.

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

Числа, даты и коды полезно нормализовать до передачи дальше. Пользователю обычно нужен не текст 1 234,50 EUR, а сумма как число и валюта как отдельное поле. Дата 02/03/26 требует заранее выбранной интерпретации, особенно в международном потоке. Если единый формат нельзя гарантировать моделью, formatter или следующий узел автоматизации должен выполнить преобразование и сохранить исходное значение для разбирательства.

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

Настройка узла Document AI в Builder

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

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

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

После изменения модели запускают тест из Builder или загружают файл в Runs. Проверяют не только отображаемое value, но и rawValue, confidence, номер страницы и подсветку. Если значение правильное случайно — например, взято из промежуточного итога вместо финального, — следующий документ может дать ошибку. Подсвеченная область показывает, на какой фрагмент опирался результат, и помогает отличить устойчивое правило от совпадения.

При добавлении нового поля интеграция должна переживать его отсутствие в старых документах. В Power Automate и n8n обращение к необязательному свойству защищают проверкой на null. В webhook-получателе неизвестные поля принимают без сбоя, а обязательность проверяют на уровне выбранной версии бизнес-схемы. Так агент можно развивать постепенно, не останавливая весь поток из-за появления нового ключа.

Обработка многостраничных PDF и смешанных пакетов

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

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

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

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

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

Почтовый вход: фильтры, вложения и защита адреса

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

Поддерживаемые вложения включают PDF, PNG, JPEG, WEBP и TIFF. Письмо может содержать несколько файлов, поэтому процесс заранее определяет, считать ли каждое вложение самостоятельным документом. Логотипы из подписи и встроенные изображения не должны попадать в агент. Их отсекают по расширению, размеру, имени и Content-ID ещё до передачи, иначе Runs заполнится бессмысленными изображениями.

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

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

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

Проверки для сумм, дат и идентификаторов

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

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

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

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

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

Как измерять качество агента на контрольном наборе

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

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

Полезно вести матрицу ошибок: пропуск, неверный выбор кандидата, ошибка чтения символа, неверная нормализация, потеря строки, лишняя строка и сбой интеграции. Каждая категория имеет собственное исправление. Пропуск лечится инструкцией или качеством входа, неверная нормализация — formatter, а null в целевой системе — проверкой mapping. Смешивание причин приводит к бессистемной смене порогов.

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

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

Организация очереди Human review

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

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

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

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

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

Повторные запуски, дубли и безопасная доставка результата

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

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

Webhook должен быстро вернуть 2xx, а длительную запись выполнять асинхронно. Иначе Cradl AI или промежуточная платформа может посчитать доставку неуспешной и повторить запрос. Получатель сначала проверяет подпись, регистрирует идемпотентный ключ, сохраняет тело и подтверждает приём. Бизнес-операция затем выполняется из внутренней очереди с собственными повторными попытками.

При ошибке внешней системы извлечённые значения не следует терять. Runs и журнал получателя должны позволять повторить только доставку, не запуская распознавание заново. Это особенно важно после временной недоступности Excel, API или базы. Если доступна только полная повторная обработка, защита от дублей должна учитывать, что новый runId относится к тому же документу.

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

Итоговая проверка готовности агента

• Все обязательные поля имеют однозначные имена и инструкции, а необязательные допускают корректное пустое значение.
• Табличные группы проверены на переносах страниц, промежуточных итогах, пустых ячейках и длинных строках.
• Пороги назначены по риску поля, а не одним произвольным числом для всей схемы.
• Human review имеет ответственных, сроки обработки и ограниченные роли.
• Экспорт испытан на тестовой цели, mapping проверен после последнего изменения схемы.
• Webhook или внешний поток защищён подписью, секретами и идемпотентностью.
• Зашифрованные, слишком большие и неподдерживаемые файлы получают понятный маршрут ошибки.
• Контрольный набор отделён от обучающих примеров и регулярно прогоняется заново.
• Insights и внешние метрики отслеживают не только объём, но и исправления, исключения и стоимость ошибок.
• Оригинал, raw value, итоговое value и идентификаторы запуска доступны для расследования в пределах политики хранения.

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

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