Чому розпізнавання таблиць ламається на сканах і PDF
Збій розпізнавання таблиць рідко починається з помилки в розпізнаванні символів — завдання підміняється раніше. Модель повертає рядки тексту, тоді як таблиця — це структура, де значення читається лише разом із координатою та заголовком стовпця. Щойно текст витягують без геометрії, складна верстка таблиць розсипається до етапу перевірки.
Об'єднані комірки — перша точка відмови: сенс значення рознесений по двох-трьох рівнях шапки, а саме воно лежить в одній комірці. За плоского розбору зв'язок втрачається, і рядок їде не в той стовпець.
Багаторядкові заголовки та порожні комірки-роздільники, що означають «те саме, що вище», добивають картину — без відновлення ієрархії шапки дані виглядають правдоподібно, але невірні.
Скани й PDF додають другу групу причин. PDF із текстовим шаром віддає координати, але часто це документ, перезібраний після друку, з утраченими лініями сітки; відсканований файл — лише зображення, де поворот на пару градусів, перспектива й шум зсувають межі щодо вихідних.
Без вирівнювання за лініями та стійкого пошуку меж комірок комірка «пливе», значення склеюються або йдуть у сусідній стовпець.
Окрема причина — розриви сторінок. Таблиця, розірвана на дві сторінки, приїздить другою половиною без шапки, а повторений заголовок потрапляє в дані звичайним рядком.
Якість вилучення даних не дотягує до порогу, за якого вивантаження можна віддати в облікову систему, і оператор починає переносити значення руками. Розбираємо, як кожен із цих збоїв закривається.
Вимірний ефект: точність, швидкість, обсяг обробки
Ефект від автоматизації введення даних вважаємо в трьох точках, а не «загалом за проєктом». Перша — частка документів, що потрапляють в облікову систему без правки оператора: на старті це зазвичай 60–70%, бо нахил сканів, об'єднані комірки та багаторядкові шапки ламають розбір.
Друга — час на пакет із тисячі сторінок: дві-три зміни ручного введення проти хвилин машинного розбору. Третя — частка рядків, які модель позначає як сумнівні й віддає на перевірку.
Точність вилучення зростає нерівномірно, і це видно заздалегідь. Числові колонки, вирівняні за правим краєм, зчитуються практично без помилок, а складені шапки на два-три рядки та порожні роздільники всередині таблиці потребують окремого правила.
Тому у звіті точність розкладена за типами таблиць і полів: зрозуміло, де автозаповнення вмикається одразу, а де потрібен контроль суми або звірка з довідником.
Зникає цілий клас помилок ручного введення: зсув розряду, перестановка колонок під час перенесення, пропущений рядок на стику сторінок, задвоєна позиція.
Машинний розбір застосовує одне правило до всього пакета, а звірка суми порядкових значень із підсумковим рядком відсікає викривлення до запису в облік. Якщо контроль не сходиться, документ не «дописують на око», а відправляють у чергу винятків із позначкою проблемної області.
Розвантаження операторів іде за рахунок зниження ручних операцій, а не прискорення набору. Люди перестають переносити цифри й займаються винятками — як правило, це 5–15% сторінок: зім'яті скани, рукописні правки, таблиці без шапки.
Стек підбираємо під тип документа: друковані форми розбирає відкритий рушій (Tesseract) із постобробкою структури, рукописні бланки — мультимодальна модель, тому швидкість обробки документів зростає без пропорційного зростання команди.
Варіанти обробки документів: шаблони, правила, навчання
Режим обробки вибирається не за «складністю» документа, а за стабільністю його форми. Шаблонне вилучення спирається на координати блоків на сторінці, правила розбору — на структуру тексту, навчання на прикладах — на статистику за множиною зразків.
Помилка у виборі проявляється однаково: частка таблиць, що потребують ручної правки, зростає разом з обсягом потоку.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Шаблонне вилучення | Форма зафіксована: блоки та колонки не зміщуються від постачання до постачання | Ламається при зміні версії бланка, на кожен новий тип потрібне окреме налаштування |
| Правила розбору | Структура передбачувана: стійкі заголовки, роздільники, повторювані рядки | Чутливість до друкарських помилок і «схожих, але інших» документів, правила розростаються |
| Навчання на прикладах | Різнорідні скани, кілька постачальників, плаваюча верстка | Потрібна розмічена вибірка, якість залежить від покриття рідкісних форм |
Змішаний потік документів закривається гібридною схемою: документ спочатку визначається за типом бланка, потім іде у свій режим — шаблон, правила або модель.
Комірки нижче порогу впевненості не йдуть у вивантаження, а потрапляють у чергу ручної верифікації, і оператор бачить підсвічений фрагмент вихідного зображення, а не порожнє поле.
Вибір режиму ми перевіряємо на ретроспективі замовника: проганяємо корпус документів і рахуємо частку таблиць, розібраних без правки, а також обсяг правил, який доведеться супроводжувати за наступної зміни форми.
Якщо правила зростають швидше, ніж точність, режим змінюємо — цей замір робиться до промислового запуску, а не після.
Етапи: розбір документів, налаштування, перевірка, передача
Документи рідко приходять однорідними: скани з нахилом, зшиті аркуші, шапки, що повторюються через сторінку, рукописні позначки поверх друкованого тексту. На такому наборі розпізнавач помиляється нерівномірно — на одному типі бланка проходить чисто, на іншому плутає межі колонок.
Тому етапи впровадження будуємо з контрольною точкою на кожному кроці: видно, що вже зафіксовано, а що ні.
- Аудит зразків — збираємо реальні документи, зокрема незручні: погані скани, багатосторінкові таблиці, шаблони від різних контрагентів.
- Розбір документів за класами — для кожного типу своя схема полів і правила для об'єднаних комірок і повторюваних шапок.
- Еталонна вибірка — 100–200 сторінок розмічаємо вручну й ділимо на навчальну та відкладену частини; якість рахуємо за комірками, а не за сторінкою.
- Складання вилучення — визначення областей таблиць, розпізнавання структури, приведення значень до єдиного формату.
- Перевірка якості — прогін на відкладеній частині, звіт із часткою вірних комірок і розбором типових помилок за кожним класом документів.
- Налаштування за результатами — уточнюємо правила та постобробку, потім повторюємо прогін на тому самому еталоні, щоб порівняння було чесним.
- Передача в експлуатацію — схема запуску, обробка винятків, черга ручної перевірки для спірних сторінок, документація та навчання вашої команди.
Що залишається у вас: конфігурації, схеми, регламенти
Комплект передається не «за фактом здачі», а як робочий інструмент підтримки: за ним ваша команда закриває штатні ситуації сама, без звернення до нас. Нижче — що саме переходить вам у руки разом із працюючим розпізнаванням таблиць.
- Схеми інтеграції — звідки приходять документи (пошта, мережева тека, облікова система), куди йде результат, де точки відмови й як переключитися на резервний маршрут без втрати файлів.
- Правила доступу — ролі та права: кому видно вихідні скани, хто змінює пороги впевненості та словник полів, де ведеться журнал операцій.
- Словник полів і правила розмітки — як колонки зіставляються з полями облікової системи, що робити з об'єднаними комірками, багаторядковими шапками та повернутими сканами.
- Регламент супроводу — періодичність перевірок якості, порядок оновлення конфігурації, викатка змін і відкат до попереднього набору налаштувань.
- Розбір спірних випадків — інструкція для оператора: як виглядає черга на ручну перевірку, що дивитися в першу чергу, як позначати помилку, щоб вона потрапила в донавчання.
- Документація рішення — опис конфігурації, метрики якості за кожним типом форми, перелік відомих обмежень і обхідних шляхів.
- Еталонні набори та перевірки — зразки документів і сценарії прогону, що показують після будь-якої зміни, чи не просів точність на складних таблицях.
Такий комплект дозволяє передати супровід внутрішній команді й повертатися до нас лише за розвитком: новими типами документів, зміною схеми вивантаження або підвищенням точності.
Практика: потік рахунків і актів до та після змін
Оптова компанія приймає близько восьми тисяч рахунків та актів на місяць від чотирьохсот контрагентів. Частина приходить електронними PDF із текстовим шаром, частина — сканами й фотографіями з різною якістю: бліді відбитки, повернутий аркуш, таблиця на дві сторінки.
Позиції потрібно порядно заводити в обліковий контур 1С — фінанси та склад звіряють рядки, а не підсумок документа.
До: ручне введення на дві зміни
Два оператори розбирали потік вручну: відкривали файл, набивали рядки, звіряли підсумок. Місячний пакет закривався за три робочі дні, частка помилок у числових колонках доходила до 4–6%, і знаходили їх уже на звірці, перевідкриваючи документи.
Після: авторозбір і контроль якості
Тепер потік ділиться за типом джерела: текстові файли розбираються напряму, скани проходять розпізнавання таблиць із відновленням комірок, шапок і підсумкових рядків.
Кожна позиція нормалізується — код, одиниця, ставка, сума — і перевіряється контрольними сумами: сума рядків звіряється з підсумком таблиці, розходження вище порогу йде оператору. В облік без правок потрапляє 84% рядків, документів із правками — близько 12%.
Допрацювання по ходу
Після перших тижнів додали шаблони нетипових актів, розбір багатосторінкових таблиць із перенесенням шапки та обробку повернутих сканів. Кожну правку перевіряли на еталонній вибірці, щоб не втратити досягнуту точність.
Підсумок: місячний пакет обробляється за один день силами оператора й перевіряльного, а не за три дні двома фахівцями. Розходження в сумах відсікаються до обліку, а не спливають на звірці.
Чим відрізняється розпізнавання таблиць від звичайного тексту
Звичайне розпізнавання тексту — завдання одновимірне: зберегти порядок символів у рядку. Достатньо вірно розбити сторінку на знаки та слова, а якість вимірюється часткою правильно розпізнаних символів.
Таблиця двовимірна: значення визначається перетином рядка та стовпця, і якщо сітка втрачена, фрагмент «Підсумок 1 250» перестає бути числом із зрозумілим сенсом.
Заважає не шрифт, а геометрія. Об'єднані комірки, багаторівневі шапки, порожня комірка як значуща ознака, таблиці без ліній — усе це потрібно розв'язати в модель «рядок — стовпець — значення».
Працює зв'язка: спочатку виділяємо лінії та межі блоків (базові алгоритми такого розбору є у відкритих бібліотеках на кшталт Camelot), потім збираємо адресовану сітку і лише потім розпізнаємо вміст кожної комірки окремо — уже з урахуванням того, що колонка чисел і колонка дат потребують різних правил.
Ключове — зв'язки комірок. Заголовок шапки пов'язаний з усіма значеннями стовпця, а багаторівнева шапка дає складений ключ, який потрібно склеїти в одне ім'я поля.
Якщо зв'язки не відновлені, текст розпізнано ідеально, але підсумки та зрізи у звіті рахуються невірно, а рядки під час завантаження в облікову систему стають не на свої місця.
Звідси інші вимоги до перевірки. Посимвольна точність перестає бути критерієм приймання: вона може бути високою, коли стовпці вже зсунулися.
Перевіряємо структурно — збіжність числа рядків і стовпців, збіг сум за рядками та за стовпцями, повнота ключів, відсутність дублів, стабільність результату за повторного прогону на контрольній вибірці документів.
Тож приймання будується не на «текст із картинки», а на придатності вивантаження: набір записів із валідними ключами та перевіреними зв'язками, який можна завантажити без ручної правки.
Скільки рядків зсунулося і скільки записів не пройшло валідацію — це і є метрики якості розпізнавання таблиць.
Технічні сумніви, які знімаємо на старті проєкту
Інженерні сумніви рідко стосуються самої моделі — вони про вхідні дані, приймання результату та межі відповідальності. Тому до старту розбираємо якість сканів, відповідальність за помилку, обсяг пілота та розширення охоплення.
У нас погані скани — розпізнавання взагалі запрацює?
Спочатку рахуємо метрику на вашій вибірці: частка комірок, вилучених вірно, на парі сотень сторінок. Шум, нахил і перекошена сітка лікуються вирівнюванням і детекцією ліній; рукописні вставки та злиплі символи дають просідання — такі поля позначаємо на ручну перевірку.
Якщо точність нижча за поріг, говоримо прямо, що дасть передобробка, а що — лише повторне сканування.
Хто відповідає за помилку у вилученому значенні?
У схемі приймання для кожного поля задано поріг впевненості: вище — значення йде в облікову систему саме, нижче — у чергу на перевірку оператором. Помилка не їде в облік мовчки, вона зупиняється на контролі.
Ми відповідаємо за конвеєр і стабільність метрики, ви — за правило: які поля критичні та що робити при незбігу.
Як виглядає пілотний етап?
Беремо один тип документа й одну ділянку процесу та проганяємо весь шлях від завантаження до запису у вашу систему. На виході — працюючий потік, звіт щодо точності кожного поля та перелік місць, де потрібні правки правил. Рішення про масштабування ухвалюєте за цифрами.
Наскільки складно потім розширити охоплення документів?
Конвеєр зібраний з етапів: розбір сторінки, детекція таблиці, відновлення структури, зіставлення колонок зі схемою. Новий тип документа — це зазвичай новий шаблон і правила нормалізації на останніх етапах, а не переписування ядра.
Тому другий і третій види бланків підключаються помітно швидше за перший, а навантаження на підтримку не зростає лінійно з числом форм.
Обговоримо завдання і повернемося з оцінкою та планом робіт
Щоб повернутися з оцінкою та планом робіт, нам не потрібен увесь архів документів — достатньо зрізу за реальним потоком.
Чим точніше ви опишете, які таблиці приходять і в якому вигляді, тим менше припущень залишиться в плані й тим швидше пілотний запуск вийде на ваші сторінки, а не на демонстраційні.
Обговорення завдання займає одну розмову: ми розбираємо потік, відзначаємо, які шаблони закриваються налаштуванням, а де потрібна окрема модель, і домовляємося про метрики приймання. Мінімальний набір даних для цього такий:
- Типи документів: рахунки, накладні, виписки, галузеві звіти — що сканують, що приходить цифровим файлом, що фотографують.
- Обсяг потоку: скільки сторінок на місяць і його профіль — рівний чи з піками у звітні періоди.
- Структура таблиць: фіксовані шаблони чи довільні, об'єднані комірки, багаторівневі шапки, багаторядкові позиції.
- Якість сканів: роздільність, нахил, шум, рукописні правки — це головний чинник підсумкової точності.
- Куди віддавати результат: Excel, облікова система, база або обмін через API — формат і правила звірки.
- Ролі людей: хто розбирає спірні рядки і яка частка ручної правки для вас прийнятна.
- Контур і доступи: хмара чи внутрішня інфраструктура, вимоги ІБ, наявність тестового середовища.
- Зразки: кілька десятків сторінок, що покривають усі наявні варіанти шаблонів.
З цього набору збирається план пілота: обсяг вибірки для перевірки, цільові метрики за рядками та комірками, етапи й умови роботи — їх фіксуємо до старту, щоб результат приймався за заздалегідь узгодженими цифрами.
Опишіть завдання у вільній формі та додайте зразки — повернемося з оцінкою термінів і порядком підготовки до старту.
