OCR Tradicional vs VLMs de Análise de Documentos
Resultados do Benchmark de Notas Fiscais (2026)

A Taxa de Erro de Caracteres (CER) mede a fração de caracteres individuais que são lidos incorretamente — exclusões, inserções e substituições divididas pelos caracteres da verdade fundamental. É a medida clássica de OCR, e é onde a narrativa de "superioridade dos VLMs" desmorona em recibos em inglês.

No SROIE 2019, os dois melhores reconhecedores de texto são um VLM e um motor tradicional, separados por 0,006 pontos: Surya2 com 0,191 e docTR com 0,197, com PaddleOCR em terceiro (0,204). Os três VLMs restantes — PaddleOCR-VL 0,337, Docling 0,591, Unlimited-OCR 0,655 — ficam em ou abaixo de motores tradicionais como EasyOCR (0,283) e Tesseract (0,335).

Precisão de Caracteres por Modelo no SROIE (Recibos em Inglês)

Fonte: summary_metrics.csv — coluna cer, linhas sroie_2019 (8 linhas). Surya2 0,1915, docTR 0,1971, PaddleOCR 0,2045, EasyOCR 0,2833, Tesseract 0,3347, PaddleOCR-VL 0,3370, Docling 0,5909, Unlimited-OCR 0,6552. Menor é melhor. Tesseract é apenas CPU.

Tabela: summary_metrics.csv — colunas cer e wer, linhas sroie_2019, 361 amostras cada (error_rate 0.0 para todos os 8 modelos). CER = taxa de erro de caracteres, WER = taxa de erro de palavras; menor é melhor. Valores exatos: Surya2 cer 0.19147 / wer 0.27352; docTR cer 0.19707 / wer 0.31990.

A Taxa de Erro de Palavras conta a mesma história com uma granularidade diferente: pontua erros de palavras inteiras em vez de caracteres. Surya2 lidera o WER com 0.274, seguido por docTR com 0.320. Observe o caso isolado no final: Unlimited-OCR tem o pior CER (0.655) mas um WER na média (0.478) — sua saída é fortemente normalizada quanto a maiúsculas e formato (uma convenção de saída discutida na seção de metodologia), o que infla as edições no nível de caracteres mesmo quando as palavras estão em grande parte intactas.

Docling merece uma nota de classificação antes de aparecer nas comparações: não é nem um motor de OCR tradicional puro nem um VLM. Docling é um analisador por pipeline — uma cadeia de ferramentas escalonada que executa análise de layout, detecção de tabelas e reconstrução de ordem de leitura em torno de um núcleo de OCR. Em um cupom simples, essa sobrecarga do pipeline compra pouco, o que é parte do motivo pelo qual seu CER bruto (0,591 no SROIE) fica atrás dos motores de passagem única.

Custo e Latência: A Vantagem do Motor Tradicional

Se a precisão de caracteres não decide nada entre as duas famílias, custo e latência decidem quase tudo. No mesmo conjunto de teste, docTR sustenta 449 páginas/min a 108,7 ms p50 por página por $0,048 por 1.000 páginas; Surya2 sustenta 12 páginas/min a 2.668 ms p50 por $1,061 por 1.000 páginas — aproximadamente 37× o throughput, 24,5× a latência por página e 22× o custo por mil páginas.

O custo é calculado como tempo de execução real × a taxa do RunPod RTX 4090 ($0,76/hora, preço com carimbo de tempo nos manifests de execução) — o preço que você realmente pagaria pelo tempo de GPU, incluindo a inicialização do modelo. Tesseract é o caso especial: apenas CPU, não tem custo de GPU e ainda assim consegue 78,6 páginas/min no SROIE; sua célula de custo está vazia no CSV por design, não porque é gratuito, mas porque não consome horas de GPU faturadas.

Fonte: summary_metrics.csv — coluna latency_p50_ms, linhas sroie_2019. docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9 (CPU), PaddleOCR-VL 694,3, Docling 732,0, Unlimited-OCR 1600,7, Surya2 2668,0. Latência em regime permanente, modo de medição aquecer-depois-avaliar (exclui carregamento do modelo).

Fonte: summary_metrics.csv — coluna cost_per_1000_pages, linhas sroie_2019. docTR 0,0479, EasyOCR 0,1098, PaddleOCR-VL 0,2048, PaddleOCR 0,2214, Unlimited-OCR 0,3879, Docling 0,3978, Surya2 1,0609. Tesseract apenas CPU: célula vazia no CSV (sem custo de GPU); custo inclui init do modelo, não throughput puro em regime permanente.

