Tesseract vs PaddleOCR em Notas Fiscais
CPU Legado vs GPU Moderna (2026)

O que são os Dois Motores: 35 Anos de OCR vs um Pipeline CNN de Duas Etapas

Toda a história desta página é uma lacuna de arquitetura. Tesseract é o clássico motor de OCR de código aberto — originalmente desenvolvido na HP nos anos 1980 e tornado de código aberto pelo Google em 2005, razão pela qual possui cerca de 35 anos de linhagem. Seu pipeline é de visão computacional tradicional: binarização adaptativa, segmentação de página, análise de componentes conectados e reconhecimento de caracteres — baseado em LSTM desde a versão 4 — tudo executado na CPU sem cobrança de GPU neste benchmark (compute_type = cpu no CSV). PaddleOCR é um motor moderno de aprendizado profundo do ecossistema PaddlePaddle: um pipeline de duas etapas na família PP-OCR — uma etapa de detecção que localiza regiões de texto (estilo DBNet), seguida de uma etapa de reconhecimento que as transcreve — rodando na GPU. Um motor lendo correspondendo formas de caracteres a padrões aprendidos; o outro lendo aprendendo onde está o texto e o que ele diz. Este benchmark submete ambos aos mesmos recibos, mesmo protocolo, mesma máquina.

Por que este mecanismo importa: a abordagem do Tesseract é barata de executar e não precisa de GPU — mas seu modelo de caracteres é uma congelada de décadas de reconhecimento clássico, o que se manifesta como um teto rígido na qualidade do texto. A abordagem do PaddleOCR custa tempo de GPU, mas lê texto substancialmente mais limpo. O trabalho do benchmark é colocar um número em ambos os lados dessa troca a partir de uma única execução controlada — e a surpresa é quão estreita a lado do custo operacional da troca se revelou.

Precisão de Caracteres: A Arquitetura Moderna Vence Todas as Métricas de Texto

No SROIE 2019, a lacuna de precisão de texto é grande e unilateral: CER 0.2045 vs 0.3347 (Tesseract) — uma melhoria relativa de 39% — e WER 0.3256 vs 0.5591, uma lacuna relativa de 42%. O CER do Tesseract de 0.3347 classifica-o em quinto lugar entre os oito motores na execução subjacente — no meio do pacote, não no último — mas todos os motores acima dele, exceto um, são motores de aprendizado profundo, e a lacuna entre o Tesseract e o nível de aprendizado profundo (melhor: Surya2 0.1915, docTR 0.1971) é maior do que a lacuna entre esses motores e o PaddleOCR (0.2045, terceiro).

A Taxa de Erro de Caracteres (CER) é a régua clássica de OCR: inserções, exclusões e substituições divididas pelos caracteres do texto verdadeiro — um CER de 0.335 significa cerca de 33,5 caracteres mal lidos a cada 100. A Taxa de Erro de Palavras (WER) aplica o mesmo cálculo de distância de edição em granularidade de palavra. Ambos são do tipo "menor é melhor". A lacuna de WER (42%) ser mais ampla do que a lacuna de CER (39%) significa que os deslizes de caracteres do Tesseract se combinam em falhas de palavras inteiras neste corpus — o modo de falha do motor clássico que um extrator de campos downstream herda diretamente.

Fonte: summary_metrics.csv — colunas cer e wer, linhas sroie_2019. PaddleOCR cer 0.20449 / wer 0.32563; Tesseract cer 0.33468 / wer 0.55915. 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: Tesseract cer 0.33468 / wer 0.55915; PaddleOCR cer 0.20449 / wer 0.32563. CER/WER menor é melhor. Contexto de classificação do mesmo CSV: CER do SROIE em todos os oito motores: surya2 0.1915, doctr 0.1971, PaddleOCR 0.2045 (3º), easyocr 0.2833, Tesseract 0.3347 (5º), paddleocr_vl 0.3370, docling 0.5909, unlimited_ocr 0.6552. Nenhum dos dois motores aqui é o campeão de precisão do benchmark — docTR e Surya2 ocupam as duas primeiras posições no CER.

