Multimodal Applications › Document Understanding

Michael BrenndoerferJanuary 5, 20269 min read
Language AI HandbookAll chapters
Part 50 of 67Multimodal Models
Chapter 392Multimodal Applications › Document Understanding
Reading section 2 of 10 · Document Understanding · 9 minSection 2 of 10 · 9 min

Book contents

Section 2 of 10 · 9 min read

Multimodal Applications › Document UnderstandingOne section · Sections in this chapter2 / 10 ↓
Reading tools Definitions & inline links

Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.

Article links

Make inline references clickable

Documents present a deceptively difficult multimodal challenge. A PDF or scanned page looks like an image, but understanding it requires integrating at least three types of information: visual layout (where things are on the page), textual content (what the words say), and structural semantics (how the layout signals meaning). A table header is not merely text in a different font. It defines the schema for the data below it. A figure caption is not merely nearby text. It is semantically linked to the image it describes. A section heading signals a topical boundary that affects how all subsequent text should be interpreted.

This document-as-multimodal-object insight distinguishes modern document AI from earlier text extraction pipelines. Traditional approaches treated a document purely as a container for text: use OCR to get the characters out, then feed them to a language model as a flat string. That approach works adequately when the semantic content resides entirely in the words themselves. But in the kinds of documents that matter most in business and legal contexts, layout is not decoration. It is meaning. The difference between "Gross Income" appearing as a form field label versus as a column header versus as a running header determines how the associated number should be interpreted, and that difference is encoded entirely in spatial position and typographic treatment.

Layout-Aware Representation

The basic insight behind layout-aware document models is that the bounding box of a text token is as semantically informative as the text itself. LayoutLM, introduced by Xu et al. at Microsoft Research in 2020, was the first model to systematically exploit this insight at scale. It extends BERT with two additional embedding types: a 2D position embedding that encodes the (x1,y1,x2,y2)(x_1, y_1, x_2, y_2) bounding box coordinates of each token, and an image embedding extracted from the document region corresponding to each token.

The 2D position embedding for a token at bounding box (x1,y1,x2,y2)(x_1, y_1, x_2, y_2) is computed as:

pos_emb(t)=Embx1(x1)+Emby1(y1)+Embx2(x2)+Emby2(y2)+Embw(x2−x1)+Embh(y2−y1)\text{pos\_emb}(t) = \text{Emb}_{x_1}(x_1) + \text{Emb}_{y_1}(y_1) + \text{Emb}_{x_2}(x_2) + \text{Emb}_{y_2}(y_2) + \text{Emb}_{w}(x_2 - x_1) + \text{Emb}_{h}(y_2 - y_1)

where:

  • Embx1,Emby1,Embx2,Emby2\text{Emb}_{x_1}, \text{Emb}_{y_1}, \text{Emb}_{x_2}, \text{Emb}_{y_2}: learned embedding tables for the four bounding box coordinates, each quantized to a fixed range of 0 to 1000 to match a normalized page coordinate system
  • Embw,Embh\text{Emb}_{w}, \text{Emb}_{h}: learned embedding tables for token width and height, which encode information about the visual size of the region

This embedding design has a pleasing property: two tokens with identical text content but different page positions will have different representations, letting the model to distinguish "Total" appearing as a row header from "Total" appearing as a column footer. The model learns from pre-training data that "Total" in the bottom-right of a document tends to co-occur with numerical summaries, while "Total" in a column header tends to co-occur with column-specific computations. The spatial signal bootstraps the semantic signal.

The coordinate quantization step deserves attention. Real document bounding boxes come in arbitrary pixel coordinates that depend on the document's resolution and physical size. By normalizing all coordinates to a fixed 0-1000 range (regardless of whether the original PDF is rendered at 72 dpi or 300 dpi), the model gains resolution invariance: the same document scanned at two different resolutions will produce the same normalized tokens. The 1000-unit range is fine enough to stand for spatial distinctions that matter (a label at x=30x=30 versus a value at x=180x=180) without requiring a prohibitively large embedding table.

LayoutLMv2 extended the original design by incorporating patch-level visual features from a convolutional neural network directly into the transformer's attention mechanism. Rather than treating text and image as separate streams that are concatenated at the beginning, LayoutLMv2 allows text tokens to attend to image patches at every transformer layer, letting richer cross-modal fusion. This matters for cases where the visual appearance of a field (font weight, background shading, border style) disambiguates its semantic role in ways that text alone cannot.

