PaddleOCR vs EasyOCR em Notas Fiscais
Benchmark de Precisão vs Custo (2026)

Os dois motores representam duas gerações de OCR baseado em deep-learning. PaddleOCR (baseado no PaddlePaddle, arquitetura PP-OCR, v3.7.0) é um pipeline moderno de duas etapas: uma etapa de detecção localiza as regiões de texto e uma etapa de reconhecimento as transcreve — projetado para alta precisão em texto impresso em escala. EasyOCR (baseado no PyTorch, 1.7.2) é um reconhecedor clássico de passagem única CNN + RNN + CTC — um extrator de características ResNet alimentando um modelo de sequência decodificado com Classificação Temporal Conectivista. É conhecido por sua cobertura muito ampla de idiomas e escritas (80+ idiomas prontos para uso) e uma instalação famosamente simples. A Taxa de Erro de Caractere (CER) mede inserções, exclusões e substituições divididas pelos caracteres do texto original — um CER de 0.204 significa ~20,4 caracteres mal lidos por 100; a Taxa de Erro de Palavra (WER) aplica a mesma lógica de distância de edição em granularidade de palavras inteiras. Menor é melhor em ambos.

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

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.2045 vs 0.2833 (uma melhoria relativa de 27,8%) e WER 0.3256 vs 0.6158 — o WER do EasyOCR é quase o dobro. A diferença no WER é maior do que no CER, o que indica que o EasyOCR complica deslizes em nível de caractere em falhas de palavras inteiras neste corpus. Ambos os motores funcionam sem erros (error_rate 0.0 em cada linha do SROIE e CORD no CSV).

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

Tabela: summary_metrics.csv — colunas cer / wer / error_rate, linhas sroie_2019. Valores exatos: PaddleOCR cer 0.20449 / wer 0.32563; EasyOCR cer 0.28327 / wer 0.61578. Menor CER/WER é melhor. Nenhum dos motores é o campeão geral de precisão do benchmark — esse título pertence ao Surya2 (CER 0.1915) e ao docTR (CER 0.1971) na mesma execução de 8 motores (summary_metrics.csv, linhas surya2 e doctr sroie_2019).

Extração de Campos: KIE por Regex e por LLM

A precisão do texto classifica os motores; a extração de campos é o que os sistemas downstream realmente consomem. As métricas de campos SROIE do benchmark visam quatro campos de recibo simples (empresa, data, endereço, total) usando dois pós-processadores no texto OCR de cada motor: padrões regex fixos (a abordagem tradicional de OCR + extração de informações-chave baseada em regras) e um pós-processador LLM (deepseek-v4-flash com temperatura 0) com um prompt estruturado. Por regex, o PaddleOCR extrai campos com 0.3254 campo F1 contra 0.1477 do EasyOCR — uma vantagem de 2,2×; por LLM, a diferença persiste em 0.5810 contra 0.3717 (1,56×).

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 ao gabarito — 1.0 significa que todos os campos do recibo foram perfeitamente recuperados, 0 significa nada. As colunas de campos regex SROIE são as métricas postprocessed_sroie_receipt_regex_* do benchmark: padrões fixos aplicados ao texto OCR de cada motor (pós-processado, não a saída estruturada nativa). Observe o contexto de classificação: o 0.3254 do PaddleOCR é o terceiro melhor resultado de campos regex no benchmark de 8 motores (atrás do Unlimited-OCR 0.3376 e do PaddleOCR-VL 0.3368) e o melhor entre os quatro motores puramente tradicionais; o 0.1477 do EasyOCR classifica-se em sétimo lugar entre oito (summary_metrics.csv, field_f1_regex, linhas sroie_2019).

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

Tabela: field_method_comparison.csv — colunas regex e llm, linhas sroie_2019. As colunas regex são métricas postprocessed_sroie_receipt_regex_*: padrões fixos aplicados ao texto OCR de cada engine. Pós-processador LLM: deepseek-v4-flash com temperatura 0 (coluna llm_model). A latência LLM é da API e separada da latência da engine (summary_metrics.csv latency_p50_ms). "Docs com todos os campos 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

