Извлечение данных из документов: практичный пайплайн для PDF, сканов, таблиц и форм
Извлечение данных из документов (document parsing) — это процесс, который превращает договоры, счета, накладные и анкеты в структурированные поля (JSON/таблицы/записи в БД). В большинстве задач достаточно правильно собрать пайплайн: определить тип документа, извлечь текст и разметку, достать нужные поля, провалидировать и отправить на ручную проверку только «сомнительные» места.
Если PDF «текстовый» (содержит слой текста), OCR обычно не нужен: быстрее и точнее сразу извлекать текст и координаты. Для сканов/фото OCR обязателен.
Оглавление
OCR и document parsing: в чём разница
OCR отвечает на вопрос «какие символы на изображении?».
Document parsing (document understanding) отвечает на вопрос «что именно написано и к каким полям это относится?», например: Номер счёта, Дата, Поставщик, Итого, а также строки табличной части (Наименование, Кол-во, Цена, НДС).
На практике это часто объединяют в IDP-подход: OCR + понимание структуры (layout) + извлечение + контроль качества + интеграции.
Какие документы сложнее всего парсить
Сложность чаще зависит не от расширения файла, а от вариативности и качества:
- Сканы/фото: перекос, тени, размытость, «съеденные» края → падает качество OCR и координат.
- Полуструктурированные формы от разных контрагентов: смысл одинаковый, вёрстка разная → правила ломаются.
- Таблицы: объединённые ячейки, переносы строк, таблицы «без линий», итоги внутри таблицы.
- Договоры/письма: много текста и контекста → ближе к NLP-задачам (сущности и условия), чем к шаблонам.
Частая ловушка: пытаться «парсить одним способом всё». Почти всегда нужна хотя бы базовая классификация документов и разные стратегии извлечения.
Эталонный пайплайн извлечения данных
- Приём и контроль входа: типы файлов, лимиты, разбиение на страницы, журналирование.
- Нормализация изображения (для сканов/фото): поворот, deskew, шумоподавление, контраст, проверка обрезанных полей.
- Классификация документа: счёт/акт/анкета/договор/прочее — чтобы выбрать схему полей и метод извлечения.
- Извлечение текста и разметки: текст + координаты (bbox), блоки, иногда линии/таблицы.
- Извлечение данных: поля «ключ-значение», сущности, табличные строки.
- Валидация и нормализация: типы данных, справочники, форматы дат/сумм, логические сверки.
- Human-in-the-loop: ручная проверка только полей с низкой уверенностью.
- Экспорт: JSON/API/БД/очереди, плюс хранение «как было распознано» для аудита и дообучения.
Подходы к извлечению: что выбрать
Сравнение подходов document parsing
| Подход | Когда подходит | Слабые места |
|---|---|---|
| Правила/регулярки | Стабильные формулировки и быстрый старт | Плохо переносится на разные шаблоны |
| Шаблоны по координатам | Один-несколько фиксированных бланков | Любая правка вёрстки требует перенастройки |
| ML-модели для форм/таблиц | Много поставщиков, вариативная вёрстка | Нужны данные для настройки и контроль дрейфа |
| LLM/мультимодальные модели | Договоры, «человеческий» текст, длинный хвост | Риск ошибок → обязательны жёсткие валидации |
| Гибрид | Почти любой продакшен-кейс | Нужно продумать оркестрацию и QC |
Самый устойчивый вариант в продакшене: извлечение моделью (или LLM) + строгие проверки правилами + ручная верификация только спорных полей.
Как повысить точность и стабильность
- Сначала улучшайте вход: скан 200–300 DPI, без агрессивного сжатия, без «кривого» кадрирования.
- Храните координаты источника (bbox) для каждого поля: это ускоряет разбор ошибок и ручную проверку.
- Разделяйте зоны: табличная часть отдельно от шапки/подвала — меньше ложных совпадений.
- Валидации важнее «ещё одной модели»:
- даты приводите к одному формату;
- суммы — к числам с валютой;
- проверяйте, что
Итого = сумма строк (+/- НДС/скидки)по вашей бизнес-логике.
- Порог уверенности делайте на уровне поля, а не документа: оператор проверяет только то, что действительно рискованно.
Метрики качества: как понять, что стало лучше
- Для OCR-текста: CER/WER (ошибки символов/слов).
- Для полей: precision/recall/F1 по каждому полю (номер, дата, ИНН, сумма и т.д.).
- Для таблиц: точность по ячейкам/строкам + бизнес-проверки (сверка итогов, количества, ставок).
Практичный ориентир: считать метрики после нормализации (например, дата стала YYYY-MM-DD), иначе вы измеряете форматирование, а не смысл.
Частые ошибки
- Нет чёткой схемы данных (какие поля нужны, типы, обязательность) — интеграции начинают «плыть».
- Не разделяют документы по классам и пытаются парсить всё одним методом.
- Не заводят «золотой набор» документов для регрессионного теста (после правок качество незаметно деградирует).
- Для таблиц не определяют правила: что считать строкой, как обрабатывать переносы, итоги и объединённые ячейки.
- Отсутствуют валидации и контроль уверенности — ошибки попадают в учётные системы.
FAQ
Можно ли обойтись без OCR?
Да, если PDF содержит текстовый слой. Тогда извлекают текст и координаты напрямую, что обычно быстрее и точнее.
Почему таблицы «едут» и разваливаются?
Потому что в PDF таблица часто не объект, а визуальная композиция текста и линий. Нужны раздельная обработка зоны таблицы, постобработка объединений/переносов и проверка итогов.
Что выбрать: правила, ML или LLM?
Если шаблон фиксированный — начните с координат/правил и валидаций. Если много поставщиков — добавляйте ML для форм и таблиц. Для договоров и свободного текста LLM может ускорить старт, но только вместе с жёсткими проверками и ручной верификацией рискованных полей.