PaddleOCR vs EasyOCR en Recibos
Precisión vs Costo Benchmark (2026)

Los dos motores representan dos generaciones de OCR basado en aprendizaje profundo. PaddleOCR (basado en PaddlePaddle, arquitectura PP-OCR, v3.7.0) es un pipeline moderno de dos etapas: una etapa de detección localiza las regiones de texto, y luego una etapa de reconocimiento las transcribe — diseñado para una alta precisión en texto impreso a gran escala. EasyOCR (basado en PyTorch, 1.7.2) es un reconocedor clásico de una sola pasada CNN + RNN + CTC — un extractor de características ResNet que alimenta un modelo de secuencia decodificado con Clasificación Temporal Conectista. Es conocido por su amplia cobertura de idiomas y escrituras (más de 80 idiomas listos para usar) y una instalación famosamente simple. La Tasa de Error de Carácter (CER) mide inserciones, eliminaciones y sustituciones divididas por los caracteres de la verdad fundamental — un CER de 0.204 significa ~20.4 caracteres mal leídos por cada 100; la Tasa de Error de Palabra (WER) aplica la misma lógica de distancia de edición a nivel de palabra completa. En ambos casos, un valor más bajo es mejor.

Precisión del Texto en SROIE (Recibos en Inglés): La Ventaja Clara de PaddleOCR

En los 361 recibos en inglés del conjunto de prueba SROIE 2019, la arquitectura moderna gana en ambas métricas de texto: CER 0.2045 vs 0.2833 (una mejora relativa del 27.8%) y WER 0.3256 vs 0.6158 — el WER de EasyOCR es casi el doble. La brecha en WER es mayor que la brecha en CER, lo que indica que EasyOCR complica los errores a nivel de carácter en fallos de palabra completa en este corpus. Ambos motores funcionan sin errores (error_rate 0.0 en cada fila de SROIE y CORD en el CSV).

Fuente: summary_metrics.csv — columnas cer y wer, filas sroie_2019. PaddleOCR cer 0.20449 / wer 0.32563; EasyOCR cer 0.28327 / wer 0.61578. Un valor más bajo es mejor. 361 muestras por motor; ambos error_rate 0.0.

Tabla: summary_metrics.csv — columnas cer / wer / error_rate, filas sroie_2019. Valores exactos: PaddleOCR cer 0.20449 / wer 0.32563; EasyOCR cer 0.28327 / wer 0.61578. Un CER/WER más bajo es mejor. Ninguno de los dos motores es el campeón de precisión general del benchmark — ese título pertenece a Surya2 (CER 0.1915) y docTR (CER 0.1971) en la misma ejecución de 8 motores (summary_metrics.csv, filas surya2 y doctr sroie_2019).

Extracción de Campos: KIE Mediante Regex y Mediante un LLM

La precisión del texto clasifica a los motores; la extracción de campos es lo que los sistemas posteriores realmente consumen. Las métricas de campos SROIE del benchmark apuntan a cuatro campos planos de recibos (empresa, fecha, dirección, total) usando dos postprocesadores en el texto OCR de cada motor: patrones regex fijos (el enfoque tradicional de OCR + extracción de información clave basada en reglas) y un postprocesador LLM (deepseek-v4-flash a temperatura 0) con un prompt estructurado. Mediante regex, PaddleOCR extrae campos con 0.3254 F1 de campo frente a 0.1477 de EasyOCR — una ventaja de 2.2×; mediante el LLM, la brecha persiste con 0.5810 frente a 0.3717 (1.56×).

El F1 de valor de campo es la media armónica de precisión y recuperación sobre los valores de campo extraídos frente a la verdad de referencia — 1.0 significa que cada campo del recibo se recuperó perfectamente, 0 significa nada. Las columnas de campos regex SROIE son las métricas postprocessed_sroie_receipt_regex_* del benchmark: patrones fijos aplicados al texto OCR de cada motor (postprocesado, no salida estructurada nativa). Observe el contexto de clasificación: el 0.3254 de PaddleOCR es el tercer mejor resultado de campos regex en el benchmark de 8 motores (detrás de Unlimited-OCR 0.3376 y PaddleOCR-VL 0.3368) y el mejor entre los cuatro motores puramente tradicionales; el 0.1477 de EasyOCR ocupa el séptimo lugar de ocho (summary_metrics.csv, field_f1_regex, filas sroie_2019).

