Розпізнавання тексту в мобільному застосунку: де втрачається точність
Точність розпізнавання в мобільному застосунку рідко ламається на ідеальному скані — вона руйнується на тому, як документ реально знято.
Відблиск від лампи на глянцевій квитанції з’їдає половину рядка під час бінаризації, тінь від руки переводить ділянку в «сіре», і шар детекції тексту перестає бачити блоки.
Розбір, який на тестовому наборі давав 98%, на потоці з поля знижується до 80–85% — це вже не косметика, а ручне виправлення оператором. Кожен такий документ повертається в чергу, і точність розпізнавання перестає бути технічною метрикою — вона стає вузьким місцем процесу.
Геометрія додає своє: нахил у 10–15 градусів, заломи на згині, перспектива від зйомки під кутом. Лінійна корекція такі випадки не витягує — потрібна випрямляюча деформація за контурами сторінки, інакше рядки «пливуть» і символи склеюються.
Складні бланки — окремий клас помилок: поля з дрібним шрифтом, таблична сітка, змішані розкладки в одному рядку, де кирилиця стоїть поруч із латиницею та цифрами всередині слова.
Розбір упевнено читає заголовок і помиляється саме в номері поліса, який і потрібен обліковій системі.
Ціна передбачувана: зростає частка ручного введення, з’являються затримки в обробці, частина документів іде на повторну зйомку. Далі розбираємо, як будується контур зйомки документів і контроль точності розпізнавання, який це закриває.
Що змінюється після впровадження: швидкість, точність, автономність
Автоматизація ручного введення вимірюється не «зручністю», а часткою документів, які потрапляють в облік без виправлень оператора.
До впровадження ця частка зазвичай тримається на 55-70%: частина реквізитів не читається, частина зчитується неправильно — і все одно передруковується руками.
Після налаштування розпізнавання під конкретні типи документів і розмітку полів показник виходить на 90-95%, причому зростає далі: виправлення оператора повертаються в систему як зворотний зв’язок.
Знімки при цьому не йдуть на сторонній сервер — розпізнавання виконується на пристрої, на перевіреному рушії Tesseract.
Швидкість введення даних змінюється якісно. Замість ланцюжка «зняв → надіслав → дочекався відповіді → звірив» користувач бачить заповнені поля через 1-2 секунди після зйомки, ще до запису в облікову систему.
На пакеті з кількох десятків накладних це різниця між паузою біля кожного документа та безперервною роботою зміни.
Робота без зв’язку перестає бути обмеженням: модель лежить усередині застосунку, тому розпізнавання доступне в підвалі, у полі та в літаку. Результат складається в локальну чергу і йде в систему з появою мережі — без втрати документів і без дублів при повторному надсиланні.
Зниження частки виправлень проявляється не одразу, а в міру накопичення даних: типові помилки — схожі символи, перекіс, відблиски — закриваються налаштуванням передобробки та післяобробки полів, а не ручною працею.
Через кілька тижнів роботи частка ручних виправлень падає в рази, і це видно за журналом операцій, а не за відчуттями.
Режими обробки: хмара, на пристрої, гібрид
Вибір режиму визначається не лише якістю розпізнавання. Схеми по-різному поводяться на складних бланках, по-різному ставляться до персональних даних і по-різному залежать від каналу зв’язку — і часто рішення ухвалюється не для застосунку загалом, а для окремих типів документів.
На практиці потік майже ніколи не буває однорідним: масові типові документи та рідкісні складні бланки вигідніше вести різними контурами. Нижче — три схеми та їхні реальні межі застосовності.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Обробка в хмарі | Складна верстка, рукописні та нестандартні бланки, де важлива максимальна точність; потік документів помірний | Потрібен стійкий канал: за слабкого сигналу зростає час відповіді та з’являються обриви. Зображення залишає пристрій — потрібні явна згода користувача та регламент зберігання на боці сервісу |
| Обробка на пристрої | Типові документи з передбачуваною версткою, сценарії без мережі, дані з підвищеними вимогами до приватності | Точність на складних бланках нижча. Модель та її оновлення займають місце у збірці, на старих пристроях обробка помітно повільніша |
| Гібридна схема | Змішаний потік: багато простих документів плюс рідкісні складні; потрібен офлайн-відгук без втрати якості | Складніша в розробці та підтримці: два контури розпізнавання, правила перемикання та єдине журналювання результатів доводиться тестувати разом |
Гібрид найчастіше й виграє: на пристрої йде попередня оцінка та розбір типових випадків, у хмару йде лише те, що не пройшло поріг упевненості.
Вимоги до каналу зв’язку при цьому знижуються — передається не кожен кадр, а одиниці з потоку, тому розпізнавання залишається робочим навіть на нестабільному зв’язку, а чутливі документи не залишають пристрій.
Схему фіксуємо матрицею «тип документа → контур обробки» і проганяємо на реальному потоці сканів, а не на демонстраційних зразках.
Впровадження за кроками: від аудиту зразків до передачі
Робота йде не від вибору бібліотеки, а від зразків: без реальних кадрів будь-яка оцінка точності — здогад. Тому починаємо з профілю даних і метрик, а закінчуємо прийманням на незалежній вибірці. Порядок етапів не змінюється — кожен наступний спирається на результат попереднього.
- Аудит зразків документів. Реальні кадри: різні пристрої, освітлення, кути, заломи, рукописні вставки. За ними видно, які бланки йдуть у потоці насправді, а не в описі.
- Еталонна розмітка. Поля та класи символів розмічаємо вручну, спірні випадки тлумачимо письмово. Далі рахуємо частку правильно вилучених полів, а не абстрактну точність розпізнавання.
- Вибір схеми обробки. На пристрої, на сервері чи змішана: офлайн-режим і приватність даних тягнуть на пристрій, важкі бланки та часте оновлення моделей — на сервер.
- Налаштування під типи бланків. Для кожного документа — своя зона інтересу, передобробка (вирівнювання, контраст, шум) і післяобробка: звірка з базою, контрольні суми, розбір неоднозначних символів.
- Перевірка на складних випадках. Регресійний набір: зім’яті чеки, тіні, повороти, змішані мови, рукописні правки. Провал або закриваємо передобробкою, або віддаємо сценарій на ручне введення.
- Пілотне впровадження. Обмежена група користувачів і збір проблемних кадрів з експлуатації — так виловлюються випадки, яких не було у вихідній вибірці.
- Приймання якості та передача. Замір на незалежному наборі, зафіксовані пороги, при низькій упевненості — ручне введення замість тихої помилки. Віддаємо конфігурації, розмітку та набори для регресії.
Після передачі у команди залишається відтворюваний конвеєр: нові зразки поповнюють еталонний набір, метрики видно на панелі моніторингу, і деградація якості помітна до того, як її побачать користувачі.
Конфігурації, схеми та регламенти, які залишаються у вас
Розпізнавання живе не в коді, а в конфігурації: правила розбору, пороги впевненості та політика зберігання змінюються частіше, ніж сам модуль. Тому ми передаємо не лише збірку, а й набір артефактів, з якими ваша команда працює самостійно.
- Профіль розпізнавання під кожен тип документа: склад полів, поріг упевненості та правило на випадок низької впевненості — прийняти, надіслати на ручну перевірку або запросити повторний знімок.
- Правила розбору: як вилучається кожне поле, які перевірки узгодженості обов’язкові, які помилки блокують запис в облікову систему.
- Схема потоку даних: знімок, передобробка, розпізнавання, перевірка оператором, запис — із позначкою, де дані залишають пристрій.
- Матриця доступу та зберігання: хто бачить зображення та результати, скільки вони живуть, що шифрується на пристрої і що стирається одразу після розбору.
- Журнали подій: тип документа, версія профілю, упевненість за полями, час обробки та код відмови — за ними видно, чи просіла точність на новому бланку.
- Тестовий набір зразків і регламент приймання: частка полів, розібраних без виправлення оператора, і межа, нижче якої викатка нової версії блокується.
- Інструкція з донавчання та порядок ескалації збоїв: як додати зразки, перевірити профіль, відкотити його і до кого йти при відмові.
Артефакти лежать у вашому сховищі коду й оновлюються за регламентом: при зміні формату бланка або вимог до зберігання правки вносить ваша команда, без звернення до нас.
Кейс: розбір накладних на складі без ручного введення
Що було до впровадження
На складі дистриб’ютора «Гарант-Логістика» приймання виглядало так: комірник розкладав паперові накладні й вбивав позиції в термінал збору даних вручну. Партія з 50–60 рядків займала 20–25 хвилин, а при зім’ятому папері або слабкому світлі — помітно довше.
Частка рядків, які потім виправляли руками, трималася близько третини: помилка в артикулі випливала вже на звірці.
Потерпав не лише час приймання. Спірні позиції накопичувалися до кінця зміни, і закриття зсувалося на годину-півтори: бригада замість відвантаження розбирала розбіжності за кількістю та одиницями вимірювання.
Що змінили і що отримали
Камеру термінала зробили основним каналом введення, ручний залишили страховкою. Кадр перед розпізнаванням проходить підготовку: знебарвлення, підрізання за контрастною рамкою документа та вирівнювання перспективи — знімати можна під кутом.
Поля шукаються за якорями шаблону накладної, а розпізнаний артикул звіряється з довідником номенклатури.
Далі — правила валідації: кількість ціла, одиниця вимірювання збігається з карткою товару, перевірка контрольної суми штрихкоду. Рядки, де щось не зійшлося, підсвічуються у списку, і комірник править дві-три позиції замість усієї накладної. Якщо зв’язку немає, знімки йдуть у локальну чергу й вирушають на сервер з її появою.
Результат за вимірами за квартал: частка ручних виправлень — з 30% до 4% рядків, партія з 60 рядків замість 25 хвилин обробляється за 3–4, спірних позицій на зміну — з 25–30 до 4–6. Закриття зміни вкладається в 20 хвилин, бо розбіжності закриваються в момент приймання.
Чим відрізняється обробка на пристрої від серверної?
Різниця починається з того, де виконується модель розпізнавання. При локальній обробці кадр з камери потрапляє в модель прямо на пристрої, і результат з’являється в інтерфейсі без звернення до мережі.
При серверній обробці кадр іде на наш контур, розпізнається там, а застосунок отримує готову структуровану відповідь.
Затримка відгуку визначається саме цим. Локально це частки секунди, і вона майже не залежить від якості зв’язку — розпізнавання працює в метро, на складі в підвалі та в роумінгу без трафіку.
Серверна схема при хорошому каналі дає порівнянну швидкість на короткому документі, але на паспорті або довгій накладній час зростає: покадрова передача та черга на обробку помітні користувачеві.
Зате при обриві зв’язку серверна схема не втрачає розпізнане — запит іде в чергу й повторюється, а локальна просто повертає помилку, якщо модель не змогла розібрати кадр.
Приватність вирішує вибір частіше, ніж швидкість. Якщо документ не залишає пристрій, у замовника не виникає обов’язків щодо захисту персональних даних на нашому боці: немає передачі, немає зберігання, немає журналів з паспортними даними.
Серверна обробка потребує захищеного каналу, шифрування в стані спокою, терміну зберігання та розмежування доступу — це керована, але окрема робота.
Збої у схем різні. Локальна модель упевнено бере друкований текст, чеки, штрихкоди та типові бланки, але спотикається на рукописі, рідкісних шрифтах, складній верстці таблиць і низькому контрасті.
Серверна з повноцінним рушієм витягує рукописне введення, ієрогліфи, багатосторінкові документи з таблицями — але ламається на поганому каналі та при великому потоці, коли черга обробки зростає швидше, ніж надходять відповіді.
На практиці ми майже завжди приходимо до гібридної схеми: базові сценарії — договори, чеки, документи співробітників — розпізнаються на пристрої, а рукопис і складна верстка йдуть на сервер, якщо користувач погодився і мережа доступна.
Так вибір схеми стає не філософським, а інженерним: під кожен тип документа добирається свій маршрут, і падіння одного не зупиняє другий.
Обмеження та часті сумніви: що уточнюємо до старту
До старту ми фіксуємо, які сценарії застосунок зобов’язаний закривати, а де розпізнавання тексту завідомо помиляється. Це знімає головний ризик — розходження очікувань: точність залежить від якості зйомки, структури документа та типу даних, а не лише від обраної технології.
Нижче — сумніви, які найчастіше випливають на погодженні, і те, як ми закриваємо їх в архітектурі.
Наскільки точно розпізнаються погані знімки?
Перед розбором кадр проходить підготовку: визначаються межі документа, вирівнюється перспектива та нахил, пригнічуються тіні й відблиски.
На рівних знімках точність за друкованим текстом висока; на зім’ятих бланках і при слабкому світлі ми задаємо поріг упевненості та надсилаємо сумнівні поля на ручну перевірку — помилка не йде далі процесом.
Що робити з рукописними записами?
Друковані форми та машинозчитувані зони розпізнаються стабільно, рукописні — помітно гірше й залежать від почерку. Зони інтересу виділяються за шаблоном: критичні поля підтверджує співробітник, решта заповнюються автоматично з підсвічуванням низької впевненості.
Де зберігаються персональні дані з документів?
За замовчуванням зображення обробляються на пристрої його не залишають. Якщо потрібна серверна обробка — вмикаємо шифрування при передачі та зберіганні, обмеження терміну зберігання, доступ за ролями та журнал звернень, а вихідні знімки видаляємо після розбору.
Як додати новий тип бланка без випуску нової версії?
Шаблон описує зони інтересу та правила розбору, тому новий бланк часто додається налаштуванням. Якщо структура відрізняється сильно, потрібна розмічена вибірка та налаштування моделі — її обсяг оцінюємо заздалегідь, до початку робіт.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Щоб оцінка проєкту була предметною, а не «плюс-мінус порядок», нам потрібен вхід від вас: чим знімають документи, при якому світлі, які типи бланків і мови трапляються.
Розпізнавання тексту — задача, де точність визначається не моделлю, а якістю вхідних кадрів і розміткою, тому розбір реальних зразків дає більше, ніж будь-який опис вимог.
Що потрібно від замовника для оцінки:
- 20–30 реальних зразків зйомки — не відскановані еталони, а те, як знімає камера телефона в полі: з відблиском, нахилом, тінню;
- перелік типів документів і мов, включно з рукописними полями та змішаними розкладками;
- сценарій використання: хто знімає, скільки документів підряд, чи є зв’язок із мережею;
- вимоги до роботи без інтернету та до зберігання чутливих даних на пристрої;
- куди йде результат — в інтерфейс, на сервер або в облікову систему, і в якому вигляді;
- обмеження за строками, платформами та поточною кодовою базою застосунку.
У відповідь ми повертаємо не листування, а робочий комплект: склад робіт за етапами розпізнавання, схему обробки — від кадру до структурованого поля, план робіт із порядком старту та точками контролю.
Окремо фіксуємо метрики приймання: частку коректно розпізнаних полів на вашому наборі, час обробки однієї сторінки та поведінку при низькій якості кадру. Опишіть задачу — повернемося з оцінкою та пропозицією щодо пілоту.
