El compilador en el bucle: cómo DocEDR de Tencent utiliza el renderizado para verificar y reparar OCR

Un modelo de OCR procesa un sistema de ecuaciones impreso. En uno de los ejemplos ilustrados del artículo, un término que debería contener $\nabla^2$ aparece en la salida LaTeX del modelo con el operador llevando un subíndice: \vec{\nabla}_{2}. El exponente se ha aplanado en un índice. La cadena sigue siendo reconocible como marcado matemático, pero su estructura renderizada ya no coincide con la fuente.

Ahora consideremos otra expresión: $T \ge 0$. El modelo la transcribe como T \geq 0, mientras que la referencia utiliza T \ge 0. Una comparación literal de cadenas detecta una diferencia. Sin embargo, ambas expresiones se renderizan de forma idéntica. Tratar esa diferencia como un error de reconocimiento penaliza un fallo que no existe.

Este doble quebradero de cabeza refleja un problema en el análisis de documentos. Por un lado, las predicciones de OCR pueden omitir contenido, reconocer erróneamente símbolos o introducir estructuras no respaldadas por la fuente. Por el otro, la evaluación basada en cadenas puede penalizar salidas válidas simplemente porque el marcado utiliza un alias o una representación equivalente.

Un equipo de investigación de WeChat Vision en Tencent propone una forma de abordar ambos problemas. Su artículo del 3 de septiembre de 2026, OCR-EDR: Rendering-Aware Diagnosis and Repair for Closed-Loop OCR Improvement, define un marco de diagnóstico y reparación e introduce DocEDR, un modelo desarrollado a partir de Qwen3.5-9B. A partir de un recorte de la fuente, una predicción editable de OCR y su renderizado, DocEDR evalúa la coherencia, aplica correcciones cuando es necesario y puede solicitar un nuevo renderizado para inspeccionar el resultado.

Los hallazgos reportados son notables. En su nuevo benchmark seleccionado, OCRErrBench, DocEDR logra una precisión diagnóstica del 94.78%, superando a Qwen3.5-397B-A17B(FP8). En el diagnóstico de fórmulas zero-shot sobre DOCRcaseBench, incrementa el Case-F1 en 30.99 puntos porcentuales respecto a DOCR-Inspector-7B. Por separado, repara el 86.23% de las entradas erróneas de OCRErrBench hasta lograr concordancia visual con sus referencias. La contribución consiste en un bucle que conecta la detección de errores con ediciones ejecutables y una reevaluación basada en el renderizado.

La trampa de las cadenas: por qué la evaluación estándar de OCR penaliza el código correcto

Para entender por qué el equipo desarrolló DocEDR, consideremos qué miden las métricas de OCR basadas en cadenas de texto. La distancia de edición cuenta las diferencias entre una predicción y una referencia. No determina por sí misma si dos cadenas distintas preservan el mismo contenido y estructura visibles.

Esa distinción es crucial para el marcado matemático. El artículo ofrece ejemplos como:

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

Estos pares emplean un código fuente diferente para generar el mismo renderizado. El artículo también presenta ejemplos válidos que involucran representaciones de símbolos griegos, tamaño de delimitadores y variaciones tipográficas inofensivas. Dichas variaciones deben comprobarse en contexto: por ejemplo, distintos comandos de delimitadores no son universalmente intercambiables.

Los autores denominan a las representaciones válidas pero no idénticas «positivos equivalentes por renderizado» (rendering-equivalent positives). En el subconjunto de diagnóstico en frontera reportado en la Tabla 3, un umbral de distancia de edición normalizada de 0.1 rechazó el 57.14% de las predicciones de texto equivalentes por renderizado. DOCR-Inspector-7B rechazó el 75.81% de los positivos equivalentes evaluados en dicha tabla. Este mantuvo su protocolo oficial de imagen única; la comparación no demuestra que inspeccione únicamente cadenas sin procesar.

También surge el problema opuesto. Un pequeño cambio en el código fuente puede alterar una relación visual importante. Cambiar \nabla^2 por \nabla_2 requiere solo una sustitución de carácter, pero desplaza un símbolo de un superíndice a un subíndice. Por lo tanto, una distancia de edición agregada baja puede coexistir con un error estructural auténtico.