Fuente: field_method_comparison.csv — columnas regex_field_value_f1 / llm_field_value_f1, filas sroie_2019 (decimales de 0–1 mostrados como %). Postprocesador LLM: deepseek-v4-flash (columna llm_model). 361 muestras por motor (llm_ok_count).

Tabla: field_method_comparison.csv — columnas regex y llm, filas sroie_2019. Las columnas regex son métricas postprocessed_sroie_receipt_regex_*: patrones fijos aplicados al texto OCR de cada motor. Postprocesador LLM: deepseek-v4-flash a temperatura 0 (columna llm_model). La latencia LLM es incurrida por la API y está separada de la latencia del motor (summary_metrics.csv latency_p50_ms). “Documentos con todos los campos exactos” es la fracción de documentos donde cada campo objetivo coincidió exactamente — un criterio mucho más estricto que el F1 por campo; EasyOCR acierta los cuatro campos exactamente en el 0.28% de los recibos.

La paradoja de EasyOCR y los LLM: texto de nivel medio, peor extracción posterior

Este es el dato más distintivo de la página, y es genuinamente contraintuitivo: el texto OCR de EasyOCR es de nivel medio en precisión de caracteres (CER de SROIE 0.2833, cuarto de ocho motores) — sin embargo, cuando ese texto se alimenta al mismo postprocesador LLM que se usa para todos los demás motores (deepseek-v4-flash, mismo prompt, mismos recibos), su F1 de campos LLM de SROIE de 0.3717 es el más bajo de los ocho motores en el benchmark — incluso por debajo de Tesseract (0.4389), un motor de CPU con un CER peor (0.3347). Solo cambió el texto OCR; el LLM, el prompt y los recibos fueron idénticos.

Patrón observado, mecanismo no verificado. Una hipótesis plausible — y no más que eso — es una convención de formato de salida: la forma en que EasyOCR dispone, une o separa las líneas de texto parece degradar la extracción de campos LLM posteriores por razones no relacionadas con la precisión de caracteres bruta. El benchmark no aisló este mecanismo; el resultado se documenta aquí como reproducible y estable (la fila de EasyOCR en SROIE fue re-verificada en una ejecución con torch 2.8 el 2026-08-17, r1/r2/r3 idénticos a nivel de byte; el CSV publicado ya contiene esos valores corregidos), pero no se hace ninguna afirmación causal. La implicación práctica es lo opuesto a la apariencia de marketing: en este corpus, elegir EasyOCR para un texto "suficientemente bueno" significa presupuestar para la peor recuperación de campos posterior con LLM de todos los motores probados.

Fuente: field_method_comparison.csv — llm_field_value_f1, las ocho filas de sroie_2019, 361 muestras cada una (llm_ok_count). Postprocesador LLM idéntico para todos los motores: deepseek-v4-flash a temperatura 0. Contexto de CER de summary_metrics.csv, columna cer, filas de sroie_2019.

Tabla: field_method_comparison.csv — llm_field_value_f1, todas las filas sroie_2019; columna CER de summary_metrics.csv, cer, filas sroie_2019. El CER de EasyOCR (0.2833) ocupa el cuarto lugar de ocho — texto de nivel intermedio con la peor recuperación de campos downstream del LLM (0.3717, por debajo del 0.4389 de Tesseract). La paradoja se documenta como observada y reproducible; su mecanismo no se aísla en este benchmark.

El Envolvente Operativo: Donde EasyOCR es Verdaderamente Competitivo

