Regex vs LLM Field Extraction for Receipts
Resultados de Benchmark de Primera Parte (2026)

Resultados de SROIE: recibos en inglés (361 muestras)

En recibos en inglés, el LLM supera a regex en los 8 motores: la mejora más pequeña es de 1,76× (PaddleOCR-VL 0,337 → 0,592), la más grande de 8,1×. Y el LLM casi elimina la brecha entre modelos: 6 de los 7 motores que no son Tesseract se sitúan dentro de una banda de 0,05 puntos (0,569–0,617), mientras que sus resultados con regex se distribuían en 0,26 puntos (0,077–0,338).

SROIE (Scanned Receipt OCR and Information Extraction, ICDAR 2019) es el estándar de referencia para recibos en inglés: 361 recibos de prueba con cuatro campos objetivo — empresa, fecha, dirección y total (Huang et al., 2019). Cada motor produjo primero texto OCR en una configuración compartida de RTX 4090; ese texto se alimentó luego a dos posprocesadores en paralelo: un conjunto fijo de patrones regex (el enfoque tradicional de OCR + KIE basado en reglas) y el LLM deepseek-v4-flash con un prompt de extracción estructurada. Ambos se evaluaron contra los mismos campos de referencia. El gráfico muestra el F1 de regex por campo (azul) frente al F1 del LLM por campo (verde) por motor.

Fuente: field_method_comparison.csv — filas para dataset=sroie_2019, columnas regex_field_value_f1 / llm_field_value_f1 (almacenadas como decimales 0–1, mostradas como %). Posprocesador LLM: deepseek-v4-flash (columna llm_model). 361 muestras por motor (llm_ok_count).

Fuente: field_method_comparison.csv — filas de sroie_2019: regex_field_value_f1 / llm_field_value_f1 / regex_field_value_accuracy / llm_field_value_accuracy (decimales 0–1 mostrados como %). F1 de docTR 0,0766 → 0,6171; Surya2 0,3183 → 0,6139; PaddleOCR 0,3254 → 0,5810.

Resultados de 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 con regex de 10.8% o menos, y dos (docTR 0.0%, EasyOCR 0.7%) apenas recuperan algo. El LLM sigue elevando a todos los motores excepto Tesseract a 33.8% o más, lo que demuestra 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 de Indonesia. Dos advertencias aplican al leer esta tabla. Primero, el texto de referencia de CORD incluye estructura de anotación y diferencias en la normalización de salida del VLM, lo que infla sistemáticamente el CER bruto de todos los motores —por lo que las métricas de campo a continuación, no el CER, son la comparación justa entre modelos. Segundo, los patrones de regex fueron escritos para el esquema plano de SROIE en inglés; el esquema anidado de CORD y el formato de Indonesia (moneda Rp, convenciones de fecha) los derrotan —lo cual 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 del 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 qué el LLM reduce la brecha y dónde está su límite

Tres patrones en los números explican lo que ocurre bajo la superficie. Cada uno es una afirmación comprobable con sus celdas CSV exactas a continuación.

(a) El LLM convierte una brecha de modelo de 0,26 puntos en una banda de 0,05 puntos

Con regex, el motor que elegiste importaba enormemente: el F1 del campo SROIE abarcaba de 0,077 (docTR) a 0,338 (Unlimited-OCR) — una diferencia de 0,26 puntos. Con el LLM, seis de los siete motores que no son Tesseract se sitúan entre 0,569 (Docling) y 0,617 (docTR) — una banda de 0,05 puntos (field_method_comparison.csv, filas sroie_2019, regex_field_value_f1 vs llm_field_value_f1). El OCR inicial solo necesita producir texto legible; el LLM extrae campos de él con una calidad aproximadamente independiente del motor. Dos motores quedan fuera de esta banda: EasyOCR con 0,372 (el F1 de LLM más bajo en recibos en inglés) y Tesseract con 0,439. En CORD, Tesseract se convierte en el claro rezagado: su 0,163 es el peor resultado de LLM en toda la tabla.

(b) El límite de Tesseract lo fija su OCR, no su postprocesador

