EasyOCR vs docTR em Recibos
Campeão de Velocidade vs Extrator de Campos (2026)

Os dois mecanismos representam duas gerações de OCR de aprendizado profundo, ambos do lado tradicional da divisão entre OCR e VLM. O EasyOCR (baseado em PyTorch, 1.7.2) é um reconhecedor clássico de passagem única CNN + RNN + CTC — um extrator de características ResNet alimentando um modelo sequencial decodificado com Classificação Temporal Conexionista, com refinamento baseado em atenção. Seu centro de design é uma cobertura muito ampla de idiomas e scripts (80+ idiomas prontos para uso) e uma instalação notoriamente simples. O docTR (v1.0.1) é um pipeline neural moderno de dois estágios: um estágio de detecção localiza regiões de texto, e um estágio 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, deleções e substituições divididas pelos caracteres de referência — uma CER de 0,197 significa ~19,7 caracteres lidos incorretamente a cada 100; a Taxa de Erro por Palavra (WER) aplica a mesma lógica de distância de edição na granularidade de palavras inteiras. Quanto menor, melhor em ambas. Nenhum dos mecanismos é um modelo de visão-linguagem (VLM) — ambos produzem texto bruto, não estrutura compreendida.

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

Nos 361 recibos em inglês da divisão de teste do SROIE 2019, a arquitetura moderna vence em ambas as métricas de texto: CER 0,1971 vs 0,2833 (melhora relativa de 30%) e WER 0,3199 vs 0,6158 — o WER do EasyOCR é quase o dobro. A diferença de WER (48%) é muito maior que a de CER (30%), o que indica que o EasyOCR acumula erros de nível de caractere em falhas de palavras inteiras neste corpus. Ambos os mecanismos rodam sem erros (error_rate 0.0 em todas as linhas de SROIE e CORD no CSV). Nenhum dos mecanismos é o campeão geral de CER do benchmark — esse título pertence ao Surya2 (0,1915), com o docTR em segundo lugar; o EasyOCR ocupa o quarto de oito.

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. Quanto menor, melhor. 361 amostras por mecanismo; ambos error_rate 0.0.

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. Diferenças relativas: CER 30% menor, WER 48% menor para docTR. CER/WER menores é melhor. Contexto de ranking CER na mesma execução de 8 mecanismos: 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

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

O F1 de valor de campo é a média harmônica de precisão e recall sobre os valores de campo extraídos contra o ground truth: 1.0 significa que todo campo do recibo foi perfeitamente recuperado, 0 significa nada. O mecanismo por trás da inversão é uma propriedade do conjunto de padrões regex, não da qualidade do 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 bruto limpo do docTR — preciso pelo CER, mas preservando maiúsculas originais 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 campos por regex" são as métricas postprocessed_sroie_receipt_regex_* do benchmark: elas medem texto de OCR + extração baseada em regras a jusante, não saída estruturada nativa. Uma biblioteca de padrões fortemente ajustada por formato poderia pontuar diferente para qualquer um dos mecanismos — o conjunto de padrões é um instrumento de medição fixo, não um parser de produção ajustado.

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

Tabela: field_method_comparison.csv — colunas de regex, linhas sroie_2019. Estas são métricas postprocessed_sroie_receipt_regex_*: padrões fixos aplicados ao texto de OCR de cada mecanismo (pós-processado, não extração nativa). O F1 de campo por regex do docTR, de 0.0766, é o segundo mais baixo entre todos os oito mecanismos 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 limpo, porém bruto, do docTR não é amigável a regex nesses quatro campos.

A Alavanca do LLM: A Virada se Inverte, Decisivamente

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

Este é o mesmo padrão de convergência por LLM visto em todo o benchmark de oito mecanismos — o pós-processamento por LLM eleva mecanismos saudáveis para uma faixa de F1 de campo de 0,57–0,62 porque ele entende a semântica (números, datas, nomes) em vez de corresponder a formatos de caracteres — com o EasyOCR como a exceção gritante. A alavanca não é gratuita: uma chamada de 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 ela não resgata texto que um mecanismo fundamentalmente não conseguiu 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 potencializa.

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

O Paradoxo EasyOCR-LLM: Texto de Nível Médio, Pior Extração Posterior

