We introduce OvisOCR2, a 0.8B document parsing model. OvisOCR2 is designed as an end-to-end parser: given a document page image, it generates a Markdown representation in natural reading order, covering text, formulas, tables, and visual regions. We build a data engine that combines filtered real-document annotations with synthetic pages whose rendered images and Markdown targets are derived from the same HTML source. The training recipe includes supervised fine-tuning, reinforcement learning on a 4B branch with a multi-component reward design, on-policy distillation into the 0.8B model, and model fusion. On OmniDocBench v1.6, OvisOCR2 achieves a state-of-the-art overall score of 96.58, placing an end-to-end model at the top of this leaderboard previously dominated by pipeline methods and highlighting the potential of end-to-end document parsing. On PureDocBench, OvisOCR2 also achieves the highest Avg3 score of 75.06. Beyond these two public benchmarks, we evaluate OvisOCR2 on an in-house benchmark designed to cover a broader set of long-tail and challenging scenarios. OvisOCR2 obtains the best overall performance among the compared methods, providing further evidence of its generalization and robustness. OvisOCR2 is available at https://huggingface.co/ATH-MaaS/OvisOCR2.
Alex: Welcome to another episode of ResearchPod. Today, we're looking at a study on OvisOCR2 — a compact model designed to turn document images into structured, readable digital text.
Sam: So the central question here is: can we replace these complicated, multi-stage systems for reading documents with one efficient model that does it all?
Alex: That's exactly it. Current systems break the task into separate steps — first analysing the layout, then recognising the text, then stitching everything together. Each handoff between steps is a chance for errors to creep in and pile up.
Sam: And OvisOCR2 aims to do all of that in a single pass. Why has that been so difficult until now?
Alex: It comes down to training data quality. Most models learn from messy, real-world scans that are already full of errors. If you're learning from flawed examples, it's very hard to develop a reliable sense of what a correct document should look like. It's a bit like trying to learn to spell by reading a book that was already full of typos.
Sam: So the garbage-in, garbage-out problem. How does this research get around that?
Alex: They built what they call a "data engine." Instead of scanning a physical page and then trying to label it, they start from HTML — the same code used to build web pages. That HTML is used to generate both the visual image of a document and the correctly formatted text at the same time. Because both come from the same source, they're guaranteed to match perfectly.
Sam: So they're creating their own practice documents from scratch, where the answer key is built in from the start.
Alex: Exactly. It eliminates the labelling errors that occur when you try to annotate real-world documents using older, less reliable tools. The training data is clean by construction.
Sam: That's a meaningful shift. But they can't train entirely on synthetic pages — real documents are messier. How do they handle real-world data?
Alex: They use a two-step cleaning process. First, specialised software extracts the raw content from real documents. Then strict rules are applied to fix problems — things like broken table structures or maths formulas in inconsistent formats. If a piece of data is too corrupted to salvage, it gets discarded entirely. And they don't just rely on automated filtering — human reviewers also spot-check batches, comparing the converted text against the source images to verify that reading order and layout are correct. If a batch has too many errors, the whole batch gets cut.
Sam: So they're prioritising quality over volume. A smaller, cleaner dataset over a massive, noisy one.
Alex: And that's precisely the point. A smaller model trained on carefully vetted data can outperform a larger model trained on a much bigger but noisier dataset. The bottleneck wasn't model size — it was data quality.
Sam: So once they have this clean data, how do they actually train the model to handle complex structures like tables or mathematical formulas?
Alex: They use a two-stage training process — think of it like learning a skill in school. In the first stage, the model does supervised practice. It studies worked examples and learns the basic patterns: what a well-formed table looks like, how a formula should be structured. In the second stage, it moves to something closer to trial and error, where it gets feedback on whether its answers are structurally correct.
Sam: But how do you give feedback on something as complex as a document layout automatically? That seems hard to judge without a human in the loop.
Alex: That's the clever part. They use programmatic checks — essentially, objective rules the structure has to satisfy. If a table the model produces has the wrong number of rows, or a formula it generates fails to render properly, the system flags it as wrong. It doesn't need a human to spot the mistake — the structure either holds together or it doesn't. The model compares several of its own attempts and learns to prefer the ones that pass those structural tests.
Sam: So it's learning to self-correct by comparing its own drafts against objective rules.
Alex: Over time, the model learns to avoid common failure modes — things like skipping lines of text or repeating the same phrase twice. The feedback loop is automatic, consistent, and doesn't require expensive human annotation at scale.
Sam: So the real insight isn't just the architecture of the model itself — it's the entire pipeline. Clean synthetic data, strict real-world filtering, and structured feedback during training.
Alex: That's the core argument of the paper. When you treat a document as a structured object with rules — rather than just an image to be described — you can build much more reliable systems, even with a relatively compact model.
Sam: How does it actually perform when tested against older systems?
Alex: The paper reports competitive results on standard document-parsing benchmarks, outperforming multi-stage pipeline systems on structured tasks like tables and formulas. The notable finding is that it achieves this with far fewer parameters — meaning less computing power — than many of the systems it's compared against.
Sam: Though I imagine it's not without limits. A compact, specialised model probably has blind spots.
Alex: The authors are candid about that. On heavily degraded physical scans — think old, faded invoices or crumpled archive pages — the model shows reduced robustness compared to much larger, general-purpose vision models. It's a trade-off: efficiency and precision on structured documents, versus the sheer visual resilience of a system trained on vastly more varied data.
Sam: So if you're digitising a clean PDF, this is a strong tool. If you're working through a box of battered archive documents, you might still need something bigger.
Alex: That's a fair characterisation. The authors point to two clear directions for future work: improving performance on low-quality, degraded images, and strengthening the model's ability to handle handwriting.
Sam: Is there any discussion of the model catching and fixing its own mistakes in real time?
Alex: That's flagged as a compelling direction. The idea would be for the model to not just parse a document, but to actively check its own output against the source image during generation — catching errors before they appear in the final result. It would shift the system from a passive reader to something more like a self-correcting editor.
Sam: Right now it reads the document once and commits. A future version might read, check, and revise.
Alex: Which would represent a meaningful step toward systems that are aware of their own uncertainty — not just producing an answer, but evaluating whether that answer holds up.
Sam: It's a good illustration of how careful engineering and data discipline can go a long way before you ever need to scale up the model itself.
Alex: That's a fitting note to end on. Thanks for listening to ResearchPod.