Автоматизация обработки документов с ИИ: проверка перед учётом

С чего начинается обработка входящего документа

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

Это пример проектирования, а не описание работающего решения ИНОБО. Здесь нет автоматического проведения документа или оплаты. За правила отвечает владелец процесса вместе с бухгалтерией и ИТ-службой; степень автоматизации определяют после проверки на своих документах.

Последовательность для обсуждения с командой:

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

Когда ИИ в этом процессе не нужен

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

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

Почему результат распознавания ещё нельзя записывать

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

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

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

Матрица полей для владельца процесса

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

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

Как устроить очередь исключений

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

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

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

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

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

1. До запуска зафиксируйте поток, время от поступления до проверенной карточки и труд сотрудника на ввод и сверку. Назначьте владельца эталонных значений и проверяющего, который не участвовал в настройке решения.
2. Для каждой отобранной копии документа вручную запишите верные значения критичных полей и ожидаемый исход: подготовить, передать человеку или отклонить. Отделите этот набор от примеров, которыми настраивали решение.
3. Пропустите набор через будущий процесс в согласованном контуре. Сохраняйте предложения системы, фрагменты-источники, результаты правил и решения проверяющего.
4. Сравните критичные поля с эталоном и отдельно посчитайте пропуски, неверные значения, ошибочно разрешённые передачи и ложные остановки. Разбирайте причины по типам входа.
5. Сопоставьте полное время обработки и ручной труд до и после, включая поиск ошибок и исправление карточек. Измеряйте на сопоставимых потоках, не объявляя ускорение по одному удачному файлу.

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

Что передать подрядчику

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

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

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

Источники

• Microsoft Learn: Azure Document Intelligence - обзор возможностей конкретного сервиса.
• Microsoft Learn: оценки точности и уверенности в Document Intelligence.