EasyOCR vs docTR en recibos
Campeón de velocidad vs extractor de campos (2026)

Los dos motores representan dos generaciones de OCR de aprendizaje profundo, ambos en el lado tradicional de la división OCR frente a VLM. 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, con refinamiento basado en atención. Su centro de diseño es una cobertura muy amplia de idiomas y escrituras (más de 80 idiomas de serie) y una instalación famosamente simple. docTR (v1.0.1) es un pipeline neuronal moderno de dos etapas: una etapa de detección localiza regiones de texto, luego una etapa de reconocimiento las transcribe — construido en torno a la detección por transformadores estilo DETR y un reconocedor por transformadores, diseñado para precisión en documentos impresos. La tasa de error por carácter (CER) mide inserciones, eliminaciones y sustituciones divididas por los caracteres de referencia — una CER de 0.197 significa ~19,7 caracteres mal leídos por cada 100; la tasa de error por palabra (WER) aplica la misma lógica de distancia de edición a nivel de palabra completa. Menor es mejor en ambas. Ninguno de los dos motores es un modelo de lenguaje visual (VLM) — ambos generan texto sin formato, no estructura comprendida.

Precisión de texto en SROIE (recibos en inglés): la clara ventaja de docTR

En los 361 recibos en inglés del split de prueba de SROIE 2019, la arquitectura moderna gana en ambas métricas de texto: CER 0.1971 frente a 0.2833 (mejora relativa del 30%) y WER 0.3199 frente a 0.6158 — el WER de EasyOCR es casi el doble. La brecha de WER (48%) es mucho mayor que la de CER (30%), lo que apunta a que EasyOCR acumula errores a nivel de carácter 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). Ninguno de los dos motores es el campeón general de CER del benchmark — ese título pertenece a Surya2 (0.1915) y docTR mismo ocupa el segundo lugar; EasyOCR ocupa el cuarto de ocho.

Fuente: summary_metrics.csv — columnas cer y wer, filas sroie_2019. docTR cer 0.19707 / wer 0.31990; EasyOCR cer 0.28327 / wer 0.61578. Menor 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: docTR cer 0.19707 / wer 0.31990; EasyOCR cer 0.28327 / wer 0.61578. Diferencias relativas: CER 30% menor, WER 48% menor para docTR. Un CER/WER más bajo es mejor. Contexto de clasificación CER dentro de la misma ejecución de 8 motores: Surya2 0.1915, docTR 0.1971, PaddleOCR 0.2045, EasyOCR 0.2833 (summary_metrics.csv, cer, filas sroie_2019).

La inversión de campos por regex: peor texto, más campos recuperables

Compara el texto sin procesar de ambos motores con los mismos patrones regex fijos en los cuatro campos de los recibos SROIE (empresa, fecha, dirección, total) — el enfoque tradicional de OCR + extracción de información clave (KIE) basada en reglas — y la clasificación se invierte: EasyOCR extrae campos con 0.1477 de F1 de campo frente al 0.0766 de docTR, una ventaja de 1.93× para el motor con peor precisión de caracteres. Esta es la inversión recurrente del benchmark de "precisión de texto ≠ precisión de campo" — el mismo patrón observado entre el OCR tradicional y los VLM de análisis de documentos en docTR vs Surya2 — ahora ocurriendo entre dos motores tradicionales que producen el mismo tipo de texto de línea sin procesar.

