Как проверять цифры из сканов перед действиями агента на базе ИИ

Представим ситуацию: ИИ распознал почти все слова в счете, верно назвал поставщика и уверенно подготовил заявку на закупку. Только количество кабеля превратилось из 125,5 метра в 1255 штук. Ошибка занимает несколько символов, а решение меняется целиком. Разберем, как проверять извлечение чисел и таблиц до того, как агент начнет действовать.

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

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

Почему точность текста мало говорит о качестве документа

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

Даже безупречное распознавание слов не гарантирует верного второго уровня. Число 48,80 может быть прочитано правильно, но перенесено в колонку количества. Языковая модель затем составит грамматически правильное объяснение неверной таблицы. Уверенный рассказ здесь ничего не исправляет.

Не стоит смешивать оценку OCR, то есть распознавания текста, с точностью извлечения бизнес-полей. Слово «метр» и значение количества полезно оценивать вместе как единый факт: 125,5 м кабеля определенного артикула. Именно такой факт использует следующая система.

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

Разберем счет с тремя строками

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

Сначала проверяем каждую строку: 125,5 × 48,80 = 6 124,40; 24 × 135 = 3 240; 2,5 × 1 800 = 4 500. Сумма до скидки – 13 864,40 рубля. Материалы стоят 9 364,40 рубля, скидка на них составляет 468,22 рубля. К оплате получается 13 396,18 рубля.

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

Отдельная ловушка – скидка. Если применить ее ко всему счету, результат составит 13 171,18 рубля. Разница с правильным итогом – 225 рублей. Все цифры исходной таблицы при этом распознаны идеально. Ошибка возникла при выборе базы расчета, потому что система не связала примечание с конкретными строками.

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

Не позволяйте арифметике исправлять оригинал

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

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

Возвращайте число вместе с доказательством

Результата amount: 13396.18 недостаточно. Через неделю специалист откроет заявку и спросит, откуда взялась сумма. Если ответить можно только повторным запуском модели, проверка превратится в новое предположение: другая версия распознавателя может выдать другой результат.

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

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

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

Продолжение таблицы на следующей странице

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

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

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

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

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

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

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

1. Определите тип документа и действие. Для сравнения цен и для создания складского прихода потребуются разные обязательные поля.
2. Получите текст и структуру. Сохраните оригинал и расположение значений, прежде чем нормализовать пробелы, запятые и единицы.
3. Соберите типизированные поля. Количество должно иметь единицу; дата – однозначный порядок компонентов; артикул – оставаться строкой с ведущими нулями.
4. Проверьте связи. У каждой суммы должна быть строка, у строки – товар или услуга, у скидки – определенная область применения.
5. Выполните арифметические и справочные проверки. Сверьте суммы, допустимые единицы и артикулы с данными процесса. Зафиксируйте все расхождения.
6. Выдайте разрешенный результат. Полный набор проверок открывает предусмотренное действие; неоднозначность направляет документ специалисту с подсвеченным фрагментом.

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

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

Как измерить качество без удобной самооценки

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

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

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

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

Вот учебный пример, а не результат внедрения. В наборе 200 счетов и 2 000 обязательных полей верно извлечены 1 940 полей: 97 процентов. Однако все обязательные поля совпали только в 160 счетах: 80 процентов. Проверки разрешили автоматическое создание заявки для 120 счетов. Среди них обнаружились два ошибочных документа.

Покрытие здесь равно 120 / 200 = 60 процентам, а доля ошибочных документов среди допущенных – 2 / 120, примерно 1,67 процента. Число 97 процентов не заменяет ни одну из этих метрик. Повышая порог, команда может уменьшить ошибки среди допущенных и одновременно отправить больше документов на ручную проверку. Показывайте оба изменения.

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

Кому принадлежит правило и зачем нужна общая платформа

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

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

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

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

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

Изображение на обложке: AiHummer