Tesseract vs PaddleOCR en recibos
CPU heredada vs GPU moderna (2026)

Qué son los dos motores: 35 años de OCR frente a un pipeline CNN de dos etapas

Toda la historia de esta página es una brecha de arquitectura. Tesseract es el motor OCR clásico de código abierto — desarrollado originalmente en HP en los años 80 y liberado como código abierto por Google en 2005, por lo que arrastra unos 35 años de linaje. Su pipeline 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 este benchmark (compute_type = cpu en el CSV). PaddleOCR es un motor moderno de aprendizaje profundo del ecosistema PaddlePaddle: un pipeline de dos etapas en la familia PP-OCR — una etapa de detección que localiza regiones de texto (estilo DBNet) y luego una etapa de reconocimiento que las transcribe — ejecutándose en GPU. Un motor lee comparando formas de caracteres con patrones aprendidos; el otro lee aprendiendo dónde está el texto y qué dice. Este benchmark somete a ambos a los mismos recibos, el mismo protocolo y la 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 un texto sustancialmente más limpio. El trabajo del benchmark es poner un número en ambos lados de ese intercambio a partir de una sola ejecución controlada — y la sorpresa es lo estrecho que resultó ser el lado del costo operativo del intercambio.

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 entre los ocho motores en la ejecución subyacente — en el medio del grupo, no el último — pero todos los motores por encima de él, excepto uno, son motores 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 el criterio clásico de OCR: inserciones, eliminaciones y sustituciones divididas por los caracteres de referencia — 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 nivel de palabra. Ambos son mejores cuanto más bajos. Que la brecha de WER (42%) sea más amplia que la de CER (39%) significa que los deslices de caracteres de Tesseract se combinan en fallos de palabras completas en este corpus — el modo de fallo 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. Cuanto más bajo, 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: CER de SROIE en los ocho motores: 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 estos dos motores es el campeón de precisión del benchmark: docTR y Surya2 ocupan los dos primeros puestos de 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 se centran en cuatro campos planos de recibos (empresa, fecha, dirección, total) usando dos posprocesadores en el texto OCR de cada motor: patrones de 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.2335 de Tesseract — una ventaja de 1.39×; mediante el LLM, la brecha persiste en 0.5810 frente a 0.4389 (1.32×). La palanca 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 pipelines de producción está una sección más abajo.

El F1 de valor de campo es la media armónica de precisión y recuperación sobre los valores de campos extraídos frente a la verdad de referencia — 1.0 significa que cada campo de recibo se recuperó perfectamente, 0 significa que nada se recuperó. Las columnas de campos regex de SROIE son las métricas postprocessed_sroie_receipt_regex_* del benchmark: patrones fijos aplicados al texto de OCR de cada motor — postprocesados, no salida estructurada nativa. Contexto de clasificación: el F1 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 de Tesseract de 0.2335 es el cuarto mejor resultado regex en general (summary_metrics.csv, field_f1_regex, filas de sroie_2019) — el motor clásico es un extractor de campos de nivel medio 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 de sroie_2019 (decimales almacenados 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. 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). “Docs with all fields exact” es la fracción de documentos donde cada campo objetivo coincidió exactamente — un estándar 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 ocupa el 7.º, solo por delante del 0.3717 de EasyOCR.

La sorpresa: paridad de rendimiento de CPU en tiempo real

El hallazgo más destacable de la página es el que ninguna comparación de terceros documenta: en los mismos recibos, un motor clásico solo con CPU iguala a un motor GPU moderno en páginas por minuto en tiempo real — 78.6 frente a 79.7 (PaddleOCR), aproximadamente 1.4% de diferencia, 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 contradecir las cifras 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 en tiempo real de toda la ejecución, incluida la inicialización del modelo y los efectos de lote. 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 — unos 456 ms por página de inicialización/precarga y sobrecarga de lote; Tesseract gasta ~763 ms por página en tiempo real frente a un p50 de 671 ms — unos 92 ms de sobrecarga. El tiempo de ejecución de CPU simplificado de Tesseract arranca rápido y fluye de manera constante; la canalización GPU de PaddleOCR paga un precio de carga/precarga más alto por ejecución que casi anula su rápida velocidad en estado estable en este corpus de 361 páginas. Una canalización cálida de larga duración ve la ventaja por página de PaddleOCR; una canalización dominada por arranques en frío, lotes pequeños o reinicializaciones frecuentes ve 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/precarga del motor GPU — la misma ruta de carga que infla su tiempo por página en tiempo real — domina su peor cola, mientras que el motor CPU no tiene tal pico. Para cargas de trabajo sensibles a la latencia de cola o planificadas por 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/min en tiempo de reloj, incluida la inicialización del modelo; la latencia por página en estado estable es la columna latency_p50_ms (ver gráfico a continuación). Conciliación: 60 ÷ 78.63285 = 763 ms/página frente a 60 ÷ 79.71298 = 753 ms/página en tiempo de reloj.

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 la carga del modelo). La tensión entre p50 y páginas/min se concilia en el texto anterior: relojes distintos, 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 págs/min; PaddleOCR p50 296.99 / p95 3331.35 / 79.71 págs/min. La latencia es por página en estado estable (caliente y luego puntuado, excluye la carga del modelo); páginas/min es tiempo de reloj, incluidos los efectos de inicialización y lote — la paridad y la inversión del p95 son hechos del modelo de medición y la arquitectura, no contradicciones.