El F1 de valor de campo es la media armónica de precisión y exhaustividad 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 que nada. El mecanismo detrás de la inversión es una propiedad del conjunto de patrones regex, no de la calidad del reconocimiento en sí: los patrones se escribieron una vez por conjunto de datos para valores formateados como RM 12.00 o 14/08/2020. El texto de línea limpio pero sin procesar de docTR — preciso según CER, pero que conserva las mayúsculas originales y el ruido de separadores — vence a los patrones fijos; la salida de EasyOCR coincide con ellos con más frecuencia. Las columnas de "extracción de campos por regex" son las métricas postprocessed_sroie_receipt_regex_* del benchmark: miden texto OCR + extracción posterior basada en reglas, no salida estructurada nativa. Una biblioteca de patrones muy ajustada por formato podría puntuar de manera diferente para cualquiera de los motores — el conjunto de patrones es un instrumento de medición fijo, no un analizador de producción ajustado.

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, filas sroie_2019. Estas son métricas postprocessed_sroie_receipt_regex_*: patrones fijos aplicados al texto OCR de cada motor (posprocesado, no extracción nativa). El F1 de campo con regex de docTR, 0.0766, es el segundo más bajo de los ocho motores en la ejecución subyacente, a pesar de tener el segundo mejor CER — el conjunto de patrones se escribió una vez por conjunto de datos, y el texto de línea limpio pero sin procesar de docTR no es compatible con regex en estos cuatro campos.

La palanca del LLM: el giro se invierte, de forma decisiva

Si alimentas ambos motores con el texto OCR de un posprocesador LLM (deepseek-v4-flash a temperatura 0) con un prompt de extracción estructurada, la clasificación de campos se invierte de nuevo — con el mayor margen de cualquier emparejamiento del benchmark: docTR 0.6171 frente a EasyOCR 0.3717 en F1 de campo, una diferencia de 1.66×. El resultado de docTR es el F1 de campo LLM más alto de los ocho motores; el de EasyOCR es el más bajo. Donde el patrón de regex penalizaba el texto limpio de docTR, el LLM lo recompensa — y el texto de nivel medio de EasyOCR, que casualmente era compatible con regex, se degrada bajo el mismo prompt.

Este es el mismo patrón de convergencia con LLM observado en el benchmark completo de ocho motores — el posprocesamiento con LLM lleva a los motores saludables a una banda de F1 de campo de 0.57–0.62 porque entiende la semántica (números, fechas, nombres) en lugar de comparar formas de caracteres — con EasyOCR como la excepción más marcada. La palanca no es gratuita: una llamada al LLM añade aproximadamente 2.0–2.1 s de latencia mediana por documento además del tiempo de OCR (1,996.3 ms para el texto de docTR, 2,004.5 ms para el de EasyOCR, incurrida por la API e idéntica en naturaleza), y no rescata texto que un motor no logró leer en absoluto. Pero para este emparejamiento, el posprocesador se convierte en el componente decisivo: con un LLM en el pipeline, la elección de docTR se potencia.

Tabla: field_method_comparison.csv — columnas llm_*, filas sroie_2019. Modelo LLM: deepseek-v4-flash a temperatura 0 (columna llm_model). La latencia del LLM la incurre la API y es independiente de la latencia del motor (summary_metrics.csv latency_p50_ms). «Campos exactos por documento» 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 EasyOCR-LLM: texto de nivel medio, la peor extracción posterior

El dato más contraintuitivo de este cara a cara — documentado por primera vez en PaddleOCR vs EasyOCR y confirmado aquí contra un oponente distinto: el texto OCR de EasyOCR queda en la mitad de la tabla por precisión de caracteres (CER SROIE 0.2833, cuarto de ocho motores) — pero cuando ese texto se pasa al mismo posprocesador LLM usado para todos los demás motores (deepseek-v4-flash, mismo prompt, mismos recibos), su F1 de valor de campo LLM en 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 eran 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: cómo EasyOCR dispone, une o separa las 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 de 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. El texto base más limpio de docTR + el LLM aterriza en la parte superior de la misma banda que EasyOCR no alcanza.

Fuente: field_method_comparison.csv — llm_field_value_f1, las ocho filas de 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 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 0.6171 de docTR es el F1 de campo LLM más alto del benchmark; 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 está aislado por este benchmark.

El Envolvente Operativo: docTR Es el Campeón de Velocidad Y Costo del Benchmark

