Regex vs LLM para Extracción de Campos en Recibos
Resultados del Benchmark Propio (2026)

Resultados SROIE: Recibos en Inglés (361 Muestras)

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

SROIE (Scanned Receipt OCR and Information Extraction, ICDAR 2019) es el benchmark estándar de recibos en inglés: 361 recibos de prueba con cuatro campos objetivo — empresa, fecha, dirección y total (Huang et al., 2019). Cada motor primero produjo texto OCR en una configuración compartida RTX 4090; ese texto luego se alimentó a dos postprocesadores 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 puntuaron contra los mismos campos de verdad fundamental. El gráfico muestra el F1 por campo de regex (azul) vs el F1 por campo de LLM (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 %). Postprocesador LLM: deepseek-v4-flash (columna llm_model). 361 muestras por motor (llm_ok_count).

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

Resultados CORD: Recibos Indonesios (100 Muestras, Prueba de Estrés)

CORD amplía la brecha, no porque el LLM mejore — no lo hace — sino porque las expresiones regulares colapsan: seis de ocho motores puntúan el F1 de campos por regex en o por debajo del 10.8%, y dos (docTR 0.0%, EasyOCR 0.7%) recuperan casi nada. El LLM aún eleva cada motor que no sea Tesseract al 33.8% o más, demostrando que su extracción se generaliza a través de idiomas y diseños donde los patrones escritos a mano no pueden.

CORD v2 es un conjunto de datos de recibos en idioma 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 en recibos indonesios. Dos advertencias aplican al leer esta tabla. Primero, el texto de referencia de CORD incluye diferencias en la estructura de anotación y la normalización de salida del VLM, que inflan sistemáticamente el CER bruto para cada motor — por lo tanto, 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 SROIE en inglés; el esquema anidado de CORD y el formato indonesio (moneda Rp, convenciones de fecha) los derrotan — lo cual es el hallazgo en sí: 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 campos por 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 nivela la brecha — y dónde está su techo

Tres patrones en los números explican lo que sucede 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 elegías importaba enormemente: el F1 de campos de SROIE abarcó desde 0,077 (docTR) hasta 0,338 (Unlimited-OCR) — una amplitud de 0,26 puntos. Con el LLM, seis de los siete motores no-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 aguas arriba solo necesita producir texto legible; el LLM extrae campos de él con una calidad aproximadamente independiente del motor. Dos motores se quedan por debajo 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 techo de Tesseract lo establece su OCR, no su postprocesador

"Basura de entrada, basura de salida" se aplica incluso al postprocesamiento con LLM. El texto OCR crudo 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 en desorden. Su F1 de campos con LLM en CORD es consecuentemente 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 techo de cualquier postprocesador lo establece la calidad base del OCR subyacente — una restricción que ninguna ingeniería de prompts elimina.

(c) docTR es el mayor beneficiario: de suelo regex a techo 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 campos con regex en SROIE fue el más bajo de los 8 motores con 0,0766 — su texto limpio y preciso (CER de SROIE 0,1971, el mejor del benchmark, summary_metrics.csv fila para doctr/sroie_2019) simplemente no coincidía con los patrones regex para totales con separadores de miles o direcciones multilínea. Con el LLM, el mismo texto produce el mejor resultado de SROIE 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 es suficiente Regex y cuándo usar un LLM

El compromiso honesto no es "regex está roto" sino "regex es frágil cuando los recibos son variables". El posprocesamiento con regex es determinista, gratuito e instantáneo; un posprocesador LLM añade tokens y 1,8–2,4 s de latencia 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 regex colapsó 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 es suficiente regex: si tus documentos provienen de un conjunto pequeño y estable de diseños y los campos que necesitas aparecen en formatos casi constantes — un patrón fijo de número de factura, una única convención de fecha, una sola moneda — regex es la herramienta correcta: no cuesta nada, se ejecuta en microsegundos y sus fallos son predecibles. Los casos base del benchmark lo demuestran: los motores con regex alineada a recibos aún alcanzaron un F1 de 0,34 en campos en SROIE (Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368).

Cuándo usar un LLM: en cuanto entra la variación de formato — múltiples monedas, formatos de fecha regionales, direcciones multilínea, nombres de proveedores en estilos variables o un segundo idioma. Cada uno de esos rompe un patrón; el LLM los absorbe todos en un solo prompt. Los resultados de CORD del benchmark cuantifican lo que cuesta "un idioma más" 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 mantuvo 0,16–0,55 — una penalización que el enfoque regex pagó al 100% y el LLM solo parcialmente. La arquitectura correcta 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 basada en reglas para campos con formatos esperados estrictos, con el costo por documento de 1,8–2,4 s del LLM amortizado en procesamiento por lotes asíncrono en lugar de esperas síncronas del usuario.

Preguntas Frecuentes

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

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

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

docTR en SROIE, con un F1 de campos de 0.6171 — pero las diferencias entre motores prácticamente desaparecen una vez que se usa un LLM: seis de los siete motores no-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, seguido de cerca por docTR con 0.5500.

¿Por qué Tesseract queda rezagado incluso con un LLM?

