O Compilador no Loop: Como o DocEDR da Tencent Usa Renderização para Verificar e Reparar OCR

Um modelo de OCR processa um sistema de equações impresso. Em um dos exemplos ilustrados no artigo, um termo que deveria conter $\nabla^2$ surge na saída LaTeX do modelo com o operador acompanhado por um subscrito: \vec{\nabla}_{2}. O expoente foi achatado em um índice. A string continua reconhecível como marcação matemática, mas sua estrutura renderizada já não corresponde ao original.

Agora considere outra expressão: $T \ge 0$. O modelo a transcreve como T \geq 0, enquanto a referência utiliza T \ge 0. Uma comparação literal de strings encontra uma diferença. No entanto, ambas as expressões são renderizadas de forma idêntica. Tratar essa diferença como um erro de reconhecimento penaliza um equívoco que não existe.

Essa dor de cabeça dupla sintetiza um problema central no parsing de documentos. Por um lado, as predições de OCR podem omitir conteúdo, reconhecer símbolos erroneamente ou introduzir estruturas sem correspondência no original. Por outro, a avaliação baseada em strings pode penalizar saídas perfeitamente válidas simplesmente porque a marcação utiliza um alias ou uma representação equivalente.

Uma equipe de pesquisa da WeChat Vision na Tencent propõe uma abordagem para enfrentar ambos os problemas. Seu artigo de 3 de setembro de 2026, OCR-EDR: Rendering-Aware Diagnosis and Repair for Closed-Loop OCR Improvement, define um framework de diagnóstico e reparo e introduz o DocEDR, um modelo construído sobre o Qwen3.5-9B. A partir de um recorte da imagem de origem, de uma predição de OCR editável e de sua renderização, o DocEDR avalia a consistência, aplica correções quando necessário e pode solicitar uma nova renderização para inspecionar o resultado.

Os resultados relatados são expressivos. Em seu benchmark recém-criado, o OCRErrBench, o DocEDR alcança 94.78% de acurácia diagnóstica, superando o Qwen3.5-397B-A17B(FP8). No diagnóstico zero-shot de fórmulas no DOCRcaseBench, ele eleva o Case-F1 em 30.99 pontos percentuais em relação ao DOCR-Inspector-7B. Além disso, repara 86.23% das entradas errôneas do OCRErrBench, atingindo concordância visual com suas referências. A grande contribuição é um loop que conecta a detecção de erros a edições executáveis e à reavaliação baseada em renderização.

The String Trap: Por Que a Avaliação Padrão de OCR Penaliza Código Bom

Para entender por que a equipe construiu o DocEDR, considere o que as métricas de OCR baseadas em strings realmente medem. A distância de edição contabiliza as diferenças entre uma predição e uma referência. Ela não determina, por si só, se duas strings diferentes preservam o mesmo conteúdo visual e a mesma estrutura.

Essa distinção é fundamental para a marcação matemática. O artigo apresenta exemplos como:

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

Esses pares utilizam códigos-fonte distintos para produzir exatamente a mesma renderização. O artigo também traz exemplos válidos envolvendo representações de símbolos gregos, dimensionamento de delimitadores e variações tipográficas inofensivas. Tais variações precisam ser avaliadas no contexto: comandos diferentes de delimitadores, por exemplo, não são universalmente intercambiáveis.

Os autores denominam essas representações válidas e não idênticas de positivos equivalentes por renderização (rendering-equivalent positives). No subconjunto de diagnóstico de fronteira relatado na Tabela 3, um limiar de distância de edição normalizada de 0.1 rejeitou 57.14% das predições de texto equivalentes por renderização. O DOCR-Inspector-7B rejeitou 75.81% dos positivos equivalentes avaliados nessa tabela. Ele manteve seu protocolo oficial de imagem única; a comparação não comprova que ele inspecione apenas strings puras.

O problema oposto também ocorre. Uma pequena alteração no código-fonte pode modificar uma relação visual crítica. Trocar \nabla^2 por \nabla_2 exige a substituição de apenas um caractere, mas desloca um símbolo de sobrescrito para subscrito. Portanto, uma distância de edição agregada baixa pode coexistir com um erro estrutural genuíno.

