Resultados del Benchmark de OCR para Recibos:
Precisión, Latencia y Costo en 5 Modelos de OCR de Código Abierto (2026)

La paradoja: el mejor lector de texto, el peor extractor de campos

La misma ejecución de referencia produjo tanto el mejor como el peor resultado de extracción de campos en los mismos 361 recibos. La diferencia no es la calidad de los datos, sino la diferencia entre leer texto y extraer campos.

Dos métricas de precisión responden a preguntas distintas. La tasa de error de caracteres (CER) mide cuántos caracteres individuales se leyeron incorrectamente en relación con la transcripción de referencia: un CER del 19,7 % significa aproximadamente un carácter incorrecto por cada cinco. La tasa de error de palabras (WER) falla una palabra completa ante cualquier carácter mal leído dentro de ella, por lo que los valores de WER siempre son más altos que los de CER. El F1 a nivel de campo, en esta referencia, mide si los cuatro campos de SROIE (nombre de la empresa, fecha, dirección y total) pueden recuperarse del texto de OCR mediante un posprocesador de regex fijo, calculado como la media armónica de precisión y exhaustividad en el conjunto de campos de los 361 documentos.

docTR produjo la transcripción más limpia (19,7 % de CER, 32,0 % de WER), pero su recuperación de campos se desplomó a 7,7 % de F1: una pasada de regex sobre texto limpio aún puede fallar cuando el formato del valor (símbolos de moneda, totales con coma decimal, direcciones de varias líneas) no coincide con el patrón de extracción. La transcripción de PaddleOCR fue ligeramente más ruidosa (20,5 % de CER), pero su salida se alineó mejor con los patrones de campo, alcanzando 32,5 % de F1. Ninguno de los dos resultados es un error: son dos capas distintas del mismo flujo, y ningún modelo de este lote logró siquiera un documento completamente correcto en los cuatro campos (coincidencia exacta de campos a nivel de documento = 0 para todos los modelos). Este es el significado práctico de la afirmación de que la precisión del texto de OCR no es la precisión de los campos.

Resultados de SROIE 2019: precisión del texto, F1 de campo, latencia y costo

El conjunto de clasificación principal es SROIE 2019 (Scanned Receipt OCR and Information Extraction, el conjunto de datos de la competencia ICDAR 2019): 361 recibos escaneados en inglés en la división de prueba oficial fija, evaluados con los cinco modelos en el mismo grupo de ejecución en la misma GPU. Un CER/WER más bajo es mejor; un F1 de campo más alto es mejor.

Fuente: ImageToTable.ai Receipt OCR Benchmark v1, división de prueba de SROIE 2019 (361 muestras). Ejecuciones: nivel oficial, protocolo warm_then_scored, RTX 4090. IC bootstrap del 95 % mediante 2.000 remuestreos. Paquete de artefactos completo disponible bajo petición. Conjunto de datos: competencia ICDAR 2019 SROIE.

Fuente: ImageToTable.ai Receipt OCR Benchmark v1, división de prueba de SROIE 2019. Todas las métricas provienen de artefactos de predicción congelados (n=361 por modelo, tasa de éxito del 100 %). CER/WER: tasa de error de caracteres/palabras frente a la transcripción de referencia. F1 de campo: extracción de campos posprocesada a partir del texto de OCR mediante expresiones regulares fijas — NO es la salida nativa de campos del modelo (ninguno de los cinco modelos emite campos estructurados nativos). IC: percentil bootstrap del 95 %, 2.000 remuestras. Costo: calculado con RunPod RTX 4090 a $0,76/hora (precio registrado el 11-08-2026). Artefactos completos disponibles bajo petición.

Por qué el F1 de campo va tan por detrás de la precisión de texto

Todos los modelos de este lote leen el texto razonablemente bien, pero no logran entregar un campo estructurado utilizable en la mayoría de los recibos: el mejor F1 de campo es del 32,5 %, y ningún modelo produjo un solo documento completamente correcto (empresa + fecha + dirección + total, todo exacto).

