Tesseract vs PaddleOCR en Recibos
CPU Heredado vs GPU Moderno (2026)

Qué son los dos motores: 35 años de OCR frente a una canalización CNN de dos etapas

Toda la historia de esta página es una brecha arquitectónica. Tesseract es el motor OCR clásico de código abierto — desarrollado originalmente en HP en la década de 1980 y de código abierto por Google en 2005, por lo que tiene aproximadamente 35 años de linaje. Su canalización es visión por computadora tradicional: binarización adaptativa, segmentación de página, análisis de componentes conectados y reconocimiento de caracteres — basado en LSTM desde la versión 4 — todo ejecutándose en CPU sin facturación de GPU en esta referencia (compute_type = cpu en el CSV). PaddleOCR es un motor moderno de aprendizaje profundo del ecosistema PaddlePaddle: una canalización de dos etapas en la familia PP-OCR — una etapa de detección que localiza regiones de texto (estilo DBNet), luego una etapa de reconocimiento que las transcribe — ejecutándose en GPU. Un motor lee emparejando formas de caracteres con patrones aprendidos; el otro lee aprendiendo dónde está el texto y qué dice. Esta referencia pone ambos a través de los mismos recibos, mismo protocolo, misma máquina.

Por qué importa este mecanismo: el enfoque de Tesseract es barato de ejecutar y no necesita GPU — pero su modelo de caracteres está congelado en décadas de reconocimiento clásico, lo que se manifiesta como un techo duro en la calidad del texto. El enfoque de PaddleOCR cuesta tiempo de GPU pero lee texto sustancialmente más limpio. El trabajo de la referencia es poner un número en ambos lados de esa compensación a partir de una ejecución controlada — y la sorpresa es lo estrecho que resultó ser el lado de costos operativos de la compensación.

Precisión de caracteres: La arquitectura moderna gana en todas las métricas de texto

En SROIE 2019, la brecha de precisión de texto es grande y unilateral: CER 0.2045 frente a 0.3347 (Tesseract) — una mejora relativa del 39% — y WER 0.3256 frente a 0.5591, una brecha relativa del 42%. El CER de Tesseract de 0.3347 ocupa el quinto lugar de los ocho motores en la ejecución subyacente — en medio del paquete, no último — pero cada motor por encima de él excepto uno es un motor de aprendizaje profundo, y la brecha entre Tesseract y el nivel de aprendizaje profundo (mejor: Surya2 0.1915, docTR 0.1971) es mayor que la brecha entre esos motores y PaddleOCR (0.2045, tercero).

La tasa de error de caracteres (CER) es la medida clásica de OCR: inserciones, eliminaciones y sustituciones divididas por caracteres de verdad fundamental — un CER de 0.335 significa aproximadamente 33.5 caracteres mal leídos por cada 100. La tasa de error de palabras (WER) aplica el mismo cálculo de distancia de edición a granularidad de palabra. Ambos son menores es mejor. La brecha de WER (42%) siendo más amplia que la brecha de CER (39%) significa que los deslices de caracteres de Tesseract se combinan en fallas de palabras completas en este corpus — el modo de falla del motor clásico que un extractor de campos posterior hereda directamente.

Fuente: summary_metrics.csv — columnas cer y wer, filas sroie_2019. PaddleOCR cer 0.20449 / wer 0.32563; Tesseract cer 0.33468 / wer 0.55915. 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: Tesseract cer 0.33468 / wer 0.55915; PaddleOCR cer 0.20449 / wer 0.32563. Un CER/WER más bajo es mejor. Contexto de clasificación del mismo CSV: El CER de SROIE en los ocho motores es surya2 0.1915, doctr 0.1971, PaddleOCR 0.2045 (3º), easyocr 0.2833, Tesseract 0.3347 (5º), paddleocr_vl 0.3370, docling 0.5909, unlimited_ocr 0.6552. Ninguno de los dos motores aquí es el campeón de precisión del benchmark — docTR y Surya2 ocupan los dos primeros puestos en CER.

Extracción de Campos: La Brecha que Decide las Decisiones de Producción