La precisión no es el único eje, y en el eje operativo EasyOCR tiene contraventajas reales y medibles. En el mismo RTX 4090 a la misma tarifa de $0.76/hr, EasyOCR procesa SROIE a $0.110 por 1,000 páginas frente a los $0.221 de PaddleOCR’s (una brecha de 2.0×), mantiene 124.5 páginas/min frente a 79.7 (1.56×), y mantiene su cola de peor caso ajustada: p95 960.4 ms frente al pico de primera página de PaddleOCR’s de 3,331.4 ms (una cola 3.5× más ajustada). Su huella también es más simple de desplegar — un solo runtime de PyTorch con amplia cobertura de idiomas, frente al stack de framework más pesado de PaddlePaddle.

Una aparente contradicción merece una explicación honesta: PaddleOCR tiene la latencia mediana por página menor (297.0 ms p50 frente a los 413.6 ms de EasyOCR) pero la cifra de páginas por minuto menor (79.7 frente a 124.5). Los dos números miden relojes diferentes. La latencia p50 es la inferencia por página en estado estable, medida en caliente (modelo ya cargado); las páginas/min son el rendimiento de reloj de pared de toda la ejecución, que incluye la inicialización del modelo y los efectos de lote. El runtime más pequeño y de carga más rápida de EasyOCR gana la carrera de volumen de reloj de pared; la inferencia por página de PaddleOCR es individualmente más rápida una vez en caliente. Ambos números son reales; describen cosas diferentes, y una carga de trabajo dominada por la sobrecarga de carga del modelo (muchos lotes pequeños, inicios en frío frecuentes) experimentará la ventaja de reloj de pared de EasyOCR, mientras que una canalización larga y en caliente experimentará la ventaja por página de PaddleOCR.

El costo se calcula como tiempo de ejecución de reloj de pared × la tarifa de RunPod RTX 4090 ($0.76/hora, precio con marca de tiempo en los manifiestos de ejecución), incluyendo la inicialización del modelo — el precio que realmente pagarías por el tiempo de GPU. El rendimiento son páginas por minuto de reloj de pared incluyendo la misma inicialización. Las latencias p50/p95 son tiempos de inferencia por página en estado estable medidos en caliente y luego puntuados (excluyendo la carga del modelo); la p95 de PaddleOCR de 3,331 ms es un pico de primera página/prefill, no su comportamiento en estado estable.

Fuente: summary_metrics.csv — columnas latency_p50_ms / latency_p95_ms, filas sroie_2019. PaddleOCR p50 296.99 / p95 3331.35; EasyOCR p50 413.64 / p95 960.37. Latencia en estado estable (modo de medición warm_then_scored, excluye carga del modelo).

Fuente: summary_metrics.csv — columna cost_per_1000_pages, filas sroie_2019. PaddleOCR 0.2214, EasyOCR 0.1098. Costo = tiempo de ejecución de reloj de pared × $0.76/hr incluyendo init del modelo, precio con marca de tiempo en los manifiestos de ejecución (agosto 2026). Ninguno de los motores es el más barato del benchmark — docTR lo tiene a $0.048 por 1,000 páginas (summary_metrics.csv, fila doctr/sroie_2019).

Tabla: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, filas sroie_2019. Ambos motores GPU (RTX 4090, precio de $0.76/hr con marca de tiempo en manifiestos); el costo incluye la inicialización del modelo. Valores exactos: PaddleOCR p50 296.99 / p95 3331.35 / 79.71 pg/min / $0.2214; EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098. La inversión p50-vs-páginas/min se explica en el texto anterior: inferencia por página en estado estable (gana PaddleOCR) vs. rendimiento en tiempo real que incluye inicialización y efectos de lote (gana EasyOCR).

CORD (Recibos Indonesios): Ambos Colapsan, Pero la Recuperación de Campos por LLM de PaddleOCR Sobrevive

