Doxis AI.dp распознаёт текст и реквизиты в PDF, сканах и фотографиях, классифицирует входящие документы, проверяет извлечённые значения, выявляет подозрительные изменения и передаёт структурированный результат в рабочие системы. Основные инструменты — настраиваемые модели захвата, Prompt Builder для собственных полей, визуальный Flow Builder, пресеты, правила проверки, преобразование в JSON, XML, CSV, XLSX, PDF и TXT, а также точки ручной валидации для документов, где ошибка недопустима.

Работа строится вокруг организации и проекта. В проекте администратор включает только нужные сервисы, затем создаёт пресеты для финансовых документов, банковских выписок, удостоверений личности или произвольных форм. Слева остаётся навигация по Dashboard, Statistics, Inbox, Project settings и активированным моделям, а центральная область меняется от списка сервисов до редактора полей и схемы обработки.

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

Интерфейс проекта и логика навигации

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

На стартовой странице проекта видны карточки сервисов и переключатели активации. Модели захвата можно включать отдельно: финансовую, банковских выписок, универсальных компонентов, документов личности, Prompt Builder, Salary Slip и Document Toolkit. Flow Builder также активируется как отдельная возможность. Такой набор позволяет не перегружать меню лишними разделами и одновременно ограничивать доступ к функциям, которые не используются в конкретном процессе.

Навигация слева разделена на общие страницы и подключённые сервисы. Dashboard показывает доступные инструменты проекта, Statistics — фактическое потребление и динамику запросов, Inbox — входящие сообщения платформы, Project settings — сервисы, права и учётные данные. Ниже появляются пункты активированных моделей и Flow Builder. При переходе между ними сохраняется контекст проекта, но несохранённые изменения в редакторе пресета или промпта могут быть потеряны, поэтому перед сменой раздела нужно нажать Save.

Активация сервисов и минимальная конфигурация

В Project settings раздел Services служит точкой сборки проекта. Переключатель не запускает обработку сам по себе: он добавляет сервис в проект и делает доступными его настройки, API-действия и блоки Flow Builder. Для процесса файл из папки — извлечение — запись результата обычно достаточно включить Flow Builder и одну модель захвата. Для нестандартной формы к ним добавляют Prompt Builder, а для операций с файлами — Document Toolkit.

Карточка каждого сервиса содержит краткое назначение и раскрываемый блок More Info. Это полезно при выборе между похожими моделями. Financial model рассчитана на реквизиты финансовых документов и строки товаров, Bank Statement model — на данные выписок, Generic и Components — на более универсальные наборы, Identity — на удостоверения. Prompt Builder нужен, когда набор полей задаёт сам пользователь и готовой схемы недостаточно.

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

Пресет как контракт на извлекаемые данные

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

В финансовом пресете компоненты включаются переключателями. Financial охватывает базовые реквизиты поставщика, суммы, НДС, дату, валюту и номер документа. Date Details добавляет связанные даты, включая период оказания услуги и срок платежа. Line Items возвращает строки товаров или услуг. Дополнительные группы позволяют получать платёжные и ссылочные сведения, язык документа и более детальную структуру сумм. Чем шире набор, тем больше данных возвращается, но тем сложнее тестировать схему и сопоставлять поля.

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

Confidence, координаты и альтернативные кандидаты

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

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

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

Prompt Builder для собственных форм и договоров

Prompt Builder создаёт схему извлечения для документа, у которого нет подходящей готовой модели. В редактор загружают образец, задают название конфигурации и добавляют поля. У каждого поля есть машинное имя, тип и вопрос к модели. Например, для договора можно создать contract_number, effective_date, counterparty_name и termination_notice, а вопрос сформулировать так, чтобы он однозначно описывал нужное значение.

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

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

Создание промпта с чистого листа

Пустой редактор Prompt Builder содержит область загрузки документа и форму Add prompt field. Пользователь вводит Field name, выбирает Type, пишет Prompt question и при необходимости включает Image Mode или In-text validation. Image Mode имеет смысл, когда ответ зависит от визуального расположения, печатей, флажков или графических элементов. Для обычного текста его без необходимости не включают.

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

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

Источники документов и триггеры