Este é o ponto de dados mais distintivo da página, e é genuinamente contraintuitivo: o texto OCR do EasyOCR é intermediário em precisão de caracteres (CER do SROIE 0.2833, quarto de oito engines) — mas quando esse texto é alimentado ao mesmo pós-processador LLM usado para todas as outras engines (deepseek-v4-flash, mesmo prompt, mesmos recibos), seu F1 de campos LLM do SROIE de 0.3717 é o menor de todas as oito engines no benchmark — abaixo até do Tesseract (0.4389), uma engine de CPU com um CER pior (0.3347). Apenas o texto OCR mudou; o LLM, o prompt e os recibos foram 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: a maneira como o EasyOCR organiza, junta ou separa linhas de texto parece degradar a extração downstream de campos por LLM por razões não relacionadas à precisão bruta de caracteres. O benchmark não isolou este mecanismo; o resultado é documentado aqui como reproduzível e estável (a linha do SROIE do EasyOCR foi re-verificada em uma execução com torch 2.8 em 2026-08-17, r1/r2/r3 idênticos em bytes; o CSV publicado já contém esses valores corrigidos), mas nenhuma afirmação causal é feita. A implicação prática é o oposto da aparência de marketing: neste corpus, escolher o EasyOCR para um texto "suficientemente bom" significa orçar para a pior recuperação downstream de campos por LLM de qualquer engine testada.

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

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 CER do EasyOCR (0.2833) ocupa a quarta posição entre oito — texto intermediário com a pior recuperação de campos downstream do LLM (0.3717, abaixo do Tesseract com 0.4389). O paradoxo é documentado como observado e reproduzível; seu mecanismo não é isolado por este benchmark.

A Faixa de Operação: Onde o EasyOCR É Genuinamente Competitivo

A precisão não é o único eixo, e no eixo operacional o EasyOCR possui contravantagens reais e mensuráveis. No mesmo RTX 4090 a $0,76/hr, o EasyOCR processa o SROIE a $0,110 por 1.000 páginas vs $0,221 do PaddleOCR’s (uma diferença de 2,0×), sustenta 124,5 páginas/min vs 79,7 (1,56×), e mantém sua cauda de pior caso apertada: p95 960,4 ms vs o pico de primeira página do PaddleOCR’s de 3.331,4 ms (uma cauda 3,5× mais apertada). Sua pegada também é mais simples de implantar — um único runtime PyTorch com ampla cobertura de idiomas, versus a pilha de framework mais pesada do PaddlePaddle.

Uma aparente contradição merece uma explicação honesta: o PaddleOCR tem a latência mediana por página menor (297,0 ms p50 vs 413,6 ms do EasyOCR) mas a figura de páginas por minuto menor (79,7 vs 124,5). Os dois números medem relógios diferentes. A latência p50 é a inferência por página em regime estacionário, medida quente (modelo já carregado); páginas/min é o throughput de relógio de parede de toda a execução, que inclui a inicialização do modelo e efeitos de lote. O runtime menor e de carregamento mais rápido do EasyOCR vence a corrida de volume de relógio de parede; a inferência por página do PaddleOCR é individualmente mais rápida uma vez em regime quente. Ambos os números são reais; eles descrevem coisas diferentes, e uma carga de trabalho dominada pelo overhead de carregamento do modelo (muitos lotes pequenos, inícios frios frequentes) experimentará a vantagem de relógio de parede do EasyOCR, enquanto um pipeline longo e em regime quente experimentará a vantagem por página do PaddleOCR.

O custo é calculado como tempo de execução de 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 de relógio de parede incluindo a mesma inicialização. As latências p50/p95 são tempos de inferência por página em regime estacionário medidos quente-então-pontuados (carregamento do modelo excluído); o p95 de 3.331 ms do PaddleOCR é um pico de primeira página/prefill, não seu comportamento em regime estacionário.

Fonte: summary_metrics.csv — colunas latency_p50_ms / latency_p95_ms, linhas sroie_2019. PaddleOCR p50 296,99 / p95 3331,35; EasyOCR p50 413,64 / p95 960,37. Latência em regime estacionário (modo de medição warm_then_scored, exclui carregamento do modelo).

Fonte: summary_metrics.csv — coluna cost_per_1000_pages, linhas sroie_2019. PaddleOCR 0,2214, EasyOCR 0,1098. Custo = tempo de execução de 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). Nenhum dos motores é o mais barato do benchmark — o docTR detém esse título a $0,048 por 1.000 páginas (summary_metrics.csv, linha doctr/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/hr com timestamp nos manifests); o custo inclui a inicialização do modelo. Valores exatos: PaddleOCR p50 296.99 / p95 3331.35 / 79.71 pg/min / $0.2214; EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098. A inversão p50-vs-páginas/min é explicada no texto acima: inferência por página em regime permanente (PaddleOCR vence) vs. throughput em tempo real incluindo inicialização e efeitos de lote (EasyOCR vence).

CORD (Notas Fiscais Indonésias): Ambos Colapsam, Mas a Recuperação de Campos por LLM do PaddleOCR Sobrevive

