OCR tradicional vs VLMs de análise de documentos
Resultados do Benchmark de Recibos (2026)

Precisão de Caracteres por Modelo no SROIE (Recibos em Inglês)

Fonte: summary_metrics.csv — coluna cer, linhas sroie_2019 (8 linhas). Surya2 0,1915, docTR 0,1971, PaddleOCR 0,2045, EasyOCR 0,2833, Tesseract 0,3347, PaddleOCR-VL 0,3370, Docling 0,5909, Unlimited-OCR 0,6552. Menor é melhor. Tesseract é somente CPU.

Tabela: summary_metrics.csv — colunas cer e wer, linhas sroie_2019, 361 amostras cada (error_rate 0.0 para todos os 8 modelos). CER = taxa de erro de caracteres, WER = taxa de erro de palavras; quanto menor, melhor. Valores exatos: Surya2 cer 0.19147 / wer 0.27352; docTR cer 0.19707 / wer 0.31990.

A taxa de erro de palavras conta a mesma história com uma granularidade diferente: ela pontua erros de palavras inteiras em vez de caracteres. Surya2 lidera em WER com 0.274, docTR vem em seguida com 0.320. Observe o caso atípico na parte inferior: Unlimited-OCR tem o pior CER (0.655), mas um WER mediano (0.478) — sua saída é fortemente normalizada em maiúsculas/minúsculas e formato (uma convenção de saída discutida na seção de metodologia), o que infla as edições em nível de caractere mesmo quando as palavras estão em grande parte intactas.

O Docling merece uma nota de classificação antes de aparecer em comparações: ele não é um motor de OCR tradicional puro nem um VLM. O Docling é um analisador por pipeline — uma ferramenta em etapas que executa análise de layout, detecção de tabelas e reconstrução da ordem de leitura em torno de um núcleo de OCR. Em um recibo simples, essa sobrecarga de pipeline agrega pouco, o que explica em parte por que seu CER bruto (0,591 no SROIE) fica atrás dos motores de passagem única.

Custo e Latência: A Vantagem dos Motores Tradicionais

Se a precisão de caracteres não decide nada entre as duas famílias, custo e latência decidem quase tudo. Na mesma divisão de teste, o docTR sustenta 449 páginas/min a 108,7 ms p50 por página por $0,048 por 1.000 páginas; o Surya2 sustenta 12 páginas/min a 2.668 ms p50 por $1,061 por 1.000 páginas — aproximadamente 37× o throughput, 24,5× a latência por página e 22× o custo por mil páginas.

O custo é calculado como tempo de execução × a taxa do RTX 4090 da RunPod ($0,76/hora, preço com registro de data e hora nos manifestos de execução) — o preço que você realmente pagaria pelo tempo de GPU, incluindo a inicialização do modelo. O Tesseract é o caso especial: somente CPU, não tem custo de GPU e ainda gerencia 78,6 páginas/min no SROIE; sua célula de custo está vazia no CSV por design, não porque é gratuito, mas porque não consome horas de GPU cobradas.

Fonte: summary_metrics.csv — coluna latency_p50_ms, linhas sroie_2019. docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9 (CPU), PaddleOCR-VL 694,3, Docling 732,0, Unlimited-OCR 1600,7, Surya2 2668,0. Latência em estado estável, modo de medição aquecido e pontuado (exclui carregamento do modelo).

Fonte: summary_metrics.csv — coluna cost_per_1000_pages, linhas sroie_2019. docTR 0,0479, EasyOCR 0,1098, PaddleOCR-VL 0,2048, PaddleOCR 0,2214, Unlimited-OCR 0,3879, Docling 0,3978, Surya2 1,0609. Tesseract somente CPU: célula vazia no CSV (sem custo de GPU); o custo inclui inicialização do modelo, não apenas throughput em estado estável.

Tabela: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, linhas sroie_2019. Execuções em GPU na RTX 4090 ($0,76/h, preço com timestamp nos manifests); Tesseract rodou apenas em CPU (célula de custo vazia, não zero). Throughput é páginas/min em tempo real, incluindo inicialização do modelo.

