Автозаповнення форм ШІ: де ламається ручне введення
Ручне введення даних передбачувано працює, поки потік однорідний: один тип бланка, текстовий шар у PDF, рівні колонки.
Щойно в потік потрапляють різнорідні скани — фотографії з телефона, факси, сторінки з нахилом і друком поверх тексту — оператор починає переносити не значення, а здогадки.
Найдорожче обходяться складені та контекстні поля. Адреса, ПІБ, серія й номер, платіжні реквізити розбиті на кілька комірок, а в скані межі колонок з'їжджають; табличні позиції переносяться на другу сторінку, і частина рядків просто не потрапляє до форми.
Окрема категорія — позначки: поля-галочки, підкреслення, рукописні правки поверх друкованого тексту.
Помилки вилучення полів небезпечні не частотою, а моментом виявлення. Помилка в одній цифрі спокійно проходить приймання і спливає на звірці або у звітності, де переробка коштує вже не хвилини оператора, а ручного розбору всієї партії.
Автозаповнення форм на жорстких правилах такого не закриває: шаблон під кожного нового постачальника документів живе до першої зміни бланка.
У цьому розділі розбираємо, як це закривається: де закінчується ручний перенос, як влаштовано розпізнавання документів із перевіркою значень за правилами і чому гібридна схема — вилучення полів моделлю плюс валідація — дає менше відмов, ніж шаблони чи чисте ручне введення.
Що дає автоматичне вилучення даних з документів
Найчастіше на вході процесу стоїть ручний перенос: оператор читає документ і розкладає реквізити, суми, дати й позиції за полями облікової системи. За потоку в сотні документів на день це вузьке місце — черга зростає швидше, ніж штат, а простій гальмує закриття періоду.
Автозаповнення форм ШІ знімає перенесення як окрему операцію: модель розмічає поля прямо в документі й віддає їх у структурованому вигляді.
Документ обробляється за секунди замість хвилин, пропускна здатність процесу зростає в рази за тієї самої кількості операторів, пікові навантаження більше не потребують тимчасового найму.
Точність вилучення вимірюємо не на око, а часткою полів, що збіглися з еталонною розміткою. На типових реквізитах і сумах це зазвичай 95-98%, а помилки концентруються у вузькому класі — м'яті скани та нестандартні макети, які й раніше розбирав оператор.
Окремий ефект — частка ручних правок: вона падає з майже повного переписування до перевірки винятків.
Зникає й цілий клас помилок — перестановка цифр у сумах, загублені рядки таблиці, неправильно склеєні реквізити: модель працює з візуальною структурою бланка, а не з плоским текстом розпізнавання.
Навантаження на оператора зміщується з введення на розбір спірних випадків: вручну переглядає лише те, де впевненість моделі нижча за поріг. Залишаються контрольна вибірка та журнал за кожним полем — видно, що саме витягла модель. Донавчання під конкретні типи документів ведемо на PyTorch.
Способи вилучення даних: від шаблонів до мовних моделей
Вхідний потік майже ніколи не однорідний: поруч лежать PDF із текстовим шаром, скани договорів, фото бланків з телефона й табличні форми від постійних постачальників.
Універсального способу розбору немає — спосіб обирають за часткою кожного типу файлу в потоці та ціною помилки в конкретному полі. Тому спочатку рахуємо, скільки документів припадає на кожен тип і які поля оператори правлять руками найчастіше.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Шаблонне вилучення за масками й координатами | 1–2 стабільні бланки, верстка не змінюється місяцями | Ламається при зміні бланка, правила правлять руками під кожен новий тип |
| Розбір за ключовими словами та якорями | 5–15 типів із передбачуваною структурою й текстовим шаром | Чутливий до формулювань, множинні значення дають хибні спрацювання |
| Мовні моделі, що читають зображення цілком | Скани й фото без текстового шару, різнорідна верстка | Потрібна розмітка на своїх документах, помилку складніше пояснити |
| Гібридний підхід: правила + модель + перевірки | Змішаний потік, критичні поля | Довше впроваджувати, потрібен явний розбір конфліктів правила й моделі |
На практиці межу проводять за статистикою: якщо більшість потоку — один бланк, шаблон надійніший і простіший у підтримці; якщо верстка змінюється щотижня, без мовної моделі не обійтися.
Далі налаштовуємо розмітку полів: для кожного задаємо поріг впевненості, обов'язковість і перевірку формату, а спірні значення відправляємо оператору.
Гібридна схема дає передбачуваний результат на змішаному потоці — модель дістає значення, правила відсікають те, що не проходить бізнес-логіку.
Порядок робіт: аудит документів, схема, налаштування, приймання
Роботи йдуть від корпусу документів до робочої схеми вилучення: поки не зафіксовано поля й не зібрано відкладений тестовий набір, налаштування перетворюється на вгадування.
Тому порядок жорсткий — спочатку аудит документів, потім схема розмітки і лише потім налаштування правил вилучення.
- Аудит документів. Збираємо реальний потік: скани, фотографії, повернені сторінки, різні шаблони від контрагентів. Фіксуємо потрібні поля, де вони лежать, як часто змінюється верстка і яка частка файлів читається погано.
- Схема розмітки. Описуємо склад полів, типи, обов'язковість і правила нормалізації — дати до єдиного вигляду, коди, найменування організацій. Схема стає контрактом між вилученням і обліковою системою.
- Тестовий набір документів. Відкладаємо частину потоку, розмічену вручну, разом із незручними випадками: таблиці, рукописні правки, об'єднання комірок. На цьому наборі модель не налаштовується — на ньому рахується підсумкова якість.
- Налаштування правил вилучення. Поля дістає нейромережева модель, поверх працюють детерміновані правила: обов'язкові поля, звірка сум, формати реквізитів. Поля з низькою впевненістю йдуть оператору, а його правки повертаються в донавчання.
- Приймання результату. Прогін на відкладеному наборі: точність і повнота за кожним полем, частка документів, прийнятих без правки, розбір помилок до нуля критичних.
- Передача в експлуатацію. Віддаємо схему, конфігурації правил, тестовий набір, моніторинг і регламент донавчання при зміні шаблонів документів.
Конфігурації, схеми розмітки та регламенти приймання
Після запуску в команди замовника залишається не лише працюючий сервіс, а й комплект артефактів, за якими його можна експлуатувати й розвивати без нас.
Нижче — те, що передається за кожним потоком обробки: із цим набором новий інженер розбереться, де що налаштовано, а оператор — як діяти при відхиленні.
- Конфігурація вилучення — файл налаштувань із переліком типів документів, порогами впевненості моделі та умовами, за яких значення йде на ручну перевірку.
- Схеми полів — опис кожного реквізиту: тип, обов'язковість, маска формату, допустимі значення та прив'язка до поля облікової системи, куди записується результат.
- Угода про розмітку — правила анотування сутностей для навчальної та перевірочної вибірок, щоб донавчання на нових документах не ламало вже досягнуту якість.
- Матриця прав доступу — розмежування ролей: хто бачить вихідний скан, хто вилучені значення, хто змінює схему полів і підтверджує результат.
- Регламент обробки — порядок дій при низькій впевненості, розбіжності з даними облікової системи та масовому збої розпізнавання.
- Інструкції для операторів — пам'ятки щодо екрана перевірки: що вважати помилкою, як виправляти й куди ескалювати спірні випадки.
- Журнал прогонів і метрики — доступ до точності за типами документів, щоб бачити просідання до того, як його помітять користувачі.
Зміни до схеми полів і порогів вносяться без правки коду, а новий тип документа заводиться через розмітку й налаштування конфігурації. Це і є умова, за якої система залишається керованою після здачі.
Кейс: як скоротили ручне введення при розмітці форм
Як було
Замовник приймав потік вхідних документів: скани накладних, анкети постачальників, акти. Оператори переносили по 12–18 полів у форму руками, і середній час обробки одного документа тримався на 6–8 хвилинах.
До 15% записів поверталися на правку після звірки, а в дні пікового навантаження черга сягала кількох сотень файлів — частина документів чекала на розбір понад добу.
Що змінили
Зібрали конвеєр, який читає документ як зображення і відразу віддає заповнену форму. Модель Donut виділяє структуру та значення полів, мовна модель приводить дати, суми й назви контрагентів до єдиного вигляду, а правила звірки перевіряють обов'язкові поля й арифметику рядків.
Оператор більше не вводить дані: він підтверджує результат там, де впевненість моделі нижча за поріг, і бачить підсвічені проблемні поля.
Що стало
Час обробки документа скоротився до 40–60 секунд, частка правок — 3–4%, і майже всі вони стосуються рукописних позначок. Відмови, коли документ губився в черзі, зникли: кожен файл отримує статус і потрапляє або до готового запису, або до черги ручної перевірки.
Близько 90% документів закриваються без участі людини, а за того самого штату потік зріс приблизно втричі — розбір перестав бути вузьким місцем.
Чим відрізняється вилучення за шаблоном від модельного?
Шаблонний розбір спирається на координати полів, якірні підписи та регулярні вирази: він детермінований, швидкий і передбачуваний, поки макет документа не змінюється.
Модель працює зі змістом полів — їй неважливо, де стоїть реквізит і як він підписаний, тому нову форму вона розбирає без перемальовування шаблону, але потребує розмічених прикладів і перевірки відповідей.
Вибір підходу — це про мінливість потоку документів. За одного типу макета шаблон дешевший у підтримці й простіший у налагодженні. Коли макетів десятки і вони надходять від сотень контрагентів, шаблон проти моделі програє: кількість правил зростає швидше, ніж обсяг документів.
Гібридна схема знімає це протиставлення: Donut і споріднені моделі вилучають значення разом з оцінкою впевненості за кожним полем, а правила перевіряють формати, обов'язковість і узгодженість реквізитів. Спірні випадки йдуть оператору, і його правки стають розміткою для донавчання.
Якщо систему розбору вже впроваджено, її не викидають. Правила залишаємо шаром контролю й еталоном для порівняння, модель вмикаємо тіньовим режимом на тому самому потоці й дивимося розбіжності за полями. Перенесення правил іде поступово: спочатку поля з високою варіативністю, потім решта.
Критерій перемикання — частка полів, які модель закриває не гірше за правила за того самого обсягу ручних правок. Поки поріг не досягнуто, працює гібрид: модель пропонує, правила й оператор підтверджують.
Технічні питання, які ставлять перед стартом
Точність автозаповнення — не одне число, а розподіл за типами документів і полями. На стабільному шаблоні система закриває майже все, на зім'ятому скані з рукописною правкою — помітно менше: річ не в моделі, а в тому, як вона поводиться на слабкому вході.
Тому ми будуємо контур із порогом впевненості: розпізнавання на Donut і мовна постобробка повертають поле разом з оцінкою, значення нижче порога йдуть на ручну перевірку, а неузгоджені не пишуться в облікову систему. Якість тримає архітектура, а не одна модель.
Що робити з нестандартними документами й рукописним текстом?
Єдиної цифри не обіцяємо: рахуємо якість за кожним типом документа на вашій вибірці. Друковані форми закриваються самі, рукописні позначки йдуть окремим маршрутом — система пропонує значення, людина підтверджує.
Як захищені персональні дані?
Обробку можна тримати в закритому контурі замовника. Персональні дані маскуються до запису в журнал, доступи розмежовані за ролями, строк зберігання вихідників задає політика.
Як рішення вбудовується в облікову систему?
Через програмний інтерфейс: поля йдуть із прив'язкою до об'єкта, повторне надсилання не дублює записи. Якщо інтерфейсу немає, забираємо документи із спільної папки або пошти й повертаємо результат туди ж.
Як контролюється якість після запуску?
Метрику рахуємо за полями, а не за документами цілком, — видно, де втрачається точність. Раз на узгоджений період звіряємо вибірку з вихідниками й донавчаємо модель на розбіжностях.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінка спиралася на дані, а не на здогадки, нам потрібен вхід від вас: як документ потрапляє в процес, які поля з нього дістаються і що відбувається з результатом далі.
Зазвичай достатньо 20-30 зразків у тому вигляді, у якому вони надходять, плюс опис того, де зараз править людина. Цього достатньо, щоб зрозуміти, де закінчується вилучення і починається нормалізація довідниками.
Розкажіть за пунктами:
- типи документів та їхні джерела — скани, фото, електронні файли або потік з облікової системи;
- які поля вилучаються і які з них критичні, а які припустимо заповнювати вручну;
- обсяг потоку та його піки — скільки документів на день і які сторінки найважчі;
- куди йде результат: вивантаження в облікову систему, файл узгодженого формату або ручна перевірка;
- вимоги до контролю: чи потрібне підсвічування впевненості за кожним полем і журнал правок оператора;
- які правила перевірки вже існують на боці замовника і хто відповідає за приймання.
У відповідь повернемося зі схемою рішення, планом упровадження та оцінкою строків. Окремо позначимо пілотну ділянку — зазвичай це один тип документа і 3-5 полів, щоб заміряти частку правильних заповнень і час обробки на реальних даних. Далі — розширення на решту типів і повний склад робіт за етапами.
