Por que o CER engana para VLMs de parsing de documentos
Quantificado com dados de benchmark proprietários (2026)

CER é um algoritmo de pontuação de correspondência exata, não um medidor de qualidade

CER é a distância de edição de Levenshtein entre o texto reconhecido e o texto de referência — o número mínimo de inserções, exclusões e substituições de caracteres necessárias para transformar um no outro, dividido pelo comprimento do texto de referência (a definição formal é publicada pela especificação de avaliação OCR-D). Ele conta diferenças e não consegue distinguir uma leitura incorreta de uma reformatação legítima. Quando a convenção de saída de um mecanismo difere do texto de referência — caixa, separadores, ordem das linhas — o CER cobra erros por comportamentos que não são leituras incorretas.

Mecanismos OCR tradicionais (Tesseract, PaddleOCR, EasyOCR, docTR) emitem fluxos de caracteres brutos que preservam a caixa original e o layout das linhas, então sua convenção de saída fica próxima do texto de referência e o CER mede algo próximo de um erro de leitura genuíno. VLMs de parsing de documentos (Surya2, Unlimited-OCR, PaddleOCR-VL) emitem texto compreendido: eles aplicam normalização de caixa (TAN CHAY YEE vira tan chay yee), fusão rótulo/valor (INVOICE NO\n: PEGIV vira Invoice No : PEGIV) e reordenação de linhas — as convenções de saída de um leitor, não de um scanner. Cada caixa normalizada e linha fundida é uma penalidade de distância de edição, mesmo quando o valor do campo subjacente está correto.

A análise de protocolo do benchmark das previsões SROIE divulgadas decompõe o orçamento bruto de CER de um VLM em aproximadamente ~76% de caracteres idênticos ao texto de referência, ~18% de substituições de caixa e ~10% de fusões de linha / separadores removidos — com os valores reais dos campos (empresa, total, data, endereço) corretos. Essa decomposição é uma estimativa derivada do protocolo das notas de análise do benchmark, não uma coluna do CSV; trate a divisão como direcional, não precisa. A direção é o que importa: apenas a normalização de caixa pode explicar uma grande parte do CER “ruim” de um VLM em recibos limpos em inglês.

Duas linhas do CSV tornam o mecanismo visível sem qualquer decomposição. Unlimited-OCR pontua CER 0.6552 mas WER 0.4779 no SROIE — seus caracteres parecem distorcidos enquanto suas palavras sobrevivem, porque a normalização de caixa substitui caracteres sem quebrar palavras (summary_metrics.csv, cer / wer, linha unlimited_ocr/sroie_2019). E o VLM que menos normaliza, Surya2, pontua CER 0.1915 — o melhor CER bruto em toda a execução de 8 mecanismos, indistinguível de um mecanismo tradicional forte (summary_metrics.csv, cer, linha surya2/sroie_2019). A convenção de saída do VLM, não a capacidade de leitura do VLM, é o que a coluna CER está medindo em sua maior parte.

A Prova Está nas Inversões: CER e F1 de Campo Discordam

O ranking de CER do benchmark e seu ranking de extração de campos discordam de forma material. Ordene os oito motores pelo CER de SROIE e o vencedor é Surya2 (0,1915); ordene-os pelo F1 de campo regex — a métrica que se aproxima do que um pipeline de produção consome — e o vencedor é Unlimited-OCR (0,3376), o motor que o CER classifica em último lugar. Uma das duas colunas não está medindo o que os sistemas downstream realmente consomem.

F1 de campo é a média harmónica de precisão e recall sobre os valores de campo extraídos (empresa, data, endereço, total no SROIE): um campo é uma unidade binária — corresponde ou falha. A coluna regex aplica o mesmo conjunto fixo de padrões ao texto de cada motor, portanto a única variável é a saída do motor. A tabela abaixo empareja o CER de cada motor com seu F1 de campo regex nos mesmos 361 recibos, com o ranking de cada motor sob ambas métricas.

Fonte: summary_metrics.csv — colunas cer e field_f1_regex, linhas sroie_2019 (361 muestras por motor, error_rate 0,0 para todos os 8). As duas séries não são comparáveis entre si como magnitudes (unidades diferentes), mas seus rankings discordam, que é o ponto.

