Оптическое распознавание символов (OCR) — одно из первых приложений машинного обучения. Набор данных MNIST, состоящий из изображений цифр от 0 до 9, является одним из эталонных наборов данных, который используется при попытке сравнить точность различных моделей классификации. В настоящее время существует множество механизмов OCR, которые могут точно извлекать текст из числового изображения документа.
Однако качество распознавания сильно зависит от качества самого документа. Документ с низким разрешением, низкой контрастностью, плохо отсканированным или иным образом трудно читаемым, скорее всего, будет иметь соответствующий вывод OCR с ненужными символами и, как правило, низкого качества.
Один из простых способов проверить качество вывода OCR — сравнить его с исходным документом (основная правда). Однако что делать, если наземная истина недоступна? Или что, если документов так много, что просмотр их по одному займет слишком много времени, и поэтому вам нужен инструмент для автоматического контроля качества в процедуре OCR? Я написал скрипт на Python, который пытается сделать именно это, и я буду описывать, как он работает и какие результаты он дает, в разделах ниже.
Методология
Сценарий принимает в качестве входных данных текст OCR из пакета документов и возвращает отдельные показатели и рейтинг качества для каждого документа в качестве выходных данных. В качестве первого шага скрипт загружает тексты OCR в python. Сценарий предоставляет несколько вариантов, таких как загрузка из одного текстового файла с использованием пользовательского разделителя для разделения текстов, загрузка всех файлов из заданного каталога или загрузка из базы данных MS Server с использованием пакета Python pymssql.
Как только тексты загружены, они обрабатываются один за другим и извлекаются соответствующие метрики. Для каждого текста скрипт извлекает общее количество символов, количество буквенно-цифровых символов, количество управляющих символов, количество специальных символов и количество символов Unicode. Текст также токенизируется, и извлекается общее количество токенов (группа символов, разделенных управляющими символами), не буквенно-цифровых токенов и токенов с символами Unicode. Сценарий также подсчитывает количество знаков препинания (например, запятых), разделяющих два слова (группы букв) без какого-либо управляющего символа между ними. Наконец, скрипт подсчитывает общее количество слов, среднюю длину слова, количество слов длиннее 4 символов и для каждого из этих более длинных слов определяет, встречаются ли они в списке примерно из 500 000 английских и немецких слов ( на данный момент эта функция работает только для этих двух языков, хотя можно добавить больше, соответствующим образом обновив список).
После извлечения всех метрик для каждого текста некоторые метрики при необходимости нормализуются (например, количество символов Unicode делится на общее количество символов) и вычисляются среднее значение и стандартное отклонение показателей по всем документам. Затем устанавливается рейтинг для каждого документа в зависимости от того, насколько далеко от среднего (с точки зрения стандартных отклонений) находится каждый показатель. Окончательная оценка представляет собой взвешенную сумму оценок каждой метрики, веса которых определяет пользователь.
Такой рейтинг относится к другим документам в пакете и не является попыткой классифицировать документы как имеющие хорошее или плохое качество распознавания в абсолютном выражении. Таким образом, преимущество заключается в том, что он не требует жесткого кодирования набора правил или использования обучения с учителем, что, в свою очередь, потребует создания обучающего набора документов с метками качества.
Одно предостережение заключается в том, что пакет документов должен быть достаточно большим, чтобы можно было определить среднее значение и стандартное отклонение для каждой метрики. Другое дело, что рейтинг говорит только о том, какие документы хуже или лучше. Таким образом, сценарий не может различать пакет документов OCR с плохим и хорошим качеством.
Я применил набор эмпирически определенных правил, чтобы качественно оценить OCR. Документ классифицируется как содержащий нетекстовые элементы (графики, изображения и т. д.), если он удовлетворяет следующему условию:
(Средняя длина слова ‹ 3) ИЛИ (символы Unicode › 10 % от общего числа) ИЛИ (специальные символы › 20 % буквенно-цифровых символов) ИЛИ (небуквенно-цифровые токены › 15 % от общего количества токенов)
Документ классифицируется как имеющий низкое качество OCR, если он удовлетворяет следующим требованиям:
(слова, не найденные в списке слов › 30% от общего числа) ИЛИ (слова, содержащие цифры или Unicode › 15% от общего количества) ИЛИ (слова, разделенные разделителями без управляющих символов между ними › 10% всех разделений слов)
Вывод
Результатом работы скрипта является файл .csv, содержащий по одной строке на каждый документ с идентификатором документа, значением каждой метрики и всеми связанными оценками. Документы перечислены в порядке кумулятивного рейтинга, причем документы с самым низким качеством перечислены первыми. Другой вывод в формате .txt содержит результаты классификации на основе правил (см. изображение ниже).
Возможные улучшения
Использование подхода к обучению с учителем для замены существующей системы, основанной на правилах, значительно улучшит классификацию документов, но, поскольку для этого требуется обучающий набор помеченных документов, у меня пока нет времени на его реализацию.
Подход к кластеризации обучения без учителя также интересен, поскольку он позволяет увидеть, какие категории документов OCR возникают из данных, вместо того, чтобы позволить человеку выбирать категории и вручную присваивать метки обучающему набору.
Я также рассматривал возможность внедрения дополнительных показателей, таких как использование библиотеки python langid для автоматического определения языка документа, а затем оценка каждой строки текста по значению достоверности, заданному langid для этого языка (более низкая достоверность может указывать на худшее качество оптического распознавания символов). ). Именно такой подход реализован в этой статье.
Другой метрикой будет оценка правильности биграмм, а не отдельных слов. Для этого потребуется больше данных, например, от Google N-gram, который также предлагает N-граммы на нескольких разных языках.
