Tesseract vs PaddleOCR em Recibos
CPU Legado vs GPU Moderna (2026)

O Que São os Dois Mecanismos: 35 Anos de OCR vs um Pipeline CNN de Dois Estágios

Toda a história desta página é uma diferença de arquitetura. O Tesseract é o mecanismo de OCR open-source clássico — originalmente desenvolvido na HP nos anos 1980 e disponibilizado como open-source pelo Google em 2005, razão pela qual carrega aproximadamente 35 anos de linhagem. Seu pipeline é 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 executando em CPU, sem cobrança de GPU neste benchmark (compute_type = cpu no CSV). O PaddleOCR é um mecanismo moderno de deep learning do ecossistema PaddlePaddle: um pipeline de dois estágios na família PP-OCR — um estágio de detecção que localiza regiões de texto (estilo DBNet) e, em seguida, um estágio de reconhecimento que as transcreve — executando em GPU. Um mecanismo lê comparando formas de caracteres com padrões aprendidos; o outro lê aprendendo onde o texto está e o que ele diz. Este benchmark submete ambos aos mesmos recibos, ao mesmo protocolo, à mesma máquina.

Por que esse mecanismo importa: a abordagem do Tesseract é barata de executar e não exige GPU — mas seu modelo de caracteres é congelado em 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ê um texto substancialmente mais limpo. O trabalho do benchmark é atribuir um número a ambos os lados dessa troca a partir de uma execução controlada — e a surpresa é quão estreito o lado do custo operacional dessa troca acabou sendo.

Precisão de Caracteres: A Arquitetura Moderna Vence em 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 de 0.3347 do Tesseract ocupa o quinto lugar entre os oito mecanismos na execução subjacente — meio do pelotão, não o último — mas todos os mecanismos acima dele, exceto um, são mecanismos de deep learning, e a lacuna entre o Tesseract e o nível de deep learning (melhor: Surya2 0.1915, docTR 0.1971) é maior do que a lacuna entre esses mecanismos e o PaddleOCR (0.2045, terceiro).

A Taxa de Erro de Caracteres (CER) é o critério clássico de OCR: inserções, exclusões e substituições divididas pelos caracteres de referência — um CER de 0.335 significa aproximadamente 33,5 caracteres lidos incorretamente por 100. A Taxa de Erro de Palavras (WER) aplica o mesmo cálculo de distância de edição na granularidade de palavras. Ambas são melhores quando menores. A lacuna de WER (42%) ser mais ampla do que a lacuna de CER (39%) significa que os deslizes de caracteres do Tesseract se acumulam em falhas de palavras inteiras neste corpus — o modo de falha do mecanismo clássico que um extrator de campos a jusante 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 mecanismo; ambos 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 menores são melhores. Contexto de classificação do mesmo CSV: CER SROIE em todos os oito mecanismos — 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 mecanismos aqui é o campeão de precisão do benchmark — docTR e Surya2 ocupam as duas primeiras posições de CER.

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

A precisão do texto classifica os mecanismos; a extração de campos é o que os sistemas downstream realmente consomem. As métricas de campo SROIE do benchmark visam quatro campos fixos de recibo (empresa, data, endereço, total) usando dois pós-processadores no texto OCR de cada mecanismo: padrões de 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. Por regex, o PaddleOCR extrai campos a 0.3254 de F1 de campo contra 0.2335 do Tesseract — uma vantagem de 1.39×; pelo LLM, a lacuna persiste em 0.5810 vs 0.4389 (1.32×). A alavanca do LLM ajuda ambos os mecanismos, mas parte da base mais fraca do Tesseract — e o argumento do teto que decide pipelines de produção está uma seção abaixo.

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

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

A Surpresa: Paridade de Throughput de CPU no Tempo Real

