docTR vs Surya2: OCR de recibos
Comparativa directa (2026)

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.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 palabras. Esta es la dimensión en la que 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 precisión de caracteres en bruto 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 palabras y un reconocedor las transcribe, preservando las mayúsculas y el diseño originales del texto impreso. Surya2 es un modelo de lenguaje de visión para procesamiento de documentos: lee la imagen completa del documento y genera texto comprendido — con normalización de mayúsculas, pares etiqueta/valor fusionados, líneas reordenadas — lo cual está más cerca de lo que los sistemas posteriores necesitan, pero más lejos de coincidencias exactas de caracteres. CER mide 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 se completaron con error_rate 0.0.

Donde Divergen: La Extracción de Campos Estándar Invierte el Resultado

Evalúe el texto bruto de los motores con los mismos patrones regex fijos en los cuatro campos de los recibos SROIE (empresa, fecha, dirección, total) — el enfoque tradicional de OCR + extracción de información clave (KIE) basada en reglas — y la clasificación se invierte: Surya2 extrae campos con un F1 de valor de campo de 0.3183 frente al 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 de texto y la precisión de 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 que 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 (conversión a minúsculas, fusión de clave-valor) coincide con esos patrones con mucha más frecuencia, mientras que el texto de línea bruto de docTR — preciso según CER, pero con mayúsculas originales 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 más la extracción posterior basada en reglas, no la salida estructurada nativa.

Fuente: field_method_comparison.csv — columnas regex_field_value_f1 / llm_field_value_f1, filas 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, filas sroie_2019. Estas son 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 de tener el segundo mejor CER.

La palanca del LLM: la elección del motor deja de importar

Alimente 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 campo casi desaparece: docTR 0.6171 frente a Surya2 0.6139 en 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 observado en el benchmark completo de ocho motores: el postprocesamiento con LLM lleva a los motores saludables a una banda convergente de F1 de campo porque comprende la semántica (números, fechas, nombres) en lugar de comparar formas de caracteres. El texto base más limpio de docTR se adelanta por poco; la estructura normalizada de Surya2 pierde esa pequeña ventaja bajo el LLM. Dos costos acompañan a esta palanca: una llamada al 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 API e idénticos en naturaleza), y no rescata texto que un motor fundamentalmente no logró 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 API y separada de la latencia del motor (summary_metrics.csv latency_p50_ms).

El Envolvente Operativo: Donde Vive la Diferencia Real

La precisión de caracteres empata, la precisión de campos converge bajo un LLM — pero una canalización por lotes no se preocupa por ninguna de las dos si los números no terminan. En la misma RTX 4090 a la misma tarifa registrada de $0.76/hora, docTR mantiene 449.3 páginas/min a 108.7 ms p50 por página por $0.048 por 1,000 páginas; 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×. Una canalización dimensionada para el ritmo de Surya2 es una conversación de arquitectura diferente a una que dimensiona el ritmo de docTR.