O artigo testa os dois lados dessa fronteira. Seu critério para fórmulas baseado em referência, CDM abaixo de 0.9, rejeita apenas 2.94% das fórmulas equivalentes no subconjunto selecionado, mas não detecta nenhum dos erros locais avaliados dentro de seu escopo aplicável. Do mesmo modo, o critério de distância de edição para texto deixa passar os erros locais em seu escopo. Esses são resultados para os casos e limiares selecionados, e não uma evidência de que qualquer uma das métricas seja universalmente ineficaz.

A pós-correção baseada exclusivamente em texto possui uma limitação semelhante. Ela pode recorrer a padrões linguísticos para aprimorar uma sequência de OCR, mas não consegue inspecionar diretamente se a saída revisada restabelece o conteúdo visual da imagem de origem. O OCR-EDR adiciona essa evidência visual ao processo de correção.

A Arquitetura Central: Transformando a Correção de Documentos em uma Máquina de Estados

O DocEDR reformula a correção de OCR como uma máquina de estados agêntica. Em vez de tratar a predição inicial como uma saída imutável, o modelo mantém um candidato editável e avalia conjuntamente três entradas:

1. Imagem de Origem ($I$): O recorte visual do documento original, que fornece evidências externas.
2. Predição Atual de OCR ($p$): A string simbólica editável, como a marcação de uma fórmula ou texto.
3. Imagem Renderizada ($R(p)$): O resultado visual da renderização da predição atual.

O modelo utiliza tanto informações simbólicas quanto visuais. A sequência de OCR permite localização e edição precisas, enquanto sua renderização expõe as consequências visuais dessa sequência. Se um comando alternativo preservar o conteúdo e a estrutura do original, o comportamento esperado é aceitar a predição e parar.

Quando a predição é inconsistente com a origem, o modelo pode diagnosticá-la e repará-la. Os autores definem cinco categorias de erros atômicos mutuamente exclusivas:

• Invalid Output (Global): Saída vazia, malformada, impossível de analisar (unparsable) ou não renderizável na representação exigida.
• Global Mismatch (Global): Predições inconsistentes com a origem como um todo, como conteúdo extraído da região errada.
• Completeness (Local): Palavras omitidas, termos ausentes ou conteúdo redundante.
• Content (Local): Caracteres ou símbolos individuais incorretos, como confundir a letra latina $k$ com a grega $\kappa$.
• Structure (Local): Ordem de leitura, agrupamento, hierarquia ou relações espaciais e de marcação incorretas, incluindo sobrescritos achatados e frações quebradas.

Cada erro atômico recebe uma categoria, embora uma mesma predição possa conter múltiplos erros. Falhas globais acionam uma operação de global_rewrite quando a edição localizada não é apropriada. Já os reparos locais utilizam insert, delete ou replace.

Crucialmente, o DocEDR não renderiza novamente de forma automática após cada edição. Seu espaço de ações no nível da política (policy-level action space) inclui inspect, diagnose_scope, localize, patch, global_patch, request_render e stop. Essas ações controlam o fluxo do processo e são distintas das operações textuais aplicadas à sequência de OCR.

Após uma edição, a renderização anterior é marcada como desatualizada (stale). O modelo pode encerrar sem uma nova verificação visual ou acionar request_render para inspecionar o candidato atualizado. Falhas na renderização possuem um estado explícito próprio, distinto de uma imagem desatualizada. Dessa forma, o framework registra se o feedback visual está atualizado, desatualizado ou indisponível devido a uma falha de renderização.

Por Dentro do DocEDR: Treinando um Modelo de 9B Parâmetros para Superar um Baseline Maior

O DocEDR é inicializado a partir do Qwen3.5-9B. Os autores o treinam por meio de um fine-tuning supervisionado diagnóstico, um currículo de reparo em três etapas e aprendizado por reforço. Essas etapas conectam progressivamente a avaliação de validade à edição e ao controle do loop de reparo.

Fase 1: Fine-Tuning Supervisionado do Verificador

O modelo primeiro aprende a verificar a consistência visual. A partir da imagem de origem, do texto de OCR e da imagem renderizada, ele é treinado durante uma época para prever a validade e fornecer informações estruturadas de erro. Para predições errôneas, essas informações incluem classes de erro, localizações e correções propostas.

O checkpoint diagnóstico segue então dois caminhos. Uma cópia é congelada para atuar como o Verificador (Verifier) de recompensa. A outra continua em treinamento como a política de reparo interativa. Isso preserva um sinal de diagnóstico estável enquanto o modelo de reparo aprende novos comportamentos.