A coluna de latência de cauda importa se você se preocupa com o pior caso, não apenas com medianas. O p95 de 3.331 ms do PaddleOCR e o de 3.240 ms do Docling estão muito distantes de seus p50 — efeitos de primeira página e picos de prefill dominam a cauda em engines de GPU — enquanto o p95 do docTR (281 ms) permanece estável. Para cargas interativas (um usuário esperando uma página), essa dispersão do p95 é a diferença entre uma espera de 0,3 segundo e uma de mais de 3 segundos.

CORD (Recibos Indonésios): Incompatibilidade de Idioma e Inflação do Ground-Truth

CORD v2 é um conjunto de dados de recibos em indonésio com campos aninhados (menu, sub_total, total). Nenhum dos 8 mecanismos foi treinado predominantemente em recibos indonésios, então o CORD funciona como um teste de estresse entre idiomas — e o CER de todos os mecanismos colapsa para 0.90–1.08. Esses números devem ser lidos com a ressalva de que o texto ground-truth do CORD incorpora a estrutura de anotação, o que infla o CER bruto para todos os mecanismos; os resultados do CORD são mantidos estritamente separados do ranking SROIE e não podem ser mesclados em um único leaderboard.

Duas forças distintas empurram o CER do CORD para 1.0, e apenas uma delas é o idioma em si. Primeiro, o idioma: mecanismos treinados em inglês realmente leem mal palavras indonésias — nomes indonésios, endereços e formatos de moeda (Rp) estão fora de suas distribuições de treinamento. Segundo, o ground-truth: as anotações de texto publicadas do CORD incorporam a estrutura de anotação (rótulos de campos com coordenadas) em vez de texto visível puro, então o CER bruto mede a distância de edição contra uma string estruturalmente aumentada. Os exemplos VLM mais limpos são penalizados com mais força — PaddleOCR-VL com CER 1.080 é o artefato extremo desse mecanismo, não uma leitura da qualidade do seu texto.

A comparação justa entre famílias no CORD é, portanto, a métrica de campo, não o CER (veja a próxima seção). O que as colunas de CER ainda mostram utilmente é que a incompatibilidade de idioma é real e universal entre arquiteturas — todas as famílias, tradicionais e VLM, caem na mesma faixa de 0.90–1.08, sem vantagem estrutural para nenhuma.

Tabela: summary_metrics.csv — coluna cer, linhas cord_v2, 100 amostras cada. Não compare esses números com o SROIE em um ranking combinado: o CORD CER combina incompatibilidade linguística real com inflação da estrutura de anotação no ground truth (metodologia abaixo). Um CER acima de 1.0 (PaddleOCR-VL 1.0805) é um artefato de distância de edição desse ground truth inflado.

Campo F1: Pós-processamento com LLM Converge o Campo

A precisão de caracteres classifica os mecanismos; a extração de campos é o que os usuários de produção realmente pagam. O benchmark extrai quatro campos do recibo (empresa, data, endereço, total) do texto OCR de cada mecanismo usando dois pós-processadores — padrões regex fixos (a abordagem tradicional de OCR + KIE baseado em regras) e um LLM (deepseek-v4-flash) com um prompt estruturado. O resultado: o LLM quase elimina a diferença entre mecanismos no SROIE, colocando seis dos oito mecanismos em uma faixa de F1 de campo de 0,57–0,62 — enquanto seus resultados com regex estavam distribuídos em uma faixa de 0,26 ponto.

O F1 de valor de campo é a média harmônica de precisão e recall sobre os valores de campo extraídos, pontuada contra o ground truth — 1,0 significa que todo valor de campo foi perfeitamente extraído, 0 significa que nada foi recuperado. As colunas de regex usam um conjunto fixo de padrões por conjunto de dados; as colunas de LLM usam deepseek-v4-flash com temperatura 0 para saída determinística (coluna llm_model no CSV de comparação). As duas métricas medem pipelines diferentes e nunca são combinadas.

Fonte: field_method_comparison.csv — colunas regex_field_value_f1 / llm_field_value_f1, linhas sroie_2019 (decimais 0–1 armazenados mostrados como %). Pós-processador LLM: deepseek-v4-flash (coluna llm_model). 361 amostras por mecanismo (llm_ok_count).

