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

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

Так как же сократить трудозатраты?

Давайте сначала определим наш горизонт возможностей. 

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

Наш бизнес очень сильно зависит от качества данных, ведь на основании документов, мы проводим платежи, считаем прибыль, сдаем отчетность в налоговую, подписываем договора с партнерами и контрагентами и т.д. Что будет, если вдруг наша нейросеть сделает ошибку в сумме контракта, или в налоговой декларации, или в счетах на оплату и т.п. Забегая немного вперед, скажу, что она обязательно сделает такую ошибку, ведь нейросеть еще не видела ту новую форму унифицированного счета-фактуры, которую прислала Галина Ивановна (главбух нашего самого крупного контрагента), у нее слетела лицензия на MS Office и теперь, она формирует таблицы - черточками в блокноте, печатает и рассылает.

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

Что нам нужно для того, чтобы обеспечить максимальное эффективный ввод данных в систему?

Обеспечить конвейер из приблизительно следующих этапов: 

• Импорт/сканирование изображений

• Нормализация изображений (исправление перекосов, цветокоррекция, избавление от шумов, ориентация текста и т.п.)

• Типизация/распознавание, извлечение атрибутов

• нормализация данных/форматно логический контроль

• проверка данных (верификация) (+ форматно логический контроль за верификатором)

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

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

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

Что делает верификатор?

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

• в одной - атрибуты документа

• в другой - изображение

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

Сейчас существует большое количество OCR движков, задача которых распознавать символы на изображениях. Ну вот же! Задача решена и остается только найти нужные атрибуты в распознанном тексте. Как можно это сделать? 

• Можно найти атрибуты простым поиском: Ищем ключевые слова + регулярочку и готово.

• Можно натренировать ML модель 

• Можно применить NLP

• Можно всё вместе

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

Давайте копнем глубже, что такое OCR движок? 

По сути это ML модель (не обязательно, но упростим для понимания), натренированная на огромном количестве шрифтов для распознавания самых разных букв и цифр. Т.е. ее задача OCR - распознать текст, напечатанный с использованием большой вариативности шрифтов, вариантов написания и дефектов печати. И чем больше вариативность будет заложена в модель, тем, по задумке авторов, OCR лучше движок будет распознавать символы. И это действительно так! Вот только мы используем всю заложенную в движок модель для распознавания всего текста с документа. А на этом документе расположены самые разные данные: обычный текст, даты, суммы, различные коды, наименования на разных языках, адреса.  OCR распознает всё подряд и нам потом в этом результате нужно искать атрибуты регулярками. Современные движки очень хорошо распознают текст. Справляются с огромным количеством шрифтов и даже плохим качеством. Только им желательно предварительно уточнить что именно они распознают.

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

Что если нам сделать более-менее универсальную модель (или набор моделей) для предварительного распознавания. С помошью нее мы получили бы неокончательную версию текста и других данных с документа. Использовали бы полученный результат для поиска примерного расположения необходимых нам атрибутов (с использованием технологий нечеткого поиска вместо регулярок), и затем уже использовали бы найденные области для уже точного извлечения атрибутов теми моделями, которые подходят для конкретного типа данных атрибута? что-то мне подсказывает, что лидеры квадранта Gartner так и делают…

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

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

Мы уже добавили классификатор, простые и не очень правила поиска: искать справа от ключевого слова, слева, снизу сверху и т.д. По сути, мы сделали конструктор, low-code платформу, если хотите, где инженер может, как из кубиков, собрать правила извлечения атрибутов для любого документа.

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

Что если, мы попробуем заставить машину понять структуру естественного языка (подлежащее, сказуемое… ну вы помните из школы) и строить правила поиска относительно именованных сущностей (NER)? Эта технология и называется NLP. И это очень полезная технология, которая помогает компьютеру понимать и обрабатывать человеческий текст (активно применяется в чат-ботах и др.). Но это сложная технология, требует инвестиций, но на что не пойдешь ради развития собственной платформы, верно?

Что нужно чтобы NLP хорошо работал?

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

Эта технология всё никак не может прижиться в сфере распознавания, потому что для настройки нужно выполнить двойную работу: и настроить стандартные правила поиска и настроить NLP. А ведь NLP это такие же правила поиска как и наши старые, просто более общие. И не бывает такого случая, когда задачу решаемую NLP нельзя было решить с помощью обычных правил. (я за 10 лет не встречал такого)

Но в R&D вбухали денег, так что будем продавать ?

А пока давайте посмотрим что умеет ML

Что же это такое? По сути ML это правила, сформированные автоматически на основании большого количества аналогичных правил. Какие же задачи ML в контексте нашей платформы?

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

Теперь давайте вернемся к верификации.

Давайте подумаем, что больше всего влияет на время работы верификатора? 

• Объем верификации - несомненно!

• Удобство интерфейса - напрямую влияет на скорость работы верификатора!

• Точность распознавания - сильно влияет! Если область расположения атрибута на изображении нашлась некорректно, то дальнейшее распознавание даже не имеет смысла

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

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

Что из этого следует?

Самое важное это интерфейс и удобство работы верификатора

как его можно улучшить? 

• сделать удобные справочники и выпадающие списки, чтобы пользователь выбирал из доступных значений, а не вбивал их вручную

• Расположение атрибутов на форме верификации должно быть интуитивно понятно  (например быть аналогично расположению на бумажном документе)

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

• Внятные подсказки и ошибки

• Инструмент распознавания прямо с формы верификации - полезно, когда атрибут плохо распознался из-за некорректно найденной области на изображении (самый частый случай). Можно быстро нарисовать новую область и распознать текст с нее прямо не выходя с верификации. Это также должно работать для таблиц - достаточно разметить таблицу (задать столбцы и строки) часто это намного проще, чем перебивать огромные таблицы руками.

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

Нужно по максимуму сокращать объем верификации

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

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

• Меж-документные проверки. Если клиент принес комплект документов. До часть данных с одного документа сходится с данными в другом документе. После проверки их в одном месте, можно автоматически подставить в остальные.

• Проверки по формулам и правилам. (корректировки и нормализация сумм, дат, кодов и др.)

Обеспечить точность извлечения 

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

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

Итак для того, чтобы обеспечить доработку вариативности правил нам нужны: 

• Набор понятных и удобных инструментов для разработки правил поиска атрибутов

• Обеспечить удобную аналитику и сбор данных для совершенствования. Например, можно отправлять на доработку примеры документов, на которые верификатор тратит аномально большое время

• Обеспечить возможность оперативной доработки правил распознавания под изменения (подход к организации работ по доработке правил их обновление)

• Инструмент должен позволять проводить регрессионные тесты

• Инструмент должен хранить историю изменений 

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

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

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

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

На этапе опытной эксплуатации и в начале промышленной важно управлять ожиданиями пользователей (как правило верификаторов), у них может сложится впечатление, что система говно не фонтан. Кстати, аналогичное мнение может возникнуть у руководителя, принимающего решение о выборе платформы. Часто в крупных корпорациях платформы меняют как перчатки с комментарием “я этот ваш Аби/Тессеракт пробовал, он работает плохо несите следующий. Вместо бесконечной смены платформ, иногда стоит разобраться в проблемах и не забывать о основной цели: сокращать трудозатраты, а не разрабатывать очередной собственный OCR движок в погоне за качеством распознавания.