El costo se calcula como tiempo de ejecución de pared × la tarifa de RTX 4090 de RunPod ($0.76/hora, precio con marca de tiempo en los manifiestos de ejecución), incluida la inicialización del modelo — el precio que realmente pagaría por el tiempo de GPU. El rendimiento es páginas por minuto en tiempo de pared, incluida esa misma inicialización. La latencia p50/p95 son tiempos de inferencia por página en estado estable, medidos en caliente y luego puntuados (se excluye 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 de pared × $0.76/hora, incluida la inicialización del modelo, precio con marca de tiempo en los manifiestos de ejecución (agosto de 2026).

Tabla: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, filas sroie_2019. Ambos motores en GPU (RTX 4090, $0.76/h con precio registrado 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 de Indonesia): Ambos motores colapsan, aislados por protocolo

Ninguno de los motores fue entrenado predominantemente con recibos de Indonesia, por lo que CORD v2 (100 muestras, campos anidados menú/subtotal/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 del benchmark, los números de CORD se mantienen aislados de la comparación SROIE — no se fusionan en ninguna clasificación — porque el texto de referencia de CORD incorpora estructura de anotación, lo que infla el CER bruto para cada motor además del genuino desajuste de idioma.

En las métricas de campo se mantiene el mismo patrón de divergencia de SROIE, comprimido: mediante patrones regex, docTR no recupera ningún campo (0.0000 F1 de campo — un cero literal en el CSV, no un valor faltante) porque los patrones en formato inglés no coincidieron con nada en el texto indonesio, mientras que la salida normalizada de Surya2 extrae 0.2458. El LLM luego vuelve a converger el par a 0.5500 (docTR) y 0.5203 (Surya2) — el choque de idioma lo absorbe el postprocesador, no el motor. CORD se cita aquí para contexto de robustez lingüística; deliberadamente nunca se agrupa con los números de SROIE en una única tabla de clasificación.

Tabla: summary_metrics.csv (cer) y field_method_comparison.csv (F1 de campo), filas cord_v2. No combine estos números en ninguna clasificación SROIE: el CER de CORD combina un desajuste genuino de idioma con la inflación por estructura de anotación en la referencia; los patrones regex se escribieron para formatos en inglés. El F1 de campo 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 resumida

«Mejor» depende de la carga de trabajo. Estos dos motores dividen los ejes con claridad, y esa división es el hallazgo: la precisión de caracteres empata, la conveniencia de campos estructurados favorece a Surya2, todos los ejes de costo/latencia/rendimiento favorecen 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 de sroie_2019). Donde difieren es en la salida de campos estructurados lista para usar (Surya2 gana 4.2× con regex) y en el entorno 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 bruto y limpio — conservando mayúsculas y separadores originales — y los patrones regex fijos, escritos para valores formateados, fallan en su mayoría contra él: su F1 de campo regex de SROIE es 0.0766, el más bajo de los ocho motores en la ejecución subyacente, frente al segundo mejor CER (0.1971) (summary_metrics.csv cer, field_method_comparison.csv regex_field_value_f1). La salida de Surya2, con minúsculas y estructura etiquetada, coincide con los patrones en 0.3183. Alimenta ambos a un LLM y la brecha se reduce a 0.003 — el regex, no el OCR, era el cuello de botella.

¿Añadir un postprocesador LLM iguala a docTR y Surya2?

Casi exactamente — docTR 0.6171 vs Surya2 0.6139 en F1 de campo LLM en SROIE (field_method_comparison.csv, llm_field_value_f1, filas de sroie_2019). El costo de esa convergencia es ~2.0–2.3 s adicionales de latencia LLM mediana por documento (llm_median_latency_ms, mismas filas), adecuado 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/hora (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, filas de sroie_2019).

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

Dos causas que se combinan y que el protocolo de referencia mantiene separadas de la clasificación SROIE: un desajuste lingüístico real (recibos indonesios fuera del enfoque de entrenamiento de ambos motores) y una inflación de la estructura de anotación dentro del texto de referencia de CORD — la CER se sitúa en 0.9101 (docTR) y 0.8959 (Surya2) (summary_metrics.csv, cer, filas cord_v2). Las métricas de campo absorben parte del impacto una vez que se añade un LLM (0.5500 frente a 0.5203), pero las filas CORD se citan y nunca se agrupan en ninguna clasificación combinada.

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

Depende del eje que consuma su pipeline. Para texto bruto a gran volumen con coste medido, el envolvente 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 de Surya2 de serie (0.3183 frente a 0.0766) es el mejor punto de partida. Para calidad final de campo con postprocesamiento LLM la elección apenas importa (0.6171 frente a 0.6139). Estos resultados se mantienen para recibos en inglés e indonesio en un nivel de GPU en agosto de 2026; cualquier decisión de producción debería re-ejecutarse sobre 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, coste, rendimiento) y results/field_method_comparison.csv (regex frente a 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 conjuntos de datos provienen de los artículos SROIE 2019 y CORD citados abajo.

Metodología y fuentes

Protocolo

Esta página informa sobre un segmento comparativo directo de una ejecución de referencia independiente y reproducible (nivel oficial) — no es un resumen de afirmaciones de terceros ni una página de comparación de proveedores. Solo divisiones de prueba fijas: prueba SROIE 2019 (361 recibos en inglés, campos planos empresa/fecha/dirección/total) y prueba 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 puntuada, por lo que las cifras de latencia son de estado estable). Ambas ejecuciones se 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 ocho motores se publican por separado en Traditional OCR vs Document Parsing VLMs.

Entorno de ejecución

