docTR vs Surya2: OCR de recibos
Benchmark frente a frente (2026)

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,197 significa cerca de 19,7 caracteres lidos incorretamente a cada 100. A Taxa de Erro de Palavras (WER) aplica o mesmo cálculo de distância de edição na granularidade de palavras. Esta é a dimensão em que os dois mecanismos 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 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 mecanismos são arquitetonicamente opostos. docTR é um pipeline tradicional de OCR neural em duas etapas: um detector localiza palavras e um reconhecedor as transcreve, preservando maiúsculas/minúsculas e o layout do texto impresso. Surya2 é um modelo de linguagem de visão (VLM) para análise de documentos: ele lê a imagem do documento inteiro e gera texto compreendido — com normalização de maiúsculas/minúsculas, pares rótulo/valor mesclados, linhas reordenadas — o que está mais próximo do que os sistemas downstream desejam, porém mais distante de correspondências exatas de caracteres. A CER mede correspondências exatas de caracteres, então é levemente conservadora contra o 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 com os mesmos padrões fixos de regex nos quatro campos de recibo do 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: a Surya2 extrai campos com F1 de valor de campo de 0,3183 contra 0,0766 da docTR, uma vantagem de 4,2×. A docTR tem a melhor precisão de caracteres da classe e a pior extração de campos por regex entre os oito mecanismos testados — precisão de texto e precisão de campos são independentes.

O F1 de valor de campo é a média harmônica entre precisão e recall sobre os valores de campo extraídos em comparação com a referência: 1,0 significa que todos os campos do recibo foram recuperados perfeitamente, 0 significa que nada foi. O mecanismo por trás da inversão é a diferença no formato de saída descrita acima. As 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 da Surya2 (caixa reduzida, chave-valor mesclada) corresponde a esses padrões com muito mais frequência, enquanto o texto de linha bruto da docTR — preciso pelo CER, mas com caixa original e ruído de separadores — não corresponde. As colunas de "extração de campos por regex" são as métricas postprocessed_sroie_receipt_regex_* do benchmark: elas medem texto de OCR + extração downstream baseada em regras, não a saída estruturada nativa.

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

A Alavanca do LLM: A Escolha do Motor Deixa de Importar

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

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

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

O Envelope Operacional: Onde Está a Diferença Real

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 terminarem. Na mesma RTX 4090, à mesma taxa registrada de $0.76/hora, o docTR sustenta 449.3 páginas/min a 108.7 ms p50 por página por $0.048 por 1.000 páginas; o Surya2 sustenta 12.1 páginas/min a 2.668,0 ms p50 por $1.061 por 1.000 páginas — uma diferença de throughput de 37×, uma diferença de latência de 24.5× e uma diferença de custo de 22.2×. Um pipeline dimensionado para o ritmo do Surya2 é uma conversa de arquitetura diferente de um dimensionado para o ritmo do docTR.

O custo é calculado como tempo de execução × a taxa da RTX 4090 do RunPod ($0.76/hora, preço com registro de data e hora nos manifests de execução), incluindo a inicialização do modelo — o preço que você realmente pagaria pelo tempo de GPU. O throughput é o total de páginas por minuto em tempo real, incluindo essa mesma inicialização. A latência p50/p95 são tempos de inferência por página em estado estável, medidos após aquecimento e pontuação (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 prefill/decode 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 × $0.76/hora, incluindo init do modelo, preço com registro de data e hora 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/h com timestamp nos manifests); o custo incluye a inicialização do modelo, não apenas a vazão em estado estacionário. 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 (Recibos Indonésios): Ambos os Motores Colapsam, Quarantenados pelo Protocolo