El artículo evalúa ambos lados de esta frontera. Su criterio para fórmulas basado en referencias, CDM por debajo de 0.9, rechaza solo el 2.94% de las fórmulas equivalentes en el subconjunto seleccionado, pero pasa por alto todos los errores locales evaluados dentro de su ámbito de aplicación. De manera similar, el criterio de distancia de edición de texto omite los errores locales dentro de su alcance. Estos resultados corresponden a los casos y umbrales seleccionados, y no constituyen evidencia de que ninguna de las dos métricas sea ineficaz de forma universal.

La poscorrección basada exclusivamente en texto presenta una limitación similar. Puede utilizar patrones lingüísticos para mejorar una secuencia de OCR, pero no puede inspeccionar directamente si el resultado corregido restituye el contenido visible de la imagen fuente. OCR-EDR incorpora esa evidencia visual al proceso de corrección.

La arquitectura central: convertir la corrección de documentos en una máquina de estados

DocEDR replantea la corrección de OCR como una máquina de estados agéntica. En lugar de tratar la predicción inicial como una salida fija, el modelo mantiene un candidato editable y evalúa conjuntamente tres entradas:

1. Imagen fuente ($I$): El recorte visual del documento original, que aporta evidencia externa.
2. Predicción actual de OCR ($p$): La cadena simbólica editable, como el marcado de fórmulas o texto.
3. Imagen renderizada ($R(p)$): El resultado visual de renderizar la predicción actual.

El modelo utiliza tanto información simbólica como visual. La secuencia de OCR facilita la localización y edición precisas, mientras que su renderizado expone las consecuencias visuales de dicha secuencia. Si un comando alternativo preserva el contenido y la estructura de la fuente, el comportamiento previsto es aceptar la predicción y detenerse.

Cuando la predicción es incoherente con la fuente, el modelo puede diagnosticarla y repararla. Los autores definen cinco categorías atómicas de error mutuamente excluyentes:

• Invalid Output (Global): Salida vacía, mal formada, no parseable o no renderizable en la representación requerida.
• Global Mismatch (Global): Predicciones incoherentes con la fuente en su totalidad, como contenido procedente de una región incorrecta.
• Completeness (Local): Palabras perdidas, términos omitidos o contenido redundante.
• Content (Local): Caracteres o símbolos individuales incorrectos, como confundir una $k$ latina con una $\kappa$ griega.
• Structure (Local): Orden de lectura, agrupamiento, jerarquía o relaciones espaciales y de marcado incorrectos, incluidos superíndices aplanados y fracciones rotas.

Cada error atómico se asigna a una única categoría, aunque una predicción puede contener múltiples errores. Los fallos globales utilizan una operación global_rewrite cuando la edición localizada resulta inadecuada. Las reparaciones locales emplean insert, delete o replace.

De manera fundamental, DocEDR no vuelve a renderizar automáticamente tras cada edición. Su espacio de acciones a nivel de política incluye inspect, diagnose_scope, localize, patch, global_patch, request_render y stop. Estas acciones controlan el proceso y son distintas de las operaciones textuales aplicadas a la secuencia de OCR.

Tras una edición, el renderizado anterior se marca como obsoleto (stale). El modelo puede detenerse sin realizar otra comprobación visual o invocar request_render para inspeccionar el candidato actualizado. El fallo de renderizado tiene su propio estado explícito, independiente de una imagen obsoleta. Por consiguiente, el marco registra si la retroalimentación visual es actual, obsoleta o no está disponible debido a un fallo en el renderizado.

En el interior de DocEDR: cómo entrenar un modelo de 9B parámetros para superar a una línea base más grande

DocEDR se inicializa a partir de Qwen3.5-9B. Los autores lo entrenan mediante ajuste fino supervisado (SFT) de diagnóstico, un plan de estudios (curriculum) de reparación en tres etapas y aprendizaje por refuerzo. Las fases conectan progresivamente la evaluación de validez con la edición y el control del bucle de reparación.

Phase 1: Verifier Supervised Fine-Tuning

El modelo aprende primero la verificación de coherencia visual. A partir de la imagen fuente, el texto de OCR y la imagen renderizada, se entrena durante una época (epoch) para predecir la validez y la información estructurada de los errores. En el caso de predicciones erróneas, dicha información incluye las clases de error, sus ubicaciones y las correcciones propuestas.

A continuación, el punto de control (checkpoint) de diagnóstico sigue dos caminos. Una copia se congela para actuar como el Verifier de recompensa. La otra continúa entrenándose como la política interactiva de reparación. Esto preserva una señal diagnóstica estable mientras el modelo de reparación aprende nuevos comportamientos.

Phase 2: Curriculum Repair SFT

A continuación, el agente se somete a tres etapas secuenciales de ajuste fino supervisado:

• Stage 1 (Single-turn repair): El modelo aprende la corrección directa sin renderizado durante el proceso de reparación.
• Stage 2 (Tool selection): El modelo aprende a elegir entre solicitar un renderizado actualizado o detenerse, en lugar de considerar que cada corrección requiere una llamada a una herramienta.
• Stage 3 (Multi-turn visual recovery): El modelo recibe retroalimentación real de renderizado posterior a la edición. Aprende a reconocer errores residuales, recuperarse de ediciones ineficaces y continuar reparando cuando sea necesario.

La Etapa 1 se ejecuta durante una época; las Etapas 2 y 3 se ejecutan durante dos épocas cada una. El benchmark se mantiene aislado de estas etapas de entrenamiento a nivel de documento fuente.

Phase 3: Reinforcement Learning via GRPO

La política final se optimiza mediante Optimización de Política Relativa de Grupo (GRPO) a lo largo de 400 actualizaciones. Para cada instrucción (prompt), el entrenamiento muestrea un grupo de ocho trayectorias y las califica mediante una recompensa condicionada por etiquetas.

La función de recompensa distingue entre entradas válidas y erróneas:

• Para entradas válidas ($y_0 = \text{good}$): Se recompensa al modelo por preservar la predicción inicial normalizada. Los cambios innecesarios, turnos adicionales y llamadas de renderizado conllevan penalizaciones.
• Para entradas erróneas ($y_0 = \text{bad}$): La calidad terminal combina la similitud de edición normalizada, la concordancia exacta con la referencia, el juicio de coherencia visual del Verifier congelado y la validez del formato de salida. Un término de proceso recompensa la recuperación y penaliza la regresión entre los estados candidatos evaluados.

La optimización también desalienta las ediciones repetidas, el renderizado excesivo y el agotamiento del presupuesto de interacción con un resultado final erróneo. Los positivos equivalentes permanecen en la rama de preservación, por lo que el entrenamiento no exige reescribirlos en una transcripción canónica preferida.

Esta fase generó una mejora de eficiencia cuantificable. Desde el SFT de la Etapa 3 hasta el GRPO final, la longitud media de la trayectoria en todos los casos disminuyó de 2.594 a 2.313 turnos, una reducción del 10.8%. El promedio de llamadas de renderizado en casos erróneos cayó de 2.104 a 1.598, un descenso del 24.0%. Al mismo tiempo, las puntuaciones de reparación y preservación mejoraron.

Ground Truth bajo revisión: la construcción de OCRErrBench

Para evaluar el marco de trabajo, los investigadores construyeron OCRErrBench en torno a la preservación, el diagnóstico, la localización y la reparación. La inclusión de representaciones alternativas válidas pone a prueba directamente un límite que la correspondencia estricta con la fuente suele enmascarar.

El benchmark contiene 900 predicciones reales de OCR recopiladas a partir de DeepSeek-OCR, PaddleOCR-VL-1.5 y Qwen3.5-27B sobre OmniDocBench y PureDocBench. Se divide equitativamente entre recortes de texto y recortes de fórmulas matemáticas, con 450 casos de cada uno.

Hay 457 entradas válidas y 443 entradas erróneas. Entre los casos válidos, 141 coinciden con la referencia tras la normalización, mientras que 316 son positivos equivalentes por renderizado. Los autores excluyen del SFT de diagnóstico, del SFT de reparación y del entrenamiento con GRPO el material procedente de los dos benchmarks de origen.

La anotación combina la revisión independiente de modelos con el respaldo de expertos humanos. GPT-5.6 Sol, Claude Opus 4.8 y Gemini 3.1 Pro evalúan de forma independiente el recorte fuente, la predicción y la retroalimentación de renderizado. La aceptación automática exige concordancia total en la anotación y convergencia en una corrección verificada por renderizado. Este es un requisito de concordancia, no una garantía de etiquetas libres de error.

Los casos difíciles o contradictorios se remiten a tres expertos independientes en el dominio. Las anotaciones unánimes se aceptan directamente; las discrepancias residuales se conservan únicamente cuando la reparación consensuada concuerda con los tipos de error asignados y recupera la referencia.

Todos los positivos equivalentes por renderizado reciben una auditoría manual adicional. Las comprobaciones de equivalencia utilizan un entorno local congelado de Playwright/Chromium con KaTeX 0.16.11, análisis de Markdown, configuraciones de visualización fijas y un repertorio tipográfico fijo que incluye fuentes Fandol. Un fallo de renderizado nunca se acepta como prueba de equivalencia.

