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

Os dois motores representam duas gerações de OCR baseado em deep learning. PaddleOCR (baseado em PaddlePaddle, arquitetura PP-OCR, v3.7.0) é um pipeline moderno de dois estágios: um estágio de deteção localiza as regiões de texto, e um estágio de reconhecimento as transcribe — projetado para alta precisão em texto impresso em escala. EasyOCR (baseado em PyTorch, 1.7.2) é um reconhecedor clássico de passagem única CNN + RNN + CTC — um extrator de características ResNet que alimenta um modelo de sequência decodificado com Classification Temporal Conexionista. É conhecido por sua amplia cobertura de idiomas e scripts (80+ idiomas prontos para uso) e por uma instalação notoriamente simples. A Taxa de Erro de Caracteres (CER) mede inserções, deleções e substituções divididas pelos caracteres de referência — um CER de 0.204 significa ~20,4 caracteres mal lidos por 100; a Taxa de Erro de Palabras (WER) aplica a mesma lógica de distância de edição a nível de palavra completa. Menor é melhor em ambos.

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

Nos 361 recibos em inglês da divisão de teste SROIE 2019, a arquitetura moderna vence em ambas métricas de texto: CER 0.2045 vs 0.2833 (uma melhora relativa de 27,8%) e WER 0.3256 vs 0.6158 — o WER de EasyOCR é quase o doble. A diferença de WER é maior que a de CER, o que indica que EasyOCR acumula erros a nível de caracteres em falhas de palavras completas neste corpus. Ambos motores funcionam sem erros (error_rate 0.0 em todas las filas de SROIE e CORD no CSV).

Fuente: summary_metrics.csv — colunas cer e wer, filas sroie_2019. PaddleOCR cer 0.20449 / wer 0.32563; EasyOCR cer 0.28327 / wer 0.61578. Menor é melhor. 361 muestras por motor; ambos 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. CER/WER menores são melhores. Nenhuno dos dois motores é o campeão geral de precisão do benchmark — esse título pertence a Surya2 (CER 0.1915) e 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 via Regex e via 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 planos de recibo (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 a temperatura 0) com um prompt estruturado. Via regex, PaddleOCR extrae campos a 0.3254 de F1 de campo contra 0.1477 de EasyOCR — uma vantagem de 2.2×; via LLM, a diferença persiste em 0.5810 vs 0.3717 (1.56×).

O F1 de valor de campo é a média harmónica de precisão e recall sobre os valores extraídos dos campos contra a verdade fundamental — 1.0 significa que cada campo do recibo foi perfeitamente recuperado, 0 significa nada. As colunas regex de campos 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 saída estruturada nativa). Note o contexto de ranking: o 0.3254 de PaddleOCR é o terceiro melhor resultado regex de campos na execução de 8 motores (atrás de Unlimited-OCR 0.3376 e PaddleOCR-VL 0.3368) e o melhor entre os quatro motores puramente tradicionais; o 0.1477 de EasyOCR ocupa o sétimo lugar de 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 armazenados 0–1 mostrados como %). Pós-processador LLM: deepseek-v4-flash (columna llm_model). 361 muestras 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 de OCR de cada mecanismo. Pós-processador LLM: deepseek-v4-flash a 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). “Documentos com todos os campos exatos” é a fração de documentos em que cada campo-alvo correspondeu 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 a Jusante

