Por que o CER Engana em Modelos de Linguagem Visual para Análise de Documentos
Quantificado com Dados de Benchmark Primeira Parte (2026)

Última revisão: 2026-08-18 · Nível de execução: oficial · Benchmark primeira parte · 8 engines × 2 conjuntos de dados de recibos

Declaração de escopo: Mecanismo ilustrado em recibos (SROIE 2019 inglês, 361 amostras de teste; CORD v2 indonésio, 100 amostras de teste) usando os dados de benchmark primeira parte. A decomposição CER de ~76%/~18%/~10% é uma estimativa derivada da nota do protocolo, não uma coluna CSV. O CORD nunca é mesclado na classificação do SROIE — idioma diferente, estrutura de texto de referência diferente.

A Character Error Rate é um algoritmo de correspondência exata de caracteres, não um medidor de qualidade: ela cobra um erro para cada caractere que difere do texto de referência. Neste benchmark, essa convenção de pontuação sozinha — antes de qualquer leitura incorreta real — move engines entre o topo e o fundo da classificação: o Unlimited-OCR pontua o pior CER (0.6552) e o melhor F1 de campo com regex (0.3376) nos mesmos 361 recibos SROIE, enquanto o docTR pontua o 2º melhor CER (0.1971) e o pior F1 de campo (0.0766).

Os três números que os escritores mais precisam: ~18% do orçamento de CER de um VLM no SROIE são apenas substituições de caixa (estimativa derivada do protocolo) — normalizar TAN CHAY YEE para tan chay yee é pontuado como erros, embora o valor do campo esteja correto; 1.0805, o CER do PaddleOCR-VL no CORD — o pior de todas as 8 engines, um artefato do texto de referência estruturado do CORD, enquanto seu F1 de campo no CORD de 0.3412 é o melhor do benchmark; e a inversão 0.6552 / 0.3376 (pior CER / melhor campo) que faz a classificação apenas por CER escolher o vencedor errado.

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

Tabela: summary_metrics.csv — colunas cer / field_f1_regex, linhas cord_v2. CORD não é incluído em nenhum ranking SROIE (regra do protocolo): a estrutura do texto de referência infla o CER para todos os motores, 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 traz sinal de ordenação.

A lente de campo inverte completamente a tabela CORD. O motor 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 grupo e não diz nada sobre ele. No CORD, publicar o CER sem os números de campo não é apenas não informativo; classifica ativamente os motores na ordem errada.

Quando o CER é Realmente a Métrica Correta

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

• Dentro da família de OCR bruto, o CER mantém seu valor. Motores tradicionais emitem texto bruto com caixa e layout preservados, então o CER mede a qualidade de leitura genuína: a coluna de CER do motor tradicional neste benchmark (0.1971–0.3347 no SROIE) acompanha seu desempenho em campos muito mais de perto do que para os VLMs (correlação de classificação com o F1 de campo por regex: PaddleOCR e Tesseract estão exatamente alinhados em 3º/3º e 5º/5º).
• Casos de uso para texto literal. Consumidores downstream de correspondência exata — busca em texto completo que deve 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, a reprodução exata de caracteres (CER) é a medida fiel e o F1 de campo é a lente errada.
• Regra de publicação. Ao publicar um número de CER, declare tanto a convenção de saída do motor (ele normaliza a 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 uma for desconhecida, o número não é portável entre motores ou conjuntos de dados.
• A regra de fronteira deste benchmark. O CER é justo dentro da família de OCR bruto e injusto na fronteira entre OCR tradicional / VLM de análise de documento; o F1 em nível de campo (pós-processado por regex ou LLM) é justo em ambos. Use o CER para qualidade de texto bruto na mesma família, o F1 de campo para comparação entre famílias — e sempre reporte a ressalva da decomposição para linhas de VLM.

Perguntas Frequentes

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

Porque o CER é uma pontuação de distância de edição de caracteres exatos, e os VLMs de análise de documentos deliberadamente não reproduzem caracteres exatamente — eles normalizam a caixa, fundem linhas de rótulo/valor e reordenam o texto. Cada uma dessas normalizadas é contabilizada como um erro, mesmo quando o valor do campo está correto. Neste benchmark, o Unlimited-OCR tem o pior CER no SROIE (0.6552) enquanto possui o melhor F1 de campo com regex (0.3376) nos mesmos 361 recibos (summary_metrics.csv, cer / field_f1_regex, unlimited_ocr/sroie_2019 row) — a classificação por CER e a classificação por campo escolhem vencedores diferentes.

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

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

Por que modelos VLM de OCR 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 no SROIE de um VLM a substituições de caixa e ~10% a fusões de linha/separadores omitidos (estimativa derivada do protocolo nas notas de análise do benchmark, não uma coluna do CSV) — enquanto os valores dos campos em si estão corretos. O CER de 0.6552 vs WER de 0.4779 do Unlimited-OCR mostra a assinatura: caracteres são normalizados, palavras sobrevivem (summary_metrics.csv, cer / wer, unlimited_ocr/sroie_2019 row).

Qual a melhor métrica para comparar motores de OCR e VLMs de análise de documentos?

F1 de campo — pós-processado com regex para um pipeline de OCR bruto, pós-processado com LLM para qualquer família. No SROIE, o F1 de campo com LLM converge seis motores para 0,57–0,62 independentemente da família (field_method_comparison.csv, llm_field_value_f1, sroie_2019 rows), e o F1 de campo com 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, cord_v2 rows). Sempre indique 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 seu F1 de campo é o melhor?

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

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