O dado mais contraintuitivo deste confronto direto — documentado pela primeira vez em PaddleOCR vs EasyOCR e confirmado aqui contra um oponente diferente: o texto de OCR do EasyOCR fica no meio do pelotão em precisão de caracteres (SROIE CER 0.2833, quarto de oito mecanismos) — mas quando esse texto é alimentado ao mesmo pós-processador LLM usado para todos os outros mecanismos (deepseek-v4-flash, mesmo prompt, mesmos recibos), seu F1 de campo LLM SROIE de 0.3717 é o mais baixo de todos os oito mecanismos no benchmark — abaixo até do Tesseract (0.4389), um mecanismo de CPU com CER pior (0.3347). Apenas o texto do OCR mudou; o LLM, o prompt e os recibos eram idênticos.

Padrão observado, mecanismo não verificado. Uma hipótese plausível — e nada mais que isso — é uma convenção de formato de saída: como o EasyOCR organiza, junta ou separa linhas de texto parece degradar a extração de campos pelo LLM por razões não relacionadas à precisão bruta de caracteres. O benchmark não isolou esse mecanismo; o resultado está documentado aqui como reproduzível e estável (a linha SROIE do EasyOCR foi reverificada em uma reexecução torch 2.8 em 2026-08-17, r1/r2/r3 byte-idênticos; o CSV publicado já carrega esses valores corrigidos), mas nenhuma alegação causal é feita. O texto base mais limpo do docTR + o LLM chega ao topo da mesma faixa que o EasyOCR não alcança.

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 mecanismos: deepseek-v4-flash a temperatura 0. Contexto CER de summary_metrics.csv, coluna cer, linhas sroie_2019.

Tabela: field_method_comparison.csv — llm_field_value_f1, todas as linhas sroie_2019; columna CER de summary_metrics.csv, cer, linhas sroie_2019. O 0.6171 do docTR é o F1 de campo LLM mais alto do benchmark; o CER do EasyOCR (0.2833) ocupa o quarto lugar entre oito — texto de nível médio com a recuperação de campo LLM downstream mais baixa (0.3717, abaixo do 0.4389 do Tesseract). O paradoxo está documentado como observado e reproduzível; seu mecanismo não é isolado por este benchmark.

O Envelope Operacional: docTR É o Campeão de Velocidade E Custo do Benchmark

A precisão decide qual mecanismo lê melhor; o envelope operacional decide qual termina primeiro. Na mesma RTX 4090 à mesma taxa registrada de $0,76/hora, o docTR sustenta 449,3 páginas/min a 108,7 ms p50 por página por $0,048 por 1.000 páginas; o EasyOCR sustenta 124,5 páginas/min a 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 mecanismos, os 108,7 ms p50, 449,3 páginas/min e $0,048 de custo do docTR são os melhores de qualquer mecanismo medido — o docTR é simultaneamente o mecanismo mais rápido e mais barato do benchmark.

O custo é calculado como tempo de execução em wall-clock × a taxa da RTX 4090 do RunPod ($0,76/hora, preço com timestamp nos manifests de execução), incluindo a inicialização do modelo — o preço que você realmente pagaria pelo tempo de GPU. O throughput é páginas por minuto em wall-clock, incluindo essa mesma inicialização. A latência p50/p95 são tempos de inferência por página em estado estável, medidos com warm-then-scored (carregamento do modelo excluído); a cauda do EasyOCR é proporcionalmente pior — 960,4 ms p95 contra os 281,4 ms do docTR, uma diferença de 3,4×. O EasyOCR ainda é genuinamente mais barato que a maioria dos outros mecanismos medidos (seus $0,110 são o segundo menor valor por 1.000 páginas no benchmark, atrás apenas do docTR) — é custo médio e velocidade média, não caro ou lento.

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).