Nenhum dos motores foi treinado predominantemente em notas fiscais indonésias, 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.9083 (PaddleOCR) e 0.9185 (EasyOCR), um empate por incompatibilidade de idioma com ambos os motores 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 o SROIE — nã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 cada motor além da incompatibilidade de idioma genuína.

As métricas de campo contam uma história diferente dos CERs quase idênticos. Através do pós-processador LLM, o F1 de campos do PaddleOCR se mantém em 0.5527 contra 0.3378 do EasyOCR no CORD — o mesmo padrão do SROIE, estendido: a recuperação downstream por LLM do PaddleOCR resiste ao choque de idioma que a do EasyOCR não resiste, mesmo quando ambos os reconhecedores de texto falham no nível de caracteres. O F1 de campos por LLM do EasyOCR no CORD é o segundo mais baixo dos oito motores (acima apenas do 0.1627 do Tesseract, linhas cord_v2 em summary_metrics.csv/field_method_comparison.csv) — novamente ficando atrás de motores com CER pior, o paradoxo persistindo em ambos os conjuntos de dados. O CORD é citado aqui para contexto de robustez de idioma; é deliberadamente nunca agrupado com os números do SROIE em um único leaderboard.

Tabela: summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) e field_method_comparison.csv (field F1), linhas 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 de estrutura de anotação no ground truth. Os padrões regex foram escritos para formatos em inglês, razão pela qual o field F1 por regex colapsa para ~0–2% em ambos os motores. O field F1 do LLM do PaddleOCR de 0.5527 no CORD repete sua vantagem no SROIE (0.5810 vs 0.3717) — sua recuperação downstream do LLM sobrevive ao choque de idioma que a do EasyOCR não sobrevive.

Quem Vence Quando: A Grade de Resumo

“Melhor” depende da carga de trabalho, e esta comparação direta divide os eixos de forma clara: todo eixo de precisão em recibos em inglês favorece o PaddleOCR; custo, throughput em tempo real, latência de cauda e simplicidade de implantação favorecem o EasyOCR; e o campeonato bruto de precisão de texto pertence a nenhum (Surya2/docTR) — enquanto o resultado downstream do LLM do EasyOCR é sua maior ressalva, não seu ponto de venda.

Perguntas Frequentes

O PaddleOCR é mais preciso que o EasyOCR em recibos?

Sim, em todos os eixos de precisão medidos neste benchmark. No SROIE 2019: CER 0.2045 vs 0.2833 (melhoria relativa de 27,8%), WER 0.3256 vs 0.6158, F1 de campos por regex 0.3254 vs 0.1477 (2,2×), F1 de campos pós-processados por LLM 0.5810 vs 0.3717 (summary_metrics.csv e field_method_comparison.csv, linhas sroie_2019). Nenhum dos dois motores é o campeão geral de texto do benchmark — Surya2 (CER 0.1915) e docTR (0.1971) detêm esse título.

O EasyOCR é mais barato que o PaddleOCR?

Sim — cerca de 2× mais barato por 1.000 páginas em recibos em inglês: $0,110 vs $0,221 no SROIE 2019, aumentando para $0,086 vs $0,342 no CORD, no mesmo RTX 4090 a $0,76/hr com custo incluindo inicialização do modelo (summary_metrics.csv, cost_per_1000_pages, linhas sroie_2019 e cord_v2). O motor mais barato do benchmark no geral é o docTR a $0,048 por 1.000 páginas.

Qual é mais rápido: PaddleOCR ou EasyOCR?

Depende de qual relógio você considera. O PaddleOCR tem menor latência mediana em regime permanente (297,0 vs 413,6 ms p50), mas o EasyOCR tem maior throughput em tempo real (124,5 vs 79,7 páginas/min) porque o throughput em tempo real inclui inicialização do modelo e efeitos de lote, e o runtime mais leve do EasyOCR carrega mais rápido (summary_metrics.csv, latency_p50_ms / pages_per_minute, linhas sroie_2019). Para um pipeline longo e aquecido, o PaddleOCR é mais rápido por página; para muitos lotes pequenos ou frequentes a frio, o EasyOCR vence a corrida em tempo real.

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

Este é o paradoxo documentado do benchmark, atualmente sem um mecanismo comprovado. O CER do EasyOCR no SROIE (0.2833) ocupa o quarto lugar entre oito motores, mas seu F1 de campos pós-processados por LLM (0.3717) ocupa o último lugar — 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 downstream; 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).

Por que ambos os motores têm um desempenho tão ruim nos recibos CORD?