Tabela: summary_metrics.csv — colunas cer / wer / field_f1_regex, linhas sroie_2019. Classificações calculadas dentro das 8 linhas desta tabela (1 = melhor nessa métrica: menor CER, maior F1 de campo). Estas são métricas postprocessed_sroie_receipt_regex_*: padrões fixos aplicados ao texto de OCR de cada mecanismo, não saída estruturada nativa. O Tesseract foi executado apenas em CPU (compute_type=cpu).

Leia os dois pares de inversão explicitamente. Unlimited-OCR: pior CER (0,6552), melhor F1 de campo (0,3376) — o mecanismo que a métrica de OCR bruto classifica por último é o que a lente de campo classifica em primeiro. docTR: 2º melhor CER (0,1971), pior F1 de campo (0,0766) — texto perfeito, falha em campo. PaddleOCR-VL também inverte na margem (rank 6 em CER, rank 2 em campo), enquanto as duas linhas alinhadas (PaddleOCR 3º/3º, Tesseract 5º/5º) são ambos mecanismos tradicionais cuja convenção de saída de texto bruto é exatamente o que o CER foi projetado para pontuar. Classifique os mecanismos apenas por CER e você obtém um vencedor diferente do que classificar pelo que a produção consome — a inversão é a demonstração, não uma anomalia.

A Métrica de Campo é a Lente Confiável Entre Famílias

Execute o texto bruto de cada mecanismo pelo mesmo pós-processador de extração de campos LLM (deepseek-v4-flash, temperatura 0) e os seis mecanismos com texto OCR utilizável convergem para 0,57–0,62 de F1 de campo — a fronteira entre famílias VLM vs. tradicional que o ranking CER faz parecer enorme (0,19 a 0,66) quase desaparece. Dois mecanismos ficam abaixo da faixa: EasyOCR em 0,3717 e Tesseract em 0,4389. A métrica de campo separa os mecanismos pelo que realmente importa — a recuperação de campos a jusante — e o faz de forma consistente através da fronteira entre famílias.

Este é o mesmo conjunto de mecanismos da tabela CER acima, reavaliado apenas na dimensão de campo: a inversão CER entre Unlimited-OCR e docTR desaparece, porque a recuperação de valores de campo é o que o pipeline consome. O mecanismo é que o pós-processador absorve as diferenças de convenção de saída que o CER punia — ele lê o texto com normalização de caixa e rótulos fundidos e extrai os valores. O F1 de campo LLM aqui é a coluna llm_field_value_f1 da comparação de métodos do benchmark, com o modelo LLM registrado por linha.

Tabela: field_method_comparison.csv — columna llm_field_value_f1, linhas sroie_2019, llm_model=deepseek-v4-flash. Columna CER repetida de summary_metrics.csv apenas para referência cruzada. A “banda de convergencia” é o intervalo observado de 0,5685–0,6171 dos seis motores com texto utilizável; as duas linhas abaixo da banda são apresentadas como observações, não como uma classificação dos motores.

CORD Adiciona uma Segunda Camada de Inflação: Estrutura do Texto de Referência

O texto de referência publicado do CORD (gt_text) incorpora estrutura de anotação — rótulos de campo, entradas de menu e coordenadas — em vez de texto visível puro. O CER calcula a distância de edição em relação a essa string estruturalmente aumentada, então o CER do CORD de cada mecanismo é sistematicamente inflado antes mesmo de qualquer erro de leitura ser considerado. O resultado: todos os oito mecanismos se agrupam em CORD CER 0.90–1.08 — uma faixa inutilmente comprimida que quase nada diz sobre a qualidade do texto.

O artefato extremo é o CORD CER do PaddleOCR-VL de 1.0805, o pior entre os 8 mecanismos — não uma leitura da qualidade do texto, mas a inflação estrutural trabalhando mais contra a saída mais limpa e mais curta, que tem a maior distância de edição relativa ao texto de referência repleto de estrutura do CORD. Na lente de campo, o mesmo mecanismo registra o melhor F1 de campo regex do CORD (0.3412) do benchmark. O CORD CER é estruturalmente inutilizável; as métricas de campo são a única lente justa do CORD, e são mantidas estritamente separadas de qualquer classificação SROIE neste benchmark (idioma diferente — indonésio — e estrutura de texto de referência diferente).