Первый блок потока определяет, откуда придёт документ и какое событие запустит обработку. В готовых примерах используется Google Drive с действием New File: поток реагирует на новый файл в выбранной папке. В правой панели задают Connection, Parent Folder и переключатель Include File Content. Последний критичен: без него триггер может передать только сведения о файле, а модуль распознавания не получит его содержимое.

В качестве источника могут использоваться загрузка, электронная почта, облачные хранилища, базы и бизнес-приложения, подключаемые через интеграции или API. Выбор зависит не от удобства демонстрации, а от точки возникновения документа. Счёт поставщика логично принимать из почтового ящика или папки AP, фотографию удостоверения — из приложения со сканирующим SDK, договор — из CRM или системы согласования.

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

Рабочая область Flow Builder

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

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

Название шага стоит менять с общего Document Capture на смысловое, например Extract invoice fields или Read contract metadata. В длинном процессе это экономит время при разборе журналов. То же относится к соединениям: Default Platform подходит для первого теста, а в рабочем проекте понятные имена помогают отличить учётные данные бухгалтерии, отдела кадров и тестового окружения.

Передача файла в модуль захвата

Второй блок обычно получает содержимое от триггера. В примере Financial Document поле File or URL заполняется значением New File Content через селектор данных. Это не ручная строка, а ссылка на выход предыдущего шага. Если выбрать имя файла или URL вместо содержимого, поведение зависит от доступности адреса и прав; наиболее надёжно передавать бинарный контент, уже полученный авторизованным источником.

Connection определяет, под какими учётными данными выполняется запрос к модулю Doxis AI.dp. Preset выбирает схему полей. Смена пресета меняет структуру ответа, поэтому все последующие сопоставления следует пересмотреть. При удалении поля из пресета старые ссылки в Flow Builder могут остаться визуально, но возвращать пустое значение.

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

Сопоставление результатов с таблицей

Выходной блок Google Sheets Insert Row демонстрирует принцип маппинга. Пользователь выбирает Connection, Spreadsheet и Sheet, затем указывает, содержит ли первая строка заголовки. После этого поля таблицы связываются с результатами Document Capture. Дата покупки получает document_date, название продавца — merchant, итог — total_amount.

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

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

Точное связывание полей и вложенных объектов

На экране подробного маппинга видно, что каждое поле таблицы хранит ссылку на конкретный путь: components, financial, document_date; затем merchant и total_amount. Такой путь показывает вложенность ответа. Если модель возвращает объект суммы с числом и валютой, нужно выбрать именно числовой дочерний элемент, а не весь объект.

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

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

Финансовые документы: счета, чеки и заказы

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

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

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

В заказах на покупку важны номера позиций, количества, единицы и цены. Line Items следует тестировать на таблицах с переносами строк и многостраничных продолжениях. Если одна позиция разорвана между страницами, downstream-логика должна уметь объединить её или отправить документ на проверку. Неверное количество строк может быть более критичным, чем единичная ошибка OCR.

Банковские выписки и контроль структуры

Bank Statement model включается отдельно и использует собственные пресеты. На странице Update Preset доступны компоненты Candidates, Confidence and Coordinates и Ocr Data. Первый добавляет альтернативы, уверенность и положение значения, второй возвращает сырой OCR-слой. Для простого экспорта реквизитов оба можно отключить; для аудита, спорных операций и интерфейса проверки они полезны.

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

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

Поток обработки банковской выписки

В Flow Builder банковский модуль подключается так же, как финансовый: источник передаёт New File content, блок Document Capture выбирает Bank Statement и пресет. В правой панели должны совпадать соединение, идентификатор пресета и источник файла. Ошибка выбора финансового пресета для выписки приводит либо к отказу, либо к неполному набору полей.

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

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

Сохранение результата в JSON

Выход Create New File показывает, как сформировать файл в Google Drive. Имя берётся из результата банковского модуля и дополняется расширением .json, содержимое — из объекта components, тип — Text, папка — Output. Этот способ удобен для обмена с системами, которые забирают файлы из каталога, и для отладки до прямой интеграции.

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

JSON сохраняет вложенные объекты и массивы, поэтому подходит для полного ответа. CSV удобнее для плоских таблиц, XML и UBL — для систем с формальными схемами, XLSX — для ручной работы, TXT — для чистого текста. Формат выбирают по контракту приёмника. Простая смена расширения не преобразует структуру; нужен соответствующий шаг сериализации.

