Что такое LayoutLMv3 и зачем он для document understanding?

Краткий тезис

LayoutLMv3 — это мультимодальный трансформер, который одновременно обрабатывает текст, пространственную разметку (bounding box) и визуальное изображение документа. Он обучен с помощью задач маскирования текста и изображения, что позволяет ему глубоко понимать структуру документов. Для document understanding LayoutLMv3 незаменим при извлечении полей из счетов, распознавании таблиц и классификации документов, а в контексте RAG он превращает неструктурированные PDF в структурированные данные, пригодные для точного поиска.


1. Термин: Document Understanding (DU)

Document Understanding — это область NLP/CV, которая занимается автоматическим извлечением смысла из отсканированных или цифровых документов (PDF, изображения). В отличие от простого OCR, DU требует понимания логической структуры: где заголовок, где таблица, какое поле относится к дате, а какое — к сумме.

Зачем это нужно

  • Автоматизация обработки счетов, накладных, контрактов.
  • Извлечение ключевых полей (номер, дата, итоговая сумма).
  • Классификация документов по типу.
  • Распознавание таблиц и форм.

До LayoutLMv3 для DU использовались отдельные модели: OCR (Tesseract), парсеры разметки (pdfplumber) и NLP-модели (BERT). LayoutLMv3 объединил все три модальности в одной архитектуре.


2. Проблема: почему DU сложна

Документы бывают:

  • Сканированные — только изображение, текст нужно распознавать.
  • Цифровые (PDF) — текст есть, но разметка может быть потеряна.
  • Смешанные — таблицы, изображения, подписи.

Основные сложности:

  • Вариативность макетов: каждый документ может выглядеть по-своему.
  • Зашумлённость: пятна, перекосы, низкое разрешение.
  • Связь текста и позиции: слово «Итого» может быть внизу страницы, а сумма — справа от него.

Традиционные подходы (OCR + BERT) не учитывают пространственные отношения между токенами и визуальный контекст (цвет фона, линии таблицы). LayoutLMv3 решает эту проблему, добавляя layout embedding и image embedding.


3. Архитектура LayoutLMv3

LayoutLMv3 — это encoder-only transformer, основанный на RoBERTa. Он принимает три модальности:

МодальностьПредставлениеОписание
ТекстТокены + позиционные эмбеддинги (как в BERT)Каждый токен документа (после OCR или извлечения из PDF)
LayoutКоординаты bounding box (x0, y0, x1, y1)Нормализованные координаты каждого токена на странице
ImageПатчи изображения через ViT (Vision Transformer)Всё изображение страницы разбивается на патчи 16×16

Как объединяются модальности

  • Текстовые токены и визуальные патчи проецируются в единое скрытое пространство.
  • Для каждого текстового токена к его эмбеддингу добавляется layout embedding (линейная проекция координат).
  • Визуальные патчи получают свои Encoding|позиционные эмбеддинги (2D-координаты патча).
  • Все токены (текстовые + визуальные) подаются в один трансформер с self-attention — так модель учится связывать, например, слово «Дата» с областью изображения, где стоит число.

Ключевое отличие от LayoutLMv2: в v3 нет отдельного визуального энкодера (ResNet), вместо него используется лёгкий ViT, что ускоряет инференс и упрощает обучение.


4. Предобучение LayoutLMv3

Модель обучается на миллионах документов (IIT-CDIP, PubLayNet, собственные наборы) с тремя задачами:

ЗадачаОписаниеЦель
MLM (Masked Language Modeling)Маскируем 15% текстовых токенов, модель предсказывает их по контексту + layout + imageПонимание текста в контексте документа
MIM (Masked Image Modeling)Маскируем случайные патчи изображения, модель восстанавливает их пикселиПонимание визуального содержимого (линии, фон)
WPA (Word-Patch Alignment)Учим модель предсказывать, принадлежит ли текстовый токен данному визуальному патчу (бинарная классификация)Выравнивание текста и изображения

Благодаря WPA модель учится, что слово «Сумма» обычно находится рядом с областью, где написана цифра.


5. Fine-tuning под задачи DU

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

5.1 Извлечение полей (Entity Extraction)

  • Вход: изображение документа + координаты всех токенов.
  • Выход: для каждого токена — метка (B-дата, I-сумма, O-не поле).
  • Пример: извлечь номер счёта, дату, итог.