Fonte: summary_metrics.csv — coluna cost_per_1000_pages, linhas sroie_2019. docTR 0,0479, EasyOCR 0,1098. Custo = tempo de execução em wall-clock × $0,76/hora incluindo init do modelo, preço com timestamp nos manifests de execução (agosto de 2026). Os $0,048 do docTR são o menor custo por 1.000 páginas de qualquer mecanismo no benchmark; os $0,110 do EasyOCR são o segundo menor (summary_metrics.csv, cost_per_1000_pages, todas as linhas sroie_2019).

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/h com timestamp nos manifests); o custo inclui a inicialização do modelo, não apenas a vazão em estado estacionário. 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 do benchmark: docTR tem a menor latência p50, o maior número de páginas/min e o menor custo entre todos os oito motores (summary_metrics.csv, linhas sroie_2019).

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

Nenhum dos mecanismos foi treinado predominantemente com 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 na CER bruta: 0.9101 (docTR) e 0.9185 (EasyOCR), um empate por incompatibilidade de idioma, com ambos os mecanismos efetivamente incapazes de ler o texto. De acordo com o protocolo do benchmark, os números do CORD são mantidos em quarentena da comparação SROIE — não mesclados em nenhuma classificação — porque o texto de referência do CORD incorpora a estrutura de anotação, o que infla a CER bruta para todos os mecanismos, além da genuína incompatibilidade de idioma.

As métricas de campo mostram o padrão do SROIE se estendendo — e aumentando. Através do pós-processador LLM, o F1 de campo do docTR se mantém em 0.5500 vs. 0.3378 do EasyOCR no CORD — uma lacuna de 1,63×, a mesma ordem do SROIE de 1,66×, 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 de F1 de campo — um zero literal no CSV, não um valor ausente) porque os padrões de formato em inglês não corresponderam a nada no texto indonésio, enquanto o EasyOCR extrai 0.0067. A vantagem de custo do docTR também diminui e se inverte no CORD ($0.094 vs. $0.086 do EasyOCR por 1.000 páginas) — mas sua vantagem de throughput em tempo real cresce para 500.4 vs. 211.8 páginas/min (2.4×). O CORD é citado aqui para contexto de robustez de idioma; ele nunca é deliberadamente combinado com os números do SROIE em um único ranking.

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

Quem Vence Quando: O Resumo

“Melhor” depende da carga de trabalho, e este confronto divide os eixos com clareza: precisão bruta de texto, campos com LLM downstream, velocidade, throughput e custo favorecem o docTR; extração de campos com regex fixo e a história de implantação favorecem o EasyOCR — com a ressalva de que o resultado do EasyOCR com LLM downstream é seu maior risco, não seu ponto de venda.

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 valor 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 dois 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 texto de linha bruto limpo — preciso por CER, mas preservando maiúsculas e separadores originais — e os padrões de regex fixos, escritos uma vez por conjunto de dados para valores formatados, falham na maioria das vezes contra ele: F1 de campo por regex no SROIE 0.0766 (field_method_comparison.csv, regex_field_value_f1, linha doctr/sroie_2019). A saída do EasyOCR coincide com os padrões em 0.1477. Alimente ambos com um LLM e a diferença se inverte para 1.66× a favor do docTR — o conjunto de padrões de regex, não o OCR, era o gargalo.

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

Este é o paradoxo documentado do benchmark, atualmente sem mecanismo comprovado. O CER do EasyOCR no SROIE (0.2833) ocupa o quarto lugar entre oito motores, mas seu F1 de valor de campo pós-processado por LLM (0.3717) fica em último — 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 linhas de texto que degrada a extração por LLM a jusante; está rotulado 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 está documentado contra um oponente diferente em PaddleOCR vs EasyOCR.

Quanto mais rápido e barato é o docTR em comparaçã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) na mesma RTX 4090 a $0,76/hora (summary_metrics.csv, latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, linhas sroie_2019). O docTR é o mecanismo 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 mecanismos pontuam tão mal em recibos CORD?

Duas causas que se somam e que o protocolo do benchmark mantém separadas da classificação SROIE: uma incompatibilidade linguística genuína (recibos indonésios fora do foco de treinamento de ambos os mecanismos) e inflação da estrutura de anotação dentro do texto de referência do CORD — a CER chega a 0,9101 (docTR) e 0,9185 (EasyOCR) (summary_metrics.csv, cer, linhas cord_v2). O que ainda os diferencia é a recuperação a jusante com LLM: docTR 0,5500 vs EasyOCR 0,3378 em F1 de campo — o padrão SROIE persiste e se amplia, mesmo quando ambos os reconhecedores falham no nível de caractere.

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