"Basura entra, basura sale" se aplica incluso al postprocesamiento con LLM. El texto OCR bruto de Tesseract en recibos indonesios tiene una tasa de error de caracteres de 0,9523 (summary_metrics.csv, tesseract/cord_v2, cer) — aproximadamente 95 de cada 100 caracteres son incorrectos o están desordenados. Su F1 de campo LLM en CORD es, en consecuencia, 0,1627 (field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1): un LLM no puede extraer un nombre de empresa o un total de un texto que no puede leer. El límite de cualquier postprocesador lo fija la calidad base del OCR subyacente — una restricción que ningún ajuste de indicaciones elimina.

(c) docTR es el mayor beneficiario: del mínimo con regex al máximo con LLM

La historia de docTR es la demostración más clara de que el problema era el postprocesador, no el OCR. Su F1 de campo regex en SROIE fue el más bajo de los 8 motores, con 0,0766 — su texto limpio y preciso (CER SROIE de 0,1971, el mejor del benchmark, fila summary_metrics.csv para doctr/sroie_2019) simplemente no coincidía con los patrones regex para totales con separadores de miles o direcciones de varias líneas. Con el LLM, el mismo texto produce el resultado SROIE más alto del benchmark, 0,6171 — un aumento de 8,1× y el mayor de la tabla (field_method_comparison.csv, doctr/sroie_2019, regex_field_value_f1 0,0766 → llm_field_value_f1 0,6171). En CORD el efecto se repite: 0,0 con regex, 0,5500 con el LLM.

Cuándo el regex es suficiente frente a cuándo usar un LLM

La disyuntiva honesta no es que "el regex esté roto", sino que "el regex es frágil cuando los recibos son variables". El postprocesamiento con regex es determinista, gratuito e instantáneo; un postprocesador con LLM añade tokens y 1,8–2,4 s de mediana por documento (field_method_comparison.csv, llm_median_latency_ms en las 16 filas). A cambio, el LLM recuperó 1,76–8,1× más campos en SROIE — y en CORD, donde el regex cayó a casi cero para la mayoría de los motores, el LLM recuperó el 33,8–55,3% de los campos que la extracción basada en reglas simplemente no podía alcanzar.

Cuándo el regex es suficiente: si sus documentos provienen de un conjunto pequeño y estable de diseños y los campos que necesita aparecen en formatos casi constantes — un patrón fijo de número de factura, una única convención de fecha, una sola moneda — el regex es la herramienta adecuada: no cuesta nada, se ejecuta en microsegundos y sus fallos son predecibles. Los casos límite del benchmark lo demuestran: los motores con regex alineado a recibos aún alcanzaron 0,34 de F1 en campos en SROIE (Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368).

Cuándo usar un LLM: en cuanto aparece la variabilidad de formatos — múltiples monedas, formatos de fecha regionales, direcciones de varias líneas, nombres de proveedores en estilos variados o un segundo idioma. Cada uno de esos casos rompe un patrón; el LLM los absorbe todos en una sola instrucción. Los resultados de CORD del benchmark cuantifican lo que "un idioma más" le cuesta a un pipeline basado en reglas: el F1 de campos con regex cayó de 0,08–0,34 (SROIE en inglés) a 0,00–0,34 (CORD en indonesio), mientras que el LLM se mantuvo en 0,16–0,55 — una penalización que el enfoque con regex pagó al 100% y el LLM solo pagó parcialmente. La arquitectura adecuada para la mayoría de los flujos de producción es híbrida: extracción con LLM para campos variables, validación con regex o reglas para campos con formatos estrictos esperados, con el costo de 1,8–2,4 s por documento del LLM amortizado en procesamiento por lotes asíncrono en lugar de esperas síncronas del usuario.

Preguntas Frecuentes

¿La extracción de campos con LLM es más precisa que la extracción con regex?

Sí, en este benchmark, en todas las filas: el postprocesamiento con LLM (deepseek-v4-flash) superó al postprocesamiento con regex para los 8 motores OCR en ambos conjuntos de datos (field_method_comparison.csv, las 16 filas). En los recibos en inglés de SROIE, el F1 de campos con LLM fue 0.37–0.62 frente a 0.08–0.34 con regex; en los recibos en indonesio de CORD, 0.16–0.55 frente a 0.00–0.34.

¿Qué modelo OCR extrae mejor los campos de los recibos con postprocesamiento con LLM?