La precisión del texto clasifica 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. A través de regex, PaddleOCR extrae campos con 0.3254 campo F1 frente a 0.2335 de Tesseract — una ventaja de 1.39×; a través del LLM, la brecha persiste con 0.5810 frente a 0.4389 (1.32×). La ventaja del LLM ayuda a ambos motores, pero parte de la base más débil de Tesseract — y el argumento del techo que decide los flujos de producción está en la siguiente sección.

El F1 de campo-valor 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 regex de campo 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. Contexto de clasificación: el F1 de regex de PaddleOCR de 0.3254 es el mejor entre los cuatro motores puramente tradicionales en el benchmark de 8 motores (solo por detrás de Unlimited-OCR 0.3376 y PaddleOCR-VL 0.3368); el 0.2335 de Tesseract es el cuarto mejor resultado de regex en general (summary_metrics.csv, field_f1_regex, filas sroie_2019) — el motor clásico es un extractor de campos de nivel intermedio en texto inglés limpio, que es precisamente donde deja de ser competitivo.

Fuente: field_method_comparison.csv — columnas regex_field_value_f1 / llm_field_value_f1, filas sroie_2019 (decimales almacenados 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 separada de la latencia del motor (latencia_p50_ms en summary_metrics.csv). “Docs 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. Contexto de clasificación (llm_field_value_f1, todas las filas sroie_2019): PaddleOCR 0.5810 ocupa el 5.º puesto de 8; Tesseract 0.4389 el 7.º, por delante solo de EasyOCR’s 0.3717.

La Sorpresa: Paridad de Rendimiento CPU en Tiempo Real

El hallazgo destacado de la página es el que ninguna comparación de terceros documenta: en los mismos recibos, un motor clásico solo CPU iguala a un motor GPU moderno en páginas por minuto de tiempo real — 78.6 vs 79.7 (PaddleOCR), una diferencia de aproximadamente 1.4%, paridad estadística. El motor clásico no es “lento a gran volumen”: es lento por página pero constante — y en este corpus supera a cuatro de los siete motores GPU en la ejecución subyacente (docling 56.7, paddleocr_vl 68.2, unlimited_ocr 34.4, surya2 12.1 páginas/min).

Esto parece una contradicción con los números de latencia, y merece una reconciliación honesta en lugar de una nota al pie. La latencia p50 es la inferencia por página en estado estable, medida en caliente y puntuada con la carga del modelo excluida — los 297.0 ms de PaddleOCR son genuinamente más rápidos que los 670.9 ms de Tesseract. Las páginas por minuto son el rendimiento de tiempo real de toda la ejecución, incluyendo la inicialización del modelo y los efectos por lotes. Convierta el rendimiento del CSV a tiempo real por página (60 segundos ÷ páginas_por_minuto): PaddleOCR gasta ~753 ms por página en tiempo real frente a un p50 de 297 ms — aproximadamente 456 ms por página de inicialización/prefill y sobrecarga por lotes; Tesseract gasta ~763 ms por página en tiempo real frente a un p50 de 671 ms — aproximadamente 92 ms de sobrecarga. El entorno de ejecución CPU simplificado de Tesseract arranca rápido y fluye de manera constante; la canalización GPU de PaddleOCR paga un precio más alto de carga/prefill por ejecución que casi anula su ventaja en estado estable en este corpus de 361 páginas. Una canalización en ejecución prolongada y en caliente aprecia la ventaja por página de PaddleOCR; una canalización dominada por arranques en frío, lotes pequeños o reinicializaciones frecuentes ve a los dos motores en paridad o mejor en el lado clásico.

La cola p95 cuenta la misma historia en un solo número: el p95 de Tesseract de 1,507.0 ms es 2.2× más ajustado que el de PaddleOCR de 3,331.4 ms. El pico de primera página/prefill del motor GPU — la misma ruta de carga que infla su tiempo real por página — domina su cola de peor caso, mientras que el motor CPU no tiene tal pico. Para cargas de trabajo sensibles a la latencia de cola o con planificación de capacidad, el motor clásico es el más predecible.

Fuente: summary_metrics.csv — columna pages_per_minute, filas sroie_2019. Tesseract 78.63285, PaddleOCR 79.71298. Páginas por minuto de reloj de pared incluyendo inicialización del modelo; la latencia por página en estado estable es la columna latency_p50_ms (ver gráfico abajo). Reconciliación: 60 ÷ 78.63285 = 763 ms/página vs 60 ÷ 79.71298 = 753 ms/página de reloj de pared.

Fuente: summary_metrics.csv — columnas latency_p50_ms / latency_p95_ms, filas sroie_2019. Tesseract p50 670.87 / p95 1506.99; PaddleOCR p50 296.99 / p95 3331.35. Latencia en estado estable (modo de medición warm_then_scored, excluye carga del modelo). La tensión entre p50 y páginas/min se reconcilia en el texto anterior: diferentes relojes, ambos reales.

Tabla: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, filas sroie_2019. Valores exactos: Tesseract p50 670.87 / p95 1506.99 / 78.63 pg/min; PaddleOCR p50 296.99 / p95 3331.35 / 79.71 pg/min. La latencia es por página en estado estable (caliente y luego evaluado, excluye carga del modelo); páginas/min es de reloj de pared incluyendo inicialización y efectos por lotes — la paridad y la inversión en p95 son hechos del modelo de medición y la arquitectura, no contradicciones.

La Historia del Costo: Donde el Motor Heredado Gana por Completo

El costo es el único eje donde la antigüedad de Tesseract es una ventaja, y es una ventaja estructural: Tesseract es solo CPU, por lo que su celda de costo en el CSV está vacía por diseño — sin facturación de GPU que medir — mientras que PaddleOCR cobra $0.2214 por 1,000 páginas en la misma RTX 4090 a la tarifa registrada de $0.76/hr. Para una carga de trabajo con rendimiento vinculado (la paridad anterior), el costo operativo del motor clásico en infraestructura que evita la facturación de GPU es materialmente más bajo — el ancla de precio para la decisión de "¿vale la pena actualizar?".

El costo se calcula como el tiempo de ejecución en tiempo real × 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. La celda vacía de Tesseract no es un cero — es un valor faltante porque el motor nunca tocó la GPU; el benchmark lo registra como vacío en lugar de asumir un número (regla de protocolo: una celda vacía es not_applicable, nunca 0). Dos números de contexto mantienen esto honesto: el $0.2214 de PaddleOCR está en el medio del paquete entre los siete motores GPU (docTR mantiene la fila GPU más barata del benchmark en $0.048 por 1,000 páginas), y en CORD el costo de PaddleOCR aumenta a $0.3419 por 1,000 páginas a 141.0 páginas/min.

Fuente: summary_metrics.csv — columna cost_per_1000_pages, filas sroie_2019. PaddleOCR 0.2214. El valor de Tesseract está vacío (celda en blanco en el CSV): tipo de computación solo CPU, sin facturación de GPU — graficado como omitido, no cero. Costo = tiempo de ejecución en tiempo real × $0.76/hr incluyendo inicialización del modelo, precio con marca de tiempo en los manifiestos de ejecución (agosto 2026). Motor GPU más barato en el benchmark: docTR $0.048 por 1,000 páginas (fila doctr/sroie_2019).

Tabla: summary_metrics.csv — columnas cost_per_1000_pages / compute_type, filas sroie_2019. La celda de costo de Tesseract está vacía (en blanco, no 0.0000) porque el motor es solo CPU; el costo de GPU de PaddleOCR incluye la inicialización del modelo a la tarifa registrada de $0.76/hr. En CORD, el costo de PaddleOCR es $0.3419 por 1,000 páginas a 141.0 páginas/min (fila paddleocr/cord_v2).

CORD (Recibos Indonesios): Ambos Colapsan — y se Abre la Brecha de Campo Más Amplia en el Benchmark

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.9523 (Tesseract), un lavado por desajuste de idioma. Según el protocolo del benchmark, los números de CORD se mantienen en cuarentena de la comparación SROIE — nunca se fusionan en ningún ranking — 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.

Donde los dos motores realmente se separan es en la palanca de campos LLM, y este es el punto de datos más fuerte de la página: a través del postprocesador LLM, el F1 de campos de CORD de PaddleOCR se mantiene en 0.5527 — el mejor de los ocho motores en CORD — mientras que el de Tesseract colapsa a 0.1627, el peor de los ocho motores en todo el benchmark. Esa diferencia de 0.39 puntos es la brecha más amplia entre cualquier par de filas hermanas de campos LLM en la ejecución. El mecanismo es el argumento del techo hecho concreto: el texto de CORD de Tesseract es lo suficientemente ilegible (CER 0.9523) que ningún postprocesador — regex o LLM — puede recuperar campos de él. La palanca LLM ayuda (el F1 de SROIE de Tesseract sube de 0.2335 regex a 0.4389 LLM), pero comienza desde una base más débil y no puede fabricar texto que el motor nunca leyó. CORD se cita aquí por contexto de robustez lingüística; se omite deliberadamente de agruparse con los números SROIE en una tabla de clasificación única.

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 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, y los patrones de expresiones regulares fueron escritos para formatos en inglés (el F1 de regex de ambos motores colapsa a ~1–8%). Contexto de clasificación (llm_field_value_f1, todas las filas cord_v2): PaddleOCR 0.5527 es el mejor de ocho; Tesseract 0.1627 es el peor de ocho — la mayor brecha entre filas hermanas en el benchmark. La celda de coste de Tesseract está vacía (solo CPU), nunca 0.

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

“Mejor” depende de la carga de trabajo, y esta comparación directa divide los ejes con una claridad inusual: cada eje de precisión favorece a PaddleOCR; el coste, la simplicidad de CPU y la cola p95 ajustada favorecen a Tesseract; el rendimiento en tiempo real es un empate estadístico; la latencia por página favorece a PaddleOCR; y el campeonato de CER bruto no pertenece a ninguno (docTR/Surya2).

Preguntas Frecuentes

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

Sí — en todos los ejes de precisión medidos en este benchmark. En SROIE 2019: CER 0.2045 vs 0.3347 (mejora relativa del 39%), WER 0.3256 vs 0.5591 (42%), F1 de campos por regex 0.3254 vs 0.2335 (1,39×), F1 de campos con postprocesamiento por LLM 0.5810 vs 0.4389 (1,32×) (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.

¿Por qué Tesseract iguala a PaddleOCR en páginas por minuto a pesar de ser solo CPU?

Porque páginas por minuto es el rendimiento en tiempo real, no la velocidad de inferencia por página. El p50 en estado estable de PaddleOCR (297,0 ms) es genuinamente 2,3× más rápido que el de Tesseract (670,9 ms), pero el rendimiento en tiempo real incluye la inicialización del modelo y efectos de lote: a 79,7 páginas/min, PaddleOCR gasta ~753 ms por página en tiempo real frente a su p50 de 297 ms, mientras que el entorno de ejecución CPU simplificado de Tesseract gasta ~763 ms por página frente a su p50 de 671 ms — el motor GPU paga un precio más alto de carga/prefill por ejecución que casi anula su ventaja de velocidad en este corpus de 361 páginas (summary_metrics.csv, pages_per_minute / latency_p50_ms, filas sroie_2019).

¿Por qué la latencia p95 de Tesseract es más baja que la de PaddleOCR?

Porque el pico de la primera página/prefill del motor GPU domina su cola de peor caso: PaddleOCR p95 3.331,4 ms vs Tesseract p95 1.507,0 ms, una inversión de 2,2× respecto al orden del p50 (summary_metrics.csv, latency_p95_ms, filas sroie_2019). La canalización CPU de Tesseract no tiene pico de carga y fluye de manera constante; el estado estable rápido de PaddleOCR viene con una ruta de inicialización más pesada en cada ejecución. Los dos relojes miden cosas diferentes y ambos son reales.

¿Tesseract es más barato que PaddleOCR?

En la facturación por GPU, sí — Tesseract no tiene coste: es solo CPU, por lo que su celda de coste en el CSV está vacía por diseño (nunca es 0), mientras que PaddleOCR factura $0.2214 por 1.000 páginas en SROIE y $0.3419 en CORD, en la misma RTX 4090 a $0.76/hr con coste incluyendo la inicialización del modelo (summary_metrics.csv, cost_per_1000_pages, filas sroie_2019 y cord_v2). El motor GPU más barato del benchmark en general es docTR a $0.048 por 1.000 páginas.

¿Por qué el F1 de campo LLM de Tesseract en CORD es el peor de todo el benchmark?

Porque el postprocesador LLM no puede recuperar texto que el motor OCR nunca leyó. El CER de Tesseract en CORD es 0.9523 — esencialmente ilegible en recibos indonesios — por lo que su F1 de campo LLM colapsa a 0.1627, el peor de los ocho motores, mientras que el de PaddleOCR se mantiene en 0.5527, el mejor de los ocho (field_method_comparison.csv, llm_field_value_f1, filas cord_v2). La misma palanca en texto inglés limpio (SROIE) eleva a Tesseract a 0.4389 — pero el techo está determinado por la calidad del texto base.

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

Dos causas acumulativas que el protocolo mantiene separadas del ranking SROIE: una auténtica discrepancia lingüística (recibos indonesios fuera del enfoque de entrenamiento de ambos motores) e inflación en la estructura de anotación dentro del texto base de CORD — el CER llega a 0.9083 (PaddleOCR) y 0.9523 (Tesseract) (summary_metrics.csv, cer, filas cord_v2). Lo que aún los separa es la recuperación descendente por LLM: 0.5527 de PaddleOCR vs 0.1627 de Tesseract en F1 de campo — la mayor brecha entre filas hermanas en el benchmark. Las filas de CORD se citan con encuadre y nunca se agrupan en ningún ranking combinado.

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

Si tu pipeline consume campos — valores extraídos para empresa, fecha, totales — PaddleOCR es el predeterminado claro para recibos: 1,39× campo F1 bajo regex, 1,32× bajo un LLM, y recuperación downstream con LLM que sobrevive el shock de idioma CORD (field_method_comparison.csv). Si necesitas texto bruto en alto volumen en documentos en inglés limpios con costo GPU cero, infraestructura solo CPU, o previsibilidad de latencia de cola, Tesseract sigue siendo una opción legítima: rendimiento de reloj de pared empatado (79,7 vs 78,6 páginas/min), p95 es 2,2× más ajustado, y no hay facturación GPU — pero presupuesta una base de texto de nivel medio (CER 0,3347, 5º de 8) que limita cada pipeline de campos downstream. Estos resultados son válidos para recibos en inglés e indonesio en un nivel de GPU en agosto de 2026; vuelve a ejecutar 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 propio — results/summary_metrics.csv (CER/WER, regex campo F1, latencia, costo, rendimiento; las filas de tesseract tienen compute_type=cpu y una celda de costo vacía) y results/field_method_comparison.csv (regex vs postprocesamiento 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 reporta un corte directo de una ejecución de benchmark independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros, ni una página de comparación de proveedores. Solo divisiones de prueba fijas: SROIE 2019 test (361 recibos en inglés, campos planos empresa/dirección/fecha/total) y CORD v2 test (100 recibos indonesios, campos anidados menu/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 asimetría CPU/GPU es inherente a esta comparación: Tesseract se ejecutó en CPU (compute_type=cpu) frente a motores acelerados por GPU, por diseño — su celda de costo está vacía porque no se facturó tiempo GPU, y su latencia/rendimiento se midieron en la misma máquina bajo el mismo protocolo. La ejecución subyacente contiene ocho motores en total; esta página compara solo los dos motores nombrados, con otros motores citados 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 máquina con una NVIDIA RTX 4090 (24 GB); el costo de GPU se calculó con la tarifa bajo demanda de RunPod de $0.76/hr, precio con marca de tiempo en el manifiesto redactado de cada ejecución (agosto de 2026). Tesseract se ejecutó en CPU y no incurrió en costo de GPU; su celda de costo está vacía por diseño.
• Motores: fuera de la caja, sin ajuste fino. Versiones bloqueadas: Tesseract 5.3.4 (motor OCR clásico de código abierto — pipeline CV tradicional con reconocimiento basado en LSTM, solo CPU, ejecutor python3 del sistema, sin entorno GPU) y PaddleOCR 3.7.0 (OCR moderno de aprendizaje profundo en dos etapas — detección + reconocimiento PP-OCR, GPU) — según la tabla de modelos del repositorio público (README.md) y los manifiestos de ejecución.
• 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 en tiempo real × $0.76/hr, incluyendo inicialización del modelo — el procesamiento por lotes reduce el costo por página; no aplica a Tesseract (solo CPU).
• Postprocesamiento de campos: las métricas de campos regex de SROIE son postprocessed_sroie_receipt_regex_* (columnas regex_* en 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. Los dos pipelines nunca se combinan.

Definiciones 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 granularidad 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 OCR (pipeline 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 valor de campo (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 puntuado, excluye carga del modelo) y rendimiento en tiempo real incluyendo inicialización del modelo. Miden relojes diferentes; la paridad p50-vs-páginas/min en esta página es un hecho del modelo de medición, no un error, y se reconcilia en la sección de Paridad de Rendimiento.
• Costo por 1,000 páginas: horas de GPU facturadas por 1,000 páginas a la tarifa registrada de $0.76/hr, incluyendo inicialización del modelo. La celda de Tesseract está vacía (solo CPU) — una celda vacía es not_applicable, nunca 0.

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 tesseract y paddleocr aquí (tesseract: compute_type=cpu, celda de costo vacía).
2. field_method_comparison.csv (GitHub raw). 16 filas; columnas model, dataset, llm_model (= deepseek-v4-flash), precisión y F1 de campos regex/llm, document-fields-exact, llm_median_latency_ms, recuentos de tokens. Cada número de F1 de campos regex/LLM se remonta a las filas de tesseract y paddleocr aquí (y a las ocho filas de sroie_2019 / cord_v2 en el contexto de clasificación).
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que alberga 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 de modelo, GPU/driver, versiones de torch/CUDA/Python, metadatos de costos con marca de tiempo de precios 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

• La asimetría CPU/GPU es inherente, no un defecto: Tesseract se ejecutó en CPU frente a motores acelerados por GPU. Su celda de coste está vacía por diseño (sin facturación de GPU, nunca 0), y su latencia/rendimiento son números de CPU medidos en la misma máquina bajo el mismo protocolo — una clase de máquina diferente podría cambiar su rango operativo. Trate la comparación de costes como “facturación de GPU vs ninguna”, no como una verdad independiente del hardware.
• Alcance del documento — solo recibos: SROIE + CORD. Nada aquí mide el comportamiento de Tesseract en diseños complejos, tablas, escritura a mano o documentos largos — tipos de documento donde se sabe que los motores clásicos degradan aún más — ni las capacidades de diseño/tablas de PP-Structure de PaddleOCR. No use esta página para concluir que cualquiera de los motores “gana en todo.”
• Tamaño de la muestra: 361 recibos en inglés + 100 en indonesio. El F1 de campo y el CER son sensibles al corpus; las 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í (39% CER, 1,39× regex F1, la diferencia de 0,39 puntos en CORD LLM-F1) están muy por encima de ese rango.
• Un solo nivel de GPU y un solo precio: todos los números de GPU provienen de una RTX 4090 a $0,76/hr, precio con marca de tiempo de agosto de 2026 en los manifiestos de ejecución. Otras GPUs, servicio multi-GPU, programación por lotes o cambios de precio cambiarán la latencia, el rendimiento y el coste — recalcule los costes 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 el F1 absoluto de campo; las brechas de 1,32× en SROIE y de 0,39 puntos en CORD pueden moverse en los márgenes. La latencia del LLM (~1.817–1.837 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 motores.
• 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 incorpora la estructura de anotación y ninguno de los motores fue entrenado predominantemente en indonesio; el CER de CORD (0,91–0,95) 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 Tesseract 5.3.4 y PaddleOCR 3.7.0 (agosto de 2026). Versiones más recientes de cualquiera de los motores podrían cambiar todos los números de esta página; los resultados de Tesseract específicamente reflejan la 5.3.4 y fueron re-verificados en una ejecución de repetición el 2026-08-14.

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

Lectura relacionada: Precisión de OCR con IA vs OCR Tradicional · Extracción de Datos de Imágenes con IA vs OCR Tradicional · Precios de Extracción de Documentos con IA (2026)