Resultados do Benchmark de OCR de Recibos:
Precisão, Latência e Custo em 5 Modelos de OCR de Código Aberto (2026)

O Paradoxo: Melhor Leitor de Texto, Pior Extrator de Campos

A mesma execução do benchmark produziu o melhor e o pior resultado de extração de campos nos mesmos 361 recibos. A diferença não é a qualidade dos dados — é a diferença entre ler texto e extrair campos.

Duas métricas de precisão respondem a perguntas diferentes. Taxa de Erro de Caracteres (CER) mede quantos caracteres individuais foram lidos incorretamente em relação à transcrição de referência — uma CER de 19,7% significa aproximadamente um caractere errado a cada cinco. Taxa de Erro de Palavras (WER) reprova uma palavra inteira se qualquer caractere dentro dela for lido incorretamente, por isso os valores de WER são sempre maiores que os de CER. O F1 de campo, neste benchmark, mede se os quatro campos SROIE — nome da empresa, data, endereço e total — podem ser recuperados do texto do OCR por um pós-processador de regex fixo, calculado como a média harmônica de precisão e revocação no conjunto de campos dos 361 documentos.

O docTR produziu a transcrição mais limpa (CER de 19,7%, WER de 32,0%), mas sua recuperação de campos caiu para F1 de 7,7% — uma passada de regex sobre texto limpo ainda pode falhar quando o formato do valor (símbolos de moeda, totais com vírgula decimal, endereços multilinha) não corresponde ao padrão de extração. A transcrição do PaddleOCR foi ligeiramente mais ruidosa (CER de 20,5%), mas sua saída se alinhou melhor aos padrões de campo, resultando em F1 de 32,5%. Nenhum dos resultados é um erro — são duas camadas diferentes do mesmo pipeline, e nenhum modelo neste lote alcançou sequer um documento totalmente correto nos quatro campos (correspondência exata de campo em nível de documento = 0 para todos os modelos). Este é o significado prático da afirmação de que a precisão do texto do OCR não é a precisão dos campos.

Resultados do SROIE 2019: Precisão de Texto, F1 de Campo, Latência e Custo

O conjunto de classificação principal é o SROIE 2019 (Scanned Receipt OCR and Information Extraction, o conjunto de dados da competição ICDAR 2019) — 361 recibos digitalizados em inglês na divisão de teste oficial fixa, avaliados com todos os cinco modelos no mesmo grupo de execução na mesma GPU. CER/WER menor é melhor; F1 de campo maior é melhor.

Fonte: ImageToTable.ai Receipt OCR Benchmark v1, divisão de teste do SROIE 2019 (361 amostras). Execuções: camada oficial, protocolo warm_then_scored, RTX 4090. IC bootstrap de 95% via 2.000 reamostragens. Pacote completo de artefatos disponível mediante solicitação. Conjunto de dados: competição ICDAR 2019 SROIE.

Fonte: ImageToTable.ai Receipt OCR Benchmark v1, divisão de teste do SROIE 2019. Todas as métricas provenientes de artefatos de benchmark congelados (n=361 por modelo, taxa de sucesso de 100%). CER/WER: taxa de erro de caracteres/palavras em relação à transcrição de referência. F1 de campo: extração de campos pós-processada a partir do texto de OCR via regex fixo — NÃO é a saída nativa de campos do modelo (nenhum dos cinco modelos emite campos estruturados nativos). IC: percentil bootstrap de 95%, 2.000 reamostragens. Custo: calculado com RunPod RTX 4090 a $0,76/hora (preço registrado em 2026-08-11). Artefatos completos disponíveis mediante solicitação.

Por que o F1 de campo fica tão atrás da precisão de texto

Todos os modelos deste lote leem o texto razoavelmente bem, mas falham em entregar um campo estruturado utilizável na maioria dos recibos — o melhor F1 de campo é 32,5%, e nenhum modelo produziu um único documento totalmente correto (empresa + data + endereço + total, todos exatos).

