EasyOCR vs docTR em Notas FiscaisCampeão de Velocidade vs Extrator de Campo (2026)

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

O que esta página cobre: Um benchmark direto, reproduzível, de primeira parte entre EasyOCR 1.7.2 (OCR clássico ResNet+CRNN+CTC com ampla cobertura de idiomas) e docTR v1.0.1 (OCR neural moderno de duas etapas: detecção por transformer estilo DETR + reconhecimento) — dois dos motores de OCR de aprendizado profundo de código aberto mais amplamente utilizados — em dois conjuntos de dados de notas fiscais: notas fiscais em inglês SROIE 2019 (361 amostras de teste) e notas fiscais em indonésio CORD v2 (100 amostras de teste). Métricas comparadas por engine: taxa de erro por caractere (CER), taxa de erro por palavra (WER), F1 de valor de campo sob dois métodos de pós-processamento (padrões regex fixos e um LLM), latência p50/p95, páginas por minuto e custo por 1.000 páginas. Cada número é rastreável a uma linha CSV publicada no repositório público de benchmark de OCR (ImageToTableai/benchmark-ocr) — dados experimentais reproduzíveis, não uma agregação de relatórios de terceiros.
O que esta página NÃO cobre: Qualquer tipo de documento que não sejam notas fiscais — sem tabelas, formulários, faturas, contratos ou documentos longos. Serviços de OCR em nuvem/API, engines ajustados e os outros seis engines do benchmark (Tesseract, PaddleOCR, Docling, Surya2, Unlimited-OCR, PaddleOCR-VL) estão fora do escopo, exceto quando citados como contexto de classificação. O levantamento completo dos 8 engines está em OCR Tradicional vs VLMs de Análise de Documentos.

Afirmação de escopo: todos os números nesta página aplicam-se apenas a notas fiscais — notas fiscais em inglês SROIE 2019 e notas fiscais em indonésio CORD v2. Um nível de hardware (RTX 4090 a $0.76/hr, preço com data de agosto de 2026), um pós-processador LLM (deepseek-v4-flash a temperatura 0), versões de modelo fixas (EasyOCR 1.7.2, docTR v1.0.1). Não extrapole estes resultados para outros tipos de documentos, GPUs ou LLMs — o benchmark mede apenas OCR de notas fiscais e extração de campos de notas fiscais. Todos os valores provêm de results/summary_metrics.csv e results/field_method_comparison.csv do benchmark, espelhados no repositório público do GitHub e citados linha por linha.

Em recibos ingleses limpos, a arquitetura moderna vence decisivamente na qualidade do texto bruto: CER do docTR no SROIE 0.1971 vs 0.2833 do EasyOCR (30% menor), WER 0.3199 vs 0.6158 (48% menor). No entanto, ao passar o texto de ambos os motores pelos mesmos padrões regex fixos, a classificação se inverte: o EasyOCR extrai campos a uma taxa 1,93× maior (F1 de campo 0,1477 vs 0,0766) — a inversão "acurácia do texto ≠ acurácia do campo" do benchmark, agora entre dois motores tradicionais. Adicione um pós-processador LLM e a inversão se reverte decisivamente novamente: docTR 0,6171 (melhor dos 8 motores) vs EasyOCR 0,3717 (pior dos 8) — uma diferença de 1,66× e um dos maiores deltas de F1 de campo com LLM do benchmark. O envelope operacional é todo do docTR: 3,8× mais rápido no p50 (108,7 vs 413,6 ms), 3,6× maior throughput (449,3 vs 124,5 páginas/min), 2,3× mais barato ($0,048 vs $0,110 por 1.000 páginas) — o motor mais rápido e barato do benchmark em ambos os eixos ao mesmo tempo.

O trade-off, em um par de números: o docTR lê uma página de recibo em 108,7 ms no p50 por $0,048 por 1.000 páginas e, através de um pós-processador LLM, extrai campos com 0,6171 de F1; o EasyOCR lê em 413,6 ms no p50 por $0,110 por 1.000 páginas e seu F1 de campo downstream com LLM despencou para 0,3717 — o pior dos oito motores testados. Mesmos recibos, mesmo split de teste, mesma RTX 4090. Nenhum motor "vence"; o EasyOCR mantém a vantagem no campo regex e na história de implantação, enquanto o docTR vence todos os eixos de acurácia, velocidade e custo medidos aqui.

0,1971 · 0,2833
CER do SROIE para docTR vs EasyOCR — uma diferença relativa de 30% (e 48% no WER) a favor da arquitetura moderna de duas etapas em recibos ingleses (summary_metrics.csv, cer / wer, linhas doctr/sroie_2019 e easyocr/sroie_2019)
1,93×
Vantagem do EasyOCR na extração de campos por regex no SROIE (F1 de campo 0,1477 vs 0,0766 do docTR) — a inversão de acurácia do texto, onde uma leitura de caracteres pior ainda produz mais campos recuperáveis por regex (field_method_comparison.csv, regex_field_value_f1, linhas sroie_2019)
1,66×
Vantagem do F1 de campo pós-processado por LLM do docTR no SROIE (0,6171, melhor dos 8 motores vs 0,3717 do EasyOCR, pior dos 8) — o maior delta de F1 com LLM entre quaisquer dois motores no benchmark (field_method_comparison.csv, llm_field_value_f1, linhas sroie_2019)

