docTR vs Surya2: OCR de Cupons
Comparação Direta (2026)

A Taxa de Erro de Caracteres (CER) é a medida clássica de OCR: inserções, exclusões e substituições divididas pelos caracteres da verdade fundamental — uma CER de 0,197 significa aproximadamente 19,7 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 palavras. Esta é a dimensão onde os dois motores são inseparáveis.

No SROIE 2019, docTR e Surya2 são os dois reconhecedores de caracteres mais fortes do benchmark, separados por 0,006 pontos — dentro da faixa de ruído para um corpus de 361 amostras. A WER conta a mesma história: Surya2 0,2735, docTR 0,3199. A narrativa de que "VLMs superam o OCR tradicional" não sobrevive a esta comparação na precisão bruta de caracteres de recibos em inglês.

Precisão de Caracteres: Um Empate Estatístico

O empate importa porque os dois motores são arquiteturalmente opostos. docTR é um pipeline de OCR neural tradicional em duas etapas: um detector localiza as palavras e um reconhecedor as transcreve, preservando o caso bruto e o layout do texto impresso. Surya2 é um modelo de linguagem visual para análise de documentos (VLM): ele lê a imagem do documento inteiro e produz texto compreendido — com caixa unificada, pares rótulo/valor mesclados, linhas reordenadas — o que está mais próximo do que os sistemas downstream desejam, mas mais longe de correspondências exatas de caracteres. A CER mede correspondências exatas de caracteres, portanto é levemente conservadora em relação ao Surya2; o fato de o empate sobreviver apesar dessa assimetria é o que o torna significativo.

Tabela: summary_metrics.csv — colunas cer e wer, linhas sroie_2019. Valores exatos: docTR cer 0,19707 / wer 0,31990; Surya2 cer 0,19147 / wer 0,27352. Menor é melhor; ambas as execuções foram concluídas com error_rate 0,0.

Onde Eles Divergem: A Extração de Campos Fora da Caixa Inverte o Resultado

Avalie o texto bruto dos mecanismos pelos mesmos padrões regex fixos nos quatro campos de recibo SROIE (empresa, data, endereço, total) — a abordagem tradicional de OCR + extração de informações-chave (KIE) baseada em regras — e a classificação se inverte: Surya2 extrai campos com 0.3183 F1 de campo contra 0.0766 do docTR, uma vantagem de 4,2×. docTR tem a melhor precisão de caracteres da categoria e a pior extração de campos por regex na execução de oito mecanismos — precisão de texto e precisão de campo são desacopladas.

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 fundamental: 1,0 significa que todos os campos do recibo foram perfeitamente recuperados, 0 significa nada. O mecanismo por trás da inversão é a diferença na forma de saída descrita acima. Expressões regulares foram escritas para valores formatados como RM 12.00 ou 14/08/2020; a saída normalizada e estruturada por rótulos do Surya2 (com caixa unificada, chave-valor mesclada) corresponde a esses padrões com muito mais frequência, enquanto o texto de linha bruto do docTR — preciso pelo CER, mas com caixa original e ruído de separador — os derrota. As colunas "extração de campos por regex" são as métricas postprocessed_sroie_receipt_regex_* do benchmark: elas medem texto OCR + extração baseada em regras downstream, não saída estruturada nativa.

