Russian (Русский) - Change language

Использование составных элементов для улучшения организации гибкого описания и поиска элементов

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

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

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

Проиллюстрируем работу с группами на примере проекта GroupSample.fsp (папка %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Group\Project1). У нас имеется изображение, на котором мы хотим находить поля с номером счета, датой счета и суммой.

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

Замечание. Перед созданием группы мы создали специальный идентификационный элемент. О назначении таких элементов говорится подробнее в разделе “Обработка гибких форм в FlexiCapture и способы их идентификации”. В данном примере мы на этом подробно останавливаться не будем. Этот элемент был создан только для того, чтобы проиллюстрировать “разветвление” дерева гипотез при наличии или отсутствии групп в его составе. Будем считать, что все элементы в дереве, кроме идентификатора, не являются обязательными, и качество нулевой гипотезы у них всех имеет значение по умолчанию 0,97.

Первым элементом в группе располагается элемент Static Text с именем InvoiceNumHeader, описывающий условия поиска заголовка поля “Номер счета”. В качестве значения для этого элемента задана строка “Invoice”.

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

Под строкой с номером счета аналогично был создан элемент для поиска заголовка поля даты InvoiceDateHeader. Для поиска собственно даты мы создали группу DateGroup с подэлементами InvoiceDate и InvoiceDateAsString. Назначение создания группы для поиска даты подробно описано в разделе Поиск даты в случае хорошего и плохого распознавания.

Для поиска поля, содержащего сумму счета, мы создали два элемента: для поиска заголовка – элемент типа StaticText с именем TotalSumHeader (значение “ Totalsum(EUR):” задано без пробелов), а для поиска собственно суммы – элемент типа Character String с именем TotalSum.

Замечание. Подробно на настройках элементов останавливаться не будем. Их можно посмотреть непосредственно в проекте.

Обратим внимание, что строка “Invoice”, заданная в качестве значения для элемента InvoiceNumHeader, на тестовых изображениях присутствует трижды: в виде заголовка к полю “Номер счета”, в виде подстроки в заголовке к полю “Дата счета” и внизу счета, в виде подстроки в условиях платежа “Current invoice is…”. Притом в заголовке “INVOICE”, который мы и должны найти с помощью элемента InvoiceNumHeader, присутствует мусор, приведший к появлению ошибки в этом заголовке. В то время как в остальных строках слово “invoice” не содержит никаких помех, и качество соответствующих гипотез должно оказаться выше, чем у гипотезы искомого заголовка.

Посмотрим, что получится при наложении гибкого описания на примере первого тестовые изображения в пакете.

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

Дерево гипотез проекта состоит из одной цепочки. Качество группы совпадает с качеством лучшей цепочки в группе.

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

Мы видим, что для элемента InvoiceNumHeader сформированы три гипотезы (по количеству обнаруженных строк “invoice”). Причем показатель качества интересующей нас гипотезы из-за наличия мусора оказался ниже (Chain quality составил примерно 0.99), поскольку вместо слова “INVOICE” программа распознала “INVOIC”. В то же время у остальных двух гипотез качество оказалось наилучшим (Chain quality = 1).

Поскольку при создании элемента InvoiceNum мы задали, что номер может состоять из произвольного количества цифр, и искать его надо правее заголовка, а на нашем имидже все эти условия соблюдаются во всех трех случаях, это позволило программе продолжить цепочку для каждой из гипотез заголовка поля “Номер счета”. Причем, хотя Pre-search quality для каждой гипотезы элемента InvoiceNum равно 1, худшей по-прежнему является именно та цепочка, которая для нас является правильной. Это происходит потому, что оценка качества цепочки осуществляется путем перемножения оценок качества гипотез, входящих в цепочку. Для искомого заголовка это качество на данном этапе составило порядка 0,99. Поэтому, если бы в группе не было больше ни одного элемента, конечный выбор на данном этапе оказался бы неправильным.

Замечание. Мы не задавали Post-search relations ни для одного элемента, поэтому для каждого элемента Post-search quality = 1, и о качестве каждой конкретной гипотезы можно судить по ее показателю Pre-search quality.

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

Как уже было сказано выше, при описании элемента InvoiceDateHeader мы задали, что его следует искать под строкой с номером счета. Однако для всех цепочек, у которых на данный момент было лучшее качество (Chain quality было равно 1), гипотезы элемента, соответствующего заголовку поля даты не были найдены. И, как следствие, во всех этих цепочках были сформированы нулевые гипотезы элемента InvoiceDateHeader. Поскольку мы не меняли значение качества нулевой гипотезы, определенное по умолчанию, результирующее качество (Chain quality) всех соответствующих цепочек понизилось и составило 0,97. В то же время для цепочки, у которой до этого момента качество было хуже, элемент, соответствующий заголовку поля даты, нашелся. Качество его гипотезы составило примерно 0,993. Оно отличается от 1, вследствие того, что на изображении, в заголовке поля даты содержится мусор, приведший к тому, что распознанное программой значение заголовка содержит ошибку и отличается от заданного в свойствах элемента InvoiceDateHeader. В результате найденная гипотеза оказалась оштрафована и итоговая оценка качества (Chain quality) составила уже порядка 0,98 (это значение получилось вследствие перемножения 0,99 и 0,993). Но, тем не менее, поскольку итоговое качество этой цепочки превысило показатели качества 0,97 всех остальных цепочек, на данном этапе она оказалась лучшей цепочкой.

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

Поскольку в каждой группе один элемент оказался найден, а другой нет, итоговое качество цепочки внутри каждой группы DateGroup оказалось равным 0,97 (результат перемножения 1 и 0,97 (качества нулевой гипотезы по умолчанию)). Т.е. в нашем случае получилось, что итоговое качество цепочек DateGroup никак не может повлиять в сторону улучшения или ухудшения на “соотношение сил”, которое сложилось на момент нахождения элемента InvoiceDateHeader. Т.е. качество каждой из цепочек просто будет домножено на 0,97.

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

Для иллюстрации того, как бы выглядело дерево гипотез, если бы в гибкого описания не было составных элементов, был создан проект GroupSample.fsp (папка Group\Project2). Вид дерева представлен на рисунке ниже. Как следует из рисунка, после нахождения элемента FormID дерево гипотез «разветвляется» из-за наличия нескольких гипотез элемента InvoiceNumHeader. Что приводит к тому, что программа вынуждена сравнивать показатели качества каждой цепочки, каждый раз начиная с самого первого ее элемента, и заканчивая последним элементом. Кроме того, при создании гибкого описания для какой-либо сложной формы (а рассматриваемая нами форма к таким не относится), подобная организация гибкого описания, без использования составных элементов, привела бы к чрезмерному «разрастанию» дерева гипотез не только в длину, но и в ширину, что затруднило бы анализ результатов наложения гибкого описания.

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

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

Не сгруппированное дерево выглядит очень «разветвленным», что делает неудобным его просмотр.

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

11/10/2020 12:08:08 PM


Please leave your feedback about this article