A normalização de caixa é normalizar todo o texto para uma única caixa — TAN CHAY YEE se torna 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 correspondem a aproximadamente ~18% do orçamento de CER de um VLM no SROIE (estimativa derivada do protocolo) — é por isso que um VLM pode ler um recibo perfeitamente e ainda relatar um CER que parece o de um modelo com falha.

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

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

De onde vêm esses 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 publicado pelo benchmark de primeira parte, hospedado em ImageToTableai/benchmark-ocr, com um manifest.json redatado por execução registrando versões do modelo e impressões digitais do ambiente. A decomposição de CER de ~76%/~18%/~10% é uma estimativa derivada do protocolo das notas de análise do benchmark, explicitamente não uma coluna CSV. As definições de conjunto de dados vêm dos artigos SROIE e CORD citados abaixo.

Metodologia & Fontes

Protocolo

Esta página relata a dimensão de equidade de métricas de uma execução de benchmark independente e reproduzível (nível oficial) — não um levantamento de alegações de terceiros. Apenas divisões de teste fixas: SROIE 2019 teste (361 recibos em inglês, campos planos empresa/data/endereço/total, CC-BY-4.0) e CORD v2 teste (100 recibos indonésios, campos aninhados menu/sub_total/total, CC-BY-4.0); divisões de treinamento nunca foram avaliadas. Oito motores rodaram fora da caixa, sem ajuste fino, sob o protocolo congelado reports/receipt_v1_official_protocol.md (aquecimento-para-pontuação, apenas nível oficial). Todas as 16 execuções pontuadas foram concluídas com error_rate 0.0 (coluna error_rate do summary_metrics.csv). Os dados foram coletados em agosto de 2026.

Ambiente de Execução

• Hardware: todas as execuções em GPU foram realizadas em uma única NVIDIA RTX 4090 (24 GB); Tesseract foi executado apenas em CPU (compute_type=cpu) e é rotulado como tal em todas as tabelas.
• Motores e versões (por manifesto 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 via 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 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 (coluna llm_model de field_method_comparison.csv).

Definições das Métricas

• Character Error Rate (CER): distância de edição Levenshtein entre o texto reconhecido e o texto de referência — mínimo de inserções/exclusões/substituições dividido pelo comprimento 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 substituição de caixa, então a divergência CER/WER revela normalização que altera caracteres sem quebrar palavras.
• F1 de valor de campo: média harmônica de precisão e recall sobre os valores dos campos extraídos; um campo corresponde apenas se for exatamente igual ao texto de referência. As colunas regex e LLM são dois pós-processadores sobre o mesmo texto OCR, nunca misturados.
• Convenção de saída: como um motor formata seu texto (caixa, separadores, ordem das linhas). Motores tradicionais preservam; VLMs de análise de documento 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 engines × 2 conjuntos de dados de recibos. Colunas incluem cer, wer, field_f1_regex, field_acc_regex, compute_type, error_rate. Todos os valores de CER/WER e F1 de campo regex nesta página são rastreados até uma linha aqui, citados no nível de arquivo/modelo/conjunto de dados/métrica.
2. field_method_comparison.csv (GitHub raw). Comparação lado a lado de extração de campos por Regex vs LLM (llm_field_value_f1, llm_model=deepseek-v4-flash). Fonte para a tabela de F1 de campo por LLM.
3. Repositório ImageToTableai/benchmark-ocr. Repositório público que hospeda os CSVs de resultados, manifestos de execução redatados, o protocolo congelado (reports/receipt_v1_official_protocol.md) e listas de amostras fixas para reprodução.
4. results/manifests/ (GitHub). Um manifesto.json redatado por execução publicada, com versões do modelo, impressões digitais do ambiente e hashes de artefatos.
5. receipt_v1_official_protocol.md. O contrato de execução congelado: divisões de teste fixas, nível oficial, medição aquecida-então-pontuada, 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 por VLM (normalização de caixa, fusão rótulo/valor, reordenação de linhas), o mecanismo da estrutura de texto de referência do CORD e a decomposição de 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 de 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 WER. Âncora definição formal.
8. Huang et al., “ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction” (2019). Definição do conjunto de dados SROIE 2019, estrutura da tarefa, 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 números de decomposição são estimativas derivadas do protocolo, não medições: a decomposição de CER do 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 leitura incorreta, domina o CER do VLM) é robusta; as porcentagens exatas devem ser tratadas como estimativas direcionais, não medições pontuais.
• Apenas recibos: recibos do 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 por LLM usam deepseek-v4-flash com temperatura 0. Um LLM diferente altera os valores absolutos de F1 e possivelmente a banda de convergência; a ordenação entre famílias dentro da banda é o sinal estável.
• CER ainda válido para casos de texto literal: a conclusão é delimitada à comparação entre famílias de saídas no estilo VLM. Para comparação dentro da mesma família de OCR bruto e consumidores downstream de 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 mesclado nos rankings do SROIE: idioma diferente, estrutura de texto de referência diferente. 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 uma camada de GPU (RTX 4090) listada acima. Versões mais recentes alteram o CER e o F1 de campo; diferenças de um dígito percentual devem ser tratadas como ruído.
• Tamanho da amostra: 361 + 100 amostras; intervalos de confiança por bootstrap são reportados na saída de avaliação do benchmark, mas não são reproduzidos linha por linha nesta página.

Referências relacionadas: Acurácia em Nível de Campo vs. Nível de Caractere (definição) · OCR Tradicional vs. VLMs de Análise de Documentos · Regex vs. Extração de Campo por 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

Leituras relacionadas: Acurácia de OCR por IA vs. OCR Tradicional · Extração de Dados de Imagem por IA vs. OCR Tradicional