As métricas de campo SROIE aqui são pós-processadas por regex: o benchmark pega o texto OCR de cada modelo e aplica uma extração fixa baseada em padrões para os quatro campos. Isso é deliberadamente diferente da saída nativa de campos estruturados de um modelo — nenhum dos cinco mecanismos de OCR de código aberto deste lote emite campos estruturados nativos para o layout de recibos, então o pós-processador é o único caminho de campo disponível para eles. A lacuna entre um CER de 19,7% e um F1 de campo de 7,7% é o que um pipeline de extração real paga pela camada de saída estruturada ausente: texto de alta qualidade ainda precisa de compreensão de layout e normalização de valores para se tornar campos.

A inversão de classificação entre os modelos é estável: PaddleOCR lidera o F1 de campo com 32,5% (IC de 30,5–34,5%), seguido por Tesseract 23,2%, Docling 22,3%, EasyOCR 14,8% e docTR 7,7% — enquanto a classificação de métricas de texto é quase exatamente invertida no topo (docTR 19,7% CER vs PaddleOCR 20,5% CER). Qualquer pipeline que relate apenas "precisão de OCR" está escondendo a camada de extração de campos onde a variação real está.

CORD v2: O Teste de Estresse de Idioma

Em 100 recibos em indonésio (CORD v2), o CER de todos os modelos colapsa para 90–95% — uma pilha de OCR treinada em inglês não transfere para outro idioma, e este benchmark quantifica a penalidade em vez de ignorá-la.

CORD v2 (um conjunto de dados de recibos consolidado criado para pós-processamento de OCR) fornece o teste de estresse entre idiomas. Suas 100 amostras de teste revisadas são recibos em indonésio, e todos os modelos deste lote foram treinados principalmente com dados em inglês. Os resultados abaixo não são uma classificação de qualidade dos modelos — as métricas de texto CORD são apresentadas como evidência de robustez de recibo/idioma/layout e não devem ser mescladas com SROIE em uma única classificação geral. As métricas de campo não são aplicáveis no CORD porque nenhum modelo emite campos estruturados CORD nativos e nenhum pós-processador CORD é definido para este lote.

Fonte: ImageToTable.ai Receipt OCR Benchmark v1, divisão de teste CORD v2 (100 amostras). Todas as execuções em nível oficial, RTX 4090, taxa de sucesso de 100%. Ressalva: teste de estresse de incompatibilidade de idioma — não compare os valores de CER do CORD com os valores de CER do SROIE. Conjunto de dados: CORD v2 (Clova AI).

Velocidade e Custo: a Dispersão de 7,7×

Em hardware idêntico, a taxa de transferência varia 7,7× e o custo por 1.000 páginas varia 7,8× — para volume de recibos, escolher o modelo mais rápido pode reduzir o custo de computação de OCR em cerca de 87% antes mesmo de considerar a precisão.

A taxa de transferência é relatada de duas formas neste benchmark: latência p50/p95 por página (a partir de registros de predição bem-sucedidos, excluindo a inicialização do executor) e páginas por minuto de ponta a ponta em tempo real (incluindo a inicialização do processo do executor no modo warm_then_scored). O custo por 1.000 páginas é calculado a partir do tempo de execução na taxa registrada de US$ 0,76/hora do RunPod RTX 4090. Os gráficos abaixo mostram a taxa de transferência e o custo em tempo real do SROIE; o CORD segue o mesmo padrão, com docTR e PaddleOCR novamente os mais rápidos e baratos.

Fonte: ImageToTable.ai Receipt OCR Benchmark v1, divisão de teste do SROIE 2019 (361 amostras). Páginas por minuto em tempo real de execuções cronometradas do benchmark, incluindo a inicialização do executor. Todas as execuções em nível oficial, RTX 4090.

Fonte: ImageToTable.ai Receipt OCR Benchmark v1, divisão de teste do SROIE 2019. Custo = tempo de execução × US$ 0,76/hora (RunPod RTX 4090, preço registrado em 2026-08-11). Inclui a sobrecarga de inicialização por execução.

Como Escolher um Modelo a Partir Destes Resultados

Não existe um modelo "melhor" único neste benchmark — os resultados apoiam a escolha por prioridade, e a mesma tabela responde a diferentes perguntas. Três prioridades comuns mapeiam diretamente para os dados:

• Se o objetivo é a precisão bruta de transcrição (indexação de texto completo, digitalização legível por humanos): o docTR lidera com 19,7% de CER e também é o mais rápido e barato, com 256,0 páginas/min e US$ 0,049 por 1.000 páginas — ele vence simultaneamente em precisão de texto, velocidade e custo.
• Se o objetivo é a extração estruturada de campos (alimentar sistemas downstream que precisam de empresa/data/total): o PaddleOCR lidera com 32,5% de F1 de campo, mas mesmo isso é uma taxa de falha de campo de ~2 em 3 — a conclusão honesta é que nenhum desses mecanismos de OCR de código aberto, isoladamente, oferece extração de campos de recibos de nível de produção sem uma camada de extração estruturada por cima.
• Se o custo em volume é a restrição: a dispersão de custo de 7,8× significa que um milhão de páginas custa cerca de US$ 49 com docTR versus US$ 381 com Docling — uma diferença de ~US$ 332 por milhão de páginas em hardware idêntico.

Qualquer que seja a prioridade aplicável, o protocolo e os artefatos permitem que você reproduza cada número desta tabela em sua própria GPU antes de se comprometer — e, para um fluxo de recibos multilíngue, os resultados do CORD são o alerta de que modelos treinados em inglês devem ser testados sob estresse no idioma-alvo primeiro.

Perguntas Frequentes

Qual modelo de OCR de código aberto é mais preciso em recibos?

Depende da métrica: docTR tem a melhor precisão de texto (19,7% CER em 361 recibos SROIE) enquanto PaddleOCR tem a melhor extração de campos (32,5% F1 de campo) no ImageToTable.ai Receipt OCR Benchmark. Nenhum modelo lidera em ambos — precisão de texto e extração de campos são camadas diferentes do pipeline.

Por que a precisão de texto do docTR é melhor, mas sua extração de campos é pior que a do PaddleOCR?

Porque as duas métricas medem camadas diferentes do pipeline. O docTR leu caracteres com mais precisão (19,7% CER vs 20,5%), mas sua saída não correspondeu aos padrões fixos de regex para empresa/data/endereço/total, reduzindo seu F1 de campo pós-processado para 7,7% enquanto o PaddleOCR alcançou 32,5%. Texto mais limpo não garante melhor extração de campos quando o formato do valor (símbolos de moeda, separadores de vírgula, layout multilinha) diverge do padrão de extração.

O PaddleOCR é melhor que o Tesseract para OCR de recibos?

Sim, em todas as métricas deste benchmark: o PaddleOCR supera o Tesseract em CER (20,5% vs 33,6%), WER (32,6% vs 56,2%), F1 de campo (32,5% vs 23,2%), velocidade (157,8 vs 54,4 páginas/min) e custo ($0,080 vs $0,233 por 1.000 páginas) no conjunto de teste SROIE de 361 recibos.

A precisão do OCR cai para recibos não ingleses?

Dramaticamente: em 100 recibos indonésios CORD v2, todos os modelos treinados em inglês pontuaram 90–95% CER (PaddleOCR 90,8% melhor, Tesseract 95,2% pior) versus 20–58% em recibos SROIE em inglês. Trate isso como um teste de estresse de idioma, não como um ranking de modelos — os mesmos modelos não foram treinados para indonésio.

Quanto custa o OCR de código aberto por página em uma GPU?

Entre $0,049 e $0,381 por 1.000 páginas em uma RTX 4090 à taxa registrada da RunPod de $0,76/hora — aproximadamente $0,00005 a $0,0004 por página, incluindo a inicialização da execução, dependendo do modelo.

O que é o SROIE e o que ele testa?

SROIE 2019 (Scanned Receipt OCR and Information Extraction) é o conjunto de dados da competição ICDAR 2019 de recibos em inglês digitalizados com transcrição e anotações de campos-chave — este benchmark usa a divisão fixa de teste com 361 amostras. Ele testa se um modelo de OCR consegue ler o texto do recibo (CER/WER) e recuperar os campos de empresa, data, endereço e total; para os modelos de código aberto aqui, os campos foram recuperados por um pós-processador de regex fixo, pois nenhum deles emite campos estruturados nativos.