Извлечение из писем и вложений

Inbox: New Email позволяет запускать поток при поступлении сообщения на выделенный адрес. В правой панели выбирают соединение и тестовый адрес, затем отправляют письмо для генерации образца. Триггер может передавать тему, отправителя, текст и вложения. Для заявки из тела письма в захват передают text, для счёта — конкретный элемент массива attachments.

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

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

Prompt Builder внутри почтового процесса

После Inbox блок Document Capture: Prompt Builder получает Inbox New Email text и выбранную конфигурацию. Это позволяет извлекать имя, компанию, телефон, адрес, номер заказа или описание запроса без промежуточного файла. Результат можно оставить в JSON, преобразовать в CSV или передать в CRM через интеграцию.

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

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

Классификация и разделение смешанных пакетов

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

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

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

Преобразование, объединение и разбиение файлов

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

Поддерживаемые входы включают PDF, JPG, JPEG, PNG, DOC, DOCX, XLSX, HEIC и WEBP, а также другие согласованные форматы. На выходе используются JSON, XML, CSV, XLSX, PDF и TXT; для электронных счетов возможны XML и UBL. Формат Word или Excel не гарантирует, что каждый визуальный элемент будет распознан так же, как в приложении-источнике: таблицы, встроенные объекты и сложная верстка требуют теста.

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

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

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

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

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

Проверка данных по справочникам и документам

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

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

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

Анонимизация и минимизация данных

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

Маскирование проверяют визуально и по текстовому слою. Чёрный прямоугольник поверх PDF не всегда удаляет исходный текст; его можно скопировать или извлечь программно. Надёжный результат должен исключать скрытые данные из итогового файла и метаданных. Оригинал хранится отдельно с более строгими правами и сроком.

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

Human-in-the-loop и очередь исключений

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

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

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

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

Для системной интеграции используются API, SDK и коннекторы. Проект хранит credentials и API keys, а Flow Builder может работать через настроенные соединения. Ключи не помещают в имя потока, текстовый файл или клиентский JavaScript. Их хранят в защищённом хранилище секретов и выдают только необходимому сервису.

Запрос обычно передаёт файл или ссылку, идентификатор модели или пресета и параметры результата. Ответ содержит структурированные компоненты, OCR и служебные поля. Асинхронная обработка подходит для больших пакетов: отправитель получает идентификатор задачи, затем проверяет состояние или принимает callback. Синхронный вызов проще, но может упереться в тайм-аут на больших документах.

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

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

Доступ пользователей и разделение обязанностей

Access Control связывает пользователя, роль и область действия. Организационный администратор управляет всей организацией, viewer имеет ограниченный просмотр, owner отвечает за объект, project admin — за настройки проекта. Точная матрица зависит от конфигурации, но общий принцип неизменен: оператору проверки не нужен доступ к ключам, а разработчику интеграции не обязательно видеть все документы.

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

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

Статистика, метрики и контроль расхода

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

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

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

Качество изображений и подготовка сканов

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

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

HEIC и WEBP удобны для мобильных приложений, но downstream-системы могут их не понимать. В таком случае преобразование выполняют до передачи. Повторное JPEG-сжатие следует избегать: оно создаёт артефакты вокруг символов и влияет на форензику. Исходник сохраняют отдельно, а нормализованную копию используют для обработки.

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

Языки, алфавиты и локальные форматы

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

Даже для поддерживаемого языка локаль влияет на даты и числа. 01/02/2026 может означать первое февраля или второе января, запятая — десятичный разделитель, точка — разделитель тысяч. Лучше извлекать исходную строку и нормализовать по стране, валюте и типу документа. Нельзя менять дату только по языку интерфейса пользователя.

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

Практический процесс: счёт в ERP

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

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

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

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

Практический процесс: чеки в Google Sheets

Для реестра чеков включают Financial model и Flow Builder, создают пресет с Financial и Line Items. В Google Drive готовят папку Input, а в таблице — заголовки Date, Merchant, Total и Currency. Триггер New File получает новые изображения, модуль захвата использует пресет, Insert Row связывает поля с колонками.

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

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

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