Las métricas de campo SROIE aquí están postprocesadas con regex: el benchmark toma el texto OCR de cada modelo y aplica una extracción fija basada en patrones para los cuatro campos. Esto es deliberadamente distinto de la salida nativa de campos estructurados de un modelo: ninguno de los cinco motores OCR de código abierto de este lote emite campos estructurados nativos para el diseño de recibos, por lo que el postprocesador es la única vía de campo disponible para ellos. La brecha entre un CER del 19,7 % y un F1 de campo del 7,7 % es lo que un pipeline de extracción real paga por la capa de salida estructurada ausente: el texto de alta calidad aún necesita comprensión del diseño y normalización de valores para convertirse en campos.

La inversión del ranking entre modelos es estable: PaddleOCR lidera el F1 de campo con 32,5 % (IC del 30,5–34,5 %), seguido de Tesseract 23,2 %, Docling 22,3 %, EasyOCR 14,8 % y docTR 7,7 % — mientras que el ranking de métricas de texto está casi exactamente invertido en la parte superior (docTR 19,7 % CER frente a PaddleOCR 20,5 % CER). Cualquier pipeline que informe solo de "precisión de OCR" está ocultando la capa de extracción de campos donde reside la varianza real.

CORD v2: la prueba de estrés lingüístico

En 100 recibos en indonesio (CORD v2), el CER de todos los modelos se desploma al 90–95 %: una pila de OCR entrenada en inglés no se transfiere a otro idioma, y este benchmark cuantifica la penalización en lugar de ignorarla.

CORD v2 (un conjunto de datos de recibos consolidado creado para el análisis posterior al OCR) proporciona la prueba de estrés multilingüe. Sus 100 muestras de prueba revisadas son recibos en indonesio, y todos los modelos de este lote se entrenaron principalmente con datos en inglés. Los resultados siguientes no son un ranking de calidad de los modelos: las métricas de texto de CORD se enmarcan como evidencia de robustez de recibos/idioma/diseño y no deben fusionarse con SROIE en un único ranking general. Las métricas de campo no son aplicables en CORD porque ningún modelo emite campos estructurados nativos de CORD y no se define ningún postprocesador de CORD para este lote.

Fuente: ImageToTable.ai Receipt OCR Benchmark v1, división de prueba de CORD v2 (100 muestras). Todas las ejecuciones en nivel oficial, RTX 4090, tasa de éxito del 100 %. Advertencia: prueba de estrés por desajuste de idioma: no compare los valores de CER de CORD con los valores de CER de SROIE. Conjunto de datos: CORD v2 (Clova AI).

Velocidad y costo: la brecha de 7,7×

En hardware idéntico, el rendimiento varía 7,7× y el costo por 1.000 páginas varía 7,8× — para volumen de recibos, elegir el modelo más rápido puede reducir el costo de cómputo de OCR en aproximadamente un 87% antes siquiera de considerar la precisión.

El rendimiento se reporta de dos maneras en este benchmark: latencia p50/p95 por página (de registros de predicción exitosos, excluyendo la inicialización del runner) y páginas por minuto de tiempo real de extremo a extremo (incluyendo el arranque del proceso del runner bajo el modo warm_then_scored). El costo por 1.000 páginas se calcula a partir del tiempo de ejecución a la tarifa registrada de $0.76/hora en RunPod RTX 4090. Los gráficos a continuación muestran el rendimiento y el costo de SROIE en tiempo real; CORD sigue la misma tendencia con docTR y PaddleOCR nuevamente como los más rápidos y económicos.

Fuente: ImageToTable.ai Receipt OCR Benchmark v1, división de prueba de SROIE 2019 (361 muestras). Páginas por minuto en tiempo real de ejecuciones cronometradas del benchmark, incluyendo la inicialización del runner. Todas las ejecuciones en nivel oficial, RTX 4090.

Fuente: ImageToTable.ai Receipt OCR Benchmark v1, división de prueba de SROIE 2019. Costo = tiempo de ejecución × $0.76/hora (RunPod RTX 4090, precio registrado el 2026-08-11). Incluye la sobrecarga de inicialización por ejecución.

Cómo elegir un modelo a partir de estos resultados

No existe un modelo "mejor" único en este benchmark — los resultados respaldan la elección según la prioridad, y la misma tabla responde diferentes preguntas. Tres prioridades comunes se mapean directamente con los datos:

