The Compiler in the Loop: How Tencent's DocEDR Uses Rendering to Check and Repair OCR

An OCR model processes a printed system of equations. In one of the paper's illustrated examples, a term that should contain $\nabla^2$ emerges in the model's LaTeX output with the operator carrying a subscript: \vec{\nabla}_{2}. The exponent has flattened into an index. The string remains recognizable as mathematical markup, but its rendered structure no longer matches the source.

Now consider another expression: $T \ge 0$. The model transcribes it as T \geq 0, while the reference uses T \ge 0. A literal string comparison finds a difference. Yet both expressions render identically. Treating that difference as a recognition error penalizes a mistake that does not exist.

This dual headache captures a problem in document parsing. On one side, OCR predictions can omit content, misrecognize symbols, or introduce unsupported structure. On the other, string-based evaluation can penalize valid outputs simply because the markup uses an alias or an equivalent representation.

A research team from WeChat Vision at Tencent proposes a way to address both problems. Their September 3, 2026 paper, OCR-EDR: Rendering-Aware Diagnosis and Repair for Closed-Loop OCR Improvement, defines a diagnosis-and-repair framework and introduces DocEDR, a model built on Qwen3.5-9B. Given a source crop, an editable OCR prediction, and its rendering, DocEDR assesses consistency, applies corrections when needed, and can request a fresh rendering to inspect the result.

The reported findings are striking. On their newly curated benchmark, OCRErrBench, DocEDR achieves 94.78% diagnostic accuracy, outperforming Qwen3.5-397B-A17B(FP8). In zero-shot formula diagnosis on DOCRcaseBench, it lifts Case-F1 by 30.99 percentage points over DOCR-Inspector-7B. Separately, it repairs 86.23% of OCRErrBench's erroneous inputs to visual agreement with their references. The contribution is a loop that connects error detection to executable edits and rendering-based reassessment.

The String Trap: Why Standard OCR Evaluation Penalizes Good Code

To understand why the team built DocEDR, consider what string-based OCR metrics measure. Edit distance counts differences between a prediction and a reference. It does not, by itself, determine whether two different strings preserve the same visible content and structure.

That distinction matters for mathematical markup. The paper gives examples such as:

• \to versus \rightarrow
• {\bf x} versus \textbf{x}
• T \ge 0 versus T \geq 0

These pairs use different source code to produce the same rendering. The paper also presents valid examples involving Greek-symbol representations, delimiter sizing, and benign typesetting differences. Such variations must be checked in context: different delimiter commands, for example, are not universally interchangeable.

The authors call valid, nonidentical representations rendering-equivalent positives. In the boundary-diagnosis subset reported in Table 3, a normalized edit distance threshold of 0.1 rejected 57.14% of rendering-equivalent text predictions. DOCR-Inspector-7B rejected 75.81% of the equivalent positives evaluated in that table. It retained its official single-image protocol; the comparison does not establish that it inspects only raw strings.

The opposite problem also appears. A small source-code change can alter an important visual relationship. Changing \nabla^2 to \nabla_2 requires only one character substitution, while moving a symbol from a superscript to a subscript. A low aggregate edit distance can therefore coexist with a genuine structural error.

The paper tests both sides of this boundary. Its reference-based formula criterion, CDM below 0.9, rejects only 2.94% of equivalent formulas in the selected subset, but misses all the evaluated local errors within its applicable scope. The text edit-distance criterion likewise misses the local errors within its scope. These are results for the selected cases and thresholds, not evidence that either metric is universally ineffective.

Text-only post-correction has a related limitation. It can use linguistic patterns to improve an OCR sequence, but it cannot directly inspect whether the revised output restores the source image's visible content. OCR-EDR adds that visual evidence to the correction process.

The Core Architecture: Turning Document Correction into a State Machine

DocEDR reframes OCR correction as an agentic state machine. Instead of treating the initial prediction as a fixed output, the model maintains an editable candidate and jointly evaluates three inputs:

1. Source Image ($I$): The visual crop from the original document, supplying external evidence.
2. Current OCR Prediction ($p$): The editable symbolic string, such as formula markup or text.
3. Rendered Image ($R(p)$): The visual result of rendering the current prediction.

