Regex vs LLM Field Extraction for Receipts
First-Party Benchmark Results (2026)

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

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

SROIE (Scanned Receipt OCR and Information Extraction, ICDAR 2019) é o benchmark padrão de recibos em inglês: 361 recibos de teste com quatro campos-alvo — empresa, data, endereço e total (Huang et al., 2019). Cada mecanismo primeiro produziu 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 baseado em regras) e o LLM deepseek-v4-flash com um prompt de extração estruturada. Ambos foram avaliados em relação aos mesmos campos de referência. O gráfico mostra o F1 de campo com regex (azul) vs. F1 de campo com LLM (verde) por mecanismo.

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 mecanismo (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 %). docTR F1 0,0766 → 0,6171; Surya2 0,3183 → 0,6139; PaddleOCR 0,3254 → 0,5810.

Resultados CORD: recibos de Indonesia (100 muestras, prueba de estrés)

CORD amplía la brecha, no porque el LLM mejore — no lo hace — sino porque el regex colapsa: seis de ocho motores obtienen un F1 de campo regex igual o inferior al 10,8%, y dos (docTR 0,0%, EasyOCR 0,7%) recuperan casi nada. El LLM sigue elevando a todos los motores que no son Tesseract al 33,8% o más, demostrando que su extracción se generaliza entre idiomas y diseños donde los patrones escritos a mano no pueden.

CORD v2 es un conjunto de datos de recibos en indonesio con campos anidados (menu, sub_total, total) (Park et al., 2019), ejecutado como una prueba de estrés entre idiomas: ninguno de los 8 motores fue entrenado principalmente con recibos indonesios. Se aplican dos advertencias al leer esta tabla. Primero, el texto de referencia de CORD incluye la estructura de anotación y las diferencias de normalización de salida del VLM, lo que infla sistemáticamente el CER bruto para cada motor — por lo que las métricas de campo a continuación, no el CER, son la comparación justa entre modelos. Segundo, los patrones regex fueron escritos para el esquema plano SROIE en inglés; el esquema anidado de CORD y el formato indonesio (moneda Rp, convenciones de fecha) los derrotan — lo que es en sí mismo el hallazgo: las reglas ajustadas a un mercado no viajan.

Fuente: field_method_comparison.csv — filas para dataset=cord_v2, columnas regex_field_value_f1 / llm_field_value_f1 (decimales 0–1 mostrados como %). 100 muestras por motor (llm_ok_count).

