FlexiCapture. Чи так він гнучкий, як називається?

    Про продукт FlexiCapture, як показує досвід, звичайні користувачі за межами компанії знають зовсім мало («Уж не цим ЄДІ розпізнають?"), незважаючи на те, що він використовується в багатьох великих організаціях. Можна з цим миритися, вважаючи, що продукт не для кінцевого користувача, а корпоративний. А можна періодично розповідати про нього всяке, що буде не тільки корисно тим, хто з ним вже знаком, але і натякне далеким від продукту людям, що Flex — це не просто 4 букви в назві.
 
Наші партнери з новосибірської компанії АТАПІ Софтвер поділилися своїм прийомами обробки різних складних випадків. Це набір конкретних практичних порад, які, ми сподіваємося, будуть вам корисні. Крім того, кожна з цих історій подібна дзенському коанов — допомагає розкрити справжню природу FlexiCapture в усьому її різноманітті.
 
 

При обробці нестандартних таблиць будь безтурботний, як квітка лотоса

Основне призначення ABBYY FlexiCapture — витягати з документів певні дані і заносити їх в інформаційну систему. У Росії більшість документів уніфіковано, тому зазвичай це не викликає труднощів. До нещастя, такого не скажеш про зарубіжних документах — скажімо, про європейські рахунках-фактурах — та й деякі російські форми «отжигают» не гірше своїх закордонних побратимів. Часто зустрічаються випадки, коли необхідна інформація в таблицях розмежована недостатньо чітко, наприклад, ось так:
  
 
 
Тут в таблиці є два рядки з описом товарних позицій. Якщо для розпізнавання такого документа використовувати автоматичний спосіб, номенклатурний номер товару (крайнє ліве поле) потрапить в окрему колонку і буде розпізнано вірно, а от поля кількість і артикул (третя колонка) потраплять в одну і ту ж колонку, хоча в нашій таблиці це різні поля. Крім того, в колонки може потрапити багато зайвої текстової інформації — це створить проблеми при верифікації.
 
Розділити шукані дані на окремі поля можна за допомогою функціональності повторюваної групи. В Flexilayout Studio створюємо елемент типу «повторювана група» (Repeating Group). Кожен примірник групи буде відповідати рядку таблиці, всередині області якої вже організовується пошук з використанням простих елементів (типу Static Text, Character String, Region і т.д.). В свою чергу, область кожного рядка може бути так само виділена за допомогою повторюваної групи, яка випереджає пошук безпосередньо інформації.
 
Це, мабуть, найкраще рішення для подібних випадків. Однак, треба не забувати, що окрім власне розпізнавання, нам потрібно навести дані з такої не зовсім стандартної таблиці до звичайного табличному увазі:
 
 
 
Навіщо це потрібно? Операторам верифікації простіше обробляти дані, коли вони представлені у вигляді таблиці. Крім того, дуже часто буває, що стандартні і нестандартні таблиці надходять на верифікацію один за одним, і якщо робити для кожного випадку окремий шаблон, оператору буде важко перемикатися з одного способу подання даних на інший — тому він неминуче почне робити помилки.
 
І ще один момент. На наступному прикладі видно, що представляти складні нестандартні таблиці у вигляді повторюваної групи в інтерфейсі не зовсім зручно — таке уявлення займає багато місця.
 
 
 
Порівняємо це з поданням аналогічних даних у вигляді таблиці:
  
 
 
Як ми бачимо, в такому вигляді (як таблиця) дані займають набагато менше місця, і у оператора з'являється можливість перевіряти документи швидше — не витрачаючи час на скролінг.
 
Щоб прискорити процес верифікації і зробити його однаковим, ми використовуємо наступний підхід:
 
 
     
  • На рівні гнучкого опису шукаємо потрібні дані за допомогою повторюваної групи, знаходимо таким чином регіони окремих рядків. Потім в межах регіону кожного рядка витягаємо необхідні поля.
  •  
  • Далі створюємо фіктивну таблицю з такою ж кількістю рядків, як в повторюваної групі. Фіктивна таблиця — це таблиця, яка накладена в довільному регіоні, тобто вона присутня на формі даних, але не прив'язана до конкретного зображення документа.
  •  
  • У проекті FlexiCapture, в настройках визначення документа, пишемо просте скриптовими правило — воно буде копіювати значення з полів, які система знаходить в повторюваної групі, до відповідних колонки таблиці.
  •  
  • Самі поля на формі даних можна приховати, так як вся інформація тепер буде зберігатися і показуватися в таблиці.
  •  
 
 

Уникай пащі тигра, покращуючи розпізнавання табличних даних

При роботі з таблицями карма розробника — велика кількість різного текстового «сміття» в осередках з даними. Наприклад, нам треба витягти цифрове значення Код за КОАТУУ і Дата внесення відомостей до ЕГРЮЛ з наступної таблиці:
  
 
 
Якщо зробити просту таблицю, то в комірку з кодом потраплятиме текстовий опис виду діяльності («Оренда власного нерухомого майна»), яке потрібно буде видаляти або розробнику за допомогою скрипта, або щоразу вручну — оператору. Крім того, в регіон таблиці також можуть потрапляти помарки, помітки, штампи, підписи і т.д.
 
Щоб подібна зайва інформація не заважала розпізнаванню, ми можемо на рівні гнучкого опису відфільтрувати ці об'єкти — задати правила, за допомогою яких система буде автоматично знаходити їх і ігнорувати при розпізнаванні. У випадку з нашим прикладом достатньо буде налаштувати «ігнор» всіх текстових об'єктів з російськими буквами і дужками.
  
 
 
Як видно на малюнку нижче, під FlexiCapture 10 дане поле буде виключено з області розпізнавання (прямокутники з сіркою штрихуванням).
  
 
 
Або ж можна піти від зворотного — спочатку за допомогою повторюваної групи знайти тільки потрібні нам дані (цифрові коди), а потім виключити з розпізнавання всі текстові чи інші об'єкти зображення з колонки «Код за КОАТУУ», відмінні від безпосередньо коду.
Приклади таких підходів представлені на картинці нижче: зліва ми виключили фіксований текст MACHINE REAMER 600 першим способом, а на правій — все, крім цифр, другим способом:
 
 
 
 

Настрій варіаційне розпізнавання поля — дозволь дзеркалу розуму відокремити гарне від не надто

Буває так, що формат одного і того ж поля сильно розрізняється в однотипних документах. Наприклад, в зарубіжних рахунках-фактурах може зустрічатися як звичайний чорний текст на білому тлі, так і білий текст на чорному фоні. Подібну ситуацію ми можемо бачити в бланках різноманітних анкет, опитувальників і т.д.
  
 
 
А буває і так, що шаблон один, а в реальності на розпізнавання документи приходять упереміш — в одних дані удруковані на принтері, а в інші вписані людиною так званим рукопечатним способом.
 
 
 
Чи не менше казусів породжує різний формат даних в одних і тих же полях. Якщо в одному документі буде зазначена дата в форматі 23-лютого-2006, а в іншому — 24/11/08, людина зрозуміє, а програмі бажано при цьому вказати різні настройки для цього поля.
 
 
 
Всі ці випадки можуть викликати труднощі з розпізнаванням. ABBYY FlexiCapture дозволяє створити два окремих поля і задавати їм різні настройки розпізнавання: інвертований або звичайний текст, друкований чи рукопечатний, розпізнавання в загальній рамці або малювання окремої рамки на кожен символ. Потім при обробці кожного документа оператор вручну вибирає вірний варіант для поля.
 
Але можна ще трохи вдосконалити процес розпізнавання. Перший варіант — обробляти документи в різних типах пакетів. Але це теж досить незручно, так як потрібно розділяти документи на етапі сканування, та й оператори в кінцевому підсумку можуть просто заплутатися, куди який документ відправляти. Навіщо вантажити оператора зайвою роботою, коли з цим завданням може впоратися програма?
 
Ми використовували наступний алгоритм. У тому місці, де у нас повинен знаходитися шуканий текст, створюємо три поля:
 
     
  • перше — приховане від користувача поле, яке розпізнає звичайний текст,
  •  
  • друге — теж приховане поле, яке розпізнає текст як інвертований,
  •  
  • третє — видиме користувачеві поле, в якому оператору подається на перевірку той з результатів розпізнавання, який система оцінює як кращий.
  •  
 
 
 
Кращий результат система може вибрати, наприклад, виходячи з кількості так званих «підозрілих символів» (Suspicious Symbols) — для цього потрібно створити скриптовими правило, яке передає як результат розпізнавання значення поля з найменшою кількістю «підозрілих символів».
 
Аналогічний підхід з трьома полями і вибором найкращого варіанту розпізнавання можна використовувати для випадків різної розмітки або друкованого / рукопечатного тексту в одному полі.
 
 

Як повернути все суще до єдиного: виділення дробової частини чисел

Здавалося б, яка проблема може бути з дробами? Ті ж цифри і точки-коми. Але іноді розділові знаки дроби нерозпізнаються або зникають при скануванні, що може привести до неприємних наслідків. Наприклад, підсумкова сума в паперовому рахунку-фактурі одна, а в електронному — інша (в ній з'являється пара зайвих нулів). Таке трапляється, наприклад, при обробці документів, переданих по факсу, розпізнаванні старих документів або з документів з поганою якістю друку.
  
 
 
В FlexiCapture вирішити таке завдання не дуже складно.
 
Зазвичай число знаків у дробовій частині варіюється від 0 до 2. Щоб зрозуміти, чи є в розпізнаному тексті роздільник, нам потрібно:
 
     
  • Обчислити відстань між останнім і передостаннім символами в рядку. Для цього від х координати правої межі передостаннього символу віднімаємо х координату лівої межі останнього символу. Це буде S 1
  •  
  • Якщо число символів в рядку дорівнює двом: порівнюємо S 1 з деяким коефіцієнтом, якщо S 1 більше цього значення, то потрібно додати роздільник.
  •  
  • Якщо число символів в рядку більше двох, то необхідно обчислити відстань S 2 між 2 і 3 символами з кінця рядка.
  •  
  • Порахувати відносини S 1 / S 2 і S 2 / S 1
  •  
Якщо якесь із відносин більше коефіцієнта, наприклад, 1.5, то вставляємо роздільник між відповідними символами.
Це рішення застосовувалося в одному з наших проектів в Австралії. Нижче наведено приклад вихідного зображення і результати розпізнавання — з нашим «улучшайзінгом» і без нього.
 
 
 
У рахунку-фактурі, до речі, результат розпізнавання досить легко перевірити по контрольній сумі. Якщо в розпізнаному документі значення поля «Разом» зійдеться із сумою за таблицею — значить, можна верифікувати результат розпізнавання без участі оператора. Також може допомогти порівняння суми цифрами з сумою прописом, якщо така є в документі.
 
Щоб автоматизувати підбір коефіцієнтів, можна аналізувати середня відстань між символами в рядку, відношення між висотою і шириною символів і т.д., але, як правило, простіше підібрати коефіцієнти експериментальним шляхом, або методом наукового «тику». Час, які ви витратите на підбір цих коефіцієнтів, обчислюється хвилинами — в той час як оператору верифікації такий підхід може заощадити годинник роботи.
 
 

Під поглядом Будди і на залізному дереві розпустяться квіти. Що робити, якщо вам потрібен повний текстовий шар документа

Ми вже писали, ABBYY FlexiCapture потрібна, щоб витягувати і зберігати конкретні дані з полів: цифри, імена контрагентів та інше, повний текст документа, як правило, нікого не цікавить. Але трапляється і так, що потрібно в одному потоці отримувати дані з полів для одних документів і розпізнавати текст цілком для інших.
 
Можливість витягувати весь текст документа у вигляді текстового файлу може знадобитися, наприклад, для індексації вмісту документа в різних пошукових системах — як широкого користування, так і внутрішньокорпоративних.
 
Така необхідність виникла у мерії Новосибірська, яка обробляла документи органів влади — накази, постанови і розпорядження. Їм потрібні були не тільки поля з «шапки» документу, за якими документ індексувався в архіві, а й результати повнотекстового розпізнавання, щоб була можливість потім знайти документ по ключовому слову з основної частини.
 
Під FlexiCapture вже давно є можливість налаштувати експорт розпізнаних документів в PDF з текстовим шаром. Але реальність така, що багато зовнішні інформаційні системи не вміють шукати по PDF-документам. Більш того, що стосується саме новосибірського архіву, який зберігає дані з початку 1920-х років — багато паперові першоджерела, які ми бачили, представляли собою досить ветхі, вицвілі сторінки, віддруковані на друкарській машинці. Можна очікувати, що результати автоматичного розпізнавання для таких файлів можуть бути не дуже якісними. У той же час саме текстовий вміст такого архівного документа, а не його шапка, може бути дуже важливо. Тому добре б мати можливість під FlexiCapture на етапі перевірки важливих даних (в нашому випадку це були номер наказу, дата і т.д.) перевірити ще й результати повнотекстового розпізнавання.
 
Рішення знайшлося. Під FlexiLayout Studio (про це інструменті для створення гнучких описів ми вже писали ) можна створити гнучке опис документа, яке дозволить, крім значущих структурованих даних, витягувати ще й весь текстовий шар документа. Робиться це дуже просто — наприклад, за допомогою повторюваної групи, яка містить всі рядки документа.
 
Якщо необхідно, цей текстовий шар можна навіть перевірити на станції верифікації FlexiCapture. Також текст можна буде копіювати, індексувати і експортувати в текстові формати. В підсумковому PDF-документі ми отримаємо більш якісний результат розпізнавання текстового шару, так як цей результат буде перевірений оператором.
 
Нижче наведено скріншот зі сторінки верифікації ABBYY FlexiCapture. Як ми бачимо, тепер можна працювати не тільки з полями, а й з усім текстом в документі.
 
 
 

Спасибо за терпіння увагу, залишилося всього 3 пропозиції

Ми привели кілька інженерних Лайфхак, які, сподіваємося, допоможуть вам в роботі з нашим продуктом.
Якщо є, що додати — ви вирішили якусь ще нестандартну проблему за допомогою FlexiCapture — ми будемо раді почитати про це в коментарях.
 
 Тетяна Ганьжіна, ABBYY Росія
при активній підтримці фахівців «АТАПІ Софтвер».

    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.