Os dois motores representam duas gerações de OCR baseado em deep-learning, ambos no lado tradicional da divisão OCR-versus-VLM. O EasyOCR (baseado em PyTorch, 1.7.2) é um clássico reconhecedor CNN + RNN + CTC de passagem única — um extrator de características ResNet alimentando um modelo de sequência decodificado com Classificação Temporal Conectivista, com refinamento baseado em atenção. Seu centro de projeto é a cobertura muito ampla de idiomas e escritas (80+ idiomas prontos para uso) e uma instalação famosamente simples. O docTR (v1.0.1) é um pipeline neural em duas etapas moderno: uma etapa de detecção localiza as regiões de texto, e uma etapa de reconhecimento as transcreve — construído em torno de detecção por transformer estilo DETR e um reconhecedor transformer, projetado para precisão em documentos impressos. A Taxa de Erro por Caractere (CER) mede inserções, exclusões e substituições divididas pelos caracteres do texto original — uma CER de 0.197 significa ~19,7 caracteres mal lidos por 100; a Taxa de Erro por Palavra (WER) aplica a mesma lógica de distância de edição em granularidade de palavras inteiras. Menor é melhor em ambos. Nenhum dos motores é um modelo de linguagem visual (VLM) — ambos produzem texto bruto, não estrutura compreendida.

Precisão do Texto no SROIE (Recibos em Inglês): Vantagem Clara do docTR

Nos 361 recibos em inglês do conjunto de teste SROIE 2019, a arquitetura moderna vence em ambas as métricas de texto: CER 0.1971 vs 0.2833 (melhoria relativa de 30%) e WER 0.3199 vs 0.6158 — a WER do EasyOCR é quase o dobro. A lacuna na WER (48%) é muito maior que a lacuna na CER (30%), o que indica que o EasyOCR complica deslizes em nível de caractere em falhas de palavras inteiras neste corpus. Ambos os motores são executados sem erros (error_rate 0.0 em cada linha do SROIE e CORD no CSV). Nenhum dos motores é o campeão geral de CER do benchmark — esse título pertence ao Surya2 (0.1915) e o próprio docTR fica em segundo; o EasyOCR ocupa o quarto lugar entre oito.

Precisão do texto no SROIE 2019: docTR CER 19,7% vs EasyOCR 28,3%; WER 32,0% vs 61,6%. Menor é melhor. Uma lacuna relativa de 30% na CER e de 48% na WER.

Fonte: summary_metrics.csv — colunas cer e wer, linhas sroie_2019. docTR cer 0.19707 / wer 0.31990; EasyOCR cer 0.28327 / wer 0.61578. Menor é melhor. 361 amostras por motor; ambos com error_rate 0.0.

Métrica (SROIE 2019, n=361)docTREasyOCRFonte
Taxa de Erro por Caractere (CER)0.19710.2833summary_metrics.csv · cer, linhas doctr/sroie_2019 e easyocr/sroie_2019
Taxa de Erro por Palavra (WER)0.31990.6158summary_metrics.csv · wer, mesmas linhas
Taxa de erro (páginas falhas)0.00.0summary_metrics.csv · error_rate, mesmas linhas

Tabela: summary_metrics.csv — colunas cer / wer / error_rate, linhas sroie_2019. Valores exatos: docTR cer 0.19707 / wer 0.31990; EasyOCR cer 0.28327 / wer 0.61578. Lacunas relativas: CER 30% menor, WER 48% menor para docTR. Menor CER/WER é melhor. Contexto de classificação CER dentro da mesma execução de 8 motores: Surya2 0.1915, docTR 0.1971, PaddleOCR 0.2045, EasyOCR 0.2833 (summary_metrics.csv, cer, linhas sroie_2019).

A Inversão Regex-Campo: Texto Pior, Campos Mais Recuperáveis

O benchmark processa o texto bruto de ambos os motores pelos mesmos padrões regex fixos nos quatro campos de recibos SROIE (empresa, data, endereço, total) — a abordagem tradicional de OCR + extração de informações-chave baseada em regras (KIE) — e a classificação se inverte: EasyOCR extrai campos com 0.1477 F1 de campo contra 0.0766 do docTR, uma vantagem de 1.93× para o motor com menor precisão de caracteres. Esta é a inversão recorrente do benchmark "precisão de texto ≠ precisão de campo" — o mesmo padrão visto entre OCR tradicional e VLMs de análise de documentos em docTR vs Surya2 — agora ocorrendo entre dois motores tradicionais que produzem o mesmo tipo de texto de linha bruto.

O F1 de valor de campo é a média harmônica de precisão e recall sobre os valores dos campos extraídos em relação à verdade fundamental: 1.0 significa que todos os campos do recibo foram perfeitamente recuperados, 0 significa nada. O mecanismo por trás da inversão é uma propriedade do conjunto de padrões regex, e não da qualidade de reconhecimento em si: os padrões foram escritos uma vez por conjunto de dados para valores formatados como RM 12.00 ou 14/08/2020. O texto de linha limpo mas bruto do docTR — preciso por CER, mas preservando o caso original e ruído de separadores — derrota os padrões fixos; a saída do EasyOCR coincide com eles com mais frequência. As colunas "extração de campo por regex" são as métricas postprocessed_sroie_receipt_regex_* do benchmark: elas medem texto OCR + extração baseada em regras downstream, não saída estruturada nativa. Uma biblioteca de padrões ajustada por formato poderia pontuar diferente para qualquer motor — o conjunto de padrões é um instrumento de medição fixo, não um analisador de produção ajustado.

