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