docTR vs Surya2: OCR de Recibos
Comparativa Directa (2026)

La Tasa de Error de Caracteres es la medida clásica de OCR: inserciones, eliminaciones y sustituciones divididas por los caracteres de la verdad de referencia — un CER de 0.197 significa aproximadamente 19.7 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. Esta es la dimensión donde los dos motores son inseparables.

En SROIE 2019, docTR y Surya2 son los dos reconocedores de caracteres más fuertes del benchmark, separados por 0.006 puntos — dentro de la banda de ruido para un corpus de 361 muestras. WER cuenta la misma historia: Surya2 0.2735, docTR 0.3199. La narrativa de que "los VLM superan al OCR tradicional" no sobrevive a esta comparación en la precisión de caracteres cruda de recibos en inglés.

Precisión de Caracteres: Un Empate Estadístico

El empate importa porque los dos motores son arquitectónicamente opuestos. docTR es un pipeline de OCR neuronal tradicional en dos etapas: un detector localiza las palabras y un transcriptor las transcribe, preservando el caso y la disposición del texto impreso. Surya2 es un modelo de lenguaje visual para documentos: lee la imagen del documento completo y produce texto procesado — con el caso unificado, pares etiqueta/valor fusionados, líneas reordenadas — lo cual es más cercano a lo que los sistemas posteriores necesitan pero más lejos de las coincidencias exactas de caracteres. CER mide las coincidencias exactas de caracteres, por lo que es ligeramente conservador contra Surya2; el hecho de que el empate sobreviva a pesar de esa asimetría es lo que lo hace significativo.

Tabla: summary_metrics.csv — columnas cer y wer, filas sroie_2019. Valores exactos: docTR cer 0.19707 / wer 0.31990; Surya2 cer 0.19147 / wer 0.27352. Menor es mejor; ambas ejecuciones completadas con error_rate 0.0.

Dónde divergen: La extracción de campos fuera de la caja invierte el resultado

Ponga a prueba el texto crudo de los motores con los mismos patrones regex fijos en los cuatro campos de 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: Surya2 extrae campos con 0.3183 F1 de campo frente a 0.0766 de docTR, una ventaja de 4.2×. docTR tiene la mejor precisión de caracteres de su clase y la peor extracción de campos por regex en la ejecución de ocho motores — la precisión del texto y la precisión de los campos están desacopladas.

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 nada. El mecanismo detrás de la inversión es la diferencia en la forma de salida descrita anteriormente. Las expresiones regulares se escribieron para valores formateados como RM 12.00 o 14/08/2020; la salida normalizada y estructurada por etiquetas de Surya2 (con cajas plegadas, clave-valor fusionadas) coincide con esos patrones con mucha más frecuencia, mientras que el texto de línea crudo de docTR — preciso por CER, pero con el formato original y ruido de separadores — los derrota. Las columnas de "extracción de campos por regex" son las métricas postprocessed_sroie_receipt_regex_* del benchmark: miden el texto OCR + la extracción basada en reglas posterior, no la salida estructurada nativa.

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, filas sroie_2019. Estas son las métricas postprocessed_sroie_receipt_regex_*: patrones fijos aplicados al texto OCR de cada motor (postprocesado, no extracción nativa). El F1 de campo regex de docTR de 0.0766 es el más bajo de los ocho motores en la ejecución subyacente a pesar del segundo mejor CER.

La Palanca del LLM: La Elección del Motor Deja de Importar

Alimenta el texto OCR de ambos motores a un postprocesador LLM (deepseek-v4-flash, temperatura 0) con un prompt de extracción estructurada, y la brecha de campos casi desaparece: docTR 0.6171 vs Surya2 0.6139 F1 de campo — una ventaja de 0.003 puntos para el motor tradicional, un empate en la práctica. El postprocesador, no el motor OCR, se convierte en el componente decisivo.