Ningún motor fue entrenado predominantemente en recibos indonesios, por lo que CORD v2 (100 muestras, campos anidados menu/sub_total/total) funciona como una prueba de estrés entre idiomas — y ambos colapsan en CER bruto: 0.9083 (PaddleOCR) y 0.9185 (EasyOCR), un empate por desajuste de idioma donde ambos motores son efectivamente incapaces de leer el texto. Según el protocolo de referencia, los números de CORD se mantienen en cuarentena de la comparación con SROIE — no se fusionan en ninguna clasificación — porque el texto de referencia de CORD incrusta estructura de anotación, lo que infla el CER bruto para cada motor además del genuino desajuste de idioma.

Las métricas de campos cuentan una historia diferente a los CER casi idénticos. A través del postprocesador LLM, el F1 de campos de PaddleOCR se mantiene en 0.5527 frente al 0.3378 de EasyOCR en CORD — el mismo patrón de SROIE, extendido: la recuperación aguas abajo del LLM de PaddleOCR resiste el choque lingüístico que la de EasyOCR no resiste, incluso cuando ambos reconocedores de texto fallan a nivel de carácter. El F1 de campos LLM de EasyOCR en CORD es el segundo más bajo de los ocho motores (solo por encima del 0.1627 de Tesseract, filas cord_v2 de summary_metrics.csv/field_method_comparison.csv) — nuevamente por detrás de motores con peor CER, el paradoja persistiendo en ambos conjuntos de datos. CORD se cita aquí por contexto de robustez lingüística; se omite deliberadamente de la agrupación con los números de SROIE en una sola tabla de clasificación.

Tabla: summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) y field_method_comparison.csv (field F1), filas cord_v2. No fusione los números de CORD en ninguna clasificación de SROIE: El CER de CORD combina una discrepancia lingüística genuina con una inflación de la estructura de anotación en la verdad de referencia. Los patrones regex fueron escritos para formatos en inglés, por lo que el field F1 de regex colapsa a ~0–2% en ambos motores. El field F1 del LLM de PaddleOCR de 0.5527 en CORD repite su ventaja en SROIE (0.5810 vs 0.3717) — su recuperación posterior al LLM sobrevive al choque lingüístico que la de EasyOCR no.

Quién Gana Cuándo: La Cuadrícula de Resumen

“Mejor” depende de la carga de trabajo, y esta comparación directa divide los ejes con claridad: cada eje de precisión en recibos en inglés favorece a PaddleOCR; el costo, el rendimiento en tiempo real, la latencia extrema y la simplicidad de despliegue favorecen a EasyOCR; y el campeonato de precisión de texto puro no pertenece a ninguno (Surya2/docTR) — mientras que el resultado posterior al LLM de EasyOCR es su mayor advertencia, no su punto de venta.

Preguntas Frecuentes

¿Es PaddleOCR más preciso que EasyOCR en recibos?

Sí, en todos los ejes de precisión medidos en este benchmark. En SROIE 2019: CER 0.2045 vs 0.2833 (mejora relativa del 27.8%), WER 0.3256 vs 0.6158, F1 de campos por regex 0.3254 vs 0.1477 (2.2×), F1 de campos postprocesados por LLM 0.5810 vs 0.3717 (summary_metrics.csv y field_method_comparison.csv, filas sroie_2019). Ninguno de los dos motores es el campeón general de texto del benchmark — Surya2 (CER 0.1915) y docTR (0.1971) ostentan ese título.

¿Es EasyOCR más barato que PaddleOCR?

Sí — aproximadamente 2× más barato por cada 1.000 páginas en recibos en inglés: $0.110 vs $0.221 en SROIE 2019, ampliándose a $0.086 vs $0.342 en CORD, en el mismo RTX 4090 a $0.76/hr con costo que incluye la inicialización del modelo (summary_metrics.csv, cost_per_1000_pages, filas sroie_2019 y cord_v2). El motor más barato del benchmark en general es docTR a $0.048 por 1.000 páginas.

¿Cuál es más rápido: PaddleOCR o EasyOCR?

