Surya2 vs Unlimited-OCR vs PaddleOCR-VL:
Benchmark VLM para Notas Fiscais (2026)

Todos os três motores são modelos de visão e linguagem para análise de documentos (VLMs): modelos neurais que leem uma imagem de documento inteira e produzem texto compreendido — com caixa unificada, pares rótulo/valor mesclados em linhas únicas, linhas reordenadas pela ordem de leitura — em vez dos fluxos de caracteres brutos com a caixa original que os motores de OCR tradicionais (Tesseract, PaddleOCR, EasyOCR, docTR — os outros motores na execução subjacente) retornam. Essa convenção de saída é o que torna seus números de extração de campos fortes desde o início e seus números brutos de erro de caracteres enganosos, como a próxima seção mostra. Dentro da família VLM, os três diferem acentuadamente em tamanho e alvo de treinamento: Surya2 é um modelo de 650 milhões de parâmetros, centrado em texto, ajustado para transcrição limpa de página inteira (90+ idiomas); PaddleOCR-VL é um compacto generalista de 0,9B construído para abrangência em idiomas, tabelas e fórmulas; Unlimited-OCR é orientado para análise de documentos longos e em lote (leitura de passagem única de documentos com 40+ páginas é seu diferencial comercial). Uma ressalva importante se aplica a todo número de CER abaixo: a taxa de erro de caracteres conta inserções, exclusões e substituições em relação aos caracteres de referência, penalizando exatamente as normalizações que os VLMs são treinados para realizar. A pontuação F1 em nível de campo é a métrica mais justa entre VLMs, e é a espinha dorsal desta página.

Por Que Não Usar CER para VLMs: A Dispersão de 3,4× é Convenção de Saída, Não Capacidade de Leitura

Lendo apenas a coluna de CER bruto, o Unlimited-OCR parece um modelo fracassado (0,6552 no SROIE) enquanto o Surya2 parece de classe mundial (0,1915, empatado com o docTR tradicional de 0,1971 para o melhor CER bruto na execução de 8 motores). Ambas as interpretações são artefatos do estilo de saída. O mesmo texto do Unlimited-OCR que pontua 0,6552 de CER pontua 0,4779 de WER — suas palavras sobrevivem enquanto seus caracteres parecem danificados, porque a unificação de caixa substitui caracteres sem quebrar palavras. Os números do PaddleOCR-VL invertem o padrão: seu CER no CORD de 1,0805 é o pior de todos os 8 motores enquanto sua pontuação F1 de campos no CORD de 0,3412 é a melhor de todos os 8 — o próprio CSV do benchmark contradiz a classificação por CER.

O mecanismo tem duas camadas. Camada 1 — imposto de normalização: os VLMs de análise de documentos produzem texto "compreendido" — TAN CHAY YEE se torna tan chay yee, INVOICE NO : PEGIV mescla um rótulo e um valor em uma linha. O CER é uma correspondência exata de caracteres, então cada caixa unificada e linha mesclada é contabilizada como um erro, mesmo quando o valor do campo está correto. A análise de decomposição de erros do benchmark das previsões publicadas do SROIE atribui aproximadamente um quinto do orçamento bruto de CER a substituições de caixa e aproximadamente um décimo a mesclagens/exclusões de linhas; os três motores pagam esse imposto em taxas diferentes — a forte unificação do Unlimited-OCR infla seu CER muito além de seu WER, enquanto a mesclagem de linhas/rótulos do PaddleOCR-VL empurra seu WER (0,6462) acima de seu próprio CER (0,3370). Camada 2 — inflação da estrutura de referência no CORD: o texto de referência do CORD incorpora a estrutura de anotação (itens de menu, coordenadas, rótulos de campos), então o CER é sistematicamente inflado para cada motor além da genuína incompatibilidade linguística — o agrupamento de CER no CORD de todos os motores de 0,90–1,08 (Tesseract tradicional 0,9523, docTR 0,9101, e todos os VLMs incluídos) confirma que a inflação é de todo o corpus, não específica do modelo.