Tabela: field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1, linhas sroie_2019. LLM = pós-processamento deepseek-v4-flash (columna llm_model). docTR regex 0.0766 → LLM 0.6171 (8,1× de melhora); os 6 motores não atrasados variam de 0.5685–0.6171.

Dois resultados contraintuitivos vivem nesta tabela. Primeiro, docTR tem o peor F1 de campo regex em SROIE (0.077) e o melhor F1 de campo LLM (0.617) — o mesmo texto OCR limpo que o regex extraiu em 7,7% dos campos rendeu 61,7% sob o LLM. O pós-processador, não o OCR, era o gargalo. Segundo, os dois motores que ficam fora da banda 0.57–0.62 são exatamente os dois com bases OCR degradadas: EasyOCR (0.372, CER SROIE 0.283) e Tesseract — cujo resultado CORD (F1 de campo LLM 0.163) mostra que um LLM não pode extrair campos de texto que fundamentalmente não consegue ler (CER CORD 0.9523). O teto de qualquer pós-processador é a qualidade da base OCR debajo dele.

No CORD, o LLM também absorbe parte do choque linguístico: o F1 de campo do LLM se mantiene em 0,47–0,55 para os motores saudáveis (PaddleOCR 0,553, docTR 0,550, PaddleOCR-VL 0,520, Surya2 0,520) mesmo quando o regex colapsa a quase zero (docTR 0,0, EasyOCR 0,7%) — os padrões foram escritos para formatos em inglês, e a penalidade de "um idioma a mais" é paga quase inteiramente pelas regras, não pelo LLM (field_method_comparison.csv, llm_field_value_f1 / regex_field_value_f1, linhas cord_v2).

Por que o CER Subestima os VLMs de Análise de Documentos

O CER compara a saída do VLM e a verdade de base caractere por caractere, e os VLMs são penalizados por dois comportamentos legítimos que não são erros de reconhecimento: normalização de maiúsculas/minúsculas e fusão de rótulo/valor. A decomposição de CER do benchmark no SROIE atribuye aproximadamente 18% do CER do VLM a diferenças de formato de maiúsculas/minúsculas (por exemplo, TAN CHAY YEE → tan chay yee) e aproximadamente 10% à fusão de linhas ou à omisión de linhas separadoras — com os próprios valores de campo (empresa, total, data) estando corretos (análise de decomposição de CER registrada nas notas de protocolo do benchmark, execuções SROIE).

A tensão de design é real e estrutural: os motores de OCR tradicionais producen texto bruto com maiúsculas/minúsculas intactas, portanto são otimizados por design para a pontuação CER; os VLMs de análise de documentos producen texto "comprendido" (maiúsculas/minúsculas normalizadas, pares rótulo-valor fundidos, linhas reordenadas), que está mais próximo do que um sistema downstream deseja, mas mais distante de correspondências exatas de caracteres. É por isso que o título da página usa CER somente onde é uma comparação justa entre saídas semelhantes, e por que a comparação justa entre famílias vive nas métricas de campo — e por que o CER do CORD (que adicionalmente sofre de inflação da estrutura de anotação) fica confinado à sua própria seção. O ponto mais amplo: uma diferença de CER entre famílias não é automaticamente uma diferença de precisão, e qualquer pessoa que compare modelos entre famílias deve verificar o que o CER está medindo antes de concluir que uma família "lê melhor".

Como Escolher: Qual Eixo Importa para Sua Carga de Trabalho

"Melhor" não significa nada sem uma carga de trabalho. A conclusão honesta do benchmark é que as duas famílias vencem em eixos diferentes, e os recibos medem especificamente os eixos onde os mecanismos tradicionais vencem e os eixos onde o pós-processamento — não a família do mecanismo — decide a qualidade dos campos.

A orientação de seleção é derivada diretamente das linhas de CSV citadas; é um auxílio de leitura orientado por dados, não um endosso de fornecedor. Seus resultados exatos variam com hardware, mix de documentos e versões de modelo.

Perguntas Frequentes

