PaddleOCR vs EasyOCR en recibos
Benchmark de precisión vs costo (2026)

Los dos motores representan dos generaciones de OCR de 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 una etapa de reconocimiento las transcribe — diseñado para una alta precisión en texto impreso a 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 secuencial decodificado con Clasificación Temporal Conexionista. Es conocido por su amplísima cobertura de idiomas y escrituras (más de 80 idiomas listos para usar) y por su instalación famosamente simple. La Tasa de Error de Caracteres (CER) mide inserciones, eliminaciones y sustituciones divididas entre los caracteres de referencia — una CER de 0.204 significa ~20.4 caracteres mal leídos por cada 100; la Tasa de Error de Palabras (WER) aplica la misma lógica de distancia de edición a nivel de palabra completa. En ambas, cuanto menor, mejor.

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

En los 361 recibos en inglés del conjunto de prueba de SROIE 2019, la arquitectura moderna gana en ambas métricas de texto: CER 0.2045 frente a 0.2833 (una mejora relativa del 27.8%) y WER 0.3256 frente a 0.6158 — la WER de EasyOCR es casi el doble. La brecha en WER es mayor que la de CER, lo que indica que EasyOCR acumula errores a nivel de carácter hasta convertirlos en fallos de palabras completas 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. Cuanto menor, 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 general de precisión 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 posprocesadores sobre 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 posprocesador LLM (deepseek-v4-flash a temperatura 0) con un prompt estructurado. Mediante regex, PaddleOCR extrae campos con un F1 de campo de 0.3254 frente al 0.1477 de EasyOCR — una ventaja de 2.2×; mediante el LLM, la brecha persiste en 0.5810 frente a 0.3717 (1.56×).

El F1 de valor de campo es la media armónica de precisión y exhaustividad sobre los valores de campos extraídos frente a la verdad fundamental — 1.0 significa que cada campo del recibo se recuperó perfectamente, 0 significa que nada. Las columnas de campos regex de SROIE son las métricas postprocessed_sroie_receipt_regex_* del benchmark: patrones fijos aplicados al texto OCR de cada motor (posprocesado, no salida estructurada nativa). Nótese 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, columnas field_f1_regex, filas sroie_2019).

Fuente: field_method_comparison.csv — columnas regex_field_value_f1 / llm_field_value_f1, filas sroie_2019 (decimales almacenados 0–1 mostrados como %). Posprocesador 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. Posprocesador LLM: deepseek-v4-flash a temperatura 0 (columna llm_model). La latencia del LLM es incurrida por la API y es independiente 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 estándar mucho más estricto que el F1 por campo; EasyOCR acierta los cuatro campos exactamente en el 0.28% de los recibos.

