Surya2 vs Unlimited-OCR vs PaddleOCR-VL:
Benchmark de VLM para Recibos (2026)

Os três mecanismos são modelos de visão e linguagem (VLMs) de parsing de documentos: modelos neurais que leem uma imagem de documento inteira e geram texto compreendido — com normalização de caixa, pares rótulo/valor mesclados em linhas únicas, linhas reordenadas por ordem de leitura — em vez dos fluxos de caracteres brutos com caixa original que mecanismos de OCR tradicionais (Tesseract, PaddleOCR, EasyOCR, docTR — os outros mecanismos da 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 mostra a próxima seção. Dentro da família VLM, os três diferem bastante em tamanho e alvo de treinamento: Surya2 é um modelo de 650M de parâmetros, centrado em texto, ajustado para transcrição limpa de páginas inteiras (90+ idiomas); PaddleOCR-VL é um generalista compacto de 0.9B construído para amplitude entre idiomas, tabelas e fórmulas; Unlimited-OCR é orientado ao parsing de documentos longos e em lote (leitura em passagem única de documentos com 40+ páginas é seu núcleo comercializado). Uma ressalva importante se aplica a cada 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, então ela pune exatamente as normalizações que os VLMs são treinados para realizar. A pontuação F1 em nível de campo é a barra mais justa entre VLMs, e é a espinha dorsal desta página.

Por que não usar CER para VLMs: a variação de 3,4× é convenção de saída, não capacidade de leitura

Leia apenas a coluna de CER bruto e 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, 0,1971, como o melhor CER bruto na execução de 8 mecanismos). Ambas as leituras são artefatos do estilo de saída. O mesmo texto do Unlimited-OCR que pontua 0,6552 em CER pontua 0,4779 em WER — suas palavras sobrevivem enquanto seus caracteres parecem danificados, porque a normalização de caixa substitui caracteres sem quebrar palavras. Os números do PaddleOCR-VL invertem o padrão: seu CER de CORD de 1,0805 é o pior de todos os 8 mecanismos, enquanto seu F1 de campo de CORD de 0,3412 é o melhor de todos os 8 — o próprio CSV do benchmark contradiz a classificação de CER.

O mecanismo tem duas camadas. Camada 1 — imposto de normalização: VLMs de parsing de documentos geram texto “compreendido” — TAN CHAY YEE vira tan chay yee, INVOICE NO : PEGIV mescla um rótulo e um valor em uma linha. CER é correspondência exata de caracteres, então cada caixa normalizada e linha mesclada é pontuada como erro, mesmo quando o valor do campo está correto. A análise de decomposição de erros do benchmark das previsões de SROIE lançadas atribui aproximadamente um quinto do orçamento bruto de CER a substituições de caixa e aproximadamente um décimo a mesclas/remoções de linhas; os três mecanismos pagam esse imposto em taxas diferentes — a forte normalizaçã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 estrutural da referência no CORD: o texto de referência do CORD incorpora estrutura de anotação (entradas de menu, coordenadas, rótulos de campo), então o CER é sistematicamente inflado para cada mecanismo, além da incompatibilidade genuína de idioma — o agrupamento de CER de CORD de todos os mecanismos de 0,90–1,08 (Tesseract tradicional 0,9523, docTR 0,9101, e todos os VLMs incluídos) confirma que a inflação é generalizada no 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. Quanto menor, melhor; as três execuções foram concluidas com error_rate 0.0. Não classifique VLMs por CER: a divergência CER/WER de Unlimited-OCR (0.6552 vs 0.4779) e a inversão CER-vs-F1-de-campo de PaddleOCR-VL no CORD (veja abaixo) são artefactos de convenção de saída exatamente do tipo que o protocolo deste benchmark assinala 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 na pontuação F1 de extração de campos (as métricas que alimentam diretamente sua saída estruturada) e no envelope operativo (latência, throughput, custo) — e cita o CER apenas junto com suas ressalvas. Esta é a regra do protocolo do benchmark para linhas de VLM de parsing 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 Pronta para Uso: a Saída Estruturada É uma Característica da Família VLM