Os VLMs de análise de documentos são mais precisos que o OCR tradicional em recibos?

Não em precisão bruta de caracteres — o melhor VLM e o melhor mecanismo tradicional estão estatisticamente empatados no SROIE 2019 (Surya2 CER 0.191 vs docTR 0.197, linhas sroie_2019 do summary_metrics.csv), e o PaddleOCR (0.204) fica em terceiro. Quando o objetivo é extração de campos, com VLM ou não, o pós-processamento com LLM é o fator decisivo (faixa de convergência de 0.57–0.62, field_method_comparison.csv).

Quando o OCR tradicional faz mais sentido que um VLM de análise de documentos?

Quando o volume é alto, o custo é medido ou a latência é interativa. No SROIE, o docTR processou 449 páginas/min a $0.048 por 1.000 páginas e 108,7 ms p50; o Surya2 processou 12 páginas/min a $1.061 por 1.000 páginas e 2.668 ms p50 (summary_metrics.csv, linhas doctr e surya2 sroie_2019). Para uma espera interativa por página, a diferença é de 0,1 segundo vs 2,7 segundos.

Por que os VLMs de análise de documentos às vezes pontuam pior em CER que OCR barato?

Porque o CER mede correspondências exatas de caracteres, e os VLMs são penalizados por conversão de caixa e fusão de rótulo/valor que são convenções de saída, não erros de leitura. A decomposição de CER do benchmark no SROIE atribui cerca de 18% do CER dos VLMs a diferenças de formato de caixa e ~10% a fusão de linhas/separadores removidos — com os valores dos campos em si frequentemente corretos (veja Metodologia). O CER do CORD é adicionalmente inflado pela estrutura de anotação dentro do ground truth, por isso esta página isola o CER do CORD de qualquer ranking e usa métricas de campo para comparação entre famílias.

Quanto custa o OCR de recibos por página em uma RTX 4090?

Entre $0,048 (docTR) e $1,061 (Surya2) por 1.000 páginas em uma RTX 4090 a $0,76/hora, preço registrado em agosto de 2026 nos manifests de execução (summary_metrics.csv cost_per_1000_pages, linhas sroie_2019). O Tesseract é apenas CPU e não consome horas de GPU. O custo inclui a inicialização do modelo, então o custo por página diminui conforme o tamanho do lote aumenta.

Por que todos os modelos pontuam acima de 0,90 CER em recibos CORD?

Duas causas que se somam: incompatibilidade genuína de idioma (recibos indonésios fora do foco de treinamento de todos os mecanismos) e inflação da estrutura de anotação no texto de referência do CORD. Nenhuma família escapa disso — todos os 8 modelos ficam na faixa de 0,90–1,08 (summary_metrics.csv cer, linhas cord_v2). CORD é um conjunto de estresse de robustez de idioma/layout, mantido separado do ranking SROIE.

Um LLM vai simplesmente corrigir minha saída de OCR ruim?

Apenas até a qualidade do texto base. No SROIE, o LLM elevou seis mecanismos para uma faixa de F1 de campo de 0,57–0,62, independentemente do mecanismo (field_method_comparison.csv), mas o caso CORD do Tesseract mostra o limite: com CER 0,9523, seu F1 de campo com LLM é 0,163 — um LLM não consegue extrair campos de texto que não consegue ler.

Qual é o OCR mais rápido para recibos?

docTR neste benchmark: 108,7 ms p50 por página e 449 páginas/min no SROIE 2019 (summary_metrics.csv doctr/sroie_2019: latency_p50_ms, pages_per_minute). O mais lento testado, Surya2, foi 24,5× mais lento no p50 (2.668 ms) e 37× mais lento no throughput (12 páginas/min).

De onde vêm os números desta página?

Cada figura é uma linha dos CSVs publicados do benchmark de primeira parte — results/summary_metrics.csv (8 modelos × 2 conjuntos de dados: CER/WER, F1 de campo, latência, custo, throughput) e results/field_method_comparison.csv (regex vs pós-processamento com LLM) — hospedados em ImageToTableai/benchmark-ocr, com um manifest.json editado por execução para impressões digitais do ambiente. As definições dos conjuntos de dados vêm dos artigos SROIE 2019 e CORD citados abaixo.