Porque su texto OCR está demasiado degradado para que cualquier postprocesador pueda recuperar los campos. En recibos indonesios, su tasa de error de caracteres es de 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 respecto a 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 F1 de campos, field_method_comparison.csv filas sroie_2019). En recibos indonesios la mejora es mucho mayor — 36× para PaddleOCR y prácticamente ilimitada para docTR (0.0 → 0.55) porque regex casi no recuperó nada.

¿El postprocesamiento con LLM acierta todos los campos?

No — y los lectores no deberían esperarlo. El mejor F1 de campo LLM en el benchmark es 0.617 (docTR, SROIE), lo que significa que aproximadamente el 38% de los campos aún se perdieron o fueron incorrectos, y la mejor tasa de coincidencia exacta de documento completo 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 bala de plata; 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ó 1.8–2.4 s de latencia mediana por documento (field_method_comparison.csv, llm_median_latency_ms, las 16 filas), y la ejecución completa de 16 grupos consumió aproximadamente 1.33M tokens de prompt + 0.28M de finalización (suma de llm_prompt_tokens / llm_completion_tokens). Esta no es una latencia de extracción de campos en tiempo real — es adecuada para procesamiento por lotes asíncrono, no para consultas interactivas.

¿Funciona el postprocesamiento con LLM en recibos que no son en inglés?

Mejor que regex, pero con un techo más bajo. En recibos indonesios CORD, el LLM mantuvo el F1 de campo en 0.16–0.55 donde regex colapsó a 0.00–0.34 (field_method_comparison.csv, filas cord_v2) — pero el mejor resultado de CORD (0.5527) aún está por debajo del mejor resultado en inglés (0.6171), reflejando tanto la escritura más difícil como la degradación de la base de OCR. Las reglas escritas para recibos en inglés básicamente dejaron de funcionar; el LLM se degradó de manera más elegante.

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 una encuesta de afirmaciones de terceros. La canalización 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 vez mediante un conjunto fijo de patrones regex y otra vez mediante el postprocesador LLM — y ambas salidas se puntúan contra los mismos campos de referencia. El postprocesador 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 100 de CORD se completaron con éxito (llm_ok_count = 361 / 100).

Entorno de Ejecución

• Hardware: todas las ejecuciones en GPU se realizaron 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 en CPU (sin costo de GPU); los motores servidos por vLLM (Surya2, Unlimited-OCR, PaddleOCR-VL) se ejecutaron en un pod vLLM. Las versiones del controlador y de Python varían ligeramente por ejecución y se registran exactamente en los manifiestos de ejecución redactados (véase Acceso a Artefactos más abajo).
• Postprocesador LLM: deepseek-v4-flash vía API, temperatura 0.
• Modo de medición: warm_then_scored — un pase de calentamiento fijo precede al pase puntuado, por lo que las cifras de latencia son en estado estable.
• Conjuntos de datos: SROIE 2019 test — 361 recibos en inglés, campos planos (empresa, fecha, dirección, total), CC-BY-4.0; CORD v2 test — 100 recibos en indonesio, campos anidados (menú, sub_total, total), CC-BY-4.0.
• Conteo de muestras: SROIE 361 / CORD 100, todas de las divisiones de prueba fijas (sin fuga de datos de entrenamiento).

El texto OCR upstream consumido por ambos postprocesadores provino de estas versiones de motor:

Las huellas de reproducibilidad completas por ejecución se encuentran en los manifiestos de ejecución redactados del benchmark en results/manifests/ del 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 ($/hora de GPU 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 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 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 referencia (regex_field_value_accuracy / llm_field_value_accuracy).
• Documentos-campos-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 crudo, utilizado en esta página solo para explicar el techo LLM de Tesseract.

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), regex/llm field F1 + accuracy, document-fields-exact, 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 remonta a una fila aquí.
2. summary_metrics.csv (GitHub raw). CER/WER por modelo × conjunto de datos, utilizado para la explicación del techo de Tesseract (tesseract/cord_v2 cer 0.9523) y el CER de docTR en SROIE 0.1971.
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que alberga 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 digital del entorno por ejecución y los hashes de artefactos listados arriba.
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 F1 de campo es sensible a la composición del corpus; trate las diferencias de unos pocos centésimos en un solo punto como ruido.
• Modelo LLM único: Todas las filas LLM usan deepseek-v4-flash. Un LLM diferente (tamaño, prompt o proveedor) produciría números absolutos diferentes; el orden regex-vs-LLM podría cambiar en los márgenes.
• Advertencia de la verdad de referencia de CORD: El gt_text de CORD incluye diferencias en la estructura de anotación y la normalización VLM, por lo que el CER bruto en CORD está sistemáticamente inflado para cada motor (por ejemplo, el CER de PaddleOCR-VL de 1.08 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 regex son un conjunto fijo escrito una vez por conjunto de datos (esquema SROIE-flat); una biblioteca regex 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: Precisión a Nivel de Campo vs. a Nivel de Carácter · Precisión de OCR de Recibos · Precisión de OCR por Tipo de Documento

Lectura relacionada: Cómo Leer las Afirmaciones de Precisión de OCR