Extração de Campos: A Lacuna que Decide Decisões de Produção

A precisão do texto classifica os motores; a extração de campos é o que os sistemas downstream realmente consomem. As métricas de campo do benchmark SROIE 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. Através do regex, o PaddleOCR extrai campos com 0.3254 F1 de campo contra 0.2335 do Tesseract — uma vantagem de 1,39×; através do LLM, a lacuna persiste em 0.5810 vs 0.4389 (1,32×). A vantagem do LLM ajuda ambos os motores, mas parte da base mais fraca do Tesseract — e o argumento do teto que decide os pipelines de produção está na seção abaixo.

O F1 de valor de campo é a média harmônica de precisão e recall sobre os valores dos campos extraídos em relação à verdade de campo — 1.0 significa que cada campo do recibo foi perfeitamente recuperado, 0 significa nada. As colunas de regex de campo SROIE são as métricas postprocessed_sroie_receipt_regex_* do benchmark: padrões fixos aplicados ao texto OCR de cada engine — pós-processados, não a saída estruturada nativa. Contexto de classificação: o F1 de regex do PaddleOCR de 0,3254 é o melhor entre as quatro engines puramente tradicionais no benchmark de 8 engines (atrás apenas do Unlimited-OCR 0,3376 e do PaddleOCR-VL 0,3368); o 0,2335 do Tesseract é o quarto melhor resultado de regex no geral (summary_metrics.csv, field_f1_regex, sroie_2019 rows) — a engine clássica é um extrator de campos mediano em texto inglês limpo, que é exatamente onde ela deixa de ser competitiva.