Metodologia e Fontes

Protocolo

Esta página relata a comparação de parsing de documentos de uma execução de benchmark independente e reproduzível (nível oficial) — não uma pesquisa de alegações de terceiros. Apenas divisões de teste fixas: teste SROIE 2019 (361 recibos em inglês, campos planos company/date/address/total) e teste CORD v2 (100 recibos em indonésio, campos aninhados menu/sub_total/total); divisões de treino nunca foram avaliadas. Cada par (modelo × conjunto de dados) reutiliza as mesmas imagens, o mesmo ground truth e o mesmo protocolo de medição (warm_then_scored: uma passada de aquecimento fixa precede a passada avaliada, então as figuras de latência são de estado estacionário). Todas as 16 execuções foram concluídas com error_rate 0.0 (coluna error_rate em summary_metrics.csv).

Ambiente de Execução

• Hardware: todas as execuções de GPU em uma NVIDIA RTX 4090 (24 GB); custo de GPU calculado na tarifa on-demand da RunPod de $0.76/hr, com o timestamp do preço registrado no manifesto editado de cada execução (agosto de 2026). O Tesseract rodou somente em CPU e não tem custo de GPU (célula de custo vazia no CSV).
• Mecanismos: todos os modelos rodam prontos para uso, sem fine-tuning. Versões fixadas conforme os manifestos de execução.
• Pós-processador LLM: deepseek-v4-flash via API com temperatura 0 para saída determinística (coluna llm_model em field_method_comparison.csv); foi o único modelo usado para todas as linhas de campos LLM.
• Base de custo: tempo de execução em wall-clock × $0.76/hr, incluindo inicialização do modelo — o processamento em lote reduz o custo por página.
• Pós-processamento de campos: as métricas de campos SROIE são postprocessed_sroie_receipt_regex_* / variantes LLM — ou seja, campos extraídos do texto do OCR por um conjunto fixo de regex ou pelo LLM. Elas medem OCR + extração downstream, não saída estruturada nativa dos modelos.

Versões conforme registradas na tabela de modelos do benchmark (README.md) e nos manifestos editados por execução (results/manifests/, um por execução publicada, 16 no total) — cada manifesto registra id da execução, versão do modelo, hash do script runner, GPU/driver, versões de torch/CUDA/Python, hash do pip-freeze, metadados de custo com timestamp do preço e hashes de artefatos para reprodutibilidade.

Definições de Métricas

• CER (Taxa de Erro de Caracteres): distância de edição (inserções + deleções + substituições) entre o texto do OCR e a verdade de campo, dividida pelos caracteres da verdade de campo. Quanto menor, melhor. Sensível a maiúsculas/minúsculas e convenções de formatação.
• WER (Taxa de Erro de Palavras): o mesmo cálculo de distância de edição em nível de palavra.
• F1 de valor de campo (regex): média harmônica de precisão/revocação sobre valores de campos extraídos usando padrões regex fixos no texto do OCR (pipeline tradicional de OCR + KIE baseado em regras). Coluna: regex_field_value_f1.
• F1 de valor de campo (LLM): a mesma métrica na saída do pós-processador LLM (texto do OCR → deepseek-v4-flash → campos). Coluna: llm_field_value_f1. Os dois pipelines são diferentes e nunca são combinados.
• Latência p50/p95 & páginas/min: tempo de inferência por página em estado estável (medido após aquecimento, exclui carregamento do modelo) e throughput em tempo real, incluindo inicialização do modelo.
• Custo por 1.000 páginas: horas de GPU cobradas para 1.000 páginas à taxa registrada de $0,76/hora; vazio para Tesseract somente em CPU.

Lista de Fontes