La precisión decide qué motor lee mejor; el envolvente operativo decide cuál termina. En la misma RTX 4090 a la misma tarifa registrada de $0.76/hora, docTR mantiene 449.3 páginas/min a 108.7 ms p50 por página por $0.048 por 1,000 páginas; EasyOCR mantiene 124.5 páginas/min a 413.6 ms p50 por $0.110 por 1,000 páginas — una brecha de latencia de 3.8×, una brecha de rendimiento de 3.6× y una brecha de costo de 2.3×, todas a favor de docTR. En la ejecución completa de ocho motores, los 108.7 ms p50, 449.3 páginas/min y $0.048 de costo de docTR son cada uno los mejores de cualquier motor medido — docTR es simultáneamente el motor más rápido y más barato del benchmark.

El costo se calcula como tiempo de ejecución 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 es páginas por minuto de tiempo de pared incluyendo esa misma inicialización. La latencia p50/p95 son tiempos de inferencia por página en estado estable medidos en caliente y luego puntuados (excluyendo la carga del modelo); la cola de EasyOCR es proporcionalmente peor — 960.4 ms p95 frente a los 281.4 ms de docTR, una brecha de 3.4×. EasyOCR sigue siendo genuinamente más barato que la mayoría de los otros motores medidos (su $0.110 es la segunda cifra más baja por 1,000 páginas en el benchmark, solo detrás de docTR) — es de costo medio y velocidad media, no caro ni lento.