• Si el objetivo es la precisión bruta de transcripción (indexación de texto completo, digitalización legible): docTR lidera con 19.7% de CER y también es el más rápido y económico con 256.0 páginas/min y $0.049 por 1.000 páginas — gana en las tres dimensiones de precisión de texto, velocidad y costo simultáneamente.
• Si el objetivo es la extracción estructurada de campos (alimentar sistemas posteriores que necesitan empresa/fecha/total): PaddleOCR lidera con 32.5% de F1 de campo, pero incluso eso es una tasa de fallo de campo de aproximadamente 2 de cada 3 — la conclusión honesta es que ninguno de estos motores de OCR de código abierto por sí solo ofrece extracción de campos de recibos de grado de producción sin una capa de extracción estructurada encima.
• Si el costo a gran volumen es la restricción: la brecha de costo de 7,8× significa que un millón de páginas cuesta aproximadamente $49 con docTR frente a $381 con Docling — una diferencia de ~$332 por millón de páginas en hardware idéntico.

Sea cual sea la prioridad que aplique, el protocolo y los artefactos le permiten reproducir cada número de esta tabla en su propia GPU antes de comprometerse — y para un flujo de recibos multilingüe, los resultados de CORD son la advertencia de que los modelos entrenados en inglés deben probarse bajo estrés en el idioma objetivo primero.

Preguntas Frecuentes

¿Qué modelo de OCR de código abierto es más preciso en recibos?

Depende de la métrica: docTR tiene la mejor precisión de texto (19,7 % de CER en 361 recibos SROIE) mientras que PaddleOCR tiene la mejor extracción de campos (32,5 % de F1 de campo) en el ImageToTable.ai Receipt OCR Benchmark. Ningún modelo lidera ambas métricas — la precisión de texto y la extracción de campos son capas diferentes del proceso.

¿Por qué la precisión de texto de docTR es mejor pero su extracción de campos es peor que la de PaddleOCR?

Porque las dos métricas miden capas diferentes del proceso. docTR leyó caracteres con mayor precisión (19,7 % de CER frente a 20,5 %), pero su salida no coincidió con los patrones de regex fijos para empresa/fecha/dirección/total, reduciendo su F1 de campo postprocesado a 7,7 % mientras que PaddleOCR alcanzó 32,5 %. Un texto más limpio no garantiza una mejor extracción de campos cuando el formato de los valores (símbolos de moneda, separadores de coma, diseño multilínea) difiere del patrón de extracción.

¿Es PaddleOCR mejor que Tesseract para OCR de recibos?

Sí, en todas las métricas de este benchmark: PaddleOCR supera a Tesseract en CER (20,5 % frente a 33,6 %), WER (32,6 % frente a 56,2 %), F1 de campo (32,5 % frente a 23,2 %), velocidad (157,8 frente a 54,4 páginas/min) y costo ($0,080 frente a $0,233 por 1.000 páginas) en el conjunto de prueba SROIE de 361 recibos.

¿La precisión del OCR disminuye con recibos en otros idiomas?

Drásticamente: en 100 recibos indonesios de CORD v2, todos los modelos entrenados en inglés obtuvieron 90–95 % de CER (PaddleOCR 90,8 % el mejor, Tesseract 95,2 % el peor) frente a 20–58 % en recibos SROIE en inglés. Considérelo una prueba de estrés lingüístico, no una clasificación de modelos — los mismos modelos no fueron entrenados para indonesio.

¿Cuánto cuesta el OCR de código abierto por página en una GPU?

Entre $0,049 y $0,381 por 1.000 páginas en una RTX 4090 a la tarifa registrada de RunPod de $0,76/hora — aproximadamente $0,00005 a $0,0004 por página, incluido el inicio de la ejecución, según el modelo.

¿Qué es SROIE y qué evalúa?

SROIE 2019 (Scanned Receipt OCR and Information Extraction) es el conjunto de datos de la competencia ICDAR 2019 de recibos escaneados reales en inglés con transcripción y anotaciones de campos clave — este benchmark utiliza su división de prueba fija de 361 muestras. Evalúa si un modelo de OCR puede leer el texto del recibo (CER/WER) y recuperar los campos de empresa, fecha, dirección y total; para los modelos de código abierto aquí, los campos se recuperaron mediante un posprocesador de regex fijo porque ninguno emite campos estructurados nativos.