Fonte: summary_metrics.csv — colunas cer e field_f1_regex, linhas cord_v2 (100 amostras por mecanismo). O CORD CER não é comparável entre famílias ou mesmo entre mecanismos — o texto de referência incorpora estrutura de anotação, então o CER mede a distância até uma string estruturalmente aumentada, não até o texto visível.

Tabela: summary_metrics.csv — colunas cer / field_f1_regex, linhas cord_v2. CORD não é mesclado em nenhum ranking SROIE (regra do protocolo): a estrutura do texto de referência infla o CER de todos os mecanismos, e os padrões regex foram escritos para formatos em inglês. As métricas de campo são a única lente justa para CORD. Ordenado por F1 de campo, não por CER — o ponto é que a coluna CER não carrega sinal de ordenação.

A lente de campo inverte completamente a tabela CORD. O mecanismo com o pior CER CORD do benchmark (PaddleOCR-VL, 1.0805) tem o melhor F1 de campo CORD (0.3412); o F1 de campo CORD do docTR é literalmente 0.0000 — nada extraído — enquanto seu CER CORD (0.9101) fica no meio do cluster e não diz nada sobre isso. No CORD, publicar CER sem os números de campo não é apenas pouco informativo; ativamente classifica os mecanismos na ordem errada.

Quando a CER é Realmente a Métrica Certa

A CER ainda mede algo real — reprodução exata de caracteres — e é a métrica certa sempre que o consumidor downstream precisar de texto verbatim, não de campos. A conclusão desta página é “a CER engana na comparação entre famílias de saídas estilo VLM,” não “a CER está sempre errada.”

• Dentro da família raw-OCR, a CER mantém seu valor. Motores tradicionais emitem texto bruto com caixa e layout preservados, então a CER mede qualidade real de leitura: a coluna de CER dos motores tradicionais neste benchmark (0.1971–0.3347 no SROIE) acompanha o desempenho de campo muito mais de perto do que para os VLMs (correlação de rank com F1 de campo via regex: PaddleOCR e Tesseract estão exatamente alinhados em 3º/3º e 5º/5º).
• Casos de uso de texto verbatim. Consumidores downstream que exigem correspondência exata — busca em texto completo que precisa encontrar uma string literal, trilhas de auditoria que reproduzem os caracteres de um documento, ou verificações de aprovação/reprovação contra uma sequência de caracteres obrigatória — consomem caracteres, não campos. Para esses casos, a reprodução exata de caracteres (CER) é a medida fiel e o F1 de campo é a lente errada.
• Regra prática para publicação. Ao publicar um número de CER, informe tanto a convenção de saída do motor (ele normaliza caixa? funde rótulos? reordena linhas?) quanto a construção do texto de referência (texto visível puro, ou anotação aumentada como o gt_text do CORD). Se qualquer um for desconhecido, o número não é portável entre motores ou conjuntos de dados.
• A regra de fronteira deste benchmark. A CER é justa dentro da família raw-OCR e injusta na fronteira OCR-tradicional / VLM de parsing de documentos; o F1 em nível de campo (regex ou pós-processado por LLM) é justo em ambas. Use a CER para qualidade de texto bruto na mesma família, e o F1 de campo para comparação entre famílias — e sempre reporte a ressalva de decomposição para linhas de VLM.

Perguntas Frequentes

Por que o CER é enganoso ao comparar mecanismos de OCR e VLMs?

Porque o CER é uma pontuação de distância de edição de caracteres exata, e VLMs de parsing de documentos deliberadamente não reproduzem caracteres exatamente — eles normalizam caixa, fundem linhas de rótulo/valor e reordenam texto. Cada uma dessas normalizações é pontuada como erro, mesmo quando o valor do campo está correto. Neste benchmark, o Unlimited-OCR obtém o pior CER SROIE (0,6552) enquanto tem o melhor F1 de campo regex (0,3376) nos mesmos 361 recibos (summary_metrics.csv, linha cer / field_f1_regex, unlimited_ocr/sroie_2019) — a classificação por CER e a classificação por campo escolhem vencedores diferentes.