LayoutLMv3, the current state of the art in the series, went further by treating masked image patches and masked text tokens symmetrically during pre-training. Instead of separate objectives for text and vision, LayoutLMv3 uses a single masked multimodal modeling objective that randomly masks both text tokens and image patches and asks the model to reconstruct them. This forces the model to develop representations that integrate both modalities rather than solving the text and image tasks with separate pathways.

Document Question Answering

Document question answering (DocQA) is the task of answering natural language questions about a document image. A user uploads a scanned invoice and asks "What is the total amount due?" The model must locate the relevant region of the document, parse the number, and return it as a structured answer.

The challenge is more subtle than it first appears. The document may be a scanned photograph rather than a digital PDF, introducing OCR errors and skewed text. It may have multiple pages with cross-page references (a summary that reads "see Schedule A on page 7"). The answer may be in a table cell whose meaning depends on headers that appear several rows above, requiring the model to understand column and row scope. The question may require arithmetic ("What is the sum of the line items?") rather than simple extraction, adding a reasoning layer on top of the understanding layer.

DocQA Task Formulation

Given a document image II and a question qq, the model must produce an answer aa that may be:

  • Extractive: a span of text copied directly from the document
  • Abstractive: a generated string not literally present in the document
  • Structured: a number, date, or entity requiring parsing

Most benchmarks (DocVQA, InfographicVQA) use extractive formulations evaluated with character-level F1 or exact match metrics.

Modern DocQA systems typically combine OCR (to extract token positions and text), a layout-aware encoder (to stand for the combined text and layout and image), and a generation or span-prediction decoder. For extractive tasks, the decoder predicts start and end positions within the token sequence. For abstractive tasks, the decoder generates free text conditioned on the encoded document representation.

The DocVQA benchmark, which tests question answering on a diverse collection of business documents including forms and invoices as well as tables, has seen large progress since 2020. Early layout-aware models achieved around 70% character-level F1 on DocVQA. Current state-of-the-art systems exceed 95%, which is approaching human annotator agreement on this benchmark. However, this progress should be interpreted carefully: DocVQA favors extractive questions with unambiguous answers, and performance on more open-ended document tasks remains substantially lower.

Table Understanding

Tables are ubiquitous in documents and stand for one of the hardest subproblems in document understanding. A table has structure at multiple levels: the cell level (a single value), the row level (a record), the column level (an attribute), and the table level (a relation between entities). Understanding a cell requires knowing what its column header says, what its row header says, and how those headers were merged or spanned across adjacent cells.

Consider a financial table where "Q1", "Q2", "Q3", "Q4" are column headers and "Revenue", "Operating Income", "Net Income" are row headers. The cell where the Q3 column meets the Operating Income row has meaning only in the context of both headers simultaneously. A model that reads this table as a flat token sequence, ignoring the two-dimensional grid structure, cannot reliably extract "operating income for Q3" because the text "43.2" by itself is meaningless.

Table detection models first locate the bounding box of the table within the document image using object detection approaches. Table structure recognition models then parse the internal grid, identifying rows and columns as well as spanning cells. This is harder than it appears because real-world tables use visual cues such as borders and shading alongside whitespace to signal structure, and these visual conventions vary widely across document types, time periods, and publishers. A table in a government form from 1985 uses visual conventions that differ systematically from a table in a modern SaaS dashboard export.

Once structure is recognized, table question answering requires compositional reasoning. Questions like "Which product had the highest revenue in Q3?" require identifying the Revenue column, scanning its Q3 values, finding the maximum, and looking up the corresponding product name in another column. This kind of multi-step compositional reasoning extends beyond what a language model trained on text alone handles well. The precise spatial grounding that layout-aware encoders give is necessary but not sufficient: the model also needs the reasoning capability to chain together the column lookup, the comparison, and the row retrieval in the correct order. This is one reason hybrid symbolic-neural approaches that combine learned neural representations with structured table operations remain active research.

Information Extraction from Forms

Forms are a specialized but practically important document type. A structured form is designed around a specific information schema: a tax form has fields for income and deductions plus credits; a medical intake form covers symptoms and medications plus allergies; an employment application covers work history and education plus references.

Extracting information from forms at scale requires understanding the relationship between field labels and field values, handling handwritten and typed content mixed on the same form, and dealing with forms that deviate from their template (crossed-out values, corrections, attachments). Models trained on form understanding, such as the FUNSD (Form Understanding in Noisy Scanned Documents) benchmark, learn to classify tokens into question and answer categories alongside header and other categories, then link questions to their corresponding answers.

The practical value of form understanding is enormous. Insurance companies process millions of claims forms annually. Healthcare systems process patient intake and consent forms. Government agencies process tax returns and benefit applications. Even modest improvements in automated understanding accuracy translate to significant labor savings and processing speed increases in these contexts.