Верифікація документів: де ламається потік заявок
Верифікація документів ламається не на моделі, а на вході. Знімок зроблено під кутом, з відблиском від лампи або спалаху, край бланка обрізано кадром — і розпізнавання бланків віддає порожні поля там, де людина бачить номер без труднощів.
Одна така заявка йде в ручний розбір, і далі все залежить від того, скільки операторів устигають за потоком.
Перевірка паспорта й прав ускладнюється тим, що бланки різні: паспорти й ID-картки, права кількох поколінь, документи різних регіонів зі своєю версткою та захисними елементами.
Універсального шаблону тут немає — під кожен тип потрібен свій набір зон і правил, а нова серія бланка приходить без попередження й валить уже налаштований контур.
Окрема точка відмови — розбіжність полів. Дані машиночитаної зони, візуальної частини та відповіді зовнішнього джерела не збігаються за написанням, транслітерацією або датою, і система або відхиляє коректний документ, або пропускає підробку.
Хибні відмови дорожчі за все: клієнт не розуміє причини, повторює спробу й іде, а черга заявок зростає швидше, ніж її встигають розбирати вручну.
Далі розбираємо, як це закривається: підготовка знімка до розпізнавання, розбір бланка за зонами, зіставлення полів і зрозумілі правила ескалації.
Ефект: швидкість перевірки, частка помилок і слід рішень
Міряємо ефект за кількома величинами: скільки займає перевірка однієї заявки, яка частка рішень ухвалюється без оператора, які помилки взагалі перестають доходити до людини і що залишається в журналі після розбору спірних випадків. Нижче — як це виглядає на працюючому контурі.
Час обробки заявки
Машиночитану зону та поля бланка розбираємо за вимогами ICAO 9303, звірку запускаємо паралельно з перевіркою якості кадру.
Типовий сценарій «документ + фото власника» закривається за секунди замість хвилин ручної роботи, а час оператора витрачається лише на заявки, де автоматика не набрала порогу впевненості.
Частка автоматичних рішень
Поріг впевненості не фіксований — він налаштовується під ризик послуги окремо для кожного типу документа й каналу подання.
На налаштованому контурі частка рішень без оператора зазвичай сягає 70–85%, і зростає вона не за рахунок зниження планки, а за рахунок відсіювання неякісних кадрів до етапу звірки.
Клас відмов, який перестає доходити до оператора
Відблиски, перекриття, копії та скриншоти, обрізані краї, незбіг обличчя з портретом, повторне подання того самого документа — усе це відсікається на вході з зрозумілою причиною.
Оператор бачить змістовні розбіжності, а не потік нечитабельних зображень, тому розбір спірних випадків займає хвилини, а не години.
Журнал рішень
Кожне рішення зберігається з причиною, мітками якості кадру та версією правил, за якими його ухвалено.
Спірну заявку можна переперевірити на тому самому наборі умов, а не відновлювати логіку з пам'яті — це й робить розбір спірних випадків керованою процедурою, а не разовим розбиранням.
Підходи до верифікації документів: порівняння режимів
Режим перевірки обирають не за «рівнем технологічності», а за потоком: скільки документів надходить за добу, які типи переважають і що робити за сумніву. Нижче — три схеми, між якими реально обирають на старті, разом з їхніми обмеженнями.
Чим режими відрізняються на практиці
Ключові метрики тут — частка рішень, ухвалених без оператора, і ціна помилки в обидва боки: пропущена підробка та хибна відмова живому клієнту.
Обмеження підходу зазвичай проявляються не в середній якості, а на рідкісних типах бланків і знімках з відблисками, засвітленням або обрізаними краями.
| Режим перевірки | Коли підходить | Обмеження |
|---|---|---|
| Автоматична звірка | Масовий потік однотипних документів: розпізнавання полів, звірка з реєстром і перевірка ознак підробки без участі людини | Помилки на поганих знімках і рідкісних бланках; потрібен запас за часткою відмов і розбір спрацювань |
| Змішана схема | Упевнені випадки закриваються автоматично, спірні та дорогі сегменти йдуть оператору | Потребує черги, регламенту ескалації та розмітки рішень оператора для донавчання моделі |
| Ручна перевірка | Поодинокі складні кейси, нестандартні документи, збір зразків для нових типів | Не масштабується: час на документ зростає лінійно, з'являється розкид між операторами |
На старті зазвичай беруть автоматичну звірку як основу, а змішану схему — як страховку на спірних випадках. Перехід між ними не потребує переробки, а частка ручних рішень видна в журналі й слугує сигналом, коли час змінювати режим.
Впровадження за кроками: від аудиту потоку до передачі
Аудит потоку починається з фактів: скільки документів за добу проходить через перевірку, яких типів (паспорт, ID-картка, права, посвідка на проживання), скільки з них іде на ручний розбір і якою є медіанна затримка до рішення.
Далі фіксуємо цільову метрику — наприклад, частку автоперевірок без участі оператора за контрольованого рівня пропущених підробок. Без цього етапу неможливо зрозуміти, де саме автоматика дає ефект, а де лише перекладає роботу.
- Розбір потоку: збираємо зразки документів і сценарії подання, позначаємо, які поля критичні, де трапляються відблиски, обрізання, зйомка під кутом.
- Схема перевірки: визначаємо порядок кроків — розпізнавання зони машиночитаного запису, звірка полів між собою, перевірка контрольних сум, зіставлення обличчя із селфі, перевірка за внутрішніми списками.
- Налаштування правил: виставляємо пороги збігу окремо за кожним типом документа, описуємо поведінку за низької якості знімка — досилання, повторний запит або ручний розбір.
- Пілот на історичних даних: проганяємо правила на накопиченому архіві, звіряємо результат з тим, що оператори вирішили вручну, правимо пороги під цільову повноту.
- Приймання: вимірюємо на відкладеній вибірці частку хибних відмов і пропусків, перевіряємо поведінку за збою зовнішніх сервісів.
- Тіньовий режим: система рахує, оператор вирішує — розбіжності розбираємо до передачі.
- Передача регламентів: інструкції для операторів і підтримки, схема оновлення правил у разі появи нових типів документів.
Після передачі правила залишаються керованими: пороги, стоп-листи та порядок кроків змінюються конфігурацією, без переписування системи.
Що залишається у вас: схеми, регламенти, доступи
Після запуску вся документація залишається у вашому контурі, поруч із кодом і налаштуваннями, а не в листуванні з нами. Передаємо її так, щоб за пів року новий інженер або оператор розібрався без дзвінків і відновлення контексту заново.
- Схема перевірки: які кроки проходить документ від завантаження до вердикту, де рішення ухвалює автоматика, де підключається оператор і які дані фіксуються на кожному кроці.
- Матриця доступів: ролі та зони видимості, строки зберігання зображень, порядок надання й відкликання прав — з явним розмежуванням, що бачить оператор, а що доступно лише сервісній ролі.
- Політика доступу до персональних даних: що логується, що маскується, що видаляється одразу після перевірки і хто на якій підставі може зробити вивантаження.
- Регламент розбору: як діяти за спірного вердикту, хто ухвалює фінальне рішення, як фіксується причина відмови і як це змінює правила на наступній ітерації.
- Інструкції для операторів: типові помилки за видами документів, порядок ескалації, приймання зміни та розбір конфліктних випадків із прикладами.
- Порядок супроводу: як додаються нові типи документів і мов, як оновлюються правила, який строк реакції за падіння точності і як відкочується невдала зміна.
- Журнал метрик: частка рішень без участі людини, частка ручних доопрацювань, розподіл причин відмови — за ним видно, чи працює система так, як задумано.
Кейс: як скоротили ручний розбір заявок
Клієнт — сервіс із потоком 4–6 тисяч заявок на добу на онбординг заявників. До впровадження 42% звернень ішли на ручний розбір: оператор витрачав 6–9 хвилин на заявку, і в пікові години черга зростала швидше, ніж розширювалася зміна.
Конвеєр зібрали з трьох кроків: перевірка справжності документа — голограми, мікротекст, мітки в інфрачервоному та ультрафіолетовому діапазоні; звірка обличчя з фото носія; ранжування ризиків за формальними ознаками.
Ядро перевірки справжності побудували на Regula, поверх — власні правила маршрутизації: у ручний розбір іде лише заявка, що не пройшла хоча б одну високоризикову ознаку.
| Показник | До | Після |
|---|---|---|
| Заявки без участі оператора | 58% | 91% |
| Середній час до результату перевірки | 19 годин | 90 секунд |
| Хибні відмови | 12% | 3% |
| Підробки, що пішли в схвалення | 6% | 0,3% |
Основний приріст дало не розбирання тексту, а розділення черг. Раніше спірні заявки складалися в загальний потік, і оператор витрачав на них стільки ж часу, скільки на прості; тепер спірне відсікається окремо й розбирається за пріоритетом, а типові закриваються автоматично. Результат перевірки заявник отримує одразу, без очікування зміни.
Чим відрізняється звірка з базою від розпізнавання тексту?
Витягування полів відповідає лише на питання «що написано в документі»: знімок перетворюється на набір значень — прізвище, номер, дата видачі, серія.
Оптичне розпізнавання впевнено відпрацює й фотомонтаж, бо модель не перевіряє, чи існує такий бланк і чи видавали його людині на фото.
Аналіз бланка — це перевірка самого носія, а не тексту на ньому. Дивимося геометрію та пропорції, шрифти та їхню посадку, захисні елементи, машиночитану зону та її контрольні суми за ICAO, сліди переклеювання й локальних правок.
Так підтверджується справжність документа, але не його поточний статус: акуратна підробка цей контроль проходить.
Звірка з реєстром закриває другу половину завдання: чи є запис, чи чинний документ, чи не анульований і чи не вважається втраченим, чи збігається фото із записом. Тут витягнуті поля — не результат, а ключ запиту, тому помилка в одному символі перетворюється на хибну відмову.
Порядок перевірок вибудовуємо від дешевих до дорогих. Спочатку якість кадру: різкість, відблиски, геометрія. Потім аналіз бланка й машиночитаної зони — він офлайн відсікає основну масу підробок.
Після цього витягування полів і лише потім звірка з реєстром як найповільніший і не завжди доступний крок.
Рішення віддаємо не як «так/ні», а як рівень впевненості з причиною: змазаний кадр, не збіглася контрольна сума, відсутність запису. Якщо доступу до реєстру немає, гібридний режим спирається на бланк і біометрію, але з меншою довірою — і це явно фіксується в результаті перевірки.
Технічні сумніви: точність, приватність, відмови
Точність перевірки впирається не в модель, а в якість вхідних даних. Відблиски на ламінаті, слабке світло, документ під кутом — заявка йде в ручну перевірку або у відмову. Тому ми дивимося на потік загалом: що надходить із камер і як швидко це виправляється.
Клієнти знімають документ на телефон за поганого світла — це лікується?
Сервіс перевіряє кадр до надсилання: різкість, засвітлення, потрапляння меж документа в рамку, читабельність ключових зон. Замість «спробуйте ще раз» людина отримує конкретну причину — повернути, наблизити, прибрати відблиск. Частка знімків, що доходять до розпізнавання з першої спроби, після такої перевірки помітно вища.
Як зберігаються образи документів і хто має до них доступ?
Образи лежать окремо від результату перевірки, у зашифрованому вигляді, зі строком зберігання, який задаєте ви. Доступ розмежовано за ролями: оператор бачить лише призначені йому випадки, кожне відкриття потрапляє в журнал. Видалення за регламентом — частина налаштування, а не окреме доопрацювання.
Скільки буде хибних відмов і що робити з рідкісними бланками?
Поріг впевненості налаштовуємо під ваш потік: десь дешевше відправити випадок оператору, ніж відмовити живому клієнту. На вашій вибірці документів рахуємо частку помилок до запуску.
Рідкісні серії та регіональні варіанти бланків додаємо в перевірний набір, а правила оновлюємо окремими модулями — без перезбирання всієї системи.
Обговоримо завдання: розберемо потік і повернемося з планом
Щоб оцінка спиралася на факти, а не на здогадки, для старту потрібен мінімальний набір ввідних. Ми розбираємо потік, виділяємо класи документів і сценарії відмови, після чого повертаємося з планом етапів і межами робіт. Що корисно проговорити й надіслати:
- типи документів у потоці — паспорт, ID-картка, водійські права, службові посвідчення: по 10–20 знеособлених зразків на кожен тип;
- «важкі» кадри — відблиски, нахил, ламінація, зйомка на телефон за слабкого світла, скани й копії;
- перелік полів для витягування та звірки, з позначкою обов'язкових і допоміжних;
- правила рішення за невпевненості розпізнавання — ручна перевірка оператором, повторна зйомка або відмова;
- вимоги до приватності: де зберігаються зображення та витягнуті дані, строк зберігання, хто має доступ;
- очікувані обсяги — число перевірок на добу та поведінка в пікові години;
- точки інтеграції: CRM, мобільний застосунок, внутрішня панель, у якому вигляді повертається результат.
За підсумком розбору ви отримуєте план етапів із критеріями приймання на кожному, оцінку обсягу робіт, склад даних для розмітки та перевірок, а також покроковий наступний крок — від підготовки вибірки до дослідної експлуатації на частині потоку. Опишіть завдання й надішліть доступні зразки: повернемося з оцінкою та планом етапів.
