Как устроены современные пайплайны обработки PDF-документов с таблицами, формами и рукописными пометками

Этап 1. Анализ документа

Обработка начинается задолго до OCR.

Первой задачей становится определение того, что именно находится внутри документа.

Система должна понять:

• сколько страниц содержит PDF;

• какие страницы являются текстовыми;

• где расположены таблицы;

• присутствуют ли формы;

• есть ли изображения или рукописные элементы.

На этом этапе выполняется layout analysis — анализ структуры страницы. Именно он позволяет определить логические блоки документа до начала извлечения данных.

Ошибки на этом этапе часто приводят к проблемам в дальнейшем. Если таблица не была обнаружена как таблица, последующий OCR уже не сможет восстановить её структуру.

Этап 2. Извлечение текста

После определения структуры документа начинается извлечение текста.

Несмотря на развитие OCR-free моделей, большинство production-систем по-прежнему используют OCR как отдельный этап обработки. Исследование показывает, что OCR-зависимые пайплайны остаются наиболее надёжным вариантом, когда важны точность, воспроизводимость результата и работа со сложными таблицами.

На практике OCR становится промежуточным представлением документа, которое затем используется остальными компонентами системы.

Среди открытых решений в этой роли часто используются:

• Surya;

• PaddleOCR;

• Tesseract.

Однако сами по себе эти инструменты обычно не решают задачу обработки документа целиком.

Этап 3. Восстановление структуры страницы

После получения текста необходимо определить связи между элементами документа.

На этом этапе система отвечает на вопросы:

• какой блок читать первым;

• какие элементы относятся к одной колонке;

• где находятся заголовки;

• какие подписи связаны с таблицами;

• как восстановить порядок чтения страницы.

Для человека подобная структура очевидна.

Для алгоритма это отдельная задача, которая сегодня считается одной из ключевых в Document AI. Не случайно современные бенчмарки вроде OmniDocBench оценивают порядок чтения наряду с текстом и таблицами.

На практике ошибки структуры могут оказаться важнее ошибок OCR.

Документ может быть прочитан безошибочно, но в неправильной п�следовательности.

Этап 4. Извлечение таблиц

Следующий уровень сложности — таблицы.

Если текст можно представить как последовательность символов, то таблица представляет собой структуру связей между данными.

Поэтому современные пайплайны выделяют отдельный этап table recognition.

Задача включает:

• поиск таблиц;

• определение строк и столбцов;

• восстановление объединённых ячеек;

• определение заголовков;

• сохранение структуры при переносе между страницами.

Именно поэтому в современных исследованиях используются отдельные наборы данных для оценки качества таблиц, включая FinTabNet, PubTabNet и SynthTabNet.

Фактически извлечение таблиц сегодня рассматривается как самостоятельная инженерная задача внутри Document AI.

Этап 5. Обработка рукописных элементов

Особое место занимают документы, где печатный текст сочетается с рукописным.

Это могут быть:

• подписи;

• комментарии;

• пометки на полях;

• исправления;

• заполненные вручную формы.

Исследование показывает, что смешанные документы до сих пор рассматриваются как отдельная категория задач. Универсальный OCR далеко не всегда обеспечивает приемлемое качество в подобных сценариях.

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

По сути система сначала определяет тип содержимого, а затем направляет его в соответствующий модуль обработки.

Этап 6. Нормализация и очистка данных

После извлечения текста и структуры документ ещё редко готов к использованию.

Необходимо:

• удалить дубликаты;

• исправить ошибки структуры;

• привести данные к единому формату;

• объединить информацию между страницами;

• преобразовать документ в машинно-обрабатываемую модель.

На этом этапе всё чаще используются LLM.

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

Поэтому в production-системах обычно ищут баланс между качеством и вычислительными затратами.

Этап 7. Экспорт в с�руктурированные данные

Конечная цель большинства пайплайнов — не получение текста.

Бизнесу обычно нужны структурированные данные.

Поэтому финальным этапом становится преобразование результата в форматы, пригодные для дальнейшей обработки:

• JSON;

• Markdown;

• таблицы;

• записи баз данных;

• объекты для RAG-систем.

Именно на этом уровне работают многие современные решения.

Marker, например, ориентирован на преобразование PDF в структурированные представления вроде Markdown и JSON. Docling часто используется в системах извлечения данных и RAG-пайплайнах.

Это отражает изменение самого подхода к обработке документов: задача заключается не в чтении PDF, а в преобразовании его в данные.

Где находятся инструменты в этой архитектуре

Если посмотреть на популярные решения через призму пайплайна, становится видно, что они закрывают разные уровни обработки.

Surya чаще выступает как OCR и layout-компонент. PaddleOCR обеспечивает OCR и поддержку структурированных документов. Marker работает как система преобразования PDF в структурированные форматы и использует OCR как часть общего процесса. Docling применяется в пайплайнах извлечения данных и подготовки информации для последующей обработки.

Коммерческие платформы вроде Google Document AI, Azure Document Intelligence и Amazon Textract объединяют несколько этапов внутри одного сервиса, предоставляя готовую инфраструктуру для работы с документами.

Вывод

Современный пайплайн обработки PDF состоит не из одного OCR-модуля и не из одной мультимодальной модели.

Он представляет собой последовательность специализированных этапов:

• анализ структуры документа;

• OCR;

• восстановление порядка чтения;

• извлечение таблиц;

• обработка рукописных элементов;

• нормализация данных;

• экспорт в структурированный формат.

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