O CER ainda é uma métrica de OCR útil?

Sim — dentro da família de OCR bruto e para consumidores de texto verbatim. Mecanismos tradicionais (Tesseract, PaddleOCR, EasyOCR, docTR) produzem fluxos de caracteres brutos que o CER mede de forma justa: neste benchmark, o CER SROIE deles varia de 0,1971 a 0,3347 e acompanha o desempenho de campo (PaddleOCR 3º/3º, Tesseract 5º/5º em CER e F1 de campo). O CER é a métrica errada quando o mecanismo normaliza sua saída (estilo VLM) ou quando o texto de referência incorpora estrutura em vez de texto visível (CORD).

Por que os modelos de OCR VLM têm altas taxas de erro de caracteres?

Principalmente por convenção de saída, não por capacidade de leitura. A análise de protocolo do benchmark atribui aproximadamente ~18% do orçamento de CER SROIE de um VLM a substituições de caixa e ~10% a fusões de linha/separadores removidos (estimativa derivada do protocolo das notas de análise do benchmark, não uma coluna CSV) — enquanto os valores dos campos em si estão corretos. O CER 0,6552 vs WER 0,4779 do Unlimited-OCR mostra a assinatura: caracteres são normalizados, palavras sobrevivem (summary_metrics.csv, linha cer / wer, unlimited_ocr/sroie_2019).

Qual é a melhor métrica para comparar mecanismos de OCR e VLMs de parsing de documentos?

F1 de campo — com pós-processamento por regex para um pipeline de OCR bruto, e pós-processamento por LLM para qualquer uma das famílias. No SROIE, o F1 de campo via LLM converge seis mecanismos para 0,57–0,62 independentemente da família (field_method_comparison.csv, llm_field_value_f1, linhas sroie_2019), e o F1 de campo via regex é a única lente que classifica a tabela CORD de forma sensata, onde o 0,3412 do PaddleOCR-VL é o melhor do benchmark (summary_metrics.csv, field_f1_regex, linhas cord_v2). Sempre informe o pós-processador e a convenção de saída junto com o número.

Por que o CER do PaddleOCR-VL é tão alto no CORD, mas o F1 de campo é o melhor?

Porque o texto de referência do CORD incorpora estrutura de anotação (rótulos de campo, coordenadas, entradas de menu) em vez de texto visível puro, e a saída do PaddleOCR-VL é a mais limpa — mais curta e mais normalizada — então sua distância de edição em relação a essa string estruturalmente aumentada é a maior (CER 1,0805, o pior de 8). Na lente de campo, o mesmo texto extrai campos de recibos indonésios com F1 de campo de 0,3412, o melhor do benchmark (summary_metrics.csv, cer / field_f1_regex, linha paddleocr_vl_vllm/cord_v2). O CER do CORD é estruturalmente inutilizável para todos os mecanismos; as métricas de campo são a única comparação justa para o CORD.

O que é normalização de caixa e por que ela infla o CER?

Normalização de caixa é padronizar todo o texto para uma única caixa — TAN CHAY YEE vira tan chay yee. O CER compara caracteres exatamente, então cada letra normalizada é uma substituição em relação ao texto de referência em maiúsculas, mesmo que o valor seja idêntico. Na análise de protocolo deste benchmark, as substituições de caixa respondem por aproximadamente ~18% do orçamento de CER de um VLM no SROIE (estimativa derivada do protocolo) — por isso um VLM pode ler um recibo perfeitamente e ainda assim reportar um CER que parece de um modelo reprovado.

Devo comparar motores de OCR por CER ou por F1 de campo?

Por F1 de campo para qualquer comparação que envolva tanto motores de OCR tradicionais como VLM — porque seu pipeline consome campos, não fluxos de caracteres, e porque o CER fica sistematicamente inflado para saída VLM normalizada e texto de referência aumentado por estrutura. Use CER apenas dentro da família de OCR bruto ou quando o consumidor downstream precisar de texto verbatim (busca, auditoria, correspondência exata). As duas métricas discordam fortemente neste benchmark: CER classifica docTR 2º e Unlimited-OCR 8º; F1 de campo por regex classifica docTR 8º e Unlimited-OCR 1º (summary_metrics.csv, linhas sroie_2019).