Tabela: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, linhas sroie_2019. Execuções em GPU com RTX 4090 ($0.76/hr, preço com timestamp nos manifests); Tesseract rodou apenas em CPU (célula de custo vazia, não zero). Throughput é páginas/min em tempo real, incluindo inicialização do modelo.

A coluna de latência de cauda importa se você se preocupa com o comportamento no pior caso, não apenas com as medianas. A p95 do PaddleOCR de 3,331 ms e a do Docling de 3,240 ms estão longe de seus valores de p50 — efeitos da primeira página e picos de prefill dominam a cauda em engines de GPU — enquanto a p95 do docTR (281 ms) permanece apertada. Para cargas de trabalho interativas (um usuário esperando por uma página), essa diferença de p95 é a diferença entre uma espera de 0,3 segundo e uma espera de mais de 3 segundos.

CORD (Indonesian Receipts): Incompatibilidade de Idioma e Inflação do Ground-Truth

O CORD v2 é um conjunto de dados de recibos indonésios com campos aninhados (menu, sub_total, total). Nenhuma das 8 ferramentas foi treinada predominantemente em recibos indonésios, então o CORD funciona como um teste de estresse entre idiomas — e a CER de cada ferramenta colapsa para 0,90–1,08. Esses números devem ser lidos com a ressalva de que o texto ground-truth do CORD incorpora a estrutura de anotação, o que infla a CER bruta de cada ferramenta; os resultados do CORD são mantidos estritamente separados do ranking do SROIE e não podem ser mesclados em um único leaderboard.

Duas forças distintas empurram a CER do CORD para 1,0, e apenas uma delas é o idioma em si. Primeiro, o idioma: ferramentas treinadas em inglês realmente leem incorretamente palavras indonésias — nomes indonésios, endereços e formatos de moeda (Rp) estão fora de suas distribuições de treinamento. Segundo, o ground-truth: as anotações de texto publicadas do CORD incorporam a estrutura de anotação (rótulos de campo com coordenadas) em vez de texto visível puro, então a CER bruta mede a distância de edição contra uma string estruturalmente aumentada. Os exemplos de VLM mais limpos são os mais penalizados — o PaddleOCR-VL com CER 1,080 é o artefato extremo desse mecanismo, não uma leitura de sua qualidade de texto.

A comparação justa entre famílias no CORD é, portanto, a métrica de campo, não a CER (veja a próxima seção). O que as colunas de CER ainda mostram de forma útil é que a incompatibilidade de idioma é real e universal entre as arquiteturas — cada família, tradicional e VLM, cai na mesma faixa de 0,90–1,08 sem vantagem estrutural para nenhuma delas.

Tabela: summary_metrics.csv — coluna cer, linhas cord_v2, 100 amostras cada. Não compare esses números com SROIE em um ranking combinado: O CER CORD combina incompatibilidade linguística genuína com inflação da estrutura de anotação no ground truth (metodologia abaixo). Um CER acima de 1.0 (PaddleOCR-VL 1.0805) é um artefato de distância de edição desse ground truth inflado.

F1 de Campo: O Pós-processamento por LLM Converge o Campo

A precisão de caracteres classifica os motores; a extração de campos é o que os usuários de produção realmente pagam. O benchmark extrai quatro campos de recibos (empresa, data, endereço, total) do texto OCR de cada motor usando dois pós-processadores — padrões regex fixos (a abordagem tradicional de OCR + KIE baseada em regras) e um LLM (deepseek-v4-flash) com um prompt estruturado. O resultado: o LLM quase apaga a diferença entre os motores no SROIE, puxando seis dos oito motores para uma faixa de F1 de campo de 0,57–0,62 — onde seus resultados de regex estavam espalhados em uma faixa de 0,26 pontos.

O F1 de valor de campo é a média harmônica de precisão e recall sobre os valores de campo extraídos, pontuados contra a verdade fundamental — 1,0 significa que cada valor de campo foi extraído perfeitamente, 0 significa que nada foi recuperado. As colunas de regex usam um conjunto fixo de padrões por conjunto de dados; as colunas de LLM usam deepseek-v4-flash com temperatura 0 para saída determinística (a coluna llm_model no CSV de comparação). As duas métricas medem pipelines diferentes e nunca são combinadas.

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 motor (llm_ok_count).

Tabela: field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1, linhas sroie_2019. LLM = pós-processamento com deepseek-v4-flash (coluna llm_model). docTR regex 0.0766 → LLM 0.6171 (ganho de 8,1×); os 6 motores não atrasados variam de 0,5685–0,6171.