Este es el mismo patrón visto en el benchmark completo de ocho motores: el postprocesamiento LLM arrastra motores saludables a una banda convergente de F1 de campo porque entiende la semántica (números, fechas, nombres) en lugar de coincidir con formas de caracteres. El texto base más limpio de docTR se adelanta por un pelo; la estructura normalizada de Surya2 pierde esa pequeña ventaja bajo el LLM. Dos costos vienen con la palanca: una llamada LLM añade aproximadamente 2.0–2.3 s de latencia mediana por documento además del tiempo de OCR (1,996.3 ms para el texto de docTR, 2,261.7 ms para el de Surya2, incurridos por la API y de naturaleza idéntica), y no rescata texto que un motor falló fundamentalmente en leer.

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 es incurrida por la API y separada de la latencia del motor (summary_metrics.csv latency_p50_ms).

El Rango Operativo: Donde Radica la Diferencia Real

La precisión de caracteres empata, la precisión de campos converge bajo un LLM — pero un pipeline por lotes no se preocupa por ninguno de los dos si los números no terminan. En la misma RTX 4090 a la misma tarifa registrada de $0.76/hr, docTR mantiene 449.3 páginas/min a 108.7 ms p50 por página por $0.048 por 1,000 páginas; Surya2 mantiene 12.1 páginas/min a 2,668.0 ms p50 por $1.061 por 1,000 páginas — una brecha de rendimiento de 37×, una brecha de latencia de 24.5× y una brecha de costo de 22.2×. Un pipeline dimensionado para el ritmo de Surya2 es una conversación de arquitectura diferente a uno dimensionado para el ritmo de docTR.

El costo se calcula como 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 — el precio que realmente pagarías por el tiempo de GPU. El rendimiento son páginas por minuto en tiempo real 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 Surya2 es proporcionalmente peor — 5,872.2 ms p95 frente a los 281.4 ms de docTR — porque los picos de prefill/decode del VLM dominan la cola en las primeras páginas.

Fuente: summary_metrics.csv — columna latency_p50_ms, filas sroie_2019. docTR 108.7166, Surya2 2667.9800. Latencia en estado estable (modo de medición warm_then_scored).

Fuente: summary_metrics.csv — columna cost_per_1000_pages, filas sroie_2019. docTR 0.0479, Surya2 1.0609. 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).

Tabla: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, filas sroie_2019. Ambos motores GPU (RTX 4090, precio de $0.76/hr con marca de tiempo en los manifiestos); el costo incluye la inicialización del modelo, no el rendimiento puro en estado estable. Valores exactos: docTR p50 108.7 / p95 281.4 / 449.3 pg/min / $0.0479; Surya2 p50 2668.0 / p95 5872.2 / 12.1 pg/min / $1.0609.

CORD (Recibos Indonesios): Ambos Motores Colapsan, Cuarentenados por Protocolo

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: CER 0.8959 (Surya2) y 0.9101 (docTR). Según el protocolo de referencia, los números de CORD se mantienen en cuarentena de la comparación con SROIE — no se fusionan en ninguna clasificación — porque el texto de referencia de CORD incrusta estructura de anotación, lo que infla el CER bruto para cada motor además del desajuste lingüístico genuino.