De onde vienen estes números de CER e F1 de campo?

Cada número de tabela é uma linha do results/summary_metrics.csv ou results/field_method_comparison.csv publicados pelo benchmark de primeira parte, hospedados em ImageToTableai/benchmark-ocr, com um manifest.json editado por execução que registra versões de modelo e fingerprints de ambiente. A decomposição CER de ~76%/~18%/~10% é uma estimativa derivada do protocolo, a partir das notas de análise do benchmark, explicitamente não uma coluna CSV. As definições de dataset vienen dos artículos SROIE e CORD citados abaixo.

Metodología & Fuentes

Protocolo

Esta página informa la dimensión de equidad de métricas de una ejecución de benchmark independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros. Solo divisiones de prueba fijas: prueba SROIE 2019 (361 recibos en inglés, campos planos company/date/address/total, CC-BY-4.0) y prueba CORD v2 (100 recibos en indonesio, campos anidados menu/sub_total/total, CC-BY-4.0); las divisiones de entrenamiento nunca se evaluaron. Ocho motores se ejecutaron listos para usar, sin ajuste fino, bajo el protocolo congelado reports/receipt_v1_official_protocol.md (calentado y luego puntuado, solo nivel oficial). Las 16 ejecuciones puntuadas se completaron con error_rate 0.0 (columna error_rate de summary_metrics.csv). Los datos se recopilaron en agosto de 2026.

Ambiente de Execução

• Hardware: todas as execuções de GPU em uma única NVIDIA RTX 4090 (24 GB); Tesseract foi executado só com CPU (compute_type=cpu) e está rotulado como tal em todas as tabelas.
• Motores e versões (por manifestos de execução): Tesseract 5.3.4, PaddleOCR 3.7.0, EasyOCR 1.7.2, docTR v1.0.1, Docling 2.119.0, Surya2 0.22.1, Unlimited-OCR servido por vLLM, PaddleOCR-VL 1.6.
• Pós-processadores de campo: F1 de campo por regex = padrões fixos sroie_receipt_regex/cord_receipt_regex aplicados ao texto de OCR de cada motor (pós-processado, não extração nativa); F1 de campo por LLM = deepseek-v4-flash (temperatura 0) lendo o mesmo texto (columna llm_model de field_method_comparison.csv).

Definições de Métricas

• Character Error Rate (CER): distância de edição de Levenshtein entre o texto reconhecido e o texto de referência — mínimo de inserções/eliminações/substituções dividido pela longitude do texto de referência (especificação de avaliação OCR-D). Menor é melhor. Mede apenas a reprodução exata de caracteres.
• Word Error Rate (WER): a mesma lógica de distância de edição em granularidade de palavra — uma palavra sobrevive a uma única substitução de caixa, portanto a divergência CER/WER revela normalização que altera caracteres sem romper palavras.
• F1 de valor de campo: média harmónica de precisão e recall sobre valores de campo extraídos; um campo corresponde apenas se é exatamente igual ao texto de referência. As colunas regex e LLM são dois pós-processadores sobre o mesmo texto de OCR, nunca misturados.
• Convenção de saída: como um motor formata seu texto (caixa, separadores, ordem de linhas). Motores tradicionais preservam; VLMs de análise de documentos normalizam — o eixo que esta página mede.
• Estrutura do texto de referência: se o texto de referência é texto visível puro (SROIE) ou aumentado com estrutura de anotação (CORD gt_text), o que infla o CER para todos os motores.

Lista de Fontes