F1 de campo SROIE 2019 por método de pós-processamento: através de padrões regex EasyOCR atinge 14.8% vs docTR 7.7%; através de pós-processamento por LLM (deepseek-v4-flash) docTR 61.7% vs EasyOCR 37.2%.

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

Pós-processamento por regex (SROIE 2019, n=361)docTREasyOCRFonte
F1 de valor de campo (regex)0.07660.1477field_method_comparison.csv · regex_field_value_f1, linhas doctr/sroie_2019 e easyocr/sroie_2019
Precisão de valor de campo (regex)0.06230.1267field_method_comparison.csv · regex_field_value_accuracy, mesmas linhas
Campos exatos do documento (regex)0.00000.0000field_method_comparison.csv · regex_document_fields_exact, mesmas linhas

Tabela: field_method_comparison.csv — colunas regex, linhas sroie_2019. Estas são métricas postprocessed_sroie_receipt_regex_*: padrões fixos aplicados ao texto OCR de cada engine (pós-processado, não extração nativa). O F1 de campo regex do docTR de 0.0766 é o segundo mais baixo de todas as oito engines na execução subjacente, apesar do segundo melhor CER — o conjunto de padrões foi escrito uma vez por conjunto de dados, e o texto de linha limpo, mas bruto, do docTR não é amigável a regex nesses quatro campos.

A Alavanca do LLM: A Inversão Decisiva

Alimente o texto OCR de ambos os motores em um pós-processador LLM (deepseek-v4-flash com temperatura 0) com um prompt de extração estruturado, e a classificação dos campos se inverte novamente — com a maior margem de qualquer combinação no benchmark: docTR 0.6171 vs EasyOCR 0.3717 F1 de campo, uma diferença de 1,66×. O resultado do docTR é o maior F1 de campo LLM dos oito motores; o do EasyOCR é o menor. Onde o conjunto de padrões regex puniu o texto limpo do docTR, o LLM o recompensa — e o texto intermediário do EasyOCR, que por acaso era amigável para regex, degrada sob o mesmo prompt.

Este é o mesmo padrão de convergência LLM visto no benchmark completo dos oito motores — o pós-processamento LLM puxa motores saudáveis para uma faixa de F1 de campo de 0,57–0,62 porque entende semântica (números, datas, nomes) em vez de combinar formas de caracteres — com o EasyOCR como exceção marcante. A alavanca não é gratuita: uma chamada LLM adiciona cerca de 2,0–2,1 s de latência mediana por documento além do tempo de OCR (1.996,3 ms para o texto do docTR, 2.004,5 ms para o do EasyOCR, incorridos via API e idênticos em natureza), e não resgata texto que um motor falhou fundamentalmente em ler. Mas para esta combinação, o pós-processador se torna o componente decisivo: com um LLM no pipeline, a escolha do docTR se amplifica.

Pós-processamento LLM (SROIE 2019, n=361)docTREasyOCRFonte
F1 de valor de campo (LLM)0.61710.3717field_method_comparison.csv · llm_field_value_f1, linhas doctr/sroie_2019 e easyocr/sroie_2019
Acurácia de valor de campo (LLM)0.61700.3712field_method_comparison.csv · llm_field_value_accuracy, mesmas linhas
Campos do documento exatos (LLM)0.14960.0028field_method_comparison.csv · llm_document_fields_exact, mesmas linhas
Latência mediana do pós-processamento LLM (ms)1.996,32.004,5field_method_comparison.csv · llm_median_latency_ms, mesmas linhas

Tabela: field_method_comparison.csv — colunas llm_*, linhas sroie_2019. Modelo LLM: deepseek-v4-flash com temperatura 0 (coluna llm_model). A latência do LLM é incorrida via API e separada da latência do motor (summary_metrics.csv latency_p50_ms). "Campos do documento exatos" é a fração de documentos onde cada campo alvo correspondeu exatamente — um critério muito mais rigoroso que o F1 por campo; o EasyOCR acerta todos os quatro campos exatamente em 0,28% dos recibos.

O Paradoxo do EasyOCR com LLM: Texto Intermediário, Pior Extração Downstream