Fuente: summary_metrics.csv — columnas latency_p50_ms / latency_p95_ms, filas sroie_2019. docTR p50 108.72 / p95 281.38; 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. docTR 0.0479, EasyOCR 0.1098. Costo = tiempo de ejecución de pared × $0.76/hora incluyendo la inicialización del modelo, precio con marca de tiempo en los manifiestos de ejecución (agosto de 2026). El $0.048 de docTR es el costo más bajo por 1,000 páginas de cualquier motor en el benchmark; el $0.110 de EasyOCR es el segundo más bajo (summary_metrics.csv, cost_per_1000_pages, todas las filas 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, no solo el rendimiento de estado estable. Valores exactos: docTR p50 108.72 / p95 281.38 / 449.31 pg/min / $0.0479; EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098. Mejores resultados del benchmark: docTR tiene la latencia p50 más baja, el mayor número de páginas por minuto y el menor costo de los ocho motores (summary_metrics.csv, filas sroie_2019).

CORD (recibos indonesios): ambos fallan en texto, la brecha del LLM se amplía

Ningún motor fue entrenado predominantemente con 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 fallan en CER bruto: 0.9101 (docTR) 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 aislados de la comparación SROIE — no se fusionan en ninguna clasificación — porque el texto de referencia de CORD incorpora estructura de anotación, lo que infla el CER bruto de cada motor además del genuino desajuste de idioma.

Las métricas de campo muestran el patrón de SROIE extendiéndose — y ampliándose. A través del posprocesador LLM, el F1 de campo de docTR se mantiene en 0.5500 frente al 0.3378 de EasyOCR en CORD — una brecha de 1.63×, el mismo orden que el 1.66× de SROIE, incluso cuando ambos reconocedores de texto fallan a nivel de carácter. A través de patrones regex, docTR no recupera ningún campo (0.0000 de F1 de campo — un cero literal en el CSV, no un valor faltante) porque los patrones de formato en inglés no coincidieron con nada en el texto indonesio, mientras que EasyOCR obtiene 0.0067. La ventaja de costo de docTR también se reduce y se invierte en CORD ($0.094 frente a $0.086 de EasyOCR por cada 1,000 páginas) — pero su ventaja de rendimiento en tiempo real crece a 500.4 frente a 211.8 páginas/min (2.4×). CORD se cita aquí para contextualizar la robustez del idioma; deliberadamente nunca se combina con los números de SROIE en una única tabla de clasificación.

Tabla: summary_metrics.csv (cer / pages_per_minute / cost_per_1000_pages) y field_method_comparison.csv (F1 de campo), filas de cord_v2. No combines los números de CORD en ninguna clasificación de SROIE: el CER de CORD combina un desajuste lingüístico real con una inflación de la estructura de anotaciones en la verdad de referencia. Los patrones de regex se escribieron para formatos en inglés, por eso el F1 de campo con regex cae a ~0–1% en ambos motores; el 0.0000 de docTR es un cero literal registrado en el CSV, no un valor faltante. La brecha de F1 de campo con LLM (0.5500 vs 0.3378) extiende el patrón de SROIE entre idiomas; el orden de costos se invierte (EasyOCR $0.086 vs docTR $0.094) mientras que la brecha de rendimiento se amplía (2.4×).

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: la precisión de texto bruto, los campos posteriores a LLM, la velocidad, el rendimiento y el costo favorecen a docTR; la extracción de campos con regex fija y la historia de implementación favorecen a EasyOCR — con la salvedad de que el resultado posterior a LLM de EasyOCR es su mayor riesgo, no su punto fuerte.

Preguntas frecuentes

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

Sí, en todos los ejes de precisión de texto sin procesar y de extracción de campos en este benchmark. En SROIE 2019: CER 0,1971 frente a 0,2833 (un 30 % menos), WER 0,3199 frente a 0,6158 (un 48 % menos), F1 de campo posprocesado por LLM 0,6171 frente a 0,3717 (1,66×, el mejor de 8 frente al peor de 8) — pero no en el F1 de campo por regex, donde EasyOCR gana 0,1477 frente a 0,0766 (summary_metrics.csv y field_method_comparison.csv, filas de sroie_2019). Ningún motor es el campeón general de CER del benchmark: Surya2 (0,1915) tiene ese título por un margen mínimo sobre docTR.

¿Por qué docTR tiene mejor precisión de texto pero peor extracción de campos por regex que EasyOCR?

Porque las dos métricas evalúan resultados distintos con un mismo instrumento de medición fijo. docTR devuelve texto sin procesar limpio de línea — preciso según CER, pero conservando mayúsculas y separadores originales — y los patrones regex fijos, escritos una vez por conjunto de datos para valores con formato, fallan en su mayoría contra ese texto: F1 de campo por regex en SROIE 0,0766 (field_method_comparison.csv, regex_field_value_f1, fila doctr/sroie_2019). El resultado de EasyOCR coincide con los patrones en 0,1477. Si se pasan ambos a un LLM, la brecha se invierte a 1,66× a favor de docTR: el conjunto de patrones regex, no el OCR, era el cuello de botella.

¿Por qué EasyOCR tiene la peor extracción de campos con 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 puesto de ocho motores, pero su F1 de campo posprocesado por LLM (0,3717) ocupa el último — 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 las líneas de texto que degrada la extracción posterior con LLM; está etiquetada como un patrón observado y reproducible con el mecanismo sin verificar (field_method_comparison.csv, llm_field_value_f1, filas de sroie_2019). La misma paradoja está documentada contra otro rival en PaddleOCR vs EasyOCR.

¿Cuánto más rápido y barato es docTR que EasyOCR?

3,8× menor latencia p50 (108,7 vs 413,6 ms), 3,4× menor p95 (281,4 vs 960,4 ms), 3,6× mayor rendimiento (449,3 vs 124,5 páginas/min) y 2,3× menor costo por 1.000 páginas ($0,048 vs $0,110) en la misma RTX 4090 a $0,76/hora (summary_metrics.csv, latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, filas sroie_2019). docTR es el motor más rápido y barato del benchmark en los tres relojes; EasyOCR es de costo medio (el segundo más barato) y de velocidad media (el segundo rendimiento más rápido).

¿Por qué ambos motores puntúan tan mal en recibos CORD?

Dos causas que se combinan y que el protocolo del benchmark mantiene separadas de la clasificación SROIE: un desajuste de idioma genuino (recibos indonesios fuera del enfoque de entrenamiento de ambos motores) y una inflación de la estructura de anotación dentro del texto de referencia de CORD — la CER se sitúa en 0,9101 (docTR) y 0,9185 (EasyOCR) (summary_metrics.csv, cer, filas cord_v2). Lo que aún los separa es la recuperación posterior con LLM: docTR 0,5500 vs EasyOCR 0,3378 en F1 de valor de campo — el patrón SROIE persiste y se amplía incluso cuando ambos reconocedores fallan a nivel de carácter.

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

Para un pipeline cuyo objetivo es campos extraídos a gran volumen con costo medido, docTR domina en este corpus: mejor texto bruto (30% menos CER), los mejores campos posteriores con LLM de cualquier motor (0,6171 vs 0,3717) y una ventaja de costo de 2,3×, rendimiento de 3,6×, latencia de 3,8× — los cuatro ejes a la vez (summary_metrics.csv / field_method_comparison.csv, filas sroie_2019). EasyOCR sigue siendo una opción legítima para OCR masivo multiescritura barato, fácil de instalar y en documentos limpios donde la extracción con regex o el texto bruto a volumen moderado es la tarea y la calidad de los campos posteriores con LLM importa menos — pero presupuesta su débil LLM posterior medido antes de comprometerte. Estos resultados se mantienen para recibos en inglés e indonesio en un nivel de GPU en agosto de 2026; vuelve a ejecutarlos en tu corpus objetivo antes de decisiones de producción (ver Limitaciones).

¿De dónde salen 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 regex por campo, latencia, costo, rendimiento) y results/field_method_comparison.csv (postprocesamiento con regex vs. 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 abajo.

Metodología y fuentes

Protocolo

Esta página informa un segmento comparativo directo de una ejecución de benchmark independiente y reproducible (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 company/date/address/total) y prueba de CORD v2 (100 recibos en indonesio, campos anidados menu/sub_total/total); las divisiones de entrenamiento nunca se evaluaron. Ambos motores vieron las mismas imágenes, la misma verdad de campo y el mismo protocolo 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). 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 compara solo los dos motores nombrados, y los demás 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 bajo demanda de RunPod de $0.76/hora, con el precio con marca de tiempo en el manifest redactado de cada ejecución (agosto de 2026).
• Motores: listos para usar, sin ajuste fino. Versiones fijadas: EasyOCR 1.7.2 (reconocedor clásico CNN + RNN + CTC, extractor de características ResNet, GPU) y docTR v1.0.1 (OCR neuronal moderno de dos etapas — detección con transformador estilo DETR + reconocimiento, GPU) — según la tabla de modelos del repositorio público (README.md) y los manifests de ejecución. La fila de SROIE de EasyOCR se volvió a verificar en una reejecución de torch 2.8 del 2026-08-17 (ejecuciones repetidas r1/r2/r3 byte-idénticas); los CSV publicados llevan esos valores corregidos.
• Postprocesador LLM: deepseek-v4-flash vía API a temperatura 0 para 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/hora, incluida 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 de OCR mediante un conjunto de patrones fijos escrito una vez por conjunto de datos. 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 pipelines nunca se mezclan.