1. summary_metrics.csv (GitHub raw). 16 linhas = 8 mecanismos × 2 conjuntos de dados de recibos. As colunas incluem cer, wer, field_f1_regex, field_acc_regex, compute_type, error_rate. Todos os valores de CER/WER e F1 de campo por regex nesta página têm origem em uma linha deste arquivo, citados no nível de arquivo/modelo/conjunto de dados/métrica.
2. field_method_comparison.csv (GitHub raw). Extração de campos por regex vs. LLM lado a lado (llm_field_value_f1, llm_model=deepseek-v4-flash). Fonte para a tabela de F1 de campos por LLM.
3. Repositório ImageToTableai/benchmark-ocr. Repositório público que hospeda os CSVs de resultados, manifestos de execução redigidos, o protocolo congelado (reports/receipt_v1_official_protocol.md) e listas de amostras fixas para reprodução.
4. results/manifests/ (GitHub). Um manifest.json redigido por execução publicada, com versões de modelo, impressões digitais de ambiente e hashes de artefatos.
5. receipt_v1_official_protocol.md. O contrato de execução congelado: divisões de teste fixas, camada oficial, medição com aquecimento antes da pontuação, regras de separação CORD vs. SROIE. Fonte para as regras de nível de protocolo citadas nesta página.
6. Notas de análise do protocolo de benchmark (documentação interna de execução, WRITING_BRIEF §8.2/§8.3). O mecanismo de normalização do VLM (normalização de caixa, fusão rótulo/valor, reordenação de linhas), o mecanismo de estrutura do texto de referência do CORD e a decomposição do CER do SROIE (~76% idêntico / ~18% caixa / ~10% fusão de linhas). Citado aqui com o rótulo explícito “estimativa derivada do protocolo — não é uma coluna do CSV”; a divisão é direcional, não precisa.
7. Projeto OCR-D — Especificação de Garantia de Qualidade. Definição formal de CER (inserções + exclusões + substituições) / total de caracteres e o análogo de WER. Âncora formal de definição.
8. Huang et al., “ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction” (2019). Definição do conjunto de dados SROIE 2019, estrutura de tarefas, licença (CC-BY-4.0).
9. Park et al., “CORD: A Consolidated Receipt Dataset for Post-OCR Parsing” (2020). Definição do conjunto de dados CORD, esquema de campos aninhados, licença (CC-BY-4.0).

Limitações

• Os valores de decomposição são estimativas derivadas do protocolo, não medições: a decomposição de CER SROIE de ~76%/~18%/~10% vem das notas de análise do protocolo do benchmark (WRITING_BRIEF §8.2), não de uma coluna CSV. A direção (normalização, não erro de leitura, domina o CER de VLM) é robusta; as porcentagens exatas devem ser tratadas como estimativas direcionais, não como medições pontuais.
• Apenas recibos: recibos SROIE (inglês) e CORD (indonésio). O comportamento em faturas, formulários, tabelas ou documentos longos não foi medido; o mecanismo se generaliza, os números não.
• Pós-processador LLM único: todos os valores de F1 de campo com LLM usam deepseek-v4-flash a temperatura 0. Um LLM diferente altera os valores absolutos de F1 e possivelmente a faixa de convergência; a ordenação entre famílias dentro da faixa é o sinal estável.
• CER ainda válido para casos de texto verbatim: a conclusão se limita à comparação entre famílias de saídas estilo VLM. Para comparação de mesma família com OCR bruto e consumidores downstream que exigem caracteres exatos (busca, auditoria), o CER continua sendo uma métrica legítima — esta página não é um argumento contra o CER nesses contextos.
• CORD não incorporado aos rankings SROIE: idioma diferente, estrutura de texto de referência diferente. O CORD é comparado apenas em métricas de campo, conforme o protocolo do benchmark.
• Versão e hardware fixados: os números valem para as versões de modelo de agosto de 2026 e um nível de GPU (RTX 4090) listados acima. Lançamentos mais recentes alteram o CER e o F1 de campo; diferenças de poucos pontos percentuais devem ser tratadas como ruído.
• Tamanho da amostra: 361 + 100 amostras; os intervalos de confiança bootstrap são relatados na saída de avaliação do benchmark, mas não são reproduzidos linha por linha nesta página.

Referências relacionadas: Precisão em nível de campo vs. nível de caractere (definição) · OCR tradicional vs. VLMs de parsing de documentos · Regex vs. extração de campos com LLM · PaddleOCR vs. EasyOCR em recibos · Surya2 vs. Unlimited-OCR vs. PaddleOCR-VL · Benchmark de latência de OCR · Custo de OCR por 1.000 páginas

Leitura relacionada: por que a precisão de OCR com IA diverge do OCR tradicional · extração com IA a partir de imagens versus pipelines tradicionais de OCR