Распознавание сканов: как проверить текст перед обработкой

Скан распознан, текст появился, ошибок программа не показала. Можно ли сразу переносить номер, дату и сумму в учётную систему? Нет: успешное завершение распознавания означает только то, что система сформировала результат.

Проверка нужна в двух местах. Сначала оценивают сам скан: все ли страницы на месте, не обрезаны ли поля, читаются ли символы. Затем распознанный текст сопоставляют с изображением и правилами документа.

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

Что проверить в исходном скане?

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

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

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

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

Какие ошибки опаснее обычной опечатки?

Не все фрагменты требуют одинакового внимания. В счёте критичны номер, дата, ИНН, итоговая сумма и ставка налога. В акте к ним добавляются стороны и период. В заявлении важными могут быть ФИО, адрес, идентификатор и отметка о выборе варианта.

Особенно внимательно проверяют похожие символы: 0 и О, 1 и I, 5 и S, 8 и В. Отдельный риск создают десятичные разделители, знак минуса, пробелы внутри чисел и перенос реквизита на следующую строку.

Допустим, на скане указана сумма 18 450,00, а система вернула 18 450,80. Текст выглядит правдоподобно, словарь не находит ошибки, но запись уже отличается от документа. Такая ошибка обнаруживается только проверкой поля по изображению или контрольным расчётом.

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

Как построить проверку перед автоматической обработкой?

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

Затем примените проверки, не зависящие от распознавания. Итог можно сверить с суммой строк, дату — с допустимым периодом, ИНН — с форматом и контрольными разрядами, номер договора — со справочником. Такие правила не исправляют текст, а находят противоречия.

Некоторые системы возвращают для слов оценку уверенности и координаты на странице. Tesseract, например, включает эти данные в TSV и hOCR. Низкая оценка помогает направить фрагмент на проверку, но высокая не доказывает правильность: правдоподобная цифра тоже может быть распознана неверно.

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

Его подбирают на собственном наборе документов с реальными вариантами сканов. Официальные рекомендации Microsoft также предлагают оценивать качество на материалах рабочего процесса и по результатам определять, что принимать автоматически, а что отправлять человеку.

Удобный маршрут выглядит так:

1. Файл проходит проверку формата, числа страниц и качества изображения.
2. Система распознаёт текст, поля и их расположение.
3. Форматные и смысловые правила отмечают противоречия.
4. Критичные или сомнительные поля сверяет сотрудник.
5. В рабочую систему передаётся проверенная версия вместе со ссылкой на исходник.

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

Когда результат можно считать проверенным?

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

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

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

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

Источники

• Improving the quality of the output — Tesseract documentation
• Command Line Usage — Tesseract documentation
• Transparency note for Document Intelligence — Microsoft