Распознавание таблиц из изображений и PDF: пайплайн под ключ

Почему распознавание таблиц ломается на сканах и PDF

Сбой распознавания таблиц редко начинается с ошибки в распознавании символов — задача подменяется раньше. Модель возвращает строки текста, тогда как таблица — это структура, где значение читается только вместе с координатой и заголовком столбца. Как только текст извлекают без геометрии, сложная вёрстка таблиц рассыпается до этапа проверки.

Объединённые ячейки — первая точка отказа: смысл значения разнесён по двум-трём уровням шапки, а само оно лежит в одной ячейке. При плоском разборе связь теряется, и строка уезжает не в тот столбец. Многострочные заголовки и пустые ячейки-разделители, означающие «то же, что выше», добивают картину — без восстановления иерархии шапки данные выглядят правдоподобно, но неверны.

Сканы и PDF добавляют вторую группу причин. PDF с текстовым слоем отдаёт координаты, но часто это документ, пересобранный после печати, с потерянными линиями сетки; отсканированный файл — только изображение, где поворот на пару градусов, перспектива и шум сдвигают границы относительно исходных. Без выравнивания по линиям и устойчивого поиска граф ячейка «плывёт», значения склеиваются или уходят в соседний столбец.

Отдельная причина — разрывы страниц. Таблица, разорванная на две страницы, приезжает второй половиной без шапки, а повторённый заголовок попадает в данные обычной строкой. Качество извлечения данных не дотягивает до порога, при котором выгрузку можно отдать в учётную систему, и оператор начинает переносить значения руками. Разбираем, как каждый из этих сбоев закрывается.

Измеримый эффект: точность, скорость, объём обработки

Эффект от автоматизации ввода данных считаем в трёх точках, а не «в целом по проекту». Первая — доля документов, попадающих в учётную систему без правки оператора: на старте это обычно 60–70%, потому что наклон сканов, объединённые ячейки и многострочные шапки ломают разбор. Вторая — время на пакет из тысячи страниц: две-три смены ручного ввода против минут машинного разбора. Третья — доля строк, которые модель помечает как сомнительные и отдаёт на проверку.

Точность извлечения растёт неравномерно, и это видно заранее. Числовые колонки, выровненные по правому краю, считываются практически без ошибок, а составные шапки на две-три строки и пустые разделители внутри таблицы требуют отдельного правила. Поэтому в отчёте точность разложена по типам таблиц и полей: понятно, где автозаполнение включается сразу, а где нужен контроль суммы или сверка со справочником.

Уходит целый класс ошибок ручного ввода: сдвиг разряда, перестановка колонок при переносе, пропущенная строка на стыке страниц, задвоенная позиция. Машинный разбор применяет одно правило ко всему пакету, а сверка суммы построчных значений с итоговой строкой отсекает искажения до записи в учёт. Если контроль не сходится, документ не «дописывают на глаз», а отправляют в очередь исключений с отметкой проблемной области.

Разгрузка операторов идёт за счёт снижения ручных операций, а не ускорения набора. Люди перестают переносить цифры и занимаются исключениями — как правило, это 5–15% страниц: замятые сканы, рукописные правки, таблицы без шапки. Стек подбираем под тип документа: печатные формы разбирает открытый движок (Tesseract) с постобработкой структуры, рукописные бланки — мультимодальная модель, поэтому скорость обработки документов растёт без пропорционального роста команды.

Варианты обработки документов: шаблоны, правила, обучение

Режим обработки выбирается не по «сложности» документа, а по стабильности его формы. Шаблонное извлечение опирается на координаты блоков на странице, правила разбора — на структуру текста, обучение на примерах — на статистику по множеству образцов. Ошибка в выборе проявляется одинаково: доля таблиц, требующих ручной правки, растёт вместе с объёмом потока.

Смешанный поток документов закрывается гибридной схемой: документ сначала определяется по типу бланка, затем идёт в свой режим — шаблон, правила или модель. Ячейки ниже порога уверенности не уходят в выгрузку, а попадают в очередь ручной верификации, и оператор видит подсвеченный фрагмент исходного изображения, а не пустое поле.

Выбор режима мы проверяем на ретроспективе заказчика: прогоняем корпус документов и считаем долю таблиц, разобранных без правки, а также объём правил, который придётся сопровождать при следующей смене формы. Если правила растут быстрее, чем точность, режим меняем — этот замер делается до промышленного запуска, а не после.

Этапы: разбор документов, настройка, проверка, передача

