Summary
What if every document a model gets wrong told you what to train on next? That's the loop behind OXR, a 1.3B model that ranks #1 on three document parsing benchmarks.
Start with what usually happens when a model misreads a document. Someone corrects that one result, ships it, and moves on. Next week a similar document arrives, and the model probably makes the same mistake. A better next version means picking out bad cases, working out what went wrong, preparing data, and checking that the data is usable, while new failures keep showing up every day.
We handed that pipeline to the system. OXR-1.0 uses recursive self-improvement (RSI) in post-training. Each round, the system finds the samples the model misreads or can't settle on in unlabeled documents, analyzes what went wrong, plans the next round of training, and generates targeted training data. To our knowledge, this is the first time RSI has been used for document parsing.
RSI is a training-time design. OXR does not learn from your documents while you use it. Most of the judging, attribution, planning, and data generation is done by a stronger general-purpose multimodal model (the General VLM in our diagrams). Disagreement across OXR's own repeated predictions also helps flag uncertain samples, and a separate model handles clustering. When we say "no manual work," we mean that the training data RSI generates needs no human annotation or correction. It does not mean the whole training process runs without people.
OXR-1.0 ranks #1 on OmniDocBench (97.18), olmOCR-Bench (87.84), and DocParsingBench (87.76). In speed tests on an RTX PRO 6000, it also ranks #1 among open-source document parsing models.
Why document parsing suits learning from errors
Document parsing has a property few other tasks share: every input has a correct answer. Characters, table rows, columns and merged cells, and formula symbols can all be checked item by item. Quality can be measured objectively, and most mistakes fall into a specific kind of problem.
That property has mostly been used for evaluation, not for learning. The catch is that the images and PDFs arriving from real use come with no human answers, so they can't serve as training data directly. OXR first has to find its weak spots in those documents, then build labeled new data around them. The three stages below do exactly that.
The RSI loop in three stages
The stages are Prediction & Classification, Attribution & Training Planning, and Data Generation. The Train line at the bottom, leading back to OXR, is the "recursive" part: data that passes validation in one round becomes training input for the next.
Stage 1: Find the misreads and the shaky samples
OXR first parses unlabeled documents. Then the General VLM looks at the original image, the prediction, and the judging criteria, and sorts each sample into one of three classes:
- Correct: judged right. It stops here for this round.
- Wrong: judged wrong. It goes on to analysis.
- Uncertain: can't be judged reliably, or the prediction is unstable. It also goes on to analysis.
Keeping Uncertain is deliberate. These documents have no human ground truth, and judging rules can't cover every case in advance. With only Correct and Wrong, the judge's hesitation gets hidden in a label that looks certain and travels all the way into the training data. In our experiments, adding the third class made the split between Correct and Wrong cleaner. That is a qualitative observation; we haven't measured it systematically.
An uncertain sample is one whose prediction is unstable and that sits near the edge of the training data distribution. There is a second way to find them: we branch off multiple rollouts from OXR and compare the predictions for the same sample. One correct answer doesn't mean the model has the sample down. If repeated runs differ clearly, the sample deserves a look. The General VLM checks whether a result is wrong, and the rollouts show whether OXR's answer is stable, so the two signals complement each other.
For samples where the rollouts disagree, we ask one more question: why is the prediction unstable? We apply small perturbations to the image, such as rescaling, blurring, compression, or a slight shift, without changing the content, and run the rollouts again. If the disagreement grows, the model is sensitive to visual changes that have nothing to do with content. The perturbation itself then becomes an important reason, and it carries into Stage 2.
Stage 2: Turn scattered errors into "what to add next"
A Wrong verdict says the result is incorrect. It doesn't say where, and the original document still has no reliable label. So the General VLM analyzes each sample's original image and prediction and writes down possible reasons. One sample can have several. For uncertain samples, it analyzes what makes the prediction unstable, without assuming the sample is wrong.
These natural-language reasons are diagnostic hypotheses, but the ones that keep recurring deserve attention. We encode the reason text with SigLIP 2 and cluster it, grouping similar reasons into reason clusters.
Here is an example built only to show the mechanism; the documents and strings in the figure are illustrative, not OXR measurements. A research report is judged Wrong, and one reason is that the capital M in "Model" was transcribed as lowercase. A technical manual is judged Uncertain because its predictions disagree on the capitalization of "Model." The two documents come from different domains, but both reasons land in the same cluster: case confusion. The next stage generates brand-new documents around that cluster to cover this kind of capitalization difficulty. That is Training Planning: turning scattered diagnoses into the problems the next round of training should cover.
Stage 3: Generate data that targets the weakness and still looks like a real document
Reason clusters give the generator a clear target, but counting samples hides two problems:
- Self-repetition. A thousand generated samples may share one set of layout habits and phrasing, like one person talking to themselves. The count goes up while the distribution stays narrow.
- Overemphasized difficulty. Without real-world style references, the generator may draw a structure too neat and too prominent just to make the point. A model can learn those exercises and still fail to recognize the same structure in natural documents.
So Stage 3 takes two kinds of input. The reason clusters say which difficulties to cover, and real samples supply layout and visual style. Each generation run draws a different sample from the real pool, so a cluster is never tied to one template. In the capitalization example, the difficulty shows up in different real layouts: "Model selection" in a research article, and "MODEL" and "model_id = 07" in a technical spec. A reason that came from perturbation goes in more directly. If the model is sensitive to slight rescaling or compression, describing the problem isn't enough, so the generated documents have to carry those changes again and again.
The General VLM writes code that draws, typesets, and renders documents, and a program runs it to produce the images and labels. The difficulty has to be a feature visible in the image, not just a line in the prompt. Then comes validation. Targeted generation tends to overdo the difficulty: cells made too small, formulas written with nonstandard symbols, the wrong delimiters where text and formulas mix. Output like that can render fine and still break the standard. Only data that passes rule-based validation and filtering goes into the next round of training.
How we know the next round improved
Data that passes filtering trains the next round of OXR. The updated model then faces real documents again, and its new predictions and classifications become the starting point of the next round. That is why RSI sits in post-training and runs repeatedly: one round's results change the next round's inputs.
We track the repair rate. We re-run the previous round's Wrong samples through the updated OXR, have the General VLM judge them again, and divide the number that turn Correct by the number originally labeled Wrong. This is the share of the same samples the VLM now judges correct. It is not accuracy on an independent test set, and nobody checked each case by hand. Overall model accuracy is what the three public benchmarks above report.
In theory RSI can iterate without limit, but iterating doesn't guarantee progress. Four things to watch when it keeps running:
- Find problems with real documents. The input for finding and attributing weaknesses has to be real documents, not synthetic ones, so the weaknesses it finds don't lean toward cases the generator created itself.
- Use enough samples per round. With too few documents, you only see scattered bad cases. With enough, reason clusters have more support and Training Planning has a firmer basis.
- Weigh quantity and diversity together. Cover different sources, time periods, document types, and layouts. A large set of near-identical documents keeps exposing the same problem.
- Build solid base capabilities first. RSI-generated samples are a small share of the overall training data, so they can't carry all the optimization. RSI strengthens specific weaknesses on top of a solid foundation.
What you can take from this
Looking back, the design relies on document parsing having correct answers. Because right and wrong can be judged automatically, the verdicts can be turned into directions for building data. Because exercises can be generated by a program, training data doesn't depend on human annotation. Because generation quality has executable standards, automated attempts can run at scale. Together with the training that follows, the three stages make up one RSI round.
The model's size follows from this too. With the data distribution better covered, the 1.3B OXR doesn't have to lean on parameter count for accuracy, and its small size plus a task-level architecture design gives it speed. We think it can get smaller still.
The approach may not stop at document parsing. Any task with a stable, automatically checkable success criterion could automate the same chain: find weaknesses, build supervision, validate data. Document parsing is the case we've gotten working.
Try OXR on your own documents, and tell us where it still reads them wrong.
-->
About OXR and SoMark
OXR is a 1.3B open-source document parsing model from the team behind SoMark. It ranks #1 on olmOCR-Bench, OmniDocBench, and DocParsingBench and delivers SOTA parsing speed. The model uses a recursive self-improvement (RSI) loop during post-training.
SoMark is a production-grade document parsing engine for agents, powered by an independent model. It supports more file formats, finer-grained recognition of document elements, and faster processing. It also offers extensive post-processing features, custom development, and model training services for different business needs.
If OXR saves you time, give it a ⭐ on GitHub: https://github.com/SoMarkAI/OXR
Top comments (0)