¿Puedo reproducir estos resultados del benchmark por mi cuenta?

Sí. El protocolo del benchmark está versionado y congelado, todos los conjuntos de datos están disponibles públicamente (SROIE de ICDAR 2019, CORD v2 de Clova AI), y los cinco modelos son de código abierto con versiones publicadas. El paquete completo de artefactos — predicciones, métricas, manifiestos, registros de rendimiento — está disponible bajo petición. Una advertencia: los manifiestos actuales son anteriores a la huella de entorno del esquema v2 y sería necesario volver a ejecutar en los entornos exactos de los modelos para una reproducibilidad byte por byte completa; consulte Limitaciones.

Metodología y fuentes

Protocolo

Este benchmark sigue un protocolo versionado y congelado (v0.1, 2026-08-11). Cada número en esta página se remonta a un artefacto de predicción específico producido bajo el protocolo, y cada ejecución cumple el mismo conjunto de puertas de publicación: run_tier=official, expected_split=test, sin predicciones faltantes, y todas las métricas not_applicable preservadas tal cual (no convertidas a cero). Una auditoría de calidad (2026-08-12) verificó todos los contratos de predicción, hashes de muestras y hashes de rendimiento.

Entorno de ejecución

Cómo reproducir

El código del benchmark, los ejecutores y los evaluadores se mantienen en el repositorio ImageToTable.ai benchmark-ocr (commit de Git 8bdc616; publicación pública pendiente). Los comandos exactos que produjeron cada número en esta página:

export BENCHMARK_RUN_TIER=official
export BENCHMARK_EXPECTED_SPLIT=test
export BENCHMARK_MEASUREMENT_MODE=warm_then_scored
export BENCHMARK_GPU_LABEL="rtx_4090"
export BENCHMARK_GPU_PROVIDER="runpod"
export BENCHMARK_GPU_HOURLY_USD="0.76"
export BENCHMARK_FIELD_POSTPROCESSOR=sroie_receipt_regex

for model in tesseract paddleocr easyocr doctr docling; do
  BENCHMARK_WARMUP_SAMPLES=sroie_warmup_5.jsonl \
    bash server/run_model.sh "$model" sroie 361 "receipt-v1-sroie-${model}"
done

unset BENCHMARK_FIELD_POSTPROCESSOR

for model in tesseract paddleocr easyocr doctr docling; do
  BENCHMARK_WARMUP_SAMPLES=cord_v2_warmup_5.jsonl \
    bash server/run_model.sh "$model" cord_v2 100 "receipt-v1-cord-v2-${model}"
done

Todos los modelos se usaron out-of-the-box con configuraciones predeterminadas. Sin fine-tuning, sin paquetes de idioma personalizados, sin adaptaciones posteriores al entrenamiento. Consulte el repositorio del benchmark para ver los scripts de ejecución por modelo y la configuración del entorno.

Definiciones de métricas

• CER (tasa de error de caracteres): distancia de edición de Levenshtein a nivel de caracteres dividida por el recuento de caracteres de referencia (menor es mejor). IC bootstrap del 95 % mediante 2.000 remuestreos, semilla 20260811.
• WER (tasa de error de palabras): distancia de edición de Levenshtein a nivel de palabras (tokenización por espacios en blanco) dividida por el recuento de palabras de referencia (menor es mejor). Mismo método de IC que el CER.
• F1 de campo (solo SROIE): media armónica de precisión y exhaustividad en los cuatro campos de SROIE (empresa, fecha, dirección, total), extraídos del texto de OCR mediante un posprocesador de expresiones regulares fijo (sroie_receipt_regex). NO es la salida nativa de campos estructurados del modelo — los cinco modelos tienen no aplicable para métricas de campos nativos.
• Latencia p50 / p95: tiempo de inferencia por página (ms) a partir de registros de predicción exitosos, excluyendo la inicialización del ejecutor.
• Páginas/min en tiempo real: total de muestras puntuadas dividido por el tiempo total de ejecución, incluido el inicio del proceso del ejecutor. Mayor es mejor.
• Costo por 1.000 páginas: tiempo de ejecución (horas) × $0,76 × (1.000 / recuento de muestras). Utiliza metadatos reales de precios del proveedor, no tarifas estimadas.
• Tasa de éxito: 100 % en las 10 ejecuciones de este lote (0 errores, 0 tiempos de espera agotados, 0 predicciones faltantes).