Документы редко приходят однородными: сканы с наклоном, сшитые листы, шапки, повторяющиеся через страницу, рукописные пометки поверх печатного текста. На таком наборе распознаватель ошибается неравномерно — на одном типе бланка проходит чисто, на другом путает границы колонок. Поэтому этапы внедрения строим с контрольной точкой на каждом шаге: видно, что уже зафиксировано, а что нет.

1. Аудит образцов — собираем реальные документы, включая неудобные: плохие сканы, многостраничные таблицы, шаблоны от разных контрагентов.
2. Разбор документов по классам — для каждого типа своя схема полей и правила для объединённых ячеек и повторяющихся шапок.
3. Эталонная выборка — 100–200 страниц размечаем вручную и делим на обучающую и отложенную части; качество считаем по ячейкам, а не по странице.
4. Сборка извлечения — определение областей таблиц, распознавание структуры, приведение значений к единому формату.
5. Проверка качества — прогон на отложенной части, отчёт с долей верных ячеек и разбором типовых ошибок по каждому классу документов.
6. Настройка по результатам — уточняем правила и постобработку, затем повторяем прогон на том же эталоне, чтобы сравнение было честным.
7. Передача в эксплуатацию — схема запуска, обработка исключений, очередь ручной проверки для спорных страниц, документация и обучение вашей команды.

Что остаётся у вас: конфигурации, схемы, регламенты

Комплект передаётся не «по факту сдачи», а как рабочий инструмент поддержки: по нему ваша команда закрывает штатные ситуации сама, без обращения к нам. Ниже — что именно переходит вам на руки вместе с работающим распознаванием таблиц.

• Схемы интеграции — откуда приходят документы (почта, сетевая папка, учётная система), куда уходит результат, где точки отказа и как переключиться на резервный маршрут без потери файлов.
• Правила доступа — роли и права: кому видны исходные сканы, кто меняет пороги уверенности и словарь полей, где ведётся журнал операций.
• Словарь полей и правила разметки — как колонки сопоставляются с полями учётной системы, что делать с объединёнными ячейками, многострочными шапками и повёрнутыми сканами.
• Регламент сопровождения — периодичность проверок качества, порядок обновления конфигурации, выкат изменений и откат к предыдущему набору настроек.
• Разбор спорных случаев — инструкция для оператора: как выглядит очередь на ручную проверку, что смотреть в первую очередь, как помечать ошибку, чтобы она попала в дообучение.
• Документация решения — описание конфигурации, метрики качества по каждому типу формы, перечень известных ограничений и обходных путей.
• Эталонные наборы и проверки — образцы документов и сценарии прогона, показывающие после любого изменения, не просела ли точность на сложных таблицах.

Такой комплект позволяет передать сопровождение внутренней команде и вернуться к нам только за развитием: новыми типами документов, изменением схемы выгрузки или повышением точности.

Практика: поток счетов и актов до и после изменений

Оптовая компания принимает около восьми тысяч счетов и актов в месяц от четырёхсот контрагентов. Часть приходит электронными PDF с текстовым слоем, часть — сканами и фотографиями с разным качеством: бледные оттиски, повёрнутый лист, таблица на две страницы. Позиции нужно построчно заводить в учётный контур 1С — финансы и склад сверяют строки, а не итог документа.

До: ручной ввод в две смены

Два оператора разбирали поток вручную: открывали файл, набивали строки, сверяли итог. Месячный пакет закрывался за три рабочих дня, доля ошибок в числовых колонках доходила до 4–6%, и находили их уже на сверке, переоткрывая документы.

После: авторазбор и контроль качества

Теперь поток делится по типу источника: текстовые файлы разбираются напрямую, сканы проходят распознавание таблиц с восстановлением ячеек, шапок и итоговых строк. Каждая позиция нормализуется — код, единица, ставка, сумма — и проверяется контрольными суммами: сумма строк сверяется с итогом таблицы, расхождение выше порога уходит оператору. В учёт без правок попадает 84% строк, документов с правками — около 12%.

Доработки по ходу

После первых недель добавили шаблоны нетиповых актов, разбор многостраничных таблиц с переносом шапки и обработку повёрнутых сканов. Каждую правку проверяли на эталонной выборке, чтобы не потерять достигнутую точность.

Итог: месячный пакет обрабатывается за один день силами оператора и проверяющего, а не за три дня двумя специалистами. Расхождения в суммах отсекаются до учёта, а не всплывают на сверке.

Чем отличается распознавание таблиц от обычного текста

Обычное распознавание текста — задача одномерная: сохранить порядок символов в строке. Достаточно верно разбить страницу на знаки и слова, а качество измеряется долей правильно распознанных символов. Таблица двумерна: значение определяется пересечением строки и столбца, и если сетка потеряна, фрагмент «Итого 1 250» перестаёт быть числом с понятным смыслом.