Para um pipeline cujo objetivo é campos extraídos em volume com custo medido, o docTR domina neste corpus: melhor texto bruto (30% menor CER), os melhores campos a jusante com LLM de qualquer mecanismo (0,6171 vs 0,3717) e uma vantagem de custo de 2,3×, throughput 3,6×, latência 3,8× — todos os quatro eixos ao mesmo tempo (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 e multiescrita em documentos limpos onde a extração por regex ou texto bruto em volume modesto é a tarefa e a qualidade dos campos a jusante com LLM importa menos — mas reserve orçamento para seu LLM a jusante fraco antes de se comprometer. Esses resultados valem para recibos em inglês e indonésio em um nível de GPU em agosto de 2026; reexecute no seu corpus alvo antes de decisões de produção (veja Limitações).

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

Cada número é uma linha dos CSVs publicados do benchmark proprietário — results/summary_metrics.csv (CER/WER, F1 de regex por campo, latência, custo, throughput) e results/field_method_comparison.csv (regex vs pós-processamento com LLM, llm_model = deepseek-v4-flash) — hospedados em ImageToTableai/benchmark-ocr, com um manifest.json editado por execução para identificadores de 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 comparativo de uma execução independente e reproduzível do benchmark (nível oficial) — não é um levantamento de alegações de terceiros, nem uma página de comparação entre fornecedores. Apenas divisões de teste fixas: teste SROIE 2019 (361 recibos em inglês, campos simples company/date/address/total) e teste CORD v2 (100 recibos em indonésio, campos aninhados menu/sub_total/total); as divisões de treino nunca foram avaliadas. Ambos os mecanismos viram 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 os números de latência refletem o estado estável). Ambas as execuções terminaram com error_rate 0.0 nos dois conjuntos de dados (coluna error_rate em summary_metrics.csv). A execução subjacente contém oito mecanismos no total; esta página compara apenas os dois mecanismos nomeados, com os demais citados somente como contexto de classificação. Os resultados completos dos 8 mecanismos são publicados separadamente em Traditional OCR vs Document Parsing VLMs.

Ambiente de Execução

• Hardware: ambos os mecanismos rodaram na mesma NVIDIA RTX 4090 (24 GB); custo de GPU calculado pela tarifa on-demand da RunPod de $0.76/hora, com preço registrado no manifest editado de cada execução (agosto de 2026).
• Mecanismos: prontos para uso, sem fine-tuning. Versões fixadas: 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 dois estágios — detecção por transformer estilo DETR + reconhecimento, GPU) — conforme a tabela de modelos do repositório público (README.md) e os manifests das execuções. A linha SROIE do EasyOCR foi reverificada em uma reexecução torch 2.8 em 2026-08-17 (execuções repetidas r1/r2/r3 byte-idênticas); os CSVs publicados trazem esses valores corrigidos.
• 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 com LLM em ambos os mecanismos.
• Base de custo: tempo de execução real × $0.76/hora, incluindo inicialização do modelo — o processamento em lote reduz o custo por página.
• Pós-processamento de campos: as métricas de regex dos campos SROIE são postprocessed_sroie_receipt_regex_* (colunas regex_* em field_method_comparison.csv) — campos extraídos do texto do OCR por um conjunto fixo de padrões escrito uma vez por conjunto de dados. Elas medem OCR + extração a jusante, não saída estruturada nativa de nenhum dos modelos; as colunas LLM_* medem texto do OCR + extração com LLM. Os dois pipelines nunca são misturados.

Definições de Métricas