La paradoja LLM de EasyOCR: 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 queda en el nivel medio en precisión de caracteres (SROIE CER 0.2833, cuarto de ocho motores) — sin embargo, cuando ese texto se alimenta al mismo posprocesador LLM usado para todos los demás motores (deepseek-v4-flash, mismo prompt, mismos recibos), su F1 de campo LLM SROIE de 0.3717 es el más bajo de los ocho motores del benchmark — incluso por debajo de Tesseract (0.4389), un motor de CPU con peor CER (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 nada más que eso — es una convención de formato de salida: la forma en que EasyOCR dispone, une o separa líneas de texto parece degradar la extracción de campos LLM posterior por razones no relacionadas con la precisión bruta de caracteres. El benchmark no aisló este mecanismo; el resultado se documenta aquí como reproducible y estable (la fila SROIE de EasyOCR se re-verificó en una re-ejecución torch 2.8 del 2026-08-17, r1/r2/r3 byte-idénticas; el CSV publicado ya incluye esos valores corregidos), pero no se hace ninguna afirmación causal. La implicación práctica es lo opuesto al barniz de marketing: en este corpus, elegir EasyOCR por un texto “suficientemente bueno” significa presupuestar la peor recuperación de campos LLM posterior de cualquier motor probado.

Fuente: field_method_comparison.csv — llm_field_value_f1, las ocho filas sroie_2019, 361 muestras cada una (llm_ok_count). Posprocesador LLM idéntico para todos los motores: deepseek-v4-flash a temperatura 0. Contexto CER de summary_metrics.csv, columna cer, filas 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 medio con la peor recuperación de campos aguas abajo con LLM (0.3717, por debajo del 0.4389 de Tesseract). La paradoja está documentada como observada y reproducible; su mecanismo no queda aislado por este benchmark.

El Envolvente Operativo: Donde EasyOCR Es Genuinamente Competitivo

La precisión no es el único eje, y en el eje operativo EasyOCR tiene contraventajas reales y medidas. En la misma RTX 4090 a los mismos $0.76/hora, EasyOCR procesa SROIE a $0.110 por cada 1,000 páginas frente a los $0.221 de PaddleOCR (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 3,331.4 ms de PaddleOCR (una cola 3.5× más ajustada). Su huella también es más simple de desplegar — un único runtime de PyTorch con amplia cobertura de idiomas, frente a la pila de framework más pesada de PaddlePaddle.

Una aparente contradicción merece una explicación honesta: PaddleOCR tiene la latencia mediana por página más baja (297.0 ms p50 frente a los 413.6 ms de EasyOCR) y sin embargo la cifra de páginas por minuto más baja (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); páginas/min es el rendimiento de tiempo 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 tiempo 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, arranques en frío frecuentes) experimentará la ventaja de tiempo de pared de EasyOCR, mientras que un pipeline de larga ejecución en caliente experimentará la ventaja por página de PaddleOCR.

El costo se calcula como tiempo de ejecución de tiempo de pared × la tarifa de RTX 4090 de RunPod ($0.76/hora, precio con marca de tiempo en los manifiestos de ejecución), incluida la inicialización del modelo — el precio que realmente pagaría por el tiempo de GPU. El rendimiento es páginas de tiempo de pared por minuto, incluida la misma inicialización. Las latencias p50/p95 son tiempos de inferencia por página en estado estable medidos en caliente y luego puntuados (carga del modelo excluida); el p95 de 3,331 ms de PaddleOCR 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 la 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 tiempo de pared × $0.76/hora incluida la inicialización del modelo, precio con marca de tiempo en los manifiestos de ejecución (agosto de 2026). Ningún motor es el más barato del benchmark — docTR lo ostenta a $0.048 por cada 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 en GPU (RTX 4090, precio de $0.76/h con marca de tiempo en los 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 entre p50 y páginas/min se explica en el texto anterior: inferencia por página en estado estable (gana PaddleOCR) frente a rendimiento en tiempo real que incluye inicialización y efectos de lote (gana EasyOCR).

CORD (recibos de Indonesia): ambos fallan, pero la recuperación de campos por LLM de PaddleOCR sobrevive

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

Las métricas de campo cuentan una historia distinta a la de los CER casi idénticos. A través del posprocesador LLM, el F1 de campo 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 posterior por LLM de PaddleOCR resiste el choque de idioma que la de EasyOCR no soporta, incluso cuando ambos reconocedores de texto fallan a nivel de caracteres. El F1 de campo 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, una paradoja que persiste en ambos conjuntos de datos. CORD se cita aquí como contexto de robustez lingüística; deliberadamente nunca se agrupa con los números de SROIE en una única tabla de clasificación.

Tabla: summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) y field_method_comparison.csv (F1 de campo), filas cord_v2. No combine los números de CORD en ninguna clasificación de SROIE: el CER de CORD combina un desajuste lingüístico genuino con la inflación de la estructura de anotación en la verdad de referencia. Los patrones de regex se escribieron para formatos en inglés, por lo que el F1 de campo con regex cae a ~0–2% en ambos motores. El F1 de campo con LLM de PaddleOCR de 0.5527 en CORD repite su ventaja en SROIE (0.5810 frente a 0.3717) — su recuperación posterior con LLM sobrevive al choque de idioma que el de EasyOCR no.

Quién gana cuándo: la cuadrícula de resumen

“Mejor” depende de la carga de trabajo, y este cara a cara divide los ejes con claridad: cada eje de precisión en recibos en inglés favorece a PaddleOCR; el costo, el rendimiento de reloj, la latencia de cola y la simplicidad de implementación favorecen a EasyOCR; y el campeonato de precisión de texto bruto no pertenece a ninguno (Surya2/docTR) — mientras que el resultado posterior con 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 con postprocesado LLM 0.5810 vs 0.3717 (summary_metrics.csv y field_method_comparison.csv, filas sroie_2019). Ningún motor 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 la misma RTX 4090 a $0.76/hora 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 cada 1,000 páginas.

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

Depende de qué reloj quiera decir. PaddleOCR tiene menor latencia mediana en estado estable (297.0 vs 413.6 ms p50), pero EasyOCR tiene mayor rendimiento en tiempo de pared (124.5 vs 79.7 páginas/min) porque las páginas/min en tiempo de pared incluyen la inicialización del modelo y efectos de lote, y el runtime más ligero de EasyOCR carga más rápido (summary_metrics.csv, latency_p50_ms / pages_per_minute, filas sroie_2019). Para un pipeline cálido de larga duración, PaddleOCR es más rápido por página; para muchos lotes fríos pequeños o frecuentes, EasyOCR gana la carrera de tiempo de pared.

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

Esta es la paradoja documentada del benchmark, actualmente sin mecanismo probado. El CER de EasyOCR en SROIE (0.2833) ocupa el cuarto lugar de ocho motores, pero su F1 de campos con postprocesado 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 cómo EasyOCR dispone o une líneas de texto que degrada la extracción LLM posterior; se etiqueta como un patrón observado y reproducible con el mecanismo sin verificar (field_method_comparison.csv, llm_field_value_f1, filas sroie_2019).

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

Dos causas que se combinan y que el protocolo mantiene separadas de la clasificación SROIE: un desajuste lingüístico real (recibos indonesios fuera del enfoque de entrenamiento de ambos motores) y una inflación en la estructura de anotaciones dentro del texto de referencia de CORD — el CER se sitúa en 0.9083 (PaddleOCR) y 0.9185 (EasyOCR) (summary_metrics.csv, cer, filas de cord_v2). Lo que aún los separa es la recuperación posterior con LLM: PaddleOCR 0.5527 frente a EasyOCR 0.3378 en F1 de campos — el patrón de SROIE persiste incluso cuando ambos reconocedores fallan a nivel de caracteres.

¿Qué motor debería elegir un pipeline de recibos, PaddleOCR o EasyOCR?

Si su pipeline consume campos — valores extraídos para empresa, fecha, totales — PaddleOCR es la opción clara por defecto en recibos: 2,2× F1 de campos con regex, 1,56× con un LLM, y una recuperación posterior con LLM que sobrevive al choque lingüístico de CORD (field_method_comparison.csv). Si necesita volumen masivo económico, una cola de peor caso ajustada, una pila ligera o una amplia cobertura de idiomas para empezar, EasyOCR es genuinamente competitivo en el eje operativo (2× más barato, 1,56× rendimiento en tiempo real, p95 3,5× más ajustado, más de 80 idiomas) — pero presupueste su débil postprocesamiento con LLM antes de comprometerse. Estos resultados se mantienen para recibos en inglés e indonesio en un nivel de GPU en agosto de 2026; vuelva a ejecutar las pruebas en su corpus objetivo antes de tomar decisiones de producción (ver Limitaciones).

¿De dónde provienen los números de 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 con regex, latencia, costo, rendimiento) y results/field_method_comparison.csv (regex frente a postprocesamiento con LLM, llm_model = deepseek-v4-flash) — alojados en ImageToTableai/benchmark-ocr, con un manifest.json redactado por ejecución para las huellas del entorno. Las definiciones de los conjuntos de datos provienen de los artículos de SROIE 2019 y CORD citados a continuación.