docTR en SROIE, con un F1 de campos de 0.6171 — pero las diferencias entre motores desaparecen en su mayoría una vez que un LLM está en el circuito: seis de los siete motores que no son Tesseract se sitúan entre 0.569 y 0.617 (field_method_comparison.csv, filas sroie_2019, llm_field_value_f1). En CORD, PaddleOCR lidera con 0.5527, con docTR muy cerca en segundo lugar con 0.5500.

¿Por qué Tesseract se queda atrás incluso con un LLM?

Porque su texto OCR está demasiado degradado para que cualquier postprocesador pueda recuperar campos de él. En los recibos en indonesio, su tasa de error de caracteres es 0.9523 (summary_metrics.csv, tesseract/cord_v2), lo que limita su F1 de campos con LLM a 0.1627 — el peor resultado con LLM en el benchmark (field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1).

¿Cuánto mejora un LLM la extracción de campos en comparación con regex?

Entre 1.76× y 8.1× en recibos en inglés, dependiendo del motor, con la mayor mejora en docTR (0.077 → 0.617 de F1 de campos, filas sroie_2019 de field_method_comparison.csv). En los recibos en indonesio, la mejora es mucho mayor — 36× para PaddleOCR y prácticamente ilimitada para docTR (0.0 → 0.55) porque regex recuperó casi nada.

¿El postprocesamiento con LLM acierta en todos los campos?

No — y los lectores no deberían esperarlo. El mejor F1 de campos con LLM en el benchmark es 0.617 (docTR, SROIE), lo que significa que aproximadamente 38% de los campos aún se omitieron o fueron incorrectos, y la mejor tasa de coincidencia exacta de documentos completos es 15.5% (Surya2, SROIE, llm_document_fields_exact) — es decir, como máximo ~1 de cada 6 documentos tenía los cuatro campos exactamente correctos. La extracción con LLM es una gran mejora sobre regex, no una solución mágica; la puntuación de confianza a nivel de campo y la revisión humana siguen siendo necesarias para producción.

¿Qué tan lento o costoso es el postprocesamiento con LLM?

En este benchmark, la llamada al LLM añadió una latencia mediana de 1.8–2.4 s por documento (field_method_comparison.csv, llm_median_latency_ms, las 16 filas), y la ejecución completa de los 16 grupos consumió aproximadamente 1.33M tokens de prompt + 0.28M tokens de completion (suma de llm_prompt_tokens / llm_completion_tokens). Esto no es una latencia de extracción de campos en tiempo real — se adapta al procesamiento por lotes asíncrono, no a consultas interactivas.

¿El postprocesamiento con LLM funciona con recibos que no están en inglés?

Mejor que regex, pero con un techo más bajo. En los recibos CORD en indonesio, el LLM mantuvo el F1 de campos en 0.16–0.55 mientras que regex cayó a 0.00–0.34 (field_method_comparison.csv, filas cord_v2) — pero el mejor resultado CORD (0.5527) aún queda por detrás del mejor resultado en inglés (0.6171), lo que refleja tanto la escritura más difícil como la base de OCR degradada. Las reglas escritas para recibos en inglés prácticamente dejaron de funcionar; el LLM se degradó de forma gradual en su lugar.

Metodología y Fuentes

Protocolo

Esta página informa la comparación de extracción de campos del benchmark OCR de código abierto de ImageToTable.ai — una ejecución experimental independiente y reproducible (nivel oficial), no un estudio de afirmaciones de terceros. El flujo para cada par (modelo × conjunto de datos): el motor OCR produce texto a partir de imágenes de recibos; ese texto se extrae dos veces — una con un conjunto fijo de patrones regex y otra con el posprocesador LLM — y ambos resultados se puntúan contra los mismos campos de referencia. El posprocesador LLM es deepseek-v4-flash (la columna llm_model en el CSV de comparación), ejecutado a temperatura 0 para una salida determinista. Las 361 muestras de SROIE y las 100 de CORD se completaron correctamente (llm_ok_count = 361 / 100).

Entorno de ejecución

