Regex vs LLM para Extração de Campos em Notas Fiscais
Resultados do Benchmark Primeira Parte (2026)

Resultados SROIE: Recibos em Inglês (361 Amostras)

Em recibos em inglês, o LLM supera o regex em todos os 8 motores — o menor ganho é de 1,76× (PaddleOCR-VL 0,337 → 0,592), o maior de 8,1×. E o LLM quase elimina a lacuna entre os modelos: 6 dos 7 motores não-Tesseract ficam dentro de uma faixa de 0,05 pontos (0,569–0,617), onde seus resultados de regex estavam espalhados por 0,26 pontos (0,077–0,338).

SROIE (Scanned Receipt OCR and Information Extraction, ICDAR 2019) é o benchmark padrão para recibos em inglês: 361 recibos de teste com quatro campos-alvo — empresa, data, endereço e total (Huang et al., 2019). Cada motor primeiro gerou texto OCR em uma configuração compartilhada de RTX 4090; esse texto foi então alimentado a dois pós-processadores paralelos: um conjunto fixo de padrões regex (a abordagem tradicional de OCR + KIE baseada em regras) e o LLM deepseek-v4-flash com um prompt de extração estruturada. Ambos foram avaliados contra os mesmos campos de verdade fundamental. O gráfico mostra o F1 por campo do regex (azul) vs. o F1 por campo do LLM (verde) para cada motor.

Fonte: field_method_comparison.csv — linhas para dataset=sroie_2019, colunas regex_field_value_f1 / llm_field_value_f1 (armazenadas como decimais 0–1, exibidas como %). Pós-processador LLM: deepseek-v4-flash (coluna llm_model). 361 amostras por motor (llm_ok_count).

Fonte: field_method_comparison.csv — linhas sroie_2019: regex_field_value_f1 / llm_field_value_f1 / regex_field_value_accuracy / llm_field_value_accuracy (decimais 0–1 exibidos como %). F1 docTR 0,0766 → 0,6171; Surya2 0,3183 → 0,6139; PaddleOCR 0,3254 → 0,5810.

Resultados CORD: Receitas Indonésias (100 Amostras, Teste de Estresse)

O CORD amplia a lacuna, não porque o LLM melhora — ele não melhora — mas porque o regex colapsa: seis dos oito motores pontuam o F1 de campos regex em ou abaixo de 10,8%, e dois (docTR 0,0%, EasyOCR 0,7%) recuperam quase nada. O LLM ainda eleva todos os motores não-Tesseract para 33,8% ou mais, provando que sua extração se generaliza em idiomas e layouts onde padrões manuais não conseguem.

O CORD v2 é um conjunto de dados de receitas em idioma indonésio com campos aninhados (menu, sub_total, total) (Park et al., 2019), executado como um teste de estresse entre idiomas: nenhum dos 8 motores foi treinado principalmente em receitas indonésias. Duas ressalvas se aplicam à leitura desta tabela. Primeiro, o texto de referência do CORD inclui diferenças na estrutura de anotação e na normalização de saída do VLM, que inflam sistematicamente o CER bruto para cada motor — portanto, as métricas de campo abaixo, não o CER, são a comparação justa entre modelos. Segundo, os padrões regex foram escritos para o esquema SROIE em inglês e plano; o esquema aninhado do CORD e a formatação indonésia (moeda Rp, convenções de data) os derrotam — o que é em si a descoberta: regras ajustadas para um mercado não funcionam em outro.

Fonte: field_method_comparison.csv — linhas para dataset=cord_v2, colunas regex_field_value_f1 / llm_field_value_f1 (decimais 0–1 mostrados como %). 100 amostras por motor (llm_ok_count).

Fonte: field_method_comparison.csv — linhas cord_v2 (F1 e acurácia de campos regex/llm, decimais 0–1 mostrados como %). PaddleOCR LLM F1 0,0154 → 0,5527; docTR 0,0 → 0,5500; tesseract 0,0752 → 0,1627.

Por que o LLM Reduz a Lacuna — e Onde Está seu Teto

Três padrões nos números explicam o que está acontecendo sob a superfície. Cada um é uma afirmação testável com suas células CSV exatas abaixo.

(a) O LLM transforma uma lacuna de modelo de 0,26 pontos em uma faixa de 0,05 pontos

Com regex, qual motor você escolhia importava enormemente: o F1 do campo SROIE variava de 0,077 (docTR) a 0,338 (Unlimited-OCR) — uma variação de 0,26 pontos. Com o LLM, seis dos sete motores não-Tesseract ficam entre 0,569 (Docling) e 0,617 (docTR) — uma faixa de 0,05 pontos (field_method_comparison.csv, linhas sroie_2019, regex_field_value_f1 vs llm_field_value_f1). O OCR upstream só precisa produzir texto legível; o LLM extrai campos dele com qualidade aproximadamente independente do motor. Dois motores ficam abaixo dessa faixa: EasyOCR com 0,372 (o menor F1 de LLM em recibos em inglês) e Tesseract com 0,439. No CORD, o Tesseract se torna o atrasado claro — seu 0,163 é o pior resultado de LLM em toda a tabela.