Posso reproduzir esses números do benchmark por conta própria?

Sim. O protocolo do benchmark é versionado e congelado, todos os conjuntos de dados são publicamente disponíveis (SROIE do ICDAR 2019, CORD v2 da Clova AI), e todos os cinco modelos são de código aberto com versões publicadas. O pacote completo de artefatos — predições, métricas, manifestos, logs de desempenho — está disponível mediante solicitação. Uma ressalva: os manifestos atuais são anteriores à impressão digital do ambiente do esquema v2, e uma nova execução nos ambientes exatos dos modelos seria necessária para reprodutibilidade byte a byte completa; veja Limitações.

Metodologia & Fontes

Protocolo

Este benchmark segue um protocolo versionado e congelado (v0.1, 2026-08-11). Cada número nesta página remonta a um artefato de predição específico produzido sob o protocolo, e cada execução atende ao mesmo conjunto de portões de publicação: run_tier=official, expected_split=test, sem predições ausentes, e todas as métricas not_applicable preservadas como estão (não convertidas em zero). Uma auditoria de qualidade (2026-08-12) verificou todos os contratos de predição, hashes de amostras e hashes de desempenho.

Ambiente de Execução

Como Reproduzir

O código do benchmark, os executores e os avaliadores são mantidos no repositório ImageToTable.ai benchmark-ocr (commit do Git 8bdc616; lançamento público pendente). Os comandos exatos que produziram cada número nesta página:

export BENCHMARK_RUN_TIER=official
export BENCHMARK_EXPECTED_SPLIT=test
export BENCHMARK_MEASUREMENT_MODE=warm_then_scored
export BENCHMARK_GPU_LABEL="rtx_4090"
export BENCHMARK_GPU_PROVIDER="runpod"
export BENCHMARK_GPU_HOURLY_USD="0.76"
export BENCHMARK_FIELD_POSTPROCESSOR=sroie_receipt_regex

for model in tesseract paddleocr easyocr doctr docling; do
  BENCHMARK_WARMUP_SAMPLES=sroie_warmup_5.jsonl \
    bash server/run_model.sh "$model" sroie 361 "receipt-v1-sroie-${model}"
done

unset BENCHMARK_FIELD_POSTPROCESSOR

for model in tesseract paddleocr easyocr doctr docling; do
  BENCHMARK_WARMUP_SAMPLES=cord_v2_warmup_5.jsonl \
    bash server/run_model.sh "$model" cord_v2 100 "receipt-v1-cord-v2-${model}"
done

Todos os modelos usados out-of-the-box com configurações padrão. Sem fine-tuning, sem pacotes de idioma personalizados, sem adaptações pós-treinamento. Consulte o repositório do benchmark para scripts de execução por modelo e configuração do ambiente.

Definições de Métricas

• CER (Character Error Rate, taxa de erro de caracteres): distância de edição de Levenshtein no nível de caracteres dividida pela contagem de caracteres do ground-truth (quanto menor, melhor). IC bootstrap de 95% via 2.000 reamostragens, semente 20260811.
• WER (Word Error Rate, taxa de erro de palavras): distância de edição de Levenshtein no nível de palavras (tokenização por espaços em branco) dividida pela contagem de palavras do ground-truth (quanto menor, melhor). Mesmo método de IC do CER.
• Field F1 (F1 de campo, apenas SROIE): média harmônica de precisão e revocação nos quatro campos do SROIE (empresa, data, endereço, total), extraídos do texto de OCR por um pós-processador de regex fixo (sroie_receipt_regex). NÃO é saída nativa de campos estruturados do modelo — todos os cinco modelos têm não aplicável para métricas nativas de campo.
• Latência p50 / p95: tempo de inferência por página (ms) a partir de registros de predição bem-sucedidos, excluindo a inicialização do runner.
• Páginas/min em tempo real: total de amostras avaliadas dividido pelo tempo total de execução, incluindo a inicialização do processo do runner. Quanto maior, melhor.
• Custo por 1.000 páginas: tempo de execução (horas) × $0,76 × (1.000 / contagem de amostras). Usa metadados reais de preço do provedor, não taxas estimadas.
• Taxa de sucesso: 100% para todas as 10 execuções deste lote (0 erros, 0 timeouts, 0 predições ausentes).