Execute o texto bruto de cada motor com os 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 os três VLMs ficam dentro de uma banda de 0,02 pontos: Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368, Surya2 0,3183. Todos os três estão entre os quatro primeiros da 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 nenhum pós-processador LLM — a característica da família que falta aos motores de OCR de caracteres brutos.

A pontuação F1 do valor de campo é a média harmónica de precisão e recall sobre os valores de campo extraídos em comparação com a verdade de base: 1,0 significa que cada campo de recibo foi perfeitamente recuperado, 0 significa que nada foi. O mecanismo por trás da vantagem da família VLM é a forma de saída descrita acima — o mesmo texto em minúsculas e estruturado por rótulos que infla o CER coincide com os 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 texto OCR + extração baseada em regras a jusante, não saída estruturada nativa, e o mesmo conjunto de padrões foi aplicado a todos os motores. Para contraste, o F1 de campos por regex dos motores tradicionais fica em 0,0766 (docTR), 0,1477 (EasyOCR), 0,2237 (Docling) e 0,2335 (Tesseract) — seis dos sete motores não-VLM estão abaixo do membro mais baixo do trio.

Fonte: field_method_comparison.csv — colunas regex_field_value_f1 / llm_field_value_f1, linhas sroie_2019 (decimais 0–1 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. 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 0.3183 de Surya2 é o mais baixo do trio, mas ainda ocupa o quarto lugar 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: Os Tres Motores Convergem

Alimente os três motores com o texto de OCR de um pós-processador LLM (deepseek-v4-flash, temperatura 0) com um prompt de extração estruturada, e a banda fora da caixa se estrecha até quase empatar: Surya2 0.6139, Unlimited-OCR 0.6054, PaddleOCR-VL 0.5921 — uma dispersão de 0,022 pontos, totalmente dentro da banda de convergencia de 0,57–0,62 do benchmark para motores saudáveis. O pós-processador, não o VLM, se torna o componente decisivo.

Este é o mesmo padrão de convergencia que a execução completa de 8 motores exibe: um LLM entende semântica (números, datas, nomes) em vez de comparar formas de caracteres, então absorbe a maioria das diferenças na qualidade do texto upstream — desde que o texto seja legível o suficiente para trabalhar. Todos os três VLMs se qualificam; todos os três caem dentro da banda. A alavanca tem um custo: uma chamada 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 de PaddleOCR-VL, 1.982,0 ms para o de Unlimited-OCR, 2.261,7 ms para o de Surya2 — incorrida pela API e idéntica em natureza), o que favorece o processamento assíncrono em lote sobre esperas síncronas por página. A exatitud a nível de documento — a fração de recibos onde todos os quatro campos coincidieron — permanece baixa para todos os três (0,1219–0,1551), um lembrete de que o F1 por campo é o número operativo significativo.