Fase 2: SFT Curricular de Reparo

Em seguida, o agente passa por três etapas sequenciais de fine-tuning supervisionado:

• Etapa 1 (Reparo em turno único / Single-turn repair): O modelo aprende a realizar correções diretas sem renderização durante o processo de reparo.
• Etapa 2 (Seleção de ferramentas / Tool selection): O modelo aprende a escolher entre solicitar uma renderização atualizada ou parar, em vez de tratar toda correção como demandando uma chamada de ferramenta.
• Etapa 3 (Recuperação visual em múltiplos turnos / Multi-turn visual recovery): O modelo recebe feedback real de renderização pós-edição. Ele aprende a reconhecer erros residuais, recuperar-se de edições ineficazes e prosseguir com os reparos quando necessário.

A Etapa 1 é executada por uma época; as Etapas 2 e 3 rodam por duas épocas cada. O benchmark permanece isolado dessas etapas de treinamento no nível dos documentos de origem.

Fase 3: Aprendizado por Reforço via GRPO

A política final é otimizada usando Group Relative Policy Optimization (GRPO) ao longo de 400 atualizações. Para cada prompt, o treinamento amostra um grupo de oito trajetórias e as pontua utilizando uma recompensa condicionada pelo rótulo.

A recompensa diferencia entradas válidas de entradas errôneas:

• Para entradas válidas ($y_0 = \text{good}$): O modelo é recompensado por preservar a predição inicial normalizada. Alterações desnecessárias, turnos adicionais e chamadas de renderização acarretam penalidades.
• Para entradas errôneas ($y_0 = \text{bad}$): A qualidade terminal combina a similaridade de edição normalizada, a concordância exata com a referência, o julgamento de consistência visual do Verificador congelado e a validade do formato de saída. Um termo de processo recompensa a recuperação e penaliza regressões entre os estados candidatos avaliados.

A otimização também desestimula edições repetidas, renderizações excessivas e o esgotamento do orçamento de iterações com um resultado final errôneo. Os positivos equivalentes permanecem no ramo de preservação, de modo que o treinamento não exige sua reescrita em uma transcrição canônica preferida.

Essa fase gerou um ganho de eficiência mensurável. Do SFT da Etapa 3 até o GRPO final, o comprimento médio da trajetória em todos os casos caiu de 2.594 turnos para 2.313 turnos, uma redução de 10.8%. A média de chamadas de renderização em casos errôneos caiu de 2.104 para 1.598, uma queda de 24.0%. Ao mesmo tempo, as pontuações de reparo e de preservação melhoraram.

Ground Truth sob Revisão: A Construção do OCRErrBench

Para avaliar o framework, os pesquisadores construíram o OCRErrBench com foco em preservação, diagnóstico, localização e reparo. A inclusão de representações alternativas válidas testa diretamente uma fronteira que a correspondência estrita com a fonte pode obscurecer.

O benchmark contém 900 predições reais de OCR coletadas a partir do DeepSeek-OCR, PaddleOCR-VL-1.5 e Qwen3.5-27B no OmniDocBench e PureDocBench. Ele é dividido igualmente entre recortes de texto e de fórmulas matemáticas, com 450 casos de cada.

Há 457 entradas válidas e 443 entradas errôneas. Entre os casos válidos, 141 coincidem com a referência após a normalização, enquanto 316 são positivos equivalentes por renderização. Os autores excluíram materiais provenientes dos dois benchmarks de origem do SFT de diagnóstico, do SFT de reparo e do treinamento com GRPO.

A anotação combina revisão independente por modelos com fallback para especialistas humanos. O GPT-5.6 Sol, o Claude Opus 4.8 e o Gemini 3.1 Pro avaliam de forma independente o recorte de origem, a predição e o feedback de renderização. A aceitação automática exige concordância total na anotação e convergência em uma correção verificada por renderização. Esse é um critério de concordância, e não uma garantia de rótulos isentos de erros.

Casos difíceis ou inconsistentes são encaminhados a três especialistas independentes na área. Anotações unânimes são aceitas diretamente; disputas residuais só são mantidas quando o reparo reconciliado coincide com os tipos de erro atribuídos e recupera a referência.

Todos os positivos equivalentes por renderização passam por uma auditoria manual adicional. As verificações de equivalência utilizam um ambiente local congelado com Playwright/Chromium, KaTeX 0.16.11, parsing de Markdown, configurações de exibição fixas e um conjunto fixo de fontes, incluindo fontes Fandol. Uma falha de renderização nunca é aceita como prova de equivalência.