La historia del costo: donde el motor clásico gana de forma contundente

El costo es el único eje donde la antigüedad de Tesseract es una ventaja, y es 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 factura $0.2214 por cada 1,000 páginas en la misma RTX 4090 a la tarifa registrada de $0.76/hora. Para una carga de trabajo ligada al rendimiento (la paridad anterior), el costo operativo del motor clásico en infraestructura que no factura GPU es materialmente menor — el ancla de precio para la decisión de “¿vale la pena actualizar?”.

El costo se calcula como tiempo de ejecución en pared × la tarifa de RunPod RTX 4090 ($0.76/hora, precio con marca de tiempo en los manifiestos de ejecución), incluida 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 del protocolo: una celda vacía es not_applicable, nunca 0). Dos números de contexto mantienen esto honesto: los $0.2214 de PaddleOCR están en la mitad del grupo entre los siete motores GPU (docTR tiene la fila GPU más barata del benchmark a $0.048 por cada 1,000 páginas), y en CORD el costo de PaddleOCR sube a $0.3419 por cada 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 cómputo solo CPU, sin facturación de GPU — graficado como omitido, no como cero. Costo = tiempo de ejecución en pared × $0.76/hora incluida la inicialización del modelo, precio con marca de tiempo en los manifiestos de ejecución (agosto de 2026). Motor GPU más barato del benchmark: docTR $0.048 por cada 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/hora. En CORD, el costo de PaddleOCR es de $0.3419 por cada 1,000 páginas a 141.0 páginas/min (fila paddleocr/cord_v2).

CORD (recibos de Indonesia): ambos colapsan — y se abre la mayor brecha de campos del benchmark