Nenhum dos motores foi treinado predominantemente em recibos indonésios, portanto CORD v2 (100 samples, campos anidados 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 de CORD são mantidos quarentenados da comparação SROIE — não são mesclados em nenhum ranking — porque o texto de referência de CORD incorpora estrutura de anotação, o que infla o CER bruto para todos os motores, além do genuino desajuste de idioma.

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

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

Quem Vence Quando: O Resumo em Grade

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

Perguntas Frequentes

O Surya2 é mais preciso que o docTR em recibos?

Não — na precisão bruta de caracteres, eles estão estatisticamente empatados: CER SROIE 0,1915 vs 0,1971 (docTR), uma diferença de 0,006 ponto (summary_metrics.csv, cer, linhas sroie_2019). Onde eles diferem é na saída estruturada de campos 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 o docTR tem a melhor precisão de caracteres, mas a pior extração de campos por regex?

Porque as duas métricas avaliam saídas diferentes. O docTR retorna texto de linha bruto limpo — preservando maiúsculas e separadores originais — e os padrões regex fixos, escritos para valores formatados, falham na maioria das vezes: seu F1 de campo regex SROIE é 0,0766, o menor 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 do Surya2, com dobra de caixa e estrutura de rótulos, coincide com os padrões em 0,3183. Alimente ambos com um LLM e a diferença cai para 0,003 — o regex, não o OCR, era o gargalo.

Adicionar um pós-processador LLM torna o docTR e o 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, linhas sroie_2019). O custo dessa convergência é um adicional de ~2,0–2,3 s de latência mediana do LLM por documento (llm_median_latency_ms, mesmas linhas), adequado para processamento assíncrono em lote em vez de esperas síncronas por página.

Quanto mais rápido e barato é o docTR em comparação ao 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) na mesma RTX 4090 a $0,76/hora (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, linhas sroie_2019).

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

Duas causas que se combinam e que o protocolo de benchmark mantiene separadas do ranking SROIE: uma incompatibilidade linguística real (recibos indonesios fora do foco de treinamento de ambos os motores) e uma inflação da estrutura de anotação dentro do texto de referência (ground-truth) do CORD — a CER fica em 0.9101 (docTR) e 0.8959 (Surya2) (summary_metrics.csv, cer, linhas cord_v2). As métricas de campo absorben parte do impacto quando se adiciona um LLM (0.5500 vs 0.5203), mas as linhas CORD são citadas e nunca são agrupadas em nenhun 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 medido, o envelope de docTR (108.7 ms, 449.3 páginas/min, $0.048/1K páginas) domina. Para campos estruturados sem nenhun pós-processador, o F1 de regex pronto para uso de Surya2 (0.3183 vs 0.0766) é o melhor ponto de partida. Para qualidade final de campo com pós-processamento LLM, a escolha quase não importa (0.6171 vs 0.6139). Estes resultados valem para recibos em inglês e indonesio em um nível de GPU em agosto de 2026; qualquer decisão de produção deve re-executar no corpus de destino (ver Limitações).

De onde vienen os números desta página?

Cada figura é uma linha dos CSVs publicados do benchmark de primeira parte — results/summary_metrics.csv (CER/WER, F1 de campo, latência, custo, throughput) e results/field_method_comparison.csv (regex vs pós-processamento LLM, llm_model = deepseek-v4-flash) — alojados em ImageToTableai/benchmark-ocr, com um manifest.json redactado por execução para fingerprints do ambiente. As definições de dataset vienen dos papers SROIE 2019 e CORD citados abaixo.

Metodologia e Fontes

Protocolo