A descoberta mais notável desta página é aquela que nenhuma comparação de terceiros documenta: nos mesmos recibos, um mecanismo clássico somente CPU iguala um mecanismo GPU moderno em páginas por minuto no tempo real — 78.6 vs 79.7 (PaddleOCR), cerca de 1.4% de diferença, paridade estatística. O mecanismo clássico não é “lento em volume”: é lento por página, mas constante — e neste corpus supera quatro dos sete mecanismos 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, não apenas uma nota de rodapé. A latência p50 é a inferência por página em estado estável, medida após aquecimento e pontuação, 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 tempo real de toda a execução, incluindo inicialização do modelo e efeitos de lote. Converta o throughput do CSV em tempo real por página (60 segundos ÷ páginas_por_minuto): o PaddleOCR gasta ~753 ms por página no tempo real contra um p50 de 297 ms — cerca de 456 ms por página de inicialização/preenchimento e sobrecarga de lote; o Tesseract gasta ~763 ms por página no tempo real contra um p50 de 671 ms — cerca de 92 ms de sobrecarga. O runtime CPU enxuto do Tesseract inicia rápido e processa de forma constante; o pipeline GPU do PaddleOCR paga um preço maior de carregamento/preenchimento por execução que quase anula sua vantagem em estado estável neste corpus de 361 páginas. Um pipeline aquecido de longa duração vê a vantagem por página do PaddleOCR; um pipeline dominado por inicializações a frio, lotes pequenos ou reinicializações frequentes vê os dois mecanismos em paridade, ou com vantagem para o lado clássico.

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/preenchimento do mecanismo GPU — o mesmo caminho de carregamento que infla seu tempo por página no tempo real — domina sua cauda de pior caso, enquanto o mecanismo CPU não tem esse pico. Para cargas de trabalho sensíveis à latência de cauda ou com planejamento de capacidade, o mecanismo clássico é o mais previsível.

Fonte: summary_metrics.csv — coluna pages_per_minute, linhas sroie_2019. Tesseract 78.63285, PaddleOCR 79.71298. Páginas/min em tempo de relógio, incluindo inicialização do modelo; a latência por página em estado estável é 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 de relógio.

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 estado estável (modo de medição warm_then_scored, exclui carregamento do modelo). A tensão entre p50 e páginas/min é reconciliada no texto acima: relógios diferentes, 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 estado estável (medida após aquecimento, exclui carregamento do modelo); páginas/min é em tempo de relógio, incluindo inicializaçã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 Decisiva

O custo é o único eixo em que a idade do Tesseract é uma vantagem, e é uma vantagem estrutural: o Tesseract é exclusivamente de CPU, portanto 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 à taxa registrada de $0,76/hora. Para uma carga de trabalho vinculada à taxa de transferência (a paridade acima), o custo operacional do motor clássico em infraestrutura sem cobrança de GPU é materialmente menor — a referência de preço para a decisão de “vale a pena atualizar?”.

O custo é calculado como tempo de execução (wall-clock) × 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. A célula vazia do Tesseract não é um zero — é um valor ausente porque o motor nunca utilizou a GPU; o benchmark a registra como vazia em vez de assumir um número (regra do protocolo: uma célula vazia é not_applicable, nunca 0). Dois números de contexto mantêm isso honesto: os $0,2214 do PaddleOCR estão no meio do pacote entre os sete motores com GPU (o docTR detém a linha de GPU mais barata do benchmark, a $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 somente CPU, sem cobrança de GPU — plotado como omitido, não zero. Custo = tempo de execução (wall-clock) × $0,76/hora incluindo inicialização do modelo, preço com registro de data e hora nos manifestos de execução (agosto de 2026). Motor com GPU mais barato do 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 é somente CPU; o custo de GPU do PaddleOCR inclui a inicialização do modelo à taxa registrada de $0,76/hora. 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 Campo do Benchmark se Abre

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.9523 (Tesseract), um empate por incompatibilidade de idioma. Conforme o protocolo do benchmark, os números do CORD são mantidos em quarentena da comparação SROIE — nunca mesclados em qualquer ranking — porque o texto de referência do CORD incorpora a estrutura de anotação, o que infla o CER bruto de todos os mecanismos, além da incompatibilidade real de idioma.

Onde os dois mecanismos realmente se separam é na alavanca de campo via LLM, e este é o ponto de dados mais forte da página: por meio do pós-processador LLM, o F1 de campo do PaddleOCR no CORD se mantém em 0.5527 — o melhor de todos os oito mecanismos no CORD — enquanto o do Tesseract colapsa para 0.1627, o pior de todos os oito mecanismos em todo o benchmark. Essa diferença de 0,39 ponto é a maior lacuna entre quaisquer duas linhas irmãs de campo via 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) para que nenhum pós-processador — regex ou LLM — consiga recuperar campos dele. A alavanca LLM ajuda (o F1 do SROIE do Tesseract sobe de 0.2335 com regex para 0.4389 com LLM), mas parte de uma base mais fraca e não pode fabricar texto que o mecanismo nunca leu. O CORD é citado aqui para contexto de robustez de idioma; ele é 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 combine números CORD em nenhuna classificação SROIE: o CER de CORD combina uma incompatibilidade linguística genuina com uma inflação da estrutura de anotação no ground truth, e os padrões regex foram escritos para formatos em inglês (o F1 regex de ambos os motores colapsa a ~1–8%). Contexto de classificação (llm_field_value_f1, todas as linhas cord_v2): PaddleOCR 0.5527 é o melhor de oito; Tesseract 0.1627 é o peor de oito — a maior lacuna entre irmãos do benchmark. A célula de custo de Tesseract está vazia (solo CPU), nunca 0.