• Hardware: todas las ejecuciones de GPU en NVIDIA RTX 4090 (24 GB). Los motores basados en PyTorch (docTR, EasyOCR, Docling) se ejecutaron con PyTorch 2.8.0+cu128 (CUDA 12.8); Tesseract se ejecutó solo con CPU (sin costo de GPU); los motores servidos con vLLM (Surya2, Unlimited-OCR, PaddleOCR-VL) se ejecutaron en un pod de vLLM. Las versiones de controlador y Python varían ligeramente por ejecución y se registran exactamente en los manifiestos de ejecución redactados (consulte Acceso a artefactos más abajo).
• Posprocesador LLM: deepseek-v4-flash vía API, temperatura 0.
• Modo de medición: warm_then_scored — una pasada de calentamiento fija precede a la pasada puntuada, por lo que las cifras de latencia son de estado estable.
• Conjuntos de datos: prueba SROIE 2019 — 361 recibos en inglés, campos planos (empresa, fecha, dirección, total), CC-BY-4.0; prueba CORD v2 — 100 recibos en indonesio, campos anidados (menú, sub_total, total), CC-BY-4.0.
• Recuentos de muestras: SROIE 361 / CORD 100, todas de las divisiones de prueba fijas (sin fuga de datos de entrenamiento).

El texto OCR ascendente consumido por ambos posprocesadores provino de estas versiones de motor:

Las huellas de reproducibilidad completas por ejecución están en los manifiestos de ejecución redactados del benchmark bajo results/manifests/ en el repositorio público (un manifest.json por ejecución publicada, 16 en total). Cada uno revela: id de ejecución, modelo + versión, hash del script de ejecución (SHA-256), modelo/controlador/VRAM de GPU, versiones de torch/CUDA/torchvision/torchaudio, versión de Python, hash de pip-freeze, metadatos de costo (GPU $/hora y marca de tiempo del precio), modo de medición y hashes de artefactos (lista de muestras, predicciones, métricas, rendimiento).

Definiciones de Métricas

• F1 de valor de campo (enfoque regex): media armónica de precisión y exhaustividad sobre los valores de campo extraídos, usando postprocesamiento regex — el enfoque tradicional de KIE basado en reglas + OCR. 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 postprocesamiento OCR + 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 fundamental (regex_field_value_accuracy / llm_field_value_accuracy).
• Campos de documento exactos: 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 únicamente para explicar el límite de Tesseract con LLM.

Acceso a Artefactos

1. field_method_comparison.csv (GitHub raw). 16 filas = 8 modelos × 2 conjuntos de datos; columnas model, dataset, llm_model (= deepseek-v4-flash), F1 de campo regex/llm + precisión, campos de documento exactos, 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 origina en 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 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.

Limitaciones

• Alcance del documento: Solo recibos (SROIE + CORD). Los hallazgos no se generalizan a facturas, formularios o documentos largos sin pruebas adicionales.
• Tamaño de la muestra: 361 recibos en inglés + 100 en indonesio. El campo F1 es sensible a la composición del corpus; trate las diferencias de unos pocos centésimos como ruido.
• Modelo LLM único: Todas las filas de LLM usan deepseek-v4-flash. Un LLM diferente (tamaño, indicaciones o proveedor) produciría números absolutos distintos; el orden regex-vs-LLM puede variar en los márgenes.
• Advertencia sobre la verdad de referencia de CORD: El gt_text de CORD incluye la estructura de anotación y diferencias de normalización de VLM, por lo que el CER bruto en CORD está sistemáticamente inflado para cada motor (por ejemplo, el CER 1.08 de PaddleOCR-VL es un artefacto, no una lectura real de su calidad de texto). Las métricas de campo son la comparación justa; el CER se usa aquí solo para la explicación de Tesseract.
• La latencia no es la latencia de extracción en tiempo real: llm_median_latency_ms (1.8–2.4 s) cubre toda la llamada de extracción de campos OCR-texto → LLM, no la búsqueda por campo, y no incluye el tiempo de OCR en sí.
• Ajuste de regex: Los patrones de regex son un conjunto fijo escrito una vez por conjunto de datos (esquema SROIE-flat); una biblioteca de regex muy ajustada por proveedor podría puntuar más alto en sus propios formatos — a costa de la carga de mantenimiento que el LLM elimina.

Referencias relacionadas: la brecha entre la precisión de campo y de caracteres · Precisión de OCR de recibos · puntos de referencia de precisión por tipo de documento

Lectura relacionada: Cómo leer las afirmaciones de precisión de OCR