Metodología y fuentes

Protocolo

Esta página presenta un extracto comparativo directo de una ejecución independiente y reproducible de benchmark (nivel oficial) — no es un sondeo de afirmaciones de terceros, ni una página de comparación de proveedores. Solo divisiones de prueba fijas: prueba de SROIE 2019 (361 recibos en inglés, campos planos empresa/fecha/dirección/total) y prueba de CORD v2 (100 recibos en indonesio, campos anidados menú/sub_total/total); las divisiones de entrenamiento nunca fueron evaluadas. Ambos motores vieron las mismas imágenes, el mismo ground truth y el mismo protocolo de medición (warm_then_scored: una pasada de calentamiento fija precede a la pasada evaluada, de modo que las cifras de latencia están en estado estable). Ambas ejecuciones se 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 solo compara los dos motores nombrados, y otros motores se citan únicamente 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ó a la tarifa on-demand de RunPod de $0.76/h, con el precio con marca de tiempo en el manifiesto redactado de cada ejecución (agosto de 2026).
• Motores: de fábrica, sin ajuste fino. Versiones fijadas: PaddleOCR 3.7.0 (OCR moderno de aprendizaje profundo en dos etapas — detección PP-OCR + reconocimiento, GPU) y EasyOCR 1.7.2 (ResNet+CRNN clásico 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 de SROIE de EasyOCR se verificó nuevamente en una re-ejecución de torch 2.8 del 2026-08-17 (las repeticiones r1/r2/r3 byte-idénticas); los CSV publicados contienen esos valores corregidos.
• Postprocesador LLM: deepseek-v4-flash vía API a temperatura 0 para una salida determinista (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 de pared × $0.76/h, incluida la inicialización del modelo — el procesamiento por lotes reduce el costo por página.
• Postprocesamiento de campos: las métricas de campo con regex de SROIE son postprocessed_sroie_receipt_regex_* (columnas regex_* de field_method_comparison.csv) — campos extraídos del texto de OCR mediante un conjunto fijo de patrones. Miden OCR + extracción posterior, no salida estructurada nativa de ninguno de los modelos; las columnas LLM_* miden texto de OCR + extracción con LLM. Los dos flujos nunca se mezclan.

Definiciones de métricas

• CER (tasa de error de caracteres): distancia de edición (inserciones + eliminaciones + sustituciones) entre el texto de OCR y la verdad de referencia, dividida por los caracteres de la verdad de referencia. Cuanto menor, mejor.
• WER (tasa de error de palabras): el mismo cálculo de distancia de edición a nivel de palabra.
• F1 de valor de campo (regex): media armónica de precisión/recuperación sobre los valores de campo extraídos usando patrones regex fijos en el texto de OCR (pipeline tradicional de OCR + KIE basado en reglas). Columna: regex_field_value_f1. Una puntuación de 0 significa que no se recuperó ningún valor de campo.
• F1 de valor de campo (LLM): la misma métrica sobre la salida del postprocesador LLM (texto de OCR → deepseek-v4-flash → campos). Columna: llm_field_value_f1. Los dos pipelines son diferentes y nunca se combinan.
• Exactitud de campos de documento: fracción de documentos donde todos los campos objetivo coincidieron exactamente — un estándar 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 (medido en caliente, excluye la carga del modelo) y rendimiento en tiempo de reloj incluyendo la inicialización del modelo. Miden relojes diferentes; la inversión p50 vs. páginas/min en esta página es una diferencia del modelo de medición, no un error.
• Costo por 1,000 páginas: horas de GPU facturadas por 1,000 páginas a la tarifa registrada de $0.76/hora, 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 valor de campo regex/llm, exactitud de campos de documento, 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 paradoja).
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 ejecución publicada (16 ejecuciones) con versiones de modelo, GPU/controlador, versiones de torch/CUDA/Python, metadatos de costo 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 diseño/table/documento de PP-Structure de PaddleOCR, la amplitud de más de 80 idiomas de EasyOCR en texto que no sea de recibos, ni ningún otro tipo de documento. No use 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 de campo y el CER dependen del corpus; diferencias de un solo dígito de unas pocas centésimas deben tratarse como ruido, no como verdad de ingeniería — aunque las brechas documentadas aquí (27.8% CER, 2.2× F1 de regex) están muy por fuera de ese rango.
• Un solo nivel de GPU y un solo precio: todos los números provienen de una RTX 4090 a $0.76/hora, precio con marca de tiempo de agosto de 2026 en los manifiestos de ejecución. Otras GPU, servicio multi-GPU, programación por lotes o cambios de precio alterarán la latencia, el rendimiento y el costo — vuelva a calcular los costos a las tarifas actuales antes de presupuestar.
• Un solo posprocesador LLM: todas las filas de LLM usan deepseek-v4-flash a temperatura 0. Un LLM diferente cambia el F1 de campo absoluto; la magnitud de la paradoja de EasyOCR puede variar con el LLM, aunque el patrón observado se mantuvo para este único posprocesador en ambos conjuntos de datos. La latencia del LLM (~1,817–2,005 ms de mediana en SROIE, field_method_comparison.csv llm_median_latency_ms) es incurrida por la API y no forma parte de la latencia propia de ninguno de los dos motores.
• Mecanismo de la paradoja de EasyOCR no verificado: el benchmark documenta que el texto CER de nivel medio de EasyOCR produce la peor recuperación de campos posterior al 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 probada de la biblioteca.
• Ajuste de regex: el conjunto de patrones se escribió una vez por conjunto de datos. Una biblioteca de patrones muy ajustada por formato podría obtener puntuaciones más altas en sus propios diseños — al costo de mantenimiento que el LLM elimina.
• El CER de CORD no es una lectura de calidad por modelo: la verdad fundamental de CORD incorpora la estructura de anotación y ninguno de los dos motores fue entrenado predominantemente en indonesio; el CER de CORD (~0.91) refleja el desajuste de idioma + la inflación de la verdad fundamental. Las filas de CORD se citan con contexto y nunca se fusionan en ninguna clasificación de SROIE (regla del protocolo).
• Fijación de versiones: los resultados corresponden a PaddleOCR 3.7.0 y EasyOCR 1.7.2 (agosto de 2026). Las versiones más recientes de cualquiera de los dos motores pueden cambiar cada número de esta página.

Referencias relacionadas: Benchmark de recibos docTR vs Surya2 · el cara a cara OCR vs VLM · reglas de regex frente a extracción con LLM · precisión de caracteres frente a precisión de campos · Precisión de OCR de recibos

Lectura relacionada: cómo se compara el OCR con IA con el OCR clásico · extracción de imágenes con IA comparada con el OCR tradicional · Precios de extracción de documentos con IA (2026)