Dois resultados contra-intuitivos estão nesta tabela. Primeiro, docTR tem o pior F1 de campo regex no SROIE (0,077) e o melhor F1 de campo LLM (0,617) — o mesmo texto OCR limpo que o regex extraiu de apenas 7,7% dos campos rendeu 61,7% sob o LLM. O gargalo era o pós-processador, não o OCR. Segundo, os dois motores que ficam fora da faixa de 0,57–0,62 são exatamente os dois com bases OCR degradadas: EasyOCR (0,372, CER SROIE 0,283) e Tesseract — cujo resultado no CORD (F1 de campo LLM 0,163) mostra que um LLM não consegue extrair campos de texto que ele fundamentalmente não consegue ler (CER CORD 0,9523). O teto de qualquer pós-processador é a qualidade da base OCR subjacente.

No CORD, o LLM também absorve parte do choque linguístico: o F1 de campos do LLM se mantém em 0.47–0.55 para os motores saudáveis (PaddleOCR 0.553, docTR 0.550, PaddleOCR-VL 0.520, Surya2 0.520), embora o regex colapse para quase zero (docTR 0.0, EasyOCR 0,7%) — os padrões foram escritos para formatos em inglês, e a penalidade de "mais um idioma" é paga quase inteiramente pelas regras, não pelo LLM (field_method_comparison.csv, llm_field_value_f1 / regex_field_value_f1, linhas cord_v2).

Por que o CER Subestima os VLMs de Análise de Documentos

O CER compara a saída do VLM e o ground truth caractere por caractere, e os VLMs são punidos por dois comportamentos legítimos que não são erros de reconhecimento: normalização de maiúsculas/minúsculas e junção de rótulo/valor. A decomposição do CER no benchmark para os atributos do SROIE atribui aproximadamente 18% do CER do VLM a diferenças de formato de maiúsculas/minúsculas (ex., TAN CHAY YEE → tan chay yee) e aproximadamente 10% à junção de linhas ou linhas separadoras omitidas — com os valores dos campos em si (empresa, total, data) realmente corretos (análise de decomposição do CER registrada nas notas do protocolo do benchmark, execuções do SROIE).

A tensão de design é real e estrutural: os motores de OCR tradicionais produzem texto bruto com a caixa intacta, portanto são otimizados por design para a pontuação do CER; os VLMs de análise de documentos produzem texto "compreendido" (caixa normalizada, pares rótulo-valor mesclados, linhas reordenadas), o que está mais próximo do que um sistema downstream deseja, mas mais distante de correspondências exatas de caracteres. É por isso que o título da página usa o CER apenas onde é uma comparação justa entre saídas semelhantes, e por que a comparação justa entre famílias está nas métricas de campos — e por que o CER do CORD (que além disso sofre com a inflação da estrutura de anotação) está isolado em sua própria seção. O ponto mais amplo: uma diferença de CER entre famílias não é automaticamente uma diferença de precisão, e qualquer pessoa comparando modelos entre famílias deve verificar o que o CER está medindo antes de concluir que uma família "lê melhor."

Como Escolher: Qual Eixo Importa para Sua Carga de Trabalho

"Melhor" é sem sentido sem uma carga de trabalho. A conclusão honesta do benchmark é que as duas famílias vencem em eixos diferentes, e recibos especificamente medem os eixos onde motores tradicionais vencem e os eixos onde o pós-processamento — não a família do motor — decide a qualidade dos campos.

A orientação de seleção é derivada diretamente das linhas CSV citadas; é uma ajuda ao leitor baseada em dados, não um endosso de fornecedor. Seus resultados exatos variam com hardware, mistura de documentos e versões de modelo.

Perguntas Frequentes

Os VLMs de análise de documentos são mais precisos que o OCR tradicional em recibos?

Não em precisão bruta de caracteres — o melhor VLM e o melhor motor tradicional estão estatisticamente empatados no SROIE 2019 (Surya2 CER 0.191 vs docTR 0,197, summary_metrics.csv sroie_2019 rows), e o PaddleOCR (0,204) é o terceiro. Quando o objetivo é a extração de campos, com ou sem VLM, o pós-processamento por LLM é o fator decisivo (faixa de convergência 0,57–0,62, field_method_comparison.csv).

Quando o OCR tradicional faz mais sentido do que um VLM de análise de documentos?

Quando o volume é alto, o custo é cobrado por uso ou a latência precisa ser interativa. No SROIE, o docTR processou 449 páginas/min a $0,048 por 1.000 páginas e 108,7 ms p50; o Surya2 processou 12 páginas/min a $1,061 por 1.000 páginas e 2.668 ms p50 (summary_metrics.csv, doctr and surya2 sroie_2019 rows). Para uma espera interativa por página, a diferença é de 0,1 segundos vs 2,7 segundos.