Fonte: field_method_comparison.csv — colunas regex_field_value_f1 / llm_field_value_f1, sroie_2019 rows (0–1 decimais armazenados mostrados como %). Pós-processador LLM: deepseek-v4-flash (coluna llm_model). 361 amostras por engine (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 a temperatura 0 (coluna llm_model). A latência LLM é causada pela API e separada da latência da engine (latência p50_ms em summary_metrics.csv). “Docs com todos os campos exatos” é a fração de documentos onde cada campo alvo correspondeu exatamente — um critério muito mais rigoroso do que o F1 por campo. Contexto de classificação (llm_field_value_f1, todas as linhas sroie_2019): PaddleOCR 0.5810 ocupa a 5ª posição de 8; Tesseract 0.4389 ocupa a 7ª, à frente apenas do EasyOCR com 0.3717.

A Surpresa: Paridade de Throughput de CPU no Relógio

A descoberta digna de manchete desta página é a que nenhuma comparação de terceiros documenta: nos mesmos recibos, uma engine clássica apenas de CPU iguala uma engine moderna de GPU em páginas por minuto no relógio — 78.6 vs 79.7 (PaddleOCR), cerca de 1.4% de diferença, paridade estatística. A engine clássica não é “lenta em volume”: é lenta por página, mas constante — e neste corpus ela supera quatro das sete engines GPU na execução subjacente (docling 56.7, paddleocr_vl 68.2, unlimited_ocr 34.4, surya2 12.1 páginas/min).

Isso parece uma contradição com os números de latência, e merece uma reconciliação honesta em vez de uma nota de rodapé. A latência p50 é a inferência por página em estado estacionário, medida aquecida e depois pontuada, com o carregamento do modelo excluído — os 297,0 ms do PaddleOCR são genuinamente mais rápidos que os 670,9 ms do Tesseract. Páginas por minuto é o throughput no relógio de toda a execução, incluindo inicialização do modelo e efeitos de lote. Converta o throughput do CSV para tempo por página no relógio (60 segundos ÷ páginas_por_minuto): PaddleOCR gasta ~753 ms por página no relógio contra um p50 de 297 ms — cerca de 456 ms por página de inicialização/prefill e sobrecarga de lote; Tesseract gasta ~763 ms por página no relógio contra um p50 de 671 ms — cerca de 92 ms de sobrecarga. O runtime de CPU simplificado do Tesseract inicia rápido e flui de forma constante; o pipeline de GPU do PaddleOCR paga um custo maior de carga/prefill por execução que quase cancela sua vantagem em estado estacionário neste corpus de 361 páginas. Um pipeline longo e aquecido vê a vantagem por página do PaddleOCR; um pipeline dominado por inícios frios, lotes pequenos ou reinicialização frequente vê as duas engines em paridade ou melhor do lado da clássica.

A cauda p95 conta a mesma história em um número: o p95 do Tesseract de 1.507,0 ms é 2,2× mais apertado que o do PaddleOCR de 3.331,4 ms. O pico de primeira página/prefill da engine GPU — o mesmo caminho de carregamento que infla seu tempo por página no relógio — domina sua cauda de pior caso, enquanto a engine CPU não tem tal pico. Para cargas de trabalho sensíveis à latência de cauda ou com planejamento de capacidade, a engine clássica é a mais previsível.

Fonte: summary_metrics.csv — coluna pages_per_minute, linhas sroie_2019. Tesseract 78.63285, PaddleOCR 79.71298. Páginas/minuto em tempo real incluindo inicialização do modelo; a latência por página em regime estacionário é a coluna latency_p50_ms (veja o gráfico abaixo). Reconciliação: 60 ÷ 78.63285 = 763 ms/página vs 60 ÷ 79.71298 = 753 ms/página em tempo real.

Fonte: summary_metrics.csv — colunas latency_p50_ms / latency_p95_ms, linhas sroie_2019. Tesseract p50 670,87 / p95 1506,99; PaddleOCR p50 296,99 / p95 3331,35. Latência em regime estacionário (modo de medição warm_then_scored, exclui carregamento do modelo). A tensão entre p50 e páginas/minuto é reconciliada no texto acima: diferentes relógios, ambos reais.

Tabela: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, linhas sroie_2019. Valores exatos: Tesseract p50 670,87 / p95 1506,99 / 78,63 pg/min; PaddleOCR p50 296,99 / p95 3331,35 / 79,71 pg/min. A latência é por página em regime estacionário (aquecido e pontuado, exclui carregamento do modelo); páginas/min é em tempo real incluindo iniciação e efeitos de lote — a paridade e a inversão do p95 são fatos do modelo de medição e da arquitetura, não contradições.

A História do Custo: Onde o Motor Legado Vence de Forma Abrutal

O custo é o único eixo onde a idade do Tesseract é uma vantagem, e é uma vantagem estrutural: o Tesseract é apenas CPU, então sua célula de custo no CSV está vazia por design — sem cobrança de GPU para medir — enquanto o PaddleOCR cobra $0.2214 por 1.000 páginas na mesma RTX 4090 a $0.76/hora registrados. Para uma carga de trabalho vinculada ao throughput (a paridade acima), o custo operacional do motor clássico em infraestrutura sem cobrança de GPU é materialmente menor — a âncora de preço para a decisão "vale a pena atualizar?".

O custo é calculado como tempo de execução em relógio × a taxa da RunPod RTX 4090 ($0.76/hora, preço com carimbo de tempo nos manifests de execução), incluindo inicialização do modelo. A célula vazia do Tesseract não é um zero — é um valor ausente porque o motor nunca tocou na GPU; o benchmark a registra como vazia em vez de assumir um número (regra de protocolo: uma célula vazia é not_applicable, nunca 0). Dois números de contexto mantêm isso honesto: o valor de $0.2214 do PaddleOCR está na metade entre os sete motores GPU (o docTR detém a linha GPU mais barata do benchmark em $0.048 por 1.000 páginas), e no CORD o custo do PaddleOCR sobe para $0.3419 por 1.000 páginas a 141.0 páginas/min.

Fonte: summary_metrics.csv — coluna cost_per_1000_pages, linhas sroie_2019. PaddleOCR 0.2214. O valor do Tesseract está vazio (célula em branco no CSV): tipo de computação apenas CPU, sem cobrança de GPU — plotado como omitido, não zero. Custo = tempo de execução em relógio × $0.76/hora incluindo inicialização do modelo, preço com carimbo de tempo nos manifests de execução (agosto de 2026). Motor GPU mais barato no benchmark: docTR $0.048 por 1.000 páginas (linha doctr/sroie_2019).

Tabela: summary_metrics.csv — colunas cost_per_1000_pages / compute_type, linhas sroie_2019. A célula de custo do Tesseract está vazia (em branco, não 0.0000) porque o motor é apenas CPU; o custo de GPU do PaddleOCR inclui inicialização do modelo a $0.76/hora registrados. No CORD, o custo do PaddleOCR é $0.3419 por 1.000 páginas a 141.0 páginas/min (linha paddleocr/cord_v2).

CORD (Recibos Indonésios): Ambos Colapsam — e a Maior Lacuna de Campos no Benchmark se Abre

Nenhum dos motores foi treinado predominantemente em recibos indonésios, então o CORD v2 (100 amostras, campos aninhados menu/sub_total/total) funciona como um teste de estresse entre idiomas — e ambos colapsam no CER bruto: 0.9083 (PaddleOCR) e 0.9523 (Tesseract), um empate por incompatibilidade de idioma. De acordo com o protocolo do benchmark, os números do CORD são mantidos em quarentena da comparação com o SROIE — nunca mesclados em qualquer classificação — 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.

Onde os dois motores realmente se separam é na alavanca de campos por LLM, e este é o ponto de dados mais forte desta página: através do pós-processador LLM, o F1 de campos do CORD do PaddleOCR se mantém em 0.5527 — o melhor de todos os oito motores no CORD — enquanto o do Tesseract colapsa para 0.1627, o pior de todos os oito motores em todo o benchmark. Essa diferença de 0,39 pontos é a maior lacuna entre quaisquer duas linhas irmãs de campos LLM na execução. O mecanismo é o argumento do teto tornado concreto: o texto do CORD do Tesseract é ilegível o suficiente (CER 0.9523) que nenhum pós-processador — regex ou LLM — pode recuperar campos dele. A alavanca LLM ajuda (o F1 do SROIE do Tesseract sobe de 0.2335 regex para 0.4389 LLM), mas começa de uma base mais fraca e não pode fabricar texto que o motor nunca leu. O CORD é citado aqui para contexto de robustez entre idiomas; é 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 mesclar números CORD em qualquer ranking SROIE: O CER do CORD combina incompatibilidade genuína de idioma com inflação de estrutura de anotação no ground truth, e os padrões regex foram escritos para formatos em inglês (o regex F1 de ambos os motores colapsa para ~1–8%). Contexto de ranking (llm_field_value_f1, todas as linhas cord_v2): PaddleOCR 0.5527 é o melhor de oito; Tesseract 0.1627 é o pior de oito — a maior lacuna entre linhas irmãs no benchmark. A célula de custo do Tesseract está vazia (somente CPU), nunca 0.

Quem Vence Quando: O Quadro Resumo

“Melhor” depende da carga de trabalho, e esta comparação direta divide os eixos com clareza incomum: cada eixo de precisão favorece PaddleOCR; custo, simplicidade de CPU e a cauda p95 apertada favorecem Tesseract; o throughput em tempo real é um empate estatístico; a latência por página favorece PaddleOCR; e o campeonato de CER bruto não pertence a nenhum (docTR/Surya2).

Perguntas Frequentes

O PaddleOCR é mais preciso que o Tesseract em recibos?

Sim — em todos os eixos de precisão medidos neste benchmark. No SROIE 2019: CER 0.2045 vs 0.3347 (melhoria relativa de 39%), WER 0.3256 vs 0.5591 (42%), F1 de campos por regex 0.3254 vs 0.2335 (1,39×), F1 de campos pós-processados por LLM 0.5810 vs 0.4389 (1,32×) (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.

Por que o Tesseract acompanha o PaddleOCR em páginas por minuto, apesar de ser apenas CPU?

Porque páginas por minuto é throughput de relógio real, não velocidade de inferência por página. O p50 em regime estável do PaddleOCR (297,0 ms) é genuinamente 2,3× mais rápido que o do Tesseract (670,9 ms), mas o throughput de relógio real inclui inicialização do modelo e efeitos de lote: a 79,7 páginas/min, o PaddleOCR gasta ~753 ms por página no relógio real contra seu p50 de 297 ms, enquanto o runtime CPU simplificado do Tesseract gasta ~763 ms por página contra seu p50 de 671 ms — o motor GPU paga um custo maior de carga/prefill por execução que quase cancela sua vantagem de velocidade neste corpus de 361 páginas (summary_metrics.csv, pages_per_minute / latency_p50_ms, linhas sroie_2019).

Por que a latência p95 do Tesseract é mais apertada que a do PaddleOCR?

Porque o pico de primeira página/prefill do motor GPU domina sua cauda de pior caso: PaddleOCR p95 3.331,4 ms vs Tesseract p95 1.507,0 ms, uma inversão de 2,2× da ordem do p50 (summary_metrics.csv, latency_p95_ms, linhas sroie_2019). O pipeline CPU do Tesseract não tem pico de carga e flui de forma estável; o estado estável rápido do PaddleOCR vem com uma rotação de inicialização mais pesada a cada execução. Os dois relógios medem coisas diferentes e ambos são reais.

O Tesseract é mais barato que o PaddleOCR?

Na cobrança por GPU, sim — o Tesseract não tem nenhuma: ele é apenas CPU, então sua célula de custo no CSV está vazia por design (nunca 0), enquanto o PaddleOCR cobra $0.2214 por 1.000 páginas no SROIE e $0.3419 no CORD, no mesmo RTX 4090 a $0.76/hora com custo incluindo inicialização do modelo (summary_metrics.csv, cost_per_1000_pages, sroie_2019 e cord_v2). O motor GPU mais barato do benchmark no geral é o docTR a $0.048 por 1.000 páginas.

Por que o F1 de campo LLM do Tesseract no CORD é o pior de todo o benchmark?

Porque o pós-processador LLM não pode recuperar texto que o motor OCR nunca leu. O CER do Tesseract no CORD é 0.9523 — praticamente ilegível em recibos indonésios — então seu F1 de campo LLM colapsa para 0.1627, o pior dos oito motores, enquanto o do PaddleOCR se mantém em 0.5527, o melhor dos oito (field_method_comparison.csv, llm_field_value_f1, cord_v2). A mesma alavanca em texto inglês limpo (SROIE) eleva o Tesseract para 0.4389 — mas o teto é definido pela qualidade básica do texto.

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

Duas causas combinadas que o protocolo mantém separadas do ranking SROIE: uma verdadeira incompatibilidade de idioma (recibos indonésios fora do foco de treinamento de ambos os motores) e inflação da estrutura de anotação dentro do texto ground-truth do CORD — o CER fica em 0.9083 (PaddleOCR) e 0.9523 (Tesseract) (summary_metrics.csv, cer, cord_v2). O que ainda os separa é a recuperação downstream via LLM: PaddleOCR 0.5527 vs Tesseract 0.1627 F1 de campo — a maior lacuna entre linhas irmãs no benchmark. As linhas do CORD são citadas com enquadramento e nunca são agrupadas em nenhum ranking combinado.

Qual engine um pipeline de recibos deve escolher, Tesseract ou PaddleOCR?

Se seu pipeline consome campos — valores extraídos para empresa, data, totais — PaddleOCR é o padrão claro para recibos: 1,39× de F1 de campos com regex, 1,32× com um LLM, e recuperação downstream com LLM que sobrevive ao choque de idioma do CORD (field_method_comparison.csv). Se você precisa de texto bruto em alto volume em documentos limpos em inglês com custo zero de GPU, infraestrutura apenas com CPU, ou previsibilidade de latência de cauda, Tesseract continua sendo uma opção legítima: throughput de relógio de parede empatado (79,7 vs 78,6 páginas/min), p95 é 2,2× mais apertado, e não há cobrança de GPU — mas orçamento para uma base de texto intermediária (CER 0,3347, 5º de 8) que limita cada pipeline de campos downstream. Esses resultados valem para recibos em inglês e indonésios 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 parte — results/summary_metrics.csv (CER/WER, F1 de campos com regex, latência, custo, throughput; linhas do tesseract têm compute_type=cpu e uma célula de custo vazia) 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 censurado por execução para impressões digitais do ambiente. As definições do conjunto de dados vêm dos artigos SROIE 2019 e CORD citados abaixo.

Metodologia & Fontes

Protocolo

Esta página relata um recorte direto de uma execução de benchmark independente e reproduzível (camada oficial) — não um levantamento de alegações de terceiros, e não uma página de comparação de fornecedores. Apenas divisões de teste fixas: teste SROIE 2019 (361 recibos em inglês, campos planos empresa/data/endereço/total) e teste CORD v2 (100 recibos indonésios, campos aninhados menu/sub_total/total); divisões de treinamento nunca foram avaliadas. Ambos os engines viram as mesmas imagens, a mesma verdade fundamental e o mesmo protocolo de medição (warm_then_scored: uma passagem de aquecimento fixa precede a passagem pontuada, então os valores de latência são em regime permanente). Ambas as execuções foram concluídas com error_rate 0.0 em ambos os conjuntos de dados (coluna error_rate do summary_metrics.csv). A assimetria CPU/GPU é inerente a esta comparação: Tesseract rodou em CPU (compute_type=cpu) contra engines acelerados por GPU, por design — sua célula de custo está vazia porque nenhum tempo de GPU foi cobrado, e sua latência/throughput foram medidas na mesma máquina sob o mesmo protocolo. A execução subjacente contém oito engines no total; esta página compara apenas os dois engines nomeados, com outros engines citados apenas como contexto de classificação. Os resultados completos dos 8 engines são publicados separadamente em Traditional OCR vs Document Parsing VLMs.

Ambiente de Execução

• Hardware: ambos os motores rodaram na mesma máquina com uma NVIDIA RTX 4090 (24 GB); o custo da GPU foi calculado na taxa sob demanda do RunPod de $0.76/hr, com o preço datado no manifesto redatado de cada execução (agosto de 2026). O Tesseract rodou na CPU e não gerou custo de GPU; sua célula de custo está vazia por design.
• Motores: prontos para uso, sem ajuste fino. Versões bloqueadas: Tesseract 5.3.4 (motor OCR clássico de código aberto — pipeline de CV tradicional com reconhecimento baseado em LSTM, apenas CPU, executor python3 do sistema, sem ambiente GPU) e PaddleOCR 3.7.0 (OCR moderno de aprendizado profundo em duas etapas — detecção + reconhecimento PP-OCR, GPU) — conforme a tabela de modelos do repositório público (README.md) e os manifestos de execução.
• Pós-processador LLM: deepseek-v4-flash via API com temperatura 0 para saída determinística (a coluna llm_model no field_method_comparison.csv); foi o único modelo usado para todas as linhas de campo LLM em ambos os motores.
• Base de custo: tempo de execução real × $0.76/hr, incluindo inicialização do modelo — o processamento em lote reduz o custo por página; não aplicável ao Tesseract (apenas CPU).
• Pós-processamento de campos: as métricas de campos regex do SROIE são postprocessed_sroie_receipt_regex_* (colunas regex_* no 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 (Taxa de Erro de Caractere): distância de edição (inserções + exclusões + substituições) entre o texto OCR e a verdade fundamental, dividida pelos caracteres da verdade fundamental. Quanto menor, melhor.
• WER (Taxa de Erro de Palavra): o mesmo cálculo de distância de edição em granularidade de palavra.
• F1 de valor de campo (regex): média harmônica de precisão/recall sobre valores de campo extraídos usando padrões regex fixos no texto OCR (pipeline tradicional de OCR + KIE baseado em regras). Coluna: regex_field_value_f1. Uma pontuação de 0 significa que nenhum valor de campo foi recuperado.
• F1 de valor de campo (LLM): a mesma métrica na saída do pós-processador LLM (texto OCR → deepseek-v4-flash → campos). Coluna: llm_field_value_f1. Os dois pipelines são diferentes e nunca são misturados.
• Campos do documento exatos: fração de documentos onde todos os campos alvo corresponderam exatamente — um critério muito mais rigoroso que o F1 por campo.
• Latência p50/p95 e páginas/min: tempo de inferência por página em regime permanente (aquecido-avaliado, exclui carregamento do modelo) e throughput em tempo real incluindo inicialização do modelo. Eles medem relógios diferentes; a paridade p50-vs-páginas/min nesta página é um fato do modelo de medição, não um erro, e é reconciliada na seção Paridade de Throughput.
• Custo por 1.000 páginas: horas de GPU cobradas para 1.000 páginas na taxa registrada de $0.76/hr, incluindo inicialização do modelo. A célula do Tesseract está vazia (apenas CPU) — uma célula vazia é not_applicable, nunca 0.

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 rastreáveis até as linhas do tesseract e paddleocr aqui (tesseract: compute_type=cpu, célula de custo vazia).
2. field_method_comparison.csv (GitHub raw). 16 linhas; colunas model, dataset, llm_model (= deepseek-v4-flash), acurácia e F1 de campo-valor regex/llm, document-fields-exact, llm_median_latency_ms, contagens de tokens. Todos os números de F1 de campo regex/LLM são rastreáveis até as linhas do tesseract e paddleocr aqui (e até todas as oito linhas sroie_2019 / cord_v2 no contexto de classificação).
3. Repositório ImageToTableai/benchmark-ocr. Repositório público que hospeda os CSVs de resultados, manifestos 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 de 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

• Assimetria CPU/GPU é inerente, não uma falha: O Tesseract rodou em CPU contra engines aceleradas por GPU. Sua célula de custo é vazia por design (sem faturamento de GPU, nunca 0), e sua latência/throughput são números de CPU medidos na mesma máquina sob o mesmo protocolo — uma classe de máquina diferente poderia alterar seu envelope operacional. Trate a comparação de custos como "faturamento de GPU vs nenhum", não como uma verdade independente de hardware.
• Escopo do documento — apenas recibos: SROIE + CORD. Nada aqui mede o comportamento do Tesseract em layouts complexos, tabelas, escrita à mão ou documentos longos — tipos de documento onde é conhecido que engines clássicas degradam mais — nem as capacidades de layout/tabela do PP-Structure do PaddleOCR. Não use esta página para concluir que qualquer engine "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 (39% CER, 1,39× regex F1, a diferença de 0,39 pontos no CORD LLM-F1) estejam muito além dessa faixa.
• Tier de GPU única e preço único: todos os números de GPU 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 alterarã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 de campo; as lacunas de 1,32× no SROIE e de 0,39 pontos no CORD podem se mover nas margens. A latência do LLM (~1.817–1.837 ms mediana no SROIE, field_method_comparison.csv llm_median_latency_ms) é imposta pela API e não faz parte da latência própria de nenhuma engine.
• 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.
• CORD CER não é uma leitura de qualidade por modelo: a verdade básica do CORD incorpora a estrutura de anotação e nenhuma engine foi treinada predominantemente em indonésio; o CORD CER (0,91–0,95) reflete incompatibilidade de idioma + inflação da verdade básica. As linhas do CORD são citadas com enquadramento e nunca são mescladas em qualquer ranking do SROIE (regra de protocolo).
• Fixação de versão: os resultados valem para Tesseract 5.3.4 e PaddleOCR 3.7.0 (agosto de 2026). Versões mais recentes de qualquer engine podem alterar todos os números nesta página; os resultados do Tesseract especificamente refletem a 5.3.4 e foram re-verificados em uma execução de repetição em 2026-08-14.

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

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