Depende de a qué reloj se refiera. PaddleOCR tiene una latencia mediana en estado estable más baja (297.0 vs 413.6 ms p50), pero EasyOCR tiene un rendimiento en tiempo real más alto (124.5 vs 79.7 páginas/min) porque las páginas por minuto en tiempo real incluyen la inicialización del modelo y los efectos de lote, y la carga de ejecución más ligera de EasyOCR es más rápida (summary_metrics.csv, latency_p50_ms / pages_per_minute, filas sroie_2019). Para un pipeline en ejecución prolongada y caliente, PaddleOCR es más rápido por página; para muchos lotes pequeños o frecuentes en frío, EasyOCR gana la carrera en tiempo real.

¿Por qué EasyOCR tiene la peor extracción de campos por LLM a pesar de una precisión de caracteres aceptable?

Este es el paradoja documentada del benchmark, actualmente sin un mecanismo probado. El CER de EasyOCR en SROIE (0.2833) ocupa el cuarto lugar de ocho motores, sin embargo su F1 de campos postprocesados por LLM (0.3717) ocupa el último lugar — incluso por debajo de Tesseract (0.4389), que tiene un CER peor. La hipótesis principal es una convención de formato de salida en la forma en que EasyOCR dispone o une las líneas de texto que degrada la extracción posterior por LLM; se etiqueta como un patrón observado y reproducible con el mecanismo no verificado (field_method_comparison.csv, llm_field_value_f1, filas sroie_2019).

¿Por qué ambos motores obtienen tan malos resultados en los recibos CORD?

Dos causas acumulativas que el protocolo mantiene separadas del ranking SROIE: una verdadera incompatibilidad lingüística (recibos indonesios fuera del enfoque de entrenamiento de ambos motores) e inflación en la estructura de anotación dentro del texto ground-truth de CORD — el CER llega a 0.9083 (PaddleOCR) y 0.9185 (EasyOCR) (summary_metrics.csv, cer, cord_v2 rows). Lo que aún los separa es la recuperación posterior al LLM: PaddleOCR 0.5527 vs EasyOCR 0.3378 en F1 de campos — el patrón SROIE persiste incluso cuando ambos reconocedores fallan a nivel de carácter.

¿Qué motor debe elegir un pipeline de recibos, PaddleOCR o EasyOCR?

Si su pipeline consume campos — valores extraídos para empresa, fecha, totales — PaddleOCR es el predeterminado claro para recibos: 2.2× en F1 de campos bajo regex, 1.56× bajo un LLM, y una recuperación posterior al LLM que sobrevive al choque lingüístico de CORD (field_method_comparison.csv). Si necesita ¿De dónde provienen los números en esta página?

Cada cifra es una fila de los CSV publicados del benchmark de primera parte — results/summary_metrics.csv (CER/WER, F1 de campos por regex, latencia, costo, rendimiento) y results/field_method_comparison.csv (regex vs postprocesamiento por LLM, llm_model = deepseek-v4-flash) — alojados en ImageToTableai/benchmark-ocr, con un manifest.json redactado por ejecución para huellas de entorno. Las definiciones de los conjuntos de datos provienen de los papers SROIE 2019 y CORD citados a continuación.

Metodología y Fuentes

Protocolo

Esta página presenta un corte directo de un benchmark independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros ni una página de comparación de proveedores. Solo se usaron divisiones de prueba fijas: SROIE 2019 test (361 recibos en inglés, campos planos empresa/dirección/total) y CORD v2 test (100 recibos en indonesio, campos anidados menú/sub_total/total); las divisiones de entrenamiento nunca se evaluaron. Ambos motores vieron las mismas imágenes, la misma verdad de referencia y el mismo protocolo 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). Ambas ejecuciones completaron con error_rate 0.0 en ambos conjuntos de datos (columna error_rate de summary_metrics.csv). La ejecución subyacente contiene ocho motores en total; esta página compara solo los dos motores nombrados, citando a los demás solo como contexto de clasificación. Los resultados completos de los 8 motores se publican por separado en Traditional OCR vs Document Parsing VLMs.

Entorno de Ejecución