• CER (Taxa de Erro por Caractere): distância de edição (inserções + exclusões + substituições) entre o texto do OCR e o ground truth, dividida pelos caracteres do ground truth. Quanto menor, melhor.
• WER (Taxa de Erro por Palavra): 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/recall sobre os valores de campo extraídos usando padrões regex fixos no texto do 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 do OCR → deepseek-v4-flash → campos). Coluna: llm_field_value_f1. Os dois pipelines são diferentes e nunca são combinados.
• Document-fields exact: fração de documentos em que todos os campos-alvo corresponderam exatamente — um critério muito mais rigoroso do que o F1 por campo.
• Latência p50/p95 & páginas/min: tempo de inferência por página em estado estacionário (após aquecimento e pontuação, excluindo carregamento do modelo) e throughput em tempo real, incluindo a 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/hora, incluindo a 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 têm origem nas linhas easyocr e doctr 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. Todos os números de F1 de campo regex/LLM têm origem nas linhas easyocr e doctr aqui (e em todas as oito linhas sroie_2019 na tabela do paradoxo).
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 dos 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 versões de modelo, GPU/driver, versões de torch/CUDA/Python, metadados de custo com timestamp de 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 das 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 — somente 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 um motor “vence em tudo”.
• Tamanho da muestra: 361 recibos em inglês + 100 em indonesio. O F1 de campo e o CER dependen del corpus; diferencias de unos pocos centésimos deben tratarse como ruido, não como verdade de ingeniería — aunque las brechas documentadas aquí (30% CER, 48% WER, 1,66× F1 del LLM) están muy por encima de esa banda.
• Un solo nivel de GPU y un solo precio: todos los números provienen de una RTX 4090 a $0,76/hora, con precio con fecha de agosto de 2026 en los manifiestos de ejecución. Otras GPUs, servicio multi-GPU, programación por lotes o cambios de precio alterarán la latencia, el rendimiento y el costo — recalcule los costos a las tarifas actuales antes de presupuestar.
• Un solo posprocesador LLM: todas las filas de LLM usan deepseek-v4-flash a temperatura 0. Un LLM diferente cambia el F1 de campo absoluto; la magnitud de la paradoja de EasyOCR puede variar con el LLM, aunque el patrón observado se mantuvo para este único posprocesador en ambos conjuntos de datos. La latencia del LLM (~2,0–2,1 s de mediana en SROIE, field_method_comparison.csv llm_median_latency_ms) es incurrida por la API y no forma parte de la latencia de ninguno de los motores.
• Mecanismo de la paradoja de EasyOCR no verificado: el benchmark documenta que el texto CER de nivel medio de EasyOCR produce la peor recuperación de campos aguas abajo del LLM (0,3717 SROIE / 0,3378 CORD) — un resultado observado y reproducible bajo la hipótesis de las convenciones de diseño del texto de salida, con el mecanismo causal explícitamente no aislado. Trátelo como un resultado medido para planificar, no como una propiedad probada de la biblioteca.
• Ajuste de expresiones regulares: el conjunto de patrones se escribió una vez por conjunto de datos. Una biblioteca de patrones muy afinada por formato podría puntuar más alto en sus propios diseños — al costo de mantenimiento que el LLM elimina. La desventaja de docTR en campos con regex (0,0766 vs 0,1477) es una propiedad de este instrumento fijo, no una afirmación sobre lo que un analizador afinado podría recuperar.
• El CER de CORD no es una lectura de calidad por modelo: la verdad de campo de CORD incorpora estructura de anotación y ninguno de los motores fue entrenado predominantemente en indonesio; el CER de CORD (~0,91) refleja desajuste de idioma + inflación de la verdad de campo. Las filas de CORD se citan con contexto y nunca se fusionan en ninguna clasificación de SROIE (regla del protocolo).
• Solo dos motores: este cara a cara excluye deliberadamente los otros seis motores de la ejecución subyacente, los servicios de OCR en la nube/API y las API de VLM alojadas; sus modelos de latencia y precios difieren fundamentalmente de los motores locales medidos aquí.
• Fijación de versiones: los resultados son válidos para EasyOCR 1.7.2 y docTR v1.0.1 (agosto de 2026). Las versiones más recientes de cualquiera de los motores pueden cambiar cada número de esta página.

Referencias relacionadas: Benchmark de recibos PaddleOCR vs EasyOCR · Benchmark de recibos docTR vs Surya2 · OCR tradicional vs VLMs de análisis de documentos · coincidencia de patrones vs extracción de campos basada en modelos · medir la precisión por campo, no por carácter · Costo de OCR por 1.000 páginas

Leitura relacionada: por que a precisão da IA OCR diverge do OCR tradicional · por que a extração por IA supera o OCR em imagens · Preços de Extração de Documentos com IA (2026)