(b) O teto do Tesseract é definido por seu OCR, não por seu pós-processador

"Lixo entra, lixo sai" se aplica até ao pós-processamento por LLM. O texto bruto do OCR do Tesseract em recibos indonésios tem uma taxa de erro de caracteres de 0,9523 (summary_metrics.csv, tesseract/cord_v2, cer) — aproximadamente 95 caracteres em 100 estão errados ou fora de ordem. Seu F1 de campo LLM no CORD é consequentemente 0,1627 (field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1): um LLM não pode extrair um nome de empresa ou total de texto que não consegue ler. O teto de qualquer pós-processador é definido pela qualidade base do OCR abaixo dele — uma restrição que nenhuma engenharia de prompt remove.

(c) docTR é o maior beneficiário: de piso regex a topo LLM

A história do docTR é a demonstração mais clara de que o problema era o pós-processador, não o OCR. Seu F1 de campo regex no SROIE foi o mais baixo dos 8 motores em 0,0766 — seu texto limpo e preciso (CER do SROIE 0,1971, o melhor do benchmark, linha do summary_metrics.csv para doctr/sroie_2019) simplesmente não correspondia aos padrões regex para totais com separadores de milhar ou endereços multilinha. Com o LLM, o mesmo texto rende o maior resultado do SROIE do benchmark, 0,6171 — um Quando Regex É Suficiente vs Quando Usar um LLM

O tradeoff honesto não é "regex está quebrado" mas "regex é frágil onde os recibos são variáveis." O pós-processamento com regex é determinístico, gratuito e instantâneo; um pós-processador LLM adiciona tokens e 1,8–2,4 s de latência mediana por documento (field_method_comparison.csv, llm_median_latency_ms em todas as 16 linhas). Em troca, o LLM recuperou 1,76–8,1× mais campos no SROIE — e no CORD, onde o regex colapsou para quase zero na maioria dos motores, o LLM recuperou 33,8–55,3% dos campos que a extração baseada em regras simplesmente não conseguia alcançar.

Quando regex é suficiente: se seus documentos vêm de um conjunto pequeno e estável de layouts e os campos que você precisa aparecem em formatos quase constantes — um padrão fixo de número de fatura, uma única convenção de data, uma moeda — regex é a ferramenta certa: custa nada, roda em microssegundos e suas falhas são previsíveis. Os casos de base do benchmark mostram isso: motores com regex alinhado a recibos ainda atingiram 0,34 de F1 de campos no SROIE (Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368).

Quando usar um LLM: assim que a variância de formato entra — múltiplas moedas, formatos de data regionais, endereços multilinha, nomes de fornecedores em estilos variados ou um segundo idioma. Cada um desses quebra um padrão; o LLM absorve todos em um único prompt. Os resultados do CORD no benchmark quantificam o custo de "mais um idioma" para um pipeline baseado em regras: o F1 de campos do regex caiu de 0,08–0,34 (inglês SROIE) para 0,00–0,34 (indonésio CORD), enquanto o LLM manteve 0,16–0,55 — uma penalidade que a abordagem regex pagou 100% e o LLM pagou apenas parcialmente. A arquitetura correta para a maioria dos fluxos de produção é híbrida: extração por LLM para campos variáveis, validação por regex ou baseada em regras para campos com formatos esperados estritos, com o custo por documento do LLM de 1,8–2,4 s amortizado em processamento assíncrono em lote em vez de esperas síncronas do usuário.

Perguntas Frequentes

A extração de campos por LLM é mais precisa que a extração por regex?

Sim, neste benchmark, em cada linha: o pós-processamento por LLM (deepseek-v4-flash) superou o pós-processamento por regex para todos os 8 motores de OCR em ambos os conjuntos de dados (field_method_comparison.csv, todas as 16 linhas). Em recibos em inglês do SROIE, o F1 dos campos por LLM foi de 0,37–0,62 contra 0,08–0,34 por regex; em recibos em indonésio do CORD, 0,16–0,55 contra 0,00–0,34.

Qual modelo de OCR extrai os campos de recibos melhor com pós-processamento por LLM?

docTR no SROIE, com F1 de campos de 0,6171 — mas as diferenças entre os motores praticamente desaparecem quando um LLM está no loop: seis dos sete motores não-Tesseract ficam entre 0,569 e 0,617 (field_method_comparison.csv, linhas sroie_2019, llm_field_value_f1). No CORD, o PaddleOCR lidera com 0,5527, seguido de perto pelo docTR com 0,5500.