Quem Vence Quando: A Grade Resumida

“Melhor” depende da carga de trabalho, e este cara a cara divide os eixos com uma claridade incomum: todos os eixos de precisão favorecen PaddleOCR; o custo, a simplicidade de CPU e a cauda p95 estreita favorecen Tesseract; o rendimento de wall-clock é um empate estatístico; a latência por página favorece PaddleOCR; e o campeonato de CER bruto não pertence a nenhuno dos dois (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 mecanismos é 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 iguala o PaddleOCR em páginas por minuto, apesar de ser apenas CPU?

Porque páginas por minuto é a taxa de transferência em tempo real, não a velocidade de inferência por página. O p50 em estado estacionário do PaddleOCR (297,0 ms) é genuinamente 2,3× mais rápido que o do Tesseract (670,9 ms), mas a taxa de transferência em tempo real inclui a inicialização do modelo e efeitos de lote: a 79,7 páginas/min, o PaddleOCR gasta ~753 ms por página em tempo real contra seu p50 de 297 ms, enquanto o runtime de CPU simplificado do Tesseract gasta ~763 ms por página contra seu p50 de 671 ms — o mecanismo com GPU paga um custo maior de carga/prefill por execução que quase anula 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 mecanismo com GPU domina sua cauda de pior caso: p95 do PaddleOCR 3.331,4 ms vs p95 do Tesseract 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 de CPU do Tesseract não tem pico de carga e flui de forma constante; o estado estacionário rápido do PaddleOCR vem com um caminho de inicialização mais pesado em 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: ele é apenas para CPU, portanto, sua célula de custo no CSV fica vazia por design (nunca 0), enquanto o PaddleOCR cobra $0.2214 por 1.000 páginas no SROIE e $0.3419 no CORD, na mesma RTX 4090 a $0.76/hora, com custo incluindo a inicialização do modelo (summary_metrics.csv, cost_per_1000_pages, linhas sroie_2019 e cord_v2). O motor GPU mais barato do benchmark em geral é o docTR a $0.048 por 1.000 páginas.

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

Porque o pós-processador LLM não consegue recuperar texto que o motor OCR nunca leu. O CER do Tesseract no CORD é 0.9523 — efetivamente ilegible em recibos indonesios — portanto, seu F1 de campo LLM cae a 0.1627, o peor de todos os oito motores, enquanto o do PaddleOCR se mantiene em 0.5527, o melhor dos oito (field_method_comparison.csv, llm_field_value_f1, linhas cord_v2). A mesma alavanca em texto inglês limpo (SROIE) eleva o Tesseract a 0.4389 — mas o teto é definido pela qualidade do texto base.

Por que ambos os motores têm resultados tão baixos em recibos CORD?

Duas causas que se combinam e que o protocolo mantiene separadas do ranking SROIE: uma incompatibilidade linguística genuina (recibos indonesios 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, linhas cord_v2). O que ainda os separa é a recuperação downstream via LLM: PaddleOCR 0.5527 vs Tesseract 0.1627 de F1 de campo — a maior diferença entre linhas irmãs do benchmark. As linhas CORD são citadas com enquadramento e nunca são agrupadas em nenhun ranking combinado.

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

Se o seu pipeline consome campos — valores extraídos como empresa, data, totais —, o PaddleOCR é a escolha padrão clara para recibos: F1 de campos 1,39× maior com regex, 1,32× maior com um LLM, e recuperação a jusante via LLM que sobrevive ao choque de idioma do CORD (field_method_comparison.csv). Se você precisa de texto bruto de alto volume em documentos em inglês limpos, com custo zero de GPU, infraestrutura somente com CPU ou previsibilidade de latência final, o Tesseract continua sendo uma opção legítima: a vazão em tempo real empata (79,7 vs 78,6 páginas/min), o p95 é 2,2× mais apertado e não há cobrança de GPU — mas reserve um orçamento para uma base de texto mediana (CER 0,3347, 5º de 8) que limita todos os pipelines de campos a jusante. 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 (consulte Limitações).

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

Cada número é uma linha dos CSVs publicados do benchmark proprietário — results/summary_metrics.csv (CER/WER, F1 de campos com regex, latência, custo, vazão; as linhas do tesseract têm compute_type=cpu e uma célula de custo vazia) e results/field_method_comparison.csv (pós-processamento com regex vs LLM, llm_model = deepseek-v4-flash) — hospedados em ImageToTableai/benchmark-ocr, com um manifest.json editado 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 comparativo direto de uma execução de benchmark independente e reproduzível (nível oficial) — não uma pesquisa de alegações de terceiros, nem uma página de comparação de fornecedores. Apenas divisões de teste fixas: teste SROIE 2019 (361 recibos em inglês, campos simples empresa/data/endereço/total) e teste CORD v2 (100 recibos em indonésio, campos aninhados menu/sub_total/total); divisões de treinamento nunca foram avaliadas. Ambos os mecanismos usaram 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 avaliada, então as figuras de latência são em estado estável). As duas execuções foram concluídas com error_rate 0.0 em ambos os conjuntos de dados (coluna error_rate de summary_metrics.csv). A assimetria CPU/GPU é inerente a esta comparação: o Tesseract foi executado em CPU (compute_type=cpu) contra mecanismos acelerados por GPU, por design — sua célula de custo está vazia porque nenhum tempo de GPU foi cobrado, e sua latência/vazão foram medidas na mesma máquina sob o mesmo protocolo. A execução subjacente contém oito mecanismos no total; esta página compara apenas os dois mecanismos nomeados, com outros mecanismos citados somente como contexto de classificação. Os resultados completos dos 8 mecanismos são publicados separadamente em OCR tradicional vs VLMs de parsing de documentos.