O Placar: Ganhos Reais em Quatro Motores Externos de OCR

No diagnóstico ponta a ponta nos 900 casos do OCRErrBench, o DocEDR alcança 94.78% de acurácia, 94.75% de acurácia balanceada e 94.59% de Bad-F1. O Qwen3.5-9B base atinge 81.44% de acurácia, enquanto o DOCR-Inspector-7B registra 78.78%. O Qwen3.5-397B-A17B(FP8) chega a 87.78%, sete pontos percentuais abaixo do DocEDR.

Para localização, o DocEDR registra um micro-F1 em nível de evento de 92.72% em trechos de texto e 73.26% em trechos de tokens de fórmulas. Essas pontuações utilizam correspondência de erros um-para-um com uma tolerância de limite de três caracteres ou tokens normalizados. O GLM-4.6V-Flash e o InternVL3.5-8B marcam 0.61% e 1.23%, respectivamente, na localização de fórmulas sob o protocolo do benchmark.

Reparo e preservação são avaliados separadamente:

• Visual Fix (VisFix): Nas 443 entradas errôneas, o DocEDR alcança 86.23%. Isso exige identidade em nível de pixel entre o reparo renderizado e o alvo renderizado sob o mesmo compilador congelado.
• Exact String Fix: Nessas mesmas entradas errôneas, ele atinge 82.17% de concordância com o alvo normalizado.
• Preservation Rate: Nas 457 entradas válidas, alcança 93.44%.

O Qwen3.5-397B direto em uma etapa atinge 72.23% de VisFix e 26.19% de ExactFix. O DOCR-Inspector-7B orientando a correção em passagem única pelo Qwen3.5-9B alcança 65.46% de VisFix. Esses baselines não utilizam rerenderização online. O modelo direto maior também apresenta uma taxa de preservação mais alta que o DocEDR: 94.75% contra 93.44%.

O diagnóstico zero-shot é testado em 637 casos compatíveis do DOCRcaseBench, abrangendo 445 casos de texto e 192 de fórmulas. O Case-F1 de fórmulas sobe de 56.69% com o DOCR-Inspector-7B para 87.68% com o DocEDR, um ganho de 30.99 pontos percentuais. O artigo relata separadamente 61 classificações corretas de fórmulas adicionais. Trata-se de resultados diagnósticos, e não de uma taxa de reparo de fórmulas.

Por fim, os autores testam o refinamento em 12,683 fórmulas por parser dos subconjuntos Simple e Complex Printed Expression do UniMER-Test. O DocEDR preserva as predições que julga corretas e repara aquelas que julga errôneas. Os ganhos relatados aplicam-se a cada partição fixa identificada pelo modelo como Bad:

• MinerU2.5: Identifica 32.50% como Bad; aprimora o Character Detection Matching (CDM) dessa partição em 2.93 pontos percentuais.
• PaddleOCR-VL-1.5: Identifica 22.19% como Bad; melhora o CDM dessa partição em 2.24 pontos.
• InternVL3.5-8B: Identifica 25.92% como Bad; aprimora o CDM dessa partição em 3.72 pontos.
• GLM-4.6V-Flash: Identifica 37.18% como Bad; melhora o CDM dessa partição em 4.62 pontos.

As pontuações gerais de CDM dos parsers antes do reparo variam de 65.59% a 94.12%. Todas as partições identificadas como Bad melhoram. Contudo, um julgamento Good por parte do DocEDR não assegura correção em nível de referência: as partições Good para o InternVL3.5-8B e o GLM-4.6V-Flash apresentam pontuações de CDM pré-reparo de 66.97% e 78.65%.

Por Que Isso Importa para a Engenharia de Documentos e Pipelines de LLMs

Para a engenharia de documentos, a lição prática mais contundente do artigo é que o treinamento especializado em diagnóstico e reparo pode superar o prompting direto de um modelo muito maior nas tarefas avaliadas. Isso reforça a relevância de investigar uma etapa dedicada de correção. No entanto, o trabalho não estabelece que o OCR de passagem única atingiu um teto de escalabilidade nem que todo pipeline de documentos precise de um loop de execução.