Esta página apresenta um recorte comparativo direto de uma execução de benchmark independente e reproduzível (execução oficial) — não é um levantamento de alegações de terceiros, nem uma página de comparação entre fornecedores. Apenas divisões de teste fixas: teste SROIE 2019 (361 recibos em inglês, campos simples company/date/address/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 viram as mesmas imagens, o mesmo ground truth e o mesmo protocolo de medição (warm_then_scored: uma passada de aquecimento fixa precede a passada avaliada, então os números de latência refletem o estado estável). Ambas as execuções foram concluídas com error_rate 0.0 (coluna error_rate em summary_metrics.csv). A execução subjacente contém oito mecanismos no total; esta página compara apenas os dois mecanismos nomeados, e os resultados completos dos oito mecanismos são publicados separadamente em Traditional OCR vs Document Parsing VLMs.

Ambiente de Execução

• Hardware: ambos os mecanismos rodaram na mesma NVIDIA RTX 4090 (24 GB); custo de GPU calculado pela tarifa on-demand da RunPod de $0.76/hora, preço com registro de data/hora no manifesto editado de cada execução (agosto de 2026).
• Mecanismos: configuração padrão, sem fine-tuning. Versões fixadas: docTR v1.0.1 (OCR neural tradicional em dois estágios, GPU) e Surya2 (surya-ocr 0.22.1) (VLM de parsing de documentos, 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 com temperatura 0 para saída determinística (a coluna llm_model em field_method_comparison.csv); foi o único modelo usado para todas as linhas de campos LLM em ambos os mecanismos.
• Base de custo: tempo de execução × $0.76/hora, 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_* em field_method_comparison.csv) — campos extraídos do texto do OCR por um conjunto fixo de padrões. Elas medem OCR + extração downstream, não saída estruturada nativa de nenhum dos modelos; as colunas LLM_* medem texto do OCR + extração via LLM. Os dois pipelines nunca são combinados.

Definições de Métricas

• CER (Taxa de Erro de Caracteres): distância de edição (inserções + exclusões + substituições) entre o texto do OCR e o ground truth, dividida pelos caracteres do ground truth. Quanto 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 (normalização de caixa, fusão de rótulo/valor).
• WER (Taxa de Erro de Palavras): o mesmo cálculo de distância de edição em nível de palavra.
• F1 de valor de campo (regex): média harmônica de precisão/revocação sobre valores de campo extraídos usando padrões regex fixos no texto do 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 do OCR → deepseek-v4-flash → campos). Coluna: llm_field_value_f1. Os dois pipelines são diferentes e nunca são combinados.
• Documentos com campos exatos: fração de documentos em que todos os campos-alvo corresponderam exatamente — um critério muito mais rigoroso do que o F1 por campo.
• Latência p50/p95 & páginas/min: tempo de inferência por página em estado estável (aquecido e pontuado, 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 à taxa registrada de $0,76/hora.

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 têm origem nas linhas doctr e surya2 aqui.
2. field_method_comparison.csv (GitHub raw). 16 linhas; colunas model, dataset, llm_model (= deepseek-v4-flash), precisão e F1 de valor de campo regex/llm, documentos com campos exatos, llm_median_latency_ms, contagens de tokens. Todos os números de F1 de campo regex/LLM têm origem nas linhas doctr e surya2 aqui.
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 timestamp de 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

• Escopo do documento — apenas recibos: SROIE + CORD. Nada aqui mede o tratamento de layout/tabela/formulário/documentos longos, onde os VLMs de parsing de documentos afirmam suas maiores vantagens; os pontos fortes divulgados da Surya2 são não medidos. Não use esta página para concluir que "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 poucos centésimos (incluindo a diferença de 0,006 no CER e a de 0,003 no F1 do LLM) devem ser tratadas como ruído, não como verdade de engenharia.
• Um único nível de GPU e um único preço: todos os números vêm de uma RTX 4090 a US$ 0,76/hora, com preço datado de agosto de 2026 nos manifestos de execução. Outras GPUs, servindo com múltiplas GPUs, agendamento em lote ou mudanças de preço alterarão latência, throughput e custo — recalcule os custos às taxas atuais antes de orçar.
• Um único pós-processador LLM: todas as linhas de LLM usam deepseek-v4-flash a temperatura 0. Um LLM diferente altera o F1 absoluto de campo; a ordem de convergência pode mudar nas margens. A latência do LLM (~2,0–2,3 s de mediana, llm_median_latency_ms em field_method_comparison.csv) é 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,90–0,91) reflete incompatibilidade de idioma + inflação do ground truth. As linhas do CORD são citadas com contextualização e nunca mescladas em qualquer ranking do SROIE (regra de protocolo).
• Justiça do CER para VLMs: o CER pontua correspondências exatas de caracteres, então a saída da Surya2 com dobra de caixa e rótulos mesclados é levemente penalizada por convenções de saída, não por erros de leitura (veja a referência relacionada sobre CER). O empate no CER, portanto, subestima levemente a Surya2; as métricas de campo são a comparação mais justa entre famílias.
• Apenas dois mecanismos: este confronto direto exclui deliberadamente os outros seis mecanismos da execução subjacente, serviços de OCR em nuvem/API e APIs de VLM hospedadas; seus modelos de latência e preço diferem fundamentalmente dos mecanismos locais medidos aqui.
• Fixar versões: os resultados valem para docTR v1.0.1 e Surya2 0.22.1 (agosto de 2026). Versões mais recentes de qualquer um dos mecanismos podem alterar todos os números desta página.

Referências relacionadas: OCR tradicional vs VLMs de parsing de documentos · onde o regex falha em documentos reais · por que contagens de caracteres enganam na extração de campos · Precisão de OCR de recibos

Leitura relacionada: Precisão de OCR com IA vs OCR clássico · extração de dados de imagem vs mecanismos de OCR · Preços de Extração de Documentos com IA (2026)