Conjuntos de Dados

1. SROIE 2019 (Scanned Receipt OCR and Information Extraction) — ICDAR 2019 Robust Reading Competition, Task 3. 361 recibos digitalizados reais em inglês com transcrição de texto em nível de linha e rótulos de ground-truth de quatro campos-chave (empresa, data, endereço, total). Divisão de teste fixa.
2. CORD v2 (Consolidated Receipt Dataset) — Clova AI Research, NAVER Corp. 100 amostras revisadas de recibos em indonésio da divisão de teste pública, usadas como teste de estresse entre idiomas. Inclui itens de menu aninhados e ground-truth de subtotal/total (não avaliados neste lote — requer emissores nativos de campos estruturados).

Modelos Testados

Acesso aos Artefatos e Reprodutibilidade

Código-fonte do benchmark: mantido no repositório benchmark-ocr (commit do Git 8bdc616). O repositório inclui scripts de execução por modelo, avaliadores (CER/WER, métricas de campo, bootstrap CI), manifestos de amostras de conjuntos de dados com hashes SHA256 e o protocolo congelado. O lançamento público está pendente — uma vez publicado, cada número nesta página será independentemente reproduzível clonando o repositório, obtendo os conjuntos de dados públicos e executando os comandos acima em uma RTX 4090.

Pacote completo de artefatos: predições por modelo (*.jsonl), métricas com IC de 95% (metrics.csv), diagnósticos em nível de campo (field_details.csv), logs de desempenho em tempo real (performance.json) e manifestos de execução (manifest.json) são versionados sob o protocolo e disponibilizados junto ao código-fonte. Contate [email protected] para acesso antecipado antes do lançamento público.

Nota sobre o esquema v1: os manifestos atuais são anteriores à impressão digital do ambiente do esquema v2 (que captura OS, versão CUDA e versões de pacotes Python por modelo em tempo de execução). A tabela de ambiente acima reflete o que o esquema v1 registra; a reprodutibilidade byte por byte exigirá uma nova execução com o esquema v2. Isso não afeta a correção das métricas relatadas.

Limitações

• Esquema de manifesto v1: os manifestos de execução atuais são anteriores à impressão digital de ambiente do esquema v2, que captura o ambiente Python exato no momento da execução. A reprodutibilidade byte por byte completa exige uma nova execução do esquema v2 nos ambientes exatos dos modelos.
• As métricas de campo do SROIE são pós-processadas por regex, não extração nativa: o F1 de campo mede a recuperação de campos a partir do texto de OCR por meio de padrões fixos — não é a capacidade nativa de campos estruturados dos modelos (que não está disponível para nenhum modelo neste lote).
• Os resultados do CORD são um teste de estresse por incompatibilidade de idioma, não uma classificação de precisão: todos os cinco modelos são treinados em inglês; os valores de CER do CORD (90%+) quantificam o colapso entre idiomas e não devem ser mesclados com o SROIE em um único ranking.
• PaddleOCR-VL bloqueado da classificação: excluído devido a problemas diretos de pipeline; seus resultados não são comparáveis aos cinco modelos classificados.
• Surya2 e Unlimited-OCR não incluídos: eles exigem um Pod de servidor vLLM e estão planejados para um lote v1.1; o lançamento atual cobre apenas o grupo local_torch.
• Apenas camada de GPU única: todas as execuções são em RTX 4090; ainda não há comparação multi-GPU ou RTX 3090/A100 disponível, portanto as conclusões de custo/throughput são específicas para esta única camada.
• Apenas modelos de código aberto: nenhum modelo de nuvem/API (AWS Textract, Google Document AI, Azure Form Recognizer) está incluído; a comparação deles é um benchmark separado planejado.

Referências relacionadas: Precisão de OCR de Recibos · Precisão de OCR por Tipo de Documento · O que é OCR?

Leitura relacionada: ABBYY FineReader vs OCR Moderno com IA · Adobe Acrobat OCR vs Extração com IA · Como Interpretar Alegações de Precisão de OCR