O dado mais contraintuitivo desta comparação direta — documentado pela primeira vez em PaddleOCR vs EasyOCR e confirmado aqui contra um oponente diferente: o texto OCR do EasyOCR é intermediário em precisão de caracteres (SROIE CER 0.2833, quarto de oito motores) — mas quando esse texto é alimentado ao mesmo pós-processador LLM usado para todos os outros motores (deepseek-v4-flash, mesmo prompt, mesmos recibos), seu F1 de campo SROIE LLM de 0.3717 é o mais baixo de todos os oito motores no benchmark — abaixo até do Tesseract (F1 de campo pós-processado por LLM no SROIE 2019 para todos os 8 motores: docTR 61,7% é o mais alto; EasyOCR 37,2% é o mais baixo (mesmo abaixo do Tesseract 43,9%) apesar de seu CER intermediário de 28,3%. Os outros 6 motores convergem para 56,9-61,7%.

Fonte: field_method_comparison.csv — llm_field_value_f1, todas as oito linhas sroie_2019, 361 amostras cada (llm_ok_count). Pós-processador LLM idêntico para todos os motores: deepseek-v4-flash com temperatura 0. Contexto de CER de summary_metrics.csv, coluna cer, linhas sroie_2019.

Todos os 8 engines, SROIE 2019 (n=361 cada)SROIE CERSROIE LLM field F1Fonte
docTR v1.0.10.19710.6171field_method_comparison.csv · linha doctr/sroie_2019, llm_field_value_f1 (cer: summary_metrics.csv)
surya20.19150.6139field_method_comparison.csv · linha surya2/sroie_2019, llm_field_value_f1 (cer: summary_metrics.csv)
unlimited_ocr0.65520.6054field_method_comparison.csv · linha unlimited_ocr/sroie_2019, llm_field_value_f1 (cer: summary_metrics.csv)
paddleocr_vl_vllm0.33700.5921field_method_comparison.csv · linha paddleocr_vl_vllm/sroie_2019, llm_field_value_f1 (cer: summary_metrics.csv)
paddleocr0.20450.5810field_method_comparison.csv · linha paddleocr/sroie_2019, llm_field_value_f1 (cer: summary_metrics.csv)
docling0.59090.5685field_method_comparison.csv · linha docling/sroie_2019, llm_field_value_f1 (cer: summary_metrics.csv)
tesseract (CPU)0.33470.4389field_method_comparison.csv · linha tesseract/sroie_2019, llm_field_value_f1 (cer: summary_metrics.csv)
EasyOCR 1.7.20.28330.3717field_method_comparison.csv · linha easyocr/sroie_2019, llm_field_value_f1 (cer: summary_metrics.csv)

Tabela: field_method_comparison.csv — llm_field_value_f1, todas as linhas sroie_2019; coluna CER de summary_metrics.csv, cer, linhas sroie_2019. O 0.6171 do docTR é o maior LLM field F1 no benchmark; o CER do EasyOCR (0.2833) ocupa a quarta posição de oito — texto intermediário com a pior recuperação downstream de campos via LLM (0.3717, abaixo do 0.4389 do Tesseract). O paradoxo é documentado como observado e reproduzível; seu mecanismo não é isolado por este benchmark.

A Envelope de Operação: docTR é o Campeão de Velocidade E Custo do Benchmark

A precisão decide qual motor lê melhor; a envelope de operação decide qual termina. No mesmo RTX 4090 com a mesma taxa registrada de $0,76/hr, docTR sustenta 449,3 páginas/min com 108,7 ms p50 por página por $0,048 por 1.000 páginas; EasyOCR sustenta 124,5 páginas/min com 413,6 ms p50 por $0,110 por 1.000 páginas — uma diferença de latência de 3,8×, uma diferença de throughput de 3,6× e uma diferença de custo de 2,3×, todas a favor do docTR. Em toda a execução de oito motores, o p50 de 108,7 ms, o throughput de 449,3 páginas/min e o custo de $0,048 do docTR são cada um os melhores de qualquer motor medido — o docTR é simultaneamente o motor mais rápido e mais barato do benchmark.

O custo é calculado como tempo de execução em relógio de parede × a taxa do RunPod RTX 4090 ($0,76/hora, preço com carimbo de tempo nos manifests de execução), incluindo a inicialização do modelo — o preço que você realmente pagaria pelo tempo de GPU. O throughput são páginas por minuto em relógio de parede, incluindo essa mesma inicialização. A latência p50/p95 são tempos de inferência por página em estado estável, medidos em modo aquecido-então-pontuado (excluindo o carregamento do modelo); a cauda do EasyOCR é proporcionalmente pior — 960,4 ms p95 contra 281,4 ms do docTR, uma diferença de 3,4×. O EasyOCR ainda é genuinamente mais barato que a maioria dos outros motores medidos (seu $0,110 é a segunda menor cifra por 1.000 páginas no benchmark, atrás apenas do docTR) — ele é de custo intermediário e velocidade intermediária, não caro ou lento.

Latência no SROIE 2019: docTR p50 108,7 ms / p95 281,4 ms vs EasyOCR p50 413,6 ms / p95 960,4 ms — uma diferença de 3,8× no p50 e de 3,4× no p95. Estado estável, aquecido-então-pontuado (exclui carregamento do modelo).

Fonte: summary_metrics.csv — colunas latency_p50_ms / latency_p95_ms, linhas sroie_2019. docTR p50 108,72 / p95 281,38; EasyOCR p50 413,64 / p95 960,37. Latência em estado estável (modo de medição warm_then_scored, exclui carregamento do modelo).

Custo por 1.000 páginas no SROIE 2019 (RTX 4090 a $0,76/hr): docTR $0,048 vs EasyOCR $0,110 — uma diferença de 2,3×. O custo inclui a inicialização do modelo.

Fonte: summary_metrics.csv — coluna cost_per_1000_pages, linhas sroie_2019. docTR 0,0479, EasyOCR 0,1098. Custo = tempo de execução em relógio de parede × $0,76/hr incluindo init do modelo, preço com carimbo de tempo nos manifests de execução (agosto de 2026). O custo de $0,048 do docTR é o menor por 1.000 páginas de qualquer motor no benchmark; o custo de $0,110 do EasyOCR é o segundo menor (summary_metrics.csv, cost_per_1000_pages, todas as linhas sroie_2019).

Envelope operacional (SROIE 2019, n=361)docTREasyOCRFonte
Latência p50 (ms)108.7413.6summary_metrics.csv · latency_p50_ms, linhas doctr/sroie_2019 e easyocr/sroie_2019
Latência p95 (ms)281.4960.4summary_metrics.csv · latency_p95_ms, mesmas linhas
Páginas por minuto (tempo real)449.3124.5summary_metrics.csv · pages_per_minute, mesmas linhas
Custo por 1.000 páginas$0.048$0.110summary_metrics.csv · cost_per_1000_pages, mesmas linhas

Tabela: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, linhas sroie_2019. Ambos os motores em GPU (RTX 4090, preço de $0.76/hr com timestamp nos manifests); o custo inclui a inicialização do modelo, não apenas o throughput em regime permanente. Valores exatos: docTR p50 108.72 / p95 281.38 / 449.31 pg/min / $0.0479; EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098. Melhores resultados do benchmark: docTR detém a menor latência p50, o maior número de páginas/min e o menor custo entre os oito motores (summary_metrics.csv, linhas sroie_2019).

CORD (Recibos Indonésios): Ambos Colapsam no Texto, a Lacuna do LLM Aumenta

Nenhum dos motores foi treinado predominantemente em recibos indonésios, então o CORD v2 (100 amostras, campos aninhados menu/sub_total/total) funciona como um teste de estresse entre idiomas — e ambos colapsam no CER bruto: 0.9101 (docTR) e 0.9185 (EasyOCR), uma incompatibilidade de idioma onde ambos os motores são efetivamente incapazes de ler o texto. De acordo com o protocolo de benchmark, os números do CORD são mantidos isolados da comparação com SROIE — não são mesclados em nenhum ranking — porque o texto de referência do CORD incorpora a estrutura de anotação, o que infla o CER bruto para todos os motores além da incompatibilidade genuína de idioma.

As métricas de campo mostram o padrão do SROIE se estendendo — e ampliando. Através do pós-processador LLM, o F1 de campo do docTR se mantém em 0.5500 contra 0.3378 do EasyOCR no CORD — uma lacuna de 1,63×, a mesma ordem da lacuna de 1,66× do SROIE, mesmo quando ambos os reconhecedores de texto falham no nível de caractere. Através de padrões regex, o docTR recupera nenhum campo (0.0000 F1 de campo — um zero literal no CSV, não um valor ausente) porque os padrões no formato inglês não corresponderam a nada no texto indonésio, enquanto o EasyOCR obtém 0,0067. A vantagem de custo do docTR também diminui e se inverte no CORD ($0,094 contra $0,086 do EasyOCR por 1.000 páginas) — mas sua vantagem de throughput em tempo real cresce para 500,4 contra 211,8 páginas/min (2,4×). O CORD é citado aqui para contexto de robustez de idioma; ele é deliberadamente nunca agrupado com os números do SROIE em um único leaderboard.

CORD v2, recibos indonésios (n=100)docTREasyOCRFonte
Taxa de Erro por Caractere (CER)0.91010.9185summary_metrics.csv · cer, linhas doctr/cord_v2 e easyocr/cord_v2
F1 de valor de campo (regex)0.00000.0067field_method_comparison.csv · regex_field_value_f1, mesmas linhas
F1 de valor de campo (LLM)0.55000.3378field_method_comparison.csv · llm_field_value_f1, mesmas linhas
Páginas por minuto (tempo real)500.4211.8summary_metrics.csv · pages_per_minute, mesmas linhas
Custo por 1.000 páginas$0.094$0.086summary_metrics.csv · cost_per_1000_pages, mesmas linhas

Tabela: summary_metrics.csv (cer / páginas_por_minuto / custo_por_1000_páginas) e field_method_comparison.csv (F1 de campo), linhas do cord_v2. Não mesclé os números do CORD em nenhum ranking do SROIE: O CER do CORD combina incompatibilidade genuína de idioma com inflação da estrutura de anotação no ground truth. Os padrões regex foram escritos para formatos em inglês, por isso o F1 de campo por regex colapsa para ~0–1% em ambos os motores; o 0.0000 do docTR é um zero literal registrado no CSV, não um valor ausente. A lacuna no F1 de campo por LLM (0.5500 vs 0.3378) estende o padrão do SROIE para outros idiomas; a ordem de custo se inverte (EasyOCR $0.086 vs docTR $0.094) enquanto a lacuna de throughput se amplia (2,4×).

Quem Vence Quando: O Quadro Resumo

“Melhor” depende da carga de trabalho, e esta comparação direta separa os eixos claramente: a acurácia do texto bruto, os campos downstream por LLM, a velocidade, o throughput e o custo favorecem o docTR; a extração de campos por regex fixa e a história de implantação favorecem o EasyOCR — com a ressalva de que o resultado downstream por LLM do EasyOCR é seu maior risco, não seu ponto de venda.

Precisão do texto bruto — docTR
CER 0.1971 vs 0.2833
Taxa de erro por caractere (CER) no SROIE, gap relativo de 30%; WER 0.3199 vs 0.6158, um gap de 48% (summary_metrics.csv, cer / wer, sroie_2019 rows). A arquitetura moderna de duas etapas lê recibos em inglês claramente melhor.
Extração de campos por regex — EasyOCR
1.93× F1
F1 de valor de campo por regex no SROIE 0.1477 vs 0.0766 — precisão de caractere pior, mais campos recuperáveis por regex; o conjunto de padrões foi escrito uma vez por conjunto de dados, e o texto de linha limpo mas bruto do docTR o derrota (field_method_comparison.csv, regex_field_value_f1, sroie_2019 rows).
Extração de campos por LLM — docTR
1.66× F1
F1 de valor de campo por LLM no SROIE 0.6171 (melhor de 8) vs EasyOCR 0.3717 (pior de 8) — o maior delta de F1 por LLM entre quaisquer dois motores no benchmark; com um pós-processador LLM no pipeline, a escolha do docTR se compõe (field_method_comparison.csv, llm_field_value_f1, sroie_2019 rows).
Velocidade & throughput — docTR
3.8× p50 · 3.6× pg/min
SROIE p50 108.7 vs 413.6 ms (3.8×), p95 281.4 vs 960.4 ms (3.4×), páginas/min 449.3 vs 124.5 (3.6×) — o docTR é o motor mais rápido do benchmark em todos os relógios (summary_metrics.csv, latency_p50_ms / latency_p95_ms / pages_per_minute, sroie_2019 rows).
Custo por 1.000 páginas — docTR
$0.048 vs $0.110
Custo no SROIE no mesmo RTX 4090 a $0.76/hr — 2.3× mais barato, custo incluindo inicialização do modelo; os $0.048 do docTR são a menor cifra do benchmark, os $0.110 do EasyOCR a segunda menor (summary_metrics.csv, cost_per_1000_pages, sroie_2019 rows). No CORD a ordem se inverte ($0.086 vs $0.094).
Instalação fácil & multi-script — EasyOCR
80+ idiomas
O centro de design do EasyOCR: instalação pip famosamente simples, cobertura de 80+ idiomas/scripts pronta para uso, e throughput bruto decente (124.5 páginas/min, o segundo melhor de oito) — a opção para "começar em minutos em vários scripts". Não medido aqui além dos dois conjuntos de dados de recibos: sem benchmarks de amplitude de idioma ou tempo de instalação nesta execução (summary_metrics.csv, pages_per_minute, sroie_2019 rows).

Perguntas Frequentes

O docTR é mais preciso que o EasyOCR em recibos?

Sim, em todos os eixos de precisão de texto bruto e extração de campos neste benchmark. No SROIE 2019: CER 0.1971 vs 0.2833 (30% menor), WER 0.3199 vs 0.6158 (48% menor), F1 de campo pós-processado por LLM 0.6171 vs 0.3717 (1,66×, melhor de 8 vs pior de 8) — mas não no F1 de campo por regex, onde o EasyOCR vence com 0.1477 vs 0.0766 (summary_metrics.csv e field_method_comparison.csv, linhas sroie_2019). Nenhum dos motores é o campeão geral de CER do benchmark — o Surya2 (0.1915) detém esse título por uma margem mínima sobre o docTR.

Por que o docTR tem melhor precisão de texto, mas pior extração de campos por regex que o EasyOCR?

Porque as duas métricas avaliam saídas diferentes contra um instrumento de medição fixo. O docTR retorna linhas de texto bruto limpas — precisas pelo CER, mas preservando o caso original e separadores — e os padrões regex fixos, escritos uma vez por conjunto de dados para valores formatados, falham na maioria das vezes contra ele: F1 de campo por regex do SROIE 0.0766 (field_method_comparison.csv, regex_field_value_f1, linha doctr/sroie_2019). A saída do EasyOCR, por acaso, corresponde aos padrões em 0.1477. Alimente ambos com um LLM e a inversão da lacuna é de 1,66× a favor do docTR — o conjunto de padrões regex, e não o OCR, era o gargalo.

Por que o EasyOCR tem a pior extração de campos por LLM, apesar de uma precisão de caracteres razoável?

Este é o paradoxo documentado do benchmark, atualmente sem um mecanismo comprovado. O CER do SROIE do EasyOCR (0.2833) ocupa a quarta posição entre oito motores, mas seu F1 de campo pós-processado por LLM (0.3717) ocupa a última — abaixo até do Tesseract (0.4389), que tem um CER pior. A hipótese principal é uma convenção de formato de saída na forma como o EasyOCR organiza ou junta as linhas de texto que degrada a extração por LLM a jusante; ela é rotulada como um padrão observado e reproduzível, com o mecanismo não verificado (field_method_comparison.csv, llm_field_value_f1, linhas sroie_2019). O mesmo paradoxo é documentado contra um oponente diferente em PaddleOCR vs EasyOCR.

Quão mais rápido e barato é o docTR em relação ao EasyOCR?

3,8× menor latência p50 (108,7 vs 413,6 ms), 3,4× menor p95 (281,4 vs 960,4 ms), 3,6× maior throughput (449,3 vs 124,5 páginas/min), e 2,3× menor custo por 1.000 páginas ($0,048 vs $0,110) no mesmo RTX 4090 a $0,76/hr (summary_metrics.csv, latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, linhas sroie_2019). O docTR é o motor mais rápido e barato do benchmark em todos os três relógios; o EasyOCR é de custo médio (segundo mais barato) e velocidade média (segundo maior throughput).

Por que ambos os motores se saem tão mal nos recibos CORD?

Duas causas combinadas que o protocolo do benchmark mantém separadas do ranking SROIE: uma verdadeira incompatibilidade de idioma (recibos indonesianos fora do foco de treinamento de ambos os motores) e inflação da estrutura de anotação dentro do texto ground-truth do CORD — o CER fica em 0,9101 (docTR) e 0,9185 (EasyOCR) (summary_metrics.csv, cer, linhas cord_v2). O que ainda os separa é a recuperação downstream via LLM: docTR 0,5500 vs EasyOCR 0,3378 F1 de campo — o padrão SROIE persiste e se amplia, mesmo quando ambos os reconhecedores falham no nível de caractere.

Qual motor um pipeline de recibos deve escolher, EasyOCR ou docTR?

Para um pipeline cujo objetivo é campos extraídos em volume com custo mensurado, o docTR domina neste corpus: texto bruto melhor (30% menor CER), os melhores campos downstream via LLM de qualquer motor (0,6171 vs 0,3717), e uma vantagem de custo de 2,3×, throughput de 3,6×, latência de 3,8× — todos os quatro eixos de uma vez (summary_metrics.csv / field_method_comparison.csv, linhas sroie_2019). O EasyOCR continua sendo uma escolha legítima para OCR em lote barato, fácil de instalar, multi-script em documentos limpos onde a extração por regex ou texto bruto em volume moderado é a tarefa e a qualidade dos campos downstream via LLM importa menos — mas orçamento para seu fraco desempenho downstream via LLM medido antes de se comprometer. Estes resultados valem para recibos em inglês e indonesiano em uma camada de GPU em agosto de 2026; execute novamente em seu corpus alvo antes de decisões de produção (veja Limitações).

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

Cada valor é uma linha dos CSVs publicados do benchmark de primeira parte — results/summary_metrics.csv (CER/WER, F1 de campo por regex, latência, custo, throughput) e results/field_method_comparison.csv (regex vs pós-processamento por LLM, llm_model = deepseek-v4-flash) — hospedados em ImageToTableai/benchmark-ocr, com um manifest.json ofuscado 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 um recorte direto de uma execução de benchmark independente e reproduzível (nível oficial) — não uma pesquisa de alegações de terceiros, nem uma página de comparação de fornecedores. Apenas divisões de teste fixas: SROIE 2019 teste (361 recibos em inglês, campos planos empresa/data/endereço/total) e CORD v2 teste (100 recibos indonésios, campos aninhados menu/sub_total/total); divisões de treinamento nunca foram avaliadas. Ambos os motores viram as mesmas imagens, o mesmo ground truth e o mesmo protocolo de medição (warm_then_scored: uma passagem de aquecimento fixa precede a passagem pontuada, para que os valores de latência sejam em regime permanente). Ambas as execuções foram concluídas com error_rate 0.0 em ambos os conjuntos de dados (coluna error_rate do summary_metrics.csv). A execução subjacente contém oito motores no total; esta página compara apenas os dois motores nomeados, com outros motores citados apenas como contexto de classificação. Os resultados completos dos 8 motores são publicados separadamente em Traditional OCR vs Document Parsing VLMs.

Ambiente de Execução

  • Hardware: ambos os motores rodaram na mesma NVIDIA RTX 4090 (24 GB); custo da GPU calculado na taxa sob demanda do RunPod de $0.76/hr, preço com carimbo de data/hora no manifest ofuscado de cada execução (agosto de 2026).
  • Motores: prontos para uso, sem ajuste fino. Versões travadas: EasyOCR 1.7.2 (reconhecedor clássico CNN + RNN + CTC, extrator de características ResNet, GPU) e docTR v1.0.1 (OCR neural moderno em duas etapas — detecção por transformer estilo DETR + reconhecimento, GPU) — conforme a tabela de modelos do repositório público (README.md) e manifests de execução. A linha SROIE do EasyOCR foi re-verificada em uma re-execução com torch 2.8 em 2026-08-17 (execuções repetidas r1/r2/r3 idênticas em bytes); os CSVs publicados contêm esses valores corrigidos.
  • Pós-processador LLM: deepseek-v4-flash via API em temperatura 0 para saída determinística (a coluna llm_model no field_method_comparison.csv); foi o único modelo usado para todas as linhas de campo LLM em ambos os motores.
  • Base de custo: tempo de execução real × $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 regex do SROIE são postprocessed_sroie_receipt_regex_* (colunas regex_* do field_method_comparison.csv) — campos extraídos do texto OCR por um conjunto fixo de padrões escrito uma vez por conjunto de dados. Elas medem OCR + extração downstream, não a saída estruturada nativa de nenhum dos modelos; as colunas LLM_* medem texto OCR + extração por LLM. Os dois pipelines nunca são misturados.

Definições das Métricas

  • CER (Character Error Rate): distância de edição (inserções + exclusões + substituições) entre o texto OCR e o ground truth, dividida pelo número de caracteres do ground truth. Quanto menor, melhor.
  • WER (Word Error Rate): o mesmo cálculo de distância de edição, mas em granularidade de palavras.
  • F1 de valor de campo (regex): média harmônica de precisão/recall sobre os valores de campo extraídos usando padrões regex fixos no texto OCR (pipeline tradicional de OCR + KIE baseado em regras). Coluna: regex_field_value_f1. Uma pontuação de 0 significa que nenhum valor de campo foi recuperado.
  • F1 de valor de campo (LLM): a mesma métrica na saída do pós-processador LLM (texto OCR → deepseek-v4-flash → campos). Coluna: llm_field_value_f1. Os dois pipelines são diferentes e nunca são combinados.
  • Campos do documento exatos: fração de documentos onde todos os campos alvo corresponderam exatamente — um critério muito mais rigoroso que o F1 por campo.
  • Latência p50/p95 & páginas/min: tempo de inferência por página em regime permanente (aquecimento + pontuação, exclui carregamento do modelo) e throughput em tempo real incluindo inicialização do modelo. Eles medem relógios diferentes.
  • Custo por 1.000 páginas: horas de GPU cobradas para 1.000 páginas à taxa registrada de $0,76/hr, incluindo inicialização do modelo.

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. Todos os números de CER/WER, latência, custo e throughput nesta página são rastreados até as linhas do easyocr e doctr aqui.
  2. field_method_comparison.csv (GitHub raw). 16 linhas; colunas model, dataset, llm_model (= deepseek-v4-flash), acurácia e F1 de valor de campo regex/llm, document-fields-exact, llm_median_latency_ms, contagens de tokens. Todos os números de F1 de valor de campo regex/LLM são rastreados até as linhas do easyocr e doctr aqui (e até todas as oito linhas do sroie_2019 na tabela paradoxo).
  3. Repositório ImageToTableai/benchmark-ocr. Repositório público hospedando os CSVs de resultado, manifests de execução redatados, 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 redatado por execução publicada (16 execuções) com versões do modelo, GPU/driver, versões torch/CUDA/Python, metadados de custo com carimbo de data/hora do preço 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 da tarefa 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. Nada aqui mede a amplitude de 80+ idiomas do EasyOCR em texto que não seja de recibo, o comportamento do docTR em tabelas/formulários/documentos longos, ou qualquer outro tipo de documento. Não use esta página para concluir que qualquer um dos motores “vence em tudo.”
  • Tamanho da amostra: 361 recibos em inglês + 100 em indonésio. O F1 de campo e o CER são sensíveis ao corpus; diferenças de um único dígito na casa dos centésimos devem ser tratadas como ruído, não como verdade de engenharia — embora as lacunas documentadas aqui (30% CER, 48% WER, 1,66× F1 do LLM) estejam muito além dessa faixa.
  • Tier de GPU único e preço único: todos os números vêm de uma RTX 4090 a $0,76/hr, com preço datado de agosto de 2026 nos manifests de execução. Outras GPUs, servimento multi-GPU, agendamento em lote ou alterações de preço mudarão a latência, throughput e custo — recalcule os custos com as taxas atuais antes de orçar.
  • LLM pós-processador único: todas as linhas de LLM usam deepseek-v4-flash com temperatura 0. Um LLM diferente altera o F1 absoluto de campo; a magnitude do paradoxo do EasyOCR pode mudar com o LLM, embora o padrão observado tenha se mantido para este único pós-processador em ambos os conjuntos de dados. A latência do LLM (~2,0–2,1 s mediana no SROIE, llm_median_latency_ms no field_method_comparison.csv) é imposta pela API e não faz parte da latência própria de nenhum dos motores.
  • Mecanismo do paradoxo do EasyOCR não verificado: o benchmark documenta que o texto de CER intermediário do EasyOCR produz a pior recuperação de campo downstream pelo LLM (0,3717 SROIE / 0,3378 CORD) — um resultado observado e reproduzível sob a hipótese de convenções de layout do texto de saída, com o mecanismo causal explicitamente não isolado. Trate-o como um resultado medido para planejar em torno, não como uma propriedade comprovada da biblioteca.
  • Ajuste de regex: o conjunto de padrões foi escrito uma vez por conjunto de dados. Uma biblioteca de padrões ajustada por formato poderia pontuar mais alto em seus próprios layouts — ao custo de manutenção que o LLM elimina. A desvantagem regex-campo do docTR (0,0766 vs 0,1477) é uma propriedade deste instrumento fixo, não uma afirmação sobre o que um parser ajustado poderia recuperar.
  • O CER do CORD não é uma leitura de qualidade por modelo: o ground truth do CORD incorpora estrutura de anotação e nenhum dos motores foi treinado predominantemente em indonésio; o CER do CORD (~0,91) reflete incompatibilidade de idioma + inflação do ground truth. As linhas do CORD são citadas com contextualização e nunca são mescladas em qualquer ranking do SROIE (regra do protocolo).
  • Apenas dois motores: esta comparação direta exclui deliberadamente os outros seis motores da execução subjacente, serviços de OCR em nuvem/API e APIs de VLM hospedadas; seus modelos de latência e precificação diferem fundamentalmente dos motores locais medidos aqui.
  • Fixação de versão: os resultados valem para EasyOCR 1.7.2 e docTR v1.0.1 (agosto de 2026). Versões mais recentes de qualquer um dos motores podem alterar todos os números nesta página.

Referências relacionadas: PaddleOCR vs EasyOCR Receipt Benchmark · docTR vs Surya2 Receipt Benchmark · Traditional OCR vs Document Parsing VLMs · Regex vs LLM Field Extraction · Field-Level vs Character-Level Accuracy · OCR Cost per 1,000 Pages

Leitura relacionada: Precisão de OCR com IA vs OCR Tradicional · Extração de Dados de Imagem com IA vs OCR Tradicional · Preços de Extração de Documentos com IA (2026)

📮 contact email: [email protected]