Ninguno de los dos motores 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 colapsan en CER bruto: 0.9083 (PaddleOCR) y 0.9523 (Tesseract), un empate por desajuste de idioma. Según el protocolo del benchmark, los números de CORD se mantienen aislados de la comparación con SROIE — nunca se fusionan en ninguna clasificación — porque el texto de referencia de CORD incorpora la estructura de anotación, lo que infla el CER bruto de todos los motores 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 posprocesador 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 de todo el benchmark. Esa diferencia de 0.39 puntos es la brecha más amplia entre dos filas hermanas de campos LLM en toda la ejecución. El mecanismo es el argumento del techo hecho realidad: el texto de CORD de Tesseract es demasiado ilegible (CER 0.9523) como para que cualquier posprocesador — regex o LLM — pueda recuperar campos de él. La palanca LLM ayuda (el F1 de SROIE de Tesseract sube de 0.2335 con regex a 0.4389 con LLM), pero parte de una base más débil y no puede fabricar texto que el motor nunca leyó. CORD se cita aquí para contextualizar la robustez lingüística; deliberadamente nunca se combina 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 (field F1), filas cord_v2. No combine los números de CORD con ninguna clasificación de SROIE: el CER de CORD combina un desajuste lingüístico genuino con una inflación de la estructura de anotación en la verdad de referencia, y los patrones de regex se escribieron para formatos en inglés (el F1 de regex de ambos motores se desploma 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 del benchmark. La celda de costo de Tesseract está vacía (solo CPU), nunca es 0.

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 una claridad inusual: todos los ejes de precisión favorecen a PaddleOCR; el costo, la simplicidad de CPU y la cola p95 ajustada favorecen a Tesseract; el rendimiento en tiempo de reloj 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 análisis comparativo. En SROIE 2019: CER 0.2045 frente a 0.3347 (mejora relativa del 39%), WER 0.3256 frente a 0.5591 (42%), F1 de campos con regex 0.3254 frente a 0.2335 (1.39×), F1 de campos con posprocesamiento LLM 0.5810 frente a 0.4389 (1.32×) (summary_metrics.csv y field_method_comparison.csv, filas sroie_2019). Ningún motor es el campeón general de texto del análisis comparativo — 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 las páginas por minuto miden el rendimiento en tiempo real, no la velocidad de inferencia por página. La p50 en estado estable de PaddleOCR (297.0 ms) es genuinamente 2.3× más rápida que la de Tesseract (670.9 ms), pero el rendimiento en tiempo real incluye la inicialización del modelo y los efectos de lote: a 79.7 páginas/min, PaddleOCR dedica ~753 ms por página en tiempo real frente a su p50 de 297 ms, mientras que el runtime de CPU simplificado de Tesseract dedica ~763 ms por página frente a su p50 de 671 ms — el motor GPU paga un costo de carga/prefill más alto por ejecución que casi anula su ventaja de velocidad en este corpus de 361 páginas (summary_metrics.csv, páginas_por_minuto / latencia_p50_ms, filas sroie_2019).

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

Porque el pico de primera página/prefill del motor GPU domina su cola de peor caso: p95 de PaddleOCR 3,331.4 ms frente a p95 de Tesseract 1,507.0 ms, una inversión de 2.2× del orden de la p50 (summary_metrics.csv, latencia_p95_ms, filas sroie_2019). El pipeline de CPU de Tesseract no tiene pico de carga y fluye de manera constante; el rápido estado estable de PaddleOCR conlleva una ruta de inicialización más pesada en cada ejecución. Los dos relojes miden cosas distintas y ambos son reales.

¿Es Tesseract más barato que PaddleOCR?

Con facturación de GPU, sí — Tesseract no tiene ninguna: es solo de CPU, por lo que su celda de costo en el CSV está vacía por diseño (nunca 0), mientras que PaddleOCR factura $0.2214 por cada 1,000 páginas en SROIE y $0.3419 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 de GPU más barato del benchmark en general es docTR a $0.048 por cada 1,000 páginas.

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

Porque el posprocesador LLM no puede recuperar texto que el motor OCR nunca leyó. El CER de Tesseract en CORD es 0.9523 — efectivamente ilegible en recibos indonesios — por lo que su F1 de campo LLM cae a 0.1627, el peor de los ocho motores, mientras que el de PaddleOCR se mantiene en 0.5527, el mejor de 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 lo fija la calidad del texto base.

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

Dos causas que se combinan y que el protocolo mantiene separadas de la clasificación de SROIE: un desajuste lingüístico genuino (recibos indonesios fuera del enfoque de entrenamiento de ambos motores) y una inflación de la estructura de anotaciones dentro del texto de referencia de CORD — el CER se sitúa en 0.9083 (PaddleOCR) y 0.9523 (Tesseract) (summary_metrics.csv, cer, filas cord_v2). Lo que aún los separa es la recuperación posterior con LLM: F1 de campo de 0.5527 para PaddleOCR frente a 0.1627 para Tesseract — la mayor brecha entre filas hermanas del benchmark. Las filas de CORD se citan con su contexto y nunca se agrupan en ninguna clasificación combinada.

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

Si su pipeline consume campos — valores extraídos para empresa, fecha, totales — PaddleOCR es la opción clara por defecto en recibos: 1,39× F1 de campos bajo regex, 1,32× bajo un LLM, y una recuperación posterior al LLM que sobrevive al choque de idioma de CORD (field_method_comparison.csv). Si necesita texto bruto de alto volumen en documentos en inglés limpios con costo de GPU cero, infraestructura solo de CPU o previsibilidad de latencia de cola, Tesseract sigue siendo una opción legítima: el rendimiento de tiempo real empata (79,7 vs 78,6 páginas/min), el p95 es 2,2× más ajustado y no hay facturación de GPU — pero presupueste una base de texto de nivel medio (CER 0,3347, 5.º de 8) que limita todo pipeline de campos posterior. Estos resultados se mantienen para recibos en inglés e indonesio en un nivel de GPU en agosto de 2026; vuelva a ejecutarlos en su corpus objetivo antes de tomar decisiones de producción (consulte 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; las filas de tesseract llevan compute_type=cpu y una celda de costo vacía) 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 huellas de entorno. Las definiciones de los conjuntos de datos provienen de los artículos SROIE 2019 y CORD citados a continuación.

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 estudio 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ú/subtotal/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: una pasada de calentamiento fija precede a la pasada evaluada, 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 asimetría CPU/GPU es inherente a esta comparación: Tesseract se ejecutó en CPU (compute_type=cpu) contra motores acelerados por GPU, por diseño — su celda de costo está vacía porque no se facturó tiempo de 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 ú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 máquina con una NVIDIA RTX 4090 (24 GB); el costo de GPU se calculó a la tarifa bajo demanda de RunPod de $0.76/hora, con la marca de tiempo del precio 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: de fábrica, sin ajuste fino. Versiones fijadas: 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 PP-OCR + reconocimiento, 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 costo: tiempo de ejecución en pared × $0.76/hora, incluida la 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 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 la salida estructurada nativa de ningún modelo; las columnas LLM_* miden texto de 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 de OCR y la verdad fundamental, dividida por los caracteres de la verdad fundamental. Cuanto menor, mejor.
• WER (tasa de error de palabras): el mismo cálculo de distancia de edición a nivel de palabras.
• 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 KIE tradicional de OCR + 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 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 (calentado y luego puntuado, excluye la carga del modelo) y rendimiento en pared incluida la 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 concilia en la sección 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/hora, incluida la 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 valor de CER/WER, latencia, costo y rendimiento en esta página proviene de 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 valores de campo regex/llm, document-fields-exact, llm_median_latency_ms, recuentos de tokens. Cada valor de F1 de campo regex/LLM proviene de las filas de tesseract y paddleocr aquí (y de las ocho filas de sroie_2019 / cord_v2 en el contexto de clasificación).
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/driver, 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

• La asimetría CPU/GPU es inherente, no un defecto: Tesseract se ejecutó en CPU frente a motores acelerados por GPU. Su celda de costo está vacía por diseño (sin facturación de GPU, nunca 0), y su latencia/rendimiento son cifras de CPU medidas en la misma máquina bajo el mismo protocolo — una clase de máquina diferente podría alterar su rango operativo. Considere la comparación de costos 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 con diseños complejos, tablas, escritura a mano o documentos extensos — tipos de documentos donde se sabe que los motores clásicos se degradan más—, ni las capacidades de diseño/tablas de PP-Structure de PaddleOCR. No utilice esta página para concluir que cualquiera de los dos motores “gana en todo”.
• Tamaño de muestra: 361 recibos en inglés + 100 en indonesio. El F1 de campo y el CER dependen del corpus; diferencias de unas pocas centésimas deben tratarse como ruido, no como verdad de ingeniería — aunque las brechas documentadas aquí (39% de CER, 1.39× de F1 de regex, la diferencia de 0.39 puntos en el LLM-F1 de CORD) están muy por fuera de ese rango.
• Un solo nivel de GPU y un solo precio: todas las cifras de GPU provienen de un RTX 4090 a $0.76/hora, con precio con fecha de agosto de 2026 en los manifiestos de ejecución. Otras GPU, servicio con múltiples 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 altera el F1 de campo absoluto; las brechas de 1.32× en SROIE y de 0.39 puntos en CORD pueden variar en los márgenes. La latencia del LLM (mediana de ~1,817–1,837 ms 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.
• 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 una puntuación más alta 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: los datos de referencia de CORD incorporan la estructura de anotación y ninguno de los motores fue entrenado predominantemente en indonesio; el CER de CORD (0.91–0.95) refleja el desajuste de idioma + la inflación de datos de referencia. 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 Tesseract 5.3.4 y PaddleOCR 3.7.0 (agosto de 2026). Las versiones más nuevas de cualquiera de los motores pueden alterar cada cifra de esta página; los resultados de Tesseract reflejan específicamente la 5.3.4 y se volvieron a verificar en una ejecución repetida del 14 de agosto de 2026.

Referencias relacionadas: Benchmark de recibos PaddleOCR vs EasyOCR · Benchmark de recibos docTR vs Surya2 · la comparación de ocho motores de OCR y VLM · reglas fijas vs. modelos de lenguaje para campos · por qué un recuento de caracteres correcto puede seguir significando un campo incorrecto

Lectura relacionada: la brecha de precisión entre la IA y el OCR tradicional · por qué la extracción con IA supera al OCR en imágenes · Precios de Extracción de Documentos con IA (2026)