1. summary_metrics.csv (GitHub raw). 16 linhas = 8 modelos × 2 conjuntos de dados. Colunas: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Cada número de CER/WER, latência, custo e throughput nesta página remete a uma linha aqui.
2. field_method_comparison.csv (GitHub raw). 16 linhas; colunas model, dataset, llm_model (= deepseek-v4-flash), precisão e F1 de valor de campo regex/llm, document-fields-exact, llm_median_latency_ms, contagens de tokens. Cada número de F1 de campo regex/LLM remete a uma linha aqui.
3. Repositório ImageToTableai/benchmark-ocr. Repositório público que hospeda os CSVs de resultados, manifestos de execução editados, protocolo congelado e listas de amostras de conjuntos de dados (divisões de teste fixas) para reprodução.
4. results/manifests/ (GitHub). Um manifest.json editado por execução publicada (16 execuções) com a impressão digital do ambiente, versão do modelo, metadados de custo e hashes de artefatos.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definição do conjunto de dados SROIE 2019, estrutura de tarefas e licença (CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definição do conjunto de dados CORD v2, esquema de campos aninhados e licença (CC-BY-4.0).

Limitações

• Escopo do documento: Apenas recibos (SROIE + CORD). Este benchmark não mede nada sobre tratamento de layout/tabelas/formulários, documentos longos ou campos que não sejam de recibos — os tipos de documento onde os VLMs de análise de documentos afirmam suas maiores vantagens permanecem não medidos aqui. Não use esta página para concluir que "OCR tradicional é melhor em tudo."
• Tamanho da amostra: 361 recibos em inglês + 100 em indonésio. F1 de campo e CER dependem do corpus; diferenças de alguns centésimos devem ser tratadas como ruído, não como verdade de engenharia.
• Nível de GPU único: todos os números de GPU vêm de uma RTX 4090 a $0,76/hora. Outras GPUs, servindo com múltiplas GPUs ou agendamento em lote alterarão latência, throughput e custo.
• Assimetria CPU/GPU: Tesseract (CPU) é comparado a motores acelerados por GPU; sua latência/tempo reflete hardware de CPU, enquanto sua vantagem de custo reflete ausência de cobrança de GPU. Isso está marcado em todas as tabelas relevantes, mas a assimetria é inerente à comparação.
• O pós-processador LLM é um único modelo: todas as linhas de campos com LLM usam deepseek-v4-flash. Um LLM diferente produziria F1 absoluto diferente; a ordem de convergência pode mudar nas margens. A latência do LLM (~1,8–2,4 s mediana, field_method_comparison.csv llm_median_latency_ms) é incorrida via API e não faz parte da latência do motor de OCR.
• Registro de custo: o preço de GPU de $0,76/hora foi registrado nos manifests de execução em agosto de 2026. Os preços spot/sob demanda de GPU mudam; recalcule os custos às tarifas atuais antes de orçar.
• CER de CORD não é uma leitura de qualidade: o ground truth de CORD incorpora estrutura de anotação e os motores não foram treinados em indonésio. O CER de CORD (0,90–1,08 em todos os 8 modelos) reflete incompatibilidade linguística + inflação do ground truth, não a qualidade de leitura por modelo; as linhas de CORD não são intencionalmente mescladas em nenhum ranking de SROIE.
• Ajuste de regex: o conjunto de padrões regex foi escrito uma vez por conjunto de dados. Uma biblioteca de padrões ajustada por fornecedor poderia pontuar mais alto em seus próprios formatos — ao custo de manutenção que o LLM elimina.
• Sem modelos em nuvem/API: AWS Textract, Google Document AI, Azure AI Document Intelligence e APIs VLM hospedadas (ex.: serviços de OCR em nuvem) não estão incluídos; seus modelos de latência e preço diferem fundamentalmente dos motores locais medidos aqui.
• Fixação de versão: os resultados valem para as versões de modelo de agosto de 2026 listadas acima; lançamentos mais recentes de qualquer motor podem alterar os resultados, e as latências p50 das duas medições com grandes picos de p95 (PaddleOCR, Docling) refletem efeitos de prefill/primeira página sob o padrão de lote desta execução.

Referências relacionadas: os limites do regex para extração de campos · precisão em nível de campo e de caractere comparadas · Precisão de OCR de Recibos · dados de precisão de OCR por tipo de documento

Leitura relacionada: precisão de OCR de IA vs OCR clássico · como a extração por visão de IA lê imagens de forma diferente do OCR · Preços de Extração de Documentos com IA (2026)