• Hardware: ambos motores se ejecutaron en la misma NVIDIA RTX 4090 (24 GB); el costo de GPU se calculó con la tarifa bajo demanda de RunPod de $0.76/hr, con marca de tiempo del precio en el manifiesto redactado de cada ejecución (agosto 2026).
• Motores: listos para usar, sin ajuste fino. Versiones bloqueadas: PaddleOCR 3.7.0 (OCR moderno de aprendizaje profundo en dos etapas — PP-OCR detección + reconocimiento, GPU) y EasyOCR 1.7.2 (clásico ResNet+CRNN con decodificación CTC, GPU) — según la tabla de modelos del repositorio público (README.md) y los manifiestos de ejecución. La fila SROIE de EasyOCR se re-verificó en una reejecución con torch 2.8 el 2026-08-17 (ejecuciones repetidas r1/r2/r3 idénticas a nivel de byte); los CSV publicados contienen esos valores corregidos.
• Postprocesador LLM: deepseek-v4-flash vía API a temperatura 0 para salida determinística (la columna llm_model en field_method_comparison.csv); fue el único modelo utilizado para todas las filas de campos LLM en ambos motores.
• Base de costos: tiempo de ejecución real × $0.76/hr, incluyendo la inicialización del modelo — el procesamiento por lotes reduce el costo por página.
• Postprocesamiento de campos: las métricas de campos regex de SROIE son postprocessed_sroie_receipt_regex_* (columnas regex_* de field_method_comparison.csv) — campos extraídos del texto OCR por un conjunto fijo de patrones. Miden OCR + extracción posterior, no la salida estructurada nativa de ningún modelo; las columnas LLM_* miden texto OCR + extracción LLM. Las dos canalizaciones nunca se combinan.

Definición de Métricas

• CER (Tasa de Error de Caracteres): distancia de edición (inserciones + eliminaciones + sustituciones) entre el texto OCR y la verdad de terreno, dividida por los caracteres de la verdad de terreno. Menor es mejor.
• WER (Tasa de Error de Palabras): el mismo cálculo de distancia de edición a nivel de palabra.
• F1 de campo-valor (regex): media armónica de precisión/recall sobre los valores de campo extraídos utilizando patrones regex fijos en el texto OCR (pipeline de OCR tradicional + KIE basado en reglas). Columna: regex_field_value_f1. Una puntuación de 0 significa que no se recuperaron valores de campo.
• F1 de campo-valor (LLM): la misma métrica en la salida del postprocesador LLM (texto OCR → deepseek-v4-flash → campos). Columna: llm_field_value_f1. Los dos pipelines son diferentes y nunca se combinan.
• Campos de documento exactos: fracción de documentos donde todos los campos objetivo coincidieron exactamente — un criterio mucho más estricto que el F1 por campo.
• Latencia p50/p95 y páginas/min: tiempo de inferencia por página en estado estable (calentado y luego evaluado, excluye la carga del modelo) y rendimiento en tiempo real incluyendo la inicialización del modelo. Miden relojes diferentes; la inversión p50-vs-páginas/min en esta página es una diferencia en el modelo de medición, no un error.
• Costo por 1,000 páginas: horas GPU facturadas por 1,000 páginas a la tarifa registrada de $0.76/hr, incluyendo la inicialización del modelo.

Lista de Fuentes