Duas causas combinadas que o protocolo mantém separadas do ranking SROIE: uma incompatibilidade genuína de idioma (recibos indonesianos fora do foco de treinamento de ambos os motores) e uma inflação na estrutura de anotação dentro do texto de referência do CORD — o CER fica em 0.9083 (PaddleOCR) e 0.9185 (EasyOCR) (summary_metrics.csv, cer, cord_v2 rows). O que ainda os separa é a recuperação downstream por LLM: PaddleOCR 0,5527 vs EasyOCR 0,3378 no F1 de campos — o padrão SROIE persiste mesmo quando ambos os reconhecedores falham no nível de caractere.

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

Se seu pipeline consome campos — valores extraídos para empresa, data, totais — PaddleOCR é o padrão claro para recibos: 2,2× o F1 de campos com regex, 1,56× com um LLM, e uma recuperação downstream por LLM que sobrevive ao choque de idioma do CORD (field_method_comparison.csv). Se você precisa de volume em lote barato, uma cauda de pior caso apertada, uma pilha leve ou ampla cobertura de idiomas para começar, EasyOCR é genuinamente competitivo no eixo operacional (2× mais barato, 1,56× de throughput em tempo real, 3,5× mais apertado no p95, 80+ idiomas) — mas orçamento para sua fraca recuperação downstream por LLM antes de se comprometer. Esses 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 figura é uma linha dos CSVs publicados do benchmark de primeira mão — results/summary_metrics.csv (CER/WER, F1 de campos 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 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 & Fontes

Protocolo

Esta página relata um recorte direto de um benchmark independente e reproduzível (nível oficial) — não um levantamento 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 terminaram 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 no manifesto redatado de cada execução (agosto de 2026).
• Motores: prontos para uso, sem ajuste fino. Versões travadas: PaddleOCR 3.7.0 (OCR moderno de aprendizado profundo em duas etapas — detecção + reconhecimento PP-OCR, GPU) e EasyOCR 1.7.2 (clássico ResNet+CRNN com decodificação CTC, GPU) — conforme a tabela de modelos do repositório público (README.md) e manifestos de execução. A linha SROIE do EasyOCR foi re-verificada em uma reexecuçã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 (coluna llm_model no field_method_comparison.csv); foi o único modelo usado para todas as linhas de campos 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. 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 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 pelos caracteres do ground truth. Quanto menor, melhor.
• WER (Word Error Rate): o mesmo cálculo de distância de edição em granularidade de palavras.
• Field-value F1 (regex): média harmônica de precisão/recall sobre valores de campos extraídos usando padrões regex fixos no texto OCR (pipeline de OCR tradicional + KIE baseado em regras). Coluna: regex_field_value_f1. Uma pontuação de 0 significa que nenhum valor de campo foi recuperado.
• Field-value F1 (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.
• Document-fields exact: fração de documentos onde 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 regime permanente (aquecimento seguido de pontuação, exclui carregamento do modelo) e throughput em tempo real incluindo inicialização do modelo. Eles medem relógios diferentes; a inversão p50-vs-páginas/min nesta página é uma diferença no modelo de medição, não um erro.
• 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 paddleocr e easyocr 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 paddleocr e easyocr aqui (e até todas as oito linhas 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 as capacidades de layout/tabela/documento do PP-Structure do PaddleOCR, a amplitude de 80+ idiomas do EasyOCR em texto não-recibo, ou qualquer outro tipo de documento. Não use esta página para concluir que qualquer um dos engines “vence em tudo.”
• Tamanho da amostra: 361 recibos em inglês + 100 em indonésio. F1 de campo e CER são sensíveis ao corpus; diferenças de um único dígito de algumas centésimas devem ser tratadas como ruído, não como verdade de engenharia — embora as lacunas documentadas aqui (27,8% CER, 2,2× regex F1) estejam muito além dessa faixa.
• Tier de GPU único e preço único: todos os números vêm de um 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 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 por 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 (~1.817–2.005 ms mediana no SROIE, llm_median_latency_ms no field_method_comparison.csv) é incorrida pela API e não faz parte da latência própria de nenhum dos engines.
• 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 campos 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.
• CER do CORD não é uma leitura de qualidade por modelo: o ground truth do CORD incorpora estrutura de anotação e nenhum dos engines 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 de protocolo).
• Fixação de versão: os resultados valem para PaddleOCR 3.7.0 e EasyOCR 1.7.2 (agosto de 2026). Versões mais recentes de qualquer um dos engines podem alterar todos os números nesta página.

Referências relacionadas: docTR vs Surya2 Receipt Benchmark · Traditional OCR vs Document Parsing VLMs · Regex vs LLM Field Extraction · Field-Level vs Character-Level Accuracy · Receipt OCR Accuracy

Leituras relacionadas: AI OCR vs Traditional OCR Accuracy · AI Image Data Extraction vs Traditional OCR · AI Document Extraction Pricing (2026)