Por que o Tesseract fica para trás mesmo com um LLM?

Porque seu texto de OCR é muito degradado para qualquer pós-processador recuperar os campos. Em recibos indonésios, sua taxa de erro de caracteres é de 0,9523 (summary_metrics.csv, tesseract/cord_v2), o que limita seu F1 de campos por LLM a 0,1627 — o pior resultado por LLM no benchmark (field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1).

Quanto um LLM melhora a extração de campos em relação ao regex?

Entre 1,76× e 8,1× em recibos em inglês, dependendo do motor, com o maior ganho no docTR (0,077 → 0,617 F1 de campos, field_method_comparison.csv linhas sroie_2019). Em recibos indonésios, o ganho é muito maior — 36× para o PaddleOCR e praticamente ilimitado para o docTR (0,0 → 0,55), pois o regex quase não recuperou nada.

O pós-processamento por LLM acerta todos os campos?

Não — e os leitores não devem esperar isso. O melhor F1 de campo do LLM no benchmark é 0.617 (docTR, SROIE), o que significa que cerca de 38% dos campos ainda foram perdidos ou estavam errados, e a melhor taxa de correspondência exata de documento inteiro é 15,5% (Surya2, SROIE, llm_document_fields_exact) — ou seja, no máximo ~1 em cada 6 documentos teve todos os quatro campos exatamente corretos. A extração por LLM é uma grande melhoria em relação a regex, não uma bala de prata; a pontuação de confiança por campo e a revisão humana continuam necessárias para produção.

Quão lento ou custoso é o pós-processamento por LLM?

Neste benchmark, a chamada ao LLM adicionou 1,8–2,4 s de latência mediana por documento (field_method_comparison.csv, llm_median_latency_ms, todas as 16 linhas), e a execução completa de 16 grupos consumiu aproximadamente 1,33M de tokens de prompt + 0,28M de tokens de conclusão (soma de llm_prompt_tokens / llm_completion_tokens). Esta não é uma latência de extração de campo em tempo real — é adequada para processamento assíncrono em lote, não para consultas interativas.

O pós-processamento por LLM funciona em recibos não ingleses?

Melhor que regex, mas com um teto menor. Em recibos indonesianos do CORD, o LLM manteve o F1 de campo entre 0,16–0,55, enquanto o regex caiu para 0,00–0,34 (field_method_comparison.csv, linhas cord_v2) — mas o melhor resultado do CORD (0,5527) ainda fica atrás do melhor resultado em inglês (0,6171), refletindo tanto a escrita mais difícil quanto a degradação da base de OCR. Regras escritas para recibos em inglês basicamente pararam de funcionar; o LLM degradou-se de forma mais graciosa.

Metodologia & Fontes

Protocolo

Esta página relata a comparação de extração de campos do benchmark OCR de código aberto do ImageToTable.ai — uma execução experimental independente e reproduzível (nível oficial), não uma pesquisa de alegações de terceiros. O pipeline para cada par (modelo × conjunto de dados): o motor OCR produz texto a partir de imagens de recibos; esse texto é então extraído duas vezes — uma vez por um conjunto fixo de padrões regex e outra vez pelo pós-processador LLM — e ambas as saídas são pontuadas em relação aos mesmos campos de verdade fundamental. O pós-processador LLM é deepseek-v4-flash (a coluna llm_model no CSV de comparação), executado com temperatura 0 para saída determinística. Todas as 361 amostras SROIE e 100 CORD foram concluídas com sucesso (llm_ok_count = 361 / 100).

Ambiente de Execução

• Hardware: todas as execuções em GPU foram em NVIDIA RTX 4090 (24 GB). Os motores baseados em PyTorch (docTR, EasyOCR, Docling) foram executados com PyTorch 2.8.0+cu128 (CUDA 12.8); Tesseract foi executado apenas em CPU (sem custo de GPU); os motores servidos por vLLM (Surya2, Unlimited-OCR, PaddleOCR-VL) foram executados em um pod vLLM. As versões do driver e do Python variam ligeiramente por execução e são registradas exatamente nos manifests de execução redatados (veja Acesso aos Artefatos abaixo).
• Pós-processador LLM: deepseek-v4-flash via API, temperatura 0.
• Modo de medição: warm_then_scored — uma passagem de aquecimento fixa precede a passagem pontuada, de modo que os valores de latência são em regime permanente.
• Conjuntos de dados: SROIE 2019 teste — 361 recibos em inglês, campos planos (empresa, data, endereço, total), CC-BY-4.0; CORD v2 teste — 100 recibos indonésios, campos aninhados (menu, sub_total, total), CC-BY-4.0.
• Contagens de amostras: SROIE 361 / CORD 100, todas dos splits de teste fixos (sem vazamento de dados de treinamento).

