Чому OCR ламається на реальних сканах, знімках і PDF
Демонстрація OCR на рівному скані й робота на живому потоці документів — дві різні задачі.
Щойно в потік потрапляють фотографії зі смартфона, копії третього-четвертого прогону та скани з плоским освітленням, точність розпізнавання тексту на зображеннях падає: рядки читаються, але склад полів і цифри роз'їжджаються. Причина не в моделі як такій, а в тому, що якість сканів ніхто не перевіряв до інференсу.
Перша група збоїв — геометрія і світло. Нахил у кілька градусів і перспектива під час зйомки під кутом розбивають рядок на фрагменти, а тіні від руки та відблиски від лампи роблять освітленість нерівномірною по кадру.
Поріг бінаризації, підібраний по всьому зображенню, у затемненій половині з'їдає тонкі штрихи, а у світлій — залишає шум.
Попередня обробка зображень тут обов'язкова: вирівнювання перспективи за межами аркуша, придушення тіні, локальна оцінка фону й адаптивна бінаризація зі збереженням засічок.
Друга група — контраст і деградація носія. Вицвілий текст, просвічувальний зворотний бік, сірий фон і дрібний шрифт виноски дають розрив між чорнилом і папером у лічені градації яскравості.
Модель, навчена на контрастних зразках, починає плутати схожі символи й губити розділові знаки, а на цифрах це коштує найдорожче.
Третя група — змішаний контент у документі.
Складені таблиці з об'єднаними комірками, шапки й повторювані колонтитули, печатки й підписи, рукописні позначки поверх друкованого тексту, а також дві мови в одному полі створюють неоднозначну розмітку: де закінчується зона і до якого атрибута належить значення. Просте читання символів без детекції блоків і логіки полів тут не допомагає.
Звідси правило: спочатку оцінюємо реальний корпус, потім будуємо ланцюжок — попередня обробка, детекція зон, розпізнавання, валідація за форматом і контрольними сумами. Розбираємо, як це закривається.
Ефект впровадження: частка автозаповнення, швидкість, клас відмов
До старту ми знімаємо базові метрики OCR на реальному архіві замовника: частка документів, які проходять без оператора, час обробки пачки та якість вилучення за кожним полем окремо.
Точка відліку потрібна, щоб «стало краще» можна було перевірити, а не відчути: спірне поле на кшталт номера договору або дати тягне підсумок вниз непомітно.
Частка автоматичного розбору на однотипних формах зростає з 55–65% до 85–93%. Залишковий хвіст — не «погана система», а документи, де нечитабельне саме джерело: перекошений скан, пляма, рукописна правка. Їх відправляємо оператору за порогом упевненості, а не всю пачку цілком.
Швидкість обробки документів змінюється нелінійно: пачка в кілька сотень сторінок переходить із «годин роботи зміни» в хвилини машинного часу. Вузьке місце зміщується на розбір винятків, і оператор перестає бути обов'язковою ланкою основної гілки процесу.
Клас відмов змінюється якісно. Зникають помилки ручного введення: перестановка цифр, втрата рядка таблиці, розходження рядка з контрольним значенням. Залишаються помилки прив'язки поля до типу документа або застарілого довідника — їх ловлять правила звірки, а не очі оператора.
Якість вилучення полів вважаємо окремо за кожним полем: одне дає 99%, інше просідає через вільний формат.
Схему збираємо гібридною — Tesseract на чистих друкованих бланках, донавчена модель на складних сканах, — тому відсоток автозаповнення передбачуваний, а список винятків скорочується в міру накопичення правок.
Режими роботи OCR-сервісу: пакетний, потоковий, гібридний
Режим роботи вибирають не за якістю розпізнавання, а за профілем потоку: звідки надходять документи, чи допустима затримка, що робити з невпевнено розпізнаними полями.
На демонстрації всі варіанти виглядають однаково — на реальному обсязі різниця видна в довжині черги, частці ручних правок і в тому, чи можна перезапустити прогін, не втративши вже готові результати.
Порівняння режимів
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Пакетний (архів) | Вивантаження за період, ретроспективна оцифровка, нічні прогони за накопиченим масивом | Результат віддається цілком: окремий документ із середини черги не витягнути, правка помилки зачіпає весь прогін |
| Потоковий | Безперервний вхідний потік — сканери на потоці, поштові скриньки, мережеві папки | Потрібні контроль черги й повторні спроби; на піках зростає затримка, частина документів чекає розбору |
| За запитом | Поодинокі документи з інтерфейсу або зовнішньої системи, коли відповідь потрібна негайно | Дорожче за документ, погано переносить сплески, не накопичує контекст за однотипними бланками |
| Гібридний з верифікацією | Змішаний потік і поля, де ціна помилки висока | Складніше налаштування порогів упевненості та маршрутів: частина полів іде оператору |
Обмеження режимів не взаємовиключні: пакет і потік часто живуть в одному OCR-сервісі, а розпізнавання за запитом закриває разові документи із зовнішніх систем.
Найчастіше ми зупиняємося на гібридному режимі: автоматика обробляє весь потік, а на ручну перевірку йдуть лише поля з низькою впевненістю та документи, що не пройшли валідацію за довідниками й контрольними сумами.
Частка таких полів — одиниці відсотків, і саме її ми закладаємо в розрахунок навантаження на операторів, а не середню якість на тестовій вибірці.
Етапи впровадження: від аудиту корпусу документів до регламентів
Починаємо не з моделі, а з корпусу: розкид форматів, якість сканів, рукописні позначки й печатки поверх тексту визначають, які кроки знадобляться. Схему обробки документів збираємо до налаштування розпізнавання, а не після.
- Аудит корпусу документів. Розбираємо вибірку за типами бланків, якістю сканів і мовами, рахуємо частки — отримуємо перелік класів, які система зобов'язана тримати.
- Схема обробки документів. Фіксуємо шлях файлу: приймання, розбір сторінок, попередня обробка (вирівнювання, знебарвлення фону, придушення шуму), розпізнавання, вилучення полів, запис у цільову систему й журнал операцій.
- Еталонна вибірка. Частину сторінок розмічаємо вручну й заморожуємо — на ній вимірюємо якість і порівнюємо версії, не підганяючи результат під поточний потік.
- Налаштування вилучення полів. Збираємо шаблони зон, словники й перевірки контрольних сум: поле вважається вилученим, лише коли сходяться кілька незалежних ознак.
- Перевірка якості. Рахуємо точність за символами й за полями окремо, розкладаємо помилки за класами: якість скану, нестандартна верстка, рукописне введення.
- Приймання розпізнавання. Прогін на відкладеній частині корпусу за критеріями, зафіксованими заздалегідь; нижче порога документ автоматично йде оператору на звірку.
- Передача регламентів. Віддаємо схему потоку, конфігурації, опис класів помилок та інструкції операторам — донавчання й розбір збоїв ідуть без нас.
Порядок тримає ризик під контролем: проблемний клас документів видно на етапі перевірки, а не після запуску в роботу.
Конфігурації, схеми потоків і регламенти: артефакти проєкту
Після здачі у замовника залишається не «модель у хмарі», а робочий комплект артефактів, із яким чергова команда супроводу працює без нас. Усе лежить у репозиторії замовника з історією змін, тому будь-яке рішення можна відкотити, а не відновлювати за листуванням.
- Конфігурація розпізнавання. Окремі профілі під кожен тип документа: обов'язкові поля, поріг упевненості для автоприймання, правила постобробки — формати дат і номерів, перехресні перевірки сум. Поруч набір еталонних сторінок, на якому конфігурація проганяється після будь-якої зміни.
- Схема потоку документів. Від точки входу (сканер, пошта, папка обміну) через попередню обробку й розпізнавання до вивантаження в облікову систему. На схемі позначені черги повторів і те, що відбувається з документом, який не пройшов перевірку.
- Політики доступу до даних. Розмежування ролей: хто бачить вихідне зображення, хто — лише вилучені поля. Терміни зберігання оригіналів, правила знеособлення, журнал звернень до персональних даних.
- Інструкція оператора. Як влаштована черга на ручну перевірку, як виправляється поле, які розходження вважаються критичними і в якому разі документ іде на друге коло.
- Регламент розбору спірних полів. Критерії «прийнято автоматично / потребує перевірки», норматив часу на ручний розбір, кому адресується конфлікт і як правка оператора повертається у вибірку для донавчання.
- Експлуатаційна документація й моніторинг. Розгортання контурів, резервне копіювання, порядок оновлення шаблонів із відкатом на попередню версію; метрики — частка документів, розібраних без людини, точність за кожним типом, сплеск відмов на конкретному шаблоні.
Кейс: OCR-система скоротила ручне введення в шість разів
До: ручна перевірка тримала потік
На вході — потік вхідних документів близько 4 000 сторінок на добу: заяви, акти, реквізити. Форми однотипні, але якість сканів різна — повторні копії, косі знімки з телефона.
Розпізнавання працювало на типовому налаштуванні Tesseract: движок віддавав текст, а рішення за ним ухвалював оператор.
Частка ручного введення сягала 62%, пачка в 500 сторінок ішла в роботу за три зміни, кожен п'ятий документ вважався спірним і розбирався цілком — хоча помилка була в одному полі з десяти.
Що змінили і що вийшло
Задачу розділили на два кроки: детекція зон, потім розпізнавання всередині зони та вилучення полів.
Підготували розмітку на минулих документах замовника, додали попередню обробку — вирівнювання, придушення шуму, бінаризацію — і правила перевірки: контрольні суми, звірку пов'язаних полів, поріг упевненості. Нижче порога документ іде оператору не цілком, а з підсвіченим спірним фрагментом.
Частка ручного введення — з 62% до 10%. Пачка з 500 сторінок — із трьох змін до 50 хвилин. Спірні документи — з 20% до 4%, і в них виправляється одне поле, а не передруковується бланк.
Кожне розпізнане поле пишеться в журнал разом із версією моделі та ознаками рішення: за помилкою видно, на якому кроці вона виникла, а відкат на попередню версію займає хвилини.
Чим OCR друкованого тексту відрізняється від розпізнавання рукопису
Розпізнавання друкованого тексту спирається на повторювані гліфи: шрифт у документі фіксований, накреслення збігаються, тому вибірка для навчання набирається синтетично, а спірні випадки знімаються словником предметної області.
Помилки тут передбачувані — плутанина схожих символів, розриви за слабкого сканування — і закриваються перевіркою за шаблоном поля: серія документа, дата, сума. Достатньо рівного освітлення й стабільної висоти рядка, щоб результат не доводилося правити руками.
Рукописний текст так не працює. Накреслення змінюється всередині одного почерку: нахил, злитність і натиск залежать від того, хто пише, інструмента й того, наскільки швидко заповнювали бланк.
Універсальної вибірки не існує, тому розпізнавання рукописного тексту починається з розмітки навчальних даних на зразках саме ваших документів — без неї модель упевнено видає неправильні символи на незнайомому почерку.
Вимоги до знімка розходяться ще сильніше. Для друку достатньо рівномірного підсвічування й контрасту, що відокремлює текст від фону.
У рукописі губляться не рядки, а перемички всередині букв: відблиск, тінь від руки або зйомка під кутом перетворюють «ш» на «и», і за контекстом це відновлюється не завжди. Звідси жорсткі умови до площини аркуша й світла на етапі зйомки, а не на етапі обробки.
Тому в обох випадках — але з різною частотою — працює підтвердження невпевнених полів. Система віддає не лише значення, а й оцінку впевненості, а все, що нижче порога, йде оператору на звірку.
Ці самі спірні фрагменти стають матеріалом для розмітки наступної версії, і частка ручних підтверджень поступово падає. Планувати навантаження на операторів варто за своїм типом документів, а не за чужим досвідом з іншими бланками.
Технічні сумніви: точність, контур даних, обсяги
Інженерні сумніви зазвичай зводяться до чотирьох речей: що буде на брудних сканах, чи можна тримати систему всередині контуру, чи витримає вона зростання обсягів і що робити при зміні форми документа. Розбираємо кожен пункт предметно.
Що буде на поганих сканах — перекосах, шумі, рукописних позначках?
Конвеєр іде в кілька проходів: вирівнювання й бінаризація, детекція зон, розпізнавання з оцінкою впевненості за кожним полем. Поля нижче порога йдуть у чергу ручної перевірки, а не у вивантаження.
Чи можна розгорнути систему всередині нашого контуру?
Так — у закритому контурі замовника, без звернень до зовнішніх сервісів. Зображення й результати не покидають периметр, доступи розведені за ролями, кожна обробка потрапляє в журнал. Це закриває вимоги щодо захисту персональних даних і спрощує внутрішній аудит.
Чи витримає рішення зростання обсягів?
Масштабування горизонтальне: під чергу додаються обробники, логіка не переписується. Потік у сотні тисяч сторінок на добу йде тим самим конвеєром, час на документ залишається стабільним, а піки розбирає черга з пріоритетами.
Що робити, якщо форма документа змінилася?
Шаблон описуємо декларативно: склад полів, координати, правила валідації. При зміні форми правиться конфігурація, а не код розпізнавання — новий шаблон підхоплюється на льоту, архівні документи обробляються за попередньою розміткою.
Обговоримо задачу: що потрібно для старту розпізнавання
Оцінка розпізнавання тримається на ваших документах, а не на демо-сканах. Ми дивимося на реальні бланки — з нахилом, відблисками, печатками поверх тексту — і говоримо, яка частка полів розпізнається впевнено, де потрібна ручна перевірка і як це позначиться на потоці. Тому до розмови варто підготувати:
- Зразки документів — 15–20 сканів із різних джерел: сканер, фото з телефона, факс, старі копії.
- Очікуваний потік — скільки сторінок на день у середньому і скільки в пікові години.
- Вимоги до контуру — де мають зберігатися дані: ваш сервер, закрита мережа або зовнішній сервіс.
- Формат вивантаження даних — табличний файл, обмін з обліковою системою, які поля обов'язкові і куди вони йдуть далі.
- Ролі користувачів — хто завантажує документи, хто перевіряє спірні поля, хто бачить звіти про помилки.
- Правила розбору — що вважати помилкою розпізнавання, які поля критичні, що робити з нечитабельними сторінками.
За цими ввідними ми повертаємося з оцінкою та планом робіт: етапи, терміни, що робимо на кожному кроці і на якому етапі ви побачите перший результат на своїх документах. Опишіть задачу розпізнавання — цього набору достатньо, щоб розмова була предметною.
