EditVeto Adds a Post-Rewrite Veto Gate for Reliable OCR Correction
Summary:EditVeto addresses overcorrection in LLM-based OCR repair, where a model fixes genuine OCR errors while unnecessarily changing already-correct text. The method first performs a full-context rewrite, aligns it character-by-character with the OCR input, splits the differences into blocks, and uses a 0.6B-parameter gate to keep or revert each edit. Across eight HIPE-OCRepair-2026 test sets, gating improves five rewriters by 0.0026–0.0044 in weighted cMER and by 0.15–0.25 in preference score. Howeve
Rewrite First, Veto Second
EditVeto divides historical-document OCR correction into two stages. An LLM first produces a revision using the full document context. A 0.6B-parameter gate then aligns the rewrite with the OCR input at character level, divides the differences into edit blocks, and decides whether to keep each change or revert it. The rewriter no longer has to identify errors directly. Instead, candidate edits are extracted from a coherent full-context rewrite and submitted to an external reviewer block by block.
This design is more reliable than isolated span correction. The paper's oracle analysis shows that, given the true error locations, generating corrections independently for each span can perform worse than applying no correction at all. Local generation lacks the cross-span context needed to distinguish OCR noise from legitimate historical spelling or terminology. A full rewrite can use that context, but it may also modify already-correct text. EditVeto separates candidate generation from edit acceptance.
How the Gate Works
The system aligns the OCR transcript and LLM output character by character, then organizes their differences into blocks. For each block, the gate examines the source text, proposed revision, and surrounding context before deciding whether to accept or revert the edit. Because the reviewer is external to the generator, it need not share the same failure modes as the rewriter, and a separate gate can be trained for each rewriting pipeline.
The gate was trained on rewrites produced by two Qwen3 models and then frozen during evaluation. On eight HIPE-OCRepair-2026 test sets, it improved five rewriters, including two unseen during training. Weighted cMER fell by 0.0026–0.0044, while preference scores rose by 0.15–0.25, with paired-bootstrap p-values around 0.0002. This suggests cross-rewriter transfer, although the result remains specific to the tested model family, OCR data, and edit-segmentation strategy.
Ensembling Contributes More Than Gating
In a second disclosed test, the team retrained the gate and applied it to LoRA-tuned rewriters. Weighted cMER still fell by 0.0011–0.0021. An ensemble of the gated rewrites reached 0.0069 cMER and a 0.928 preference score. Ablations, however, indicate that most of the gain came from fine-tuning and pooling multiple outputs rather than from gating itself.
The distinction matters. Ensembling broadens candidate coverage and reduces uncertainty in a single generation, whereas a veto gate changes which local edits are accepted. They solve different failure modes, and deployment systems should not attribute ensemble gains to the gate without an ablation.
The Gate Is Not a Universal Improvement
The most important negative result appears when EditVeto is applied to published competition outputs. It reduces cMER for three of four teams, but worsens the winning run from 0.0050 to 0.0065. Thus, even a gate that improves five rewriters under controlled evaluation can conflict with an already strong rewriting system.
Possible causes include a mismatch between the gate's training distribution and the winning system's output style, weak separation between useful and unnecessary character-level edits, and a high-quality rewriter already incorporating domain-specific error boundaries. A deployment that already uses domain-adapted OCR repair should therefore test the gate on the exact rewritten outputs before adding it. Average gains do not imply monotonic improvement.
The public-model-and-data EditVeto system ultimately trailed the competition winner and tied with the second-place run. Both leading systems used domain pre-training. This comparison indicates that a post-hoc gate can constrain overcorrection from general-purpose models, but it does not replace domain adaptation for historical spelling, typography, and recurring OCR errors.
Generalization and Metric Divergence
In a third, less fully disclosed evaluation, the unchanged gate reduced zero-shot Qwen3.8-27B cMER from 0.0114 to 0.0108. Its LoRA-tuned version improved only the preference score, not cMER. The divergence indicates that character error rate and human preference capture different qualities. cMER focuses on character-level accuracy, whereas preference may also reflect fluency, formatting, and annotator bias. Production evaluation should report error rate, preference, and domain-specific correctness separately.
Deployment Recommendations
EditVeto can be attached as a post-processing layer without modifying the rewriter. The cost is an additional character-alignment pass, block-level inference, and a small model invocation. The 0.6B gate remains much cheaper than a full generative model, but it adds memory pressure, serialization latency, and operational complexity. Offline batch pipelines can process gate decisions in batches; real-time systems need to test whether the extra stage offsets gains from a faster rewriter.
A production system should retain the source OCR, candidate rewrite, gate decisions, and reverted blocks for auditing. Training data should cover multiple periods, document types, layouts, and OCR engines, including outputs from strong domain-adapted models. Evaluation should also include already-strong systems, because gate quality is not monotonic with rewriter quality.
EditVeto is a lightweight protection layer against overcorrection: generate a context-aware revision, then review its edits with a smaller model. Its controlled results are promising, but the degradation of the best competition output shows that domain-level validation and per-rewriter ablations are mandatory before deployment.
— END —Source: ArXiv NLP/LLM (cs.CL) (2026-11-06)
Tags: #EditVeto #OCR Correction #LLM Gating #Character Error Rate #Qwen3
Editorial & Fact-Checking Note: This article is compiled from primary research, official release documentation, and source papers by the ZICQ Newsroom pipeline with automated entity verification and human editorial review. If you notice any technical inaccuracy, please submit a correction via our corrections policy or email our editorial desk directly.
Community Comments