Ambiente de Execução

• Hardware: ambos os motores foram executados na mesma máquina com uma NVIDIA RTX 4090 (24 GB); o custo de GPU foi calculado com a tarifa on-demand de RunPod de $0,76/hora, com o preço registrado com timestamp em cada manifest redacted de cada execução (agosto de 2026). Tesseract foi executado na CPU e não incorreu em custo de GPU; sua célula de custo fica vazia por design.
• Motores: configuração padrão, sem fine-tuning. Versões fixadas: Tesseract 5.3.4 (motor OCR clássico de código aberto — pipeline CV tradicional com reconhecimento baseado em LSTM, somente CPU, runner python3 do sistema, sem ambiente GPU) e PaddleOCR 3.7.0 (OCR moderno de deep learning em dois estágios — detección PP-OCR + reconocimiento, GPU) — conforme a tabela de modelos do repositório público (README.md) e os manifests de execução.
• Pós-processador LLM: deepseek-v4-flash via API com temperatura 0 para saída determinística (columna llm_model em field_method_comparison.csv); foi o único modelo usado para todas as filas de campos LLM em ambos motores.
• Base de custo: tempo de execução wall-clock × $0,76/hora, incluindo inicialização do modelo — o processamento em lote reduz o custo por página; não aplicable a Tesseract (somente CPU).
• Pós-processamento de campos: as métricas de campos regex SROIE são postprocessed_sroie_receipt_regex_* (colunas regex_* em field_method_comparison.csv) — campos extraídos do texto OCR por um conjunto fixo de padrões. Medem OCR + extração downstream, não saída estruturada nativa de nenhum modelo; as colunas LLM_* meden texto OCR + extração LLM. Os dois pipelines nunca são combinados.

Definições de Métricas