Fonte: field_method_comparison.csv — colunas regex_field_value_f1 / llm_field_value_f1, linhas sroie_2019 (decimais de 0–1 mostrados 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, linhas sroie_2019. Estas são as métricas postprocessed_sroie_receipt_regex_*: padrões fixos aplicados ao texto OCR de cada engine (pós-processado, não extração nativa). O F1 de campo regex do docTR de 0,0766 é o mais baixo de todas as oito engines na execução subjacente, apesar do segundo melhor CER.

A Alavanca do LLM: A Escolha da Engine Deixa de Importar

Alimente o texto OCR de ambas as engines com um pós-processador LLM (deepseek-v4-flash, temperatura 0) com um prompt de extração estruturada, e a lacuna de campos quase desaparece: docTR 0,6171 vs Surya2 0,6139 F1 de campo — uma vantagem de 0,003 pontos para a engine tradicional, um empate na prática. O pós-processador, não a engine OCR, torna-se o componente decisivo.

Este é o mesmo padrão visto no benchmark completo de oito engines: o pós-processamento LLM puxa engines saudáveis para uma faixa convergente de F1 de campo porque entende semântica (números, datas, nomes) em vez de corresponder a formas de caracteres. O texto base mais limpo do docTR se adianta por um fio; a estrutura normalizada do Surya2 perde essa pequena vantagem sob o LLM. Dois custos vêm com a alavanca: uma chamada LLM adiciona cerca de 2,0–2,3 s de latência mediana por documento além do tempo de OCR (1.996,3 ms para o texto do docTR, 2.261,7 ms para o do Surya2, incorridos via API e idênticos em tipo), e não resgata texto que uma engine falhou fundamentalmente em ler.

Tabela: field_method_comparison.csv — colunas llm_*, linhas sroie_2019. Modelo LLM: deepseek-v4-flash com temperatura 0 (coluna llm_model). A latência do LLM é incorrida via API e separada da latência da engine (latency_p50_ms em summary_metrics.csv).

A Faixa de Operação: Onde a Verdadeira Diferença Está

A precisão de caracteres empata, a precisão de campos converge sob um LLM — mas um pipeline em lote não se importa com nenhuma das duas se os números não fecharem. No mesmo RTX 4090 com a mesma taxa registrada de $0,76/hr, o docTR sustenta 449,3 páginas/min com 108,7 ms p50 por página por $0,048 por 1.000 páginas; o Surya2 sustenta 12,1 páginas/min com 2.668,0 ms p50 por $1,061 por 1.000 páginas — uma diferença de 37× no throughput, de 24,5× na latência e de 22,2× no custo. Um pipeline dimensionado para o ritmo do Surya2 é uma conversa de arquitetura diferente daquele dimensionado para o ritmo do docTR.

O custo é calculado como tempo de execução em relógio × a taxa do RunPod RTX 4090 ($0,76/hora, preço com carimbo de tempo nos manifests de execução), incluindo a inicialização do modelo — o preço que você realmente pagaria pelo tempo de GPU. O throughput são páginas por minuto em relógio, incluindo essa mesma inicialização. As latências p50/p95 são tempos de inferência por página em estado estável, medidos aquecidos-e-pontuados (excluindo o carregamento do modelo); a cauda do Surya2 é proporcionalmente pior — 5.872,2 ms p95 contra 281,4 ms do docTR — porque os picos de preenchimento/decodificação do VLM dominam a cauda nas primeiras páginas.

Fonte: summary_metrics.csv — coluna latency_p50_ms, linhas sroie_2019. docTR 108,7166, Surya2 2667,9800. Latência em estado estável (modo de medição warm_then_scored).

Fonte: summary_metrics.csv — coluna cost_per_1000_pages, linhas sroie_2019. docTR 0,0479, Surya2 1,0609. Custo = tempo de execução em relógio × $0,76/hr incluindo init do modelo, preço com carimbo de tempo nos manifests de execução (agosto de 2026).

Tabela: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, linhas sroie_2019. Ambos os motores em GPU (RTX 4090, preço de $0.76/hr com timestamp nos manifests); o custo inclui a inicialização do modelo, não apenas o throughput em regime permanente. Valores exatos: docTR p50 108.7 / p95 281.4 / 449.3 pg/min / $0.0479; Surya2 p50 2668.0 / p95 5872.2 / 12.1 pg/min / $1.0609.

CORD (Indonesian Receipts): Both Engines Collapse, Quarantined by Protocol

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: CER 0.8959 (Surya2) e 0.9101 (docTR). De acordo com o protocolo de benchmark, os números do CORD são mantidos em quarentena da comparação com o SROIE — não são mesclados em nenhum ranking — porque o texto de referência do CORD incorpora a estrutura de anotação, o que infla o CER bruto para cada motor além da incompatibilidade genuína de idioma.

Nos métricas de campo, o mesmo padrão de divergência do SROIE se mantém, comprimido: através de padrões regex, o docTR recupera nenhum campo (0.0000 field F1 — um zero literal no CSV, não um valor ausente) porque os padrões no formato inglês não corresponderam a nada no texto em indonésio, enquanto a saída normalizada do Surya2 obtém 0.2458. O LLM então reconverge o par para 0.5500 (docTR) e 0.5203 (Surya2) — o choque de idioma é absorvido pelo pós-processador, não pelo motor. O CORD é citado aqui para contexto de robustez de idioma; ele é deliberadamente nunca agrupado com os números do SROIE em um único leaderboard.

Tabela: summary_metrics.csv (cer) e field_method_comparison.csv (field F1), cord_v2 rows. Não mescle estes números em nenhum ranking do SROIE: O CER do CORD combina incompatibilidade genuína de idioma com inflação da estrutura de anotação no ground truth; os padrões regex foram escritos para formatos em inglês. O field F1 de regex do docTR de 0.0000 é um zero literal registrado no CSV, não um valor ausente.

Quem Vence Quando: A Grade de Resumo

"Melhor" depende da carga de trabalho. Esses dois motores dividem os eixos de forma limpa, e a divisão é a descoberta: empate na precisão de caracteres, conveniência de campos estruturados favorece Surya2, todos os eixos de custo/latência/throughput favorecem docTR, e um pós-processador LLM torna a escolha do motor quase irrelevante para a qualidade final dos campos.

Perguntas Frequentes

Surya2 é mais preciso que docTR em recibos?

Não — em precisão bruta de caracteres, estão estatisticamente empatados: CER do SROIE 0.1915 (Surya2) vs 0.1971 (docTR), uma diferença de 0,006 pontos (summary_metrics.csv, cer, sroie_2019 rows). Onde eles diferem é na saída de campos estruturados pronta para uso (Surya2 vence 4,2× com regex) e no envelope operacional (docTR vence 24,5× em latência, 22,2× em custo, 37× em throughput).

Por que docTR tem a melhor precisão de caracteres, mas a pior extração de campos com regex?

Porque as duas métricas avaliam saídas diferentes. docTR retorna texto de linha bruto limpo — preservando o caso original e separadores — e os padrões regex fixos, escritos para valores formatados, falham na maioria das vezes contra ele: seu F1 de campo regex do SROIE é 0,0766, o mais baixo de todos os oito mecanismos na execução subjacente, contra o segundo melhor CER (0,1971) (summary_metrics.csv cer, field_method_comparison.csv regex_field_value_f1). A saída com dobras de caso e estrutura de rótulos do Surya2, por acaso, corresponde aos padrões em 0,3183. Alimente ambos com um LLM e a diferença colapsa para 0,003 — o regex, não o OCR, era o gargalo.

Adicionar um pós-processador LLM torna docTR e Surya2 iguais?

Quase exatamente — docTR 0,6171 vs Surya2 0,6139 F1 de campo LLM no SROIE (field_method_comparison.csv, llm_field_value_f1, sroie_2019 rows). O custo dessa convergência é uma latência LLM mediana extra de ~2,0–2,3 s por documento (llm_median_latency_ms, mesmas linhas), adequada a processamento assíncrono em lote em vez de esperas síncronas por página.

Quanto mais rápido e barato é docTR em comparação com Surya2?

24,5× menor latência p50 (108,7 ms vs 2.668,0 ms), 37× maior throughput (449,3 vs 12,1 páginas/min), e 22,2× menor custo por 1.000 páginas ($0,048 vs $1,061) no mesmo RTX 4090 a $0,76/hr (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, sroie_2019 rows).

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

Duas causas combinadas que o protocolo de benchmark mantém separadas do ranking SROIE: uma incompatibilidade genuína de idioma (recibos indonesianos fora do foco de treinamento de ambos os motores) e uma inflação na estrutura de anotação dentro do texto de referência do CORD — o CER fica em 0.9101 (docTR) e 0.8959 (Surya2) (summary_metrics.csv, cer, cord_v2 rows). As métricas de campo absorvem parte do impacto quando um LLM é adicionado (0.5500 vs 0.5203), mas as linhas do CORD são citadas e nunca são agrupadas em nenhum ranking combinado.

Qual motor um pipeline de recibos deve escolher, docTR ou Surya2?

Depende do eixo que seu pipeline consome. Para texto bruto em volume com custo mensurado, o envelope do docTR (108,7 ms, 449,3 páginas/min, $0,048/1K páginas) domina. Para campos estruturados sem nenhum pós-processador, o F1 de regex pronto para uso do Surya2 (0,3183 vs 0,0766) é o melhor ponto de partida. Para qualidade final de campo com pós-processamento LLM a escolha pouco importa (0,6171 vs 0,6139). Esses resultados valem para recibos em inglês e indonesiano em uma camada de GPU em agosto de 2026; qualquer decisão de produção deve ser re-executada no corpus alvo (veja Limitações).

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

Cada cifra é uma linha dos CSVs publicados do benchmark de primeira mão — results/summary_metrics.csv (CER/WER, F1 de campo, latência, custo, throughput) e results/field_method_comparison.csv (regex vs pós-processamento 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 de 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 (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: SROIE 2019 teste (361 recibos em inglês, campos planos empresa/data/endereço/total) e CORD v2 teste (100 recibos indonésios, campos aninhados menu/sub_total/total); divisões de treinamento nunca foram avaliadas. Ambos os motores viram as mesmas imagens, o mesmo gabarito e o mesmo protocolo de medição (warm_then_scored: uma passagem de aquecimento fixa precede a passagem pontuada, de modo que os valores de latência sejam em regime permanente). Ambas as execuções foram concluídas com error_rate 0.0 (coluna error_rate do summary_metrics.csv). A execução subjacente contém oito motores no total; esta página compara apenas os dois motores nomeados, e os resultados completos dos 8 motores são publicados separadamente em Traditional OCR vs Document Parsing VLMs.

Ambiente de Execução

• Hardware: ambos os motores rodaram na mesma NVIDIA RTX 4090 (24 GB); custo da GPU calculado na tarifa sob demanda da RunPod de $0.76/hr, preço com carimbo de data no manifesto redatado de cada execução (agosto de 2026).
• Motores: prontos para uso, sem ajuste fino. Versões bloqueadas: docTR v1.0.1 (OCR neural tradicional de duas etapas, GPU) e Surya2 (surya-ocr 0.22.1) (VLM de análise de documento, servido via vLLM) — 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 em 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 campos LLM em ambos os motores.
• Base de custo: tempo de execução real × $0.76/hr, incluindo inicialização do modelo — o processamento em lote reduz o custo por página.
• Pós-processamento de campos: as métricas de campos regex do SROIE são postprocessed_sroie_receipt_regex_* (colunas regex_* do field_method_comparison.csv) — campos extraídos do texto OCR por um conjunto fixo de padrões. Elas medem OCR + extração downstream, não a saída estruturada nativa de nenhum dos modelos; as colunas LLM_* medem texto OCR + extração LLM. Os dois pipelines nunca são misturados.

Definições das Métricas

• CER (Character Error Rate): distância de edição (inserções + exclusões + substituições) entre o texto OCR e o ground truth, dividida pelos caracteres do ground truth. Menor é melhor. Sensível a maiúsculas/minúsculas e convenções de formatação — levemente conservador em relação à saída normalizada do Surya2 (junção de maiúsculas/minúsculas, fusão de rótulo/valor).
• WER (Word Error Rate): o mesmo cálculo de distância de edição em granularidade 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 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 combinados.
• 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 & páginas/min: tempo de inferência por página em regime permanente (aquecimento seguido de pontuação, exclui carregamento do modelo) e throughput em tempo real incluindo inicialização do modelo.
• Custo por 1.000 páginas: horas de GPU cobradas para 1.000 páginas na taxa registrada de $0,76/hr.

Lista de Fontes

1. summary_metrics.csv (GitHub raw). 16 linhas = 8 modelos × 2 conjuntos de dados. Colunas: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Todos os números de CER/WER, latência, custo e throughput nesta página são rastreados até as linhas do doctr e surya2 aqui.
2. field_method_comparison.csv (GitHub raw). 16 linhas; colunas model, dataset, llm_model (= deepseek-v4-flash), acurácia e F1 de valor de campo regex/llm, document-fields-exact, llm_median_latency_ms, contagens de tokens. Todos os números de F1 de valor de campo regex/LLM são rastreados até as linhas do doctr e surya2 aqui.
3. Repositório ImageToTableai/benchmark-ocr. Repositório público hospedando os CSVs de resultado, 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 manifesto.json redatado por execução publicada (16 execuções) com versões do modelo, GPU/driver, versões torch/CUDA/Python, metadados de custo com carimbo de data/hora do preço e hashes de artefatos.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definição do conjunto de dados SROIE 2019, estrutura da tarefa e licença (CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definição do conjunto de dados CORD v2, esquema de campos aninhados e licença (CC-BY-4.0).

Limitações

• Escopo do documento — apenas recibos: SROIE + CORD. Nada aqui mede o manuseio de layout/tabela/fórmula/documento longo onde os VLMs de análise de documentos reivindicam suas maiores vantagens; os pontos fortes comercializados do Surya2 são não medidos. Não use esta página para concluir "docTR 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 um único dígito de algumas centésimas (incluindo a lacuna de 0.006 no CER e a de 0.003 no LLM-F1) devem ser tratadas como ruído, não como verdade de engenharia.
• Única camada de GPU e único preço: todos os números vêm de uma RTX 4090 a $0.76/hr, com preço datado de agosto de 2026 nos manifests de execução. Outras GPUs, servimento multi-GPU, agendamento em lote ou alterações de preço mudarão a latência, throughput e custo — recalcule os custos com as taxas atuais antes de orçar.
• Único pós-processador LLM: todas as linhas LLM usam deepseek-v4-flash com temperatura 0. Um LLM diferente altera o F1 absoluto de campo; a ordem de convergência pode se mover nas margens. A latência do LLM (~2.0–2.3 s mediana, llm_median_latency_ms no field_method_comparison.csv) é imposta pela API e não faz parte da latência própria de nenhum dos engines.
• 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.
• O CER do CER não é uma leitura de qualidade por modelo: o ground truth do CORD incorpora estrutura de anotação e nenhum dos engines foi treinado predominantemente em indonésio; o CER do CORD (0.90–0.91) reflete incompatibilidade de idioma + inflação do ground truth. As linhas do CORD são citadas com contextualização e nunca são mescladas em qualquer ranking do SROIE (regra do protocolo).
• Justiça do CER para VLMs: o CER pontua correspondências exatas de caracteres, então a saída do Surya2, com caixa unificada e rótulos mesclados, é levemente penalizada por convenções de saída, não por leituras incorretas (veja referência relacionada sobre CER). O empate no CER, portanto, subestima levemente o Surya2; as métricas de campo são a barra justa entre famílias.
• Apenas dois engines: esta comparação direta exclui deliberadamente os outros seis engines da execução subjacente, serviços de OCR em nuvem/API e APIs de VLM hospedadas; seus modelos de latência e precificação diferem fundamentalmente dos engines locais medidos aqui.
• Fixação de versão: os resultados valem para docTR v1.0.1 e Surya2 0.22.1 (agosto de 2026). Versões mais recentes de qualquer um dos engines podem alterar todos os números nesta página.

Referências relacionadas: OCR Tradicional vs VLMs de Análise de Documentos · Regex vs Extração de Campos por LLM · Precisão por Campo vs Precisão por Caractere · Precisão de OCR para Recibos

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