Em segundo lugar, a imagem de origem continua sendo útil após o reconhecimento. O OCR-EDR a mantém como evidência ao longo de toda a correção, juntamente com o texto editável e sua renderização. Isso permite à política inspecionar se a alteração proposta restabelece o conteúdo visual e a estrutura. O artigo não avalia recuperação (retrieval), RAG, resposta a perguntas matemáticas ou outras aplicações downstream; portanto, melhorias nesses sistemas permanecem não testadas.

Em terceiro lugar, a avaliação se beneficia ao distinguir variações de representação de erros de reconhecimento. O OCRErrBench inclui explicitamente tanto positivos exatos quanto positivos equivalentes por renderização, ao lado de erros genuínos. Seus resultados mostram por que um benchmark deve testar tanto a preservação quanto a correção: um modelo que repara muitas predições defeituosas ainda pode alterar desnecessariamente predições válidas.

Os estudos de ablação reforçam essa lição. Em um experimento pareado, a iteração sem renderização atualizada reduz o ExactFix de 72.46% para 66.82% em comparação com a configuração de etapa única sem feedback pós-edição. Já a combinação de iteração com renderização atualizada eleva o ExactFix para 82.17% e o VisFix para 86.23%. Turnos adicionais por si sós não explicam os ganhos; o modelo precisa de evidências úteis sobre as edições realizadas.

Por fim, o experimento com parsers externos demonstra um padrão de integração concreto: pegar uma predição de OCR existente, diagnosticá-la, preservá-la ou repará-la e mensurar o resultado. O roteamento de regiões selecionadas do documento para essa etapa é uma possível extensão de implantação. O artigo não testa o roteamento baseado em confiança nem estabelece seus custos operacionais.

Trade-offs de Engenharia e Problemas em Aberto

Os resultados são impressionantes, mas os experimentos relatados deixam em aberto várias questões de implantação.

Uma delas é a latência. O DocEDR registra uma média de 2.313 turnos de interação em todos os casos do OCRErrBench e 1.598 chamadas de renderização em entradas errôneas. Esses números descrevem a eficiência de interação, não o tempo decorrido de processamento. O artigo não reporta a latência em tempo real (wall-clock latency), o throughput nem o custo de implantação; logo, eles não permitem determinar se o sistema é adequado para escaneamento interativo ou processamento em lote (batch) em larga escala.

Outra questão é o ambiente de renderização. As verificações de equivalência e o critério de reparo visual do benchmark dependem de um compilador e de uma configuração de fontes congelados. Isso torna as comparações relatadas reproduzíveis dentro do ambiente escolhido, mas não garante cobertura para marcações, fontes ou formatos de documento arbitrários. O framework representa falhas de renderização de forma explícita, mas o artigo não demonstra uma solução geral para construções válidas sem suporte.

A localização de fórmulas também permanece inferior à localização de texto nas respectivas métricas: 73.26% contra 92.72% de F1. A ablação de entradas acrescenta uma nuance relevante: a combinação de imagem de origem mais texto de OCR alcança pontuações de localização mais altas do que o trio completo, enquanto a adição da renderização produz os resultados mais robustos de validade e tipos de erro. A renderização ajuda, mas não aprimora todas as capacidades medidas.

Os resultados de positivos equivalentes exigem cuidado especial. A Tabela 3 relata uma taxa de falsos positivos de 25.81% para o DocEDR em sua análise de diagnóstico de fronteira, em comparação com 75.81% do DOCR-Inspector-7B. A Tabela E1, separadamente, relata 4.75% de falsos positivos para positivos equivalentes no modelo com entrada completa. O artigo não reconcilia claramente esses números; portanto, 25.81% não deve ser apresentado como uma taxa universal para variações válidas de código. Além disso, um falso positivo no diagnóstico não comprova, por si só, que uma edição de fato ocorreu.

A preservação continua imperfeita, como demonstra o resultado de 93.44% em entradas válidas. Tampouco toda correção recebe uma nova verificação visual: solicitar outra renderização é uma decisão da política, e o modelo pode parar logo após a edição. As pontuações de reparo estabelecem o desempenho sob o procedimento de avaliação do benchmark, e não uma garantia para qualquer saída.

Mesmo com essas ressalvas, o OCR-EDR oferece um avanço concreto. Ele conecta o diagnóstico fundamentado na fonte, a correção executável e a reavaliação visual opcional em uma única política — medindo tanto o sucesso nos reparos quanto a preservação de predições válidas.