Post OCR Correction: как в Dbrain научились исправлять ошибки распознавания рукописных документов

Представьте, что произошло лёгкое ДТП. Вы с другим водителем мирно разошлись и заполнили на месте европротоколы.

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

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

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

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

Задачка не из простых. Один из способов, которые мы применяем, — это коррекция результатов OCR с помощью языковых моделей. Эти модели помогают «понять» текст на текстовом, а не визуальном уровне и исправить ошибки, основываясь на контексте. Пример: пишем неразборчивым почерком фразу «мама мыла раму». Распознаём с помощью модели и получаем «мома мыпа ралу». Но мы-то понимаем, что это известная скороговорка.

Обычные OCR (HTR) модели не делают подобных действий в явном виде. Их задача — понять, из каких комбинаций пикселей собраны рукописные буквы, и выдать нам в качестве ответа. Наша цель — сделать этап корректировки текста явным шагом и выделить под него отдельную языковую модель, которая только этим и будет заниматься: имитировать работу нашего мозга по исправлению ошибок в тексте.

Комбинация Text Detection + OCR (HTR) — это наш инструмент для «чтения» рукописного текста. Даём ему текст и просим вернуть логику по контексту, привычному для нашего мозга.

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

Мы подумали: а что, если начать с чего-то простого? Например, с прописей. Если просто выстроить буквы в ряд — снова получится шрифт. Тогда мы стали использовать кривые Безье, которые используются в компьютерной графике для рисования плавных изгибов. Они помогают нам контролировать создание каждой буквы и плавно соединять их между собой.

Вот так выглядит буква Ю:

Упс. То есть вот так она выглядит:

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

Вот так выглядит интерфейс редактирования кривых Безье для букв:

Весь сгенерированный алфавит, который мы взяли с Википедии в качестве эталонного примера прописей:

Сначала мы научились задавать параметры для каждой буквы алфавита, а потом стали генерировать тексты. Добавили небольшие вариации в параметры кривых Безье. Теперь можно сделать почерк пляшущим, строгим, размашистым — на любой вкус (даже как у врача). Буквы соединяются автоматически. А мы можем контролировать весь процесс.

Мы научились распознавать и такую писанину:

И такую:

Когда текст сгенерирован, мы рендерим его в формате SVG и получаем настоящие рукописные сочинения. Можно их конвертировать в PNG или JPEG и подавать на распознавание любым Text Detection / OCR / HTR моделям. И дальше исправлять ошибки с помощью Post-OCR Correction.

И вуаля! Мы генерируем массу текстов, собираем ошибки и обучаем языковую модель типа BERT на их исправлении. Получается своего рода перевод из ошибочного текста в корректный. Благодаря исправлениям помогаем сотрудникам тех же страховых быстрее работать с данными, выплачивать компенсации и увеличить клиентский поток.

Вот как коррекция работает на практике:

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

Для определения вклада POC модели в качество предсказаний мы считаем метрики на трех датасетах, два из которых открыты.

Student Essays — наш in-house датасет рукописных сочинений.

Мы измеряем метрики CAR (Character Accuracy Rate) и WAR (Word Accuracy Rate). Первая показывает, насколько хорошо мы узнаем символы в целом, а вторая — насколько хорошо угадываем слова. Чем выше метрики, тем лучше распознавание. Расчет метрик производится по трём методикам, чтобы понять, на какие именно символы влияет POC.

Методики:

Применяя Post-OCR коррекцию, мы часто видим увеличение метрики WAR, при этом метрика CAR либо незначительно растёт, либо падает. Когда видим слово с одной ошибкой, исправляем его на корректное и повышаем в большей степени WAR и совсем немного — CAR. Почему просаживается

CAR? У моделей распознавания текста иногда получаются совсем неуместные предсказания. При этом часть букв удаётся все-таки корректно распознать. Когда же алгоритм POC получает искаженное слово, он пытается слепить из него хоть какое-нибудь существующее слово, которое может сильно отличаться от того, что было написано. В итоге слово мы вроде попробовали исправить, но в процессе исправлений наделали ещё ошибок и CAR подпросел.

На датасете HWR200 видим улучшение WAR на всех типах изображений от 11% до 13%. При этом у CAR получаются просадки на 1-2%. На сканах просадка наименьшая, потому что наша система распознавания, в основном, заточена под сканы тетрадей. Чем больше допущений мы делаем, тем выше метрика. Распознать текст с учетом регистра сложнее, чем без его учета.

На тетрадях Сбербанка WAR увеличивается на 3-4%, а CAR просаживается на 4-5%. Это уже более существенно. На этом датасете задача распознавания рукописного текста более сложная. Там множество пометок от школьников и учителей, причём ручками разного цвета. Мы в обучении фокусировали модель на ручку чёрного цвета, но распознать можем и другие цвета написания.

Самые лучшие показатели мы получили на датасете сочинений. Именно на этих данных мы обучали модели. Здесь улучшились не только метрики WAR (7-12%), но и CAR (1%).

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

Начинали мы с европротоколов, а метрики на сочинениях показали для воспроизводимости. А вот где ещё POC может улучшить качество распознавания:

Если хотите больше технических подробностей и спецтерминов, читайте нашу статью на Arxiv.

Если к вам приходят люди с написанными от руки документами, которые нужно перенести в базу, лучше воспользоваться Post OCR Сorrection.

Записывайтесь к нам на демо продуктов в Dbrain, там расскажем все подробнее.