Для формы создают Prompt Builder-конфигурацию на реальном образце. Поля задают по бизнес-назначению, а не по визуальному порядку. Например, mailing_address, taxpayer_id и signature_date устойчивее, чем field_1, field_2 и field_3. Затем тестируют другие версии формы и сканы, чтобы вопрос не зависел от одного расположения.

В Flow Builder источник передаёт документ в Document Capture: Prompt Builder. После извлечения даты приводят к единому формату, обязательные поля проверяют, а результат записывают в систему. Если форма содержит флажки, рукопись или печати, включают подходящий режим и обязательно оставляют ручную проверку для юридически значимых решений.

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

Тестирование и ввод в эксплуатацию

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

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

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

Типичные ошибки Flow Builder и их устранение

Ошибка нет содержимого файла чаще всего связана с выключенным Include File Content или выбором метаданных вместо content. Открывают триггер, включают передачу содержимого, заново загружают sample data и обновляют поле File or URL в следующем шаге. Если используется URL, проверяют, доступен ли он сервису без пользовательской сессии.

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

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

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

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

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

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

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

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

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

Строки таблиц и повторяющиеся позиции

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

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

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

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

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

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

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

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

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

Условия, ветвление и маршрутизация

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

Условие строят на стабильном значении: классе, обязательном поле, диапазоне суммы, стране, языке или результате проверки. Нельзя маршрутизировать по длинному необработанному тексту, если ту же задачу решает нормализованное поле. Названия ветвей делают предметными — например, invoice_valid, invoice_review и unsupported — чтобы журнал был понятен без открытия каждого блока.

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

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

Повторные попытки без дублей

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

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

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

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

Построение схемы данных в Prompt Builder

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

Составное значение лучше разбивать. Вместо одного поля contact_details создают email, phone и mailing_address; вместо contract_period — start_date и end_date. Для флажка формулируют допустимый логический ответ, для категории — закрытый набор значений, для списка — массив. Это уменьшает объём последующей очистки.

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

В Flow Builder блок Prompt Builder получает документ из предыдущего шага и возвращает структурированный результат для следующего блока. На экране настройки важно выбрать правильную конфигурацию и передать именно file content или доступный URL. Затем каждое поле проверяют и сопоставляют с выходной системой, а не отправляют весь ответ без контроля.

Интеграция с ERP, CRM и бухгалтерией

Doxis AI.dp передаёт результат через API, SDK, вебхуки и коннекторы, но контракт с системой назначения нужно определить заранее. Для ERP важны коды поставщика, налоги, валюта, центр затрат и строки; для CRM — контакт, компания, канал и согласие; для бухгалтерии — номера счетов и статусы проводки. Один универсальный JSON редко подходит всем потребителям.

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

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

При изменении схемы ERP сначала обновляют тестовую ветвь и запускают эталонную выборку. Переименование поля без периода совместимости ломает опубликованные потоки. Безопаснее добавить новое поле, заполнить оба варианта на переходный срок и удалить старое после проверки всех потребителей.

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

В логистическом процессе входом служат накладные, CMR, proof of delivery, упаковочные листы и транспортные документы. Классификация разделяет типы, извлечение получает номера отправления, отправителя, получателя, даты, места, количество мест и вес. Табличные позиции связывают с заказом или рейсом, а подпись и отметки о повреждении направляют на отдельную проверку.

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

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

После проверки результат записывают в TMS или ERP, оригинал сохраняют рядом с записью, а статус доставки обновляют только после успешного ответа. Повторная отправка того же proof of delivery определяется по хэшу и номеру рейса, чтобы не создавать несколько подтверждений.

Анкеты сотрудников и кадровые документы

Для кадрового ввода Prompt Builder может извлекать поля из анкет, заявлений и типовых форм, а готовые модели — реквизиты удостоверяющих документов. Результат направляют в HR-систему только после проверки имени, даты рождения, контактов и обязательных согласий. Поля о здоровье, банковских реквизитах и идентификаторах отделяют более строгими правами.

Форма сотрудника нередко содержит пустые строки, флажки и рукописные дополнения. Схема должна различать не заполнено, не применимо и отрицательный ответ. Автоматическое подставление false вместо пустоты может создать неверное заявление, поэтому неопределённый результат отправляют на проверку.

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

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

