Иногда OCR распознаёт каждую цифру правильно и всё равно выдаёт неверный документ. Достаточно, чтобы значение из третьей колонки попало во вторую строку соседней позиции.
Для таблицы мало знать символы. Нужно восстановить отношения: какая ячейка относится к какой строке, где заголовок, что объединено, какой итог относится к какому блоку и продолжается ли таблица на следующей странице. Извлечение таблиц из PDF нужно проверять как восстановление структуры, а не как обычное распознавание набора символов.
Поэтому я проверяю табличное извлечение отдельно от обычного текста. Ошибка структуры способна изменить смысл даже при идеальном OCR.
Таблица — это граф отношений между ячейками
С практической точки зрения у каждой ячейки есть строка, колонка, координаты и иногда span на несколько рядов или столбцов. Заголовок задаёт значение колонке. Итоговая строка относится к определённому набору позиций.
Amazon Textract, Azure Document Intelligence и Google Document AI возвращают структурные элементы таблиц, но форматы и возможности различаются. Я бы всё равно приводил результат к внутренней схеме компании, где явно определены row index, column key и исходная область страницы.
Это позволяет проверять не только текст `1500`, но и утверждение `цена позиции №4 = 1500`. Именно второе нужно бизнес-процессу.
Проверяемые источники: AWS — Tables — Amazon Textract · Microsoft — Document Intelligence layout model · Google Cloud — Document AI overview
Merged cells ломают простое правило «одна ячейка — одно значение»
Объединённый заголовок может относиться сразу к нескольким колонкам. Наименование товара занимает две строки. Категория указана один раз для группы позиций. Если parser просто идёт слева направо, часть контекста теряется.
Я бы сохранял rowSpan/columnSpan или аналогичную структуру, а затем уже нормализовал данные в плоскую бизнес-таблицу. При распрямлении нужно явно определить, какие значения наследуются вниз и какие остаются только заголовком.
Особенно осторожно стоит обращаться с визуальными отступами вместо реальных границ. Человек видит группировку по дизайну страницы, а модель может вернуть набор блоков без однозначной связи.
Проверяемые источники: AWS — Tables — Amazon Textract · Microsoft — Document Intelligence layout model
Многостраничная таблица должна сохранить одну схему
На второй странице часто повторяется header. Иногда он немного отличается: добавляется номер страницы, пропадает служебная колонка, меняется ширина. Если обрабатывать страницы независимо, один документ превращается в несколько таблиц.
Я бы сопоставлял headers и типы колонок, затем проверял продолжение по контексту документа. Повторный заголовок не должен становиться строкой товара. Номер страницы не должен попадать в значение количества.
Если продолжение неоднозначно, лучше создать отдельное исключение `table_boundary_unknown`, чем незаметно склеить две несвязанные таблицы.
Проверяемые источники: Microsoft — Document Intelligence layout model · Google Cloud — Document AI overview
Пустое значение и потерянная ячейка — разные состояния
Пустая ячейка может быть корректной: скидка не применяется, комментария нет. Но parser может не найти область из-за плохого скана. В обоих случаях на выходе легко получить `null`, хотя смысл отличается.
Я предпочитаю различать `empty_in_source`, `not_detected`, `not_applicable` и `needs_review`, если процесс действительно зависит от этого различия. Тогда downstream-правила не принимают отсутствие распознавания за отсутствие значения в документе.
Для критичной колонки стоит проверять, что у каждой бизнес-строки есть ожидаемый набор полей. Неожиданно пропавшее количество — отдельный сигнал качества.
Проверяемые источники: Google Cloud — Document AI overview · Google Cloud — Enterprise Document OCR
Арифметические проверки ловят структурные ошибки лучше общего confidence
Если таблица содержит количество, цену и сумму, можно проверить `quantity × price = line total` с правилами округления. Затем сумма строк сопоставляется с subtotal и итогом. Несходящаяся арифметика часто указывает на пропущенную или сдвинутую ячейку.
Я бы также проверял количество позиций, единицы измерения, валюту и допустимые типы данных. Строка, где в колонку количества попало слово из описания, должна остановиться до импорта.
Такие правила не заменяют модель. Они дают независимый слой доказательства. Именно этого обычно не хватает в демонстрации «мы извлекли таблицу из PDF».
Проверяемые источники: AWS — Tables — Amazon Textract · Microsoft — Document Intelligence layout model
В очередь нужно отправлять строку или ячейку, а не весь PDF
Если из ста строк сомнительны две, сотруднику нужны именно они. Интерфейс review показывает исходный фрагмент, соседние колонки, распознанное значение, причину проверки и контрольный итог.
После исправления можно повторно пересчитать зависимые суммы. Решение человека сохраняется как версия конкретной ячейки или строки, а не как неформальная заметка «документ проверен».
Для меня это критерий зрелости табличного процесса: система умеет доказать структуру большинства данных и локализовать исключение до минимального проверяемого фрагмента.
Проверяемые источники: AWS — Tables — Amazon Textract · Google Cloud — Document AI overview
Golden set для таблиц должен содержать плохие страницы
Я бы не собирал тест только из аккуратных цифровых PDF. Нужны сканы, перекошенные страницы, слабый контраст, merged cells, таблицы через несколько страниц и документы с повторяющимися заголовками.
Эталон хранит не только текст ячеек, но и правильную структуру строк и колонок. Тогда regression test замечает ситуацию, где OCR-качество формально не изменилось, а alignment стал хуже.
После обновления модели или parser такой набор прогоняется целиком. Для массовой обработки это надёжнее ручного впечатления от пары новых документов.
Проверяемые источники: AWS — Tables — Amazon Textract · Microsoft — Document Intelligence layout model · Google Cloud — Document AI overview
Контрольные вопросы перед внедрением
Почему OCR неправильно распознаёт таблицы в PDF?
Часто символы распознаны верно, а ошибка возникает в структуре: строки, колонки, объединённые ячейки или границы между страницами. Поэтому качество таблицы нужно проверять отдельно от качества текста.
Как проверить извлечённую таблицу автоматически?
Используйте схему колонок, обязательность полей, типы данных, количество строк и арифметические связи между значениями. Критичные несоответствия отправляйте в review вместе с исходным фрагментом.
Можно ли полностью автоматизировать PDF в Excel?
Для стабильных документов — часто да. Для вариативных таблиц всё равно нужен контроль исключений. Финальный Excel должен отражать структуру исходника; наличия похожих чисел недостаточно.
Таблица считается распознанной не тогда, когда все символы появились в JSON. Нужно подтвердить отношения между значениями: строку, колонку, заголовок, итог и продолжение между страницами. Пока структура не доказана, цифры остаются только набором распознанного текста.
Для соседних проверок пригодятся для «извлечение таблиц из PDF»: Что делать, если AI неправильно распознал документ · Как автоматически извлекать данные из счетов, актов и договоров · Как передавать данные из PDF в 1С с подтверждением сотрудника.
Источники и методическая база
- Tables — Amazon TextractAWS
- Document Intelligence layout modelMicrosoft
- Document AI overviewGoogle Cloud
- Enterprise Document OCRGoogle Cloud
