Чому розпізнавання паспортів AI ламається на реальних сканах
Паспорт на скані майже ніколи не виглядає як в інструкції.
Відблиски від лампи на ламінаті, тінь від пальця поверх машинозчитуваної зони, зімʼята сторінка після дороги, фото на телефон під кутом — і якість сканів документів падає настільки, що розпізнавання паспортів AI впевнено читає прізвище, але плутає номер або губить одну цифру в серії.
Окрема складність — десятки варіантів посвідчень і внутрішніх паспортів різних країн: у кожного своє розташування полів і свій порядок машинозчитуваної зони, закріплений у рекомендаціях ICAO.
Поки потік невеликий, це лікується оператором.
На обсязі введення паспортних даних стає вузьким місцем в обробці заявок: у пікові години людина вбиває кілька десятків полів вручну, до середини нічної зміни увага падає, і помилки ручного введення паспортних даних ідуть далі процесом.
Опечатка в номері або даті дії спливає вже на боці банку або приймальної сторони — заявка повертається, клієнт чекає повторного циклу, а частка відмов зростає саме разом із навантаженням.
Перевірка посвідчень у такому режимі тримається на людях, а не на процесі, тому перше, що розсипається при зростанні обсягу, — швидкість і повторюваність результату. Нижче розбираємо, де саме ламається розпізнавання і як це закривається.
Що дає розпізнавання документів у потоці заявок
Автозаповнення анкети за документом знімає з оператора ручне введення: система сама розносить серію, номер, дату видачі, орган і машинозчитувану зону по полях картки.
На типовому потоці частка автозаповнення сягає 85–95% полів, і оператору залишається підтвердити результат, а не набирати його заново. Чим однорідніші бланки, тим вища ця частка — відхилення система позначає, а не підганяє під шаблон.
Час обробки заявки скорочується з кількох хвилин до десятків секунд, і змінюється сама природа вузького місця: раніше темп зміни задавала черга на введення, тепер — лише перевірка спірних полів.
Це дозволяє пропускати той самий обсяг заявок меншим складом зміни або приймати пікові періоди без авралів і накопичення нерозібраних заявок.
Контроль якості вилучених полів будується на порозі впевненості: значення вище порога йде в картку автоматично, нижче — підсвічується й потрапляє на ручну звірку.
Частка помилок оператора падає передусім там, де людина раніше вгадувала за змазаним сканом або плутала схожі символи в серії та номері.
Додатково ми вивантажуємо вибірку полів на вибірковий аудит — видно, як змінюється точність за типами документів і за конкретними операторами, і де поріг варто підкрутити.
Окремо зникає цілий клас відмов через нечитабельні поля: заломи, відблиски, обрізаний край, нестандартний шрифт більше не призводять до повернення заявки клієнту.
Система віддає частковий результат і явно позначає проблемне поле — заявка йде далі процесом, а не розвертається на початок. Розпізнавання паспортів у потоці працює саме так: не «ідеально або ніяк», а з прозорим розділенням, що прийнято машиною, а що потребує людини.
Способи розгортання: хмара, власний контур, гібрид
Вибір варіанта визначається двома осями: профілем навантаження й вимогами до зберігання персональних даних.
Поки обсяг заявок невеликий і нерівний, хмарне розпізнавання документів знімає питання до потужностей — модель оновлюється на боці сервісу, ми підключаємося через програмний інтерфейс і отримуємо поля в узгодженому форматі.
Щойно з’являються чутливі поля або внутрішній регламент забороняє винесення зображень за периметр, розгортання у власному контурі стає не опцією, а умовою.
Між цими крайнощами найчастіше й лежить робоче рішення — гібридна схема обробки. Зображення й попередня обробка залишаються всередині, назовні йде знеособлений фрагмент або лише результат розбору, а оригінали живуть у вашому сховищі із заданим строком.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Хмарне розпізнавання документів | Нерівний потік, швидкий старт, немає власних обчислювальних потужностей | Дані залишають периметр: потрібне доручення на обробку й зрозуміла політика зберігання; відгук залежить від каналу зв’язку |
| Розгортання у власному контурі | Жорсткі вимоги до зберігання персональних даних, стабільний обсяг, закрита мережа | Потрібні власні потужності й резерв під піки; оновлення моделей і контроль якості — на нашому боці |
| Гібридна схема обробки | Чутливі поля мають залишитися всередині, решту можна віддати назовні | Складніший супровід: маршрутизація запитів, єдина розмітка, узгоджений контроль якості на обох ділянках |
Підсумкову схему фіксуємо в проєктній документації: де лежить оригінал, скільки зберігається, що і в якому вигляді йде за периметр — щоб рішення проходило перевірку й не ламалося при зміні регламенту.
Як відбувається впровадження: від аудиту зразків до передачі
Порядок етапів однаковий і для одного типу документа, і для десяти: спочатку розбираємо реальні зразки, потім проєктуємо рух даних, і лише потім налаштовуємо вилучення.
Такий порядок прибирає головну причину провалів, коли рішення показує хороші результати на підготовлених файлах, а на сканах замовника частка правильних полів різко падає.
- Аудит зразків документів. Дивимося, що реально надходить: типи паспортів і посвідчень, якість сканів, ракурси, відблиски, обрізані краї, змішані мови. Фіксуємо перелік полів, потрібних бізнесу, і найчастіші дефекти.
- Схема потоків даних. Визначаємо, звідки йдуть файли, де зберігаються, хто їх бачить і як рішення вбудовується в поточний контур — по одному документу, пакетом або потоком. Окремо описуємо поведінку при невпевненому розпізнаванні: ручна перевірка, повтор, відмова.
- Розмітка набору для перевірки. Частину зразків розмічаємо вручну й ділимо на дві частини: робочу й відкладену. Відкладена вибірка не бере участі в налаштуванні — на ній вимірюємо чесний результат.
- Налаштування вилучення. Під кожен тип документа свій набір правил і звірок: узгодженість машинозчитуваної зони з візуальною частиною, перевірка дат, відповідність номера формату. Такі зв’язки відсікають помилки до потрапляння в систему.
- Перевірка на відкладеній вибірці. Рахуємо частку повністю правильних документів і частку правильних полів окремо за кожним типом. Дивимося не середню цифру, а де саме помиляємося, і добиваємо слабкі типи.
- Передача рішення замовнику. Передаємо налаштований контур, інструкції, схему даних і порядок оновлення при появі нових форм. Навчаємо команду, щоб доналаштування йшло власними силами.
Етапи йдуть із контрольними точками: після аудиту й після перевірки на відкладеній вибірці фіксуємо результат у цифрах, щоб рішення ухвалювалося на даних, а не на демонстрації.
Що залишається замовнику: схеми, політики, регламенти
Рішення працює у вашому контурі, тому передаємо не лише сервіс розпізнавання, а й усе для його самостійної експлуатації. Склад артефактів фіксуємо в акті приймання — за ним перевіряємо, що систему можна вести власними силами.
- Схема інтеграції — шлях документа від завантаження до запису в облікову систему: точки входу, черга, поведінка при недоступності суміжної системи, захист від дублів за номером документа.
- Передача конфігурацій — профілі розбору під кожен тип документа: перелік полів, що вилучаються, пороги впевненості, довідники країн і підрозділів. Зберігаються в системі контролю версій з історією та відкатом на попередній профіль.
- Політики доступу до документів — ролі оператора, перевіряльного й адміністратора, строки зберігання зображень, шифрування, маскування номерів у журналах, заборона масових вивантажень.
- Регламент ручного коригування — коли підключається оператор (значення нижче порога впевненості, розходження з перевірним джерелом), хто підтверджує правку і як вона йде в еталонну вибірку.
- Документація з розбору помилок — каталог типових відмов: відблиск, обрізаний край, застаріла форма, змішана розкладка. За кожним — ознаки й порядок дій чергового інженера.
- Еталонна вибірка й регресія — розмічений набір документів, на якому проганяємо оновлення профілю й порівнюємо з минулим прогоном: видно, які поля деградували, ще до викату в робочий контур.
Кейс: потік заявок без ручного введення паспортних даних
Що було до запуску
Фінансова організація обробляла кілька тисяч комплектів документів на місяць: фото або скан паспорта, частина заявок — із другим документом.
Оператор переносив в облікову систему ПІБ, серію й номер, дату видачі, код підрозділу, а другий співробітник звіряв введення із зображенням. Комплект займав 6–8 хвилин, і в дні пікового навантаження черга заявок зростала швидше, ніж зміна встигала її закривати.
Найдорожче обходилися не самі хвилини, а повторні перевірки. Близько чверті комплектів поверталися на другий круг: відблиск на ламінаті, обрізана зона машинозчитуваних записів, різні варіанти написання імені. Кожне повернення — ще один прохід оператора й зайва доба очікування для клієнта.
Що змінили і що отримали
Ми зібрали конвеєр: приведення зображення до робочого вигляду, визначення типу документа, розбір зони машинозчитуваних записів за стандартом ICAO 9303 і крос-перевірка полів — контрольні суми, строк дії, узгодженість даних між рядком і зображенням.
Якщо впевненість розпізнавання нижча за поріг, комплект іде оператору, але з підсвіченими сумнівними полями, а не з порожньою карткою.
Через місяць на бойовому потоці частка ручних операцій упала зі 100% до 12%, час обробки комплекту — з 6–8 хвилин до 40–60 секунд, частка повторних перевірок документів — з 23% до 6%.
Пороги впевненості й правила маршрутизації залишилися налаштовуваними: їх змінює бізнес, без правки коду.
Чим відрізняється перевірка справжності від вилучення полів
Це дві різні задачі, які в брифі часто змішують. Вилучення полів відповідає на питання «що написано в документі»: ПІБ, серія, строк дії, ким виданий — і вимірюється точністю за кожним полем.
Перевірка справжності відповідає на «чи видано документ тому, хто його пред’явив», і працює з поліграфією бланка, а не з текстом.
Різні питання потребують різних перевірок і дають різний клас помилок — підходи не взаємозамінні:
| Підхід | Що вирішує | Де обмежений |
|---|---|---|
| Розбір друкованих і машинозчитуваної зон | Вилучення полів: ПІБ, серія, строк | Відблиск, вигин, перекриття — падає точність |
| Мікротекст, гільош, захисна сітка | Ознаки підробки бланка | Потрібен канал зйомки, у якому ознака видима |
| Контрольні суми машинозчитуваної зони | Правки тексту, опечатки | Не покажуть підробку самого бланка |
| Запит до реєстру випущених документів | Статус і дійсність документа | Залежить від доступності джерела |
Формат машинозчитуваної зони й алгоритм контрольних сум задає ICAO. Така звірка йде локально, відсікає більшість правок тексту, але про поліграфію не говорить нічого — її замінюють на ознаку «дані прочитано, бланк не перевірено».
У конвеєрі це два потоки. Поля читаються один раз і одразу йдуть в облікову систему, а перевірки справжності йдуть паралельно й не блокують видачу: якщо знімок зроблено не в тому каналі, система віддає вилучені поля з позначкою про непідтверджену справжність, а не відмову.
Тому точність за полями й частка виявлених ознак підробки рахуються окремо — інакше зростання одного показника маскує провал другого.
Обмеження та сумніви: що уточнюють перед запуском
Питання, які закриваємо до старту, — не про те, чи вміє модель читати паспорт, а про те, де закінчується її впевненість.
Рідкісний бланк, документ старого зразка, зйомка на телефон під кутом із відблиском від ламінату — на таких кадрах сиплеться будь-яке вилучення даних, якщо поріг впевненості не заданий заздалегідь.
Тому межі застосовності фіксуємо на тестовій вибірці: які типи документів і умови зйомки обробляються автоматично, а які йдуть на ручне доопрацювання результату.
Що робити з рідкісними типами документів, яких немає у вибірці?
Збираємо перелік усіх типів, які реально трапляються у вашому потоці, і розкладаємо на три групи: упевнене вилучення, вилучення з перевіркою оператором, ручне введення. Рідкісні бланки додаємо в розмітку й дообучаємо модель — вони переходять у першу групу. Якщо документ одиничний, дешевше залишити його в ручному введенні.
Наскільки критична якість зйомки?
Критична, але керована. Модель стійка до нахилу, тіней і зйомки на камеру телефона, найгірше — відблиски на ламінаті та захисних плівках, перекриття тексту пальцем, змаз при русі.
На впровадженні віддаємо вимоги до кадру, а якщо зйомка йде на вашому боці, вбудовуємо перевірку якості до відправлення: нечіткий кадр повертається одразу, а не після помилки в базі.
Як влаштоване ручне доопрацювання і хто відповідає за помилку?
Вилучення віддає не лише поля, а й оцінку впевненості за кожним. Усе нижче узгодженого порога потрапляє в чергу на перевірку з підсвічуванням спірного фрагмента — оператор править значення, а не перебирає документ цілком.
Поля вище порога система вважає готовими, спірні — лише після підтвердження. Це фіксується в регламенті, тому в базі не залишається значення, яке ніхто не перевірив, а правки йдуть у дообучення і частка ручних операцій падає.
Обговоримо задачу: з чого почати і що підготувати
Оцінка такої задачі не потребує довгого технічного завдання — достатньо описати процес і надіслати реальні документи.
Ми розберемо, які поля вилучаються впевнено, а де на першому етапі потрібна ручна перевірка, і запропонуємо перший розумний крок — пілотний запуск на обмеженій вибірці.
Що підготувати до обговорення:
- 10–20 зразків документів різних типів: скани, фото з телефона, знімки з низькою якістю зйомки та нестандартною версткою;
- список полів, які потрібно вилучати, і правила для спірних випадків: що робити, якщо поле не читається або заповнене частково;
- куди має потрапляти результат: картка в обліковій системі, вивантаження у файл, відповідь системі, що викликає;
- обсяг потоку: скільки документів на добу, чи є пікові періоди й обробка в неробочий час;
- вимоги до зберігання й обробки персональних даних, включно з контуром розміщення;
- які системи вже використовуються і які способи приймання документів для вас припустимі.
Пілотний запуск іде на вибірці в кілька сотень документів. Рахуємо частку полів із точним збігом, частку документів, що пройшли без ручного втручання, і розбір типових помилок — за цими цифрами видно, чи готове рішення до потоку чи потрібне доопрацювання.
Опишіть задачу у вільній формі — повернемося з оцінкою, планом робіт і межами етапів, щоб ви розуміли, що отримуєте на кожному кроці.