Мешает не шрифт, а геометрия. Объединённые ячейки, многоуровневые шапки, пустая ячейка как значимый признак, таблицы без линий — всё это нужно разрешить в модель «строка — столбец — значение». Работает связка: сначала выделяем линии и границы блоков (базовые алгоритмы такого разбора есть в открытых библиотеках вроде Camelot), затем собираем адресуемую сетку и только потом распознаём содержимое каждой ячейки отдельно — уже с учётом того, что колонка чисел и колонка дат требуют разных правил.

Ключевое — связи ячеек. Заголовок шапки связан со всеми значениями столбца, а многоуровневая шапка даёт составной ключ, который нужно склеить в одно имя поля. Если связи не восстановлены, текст распознан идеально, но итоги и срезы в отчёте считаются неверно, а строки при загрузке в учётную систему встают не на свои места.

Отсюда другие требования к проверке. Посимвольная точность перестаёт быть критерием приёмки: она может быть высокой, когда столбцы уже сдвинулись. Проверяем структурно — сходимость числа строк и столбцов, совпадение сумм по строкам и по столбцам, полнота ключей, отсутствие дублей, стабильность результата при повторном прогоне на контрольной выборке документов.

Поэтому приёмка строится не на «текст из картинки», а на пригодности выгрузки: набор записей с валидными ключами и проверенными связями, который можно загрузить без ручной правки. Сколько строк сдвинулось и сколько записей не прошло валидацию — это и есть метрики качества распознавания таблиц.

Технические сомнения, которые снимаем на старте проекта

Инженерные сомнения редко касаются самой модели — они про входные данные, приёмку результата и границы ответственности. Поэтому до старта разбираем качество сканов, ответственность за ошибку, объём пилота и расширение охвата.

Кто отвечает за ошибку в извлечённом значении?

В схеме приёмки для каждого поля задан порог уверенности: выше — значение уходит в учётную систему само, ниже — в очередь на проверку оператором. Ошибка не уезжает в учёт молча, она останавливается на контроле. Мы отвечаем за конвейер и стабильность метрики, вы — за правило: какие поля критичны и что делать при несовпадении.

Как выглядит пилотный этап?

Берём один тип документа и один участок процесса и прогоняем весь путь от загрузки до записи в вашу систему. На выходе — работающий поток, отчёт по точности каждого поля и перечень мест, где нужны правки правил. Решение о масштабировании принимаете по цифрам.

Насколько сложно потом расширить охват документов?

Конвейер собран из этапов: разбор страницы, детекция таблицы, восстановление структуры, сопоставление колонок со схемой. Новый тип документа — это обычно новый шаблон и правила нормализации на последних этапах, а не переписывание ядра. Поэтому второй и третий виды бланков подключаются заметно быстрее первого, а нагрузка на поддержку не растёт линейно с числом форм.

Обсудим задачу и вернёмся с оценкой и планом работ

Чтобы вернуться с оценкой и планом работ, нам не нужен весь архив документов — достаточно среза по реальному потоку. Чем точнее вы опишете, какие таблицы приходят и в каком виде, тем меньше допущений останется в плане и тем быстрее пилотный запуск выйдет на ваши страницы, а не на демонстрационные.

Обсуждение задачи занимает один разговор: мы разбираем поток, отмечаем, какие шаблоны закрываются настройкой, а где нужна отдельная модель, и договариваемся о метриках приёмки. Минимальный набор данных для этого такой:

• Типы документов: счета, накладные, выписки, отраслевые отчёты — что сканируют, что приходит цифровым файлом, что фотографируют.
• Объём потока: сколько страниц в месяц и его профиль — ровный или с пиками в отчётные периоды.
• Структура таблиц: фиксированные шаблоны или произвольные, объединённые ячейки, многоуровневые шапки, многострочные позиции.
• Качество сканов: разрешение, наклон, шум, рукописные правки — это главный фактор итоговой точности.
• Куда отдавать результат: Excel, учётная система, база или обмен по API — формат и правила сверки.
• Роли людей: кто разбирает спорные строки и какая доля ручной правки для вас приемлема.
• Контур и доступы: облако или внутренняя инфраструктура, требования ИБ, наличие тестовой среды.
• Образцы: несколько десятков страниц, покрывающих все встречающиеся варианты шаблонов.

Из этого набора собирается план пилота: объём выборки для проверки, целевые метрики по строкам и ячейкам, этапы и условия работы — их фиксируем до старта, чтобы результат принимался по заранее согласованным цифрам. Опишите задачу в свободной форме и приложите образцы — вернёмся с оценкой сроков и порядком подготовки к старту.