Разработка OCR-системы распознавания текста на изображениях

Почему OCR ломается на реальных сканах, снимках и PDF

Демонстрация OCR на ровном скане и работа на живом потоке документов — две разные задачи. Как только в поток попадают фотографии со смартфона, копии третьего-четвёртого прогона и сканы с плоским освещением, точность распознавания текста на изображениях падает: строки читаются, но состав полей и цифры разъезжаются. Причина не в модели как таковой, а в том, что качество сканов никто не проверял до инференса.

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

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

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

Отсюда правило: сначала оцениваем реальный корпус, потом строим цепочку — предобработка, детекция зон, распознавание, валидация по формату и контрольным суммам. Разбираем, как это закрывается.

Эффект внедрения: доля автозаполнения, скорость, класс отказов

До старта мы снимаем базовые метрики OCR на реальном архиве заказчика: доля документов, которые проходят без оператора, время обработки пачки и качество извлечения по каждому полю отдельно. Точка отсчёта нужна, чтобы «стало лучше» можно было проверить, а не почувствовать: спорное поле вроде номера договора или даты тянет итог вниз незаметно.

Доля автоматического разбора на однотипных формах вырастает с 55–65% до 85–93%. Оставшийся хвост — не «плохая система», а документы, где нечитаем сам источник: перекошенный скан, пятно, рукописная правка. Их отправляем оператору по порогу уверенности, а не всю пачку целиком.

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

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

Качество извлечения полей считаем отдельно по каждому полю: одно даёт 99%, другое проседает из-за свободного формата. Схему собираем гибридной — Tesseract на чистых печатных бланках, дообученная модель на сложных сканах, — поэтому процент автозаполнения предсказуем, а список исключений сокращается по мере накопления правок.

Режимы работы OCR-сервиса: пакетный, потоковый, гибридный

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

Сравнение режимов

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

Этапы внедрения: от аудита корпуса документов до регламентов

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

1. Аудит корпуса документов. Разбираем выборку по типам бланков, качеству сканов и языкам, считаем доли — получаем перечень классов, которые система обязана держать.
2. Схема обработки документов. Фиксируем путь файла: приём, разбор страниц, предобработка (выравнивание, обесцвечивание фона, подавление шума), распознавание, извлечение полей, запись в целевую систему и журнал операций.
3. Эталонная выборка. Часть страниц размечаем вручную и замораживаем — на ней измеряем качество и сравниваем версии, не подгоняя результат под текущий поток.
4. Настройка извлечения полей. Собираем шаблоны зон, словари и проверки контрольных сумм: поле считается извлечённым, только когда сходятся несколько независимых признаков.
5. Проверка качества. Считаем точность по символам и по полям отдельно, раскладываем ошибки по классам: качество скана, нестандартная вёрстка, рукописный ввод.
6. Приёмка распознавания. Прогон на отложенной части корпуса по критериям, зафиксированным заранее; ниже порога документ автоматически уходит оператору на сверку.
7. Передача регламентов. Отдаём схему потока, конфигурации, описание классов ошибок и инструкции операторам — дообучение и разбор сбоев идут без нас.

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

Конфигурации, схемы потоков и регламенты: артефакты проекта

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

• Конфигурация распознавания. Отдельные профили под каждый тип документа: обязательные поля, порог уверенности для автоприёма, правила постобработки — форматы дат и номеров, перекрёстные проверки сумм. Рядом набор эталонных страниц, на котором конфигурация прогоняется после любого изменения.
• Схема потока документов. От точки входа (сканер, почта, папка обмена) через предобработку и распознавание до выгрузки в учётную систему. На схеме отмечены очереди повторов и то, что происходит с документом, не прошедшим проверку.
• Политики доступа к данным. Разграничение ролей: кто видит исходное изображение, кто — только извлечённые поля. Сроки хранения оригиналов, правила обезличивания, журнал обращений к персональным данным.
• Инструкция оператора. Как устроена очередь на ручную проверку, как исправляется поле, какие расхождения считаются критичными и в каком случае документ уходит на второй круг.
• Регламент разбора спорных полей. Критерии «принято автоматически / требует проверки», норматив времени на ручной разбор, кому адресуется конфликт и как правка оператора возвращается в выборку для дообучения.
• Эксплуатационная документация и мониторинг. Развёртывание контуров, резервное копирование, порядок обновления шаблонов с откатом на предыдущую версию; метрики — доля документов, разобранных без человека, точность по каждому типу, всплеск отказов на конкретном шаблоне.

Кейс: OCR-система сократила ручной ввод в шесть раз

До: ручная проверка держала поток

На входе — поток входящих документов около 4 000 страниц в сутки: заявления, акты, реквизиты. Формы однотипные, но качество сканов разное — повторные копии, косые снимки с телефона. Распознавание работало на типовой настройке Tesseract: движок отдавал текст, а решение по нему принимал оператор. Доля ручного ввода доходила до 62%, пачка в 500 страниц уходила в работу за три смены, каждый пятый документ считался спорным и разбирался целиком — хотя ошибка была в одном поле из десяти.

Что изменили и что получилось

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

Доля ручного ввода — с 62% до 10%. Пачка из 500 страниц — с трёх смен до 50 минут. Спорные документы — с 20% до 4%, и в них правится одно поле, а не перепечатывается бланк. Каждое распознанное поле пишется в журнал вместе с версией модели и признаками решения: по ошибке видно, на каком шаге она возникла, а откат на прошлую версию занимает минуты.

Чем OCR печатного текста отличается от распознавания рукописи

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

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

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

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

Технические сомнения: точность, контур данных, объёмы

Инженерные сомнения обычно сводятся к четырём вещам: что будет на грязных сканах, можно ли держать систему внутри контура, выдержит ли она рост объёмов и что делать при смене формы документа. Разбираем каждый пункт предметно.

Можно ли развернуть систему внутри нашего контура?

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

Выдержит ли решение рост объёмов?

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

Что делать, если форма документа поменялась?

Шаблон описываем декларативно: состав полей, координаты, правила валидации. При смене формы правится конфигурация, а не код распознавания — новый шаблон подхватывается на лету, архивные документы обрабатываются по прежней разметке.

Обсудим задачу: что нужно для старта распознавания

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

• Образцы документов — 15–20 сканов из разных источников: сканер, фото с телефона, факс, старые копии.
• Ожидаемый поток — сколько страниц в день в среднем и сколько в пиковые часы.
• Требования к контуру — где должны храниться данные: ваш сервер, закрытая сеть или внешний сервис.
• Формат выгрузки данных — табличный файл, обмен с учётной системой, какие поля обязательны и куда они уходят дальше.
• Роли пользователей — кто загружает документы, кто проверяет спорные поля, кто видит отчёты по ошибкам.
• Правила разбора — что считать ошибкой распознавания, какие поля критичны, что делать с нечитаемыми страницами.

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