# olmOCR 2: Unit Test Rewards for Document OCR > Analysis of olmOCR 2, a 7B VLM trained with reinforcement learning using binary unit-test rewards for document OCR - Authors: Hunter Heidenreich - Published: 2025-10-15 - Updated: 2026-03-04 - Paper: olmOCR 2 Paper - Code: olmOCR Code - Demo: olmOCR Demo - Model: olmOCR-2-7B-1025 Model - Source: Bevaya Labs, --- ## TL;DR olmOCR 2 is an OCR system built around a 7B VLM (Qwen2.5-VL-7B-Instruct base) trained with reinforcement learning using verifiable rewards (RLVR), where rewards come from a suite of binary unit tests. The authors scale unit-test creation by generating synthetic document pages with ground-truth HTML and extracted test cases, then apply GRPO-based RL to improve performance. They report an overall olmOCR-Bench score of 82.4 $\\pm$ 1.1, a +14.2 point improvement over the initial olmOCR release, with large gains in math/table/multi-column handling. * * * ## What kind of paper is this? Primarily **$\\Psi\_{\\text{Method}}$**, with substantial **$\\Psi\_{\\text{Resource}}$** and **$\\Psi\_{\\text{Evaluation}}$** components. - **Dominant: $\\Psi\_{\\text{Method}}$**: The center of gravity is the training recipe (synthetic unit-test generation + GRPO RLVR) and the inference/system changes driving benchmark gains. - **Secondary: $\\Psi\_{\\text{Resource}}$**: The authors explicitly emphasize releasing model/data/code under permissive open licenses. - **Secondary: $\\Psi\_{\\text{Evaluation}}$**: A core argument is why binary unit tests can be preferable to edit distance for OCR correctness, supported by Figures 1--2 (p.3). A rough superposition: 0.50 $\\Psi_{\\text{Method}}$ + 0.30 $\\Psi_{\\text{Resource}}$ + 0.20 $\\Psi\_{\\text{Evaluation}}$. ## What is the motivation? - **Need for clean, naturally ordered text from PDFs**: The target is digitized print documents (like PDFs) converted into "clean, naturally ordered plain text." - **Manual unit tests do not scale**: The original olmOCR-Bench unit tests were manually verified and "took hours of work" to create/check, which blocks RL scaling. - **Edit distance is a weak proxy for OCR correctness in key cases**: - Floating elements lead to "ties" (multiple equivalent linearizations) that unit tests can treat equivalently, but edit distance can reward/penalize arbitrarily (Figure 1, p.3). - Continuous scores can miss what matters: reading order vs caption placement; rendered correctness of equations vs LaTeX string similarity (Figure 2, p.3). - **Goal**: Build a scalable pipeline where OCR outputs can be automatically verified via unit tests, enabling RLVR training at scale. ## What is the novelty? The paper combines and operationalizes several ideas into a cohesive training loop: - **Binary unit tests as verifiable RL rewards**: Rewards are a "diverse set of binary unit tests" used for RLVR, rather than using only continuous text similarity. - **Synthetic pipeline to generate unit tests at scale**: They create synthetic documents with known ground-truth HTML source and extracted test cases, enabling programmatic unit-test creation. - **Iterative PDF-to-HTML generation via a general VLM** (Figure 3, p.4): They sample a real page and prompt a general VLM (`claude-sonnet-4-20250514`) to produce a highly similar HTML page; the rendered HTML image paired with raw HTML becomes supervision. - **GRPO-based RLVR on OCR**: They apply Group Relative Policy Optimization (GRPO) using unit tests as binary reward signals. - **System/inference engineering that matters for OCR**: Dynamic temperature scaling to avoid repetition loops, prompt-order standardization, YAML output format changes, and image resizing changes are described as meaningful contributors. > **Contrast to Infinity Parser**: The authors describe Infinity Parser as the closest related work; their stated key difference is **binary unit tests** as rewards vs Infinity Parser's reward based on edit distance/paragraph count/structural consistency, plus differences in how real content seeds HTML generation. ## What experiments were performed? - **Benchmarking on olmOCR-Bench (English)**: The benchmark measures unit-test types including: - Text presence/absence, natural reading order, table accuracy, math formula accuracy via KaTeX rendering, baseline robustness. - **Comparisons vs other OCR systems** (Table 1, p.2): They list multiple baselines (API-only, open-source, and VLM-based OCR systems), and report olmOCR 2 at **82.4 $\\pm$ 1.1**. The table caption notes their reproduction policy: results are reproduced in-house except those marked with `*`. - **Ablation-style incremental development breakdown** (Table 3, p.7): They show stepwise improvements from "olmOCR (first release)" to "Synth data, RLVR, souping" and the resulting overall score changes. - **SFT dataset refresh comparison** (Table 2, p.5): One-epoch finetuning on `olmOCR-mix-0225` vs `olmOCR-mix-1025` with per-slice benchmark scores and overall results. - **Metric motivation experiments** (Figures 1--2, p.3): - Figure 1: unit test vs edit distance for reading order errors with floating caption; unit tests treat valid placements as ties while edit distance penalizes some ordering choices more than others. - Figure 2: unit test vs edit distance for math parsing; rendering-based checks can pass outputs with worse LaTeX edit distance and fail outputs with better edit distance. ## What are the outcomes/limitations? **Outcomes reported:** - **Overall improvement**: +14.2 point improvement over the initial release when evaluated on the latest olmOCR-Bench, moving from 68.2 to 82.4. - **Where gains concentrate**: The largest improvements are in math formula conversion, table parsing, and multi-column layouts. - **Open artifacts**: Model/data/code released under permissive open licenses. Table 1 is structured to emphasize openness across model weights/training data/training code/inference code. **Limitations and open questions:** - **Comparisons are heterogeneous**: Table 1 includes systems with scores marked `*` (reported by authors, not reproduced by the olmOCR team) and some entries show "$\\pm$ ?" uncertainty, so "best overall" claims depend on which subset you view as comparable. - **Benchmark scope**: The benchmark is explicitly described as English-language; generalization beyond that is not established in this report. - **Unit-test coverage is a bottleneck**: Any unit-test regime is inherently limited to the properties it encodes (a general risk for test-suite-based rewards). The authors explicitly want to extend the synthetic pipeline to more complicated document types/unit tests. - **Reliance on frontier model tooling in the pipeline**: Synthetic generation uses `claude-sonnet-4-20250514`, and the refreshed SFT mix is processed using GPT-4.1; reproducing the pipeline end-to-end may require access to these systems. - **Binary vs continuous metrics**: The paper argues binary tests often align better with correctness; still, calibrated continuous scores for non-math targets remain open work. * * * ## Model ### Core model - **`olmOCR-2-7B-1025`**: A specialized 7B vision-language model trained with RLVR. - **Base family**: Starts from `Qwen2.5-VL-7B-Instruct` fine-tuned on `olmOCR-mix-1025`. The authors explicitly note switching from Qwen 2 VL to Qwen 2.5 VL for a slight benchmark gain. - **FP8 variant**: `olmOCR-2-7B-1025-FP8` also released. ### Output format and schema constraints - **Switched from JSON to YAML**: To reduce retries; the authors speculate YAML avoids quote-count bookkeeping and reduces repetition loops. - **Document metadata at top**: A reward term enforces that model outputs document metadata at the top (examples given: primary language, rotation correction factor). ### Inference engineering (Section 4) The authors highlight several system changes that materially affect end quality: - **Dynamic temperature scaling**: Start at 0.1 and increase stepwise (0.2, 0.3, ...) up to max 0.8 when EOS is not produced (to prevent repetition loops). - **Prompt ordering**: Fix mismatch between training and inference prompt order by always placing text first; authors report improved performance and note this enables prompt caching. - **Image resizing**: Increase from 1024 px to 1288 px on longest edge; authors describe this as a chosen balance between score and inference speed. - **Blank-page handling**: Fix data loader skipping blank pages that caused hallucinations; no benchmark impact reported. > **Contrast to DeepSeek-OCR**: DeepSeek quantifies a frontier of 97% OCR at ~10$\\times$ text$\\rightarrow$vision compression with a SAM$\\rightarrow$conv-16$\\times$$\\rightarrow$CLIP DeepEncoder (and token-economical multi-res modes), whereas olmOCR 2 largely keeps model size fixed and improves policy quality via unit-test rewards. * * * ## Data ### Supervised fine-tuning (SFT) data: `olmOCR-mix-1025` - **Size**: 267,962 pages from over 100,000 PDFs, including 9,828 pages from national archives. - **Delta vs previous mix** (`olmOCR-mix-0225`): Reprocessed using GPT-4.1 instead of GPT-4o; more consistent equation formatting using `\[ ... \]` and `\( ... \)`; tables in HTML format; basic alt text for images. ### Synthetic RL data: `olmOCR2-synthmix-1025` - **Size**: 2,186 PDF pages with 30,381 unit test cases. - **Sourcing strategy**: Sample real documents with "relevant, difficult-to-OCR material," including arXiv math-heavy papers for equation-focused tests. - **General VLM used for HTML generation**: `claude-sonnet-4-20250514`. - **Cost**: Approximately $0.12 per document page (for the synthetic pipeline). - **Hallucination robustness claim**: Pipeline is robust to Claude OCR errors because unit tests are generated from the HTML output alone. ### Unit-test families - Text presence/absence - Natural reading order - Table cell position - Formula rendering (DOM/KaTeX) - Baseline robustness (repeated n-grams, non-target language characters) * * * ## Algorithms / Training ### Pipeline overview The authors describe a two-part training recipe: (1) build a synthetic pipeline that renders documents into clean HTML and produces verifiable unit tests, then (2) apply GRPO to train using these binary reward signals. ### Synthetic PDF-to-HTML generation steps They break conversion into three steps (Figure 3, p.4): 1. **Layout analysis**: Prompt a general VLM to describe layout (columns, images/tables, headers/footers) to guide HTML generation. 2. **Content rendering**: Prompt again to "render this document as clean, semantic HTML" within original dimensions. 3. **Output refinement**: Render generated HTML to an image, then prompt the VLM to refine HTML to better match the original image. ### Unit test creation from HTML semantics - **Header/footer tags**: By requiring `
` and `