Por que os VLMs de análise de documentos às vezes pontuam pior no CER do que um OCR barato?

Porque o CER mede correspondências exatas de caracteres, e os VLMs são penalizados por normalização de maiúsculas/minúsculas e fusão de rótulo/valor, que são convenções de saída, não erros de leitura. A decomposição do CER no benchmark no SROIE atribui aproximadamente 18% do CER dos VLMs a diferenças de formato de maiúsculas e ~10% a fusão de linhas/separadores omitidos — com os valores dos campos frequentemente corretos (veja Metodologia). O CER do CORD é adicionalmente inflado pela estrutura de anotação dentro de seu ground truth, razão pela qual esta página isola o CER do CORD de qualquer classificação e usa métricas de campo para comparação entre famílias.

Quanto custa o OCR de recibos por página em uma RTX 4090?

Entre $0.048 (docTR) e $1.061 (Surya2) por 1.000 páginas em uma RTX 4090 a $0.76/hr, preço com data de agosto de 2026 nos manifests de execução (summary_metrics.csv cost_per_1000_pages, linhas sroie_2019). O Tesseract é apenas para CPU e não consome horas de GPU. O custo inclui a inicialização do modelo, então o custo por página diminui conforme o tamanho do lote aumenta.

Por que todos os modelos pontuam acima de 0.90 CER nos recibos CORD?

Duas causas combinadas: incompatibilidade genuína de idioma (recibos em indonésio fora do foco de treinamento de todos os motores) e inflação de estrutura de anotação dentro do texto ground-truth do CORD. Nenhuma família escapa disso — todos os 8 modelos ficam na faixa de 0,90–1,08 (summary_metrics.csv cer, linhas cord_v2). O CORD é um conjunto de estresse de robustez de idioma/layout, mantido separado do ranking do SROIE.

Um LLM vai simplesmente corrigir minha saída de OCR ruim?

Apenas até a qualidade do texto base. No SROIE, o LLM elevou seis motores para uma faixa de F1 de campo de 0,57–0,62, independentemente do motor (field_method_comparison.csv), mas o caso do Tesseract no CORD mostra o limite: com CER de 0,9523, seu F1 de campo com LLM é 0,163 — um LLM não pode extrair campos de texto que ele não consegue ler.

Qual é o OCR mais rápido para recibos?

O docTR neste benchmark: 108,7 ms p50 por página e 449 páginas/min no SROIE 2019 (summary_metrics.csv doctr/sroie_2019: latency_p50_ms, pages_per_minute). O mais lardo testado, Surya2, foi 24,5× mais lento no p50 (2.668 ms) e 37× mais lento no throughput (12 páginas/min).

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

Cada valor é uma linha dos CSVs publicados do benchmark de primeira mão — results/summary_metrics.csv (8 modelos × 2 conjuntos de dados: CER/WER, F1 de campo, latência, custo, throughput) e results/field_method_comparison.csv (regex vs pós-processamento por LLM) — hospedados em ImageToTableai/benchmark-ocr, com um manifest.json por execução (com dados omitidos) para impressões digitais do ambiente. As definições dos conjuntos de dados vêm dos artigos do SROIE 2019 e CORD citados abaixo.

Metodologia e Fontes

Protocolo

Esta página relata a comparação de parsing de documentos de um benchmark independente e reproduzível (nível oficial) — não uma pesquisa de alegações de terceiros. Apenas divisões de teste fixas: SROIE 2019 test (361 recibos em inglês, campos planos empresa/data/endereço/total) e CORD v2 test (100 recibos indonésios, campos aninhados menu/sub_total/total); divisões de treinamento nunca foram avaliadas. Cada par (modelo × conjunto de dados) reutiliza 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 pontuada, de modo que os valores de latência sejam em regime permanente). Todas as 16 execuções foram concluídas com error_rate 0.0 (coluna error_rate do summary_metrics.csv).

Ambiente de Execução

• Hardware: todas as execuções em GPU em uma NVIDIA RTX 4090 (24 GB); custo da GPU calculado na taxa sob demanda do RunPod de $0.76/hr, com o registro do timestamp do preço no manifesto redatado de cada execução (agosto de 2026). O Tesseract foi executado apenas em CPU e não possui custo de GPU (célula de custo vazia no CSV).
• Motores: todos os modelos executados fora da caixa, sem ajuste fino. Versões bloqueadas conforme 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 no field_method_comparison.csv); foi o único modelo usado para todas as linhas de campos LLM.
• 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 SROIE são variantes postprocessed_sroie_receipt_regex_* / LLM — ou seja, campos extraídos do texto OCR por um conjunto fixo de regex ou pelo LLM. Elas medem OCR + extração downstream, não a saída estruturada nativa dos modelos.