En las métricas de campo, el mismo patrón de divergencia de SROIE se mantiene, comprimido: a través de patrones regex, docTR recupera ningún campo (0.0000 field F1 — 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 la salida normalizada de Surya2 alcanza 0.2458. El LLM luego reconverge el par a 0.5500 (docTR) y 0.5203 (Surya2) — el choque lingüístico es absorbido por el postprocesador, no por el motor. CORD se cita aquí por su contexto de robustez lingüística; se omite deliberadamente de la agrupación con los números de SROIE en una única tabla de clasificación.

Tabla: summary_metrics.csv (cer) y field_method_comparison.csv (field F1), filas cord_v2. No fusionar estos números en ninguna clasificación de SROIE: el CER de CORD combina el desajuste lingüístico genuino con la inflación de la estructura de anotación en la verdad de referencia; los patrones regex fueron escritos para formatos en inglés. El field F1 de regex de docTR de 0.0000 es un cero literal registrado en el CSV, no un valor faltante.

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

"Mejor" depende de la carga de trabajo. Estos dos motores dividen los ejes de forma clara, y la división es el hallazgo: precisión de caracteres empatada, comodidad de campos estructurados favorece a Surya2, cada eje de costo/latencia/rendimiento favorece a docTR, y un postprocesador LLM hace que la elección del motor sea casi irrelevante para la calidad final de los campos.

Preguntas Frecuentes

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

No — en precisión bruta de caracteres están estadísticamente empatados: CER de SROIE 0.1915 vs 0.1971 (docTR), una diferencia de 0.006 puntos (summary_metrics.csv, cer, filas sroie_2019). Donde difieren es en la salida de campos estructurados listos para usar (Surya2 gana 4.2× con regex) y en el rango operativo (docTR gana 24.5× en latencia, 22.2× en costo, 37× en rendimiento).

¿Por qué docTR tiene la mejor precisión de caracteres pero la peor extracción de campos con regex?

Porque las dos métricas evalúan salidas diferentes. docTR devuelve texto de línea crudo limpio — preservando mayúsculas y separadores originales — y los patrones regex fijos, escritos para valores formateados, fallan mayormente contra él: su F1 de campos con regex en SROIE es 0.0766, el más bajo de los ocho motores en la ejecución base, frente al segundo mejor CER (0.1971) (summary_metrics.csv cer, field_method_comparison.csv regex_field_value_f1). La salida de Surya2, con mayúsculas normalizadas y estructura de etiquetas, coincide con los patrones en 0.3183. Al alimentar ambos con un LLM, la brecha se reduce a 0.003 — el regex, no el OCR, era el cuello de botella.

¿Agregar un postprocesador LLM iguala a docTR y Surya2?

Casi exactamente — docTR 0.6171 vs Surya2 0.6139 F1 de campos con LLM en SROIE (field_method_comparison.csv, llm_field_value_f1, filas sroie_2019). El costo de esa convergencia es una latencia LLM adicional de ~2.0–2.3 s mediana por documento (llm_median_latency_ms, mismas filas), adecuada para procesamiento por lotes asíncrono en lugar de esperas síncronas por página.

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

24.5× menor latencia p50 (108.7 ms vs 2,668.0 ms), 37× mayor rendimiento (449.3 vs 12.1 páginas/min), y 22.2× menor costo por 1,000 páginas ($0.048 vs $1.061) en la misma RTX 4090 a $0.76/hr (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, filas sroie_2019).

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

Dos causas acumulativas que el protocolo de referencia mantiene separadas del ranking SROIE: una verdadera incompatibilidad lingüística (recibos indonesios fuera del enfoque de entrenamiento de ambos motores) e inflación en la estructura de anotación dentro del texto de referencia de CORD — el CER llega a 0.9101 (docTR) y 0.8959 (Surya2) (summary_metrics.csv, cer, cord_v2 rows). Las métricas de campo absorben parte del impacto una vez que se añade un LLM (0.5500 vs 0.5203), pero las filas de CORD se citan y nunca se agrupan en ningún ranking combinado.

¿Qué motor debe elegir un pipeline de recibos, docTR o Surya2?

Depende del eje que consuma su pipeline. Para texto bruto a gran volumen con costo medido, el rendimiento de docTR (108.7 ms, 449.3 páginas/min, $0.048/1K páginas) domina. Para campos estructurados sin ningún postprocesador, el F1 de regex listo para usar de Surya2 (0.3183 vs 0.0766) es el mejor punto de partida. Para calidad final de campos con postprocesamiento LLM la elección apenas importa (0.6171 vs 0.6139). Estos resultados son válidos para recibos en inglés e indonesio en un nivel de GPU en agosto de 2026; cualquier decisión de producción debe re-ejecutarse en el corpus objetivo (ver Limitaciones).

¿De dónde provienen los números de esta página?

Cada cifra es una fila de los CSV publicados del benchmark de primera parte — results/summary_metrics.csv (CER/WER, F1 de campo, latencia, costo, rendimiento) 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 artículos de SROIE 2019 y CORD citados a continuación.

Metodología y Fuentes

Protocolo

Esta página presenta un corte directo de un benchmark independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros ni una página de comparación de proveedores. Solo se usaron divisiones de prueba fijas: SROIE 2019 test (361 recibos en inglés, campos planos empresa/dirección/total) y CORD v2 test (100 recibos en indonesio, campos anidados menú/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 (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 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ó con la tarifa bajo demanda de RunPod de $0.76/hr, con marca de tiempo del precio en el manifiesto redactado de cada ejecución (agosto de 2026).
• Motores: listos para usar, sin ajuste fino. Versiones bloqueadas: docTR v1.0.1 (OCR neuronal tradicional de dos etapas, GPU) y Surya2 (surya-ocr 0.22.1) (VLM de análisis de documentos, servido con vLLM) — 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 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 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 flujos de trabajo 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 fundamental, dividida por los caracteres de la verdad fundamental. Menor es mejor. Sensible a las convenciones de mayúsculas y formato — ligeramente conservador con la salida normalizada de Surya2 (unificación de mayúsculas, fusión de etiqueta/valor).
• WER (Tasa de Error de Palabras): el mismo cálculo de distancia de edición a nivel de palabra.
• F1 de valor de campo (regex): media armónica de precisión/recuperación sobre los valores de campo extraídos utilizando patrones regex fijos en el texto OCR (pipeline tradicional de OCR + 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.
• Costo por 1,000 páginas: horas de GPU facturadas por 1,000 páginas a la tarifa registrada de $0.76/hr.

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 doctr y surya2 aquí.
2. field_method_comparison.csv (GitHub raw). 16 filas; columnas model, dataset, llm_model (= deepseek-v4-flash), precisión y F1 de valor de campo regex/llm, document-fields-exact, llm_median_latency_ms, recuentos de tokens. Cada número de F1 de valor de campo regex/LLM se remonta a las filas de doctr y surya2 aquí.
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 del modelo, GPU/controlador, versiones de torch/CUDA/Python, metadatos de costos con marca de tiempo de precio y hashes de artefactos.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definición del conjunto de datos SROIE 2019, estructura de tareas y licencia (CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definición del conjunto de datos CORD v2, esquema de campos anidados y licencia (CC-BY-4.0).

Limitaciones

• Alcance del documento — solo recibos: SROIE + CORD. Nada aquí mide el manejo de diseño/tabla/fórmula/documentos largos donde los VLMs de análisis de documentos reclaman sus mayores ventajas; las fortalezas comercializadas de Surya2 son no medidas. No use esta página para concluir "docTR 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 unos pocos centésimos (incluyendo la brecha de CER de 0.006 y la brecha de LLM-F1 de 0.003) deben tratarse como ruido, no como verdad de ingeniería.
• Un solo nivel de GPU y un solo precio: todos los números 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 costo — recalcule los costos a las tarifas actuales antes de presupuestar.
• Un solo postprocesador LLM: todas las filas de LLM usan deepseek-v4-flash a temperatura 0. Un LLM diferente cambia el F1 de campo absoluto; el orden de convergencia puede moverse en los márgenes. La latencia del LLM (~2.0–2.3 s mediana, field_method_comparison.csv llm_median_latency_ms) es incurrida por la API y no es 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 puntuar más alto 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 incrusta la estructura de anotación y ninguno de los motores fue entrenado predominantemente en indonesio; el CER de CORD (0.90–0.91) refleja desajuste lingüístico + 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).
• Equidad del CER para VLMs: el CER puntúa las coincidencias exactas de caracteres, por lo que la salida de Surya2 con mayúsculas/minúsculas unificadas y etiquetas fusionadas está ligeramente penalizada por convenciones de salida, no por errores de lectura (ver referencia relacionada sobre CER). El empate de CER por lo tanto subestima ligeramente a Surya2; las métricas de campo son la barra inter-familia más justa.
• Solo dos motores: esta comparación directa excluye deliberadamente los otros seis motores de la ejecución subyacente, los servicios OCR en la nube/API y las APIs de VLM alojadas; sus modelos de latencia y precios difieren fundamentalmente de los motores locales medidos aquí.
• Fijación de versión: los resultados son válidos para docTR v1.0.1 y Surya2 0.22.1 (agosto de 2026). Versiones más recientes de cualquiera de los motores pueden cambiar todos los números de esta página.

Referencias relacionadas: OCR Tradicional vs VLMs de Análisis de Documentos · Regex vs Extracción de Campos con LLM · Precisión a Nivel de Campo vs a Nivel de Carácter · Precisión de OCR para Recibos

Lecturas relacionadas: 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)