The model uses both symbolic and visual information. The OCR sequence supports precise localization and editing, while its rendering exposes the visual consequences of that sequence. If an alternative command preserves the source's content and structure, the intended behavior is to accept the prediction and stop.

When the prediction is inconsistent with the source, the model can diagnose and repair it. The authors define five mutually exclusive atomic error categories:

• Invalid Output (Global): Empty, malformed, unparsable, or unrenderable output in the required representation.
• Global Mismatch (Global): Predictions inconsistent with the source as a whole, such as content from the wrong region.
• Completeness (Local): Dropped words, omitted terms, or redundant content.
• Content (Local): Incorrect individual characters or symbols, such as mistaking a Latin $k$ for a Greek $\kappa$.
• Structure (Local): Incorrect reading order, grouping, hierarchy, or spatial and markup relations, including flattened superscripts and broken fractions.

Each atomic error receives one category, although a prediction can contain multiple errors. Global failures use a global_rewrite operation when localized editing is inappropriate. Local repairs use insert, delete, or replace.

Crucially, DocEDR does not automatically rerender after every edit. Its policy-level action space contains inspect, diagnose_scope, localize, patch, global_patch, request_render, and stop. These actions control the process; they are distinct from the textual operations applied to the OCR sequence.

After an edit, the previous rendering is marked stale. The model can stop without another visual check or call request_render to inspect the updated candidate. Rendering failure has its own explicit state, separate from a stale image. The framework therefore records whether visual feedback is current, outdated, or unavailable because rendering failed.

Inside DocEDR: Training a 9B Parameter Model to Beat a Larger Baseline

DocEDR is initialized from Qwen3.5-9B. The authors train it through diagnostic supervised fine-tuning, a three-stage repair curriculum, and reinforcement learning. The stages progressively connect validity assessment to editing and control of the repair loop.

Phase 1: Verifier Supervised Fine-Tuning

The model first learns visual consistency verification. Given the source image, OCR text, and rendered image, it is trained for one epoch to predict validity and structured error information. For erroneous predictions, that information includes error classes, locations, and proposed corrections.

The diagnostic checkpoint then follows two paths. One copy is frozen to serve as the reward Verifier. The other continues training as the interactive repair policy. This preserves a stable diagnostic signal while the repair model learns new behaviors.

Phase 2: Curriculum Repair SFT

Next, the agent undergoes three sequential stages of supervised fine-tuning:

• Stage 1 (Single-turn repair): The model learns direct correction without rendering during the repair process.
• Stage 2 (Tool selection): The model learns to choose between requesting an updated rendering and stopping, rather than treating every correction as requiring a tool call.
• Stage 3 (Multi-turn visual recovery): The model receives real post-edit rendering feedback. It learns to recognize residual errors, recover from ineffective edits, and continue repairing when needed.

Stage 1 runs for one epoch; Stages 2 and 3 run for two epochs each. The benchmark remains isolated from these training stages at the source-document level.

Phase 3: Reinforcement Learning via GRPO

The final policy is optimized using Group Relative Policy Optimization (GRPO) across 400 updates. For each prompt, training samples a group of eight trajectories and scores them using a label-conditioned reward.

The reward separates valid inputs from erroneous ones:

• For valid inputs ($y_0 = \text{good}$): The model is rewarded for preserving the normalized initial prediction. Unnecessary changes, additional turns, and rendering calls incur penalties.
• For erroneous inputs ($y_0 = \text{bad}$): Terminal quality combines normalized edit similarity, exact reference agreement, the frozen Verifier's visual-consistency judgment, and output-format validity. A process term rewards recovery and penalizes regression between evaluated candidate states.

The optimization also discourages repeated edits, excessive rendering, and exhausting the interaction budget with an erroneous final result. Equivalent positives remain in the preservation branch, so training does not require rewriting them into a preferred canonical transcription.

This phase produced a measurable efficiency dividend. From Stage 3 SFT to final GRPO, average trajectory length across all cases dropped from 2.594 turns to 2.313 turns, a 10.8% reduction. Average rendering calls on erroneous cases fell from 2.104 to 1.598, a 24.0% drop. Repair and preservation scores improved at the same time.