Definición de métricas

• CER (tasa de error por carácter): distancia de edición (inserciones + eliminaciones + sustituciones) entre el texto del OCR y la verdad de referencia, dividida por los caracteres de la verdad de referencia. Cuanto más bajo, mejor.
• WER (tasa de error por palabra): 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/exhaustividad sobre los valores de campo extraídos mediante patrones regex fijos aplicados al texto del 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 posprocesador LLM (texto del OCR → deepseek-v4-flash → campos). Columna: llm_field_value_f1. Los dos pipelines son diferentes y nunca se combinan.
• Exactitud de campos del documento: fracción de documentos en los que 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 (con calentamiento previo y luego puntuado, excluye la carga del modelo) y rendimiento en tiempo real que incluye la inicialización del modelo. Miden relojes distintos.
• Costo por cada 1.000 páginas: horas de GPU facturadas por 1.000 páginas a la tarifa registrada de $0,76/hora, incluida 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 cifra de CER/WER, latencia, costo y rendimiento de esta página proviene de las filas easyocr y doctr de este archivo.
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 del documento, llm_median_latency_ms, recuentos de tokens. Cada cifra de F1 de campo regex/LLM proviene de las filas easyocr y doctr de este archivo (y de las ocho filas sroie_2019 de 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 su 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 del 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 de esto mide la cobertura de los 80+ idiomas de EasyOCR en texto que no sea de recibos, el comportamiento de docTR en tablas, formularios o documentos largos, ni ningún otro tipo de documento. No uses esta página para concluir que un motor “gana en todo”.
• Tamaño de la muestra: 361 recibos en inglés + 100 en indonesio. La F1 por campo y la CER dependen del corpus; diferencias de solo algunas centésimas deben tratarse como ruido, no como verdad de ingeniería — aunque las brechas documentadas aquí (30% de CER, 48% de WER, 1,66× en F1 del LLM) están mucho más allá de ese rango.
• Un solo nivel de GPU y un solo precio: todos los números provienen de una RTX 4090 a $0.76/h, con precio con fecha de agosto de 2026 en los manifiestos de ejecución. Otras GPU, servidores multi-GPU, programación por lotes o cambios de precio alterarán la latencia, el rendimiento y el costo — recalcula los costos a las tarifas actuales antes de presupuestar.
• Un solo postprocesador LLM: todas las filas de LLM usan deepseek-v4-flash con temperatura 0. Un LLM diferente cambia la F1 absoluta de campos; la magnitud de la paradoja de EasyOCR puede moverse con el LLM, aunque el patrón observado se mantuvo para este único postprocesador en ambos conjuntos de datos. La latencia del LLM (~2,0–2,1 s de mediana en SROIE, llm_median_latency_ms en field_method_comparison.csv) la impone 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 de nivel medio de EasyOCR produce la peor recuperación de campos aguas abajo con LLM (0.3717 en SROIE / 0.3378 en CORD) — un resultado observado y reproducible bajo la hipótesis de las convenciones de diseño del texto de salida, sin aislar explícitamente el mecanismo causal. Trátalo como un resultado medido para planificar en torno a él, no como una propiedad probada de la librería.
• Ajuste de expresiones regulares: el conjunto de patrones se escribió una vez por conjunto de datos. Una biblioteca de patrones muy ajustada por formato podría puntuar más alto en sus propios diseños — al costo de mantenimiento que el LLM elimina. La desventaja de docTR en campos regex (0.0766 vs. 0.1477) es una propiedad de este instrumento fijo, no una afirmación sobre lo que un parser ajustado podría recuperar.
• La CER de CORD no es una lectura de calidad por modelo: la verdad de referencia de CORD incorpora estructura de anotaciones y ninguno de los dos motores se entrenó predominantemente en indonesio; la CER de CORD (~0,91) refleja desajuste de idioma + inflación de la verdad de referencia. Las filas de CORD se citan con contexto y nunca se fusionan en ninguna clasificación de SROIE (regla del protocolo).
• Solo dos motores: este enfrentamiento excluye deliberadamente a los otros seis motores de la ejecución subyacente, los servicios de OCR en la nube/API y las API de VLM alojadas; sus modelos de latencia y precios difieren fundamentalmente de los motores locales medidos aquí.
• Fijación de versiones: los resultados corresponden a EasyOCR 1.7.2 y docTR v1.0.1 (agosto de 2026). Las versiones más recientes de cualquiera de los motores pueden cambiar todos los números de esta página.

Referencias relacionadas: Benchmark de recibos de PaddleOCR vs EasyOCR · Benchmark de recibos de docTR vs Surya2 · OCR tradicional vs VLM de análisis de documentos · coincidencia de patrones vs extracción de campos basada en modelos · medir la precisión por campo, no por carácter · Costo de OCR por cada 1,000 páginas

Lecturas relacionadas: por qué la precisión de la OCR con IA difiere de la OCR tradicional · por qué la extracción con IA supera a la OCR en imágenes · Precios de Extracción de Documentos con IA (2026)