Tabela: field_method_comparison.csv — colunas llm_*, filas sroie_2019. Modelo LLM: deepseek-v4-flash a temperatura 0 (columna llm_model). A latência do LLM é incorrida pela API e separada da latência do motor (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 estresse multilíngue do benchmark — e é onde os três VLMs realmente se separam. Com os mesmos padrões de regex em formato inglês, o PaddleOCR-VL extrai campos de recibos indonésios com 0,3412 de pontuação F1 de campo — o maior de todos os 8 mecanismos em todo o benchmark — enquanto o Surya2 alcança 0,2458 e o Unlimited-OCR cai para 0,1079. A amplitude de treinamento do generalista compacto 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 nenhuma classificação do SROIE: o ground truth do CORD incorpora estrutura de anotação (inflando o CER bruto para todos os mecanismos, além da incompatibilidade genuína de idioma — o cluster de CER do CORD para todos os mecanismos fica em 0,90–1,08), e os padrões de regex foram escritos para formatos em inglês. A comparação do CORD abaixo é apenas de métricas de campo. Com um pós-processador LLM, o choque de idioma é absorvido como foi no SROIE: o trio volta a convergir para 0,4678–0,5203 de pontuação F1 de campo (Surya2 0,5203, PaddleOCR-VL 0,5198, Unlimited-OCR 0,4678) — o pós-processador, não o mecanismo, faz o trabalho pesado multilíngue.

Fonte: summary_metrics.csv — coluna field_f1_regex, linhas cord_v2 (decimais armazenados de 0–1 mostrados como %). O valor 0,3412 do PaddleOCR-VL é o field_f1_regex máximo em todas as 16 linhas do arquivo; o segundo melhor no regex do CORD é o Surya2 com 0,2458.

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

O Envelope Operacional: 3,8× de Latência, 5,2× de Custo

A precisão de campo converge; o custo operacional não. Na mesma RTX 4090 à mesma taxa registrada de $0,76/hora, o PaddleOCR-VL sustenta 68,2 páginas/min a 694,3 ms p50 por página por $0,205 por 1.000 páginas; o Unlimited-OCR fica no meio do envelope a 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 a 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 no mesmo hardware.

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. A taxa de transferência é o total de páginas por minuto em tempo real, incluindo essa mesma inicialização. As latências p50/p95 são tempos de inferência por página em estado estável, medidos após aquecimento (excluindo o 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 prefill/decode do VLM dominam a cauda nas primeiras páginas. Dois números para ler juntos, e não um contra o outro: o PaddleOCR-VL tem o menor p50, mas é superado na taxa de transferência em tempo real pelo Unlimited-OCR em CORD (73,99 vs 67,13 páginas/min) — os números em tempo real incluem a inicialização do modelo, e o manuseio de lote 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 estado 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 em relógio de parede × US$ 0,76/h incluindo inicialização do modelo, preço com registro de data e hora 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. Os três mecanismos em GPU (RTX 4090, preço de US$ 0,76/h com registro de data e hora nos manifestos); o custo inclui a inicialização do modelo, não a vazão pura em estado estacionário. Valores exatos: Surya2 p50 2668,0 / p95 5872,2 / 12,1 pg/min / US$ 1,0609; Unlimited-OCR p50 1600,7 / p95 2521,9 / 34,4 pg/min / US$ 0,3879; PaddleOCR-VL p50 694,3 / p95 1154,3 / 68,2 pg/min / US$ 0,2048.

Quem Vence Quando: O Resumo

“Melhor” depende da carga de trabalho, e entre esses três VLMs os eixos se dividem claramente: a precisão de campos converge (regex e LLM), o texto bruto de caracteres favorece o Surya2, campos multilíngues favorecem o PaddleOCR-VL, e todos os eixos de custo/latência/throughput favorecem o PaddleOCR-VL com o 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 parsing de documentos é mais preciso em recibos?

Na extração de campos, há um quase empate triplo em recibos em inglês: F1 de campo regex SROIE 0.3183–0.3376 e F1 de campo LLM 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 F1 de campo regex CORD do PaddleOCR-VL, de 0.3412, é o melhor de todos os 8 mecanismos no benchmark (summary_metrics.csv, field_f1_regex, linhas cord_v2). O CER bruto não deve ser usado para classificar VLMs — ele conta convenções de saída (dobramento 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 o pior CER, mas o melhor F1 de campo regex no SROIE?

Porque as duas métricas avaliam saídas diferentes. O forte dobramento de maiúsculas do Unlimited-OCR infla os erros em nível de caractere — seu CER de 0.6552 vs. WER de 0.4779 é o indicativo — enquanto o mesmo texto normalizado acaba correspondendo melhor aos padrões fixos de extração do que qualquer outro mecanismo: F1 de campo regex SROIE 0.3376, o topo da execução de 8 mecanismos (summary_metrics.csv cer / wer, field_method_comparison.csv regex_field_value_f1, linhas sroie_2019).

Por que o CER CORD do PaddleOCR-VL é o pior do benchmark, enquanto seu F1 de campo CORD é o melhor?

Porque o ground truth do CORD incorpora estrutura de anotação, e a saída do PaddleOCR-VL é a mais limpa e normalizada — a mais distante desse texto com estrutura, então 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: F1 de campo regex CORD 0.3412, o melhor de todos os 8 mecanismos (summary_metrics.csv, cer / field_f1_regex, linhas cord_v2). Essa inversão é a própria demonstração do benchmark de que o CER CORD não é uma leitura de qualidade por modelo.

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

Adicionar um pós-processador LLM torna os três VLMs equivalentes?

Quase — 0,5921 a 0,6139 de F1 de campo LLM no SROIE, uma diferença de 0,022 ponto 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 LLM mediana adicional 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 em inglês bruto e limpo quando custo e latência não são limitantes, o CER do Surya2 (0,1915) é o mais forte. Para um ponto equilibrado de volume médio, Unlimited-OCR (1.600,7 ms, $0,388/1K páginas, melhor F1 de campo SROIE pronto para uso). Com um pós-processador LLM no pipeline, a escolha importa pouco em recibos — todos os três ficam na faixa de convergência. Esses resultados valem para recibos em inglês e indonésio em um nível de GPU em agosto de 2026; qualquer decisão de produção deve ser reexecutada no corpus-alvo (ver Limitações).

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

Cada figura é uma linha dos CSVs publicados do benchmark proprietário — results/summary_metrics.csv (CER/WER, F1 de campo, 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 um recorte de três vias 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 entre fornecedores. Apenas divisões de teste fixas: teste SROIE 2019 (361 recibos em inglês, campos planos 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. Os três mecanismos viram 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 de estado estacionário). As três 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 três VLMs nomeados, e os resultados completos dos 8 mecanismos são publicados separadamente em Traditional OCR vs Document Parsing VLMs.

Ambiente de Execução

• Hardware: os três mecanismos rodaram na mesma NVIDIA RTX 4090 (24 GB); custo de GPU calculado na tarifa sob demanda da RunPod de $0.76/hora, preço com registro de data e hora no manifest editado de cada execução (agosto de 2026).
• Mecanismos: prontos para uso, sem ajuste fino. Versões fixadas: Surya2 (surya-ocr 0.22.1) e PaddleOCR-VL 1.6, ambos servidos por vLLM; Unlimited-OCR servido por 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 na 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 nos três mecanismos.
• Base de custo: tempo de execução em parede × $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 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. Elas medem OCR + extração a jusante, não saída estruturada nativa de nenhum modelo; as colunas LLM_* medem texto OCR + extração por LLM. Os dois pipelines nunca são misturados.

Definições de Métricas

• CER (taxa de erro de caracteres): distância de edição (inserções + deleções + substituições) entre o texto do OCR e a referência, dividida pelos caracteres da referência. Quanto menor, melhor. Injusto para VLMs de parsing de documentos: penaliza diferenças de capitalização, fusão de rótulo/valor e reordenamento de linhas como erros, mesmo quando os valores dos campos estão corretos. Citado nesta página apenas junto com suas ressalvas.
• WER (taxa de erro de palavras): o mesmo cálculo de distância de edição em granularidade de palavras. Onde CER e WER divergem acentuadamente (Unlimited-OCR: 0,6552 vs 0,4779), a diferença marca onde a normalização da saída, e não um erro de leitura, está causando o problema.
• 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 do OCR (pipeline tradicional de OCR + KIE baseado em regras). Columna: regex_field_value_f1. Uma pontuación de 0 significa que nenhun 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). Columna: llm_field_value_f1. Os dois pipelines são diferentes e nunca são combinados.
• Exactitud de campos do documento: fracción de documentos onde todos os campos alvo coincidem exatamente — um padrão muito mais rigoroso que o F1 por campo.
• Latência p50/p95 & páginas/min: tempo de inferência por página em estado estacionário (aquecido e depois pontuado, excluye carga do modelo) e rendimento de parede incluindo inicialização do modelo.
• Custo por 1.000 páginas: horas de GPU cobradas por 1.000 páginas à tarifa 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 rendimento desta página provienen das filas 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), precisão e F1 de valores de campo regex/llm, document-fields-exact, llm_median_latency_ms, contagens de tokens. Todos os números de F1 de campo regex/LLM provienen das filas dos três motores nomeados aqui.
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que aloja los CSVs de resultados, manifiestos de ejecución redactados, protocolo congelado y listas de muestras de conjuntos de datos (divisiones de prueba fijas) para reproducción.
4. results/manifests/ (GitHub). Un manifest.json redactado por ejecución publicada (16 ejecuciones) con versiones de modelo, GPU/driver, versiones de torch/CUDA/Python, metadatos de costo con marca de tiempo de precio y hashes de artefactos.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definición del conjunto de datos SROIE 2019, estructura de tareas y licencia (CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definición del conjunto de datos CORD v2, esquema de campos anidados y licencia (CC-BY-4.0).

Limitações

• A injustiça do CER para VLMs é o motivo desta página ser baseada em métricas de campo: VLMs de parsing de documentos dobram maiúsculas/minúsculas, mesclam linhas de rótulo/valor e reordenam texto, então pontuações brutas de CER tratam convenções de saída como erros — a divergência entre CER (0,6552) e 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 ambos artefatos desse custo. Qualquer comparação que classifique VLMs por CER — inclusive 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 VLMs de parsing de documentos afirmam suas maiores vantagens; os pontos fortes divulgados dos três mecanismos (incluindo o parsing de passagem única de 40+ páginas do Unlimited-OCR) são não medidos. Não use esta página para concluir “VLM X vence em tudo.”
• Tamanho da amostra: 361 recibos em inglês + 100 em indonésio. F1 de campo e CER são sensíveis ao corpus; diferenças de alguns centésimos (incluindo a diferença de 0,022 ponto no F1 do LLM) devem ser tratadas como ruído, não como verdade de engenharia.
• Nível único de GPU e preço único: todos os números vêm de uma RTX 4090 a $0,76/hora, preço com registro de agosto de 2026 nos manifests 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.
• Pós-processador LLM único: 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 (~1,9–2,3 s mediana, field_method_comparison.csv llm_median_latency_ms) é incorrida pela API e não faz parte da latência de nenhum mecanismo.
• Quarentena do CORD: o ground truth do CORD incorpora estrutura de anotação e os padrões de regex foram escritos para formatos em inglês; o CER do CORD (0,90–1,08 em todos os mecanismos) reflete incompatibilidade de idioma + inflação do ground truth, não qualidade por modelo. As linhas do CORD são citadas com enquadramento e nunca mescladas em nenhuma 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 tem número de versão publicamente fixado na tabela de modelos publicada do benchmark, então sua linha não pode ser rastreada até uma versão exata; versões mais recentes de qualquer mecanismo podem alterar todos os números desta página.
• Ajuste de regex: o conjunto de padrões foi escrito uma vez por conjunto de dados. Uma biblioteca de padrões fortemente ajustada por formato poderia pontuar mais alto em seus próprios layouts — ao custo de manutenção que o LLM elimina.

Referências relacionadas: Benchmark de Recibos docTR vs Surya2 · OCR Tradicional vs VLMs de Parsing de Documentos · qual método de extração vence em layouts bagunçados · pontuação por campo vs pontuação por caractere · Precisão de OCR de Recibos

Leitura relacionada: OCR com IA versus OCR tradicional · extração de dados de imagem versus mecanismos de OCR · Preços de Extração de Documentos com IA (2026)