Conjuntos de datos

1. SROIE 2019 (Scanned Receipt OCR and Information Extraction) — ICDAR 2019 Robust Reading Competition, Task 3. 361 recibos escaneados reales en inglés con transcripción de texto a nivel de línea y etiquetas de verdad fundamental de cuatro campos clave (empresa, fecha, dirección, total). División de prueba fija.
2. CORD v2 (Consolidated Receipt Dataset) — Clova AI Research, NAVER Corp. 100 muestras revisadas de recibos en indonesio de la división de prueba pública, utilizadas como prueba de esfuerzo entre idiomas. Incluye elementos de menú anidados y verdad fundamental de subtotal/total (no puntuados en este lote — requiere emisores nativos de campos estructurados).

Modelos evaluados

Acceso a los artefactos y reproducibilidad

Código fuente del benchmark: se mantiene en el repositorio benchmark-ocr (commit de Git 8bdc616). El repositorio incluye scripts de ejecución por modelo, evaluadores (CER/WER, métricas de campo, IC bootstrap), manifiestos de muestra de datos con hashes SHA256 y el protocolo congelado. La publicación pública está pendiente — una vez publicada, cada cifra de esta página será reproducible de forma independiente clonando el repositorio, obteniendo los conjuntos de datos públicos y ejecutando los comandos anteriores en una RTX 4090.

Paquete completo de artefactos: predicciones por modelo (*.jsonl), métricas con IC del 95 % (metrics.csv), diagnósticos a nivel de campo (field_details.csv), registros de rendimiento en tiempo real (performance.json) y manifiestos de ejecución (manifest.json) están versionados bajo el protocolo y disponibles junto con el código fuente. Contacte con [email protected] para obtener acceso anticipado antes de la publicación pública.

Nota sobre el esquema v1: los manifiestos actuales son anteriores a la huella de entorno del esquema v2 (que captura el sistema operativo, la versión de CUDA y las versiones de paquetes de Python por modelo en tiempo de ejecución). La tabla de entorno anterior refleja lo que registra el esquema v1; la reproducibilidad byte por byte completa requerirá una nueva ejecución con el esquema v2. Esto no afecta a la corrección de las métricas notificadas.

Limitaciones

• Esquema de manifiesto v1: los manifiestos de ejecución actuales son anteriores a la huella de entorno del esquema v2, que captura el entorno exacto de Python en tiempo de ejecución. La reproducibilidad byte por byte completa requiere una nueva ejecución con el esquema v2 en los entornos de modelo exactos.
• Las métricas de campo de SROIE son posprocesadas con regex, no extracción nativa: el F1 de campo mide la recuperación de campos a partir del texto de OCR mediante patrones fijos — no es la capacidad nativa de campos estructurados de los modelos (que no está disponible para ningún modelo en este lote).
• Los resultados de CORD son una prueba de estrés por desajuste de idioma, no una clasificación de precisión: los cinco modelos están entrenados en inglés; los valores de CER de CORD (90 %+) cuantifican el colapso entre idiomas y no deben fusionarse con SROIE en una única tabla de clasificación.
• PaddleOCR-VL excluido de la clasificación: excluido debido a problemas directos en el pipeline; sus resultados no son comparables con los cinco modelos clasificados.
• Surya2 y Unlimited-OCR no incluidos: requieren un Pod de servidor vLLM y están planificados para un lote v1.1; la versión actual cubre solo el grupo local_torch.
• Solo nivel de GPU única: todas las ejecuciones son RTX 4090; aún no hay comparación con múltiples GPU o RTX 3090/A100, por lo que las conclusiones de costo/rendimiento son específicas de este único nivel.
• Solo modelos de código abierto: no se incluyen modelos en la nube/API (AWS Textract, Google Document AI, Azure Form Recognizer); su comparación es un benchmark planificado por separado.

Referencias relacionadas: Precisión de OCR en recibos · Precisión de OCR por tipo de documento · ¿Qué es el OCR?

Lecturas relacionadas: ABBYY FineReader vs OCR moderno con IA · Adobe Acrobat OCR vs extracción con IA · Cómo interpretar las afirmaciones de precisión de OCR