Удостоверения и проверка личности

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

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

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

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

Медицинские и страховые документы

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

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

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

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

Производственные сертификаты и контроль качества

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

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

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

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

Журналы, трассировка и аудит

Для каждого запуска нужен сквозной correlation id, который связывает источник, блоки Flow Builder, результат модели и запись в системе назначения. Без него расследование ошибки превращается в поиск по времени и имени файла. Идентификатор не должен содержать персональные данные и сохраняется во всех технических сообщениях.

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

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

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

Метрики качества вместо общей точности

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

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

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

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

Безопасное изменение опубликованного процесса

Опубликованный поток нельзя редактировать как эксперимент, если он создаёт финансовые или юридические записи. Изменения готовят в тестовом проекте или копии, где используются отдельные credentials и безопасное назначение. Эталонные документы прогоняют до и после изменения и сравнивают структурированный результат.

Конфигурации пресетов и Prompt Builder версионируют по смыслу. В описании изменения указывают добавленные поля, изменённые типы и затронутые потоки. Переименование выходного поля считается несовместимым изменением, пока все маппинги не обновлены.

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

После успешного перехода проверяют не только интерфейс Doxis AI.dp, но и фактические записи назначения. Зеленый статус блока не гарантирует, что ERP интерпретировала валюту и даты правильно. Финальное подтверждение даёт сверка бизнес-объекта с исходным документом.

Сравнение Doxis AI.dp с аналогами

Прямые аналоги отличаются не столько наличием OCR, сколько глубиной оркестрации. Doxis AI.dp объединяет модели захвата, промпты, коннекторы и визуальный поток. Rossum сильнее сфокусирован на транзакционных процессах и коммуникации по документам. ABBYY Vantage предлагает развитую концепцию готовых и пользовательских навыков. Сервисы Microsoft, Google и Amazon дают мощные API и модели, но требуют собирать полный процесс вокруг них.

Выбор зависит от команды. Бизнес-подразделению, которому нужен наглядный маршрут от папки или почты до таблицы и ERP, ближе Doxis AI.dp или Rossum. Организации с опытом ABBYY и сложными OCR-навыками стоит оценить Vantage. Разработчикам, уже использующим Azure, Google Cloud или AWS, проще встроить родной сервис и дополнить его очередями, функциями и хранилищами. Для ручного изменения нескольких PDF ни одно из этих решений не заменяет простой редактор.

Программа	Лучше подходит для	Главное ограничение
Doxis AI.dp	Визуальных потоков захвата, проверки, преобразования и передачи документов между бизнес-системами	Требует проектной настройки моделей, прав и интеграций
Rossum	Транзакционных документов, почтовых каналов, валидации и сложных процессов с поставщиками	Ориентирован прежде всего на корпоративные процессы и внедрение
ABBYY Vantage	Готовых и собственных document skills, низкокодовой автоматизации и развитого OCR	Полноценная эксплуатация требует настройки навыков и корпоративной инфраструктуры
Azure AI Document Intelligence	Разработчиков в экосистеме Azure, готовых и пользовательских моделей извлечения	Это сервис распознавания и моделей, а полный процесс собирают дополнительными средствами
Google Cloud Document AI	Процессоров OCR, классификации, разделения и извлечения в проектах Google Cloud	Нужны облачный проект, IAM и самостоятельная оркестрация интеграции
Amazon Textract	Извлечения текста, форм, таблиц, подписей, запросов и макета в AWS	Не предоставляет готовый бизнес-процесс уровня визуальной IDP-платформы

Как выбрать пилотный сценарий

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

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

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

Контрольный список перед публикацией потока

Перед нажатием Publish проверяют активный проект, сервисы, пресеты и соединения. Все обязательные блоки должны пройти тест на образцах, а Data Selector — ссылаться на существующие выходы. Input и Output разделяют, чтобы процесс не запускал сам себя.

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

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

Итоговая логика работы

Doxis AI.dp наиболее полезна там, где документ должен пройти полный путь: поступить из реального канала, быть распознанным и классифицированным, превратиться в проверенные поля, пройти контроль риска и попасть в систему назначения. Preset задаёт структуру, Prompt Builder расширяет её для собственных форм, а Flow Builder соединяет источник, обработку и выход.

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