Versões conforme registradas na tabela de modelos do benchmark (README.md) e nos manifestos redatados por execução (results/manifests/, um por execução publicada, 16 no total) — cada manifesto registra o id da execução, versão do modelo, hash do script executor, GPU/driver, versões torch/CUDA/Python, hash do pip-freeze, metadados de custo com timestamp do preço e hashes dos artefatos para reprodutibilidade.

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. Quanto menor, melhor. Sensível a maiúsculas/minúsculas e convenções de formatação.
• 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 campos extraídos usando padrões regex fixos no texto OCR (pipeline de OCR tradicional + KIE baseado em regras). Coluna: regex_field_value_f1.
• 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.
• 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 à taxa registrada de $0,76/hr; vazio para Tesseract apenas com CPU.

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 remetem a uma linha 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 campo regex/LLM remetem a uma linha aqui.
3. Repositório ImageToTableai/benchmark-ocr. Repositório público hospedando os CSVs de resultados, 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 a impressão digital do ambiente, versão do modelo, metadados de custo 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). Esta referência não mede nada sobre tratamento de layout/tabelas/fórmulas, documentos longos ou campos não-recibo — os tipos de documento onde VLMs de análise de documentos reivindicam suas maiores vantagens permanecem não medidos aqui. Não use esta página para concluir que "OCR tradicional é melhor em todos os casos."
• 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 um único dígito de algumas centésimas devem ser tratadas como ruído, não como verdade de engenharia.
• Tier de GPU único: todos os números de GPU são de uma única RTX 4090 a $0,76/hr. Outras GPUs, servimento multi-GPU ou agendamento em lote alterarão latência, throughput e custo.
• Assimetria CPU/GPU: Tesseract (CPU) é comparado a motores acelerados por GPU; sua latência/tempo reflete hardware CPU, enquanto sua vantagem de custo reflete a ausência de cobrança por GPU. Isso é marcado em cada tabela relevante, mas a assimetria é inerente à comparação.
• Pós-processador LLM é um único modelo: todas as linhas de campo LLM usam deepseek-v4-flash. Um LLM diferente produziria F1 absoluto diferente; a ordenação de convergência pode mudar nas margens. A latência do LLM (~1,8–2,4 s mediana, field_method_comparison.csv llm_median_latency_ms) é imposta por API e não faz parte da latência própria do motor OCR.
• Carimbo de data do custo: o preço de GPU de $0,76/hr foi registrado nos manifests de execução em agosto de 2026. Preços spot/sob demanda de GPU mudam; recalcule os custos com as taxas atuais antes de orçar.
• CORD CER não é uma leitura de qualidade: o ground truth do CORD incorpora estrutura de anotação e os motores não foram treinados em indonésio. O CORD CER (0,90–1,08 em todos os 8 modelos) reflete incompatibilidade de idioma + inflação do ground-truth, não a qualidade de leitura por modelo; as linhas do CORD são intencionalmente não mescladas em nenhum ranking do SROIE.
• Ajuste de regex: o conjunto de padrões regex foi escrito uma vez por conjunto de dados. Uma biblioteca de padrões ajustada por fornecedor poderia pontuar mais alto em seus próprios formatos — ao custo de manutenção que o LLM elimina.
• Sem modelos cloud/API: AWS Textract, Google Document AI, Azure AI Document Intelligence e APIs VLM hospedadas (ex.: serviços de OCR em nuvem) não estão incluídos; seus modelos de latência e precificação diferem fundamentalmente dos motores locais medidos aqui.
• Fixação de versão: os resultados valem para as versões de modelo de agosto de 2026 listadas acima; versões mais recentes de qualquer motor podem alterar os resultados, e as latências p50 das duas medições com grandes picos de p95 (PaddleOCR, Docling) refletem efeitos de preenchimento/página inicial sob o padrão de lote desta execução.

Referências relacionadas: Regex vs Extração de Campos por LLM · Precisão por Campo vs por Caractere · Precisão de OCR de Recibos · Precisão de OCR por Tipo de Documento

Leituras relacionadas: Precisão de AI OCR vs OCR Tradicional · Extração de Dados de Imagem por AI vs OCR Tradicional · Preços de Extração de Documentos por AI (2026)