Ground Truth Under Review: The Construction of OCRErrBench

To evaluate the framework, the researchers constructed OCRErrBench around preservation, diagnosis, localization, and repair. Its inclusion of valid alternative representations directly tests a boundary that strict source matching can obscure.

The benchmark contains 900 real OCR predictions collected from DeepSeek-OCR, PaddleOCR-VL-1.5, and Qwen3.5-27B on OmniDocBench and PureDocBench. It is split evenly between text crops and mathematical formula crops, with 450 cases of each.

There are 457 valid inputs and 443 erroneous inputs. Among the valid cases, 141 match the reference after normalization, while 316 are rendering-equivalent positives. The authors exclude material originating from the two source benchmarks from diagnostic SFT, repair SFT, and GRPO training.

Annotation combines independent model review with expert fallback. GPT-5.6 Sol, Claude Opus 4.8, and Gemini 3.1 Pro independently assess the source crop, prediction, and rendering feedback. Automatic acceptance requires complete agreement on the annotation and convergence on a rendering-verified correction. This is an agreement requirement, not a guarantee of error-free labels.

Difficult or inconsistent cases go to three independent domain experts. Unanimous annotations are accepted directly; residual disputes are retained only when the reconciled repair agrees with the assigned error types and recovers the reference.

All rendering-equivalent positives receive an additional manual audit. Equivalence checks use a frozen local Playwright/Chromium environment with KaTeX 0.16.11, Markdown parsing, fixed display settings, and a fixed font inventory including Fandol fonts. A rendering failure is never accepted as evidence of equivalence.

The Scorecard: Real Gains Across Four External OCR Engines

On end-to-end diagnosis across OCRErrBench's 900 cases, DocEDR achieves 94.78% accuracy, 94.75% balanced accuracy, and 94.59% Bad-F1. The base Qwen3.5-9B scores 81.44% accuracy, while DOCR-Inspector-7B achieves 78.78%. Qwen3.5-397B-A17B(FP8) reaches 87.78%, seven percentage points below DocEDR.

For localization, DocEDR records event-level micro-F1 of 92.72% on text spans and 73.26% on formula-token spans. These scores use one-to-one error matching with a boundary tolerance of three normalized characters or tokens. GLM-4.6V-Flash and InternVL3.5-8B score 0.61% and 1.23%, respectively, on formula localization under the benchmark protocol.

Repair and preservation are evaluated separately:

• Visual Fix (VisFix): On the 443 erroneous inputs, DocEDR achieves 86.23%. This requires pixel-level identity between the rendered repair and rendered target under the same frozen compiler.
• Exact String Fix: On those same erroneous inputs, it achieves 82.17% normalized target agreement.
• Preservation Rate: On the 457 valid inputs, it achieves 93.44%.

Direct one-step Qwen3.5-397B reaches 72.23% VisFix and 26.19% ExactFix. DOCR-Inspector-7B guiding one-pass correction by Qwen3.5-9B reaches 65.46% VisFix. These baselines do not use online rerendering. The larger direct model also has a higher preservation score than DocEDR: 94.75% versus 93.44%.

Zero-shot diagnosis is tested on 637 compatible DOCRcaseBench cases, comprising 445 text cases and 192 formula cases. Formula Case-F1 rises from DOCR-Inspector-7B's 56.69% to DocEDR's 87.68%, a gain of 30.99 percentage points. The paper separately reports 61 additional correct formula classifications. These are diagnostic results, not a formula-repair rate.

Finally, the authors test refinement on 12,683 formulas per parser from UniMER-Test's Simple and Complex Printed Expression subsets. DocEDR preserves predictions it judges correct and repairs those it judges erroneous. The reported gains apply to each fixed, model-identified Bad partition:

• MinerU2.5: Identifies 32.50% as Bad; improves that partition's Character Detection Matching (CDM) by 2.93 percentage points.
• PaddleOCR-VL-1.5: Identifies 22.19% as Bad; improves that partition's CDM by 2.24 points.
• InternVL3.5-8B: Identifies 25.92% as Bad; improves that partition's CDM by 3.72 points.
• GLM-4.6V-Flash: Identifies 37.18% as Bad; improves that partition's CDM by 4.62 points.

The parsers' pre-repair overall CDM scores range from 65.59% to 94.12%. Every identified Bad partition improves. However, a DocEDR Good judgment does not establish reference-level correctness: the Good partitions for InternVL3.5-8B and GLM-4.6V-Flash have pre-repair CDM scores of 66.97% and 78.65%.

Why it matters for document engineering and LLM pipelines

For document engineering, the paper's strongest practical lesson is that specialized diagnosis and repair training can outperform direct prompting of a much larger model on the evaluated tasks. That supports investigating a dedicated correction stage. It does not establish that single-pass OCR has reached a scaling ceiling or that every document pipeline needs an execution loop.

Second, the source image remains useful after recognition. OCR-EDR retains it as evidence throughout correction, alongside the editable text and its rendering. This lets the policy inspect whether a proposed change restores visible content and structure. The paper does not evaluate retrieval, RAG, mathematical question answering, or other downstream applications, so improvements in those systems remain untested.

Third, evaluation benefits from distinguishing representation differences from recognition errors. OCRErrBench explicitly includes both exact positives and rendering-equivalent positives, alongside genuine errors. Its results show why a benchmark should test preservation as well as correction: a model that repairs many broken predictions can still unnecessarily modify valid ones.

The ablations sharpen that lesson. In a matched experiment, iteration without updated rendering lowers ExactFix from 72.46% to 66.82% relative to the one-step setting without post-edit feedback. Combining iteration with updated rendering raises ExactFix to 82.17% and VisFix to 86.23%. Extra turns alone do not explain the gains; the model needs useful evidence about its edits.

Finally, the external-parser experiment demonstrates a concrete integration pattern: take an existing OCR prediction, diagnose it, preserve it or repair it, and measure the result. Routing selected document regions to such a stage is a possible deployment extension. The paper does not test confidence-based routing or establish its operational cost.

The Engineering Trade-offs and Unsolved Hard Problems

The results are compelling, but the reported experiments leave several deployment questions open.

One is latency. DocEDR averages 2.313 interaction turns across all OCRErrBench cases and 1.598 rendering calls on erroneous inputs. Those figures describe interaction efficiency, not elapsed processing time. The paper does not report wall-clock latency, throughput, or deployment cost, so they cannot establish whether the system suits interactive scanning or large-scale batch processing.

Another is the rendering environment. The benchmark's equivalence checks and visual repair criterion depend on a frozen compiler and font setup. That makes the reported comparisons reproducible within the chosen environment. It does not establish coverage of arbitrary markup, fonts, or document formats. The framework represents rendering failures explicitly, but the paper does not demonstrate a general solution for unsupported valid constructs.

Formula localization also remains weaker than text localization under the respective metrics: 73.26% versus 92.72% F1. The input ablation adds a useful qualification. Source image plus OCR text achieves higher localization scores than the complete triplet, while adding rendering produces the strongest validity and error-type results. Rendering helps, but it does not improve every measured capability.

Equivalent-positive results require particular care. Table 3 reports a 25.81% false-positive rate for DocEDR in its boundary-diagnosis analysis, compared with DOCR-Inspector-7B's 75.81%. Table E1 separately reports 4.75% equivalent-positive false positives for the full-input model. The paper does not clearly reconcile those figures, so 25.81% should not be presented as a universal rate for valid code variations. A diagnostic false positive also does not, by itself, establish that an edit occurred.

Preservation remains imperfect, as the 93.44% result on valid inputs shows. Nor does every correction receive a fresh visual check: requesting another rendering is a policy decision, and the model may stop after editing. The repair scores establish performance under the benchmark's evaluation procedure, not a guarantee for every output.

Even with those caveats, OCR-EDR offers a concrete advance. It connects source-grounded diagnosis, executable correction, and optional visual reassessment in one policy—and measures both successful repairs and the preservation of valid predictions.