O texto OCR upstream consumido por ambos os pós-processadores veio dessas versões de motores:

As impressões digitais de reprodutibilidade completas por execução estão nos manifests de execução redatados do benchmark em results/manifests/ no repositório público (um manifest.json por execução publicada, 16 no total). Cada um divulga: id da execução, modelo + versão, hash do script executor (SHA-256), modelo/driver/VRAM da GPU, versões torch/CUDA/torchvision/torchaudio, versão do Python, hash do pip-freeze, metadados de custo (GPU $/hora e carimbo de data/hora do preço), modo de medição e hashes dos artefatos (lista de amostras, previsões, métricas, desempenho).

Definições das Métricas

• Field-value F1 (abordagem regex): média harmônica de precisão e recall sobre os valores de campo extraídos, usando pós-processamento regex — a abordagem tradicional de OCR + KIE baseada em regras. Coluna: regex_field_value_f1.
• Field-value F1 (abordagem LLM): a mesma métrica calculada na saída do pós-processador LLM — a abordagem de OCR + pós-processamento LLM. Coluna: llm_field_value_f1. Estas duas abordagens são pipelines diferentes e nunca são combinadas.
• Precisão do valor do campo: fração dos valores de campo extraídos que correspondem exatamente ao gabarito (regex_field_value_accuracy / llm_field_value_accuracy).
• Document-fields-exact: fração de documentos onde cada campo alvo correspondeu exatamente (regex_document_fields_exact / llm_document_fields_exact).
• CER/WER (apenas contexto): taxa de erro por caractere/palavra do texto OCR bruto, usada nesta página apenas para explicar o teto de performance do Tesseract com LLM.

Acesso aos Artefatos

1. field_method_comparison.csv (GitHub raw). 16 linhas = 8 modelos × 2 conjuntos de dados; colunas model, dataset, llm_model (= deepseek-v4-flash), regex/llm field F1 + accuracy, document-fields-exact, llm_median_latency_ms, llm_prompt_tokens, llm_completion_tokens. Cada número de field-F1 e accuracy nesta página rastreia até uma linha aqui.
2. summary_metrics.csv (GitHub raw). CER/WER por modelo × conjunto de dados, usado para a explicação do teto do Tesseract (tesseract/cord_v2 cer 0.9523) e o CER 0.1971 do docTR no SROIE.
3. Repositório ImageToTableai/benchmark-ocr. Repositório público hospedando os CSVs de resultados, manifests de execução e listas de amostras de conjuntos de dados para reprodução.
4. results/manifests/ (GitHub). Um manifest.json editado por execução publicada (16 execuções), com a impressão digital do ambiente por execução e os hashes dos artefatos listados acima.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definição e licença do conjunto de dados SROIE.
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2019). Definição e licença do conjunto de dados CORD v2.

Limitações

• Escopo do documento: Apenas recibos (SROIE + CORD). Os resultados não se generalizam para faturas, formulários ou documentos longos sem testes adicionais.
• Tamanho da amostra: 361 recibos em inglês + 100 em indonésio. O F1 do campo é sensível à composição do corpus; trate diferenças de poucas centésimos em um único ponto como ruído.
• Modelo LLM único: Todas as linhas LLM usam deepseek-v4-flash. Um LLM diferente (tamanho, prompt ou fornecedor) produziria números absolutos diferentes; a ordenação regex-vs-LLM pode mudar nas margens.
• Ressalva sobre o ground-truth do CORD: O gt_text do CORD inclui diferenças na estrutura de anotação e na normalização do VLM, então o CER bruto no CORD é sistematicamente inflado para todos os motores (por exemplo, o CER 1.08 do PaddleOCR-VL é um artefato, não uma leitura real de sua qualidade de texto). As métricas por campo são a comparação justa; o CER é usado aqui apenas para a explicação do Tesseract.
• A latência não é a latência de extração em tempo real: llm_median_latency_ms (1,8–2,4 s) cobre toda a chamada de extração de campos OCR-texto → LLM, não a busca por campo, e não inclui o próprio tempo de OCR.
• Ajuste de regex: Os padrões de regex são um conjunto fixo escrito uma vez por conjunto de dados (esquema SROIE-flat); uma biblioteca de regex ajustada por fornecedor poderia pontuar mais alto em seus próprios formatos — ao custo da carga de manutenção que o LLM elimina.

Referências relacionadas: Precisão por Campo vs. Precisão por Caractere · Precisão do OCR de Recibos · Precisão do OCR por Tipo de Documento

Leitura relacionada: Como Ler Afirmações de Precisão de OCR