• CER (Character Error Rate): distância de edição (inserções + deleções + substituições) entre o texto OCR e o ground truth, dividida pelos caracteres do ground truth. Menor é melhor.
• WER (Word Error Rate): o mesmo cálculo de distância de edição a nível de palavras.
• 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 KIE tradicional baseado em regras + OCR). Columna: regex_field_value_f1. Uma puntuación de 0 significa que não se recuperaron valores de campo.
• F1 de valor de campo (LLM): a mesma métrica sobre a saída do pós-processador LLM (texto OCR → deepseek-v4-flash → campos). Columna: llm_field_value_f1. Os dois pipelines são diferentes e nunca são combinados.
• Exactitud de campos de documento: fracción de documentos onde todos os campos objetivo coincidieron exactamente — uma barra muito mais estricta que o F1 por campo.
• Latencia p50/p95 & páginas/min: tempo de inferencia por página em estado estacionario (warm-then-scored, excluye carga del modelo) y rendimiento wall-clock incluyendo inicialización del modelo. Miden relojes diferentes; la paridad p50-vs-páginas/min en esta página es un hecho del modelo de medición, no un error, y se reconcilia en la sección Throughput Parity.
• Costo por 1.000 páginas: horas de GPU facturadas por 1.000 páginas a la tarifa registrada de $0,76/hora, incluyendo inicialización del modelo. La celda de Tesseract está vacía (solo CPU) — una celda vacía es 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. Cada número de CER/WER, latência, custo e throughput nesta página tem origem nas linhas 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), precisão e F1 de valores de campo regex/llm, document-fields-exact, llm_median_latency_ms, contagens de tokens. Cada número de F1 de campo regex/LLM tem origem nas linhas tesseract e paddleocr aqui (e em 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 editados, 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 editado por execução publicada (16 execuções) com versões de modelo, GPU/driver, versões de torch/CUDA/Python, metadados de custo com 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 de tarefas e licença (CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definição do conjunto de dados CORD v2, esquema de campos aninhados e licença (CC-BY-4.0).

Limitações

• A assimetria CPU/GPU é inerente, não uma falha: O Tesseract rodou em CPU contra mecanismos acelerados por GPU. Sua célula de custo está vazia por design (sem cobrança 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 diferente de máquina poderia alterar seu envelope operacional. Trate a comparação de custo como “cobrança de GPU vs nenhuma,” 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 manual ou documentos longos — tipos de documento em que mecanismos clássicos são conhecidos por degradar ainda mais — nem as capacidades de layout/tabela do PP-Structure do PaddleOCR. Não use esta página para concluir que qualquer mecanismo “vence em tudo.”
• Tamanho da amostra: 361 recibos em inglês + 100 em indonésio. O F1 de campo e o CER são sensíveis ao corpus; diferenças de alguns centésimos devem ser tratadas como ruído, não como verdade de engenharia — embora as lacunas documentadas aqui (39% de CER, 1,39× de F1 de regex, a diferença de 0,39 ponto no LLM-F1 do CORD) estejam muito além dessa faixa.
• Um único nível de GPU e um único preço: todos os números de GPU vêm de uma RTX 4090 a $0,76/hora, preço com registro 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 de LLM: todas as linhas de LLM usam deepseek-v4-flash a temperatura 0. Um LLM diferente altera o F1 absoluto de campo; as lacunas de 1,32× no SROIE e de 0,39 ponto no CORD podem se mover nas margens. A latência do LLM (~1.817–1.837 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.
• Ajuste de regex: o conjunto de padrões foi escrito uma vez por conjunto de dados. Uma biblioteca de padrões por formato, fortemente ajustada, 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–0,95) 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).
• Fixar versões: os resultados valem para Tesseract 5.3.4 e PaddleOCR 3.7.0 (agosto de 2026). Versões mais recentes de qualquer um dos mecanismos podem alterar cada número nesta página; os resultados do Tesseract refletem especificamente a 5.3.4 e foram reverificados em uma execução repetida em 14-08-2026.

Referências relacionadas: PaddleOCR vs EasyOCR Receipt Benchmark · docTR vs Surya2 Receipt Benchmark · a comparação de oito mecanismos de OCR e VLMs · regras fixas vs modelos de linguagem para campos · por que uma contagem correta de caracteres ainda pode significar um campo errado

Lecturas relacionadas: la brecha de precisión entre la IA y el OCR tradicional · por qué la extracción con IA supera al OCR en imágenes · Precios de Extracción de Documentos con IA (2026)