Tabela: summary_metrics.csv — colunas cer e wer, linhas sroie_2019. Valores exatos: Surya2 cer 0.19147 / wer 0.27352; Unlimited-OCR cer 0.65524 / wer 0.47788; PaddleOCR-VL cer 0.33696 / wer 0.64623. Menor é melhor; as três execuções foram concluídas com error_rate 0.0. Não classifique VLMs pelo CER: A divergência CER/WER do Unlimited-OCR (0.6552 vs 0.4779) e a inversão CER-vs-field-F1 do PaddleOCR-VL no CORD (veja abaixo) são artefatos de convenção de saída do tipo exato que o protocolo deste benchmark sinaliza para linhas de VLM.

A consequência das Camadas 1 e 2 é que cada seção restante desta página compara os três VLMs com base na pontuação F1 de extração de campos (as métricas cuja saída estruturada alimenta diretamente) e na faixa operacional (latência, throughput, custo) — e cita o CER apenas com suas ressalvas. Esta é a regra do protocolo do benchmark para linhas de VLM de análise de documentos, e é a lente correta: um pipeline de recibos consome campos (empresa, data, endereço, total), não fluxos de caracteres.

Extração de Campos Prontos para Uso: Saída Estruturada é a Característica da Família VLM

Execute o texto bruto de cada motor 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 baseada em regras (KIE) — e os três VLMs ficam dentro de uma faixa de 0,02 pontos: Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368, Surya2 0,3183. Todos os três ficam entre os quatro primeiros na execução de oito motores; dois deles superam o melhor motor tradicional (0,3254 do PaddleOCR), e o terceiro fica 0,007 pontos atrás. Seu "texto compreendido" chega aos consumidores de campos mesmo sem qualquer pós-processador LLM — a característica da família que os motores OCR de caracteres brutos não possuem.

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 cada campo do recibo foi perfeitamente recuperado, 0 significa nada. O mecanismo por trás da vantagem da família VLM é a forma de saída descrita acima — o mesmo texto estruturado por rótulos, com caixa flexível, que infla a CER, acaba correspondendo aos padrões de extração. As colunas "extração de campos por regex" são as métricas postprocessed_sroie_receipt_regex_* do benchmark: elas medem o texto do OCR + extração baseada em regras downstream, não a saída estruturada nativa, e o mesmo conjunto de padrões foi aplicado a cada motor. Para comparação, o F1 de campos por regex dos motores tradicionais chega a 0,0766 (docTR), 0,1477 (EasyOCR), 0,2237 (Docling) e 0,2335 (Tesseract) — seis dos sete motores não-VLM ficam abaixo do membro mais baixo do trio.