La tabla de resultados: mejoras reales en cuatro motores de OCR externos

En el diagnóstico de extremo a extremo a lo largo de los 900 casos de OCRErrBench, DocEDR alcanza una precisión (accuracy) del 94.78%, una precisión balanceada del 94.75% y un Bad-F1 del 94.59%. El modelo base Qwen3.5-9B obtiene una precisión del 81.44%, mientras que DOCR-Inspector-7B alcanza el 78.78%. Qwen3.5-397B-A17B(FP8) llega al 87.78%, siete puntos porcentuales por debajo de DocEDR.

En cuanto a la localización, DocEDR registra un micro-F1 a nivel de evento del 92.72% en tramos de texto y del 73.26% en tramos de tokens de fórmulas. Estas puntuaciones utilizan una correspondencia de errores uno a uno con una tolerancia de límite de tres caracteres o tokens normalizados. GLM-4.6V-Flash e InternVL3.5-8B obtienen un 0.61% y un 1.23%, respectivamente, en la localización de fórmulas bajo el protocolo del benchmark.

La reparación y la preservación se evalúan por separado:

• Visual Fix (VisFix): En las 443 entradas erróneas, DocEDR alcanza el 86.23%. Esto requiere una identidad a nivel de píxel entre la reparación renderizada y el objetivo renderizado bajo el mismo compilador congelado.
• Exact String Fix: En esas mismas entradas erróneas, alcanza una concordancia normalizada con el objetivo del 82.17%.
• Preservation Rate: En las 457 entradas válidas, logra un 93.44%.

Qwen3.5-397B directo en un solo paso alcanza un 72.23% de VisFix y un 26.19% de ExactFix. DOCR-Inspector-7B guiando una corrección en una sola pasada con Qwen3.5-9B alcanza un 65.46% de VisFix. Estas líneas base no utilizan rerenderizado en línea. El modelo directo de mayor tamaño también obtiene una puntuación de preservación más alta que DocEDR: 94.75% frente a 93.44%.

El diagnóstico zero-shot se evalúa en 637 casos compatibles de DOCRcaseBench, que comprenden 445 casos de texto y 192 casos de fórmulas. El Case-F1 en fórmulas pasa del 56.69% de DOCR-Inspector-7B al 87.68% de DocEDR, una ganancia de 30.99 puntos porcentuales. El artículo reporta de forma independiente 61 clasificaciones correctas adicionales de fórmulas. Estos son resultados de diagnóstico, no una tasa de reparación de fórmulas.

Por último, los autores evalúan el refinamiento en 12,683 fórmulas por analizador a partir de los subconjuntos Simple y Complex Printed Expression de UniMER-Test. DocEDR preserva las predicciones que juzga correctas y repara aquellas que considera erróneas. Las mejoras reportadas se aplican a cada partición fija clasificada como Bad por el modelo:

• MinerU2.5: Identifica el 32.50% como Bad; mejora el Character Detection Matching (CDM) de esa partición en 2.93 puntos porcentuales.
• PaddleOCR-VL-1.5: Identifica el 22.19% como Bad; mejora el CDM de esa partición en 2.24 puntos.
• InternVL3.5-8B: Identifica el 25.92% como Bad; mejora el CDM de esa partición en 3.72 puntos.
• GLM-4.6V-Flash: Identifica el 37.18% como Bad; mejora el CDM de esa partición en 4.62 puntos.

Las puntuaciones generales de CDM previas a la reparación de los analizadores oscilan entre el 65.59% y el 94.12%. Todas las particiones identificadas como Bad mejoran. Sin embargo, un dictamen Good por parte de DocEDR no garantiza la exactitud a nivel de referencia: las particiones Good para InternVL3.5-8B y GLM-4.6V-Flash presentan puntuaciones CDM previas a la reparación de 66.97% y 78.65%.

Por qué es relevante para la ingeniería de documentos y los pipelines de LLM

Para la ingeniería de documentos, la lección práctica más contundente del artículo es que un entrenamiento especializado en diagnóstico y reparación puede superar al prompting directo de un modelo mucho más grande en las tareas evaluadas. Esto respalda la investigación de una etapa de corrección dedicada. No obstante, no demuestra que el OCR de pasada única haya alcanzado un límite de escalado ni que todo pipeline de documentos requiera un bucle de ejecución.

