PaddleOCR-VL-1.6: Expanding the Frontier of Document Parsing with Under-Optimized Region Refinement and Progressive Post-Training

Modern document parsing—converting unstructured PDFs and images into machine-readable Markdown or JSON—is the bottleneck for high-fidelity RAG (Retrieval-Augmented Generation) systems. Large vision-language models (VLMs) can handle this. However, they are often too heavy for efficient, large-scale ingestion. Recent work focuses on compact, 0.9B-parameter models. These offer high throughput. But these small models eventually hit a wall. Generic data scaling no longer yields returns.

Researchers found that instead of just making models bigger, they can identify specific "weak spots." They find where the AI makes mistakes. By using a system to find these errors, they fix the labels. They add targeted training data. This makes a tiny model perform as well as massive architectures. This paper introduces PaddleOCR-VL-1.6. It achieves this through a surgical approach to data engineering.

The Problem

In the high-performance regime of document parsing, errors are rarely uniform noise. As models like the predecessor PaddleOCR-VL-1.5 approach saturation, they fail in predictable, localized "under-optimized regions." These are pockets where the model is unstable. They are areas where training data is too sparse to represent a pattern. Or, the supervision signals (the ground-truth labels) are simply wrong.

Standard practice is to throw more data at the problem. This is called uniform scaling. However, the authors note that blindly expanding the corpus is wasteful. It spends compute on regions where the model is already reliable. This leads to diminishing returns. Many systems also suffer from "unreliable supervision." This happens when models learn incorrect patterns from flawed training labels. As shown in, the challenge is moving from uniform scaling to a targeted, model-oriented diagnostic approach.

How It Works

The core innovation is an Under-Optimized Region (UOR) driven data engine. It feeds into a progressive three-stage post-training recipe. Instead of one massive training run, the authors use a staged pipeline: Continued Pre-Training (CPT), Supervised Fine-Tuning (SFT), and Reinforcement Learning (RL).

The data engine operates through three diagnostic lenses: 1. Boundary-Fragile Mining: The engine identifies samples where predictions fluctuate between late-stage training checkpoints. It also looks for instability under minor visual distortions, like JPEG compression. This detects areas lacking a stable decision boundary. 2. Coverage-Sparse Mining: Using a density-oriented clustering algorithm (Algorithm 1), the engine finds "outlier clusters" in the feature space. These represent long-tail patterns like ancient manuscripts or complex industrial tables. 3. Unreliable-Supervision Mining: The engine uses a "multi-expert consensus" approach. It compares existing labels against three independent expert models: Qianfan-OCR, GLM-OCR, and MinerU2.5-Pro. If experts disagree with the original label, the sample is flagged for correction.

For the hardest cases, the authors use a Render-Guided Judge-and-Refine strategy (Algorithm 2). Comparing raw LaTeX (a math typesetting language) or HTML to an image is difficult for a model. The system renders the candidate text back into an image. This turns a structural comparison into a visual matching task. A high-capacity model (ERNIE 5.0) then "sees" exactly where a table cell or formula is misaligned.

The training follows the progression in .

CPT expands distributional coverage. SFT sharpens behavior on hard cases. Finally, a specialized GRPO (Group Relative Policy Optimization) stage uses a "high-potential" selection strategy. This ensures the RL process does not degrade the compact 0.3B language component.

Numbers

Targeted data curation beats raw parameter count. The authors report that PaddleOCR-VL-1.6 achieves a state-of-the-art score of 96.33% on OmniDocBench v1.6. This is a significant jump from the 94.93% achieved by its predecessor.

Crucially, this 0.9B parameter model outperforms much larger general-purpose VLMs. On the Real5-OmniDocBench—a benchmark simulating real-world conditions like skewed or poorly lit photos—it scores 93.19%. This outperforms the 235B-parameter Qwen3-VL-235B. In specialized tasks, the delta is even sharper. For seal recognition, the 0.9B model achieved a Normalized Edit Distance (NED) of 0.119. This is much better than the 0.382 scored by the 235B Qwen3-VL. Note that for NED, a lower score means higher accuracy.

The ablation study in [Table 8] clarifies the value of the staged approach. The largest gains in the overall score and structural table accuracy (Table-TEDS) come from the CPT and SFT stages. The RL stage provides the final "polish." It specifically boosts the Formula-CDM score (a metric for mathematical formula accuracy) from 97.37% to 97.49%.

What's Missing

While the performance metrics are impressive, there are gaps for a production engineer: * Computational Overhead of the Data Engine: The paper describes a sophisticated, multi-stage labeling pipeline. It involves multiple expert models and iterative rendering. The authors do not report the total compute cost or time required to generate this dataset. The "data tax" might be high compared to standard SFT runs. * Dependency on Expert Quality: The engine relies on the assumption that "expert" models are superior to the target model. If your specific domain is a blind spot for all these experts, the consensus mechanism might reinforce shared errors. * Hardware Footprint Details: The paper discusses model scale and parameter counts. However, it does not provide detailed inference latency or throughput metrics on specific hardware like A100 or H100 GPUs.

Should You Prototype This

Yes, if you are building a high-volume document ingestion pipeline.

The takeaway is that targeted data engineering is the path to squeezing SOTA (State-Of-The-Art) performance out of small footprints. If you are hitting a performance ceiling with a 0.9B or 1B parameter model, these techniques are actionable. Do not just add more random web-scraped data. Find where your model is jittery. Use a larger model to "render and verify" the corrections.

Code and models are reportedly available at the canonical links in the paper: GitHub and HuggingFace. You can likely prototype the data engine logic before committing to a full training run.

Figures from the paper