Este é o dado mais marcante da página e é genuinamente contraintuitivo: o texto 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 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: a forma como o EasyOCR organiza, junta ou separa linhas de texto parece degradar a extração de campos do LLM a jusante 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ênticas; o CSV publicado já carrega esses valores corrigidos), mas nenhuma alegação causal é feita. A implicação prática é o oposto do verniz de marketing: neste corpus, escolher EasyOCR para texto “bom o suficiente” significa orçar para a pior recuperação de campos a jusante via LLM de qualquer mecanismo testado.

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; coluna CER de summary_metrics.csv, cer, linhas sroie_2019. O CER do EasyOCR (0.2833) ocupa o quarto lugar entre oito — texto de nível médio com a pior recuperação de campos downstream via LLM (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: Onde o EasyOCR É Genuinamente Competitivo

A precisão não é o único eixo, e no eixo operacional o EasyOCR tem contra-vantagens reais e medidas. Na mesma RTX 4090 ao mesmo preço de $0.76/hr, o EasyOCR processa SROIE a $0.110 por 1.000 páginas vs $0.221 do PaddleOCR (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 de 3.331,4 ms do PaddleOCR (uma cauda 3.5× mais apertada). Sua pegada também é mais simples de implantar — um único runtime PyTorch com ampla cobertura de idiomas, em vez da pilha de framework mais pesada do PaddlePaddle.

Uma aparente contradição merece uma explicação honesta: o PaddleOCR tem a latência mediana menor por página (297.0 ms p50 vs 413.6 ms do EasyOCR), mas o número menor de páginas por minuto (79.7 vs 124.5). Os dois números medem relógios diferentes. A latência p50 é a inferência por página em estado estável, medida com o modelo já carregado (aquecido); páginas/min é a vazão de tempo real 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 em tempo real; a inferência por página do PaddleOCR é individualmente mais rápida quando aquecido. Ambos os números são reais; eles descrevem coisas diferentes, e uma carga de trabalho dominada pela sobrecarga de carregamento do modelo (muitos lotes pequenos, inicializações a frio frequentes) experimentará a vantagem de tempo real do EasyOCR, enquanto um pipeline de longa duração e aquecido experimentará a vantagem por página do PaddleOCR.

O custo é calculado como tempo de execução em tempo real × a taxa da RTX 4090 do RunPod ($0.76/hora, preço com registro de data e hora nos manifestos de execução), incluindo a inicialização do modelo — o preço que você realmente pagaria pelo tempo de GPU. A vazão é páginas por minuto em tempo real, incluindo a mesma inicialização. As latências p50/p95 são tempos de inferência por página em estado estável, medidos com aquecimento e depois 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 estado estável.

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 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. PaddleOCR 0.2214, EasyOCR 0.1098. Custo = tempo de execução em tempo real × $0.76/hr incluindo init do modelo, preço com registro de data e hora nos manifestos de execução (agosto de 2026). Nenhum dos dois 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, $0,76/hora 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 entre p50 e páginas/min é explicada no texto acima: inferência por página em estado estável (PaddleOCR vence) vs. throughput em tempo real incluindo inicialização e efeitos de lote (EasyOCR vence).

CORD (recibos indonésios): ambos colapsam, mas a recuperação de campos via LLM do PaddleOCR sobrevive

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 no CER bruto: 0.9083 (PaddleOCR) e 0.9185 (EasyOCR), um empate por incompatibilidade de idioma, com ambos os mecanismos efetivamente incapazes de ler o texto. Conforme o protocolo do benchmark, os números do CORD são mantidos em quarentena em relação à comparação SROIE — não são mesclados em nenhum ranking — porque o texto de referência do CORD incorpora estrutura de anotação, o que infla o CER bruto de todos os mecanismos, além da incompatibilidade real de idioma.

As métricas de campo contam uma história diferente dos CERs quase idênticos. Por meio do pós-processador LLM, o F1 de campos do PaddleOCR se mantém em 0.5527 vs. 0.3378 do EasyOCR no CORD — o mesmo padrão do SROIE, estendido: a recuperação downstream via 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 via LLM do EasyOCR no CORD é o segundo mais baixo entre os oito mecanismos (acima apenas do 0.1627 do Tesseract, linhas cord_v2 em summary_metrics.csv/field_method_comparison.csv) — novamente atrás de mecanismos com CER pior, o paradoxo persistindo nos dois conjuntos de dados. O CORD é citado aqui para contexto de robustez a idiomas; deliberadamente nunca é agrupado com os números do SROIE em um único ranking.

Tabela: summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) e field_method_comparison.csv (field F1), linhas cord_v2. Não mescle números de CORD em nenhuma classificação SROIE: o CER de CORD combina incompatibilidade linguística genuína 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 via regex cai para ~0–2% em ambos os mecanismos. O F1 de campo via LLM de 0,5527 do PaddleOCR em CORD repete sua vantagem em SROIE (0,5810 vs 0,3717) — sua recuperação downstream via LLM sobrevive ao choque linguístico que a do EasyOCR não suporta.

Quem Vence Quando: O Quadro-Resumo

“Melhor” depende da carga de trabalho, e este confronto direto separa os eixos com clareza: todos os eixos de precisão em recibos em inglês favorecem o PaddleOCR; custo, throughput de tempo real, latência de cauda e simplicidade de implantação favorecem o EasyOCR; e o campeonato de precisão de texto bruto não pertence a nenhum dos dois (Surya2/docTR) — enquanto o resultado downstream via 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 campo por regex 0.3254 vs 0.1477 (2,2×), F1 de campo pós-processado 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, ampliando para $0.086 vs $0.342 no CORD, na mesma RTX 4090 a $0.76/h 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 em geral é o docTR a $0.048 por 1.000 páginas.

Qual é mais rápido: PaddleOCR ou EasyOCR?

Depende de qual relógio você quer dizer. O PaddleOCR tem menor latência mediana em estado estável (297.0 vs 413.6 ms p50), mas o EasyOCR tem maior throughput em tempo de relógio (124.5 vs 79.7 páginas/min) porque páginas/min em tempo de relógio 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 frios pequenos ou frequentes, o EasyOCR vence a corrida de tempo de relógio.

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 campo pós-processado 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 subsequente por LLM; está rotulado como um padrão observado e reproduzível com mecanismo não verificado (field_method_comparison.csv, llm_field_value_f1, linhas sroie_2019).

Por que ambos os mecanismos têm pontuação tão baixa em recibos CORD?

Duas causas combinadas que o protocolo mantém separadas do ranking SROIE: uma incompatibilidade genuína de idioma (recibos indonésios fora do foco de treinamento de ambos os mecanismos) e inflação da estrutura de anotação no texto de referência do CORD — o CER fica em 0.9083 (PaddleOCR) e 0.9185 (EasyOCR) (summary_metrics.csv, linhas cer, cord_v2). O que ainda os diferencia é a recuperação a jusante via LLM: PaddleOCR 0.5527 vs EasyOCR 0.3378 em F1 de campos — o padrão SROIE persiste mesmo quando ambos os reconhecedores falham no nível de caracteres.

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

Se o seu pipeline consome campos — valores extraídos para empresa, data, totais — o PaddleOCR é a escolha padrão clara para recibos: 2,2× F1 de campos com regex, 1,56× com LLM, e recuperação a jusante via LLM que sobrevive ao choque de idioma do CORD (field_method_comparison.csv). Se você precisa de volume em lote barato, cauda de pior caso apertada, stack leve ou ampla cobertura de idiomas para começar, o EasyOCR é genuinamente competitivo no eixo operacional (2× mais barato, 1,56× throughput de tempo real, p95 3,5× mais apertado, 80+ idiomas) — mas reserve orçamento para seu downstream fraco com LLM 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 (ver Limitações).

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

Cada figura é uma linha dos CSVs publicados do benchmark de primeira parte — results/summary_metrics.csv (CER/WER, F1 de campos com regex, 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 impressões digitais de ambiente. As definições de conjuntos de dados vêm dos artigos SROIE 2019 e CORD citados abaixo.

Metodologia & Fontes

Protocolo

Esta página apresenta um comparativo direto de um benchmark independente e reprodutível (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 do SROIE 2019 (361 recibos em inglês, campos simples company/date/address/total) e teste do CORD v2 (100 recibos em indonésio, campos aninhados menu/sub_total/total); as divisões de treinamento 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 pontuada, de modo que os números de latência refletem o estado estável). Ambas as execuções foram concluídas com error_rate 0.0 nos dois conjuntos de dados (coluna error_rate do 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); o custo de GPU foi calculado pela tarifa on-demand da RunPod de $0.76/hr, com o preço registrado no manifesto editado de cada execução (agosto de 2026).
• Mecanismos: prontos para uso, sem fine-tuning. Versões fixadas: PaddleOCR 3.7.0 (OCR moderno de aprendizado profundo em duas etapas — detecção + reconhecimento PP-OCR, GPU) e EasyOCR 1.7.2 (ResNet+CRNN clássico com decodificação CTC, GPU) — conforme a tabela de modelos do repositório público (README.md) e os manifestos de execução. A linha do SROIE do EasyOCR foi reverificada em uma nova execução de 2026-08-17 com torch 2.8 (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 do 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 em wall-clock × $0.76/hr, incluindo inicialização do modelo — o processamento em lote reduz o custo por página.
• Pós-processamento de campos: as métricas de campos regex do SROIE são postprocessed_sroie_receipt_regex_* (colunas regex_* do field_method_comparison.csv) — campos extraídos do texto do OCR por um conjunto fixo de padrões. Elas medem OCR + extração a jusante, não a saída estruturada nativa de nenhum dos modelos; as colunas LLM_* medem texto do OCR + extração com LLM. As duas pipelines nunca são combinadas.

Definición de Métricas

• CER (Character Error Rate): distancia de edición (inserciones + eliminaciones + sustituciones) entre el texto OCR y la verdad de referencia, dividida por los caracteres de la verdad de referencia. Menor es mejor.
• WER (Word Error Rate): el mismo cálculo de distancia de edición a nivel de palabra.
• F1 de valor de campo (regex): media armónica de precisión/recuperación sobre los valores de campo extraídos usando patrones regex fijos en el texto OCR (pipeline tradicional de OCR + KIE basado en reglas). Columna: regex_field_value_f1. Una puntuación de 0 significa que no se recuperaron valores de campo.
• F1 de valor de campo (LLM): la misma métrica en la salida del postprocesador LLM (texto OCR → deepseek-v4-flash → campos). Columna: llm_field_value_f1. Los dos pipelines son diferentes y nunca se combinan.
• Exactitud de campos de documento: fracción de documentos donde todos los campos objetivo coincidieron exactamente — un estándar mucho más estricto que el F1 por campo.
• Latencia p50/p95 y páginas/min: tiempo de inferencia por página en estado estable (calentado y luego puntuado, excluye la carga del modelo) y rendimiento de tiempo real incluyendo la inicialización del modelo. Miden relojes diferentes; la inversión de p50 vs. páginas/min en esta página es una diferencia del modelo de medición, no un error.
• Costo por 1,000 páginas: horas de GPU facturadas por 1,000 páginas a la tarifa registrada de $0.76/hora, incluyendo la inicialización del modelo.

Lista de Fuentes

1. summary_metrics.csv (GitHub raw). 16 filas = 8 modelos × 2 conjuntos de datos. Columnas: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Cada número de CER/WER, latencia, costo y rendimiento en esta página se rastrea hasta las filas de paddleocr y easyocr aquí.
2. field_method_comparison.csv (GitHub raw). 16 filas; columnas model, dataset, llm_model (= deepseek-v4-flash), precisión y F1 de valor de campo regex/llm, exactitud de campos de documento, llm_median_latency_ms, recuentos de tokens. Cada número de F1 de campo regex/LLM se rastrea hasta las filas de paddleocr y easyocr aquí (y a las ocho filas de sroie_2019 en la tabla de paradoja).
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que aloja los CSV de resultados, manifiestos de ejecución redactados, protocolo congelado y listas de muestras de conjuntos de datos (divisiones de prueba fijas) para reproducción.
4. results/manifests/ (GitHub). Un manifest.json redactado por ejecución publicada (16 ejecuciones) con versiones de modelo, GPU/controlador, versiones de torch/CUDA/Python, metadatos de costo con marca de tiempo de precio y hashes de artefactos.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definición del conjunto de datos SROIE 2019, estructura de tareas y licencia (CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definición del conjunto de datos CORD v2, esquema de campos anidados y licencia (CC-BY-4.0).

Limitações

• Escopo do documento — apenas recibos: SROIE + CORD. Nada aqui mede os recursos de layout/tabela/documento do PP-Structure do PaddleOCR, a amplitude de 80+ idiomas do EasyOCR em textos que não são recibos, ou qualquer outro tipo de documento. Não use esta página para concluir que qualquer um dos mecanismos “vence em tudo”.
• Tamanho da amostra: 361 recibos em inglês + 100 em indonésio. O F1 de campo e o CER dependem do corpus; diferenças de alguns centésimos devem ser tratadas como ruído, não como verdade de engenharia — embora as lacunas documentadas aqui (27,8% de CER, 2,2× de F1 regex) estejam muito além dessa faixa.
• Um único nível de GPU e um único preço: todos os números vêm de uma RTX 4090 a US$ 0,76/hora, com preço datado de agosto de 2026 nos manifestos de execução. Outras GPUs, serviço multi-GPU, agendamento em lote ou mudanças de preço alterarão latência, throughput e custo — recalcule os custos às taxas atuais antes de orçar.
• Um único pós-processador LLM: todas as linhas de LLM usam deepseek-v4-flash a temperatura 0. Um LLM diferente altera o F1 absoluto de campo; a magnitude do paradoxo do EasyOCR pode variar 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 de mediana no SROIE, field_method_comparison.csv llm_median_latency_ms) é incorrida pela API e não faz parte da latência de nenhum dos mecanismos.
• Mecanismo do paradoxo do EasyOCR não verificado: o benchmark documenta que o texto CER de nível intermediário do EasyOCR produz a pior recuperação de campo a jusante do LLM (0,3717 SROIE / 0,3378 CORD) — um resultado observado e reproduzível sob a hipótese de convenções de layout de texto de saída, com o mecanismo causal explicitamente não isolado. Trate-o como um resultado medido para planejar, 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 fortemente ajustada por formato poderia pontuar mais alto em seus próprios layouts — ao custo de manutenção que o LLM elimina.
• 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 mecanismos 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 enquadramento e nunca mescladas em qualquer ranking do SROIE (regra do 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 mecanismos podem alterar todos os números desta página.

Referências relacionadas: Benchmark de recibos docTR vs Surya2 · o confronto direto OCR vs VLM · regras de regex contra extração por LLM · precisão de caracteres vs precisão de campo · Precisão de OCR de recibos

Leitura relacionada: como o OCR com IA se compara ao OCR clássico · extração de imagens com IA comparada ao OCR tradicional · Preços de Extração de Documentos com IA (2026)