Fonte: field_method_comparison.csv — colunas regex_field_value_f1 / llm_field_value_f1, linhas sroie_2019 (0–1 decimais armazenados mostrados como %). Pós-processador LLM: deepseek-v4-flash (coluna llm_model). 361 amostras por motor (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 motor (pós-processado, não extração nativa). O 0.3183 do Surya2 é o menor do trio, mas ainda ocupa a quarta posição entre oito motores e fica 0.007 abaixo do melhor motor tradicional (PaddleOCR 0.3254, summary_metrics.csv field_f1_regex, linha paddleocr/sroie_2019).

A Alavanca do LLM: As Três Máquinas Convergem

Alimente o texto OCR das três máquinas a um pós-processador LLM (deepseek-v4-flash, temperatura 0) com um prompt de extração estruturada, e a faixa de desempenho inicial se estreita em um empate quase técnico: Surya2 0.6139, Unlimited-OCR 0.6054, PaddleOCR-VL 0.5921 — uma diferença de 0,022 ponto, totalmente dentro da faixa de convergência de 0,57–0,62 do benchmark para máquinas saudáveis. O pós-processador, e não o VLM, torna-se o componente decisivo.

Este é o mesmo padrão de convergência que a execução completa com 8 máquinas exibe: um LLM entende semântica (números, datas, nomes) em vez de corresponder a formas de caracteres, então ele absorve a maioria das diferenças na qualidade do texto a montante — desde que o texto seja legível o suficiente para trabalhar. Todos os três VLMs qualificam; todos ficam dentro da faixa. A alavanca traz um custo: uma chamada de LLM adiciona aproximadamente 1,9–2,3 s de latência mediana por documento além do tempo de OCR (1.946,7 ms para o texto do PaddleOCR-VL, 1.982,0 ms para o do Unlimited-OCR, 2.261,7 ms para o do Surya2 — incorridos via API e idênticos em natureza), o que favorece o processamento assíncrono em lote sobre as esperas síncronas por página. A exatidão no nível do documento — a fração de recibos onde todos os quatro campos corresponderam — permanece baixa para todos os três (0,1219–0,1551), um lembrete de que a pontuação F1 por campo é o número operacional significativo.

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 máquina (summary_metrics.csv latency_p50_ms).

CORD (Recibos Indonésios): O Generalista Compacto Vence

O CORD v2 (100 recibos indonésios, campos aninhados menu/sub_total/total) é o teste de resistência entre idiomas do benchmark—e é onde os três VLMs realmente se separam. Através dos mesmos padrões regex em formato inglês, o PaddleOCR-VL extrai campos de recibos indonésios com 0.3412 pontuação F1 por campo — a mais alta de todos os 8 motores em todo o benchmark — enquanto o Surya2 consegue 0.2458 e o Unlimited-OCR cai para 0.1079. A amplitude de treinamento do generalista compacto se mostra exatamente onde os modelos centrados em texto e de documentos longos perdem terreno.

Todos os valores de CER do CORD são isolados pelo protocolo do benchmark e nunca são mesclados em nenhum ranking do SROIE: a verdade básica do CORD incorpora a estrutura de anotação (inflando o CER bruto para cada motor além da incompatibilidade genuína de idioma—o cluster de CER do CORD para todos os motores de 0.90–1.08), e os padrões regex foram escritos para formatos em inglês. A comparação do CORD abaixo é apenas por métricas de campo. Sob um pós-processador LLM, o choque de idioma é absorvido como foi no SROIE: o trio reconverge para 0.4678–0.5203 pontuação F1 por campo (Surya2 0.5203, PaddleOCR-VL 0.5198, Unlimited-OCR 0.4678) — o pós-processador, não o motor, faz o trabalho pesado entre idiomas.

Fonte: summary_metrics.csv — coluna field_f1_regex, linhas cord_v2 (0–1 casas decimais armazenadas mostradas como %). PaddleOCR-VL 0.3412 é o máximo de field_f1_regex em todas as 16 linhas do arquivo; o melhor no regex do CORD é Surya2 0.2458.

Tabela: summary_metrics.csv (field_f1_regex / cer) e field_method_comparison.csv (llm_field_value_f1), linhas cord_v2. Não mesclé os números do CORD em nenhum ranking do SROIE: O CER do CORD combina incompatibilidade linguística genuína com inflação da estrutura de anotação no ground truth (todos os motores agrupados entre 0,90–1,08 — Tesseract tradicional 0,9523, docTR 0,9101 incluídos); o CER do PaddleOCR-VL de 1,0805 é o mais alto dos 8 motores precisamente porque sua saída limpa e normalizada está mais distante do ground truth carregado de estrutura do CORD — enquanto seu F1 de campo regex é o melhor do benchmark.

A Envolvente Operacional: 3,8× de Latência, 5,2× de Custo

A precisão dos campos converge; o custo operacional não. No mesmo RTX 4090 com a mesma taxa registrada de $0,76/hr, o PaddleOCR-VL sustenta 68,2 páginas/min com 694,3 ms p50 por página para $0,205 por 1.000 páginas; o Unlimited-OCR fica no meio da envolvente com 34,4 páginas/min, 1.600,7 ms p50, $0,388 por 1.000 páginas; o Surya2 é o outlier de preço e latência com 12,1 páginas/min, 2.668,0 ms p50, $1,061 por 1.000 páginas. O VLM mais rápido é 3,8× mais rápido e 5,2× mais barato que o mais lento em hardware idêntico.

O custo é calculado como tempo de execução em relógio de parede × 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 de parede, incluindo essa mesma inicialização. As latências p50/p95 são tempos de inferência por página em regime estável, medidos aquecidos-e-pontuados (excluindo carregamento do modelo); a cauda do Surya2 é proporcionalmente pior — 5.872,2 ms p95 contra 1.154,3 ms do PaddleOCR-VL — porque os picos de preenchimento/decodificação do VLM dominam a cauda nas primeiras páginas. Dois números para ler juntos em vez de contra si: o PaddleOCR-VL tem o menor p50, mas é ultrapassado no throughput em relógio de parede pelo Unlimited-OCR no CORD (73,99 vs 67,13 páginas/min) — os valores em relógio de parede incluem a inicialização do modelo, e o tratamento em lote do vLLM do Unlimited-OCR é eficiente o suficiente para inverter a ordem ali.

Fonte: summary_metrics.csv — coluna latency_p50_ms, linhas sroie_2019. Surya2 2667,9800, Unlimited-OCR 1600,7459, PaddleOCR-VL 694,2519. Latência em regime estável (modo de medição warm_then_scored).

Fonte: summary_metrics.csv — coluna cost_per_1000_pages, linhas sroie_2019. Surya2 1.0609, Unlimited-OCR 0.3879, PaddleOCR-VL 0.2048. Custo = tempo de execução real × $0.76/hr incluindo inicialização do modelo, preço com carimbo de data nos manifestos 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. Todos os três motores em GPU (RTX 4090, preço de $0.76/hr com carimbo de data nos manifestos); o custo inclui a inicialização do modelo, não é o throughput puro em regime permanente. Valores exatos: Surya2 p50 2668,0 / p95 5872,2 / 12,1 pg/min / $1.0609; Unlimited-OCR p50 1600,7 / p95 2521,9 / 34,4 pg/min / $0.3879; PaddleOCR-VL p50 694,3 / p95 1154,3 / 68,2 pg/min / $0.2048.

Quem Vence Quando: A Grade de Resumo

“Melhor” depende da carga de trabalho, e entre esses três VLMs os eixos se separam claramente: a precisão de campos converge (regex e LLM), o texto bruto de caracteres favorece Surya2, campos multilíngues favorecem PaddleOCR-VL, e todos os eixos de custo/latência/throughput favorecem PaddleOCR-VL com Unlimited-OCR no meio. A conclusão honesta é que em recibos, com qualquer pós-processador no pipeline, a escolha do VLM importa pouco — e sem um, o generalista compacto e barato supera os especialistas caros nos eixos que geralmente importam.

Perguntas Frequentes

Qual VLM de análise de documentos é mais preciso em recibos?

Na extração de campos, há um empate técnico entre três modelos em recibos em inglês: SROIE regex field F1 0.3183–0.3376 e LLM field F1 0.5921–0.6139 entre Surya2, Unlimited-OCR e PaddleOCR-VL (field_method_comparison.csv, linhas sroie_2019). Em recibos indonésios, a resposta muda: o CORD regex field F1 de 0.3412 do PaddleOCR-VL é o melhor entre todos os 8 motores no benchmark (summary_metrics.csv, field_f1_regex, linhas cord_v2). A CER bruta não deve ser usada para classificar VLMs — ela contabiliza convenções de saída (normalização de maiúsculas, fusão de linhas) como erros (veja a seção "Por que Não Usar CER" acima).

Por que o Unlimited-OCR tem a pior CER, mas o melhor regex field F1 no SROIE?

Porque as duas métricas avaliam saídas diferentes. A forte normalização de maiúsculas do Unlimited-OCR infla os erros em nível de caractere — sua CER de 0.6552 em comparação com a WER de 0.4779 é a prova — enquanto o mesmo texto normalizado acaba por corresponder melhor aos padrões de extração fixos do que qualquer outro motor: SROIE regex field F1 0.3376, o topo dos 8 motores (summary_metrics.csv cer / wer, field_method_comparison.csv regex_field_value_f1, linhas sroie_2019).

Por que a CER do CORD do PaddleOCR-VL é a pior no benchmark, enquanto seu CORD field F1 é o melhor?

Porque o ground truth do CORD incorpora a estrutura da anotação e a saída do PaddleOCR-VL é a mais limpa e normalizada — a mais distante desse texto carregado de estrutura, de modo que sua distância de edição é a maior (CER 1.0805). O mesmo estilo de saída alimenta bem os padrões de extração: CORD regex field F1 0.3412, o melhor entre todos os 8 motores (summary_metrics.csv, cer / field_f1_regex, linhas cord_v2). Esta inversão é a demonstração do próprio benchmark de que a CER do CORD não é uma leitura de qualidade por modelo.

Quão mais rápido e barato é o PaddleOCR-VL em comparação com o Surya2?

3,8× menor latência p50 (694,3 ms vs 2.668,0 ms), 5,6× maior throughput (68,2 vs 12,1 páginas/min) e 5,2× menor custo por 1.000 páginas ($0,205 vs $1,061) no mesmo RTX 4090 a $0,76/hr (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, linhas sroie_2019).

A adição de um pós-processador LLM iguala os três VLMs?

Quase — 0,5921 a 0,6139 de F1 de campos LLM no SROIE, uma diferença de 0,022 pontos dentro da faixa de convergência de 0,57–0,62 do benchmark (field_method_comparison.csv, llm_field_value_f1, linhas sroie_2019). O custo dessa convergência é de aproximadamente 1,9–2,3 s de latência mediana extra do LLM por documento (llm_median_latency_ms, mesmas linhas), o que favorece o processamento assíncrono em lote.

Qual dos três VLMs um pipeline de recibos deve escolher?

Depende do eixo que seu pipeline consome. Para campos nativos multilíngues sem pós-processador, o F1 de regex CORD do PaddleOCR-VL (0,3412) é o único nível útil medido. Para serviço de VLM mais barato e rápido, novamente o PaddleOCR-VL (694,3 ms, $0,205/1K páginas). Para texto bruto em inglês limpo quando custo e latência não são limitantes, a CER do Surya2 (0,1915) é a mais forte. Para um ponto equilibrado de volume médio, o Unlimited-OCR (1.600,7 ms, $0,388/1K páginas, melhor F1 de campos SROIE fora da caixa). Com um pós-processador LLM no pipeline, a escolha importa pouco para recibos — os três caem na faixa de convergência. Esses resultados valem para recibos em inglês e indonésios 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 valor é uma linha dos CSVs publicados do benchmark de primeira parte — results/summary_metrics.csv (CER/WER, campo F1, latência, custo, throughput) e results/field_method_comparison.csv (regex vs pós-processamento por 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 e Fontes

Protocolo

Esta página relata uma fatia tripla de uma execução de benchmark independente e reproduzível (nível oficial) — não um levantamento 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. Os três motores viram as mesmas imagens, a mesma verdade de referência e o mesmo protocolo de medição (warm_then_scored: uma passagem de aquecimento fixa precede a passagem pontuada, para que os valores de latência sejam em regime permanente). As três 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 três VLMs nomeados, e os resultados completos dos 8 motores são publicados separadamente em OCR Tradicional vs VLMs de Análise de Documentos.

Ambiente de Execução

• Hardware: os três motores rodaram na mesma NVIDIA RTX 4090 (24 GB); custo da GPU calculado na tarifa sob demanda do RunPod de $0.76/hr, preço com carimbo de data/hora no manifest editado de cada execução (agosto de 2026).
• Motores: prontos para uso, sem ajuste fino. Versões travadas: Surya2 (surya-ocr 0.22.1) e PaddleOCR-VL 1.6, ambos servidos via vLLM; Unlimited-OCR servido via vLLM sem versão publicamente fixada (ver Limitações) — 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 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 nos três 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 qualquer modelo; as colunas LLM_* medem texto OCR + extração por LLM. Os dois pipelines nunca são misturados.

Definições das Métricas

• CER (taxa de erro de caracteres): distância de edição (inserções + exclusões + substituições) entre o texto OCR e o gabarito, dividida pelos caracteres do gabarito. Quanto menor, melhor. Injusto para VLMs de análise de documentos: penaliza dobras de caixa, fusão de rótulo/valor e reordenação de linhas como erros, mesmo quando os valores dos campos estão corretos. Citado nesta página apenas com suas ressalvas.
• WER (taxa de erro de palavras): o mesmo cálculo de distância de edição em granularidade de palavra. Onde CER e WER divergem fortemente (Unlimited-OCR: 0.6552 vs 0.4779), a lacuna marca onde a normalização da saída, e não a leitura incorreta, está causando o problema.
• F1 de valor de campo (regex): média harmônica de precisão/recall sobre valores de campos 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 do que o F1 por campo.
• Latência p50/p95 e páginas/min: tempo de inferência por página em regime permanente (aquecido e depois 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 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. Toda taxa de erro de caracteres (CER), taxa de erro de palavras (WER), latência, custo e número de produtividade nesta página rastreia até as linhas surya2, unlimited_ocr e paddleocr_vl_vllm aqui.
2. field_method_comparison.csv (GitHub raw). 16 linhas; colunas model, dataset, llm_model (= deepseek-v4-flash), regex/llm field-value accuracy e F1, document-fields-exact, llm_median_latency_ms, contagens de tokens. Toda pontuação F1 de campo regex/LLM rastreia até as três linhas de motor nomeadas 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 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

• A injustiça da CER com os VLMs é o motivo desta página ser construída com métricas de campo: os VLMs de análise de documentos misturam maiúsculas/minúsculas, unem linhas de rótulo/valor e reordenam o texto, de modo que as pontuações brutas de CER tratam convenções de saída como erros — a divergência entre a CER (0.6552) e a WER (0.4779) do Unlimited-OCR e a inversão do CORD do PaddleOCR-VL (pior CER 1.0805, melhor F1 de campo 0.3412) são artefatos dessa taxa. Qualquer comparação que classifique VLMs por CER — incluindo nesta página — deve ser tratada como uma medida de estilo de saída, não de capacidade de leitura.
• Escopo do documento — apenas recibos: SROIE + CORD. Nada aqui mede o tratamento de layout/tabela/fórmula/documentos longos onde os VLMs de análise de documentos reivindicam suas maiores vantagens; os pontos fortes comercializados dos três motores (incluindo a análise de mais de 40 páginas em passagem única do Unlimited-OCR) são não medidos. Não use esta página para concluir "o VLM X vence em tudo."
• Tamanho da amostra: 361 recibos em inglês + 100 em indonésio. A F1 de campo e a CER são sensíveis ao corpus; diferenças de um único dígito de algumas centésimas (incluindo a variação de 0,022 pontos na F1-LLM) 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/hora, com preço datado de agosto de 2026 nos manifests de execução. Outras GPUs, atendimento multi-GPU, agendamento em lote ou alterações de preço mudarão a latência, o throughput e o custo — recalcule os custos com as taxas atuais antes de orçar.
• Único pós-processador LLM: todas as linhas de LLM usam deepseek-v4-flash com temperatura 0. Um LLM diferente altera a F1 de campo absoluta; a ordem de convergência pode se mover nas margens. A latência do LLM (~1,9–2,3 s mediana, llm_median_latency_ms no field_method_comparison.csv) é incorrida pela API e não faz parte da latência de nenhum motor.
• Quarentena do CORD: o ground truth do CORD incorpora a estrutura de anotação e os padrões regex foram escritos para formatos em inglês; a CER do CORD (0,90–1,08 em todos os motores) reflete incompatibilidade de idioma + inflação do ground-truth, não qualidade por modelo. As linhas do CORD são citadas com contextualização e nunca são mescladas em qualquer classificação SROIE (regra de protocolo).
• Fixação de versão: os resultados valem para Surya2 0.22.1, PaddleOCR-VL 1.6 e Unlimited-OCR servido via vLLM (agosto de 2026). O Unlimited-OCR não possui um número de versão publicamente fixado na tabela de modelos publicada do benchmark, de modo que sua linha não pode ser rastreada até um lançamento exato; versões mais recentes de qualquer motor podem alterar todos os números nesta página.
• 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.

Referências relacionadas: docTR vs Surya2 Receipt Benchmark · Traditional OCR vs Document Parsing VLMs · Regex vs LLM Field Extraction · Field-Level vs Character-Level Accuracy · Receipt OCR 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)