Fuente: field_method_comparison.csv — filas cord_v2 (F1 y precisión de valor de campo regex/llm, decimales 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 achata a diferença — e onde está seu teto

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

(a) O LLM transforma uma diferença de 0,26 ponto entre modelos em uma faixa de 0,05 ponto

Com regex, qual mecanismo você escolheu importava muito: o F1 de campo SROIE variava de 0,077 (docTR) a 0,338 (Unlimited-OCR) — uma diferença de 0,26 ponto. Com o LLM, seis dos sete mecanismos não-Tesseract ficam entre 0,569 (Docling) e 0,617 (docTR) — uma faixa de 0,05 ponto (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 mecanismo. Dois mecanismos ficam fora dessa faixa: EasyOCR em 0,372 (o menor F1 de LLM em recibos em inglês) e Tesseract em 0,439. No CORD, o Tesseract se torna o claro retardatário — seu 0,163 é o pior resultado de LLM em toda a tabela.

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

"Lixo entra, lixo sai" se aplica até ao pós-processamento com LLM. O texto OCR bruto 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 com LLM no CORD é consequentemente 0,1627 (field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1): um LLM não consegue extrair um nome de empresa ou total de um 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: do piso do regex ao topo do 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 com regex no SROIE foi o mais baixo de todos os 8 mecanismos, em 0,0766 — seu texto limpo e preciso (CER SROIE 0,1971, o melhor do benchmark, linha 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 produz o maior resultado SROIE do benchmark, 0,6171 — um aumento de 8,1× e o maior da tabela (field_method_comparison.csv, doctr/sroie_2019, regex_field_value_f1 0,0766 → llm_field_value_f1 0,6171). No CORD o efeito se repete: 0,0 com regex, 0,5500 com o LLM.

Quando Regex é Suficiente vs Quando Usar um LLM

A troca honesta não é "regex está quebrado", mas "regex é frágil onde recibos são variáveis." O pós-processamento com regex é determinístico, gratuito e instantâneo; um pós-processador com LLM adiciona tokens e 1,8–2,4 s de 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 caiu para quase zero na maioria dos mecanismos, 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: não custa nada, roda em microssegundos, e suas falhas são previsíveis. Os casos mínimos do benchmark mostram isso: mecanismos com regex alinhado a recibos ainda alcançaram 0,34 de F1 de campo no SROIE (Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368).

Quando usar um LLM: assim que a variação de formato entra — múltiplas moedas, formatos de data regionais, endereços de várias linhas, 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 que "mais um idioma" custa a um pipeline baseado em regras: o F1 de campo com regex caiu de 0,08–0,34 (SROIE em inglês) para 0,00–0,34 (CORD em indonésio), enquanto o LLM manteve 0,16–0,55 — uma penalidade que a abordagem com regex pagou 100% e o LLM pagou apenas parcialmente. A arquitetura certa para a maioria dos fluxos de produção é híbrida: extração com LLM para campos variáveis, validação com regex ou baseada em regras para campos com formatos estritos esperados, com o custo de 1,8–2,4 s por documento do LLM amortizado em processamento assíncrono em lote, em vez de esperas síncronas do usuário.

Perguntas Frequentes

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

Sim, neste benchmark, em todas as linhas: o pós-processamento com LLM (deepseek-v4-flash) superou o pós-processamento com regex para todos os 8 mecanismos 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 de campos com LLM foi 0,37–0,62 contra 0,08–0,34 com regex; em recibos em indonésio do CORD, 0,16–0,55 contra 0,00–0,34.

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

docTR no SROIE, com F1 de campos de 0,6171 — mas as diferenças entre os mecanismos desaparecem em grande parte quando um LLM entra no processo: seis dos sete mecanismos não-Tesseract ficam entre 0,569 e 0,617 (field_method_comparison.csv, linhas sroie_2019, llm_field_value_f1). No CORD, PaddleOCR lidera com 0,5527, com docTR em segundo lugar próximo com 0,5500.

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

Porque o texto do seu OCR é degradado demais para que qualquer pós-processador recupere campos. Em recibos em indonésio, sua taxa de erro de caracteres é 0,9523 (summary_metrics.csv, tesseract/cord_v2), o que limita seu F1 de campos com LLM a 0,1627 — o pior resultado com 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 mecanismo, com o maior ganho no docTR (0,077 → 0,617 de F1 de campos, linhas sroie_2019 do field_method_comparison.csv). Em recibos em indonésio, o ganho é muito maior — 36× para PaddleOCR e praticamente ilimitado para docTR (0,0 → 0,55), pois o regex recuperou quase nada.

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

Não — e os leitores não devem esperar que acerte. O melhor F1 de campos com LLM no benchmark é 0,617 (docTR, SROIE), o que significa que cerca de 38% dos campos ainda foram perdidos ou 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 com LLM é uma grande melhoria em relação ao regex, não uma solução mágica; a pontuação de confiança em nível de campo e a revisão humana continuam sendo necessárias para produção.

Quão lento ou caro é o pós-processamento com LLM?

Neste benchmark, a chamada de 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 dos 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). Isso não é uma latência de extração de campos em tempo real — é adequado para processamento assíncrono em lote, não para consultas interativas.

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

Melhor que regex, mas com um teto menor. Em recibos CORD indonésios, o LLM manteve o F1 de campos em 0,16–0,55, enquanto o regex caiu para 0,00–0,34 (field_method_comparison.csv, linhas cord_v2) — mas o melhor resultado CORD (0,5527) ainda fica atrás do melhor resultado em inglês (0,6171), refletindo tanto o script mais difícil quanto a base de OCR degradada. Regras escritas para recibos em inglês praticamente pararam de funcionar; o LLM degradou de forma graciosa em vez disso.

Metodologia & Fontes

Protocolo

Esta página informa a comparação de extração de campos do benchmark de OCR de código aberto ImageToTable.ai — uma execução experimental independente e reproduzible (nivel oficial), não uma pesquisa de afirmações de terceiros. O pipeline para cada par (modelo × conjunto de dados): o motor de 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 pelo pós-processador LLM — e ambas saídas são avaliadas contra os mesmos campos de referência. O pós-processador LLM é deepseek-v4-flash (a columna llm_model no CSV de comparação), executado a temperatura 0 para saída determinística. Todas as 361 muestras SROIE e 100 CORD foram concluidas com éxito (llm_ok_count = 361 / 100).

Ambiente de Execução

• Hardware: todas as execuções de GPU 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 somente 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 de driver e Python variam ligeiramente por execução e são registradas exatamente nos manifiestos de execução editados (consulte Acceso a Artefactos abaixo).
• Pós-processador LLM: deepseek-v4-flash via API, temperatura 0.
• Modo de medição: warm_then_scored — uma passada de aquecimento fixa precede a passada avaliada, de modo que as figuras de latência estão em estado estacionário.
• Conjuntos de dados: SROIE 2019 test — 361 recibos em inglês, campos planos (empresa, data, endereço, total), CC-BY-4.0; CORD v2 test — 100 recibos indonesios, campos anidados (menu, sub_total, total), CC-BY-4.0.
• Contagem de muestras: SROIE 361 / CORD 100, todas das divisões de teste fixas (sem vazamento de dados de treinamento).

O texto de OCR upstream consumido por ambos pós-processadores proviene destas versões de motor:

As huellas digitais completas de reprodução por execução estão nos manifiestos de execução editados do benchmark sob results/manifests/ no repositório público (um manifest.json por execução publicada, 16 no total). Cada um divulga: id de execução, modelo + versão, hash do script de execução (SHA-256), modelo/driver/VRAM de GPU, versões de torch/CUDA/torchvision/torchaudio, versão de Python, hash de pip-freeze, metadatos de custo (GPU $/hora e timestamp de preço), modo de medição e hashes de artefactos (lista de muestras, predicciones, métricas, desempeño).

Definición de Métricas

• F1 de valor de campo (enfoque regex): media armónica de precisión y recall sobre los valores de campo extraídos, usando postprocesamiento con regex — el enfoque tradicional de OCR + KIE basado en reglas. Columna: regex_field_value_f1.
• F1 de valor de campo (enfoque LLM): la misma métrica calculada sobre la salida del postprocesador LLM — el enfoque de OCR + postprocesamiento con LLM. Columna: llm_field_value_f1. Estos dos enfoques son pipelines diferentes y nunca se combinan.
• Precisión de valor de campo: fracción de valores de campo extraídos que coinciden exactamente con la verdad de campo (regex_field_value_accuracy / llm_field_value_accuracy).
• Documento-campos-exacto: fracción de documentos donde cada campo objetivo coincidió exactamente (regex_document_fields_exact / llm_document_fields_exact).
• CER/WER (solo contexto): tasa de error de caracteres/palabras del texto OCR sin procesar, utilizada en esta página solo para explicar el límite del LLM de Tesseract.

Acceso a Artefactos

1. field_method_comparison.csv (GitHub raw). 16 filas = 8 modelos × 2 conjuntos de datos; columnas: modelo, conjunto de datos, modelo_llm (= deepseek-v4-flash), F1 de campo regex/llm + precisión, documento-campos-exacto, llm_median_latency_ms, llm_prompt_tokens, llm_completion_tokens. Cada número de F1 de campo y precisión en esta página se rastrea hasta una fila aquí.
2. summary_metrics.csv (GitHub raw). CER/WER por modelo × conjunto de datos, utilizado para la explicación del límite de Tesseract (tesseract/cord_v2 cer 0.9523) y el CER de SROIE de docTR 0.1971.
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que aloja los CSV de resultados, manifiestos de ejecución y listas de muestras de conjuntos de datos para reproducción.
4. results/manifests/ (GitHub). Un manifest.json redactado por ejecución publicada (16 ejecuciones), con la huella de entorno por ejecución y los hashes de artefactos enumerados anteriormente.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definición y licencia del conjunto de datos SROIE.
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2019). Definición y licencia del conjunto de datos 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 recibos em indonésio. O F1 por campo é sensível à composição do corpus; trate diferenças de alguns centésimos como ruído.
• Modelo LLM único: Todas as linhas de LLM usam deepseek-v4-flash. Um LLM diferente (tamanho, prompt ou fornecedor) produziria números absolutos diferentes; a ordem regex-vs-LLM pode mudar nas margens.
• Ressalva sobre o ground-truth do CORD: O gt_text do CORD inclui estrutura de anotação e diferenças de normalização do VLM, então o CER bruto no CORD é sistematicamente inflado para todos os mecanismos (por exemplo, CER 1.08 do PaddleOCR-VL é um artefato, não uma leitura real da qualidade do texto). As métricas por campo são a comparação justa; o CER é usado aqui apenas para a explicação do Tesseract.
• Latência não é 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 consulta por campo, e não inclui o tempo do OCR em si.
• Ajuste de regex: Os padrões de regex são um conjunto fixo escrito uma vez por conjunto de dados (esquema plano SROIE); uma biblioteca de regex por fornecedor fortemente ajustada poderia pontuar mais alto em seus próprios formatos — ao custo da carga de manutenção que o LLM elimina.

Referências relacionadas: a diferença entre precisão por campo e por caractere · Precisão de OCR de recibos · benchmarks de precisão por tipo de documento

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