Почему OCR документов ломается на фото с телефона
Скан и фото телефона — два разных входа для OCR документов. У скана геометрия листа предсказуема, освещение ровное, фон белый. На фото всё это нужно сначала восстановить — и каждая ошибка восстановления уходит дальше по цепочке и превращается в ошибки распознавания полей.
Первый шаг — детекция документа на снимке: алгоритм ищет четыре угла и границы листа. Но кадр часто сделан на столе с текстурой, папке или другом листе: градиент фона сливается с бумагой, край обрезан, палец лежит на углу. Если контур найден неверно, дальше выпрямляется не тот прямоугольник.
Коррекция перспективы пересчитывает кадр в плоскость листа. При съёмке под острым углом верх строки сжат иначе, чем низ; после выпрямления пропорции символов растягиваются, а мелкий шрифт в шапке бланка теряет разборчивость. Сильнее всего страдают узкие символы — единицы, скобки, дефисы, — а из них и состоят номера и даты.
Тени и блики ломают уже подготовку изображения к распознаванию: локальное затемнение от корпуса телефона даёт ложные залитые пятна, блик стирает штрихи подписей и печатей. Мятый бланк добавляет искривления строк, а слипшиеся страницы — перекрытие, из которого распознаватель тянет текст соседнего документа.
На выходе получается не «нечитаемый файл», а правдоподобные ошибки: 8 вместо 3, слипание двух строк в одну, потерянная строка таблицы. Такие сбои не видны при беглом взгляде на результат — поэтому разбираем, как это закрывается.
Что даёт управляемый конвейер распознавания
Доля автоматического извлечения полей считается отдельно по каждому типу: печатные реквизиты и табличные блоки требуют разных порогов уверенности. Мы не сводим их в один порог, а задаём правила — типовые поля уходят в систему без оператора, спорные попадают в очередь проверки. Распознавание строится слоями: Tesseract как один из движков, рядом — детекция областей, сверка со справочниками и проверка контрольных сумм.
Сокращение ручного ввода даёт не понижение порогов, а сортировка очереди: оператор видит сначала документы с наибольшим числом сомнительных полей. Каждое подтверждение сохраняется и работает как разметка для дообучения — доля ручных правок на тех же типах документов падает.
Стабильность распознавания закладывается до самого распознавания. Детекция границ, выравнивание перспективы и нормализация яркости по локальным областям снимают класс отказов, который давали снимки с телефона: блики, перекос, тени, мятая бумага. Документ перестаёт уходить оператору целиком из-за одного плохо снятого угла.
Время обработки пакета документов определяется раскладкой нагрузки: страницы идут параллельно, нечитаемые отбраковываются до распознавания, результаты кэшируются по отпечатку снимка. Пакет в несколько сотен фото перестаёт быть задачей на ночь. Эффект замеряем на размеченном наборе — доля верных извлечений, доля ручных правок и время пакета; каждая доработка конвейера проходит проверку на регресс.
Способы распознавания: облако, локальный контур, гибрид
Выбор между облаком и локальным контуром — не вопрос вкуса, а следствие требований к данным, объёму потока и допустимой задержке ответа. Облачное распознавание даёт свежие модели без своего оборудования, но документ покидает ваш периметр. Локальный контур держит данные внутри, зато качество модели и её обновление целиком на вашей стороне. Гибридная схема разделяет поток: чувствительные страницы обрабатываются в контуре, массовые типовые уходят наружу.
На практике вариант закрепляется правилом маршрутизации — по типу документа, метке конфиденциальности и требуемому времени ответа. Ниже — признаки, по которым мы разводим подходы, и где у каждого начинаются границы.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Облачное распознавание | Разрозненные типы документов, невысокий и неравномерный поток, нужен быстрый старт и распознавание рукописных полей | Данные выходят за периметр, задержка зависит от канала связи, качество меняется при обновлении модели на стороне сервиса |
| Локальный контур обработки | Персональные данные, коммерческая тайна, требования регулятора хранить документы внутри | Нужны собственные вычислительные мощности, обновление моделей и мониторинг качества — на вас, старт дольше |
| Гибридная схема | Смешанный поток: часть документов закрыта, часть типовая и массовая | Сложнее эксплуатация: два контура, единая очередь и правило маршрутизации требуют отдельной отладки |
Отдельно проверяем то, что чаще всего всплывает на приёмке: качество на реальных сканах и предсказуемость времени ответа при пиковой нагрузке. Для действующего документооборота добавляем к каждому варианту измеримую планку — долю полей, извлечённых без ручной правки, — и уже по ней сравниваем подходы между собой.
Этапы внедрения: от аудита образцов до передачи
Работу ведём этапами: каждый следующий опирается на подтверждённый предыдущий, поэтому слабое место всплывает на своей стадии, а не на приёмке. Ниже — что делаем на каждом шаге и какой результат считаем пропуском дальше.
- Аудит образцов документов. Собираем 150–300 реальных снимков из вашего потока: разные камеры, ракурсы, освещение, износ бланка. По ним фиксируем классы дефектов — блики, перспективные искажения, слипшийся текст — и согласуем целевое качество по каждому реквизиту.
- Разметка эталонного набора. На тех же образцах размечаем поля, границы таблиц и ключевые реквизиты. Набор делим на обучающую и отложенную части, чтобы одна страница не попала в обе.
- Предобработка и детекция. Выравниваем геометрию снимка, нормализуем контраст, находим зоны документа, распознаём текст и структуру таблиц.
- Правила и постобработка. Приводим значения к справочникам, сверяем контрольные суммы, отсекаем логически невозможные сочетания. Сомнительное поле уходит на ручную сверку, а не в молчаливую ошибку.
- Проверка на отложенных данных. Считаем точность по каждому полю отдельно и разбираем худшие страницы, а не только средний результат. Дальше двигаемся, если ключевые реквизиты держат согласованный уровень.
- Передача решения в эксплуатацию. Разворачиваем у вас или у нас, отдаём схему обработки, регламент ручной сверки, доступы и инструкции, обучаем вашу команду. Первый месяц сопровождаем и дообучаем на новых образцах.
Границы этапов — контрольные точки: после каждого вы видите измеримый результат и решаете, продолжать ли в том же виде.
Конфигурации, схемы и регламенты в поставке
Поставка не заканчивается тем, что распознавание заработало на вашем потоке фото. Все настройки, схемы и правила остаются у вас в виде файлов — команда сопровождения меняет конфигурацию под новые типы документов, не обращаясь к нам.
- Схема конвейера обработки: приём снимка, детекция границ документа в кадре, выравнивание перспективы, подготовка к распознаванию, разбор полей, проверка результата — с указанием, что логируется на каждом шаге и где чаще всего теряется точность.
- Словарь типов документов: перечень классов с образцами, для каждого — свой набор полей, допустимые ориентации, признаки обязательных и необязательных реквизитов.
- Конфигурации этапов: параметры детекции и коррекции, пороги уверенности, при которых документ автоматически уходит на ручную проверку, а не в базу.
- Регламент разметки: как обводятся поля на эталонных сканах, требования к фону и освещению при съёмке, порядок добавления нового типа документа без пересборки всей логики.
- Контроль качества распознавания: набор эталонных документов с заранее выверенными значениями, метрики по каждому полю (доля верных символов, доля полностью верных реквизитов), обязательный прогон после любой правки настроек.
- Схема маршрутизации ошибок: что происходит при низкой уверенности — очередь оператора, запрос повторного снимка или отказ с понятной причиной для пользователя.
- Мониторинг и журнал: какие события пишутся, как отличить деградацию на отдельных типах бланков от систематически плохих фото на входе.
- Инструкция по эксплуатации: развёртывание, обновление словаря типов, откат настроек к предыдущему рабочему набору.
Такой комплект позволяет развивать OCR документов своими силами и понимать, почему конкретный снимок распознан именно так.
Кейс: распознавание архива договоров и накладных
Заказчик — оптовый поставщик с архивом договоров, счетов и накладных за несколько лет: около двухсот тысяч страниц, часть — фотографии с телефона под углом и при плохом свете. Текущий поток — порядка двух тысяч документов в месяц, и до нас реквизиты вносили в учётную систему вручную: оператор разбирал пакет почти за смену, а расхождения всплывали уже на сверке с поставщиком.
Мы собрали конвейер: детекция границ листа и перспективная коррекция, отсечение фона, поиск зон реквизитов по шаблону документа, распознавание и постобработка — контрольные суммы, сверка суммы цифрами и прописью, нормализация дат и нумерации. Распознавание построено на открытом движке Tesseract с моделью, дообученной на их шаблонах накладных, а правила валидации отсекают сомнительные поля до попадания в систему.
Каждый файл получает хеш содержимого: задача ставится в очередь обработки ровно один раз, и ночная догрузка тех же сканов не запускает распознавание заново. Пакет из тысячи страниц разбирается параллельно на нескольких узлах, оператору уходят только те поля, где правила валидации не сошлись.
Доля полей, попавших в систему без оператора, выросла с 58 до 93 процентов. Время обработки пакета в тысячу страниц сократилось с половины смены до нескольких минут, повторные прогоны распознавания упали с 15 до 2 процентов — раньше документ перезапускали при любой правке шаблона. Архив разобрали пакетами, не останавливая текущий документооборот.
Что делать, если распознавание внедрено частично
Частично внедрённый модуль обычно выглядит так: вызов распознавания есть, а конвейера вокруг него нет. Изображение уходит в модель как есть, возвращается сырым текстом, и дальше документ живёт в учётной системе отдельно от того, что увидела модель. На сканах хорошего качества схема держится, на фото с телефона — рассыпается.
Разбираем контур по этапам и ищем, где именно теряется качество. Чаще всего провал не в самой модели, а перед ней: не выровнены границы листа, не убраны тени и блики, в кадре лишние объекты. Замена модуля распознавания — последний шаг, а не первый: сначала закрываем предобработку и контроль качества, иначе новая модель получит на входе тот же мусор.
Отдельная ветка — дообучение на своих образцах. Собираем корпус реальных фото, включая отказы и ручные правки операторов, размечаем поля и измеряем качество на отложенной выборке по каждому типу документа, а не средним числом. Открытые движки вроде Tesseract удобны как эталон и как база для дообучения под ваш бланк, шрифт и условия съёмки.
Интеграция с текущим контуром — это про надёжность. Обработка должна быть идемпотентной, повторы после сбоя — безопасными, у каждой версии модели — свой журнал и откат. Перед переключением трафика прогоняем новую схему в теневом режиме и сверяем расхождения по полям.
Достраивать конвейер дешевле, чем переписывать: меняются два-три этапа, остальное продолжает работать.
OCR документов: технические сомнения инженеров
Точность OCR — не одно число, а распределение по типам документов: считаем её отдельно по символам и по полям, потому что перепутанный знак в номере договора обесценивает всю запись, а лишний пробел в адресе — нет. Перед распознаванием идёт детекция границ и коррекция — выравнивание перекоса, устранение перспективы, нормализация контраста; без этого модель теряет проценты на тенях и наклоне, а не на тексте.
Какой точности распознавания реально ждать?
На печатных формах полевая точность доходит до 97–99%, на фото с телефона ниже: мешают блики, смаз и геометрия. Следим не за средней цифрой по потоку, а за точностью критичных реквизитов и долей полей, ушедших на проверку.
Распознаётся ли рукописный текст?
Печатные буквы от руки — да, предсказуемо. Слитный курсив и подписи — нет. Такие поля распознаются с пониженным порогом уверенности и отдаются оператору, а сверка со справочником ФИО и названий организаций снижает число ошибок в разы.
Как обрабатываются печати и подписи?
Их не читают как текст: детектируется наличие, положение и перекрытие со значимыми полями. Если печать ложится поверх реквизита, поле помечается сомнительным и уходит оператору первым — брак не идёт дальше по учёту.
Как проверяется качество распознавания?
Держим регресс-набор реальных сканов с эталонной разметкой: перед обновлением модели считаем полевую точность, полноту и число расхождений. Для старта хватает нескольких сотен размеченных примеров на тип формы, дальше набор растёт за счёт спорных случаев из потока.
Обсудим задачу распознавания и вернёмся с планом
Разбор начинается с образцов, а не с общих слов: по фотографиям с разных камер видно, где именно ломается распознавание — на качестве съёмки, геометрии листа или структуре таблиц. Поэтому начните с описания задачи и передайте образцы документов; оценка объёма потока без них будет гаданием.
Что прислать для разбора:
- 15–20 образцов в том виде, в каком они реально попадают в систему — сканы, фото со смартфона, съёмка под углом, с тенями и бликами.
- Оценку объёма потока: сколько страниц в день в среднем и в пик, сколько типов документов и как часто появляются новые.
- Перечень полей, которые нужно извлечь, с пометкой обязательных и необязательных, плюс примеры нестандартных значений.
- Требования к точности по каждому полю и допустимую долю документов, уходящих на ручную проверку.
- Описание систем, куда уходит результат, и ограничения по доступам, хранению и обработке персональных данных.
- Примеры того, что уже не получилось: предыдущие попытки распознавания, правила и шаблоны, которые не сработали.
В ответ вернём оценку объёма потока в страницах и часах машинного времени, состав этапов работ, предварительный план с точками проверки и критерии приёмки на ваших же образцах. Опишите задачу — обсудим её предметно и вернёмся с оценкой и планом.