5.2 Классификация документов

  • Вход: документ целиком.
  • Выход: класс (счёт, договор, накладная).
  • Используется [CLS]-токен.

5.3 Понимание таблиц

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

Пример кода (HuggingFace Transformers):

from transformers import LayoutLMv3ForTokenClassification, LayoutLMv3Processor

processor = LayoutLMv3Processor.from_pretrained("microsoft/layoutlmv3-base")
model = LayoutLMv3ForTokenClassification.from_pretrained("microsoft/layoutlmv3-base", num_labels=num_labels)

# Подготовка: изображение, слова, bounding boxes
encoding = processor(image, words, boxes=boxes, return_tensors="pt")
outputs = model(**encoding)

6. Сравнение с другими моделями

МодельМодальностиПредобучениеРазмерИнференсКогда выбирать
LayoutLMv1текст + layoutMLM + layout-задачи~340Mсреднийlegacy, если нет GPU
LayoutLMv2текст + layout + image (ResNet)MLM + MIM + ITM~400Mмедленныйкогда важна точность, GPU есть
LayoutLMv3текст + layout + image (ViT)MLM + MIM + WPA~340Mбыстрыйсовременный стандарт
Donutimage (трансформер encoder-decoder)авторегрессия~200Mбыстрыйкогда нет OCR, нужен end-to-end
Table Transformerimage (DETR-like)детекция таблиц~100Mбыстрыйтолько для таблиц

Когда LayoutLMv3 лучше

  • Есть доступ к OCR (или текст из PDF).
  • Нужно извлекать поля с точностью >95%.
  • Документы сложные (счёт с таблицей и подписью).

Когда лучше Donut

  • Нет OCR (только изображение).
  • Документы простые (квитанции).

7. Применение LayoutLMv3 в RAG

В Agentic RAG агент часто работает с документами разного формата. LayoutLMv3 позволяет:

  1. Извлекать структурированные поля из PDF (например, номер заказа, дату) и индексировать их как метаданные.
  2. Преобразовывать таблицы в текст с сохранением структуры (например, в Markdown).
  3. Классифицировать документы перед отправкой в разные индексы (счета → векторная БД счетов, контракты → отдельный индекс).

Пример пайплайна

  • Агент получает PDF.
  • LayoutLMv3 извлекает поля: {"invoice_no": "INV-123", "date": "2024-01-15", "total": 1500.00}.
  • Эти поля сохраняются как метаданные в чанке.
  • При поиске агент может фильтровать по дате или номеру.

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


8. Ограничения и альтернативы

  • Зависимость от OCR: если текст не распознан, модель не сможет его обработать. Альтернатива — Donut (работает напрямую с изображением).
  • Размер модели: ~340M параметров, требует GPU для инференса. Можно использовать LayoutLMv3-base или дистиллированные версии.
  • Только одна страница: для многостраничных документов нужна дополнительная логика.
  • Англоязычные документы: предобучена в основном на английском. Для русского языка требуется дообучение (fine-tuning) на русскоязычных документах.

Альтернативы


Пет-проект для закрепления

Задача: Разработать скрипт, который извлекает номер счёта и дату из PDF-счетов с помощью LayoutLMv3.

Инструменты:

Шаги:

  1. Загрузить предобученную модель microsoft/layoutlmv3-base.
  2. Для каждого PDF:
    • Извлечь слова и bounding boxes через pdfplumber.
    • Преобразовать изображение страницы в RGB.
    • Подать в processor, получить тензоры.
    • Получить предсказания модели.
    • Извлечь токены с метками B-invoice_no, B-date.
  3. Оценить точность (accuracy) на тестовой выборке.

Ожидаемый результат: Скрипт, который для 90% счетов правильно извлекает номер и дату. Можно добавить веб-интерфейс (Streamlit) для загрузки PDF.


Связь с другими вопросами

ВопросТема
550Document Understanding: обзор подходов
551LayoutLMv1: архитектура и отличия
552LayoutLMv2: роль визуального энкодера
554Donut: end-to-end DU без OCR
555Table Transformer: детекция таблиц
560Agentic RAG: как агент использует DU

Навигация