En segundo lugar, la imagen fuente sigue siendo útil tras el reconocimiento. OCR-EDR la conserva como evidencia a lo largo de toda la corrección, junto con el texto editable y su renderizado. Esto permite a la política inspeccionar si un cambio propuesto restituye el contenido y la estructura visibles. El artículo no evalúa la recuperación de información, RAG, respuestas a preguntas matemáticas u otras aplicaciones posteriores (downstream), por lo que las mejoras en esos sistemas aún no han sido comprobadas.

En tercer lugar, la evaluación se beneficia al distinguir entre diferencias de representación y errores de reconocimiento. OCRErrBench incluye explícitamente tanto positivos exactos como positivos equivalentes por renderizado, junto con errores auténticos. Sus resultados demuestran por qué un benchmark debe evaluar tanto la preservación como la corrección: un modelo que repara muchas predicciones defectuosas aún puede modificar innecesariamente aquellas que son válidas.

Los estudios de ablación refuerzan esta lección. En un experimento controlado, la iteración sin un renderizado actualizado reduce el ExactFix del 72.46% al 66.82% en comparación con la configuración de un solo paso sin retroalimentación posterior a la edición. Combinar la iteración con un renderizado actualizado eleva el ExactFix al 82.17% y el VisFix al 86.23%. Los turnos adicionales por sí solos no explican estas mejoras; el modelo necesita evidencia útil sobre sus ediciones.

Por último, el experimento con analizadores externos demuestra un patrón de integración concreto: tomar una predicción de OCR existente, diagnosticarla, preservarla o repararla, y medir el resultado. Enrutar regiones seleccionadas del documento hacia una etapa de este tipo es una posible extensión de despliegue. El artículo no evalúa el enrutamiento basado en confianza ni determina su coste operativo.

Compromisos de ingeniería y problemas difíciles no resueltos

Los resultados son convincentes, pero los experimentos reportados dejan abiertas varias cuestiones de despliegue.

Una de ellas es la latencia. DocEDR promedia 2.313 turnos de interacción en todos los casos de OCRErrBench y 1.598 llamadas de renderizado en entradas erróneas. Esas cifras describen la eficiencia de la interacción, no el tiempo de procesamiento transcurrido. El artículo no reporta la latencia de reloj de pared (wall-clock latency), el rendimiento (throughput) ni el coste de despliegue, por lo que no es posible determinar si el sistema es adecuado para el escaneo interactivo o el procesamiento por lotes a gran escala.

Otra cuestión es el entorno de renderizado. Las comprobaciones de equivalencia del benchmark y el criterio de reparación visual dependen de una configuración congelada de compilador y fuentes. Esto hace que las comparaciones reportadas sean reproducibles dentro del entorno elegido, pero no garantiza la cobertura de marcado, fuentes o formatos de documentos arbitrarios. El marco representa los fallos de renderizado de manera explícita, pero el artículo no demuestra una solución general para construcciones válidas no soportadas.

La localización de fórmulas también sigue siendo más débil que la de texto según sus respectivas métricas: 73.26% frente a 92.72% de F1. La ablación de entradas añade una matización útil: la combinación de imagen fuente más texto de OCR logra puntuaciones de localización más altas que el triplete completo, mientras que añadir el renderizado produce los resultados más sólidos en validez y tipo de error. El renderizado ayuda, pero no mejora todas las capacidades evaluadas.

Los resultados de positivos equivalentes requieren especial atención. La Tabla 3 reporta una tasa de falsos positivos del 25.81% para DocEDR en su análisis de diagnóstico en frontera, en comparación con el 75.81% de DOCR-Inspector-7B. Por otra parte, la Tabla E1 reporta un 4.75% de falsos positivos en equivalentes positivos para el modelo con entrada completa. El artículo no concilia claramente estas cifras, por lo que el 25.81% no debe presentarse como una tasa universal para variaciones de código válidas. Además, un falso positivo en el diagnóstico no demuestra por sí mismo que se haya producido una edición.

La preservación sigue siendo imperfecta, como demuestra el resultado del 93.44% en entradas válidas. Tampoco todas las correcciones reciben una nueva verificación visual: solicitar otro renderizado es una decisión de la política, y el modelo puede detenerse tras la edición. Las puntuaciones de reparación determinan el rendimiento bajo el procedimiento de evaluación del benchmark, pero no constituyen una garantía para cada salida individual.

Aun con esas salvedades, OCR-EDR representa un avance concreto. Integra en una única política el diagnóstico fundamentado en la fuente, la corrección ejecutable y la reevaluación visual opcional, midiendo tanto las reparaciones exitosas como la preservación de predicciones válidas.