• Hardware: ambos motores se ejecutaron en la misma NVIDIA RTX 4090 (24 GB); el costo de GPU se calculó a la tarifa bajo demanda de RunPod de $0.76/hora, con el precio con marca de tiempo en el manifiesto redactado de cada ejecución (agosto de 2026).
• Motores: listos para usar, sin ajuste fino. Versiones fijadas: 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 pared × $0.76/hora, incluida la inicialización del modelo — el procesamiento por lotes reduce el costo por página.
• Postprocesamiento de campos: las métricas de campos regex de SROIE son postprocessed_sroie_receipt_regex_* (columnas regex_* de field_method_comparison.csv) — campos extraídos del texto de OCR mediante un conjunto de patrones fijos. Miden OCR + extracción posterior, no salida estructurada nativa de ninguno de los modelos; las columnas LLM_* miden texto de OCR + extracción con LLM. Los dos flujos 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 referencia, dividida por los caracteres de la verdad de referencia. Cuanto menor, mejor. Sensible a mayúsculas y convenciones de formato — ligeramente conservador frente a la salida normalizada de Surya2 (plegado 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 usando patrones regex fijos sobre el texto OCR (pipeline KIE tradicional basado en reglas + OCR). Columna: regex_field_value_f1. Una puntuación de 0 significa que no se recuperó ningún valor de campo.
• F1 de valor de campo (LLM): la misma métrica sobre la salida del postprocesador LLM (texto 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 de tiempo real incluyendo la 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/hora.

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 proviene de las filas 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, exactitud de campos de documento, llm_median_latency_ms, recuentos de tokens. Cada número de F1 de campo regex/LLM proviene de las filas doctr y surya2 aquí.
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que aloja los CSV de resultados, manifiestos de ejecución redactados, protocolo congelado y listas de muestra de conjuntos de datos (divisiones de prueba fijas) para reproducción.
4. results/manifests/ (GitHub). Un manifest.json redactado por ejecución publicada (16 ejecuciones) con versiones de modelo, GPU/controlador, versiones de torch/CUDA/Python, metadatos de costo con marca de tiempo 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, tablas, fórmulas o documentos largos donde los VLM de análisis de documentos afirman sus mayores ventajas; los puntos fuertes promocionados de Surya2 están sin medir. No use esta página para concluir que «docTR gana en todo».
• Tamaño de la 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 (incluida la brecha de CER de 0.006 y la de F1-LLM 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/hora, con precio con marca de tiempo 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 postprocesador LLM: todas las filas de LLM usan deepseek-v4-flash a temperatura 0. Un LLM diferente cambia el F1 absoluto de campo; el orden de convergencia puede variar en los márgenes. La latencia del LLM (~2.0–2.3 s de mediana, llm_median_latency_ms en field_method_comparison.csv) la incurre 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 puntuar más alto 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: la verdad de referencia de CORD incorpora estructura de anotación y ninguno de los dos motores se entrenó predominantemente en indonesio; el CER de CORD (0.90–0.91) refleja desajuste de idioma + inflación de la verdad de referencia. Las filas de CORD se citan con contexto y nunca se fusionan en ninguna clasificación de SROIE (regla del protocolo).
• Equidad del CER para VLM: el CER puntúa coincidencias exactas de caracteres, por lo que la salida de Surya2 con plegado de mayúsculas y etiquetas fusionadas se penaliza levemente por convenciones de salida, no por errores de lectura (consulte la referencia relacionada sobre CER). Por lo tanto, el empate en CER subestima ligeramente a Surya2; las métricas de campo son la medida más justa entre familias.
• Solo dos motores: este cara a cara excluye deliberadamente los otros seis motores de la ejecución subyacente, los servicios de OCR por API en la nube y las API de VLM alojadas; sus modelos de latencia y precios difieren fundamentalmente de los motores locales medidos aquí.
• Fijación de versiones: los resultados corresponden a docTR v1.0.1 y Surya2 0.22.1 (agosto de 2026). Las versiones más recientes de cualquiera de los motores pueden cambiar cada número de esta página.

Referencias relacionadas: OCR tradicional vs VLM de análisis de documentos · dónde falla el regex en documentos reales · por qué los recuentos de caracteres engañan en la extracción de campos · Precisión del OCR de recibos

Lectura relacionada: Precisión del OCR con IA vs OCR clásico · extracción de datos de imágenes vs motores de OCR · Precios de extracción de documentos con IA (2026)