1. summary_metrics.csv (GitHub raw). 16 filas = 8 modelos × 2 conjuntos de datos. Columnas: 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. Cada número de CER/WER, latencia, costo y rendimiento en esta página se remonta a las filas de paddleocr y easyocr aquí.
2. field_method_comparison.csv (GitHub raw). 16 filas; columnas model, dataset, llm_model (= deepseek-v4-flash), precisión y F1 de campo-valor regex/llm, document-fields-exact, llm_median_latency_ms, recuentos de tokens. Cada número de F1 de campo regex/LLM se remonta a las filas de paddleocr y easyocr aquí (y a las ocho filas de sroie_2019 en la tabla de paradojas).
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que aloja los CSV de resultados, manifiestos de ejecución redactados, protocolo congelado y listas de muestras de conjuntos de datos (divisiones de prueba fijas) para reproducción.
4. results/manifests/ (GitHub). Un manifest.json redactado por cada ejecución publicada (16 ejecuciones) con versiones del modelo, GPU/driver, versiones de torch/CUDA/Python, metadatos de costos con marca de tiempo de precio y hashes de artefactos.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definición del conjunto de datos SROIE 2019, estructura de tareas y licencia (CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definición del conjunto de datos CORD v2, esquema de campos anidados y licencia (CC-BY-4.0).

Limitaciones

• Alcance del documento — solo recibos: SROIE + CORD. Nada aquí mide las capacidades de PaddleOCR’s PP-Structure para diseño/tablas/documentos, la amplitud de 80+ idiomas de EasyOCR en texto que no sea de recibos, ni ningún otro tipo de documento. No utilice esta página para concluir que cualquiera de los dos motores “gana en todo.”
• Tamaño de la muestra: 361 recibos en inglés + 100 en indonesio. El F1 por campo y el CER son sensibles al corpus; diferencias de un solo dígito de unas centésimas deben tratarse como ruido, no como verdad de ingeniería — aunque las brechas documentadas aquí (27.8% CER, 2.2× regex F1) están muy por encima de ese rango.
• Un solo nivel de GPU y un solo precio: todos los números provienen de una RTX 4090 a $0.76/hr, con precio registrado en agosto de 2026 en los manifiestos de ejecución. Otras GPUs, servicio multi-GPU, programación por lotes o cambios de precio alterarán la latencia, el rendimiento y el costo — recalcule los costos a las tarifas actuales antes de presupuestar.
• Un solo postprocesador LLM: todas las filas de LLM usan deepseek-v4-flash a temperatura 0. Un LLM diferente cambiará el F1 por campo absoluto; la magnitud de la paradoja de EasyOCR puede variar con el LLM, aunque el patrón observado se mantuvo para este único postprocesador en ambos conjuntos de datos. La latencia del LLM (~1,817–2,005 ms mediana en SROIE, field_method_comparison.csv llm_median_latency_ms) es incurrida por la API y no forma parte de la latencia de ninguno de los dos motores.
• Mecanismo de la paradoja de EasyOCR no verificado: el benchmark documenta que el texto de CER intermedio de EasyOCR produce la peor recuperación de campos aguas abajo del LLM (0.3717 SROIE / 0.3378 CORD) — un resultado observado y reproducible bajo la hipótesis de las convenciones de diseño del texto de salida, con el mecanismo causal explícitamente no aislado. Trátelo como un resultado medido para planificar en torno a él, no como una propiedad comprobada de la biblioteca.
• Ajuste de regex: el conjunto de patrones se escribió una vez por conjunto de datos. Una biblioteca de patrones ajustada por formato podría obtener una puntuación más alta en sus propios diseños — a costa del mantenimiento que el LLM elimina.
• El CER de CORD no es una lectura de calidad por modelo: la verdad de referencia de CORD incrusta la estructura de anotación y ninguno de los dos motores fue entrenado predominantemente en indonesio; el CER de CORD (~0.91) refleja la discordancia lingüística + la inflación de la verdad de referencia. Las filas de CORD se citan con encuadre y nunca se fusionan en ninguna clasificación de SROIE (regla de protocolo).
• Fijación de versiones: los resultados son válidos para PaddleOCR 3.7.0 y EasyOCR 1.7.2 (agosto de 2026). Versiones más recientes de cualquiera de los dos motores pueden alterar todos los números de esta página.

Referencias relacionadas: docTR vs Surya2 Receipt Benchmark · Traditional OCR vs Document Parsing VLMs · Regex vs LLM Field Extraction · Field-Level vs Character-Level Accuracy · Receipt OCR Accuracy

Lecturas relacionadas: AI OCR vs Traditional OCR Accuracy · AI Image Data Extraction vs Traditional OCR · AI Document Extraction Pricing (2026)