docTR vs Docling en Recibos
Velocidad de Pasada Única vs Pipeline de Documentos (2026)

Qué es Docling (y qué no): OCR de paso único vs. una canalización de análisis

Los dos motores se sitúan en lados opuestos de una división arquitectónica fundamental, y esa división — no una diferencia de código ni de ajuste — es toda la historia de esta página. docTR es un motor de OCR neuronal de paso único: una etapa de detección localiza los cuadros delimitadores del texto y una etapa de reconocimiento transcribe los caracteres dentro de ellos, compuestos en un predictor de OCR cuyo pase hacia adelante produce líneas de texto crudas. No hay modelo de diseño, ni analizador de tablas, ni reconstrucción del orden de lectura — lo que se imprime es lo que sale, en el orden en que el reconocedor lo lee. Docling no es un motor de OCR ni un modelo de visión-lenguaje; es una canalización de análisis de documentos. Según su propio informe técnico (citado por contexto arquitectónico, no por ningún número en esta página), ejecuta una secuencia de modelos por página — análisis de diseño, detección de tablas, inferencia del orden de lectura — los agrega y ensambla un objeto de documento intermedio antes de emitir el texto, por lo que su salida lleva estructura (etiquetas, orden, zonas) que las líneas de docTR no tienen.

¿Por qué importa este mecanismo para un benchmark? Cada modelo escalonado en la cadena de Docling existe para explotar la estructura del diseño — una tabla que analizar, un formulario de dos columnas, una ruta de lectura que no es el orden léxico. Un recibo en inglés simple casi no tiene nada de eso: una sola columna, algunas zonas, una ruta mayormente predecible de arriba a abajo, sin tablas. La maquinaria escalonada aún se ejecuta en cada página — por eso es más lenta y costosa — pero sin estructura que explotar, la sobrecarga no puede convertirse en un mejor texto. Esta página aísla exactamente ese costo y muestra qué compra — y qué no.

Precisión de Caracteres: El Impuesto del Pipeline sobre el Texto Crudo

En SROIE 2019, la brecha del texto crudo no es pequeña: CER 0.1971 vs 0.5909 (Docling) — una penalización de 3.0× — y WER 0.3199 vs 0.7596. La Tasa de Error de Caracteres mide inserciones, eliminaciones y sustituciones divididas por los caracteres de la verdad de referencia — un CER de 0.197 significa ~19.7 caracteres mal leídos por cada 100; la Tasa de Error de Palabras aplica la misma lógica de distancia de edición a nivel de palabra. El 0.5909 de Docling se clasifica en el 7º de 8 motores en la ejecución subyacente, por delante solo de Unlimited-OCR (0.6552, columna cer de summary_metrics.csv, todas las filas de sroie_2019) — el enfrentamiento directo docTR-vs-Surya2 documentó a docTR como uno de los dos mejores reconocedores en este mismo benchmark, y esta página muestra que el mismo motor en el otro extremo de la tabla de precisión de texto es un pipeline, no una familia de reconocedores más débil.

Fuente: summary_metrics.csv — columnas cer y wer, filas sroie_2019. docTR cer 0.19707 / wer 0.31990; Docling cer 0.59092 / wer 0.75961. Menor es mejor. 361 muestras por motor; ambos error_rate 0.0.

Tabla: summary_metrics.csv — columnas cer / wer / error_rate, filas sroie_2019. Valores exactos: docTR cer 0.19707 / wer 0.31990; Docling cer 0.59092 / wer 0.75961. El CER de SROIE de Docling es el segundo peor de los ocho motores en la ejecución subyacente (por delante solo del 0.6552 de Unlimited-OCR) — la precisión de caracteres crudos es donde el impuesto del pipeline se manifiesta primero.

La Inversión: La Extracción de Campos con Regex Invierte el Resultado

Evalúa el texto de ambos 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 basada en reglas (KIE) — y la clasificación se invierte: Docling extrae campos con 0.2237 campo F1 frente a los 0.0766 de docTR, una ventaja de 2.9×. Estas son las métricas postprocessed_sroie_receipt_regex_* del benchmark: patrones fijos aplicados al texto OCR de cada motor — postprocesado, no la salida estructurada nativa de ninguno de los dos motores, y el modelo de documento nativo de Docling no se evalúa aquí.

El campo-valor F1 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 misma diferencia de arquitectura que causó la brecha de CER, pero funcionando en la dirección opuesta: el modelo de documento de Docling reordena el texto en una ruta de lectura y asocia etiquetas con valores, por lo que su texto emitido es más cercano en forma a lo que esperan los patrones fijos; el texto de líneas limpio pero crudo de docTR — preciso por CER, pero con el formato original y ruido de separadores y sin encuadre de etiquetas — vence a los patrones. El campo F1 de regex de docTR de 0.0766 es el peor de los ocho motores en la ejecución subyacente a pesar de su CER de mejor clase (columnas field_f1_regex y cer del summary_metrics.csv, todas las filas sroie_2019); el 0.2237 de Docling ocupa el sexto lugar. El mismo desacoplamiento documentado en la comparación directa del hermano en la parte superior de la escala de precisión (docTR vs Surya2) se repite aquí en la parte inferior: la precisión del texto no es la precisión de los campos.

Fuente: field_method_comparison.csv — columnas regex_field_value_f1 / llm_field_value_f1, filas sroie_2019 (decimales de 0–1 almacenados 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, no extracción estructurada nativa. Ningún motor obtiene los cuatro campos exactamente correctos mediante regex en ningún recibo SROIE individual (0.0000, un cero literal registrado en el CSV). El field F1 de regex de docTR de 0.0766 es el más bajo de los ocho motores en la ejecución base.

El Postprocesamiento con LLM Restaura la Clasificación — Parcialmente

Alimenta el texto de ambos motores a un postprocesador LLM (deepseek-v4-flash a temperatura 0) con un prompt de extracción estructurada, y docTR recupera la delantera: field F1 0.6171 vs 0.5685 — una ventaja de 0.049 puntos, pequeña comparada con la brecha de CER cruda pero no eliminada. El texto base más limpio hace superficie valores de campo más recuperables; el LLM compensa parcialmente los artefactos de diseño de Docling pero no los borra.

Esta es la misma banda de convergencia vista en el benchmark completo de ocho motores — el postprocesamiento con LLM acerca motores sanos porque entiende semántica (números, fechas, nombres) en lugar de coincidir formas de caracteres — y la brecha residual importa: el 0.6171 de docTR es el mejor field F1 con LLM de los ocho motores, mientras que el 0.5685 de Docling ocupa el sexto lugar (field_method_comparison.csv llm_field_value_f1, todas las filas sroie_2019). La barra más exigente — documentos donde todos los cuatro campos coinciden exactamente — los separa 2.7×: docTR 0.1496 vs Docling 0.0554. Dos costos vienen con la palanca: una llamada a LLM añade ~2.0–2.4 s de latencia mediana por documento además del tiempo de OCR (1,996.3 ms para el texto de docTR, 2,365.1 ms para el de Docling — incurridos por la API y de la misma naturaleza), y no puede rescatar 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 LLM es incurrida por la API y está separada de la latencia del motor (latencia_p50_ms en summary_metrics.csv). Ambas filas completadas con llm_ok_count 361.

El Envolvente Operativo: 6.7× Latencia, 7.9× Rendimiento, 8.3× Costo

El impuesto del pipeline es más pesado donde se planifica el rendimiento. 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; Docling mantiene 56.7 páginas/min a 732.0 ms p50 por $0.398 por 1,000 páginas — una brecha de latencia de 6.7×, una brecha de rendimiento de 7.9× y una brecha de costo de 8.3×. La cola es proporcionalmente peor para el pipeline: p95 281.4 ms vs 3,239.8 ms, una brecha de 11.5×, porque los modelos escalonados de Docling combinan sus tiempos de peor caso página a página.

El costo se calcula como tiempo de ejecución de reloj × 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 de reloj incluyendo esa misma inicialización. La latencia p50/p95 son tiempos de inferencia por página en estado estable medidos en caliente-para-puntuar (excluyendo la carga del modelo). docTR es el motor más rápido y el más barato de los ocho en la ejecución subyacente en SROIE; Docling, a 56.7 páginas/min y $0.398 por 1,000 páginas, se sitúa en la mitad inferior de la tabla del envolvente operativo (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, todas las filas sroie_2019).

Fuente: summary_metrics.csv — columnas latency_p50_ms / latency_p95_ms, filas sroie_2019. docTR p50 108.72 / p95 281.38; Docling p50 732.00 / p95 3239.79. Latencia en estado estable (modo de medición warm_then_scored, excluye carga del modelo).

Fuente: summary_metrics.csv — columna cost_per_1000_pages, filas sroie_2019. docTR 0.0479, Docling 0.3978. Costo = tiempo de ejecución de reloj × $0.76/hr incluyendo init del modelo, precio con marca de tiempo en manifiestos de ejecución (agosto 2026). docTR es el motor más barato de los ocho en la ejecución subyacente.

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 $0.76/hr con marca de tiempo en manifiestos); el costo incluye la inicialización del modelo. Valores exactos: docTR p50 108.72 / p95 281.38 / 449.31 pg/min / $0.0479; Docling p50 732.00 / p95 3239.79 / 56.66 pg/min / $0.3978.

CORD (Recibos Indonesios): Ambos Colapsan, la Recuperación de Campos por LLM de docTR Sigue Liderando

Ningún motor fue entrenado predominantemente en recibos indonesios, por lo que CORD v2 (100 muestras, campos anidados menu/sub_total/total) funciona como una prueba de estrés entre idiomas — y ambos colapsan en CER bruto: 0.9101 (docTR) y 0.9219 (Docling), un empate por desajuste de idioma. Según el protocolo de referencia, los números de CORD se mantienen en cuarentena de la comparación con SROIE — nunca 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 genuino desajuste de idioma.

En las métricas de campos, la única ventaja preservada de Docling se reduce a casi nada: mediante patrones regex, ambos motores recuperan casi ningún campo de CORD (docTR 0.0000 — un cero literal en el CSV — vs 0.0612 de Docling, porque los patrones de formato en inglés nunca se escribieron para texto indonesio). El postprocesador LLM absorbe el choque de idioma en ambos lados pero mantiene a docTR adelante: F1 de campos 0.5500 vs 0.4695. CORD se cita aquí por contexto de robustez lingüística; se omite deliberadamente de agruparse 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 de cord_v2. No fusiones los números de CORD en ningún ranking de SROIE: El CER de CORD combina una discrepancia lingüística genuina con una inflación de la estructura de anotación en el ground truth, y los patrones regex fueron escritos para formatos en inglés. El field F1 de docTR para CORD regex 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, y esta comparación directa divide los ejes claramente: en un recibo en inglés simple, todos los ejes de velocidad/costo y de texto bruto favorecen a docTR; la inversión de field regex fuera de la caja favorece a Docling; un postprocesador LLM los devuelve a una ventaja de 0.049 puntos para docTR; y las capacidades para las que existe Docling — diseño, tablas, orden de lectura, documentos largos — no se miden aquí, no se refutan.

Preguntas Frecuentes

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

No — en precisión de caracteres brutos, docling es 3,0 veces peor: SROIE CER 0,5909 vs 0,1971, y WER 0,7596 vs 0,3199 (summary_metrics.csv, cer / wer, filas sroie_2019). Docling “gana” solo en un eje medido: extracción de campos con regex sin configuración (0,2237 vs 0,0766 field F1) — y un postprocesador LLM invierte eso a favor de docTR (0,6171 vs 0,5685).

¿Por qué Docling extrae campos mejor con regex a pesar de un texto bruto mucho peor?

Porque las dos métricas evalúan cosas diferentes, y la forma de la salida de Docling coincide con los patrones. El pipeline de documentos de Docling reordena el texto en una ruta de lectura y asocia etiquetas con valores, por lo que su texto emitido está estructuralmente más cerca de lo que esperan los patrones regex fijos; docTR emite texto de línea bruto limpio que es preciso por CER pero derrota los patrones (0,0766 field F1, el peor de los ocho motores, frente a un CER de mejor clase). Estas son puntuaciones postprocessed_sroie_receipt_regex_* — texto OCR ejecutado a través de patrones fijos — no salida estructurada nativa (field_method_comparison.csv, regex_field_value_f1, filas sroie_2019). Esta desacoplamiento de precisión de texto ≠ precisión de campos aparece en todo este benchmark.

¿Por qué Docling es mucho más lento y costoso por página?

Porque ejecuta un pipeline de documentos por etapas — análisis de diseño, detección de tablas, reconstrucción del orden de lectura y un modelo de documento intermedio — en cada página, incluso cuando la página es un recibo simple sin estructura que explotar. En SROIE ese costo se mide en 6,7 veces en p50 (108,7 vs 732,0 ms), 11,5 veces en p95, 7,9 veces menor rendimiento (449,3 vs 56,7 páginas/min), y 8,3 veces mayor costo por 1.000 páginas ($0,048 vs $0,398) — misma GPU, mismo protocolo (summary_metrics.csv, filas sroie_2019).

¿Un postprocesador LLM cierra la brecha entre docTR y Docling?

Mayormente, pero no completamente: El F1 de campos postprocesado por LLM en SROIE llega a docTR 0.6171 vs Docling 0.5685 — una ventaja de 0.049 puntos para docTR que sobrevive a la compensación parcial del LLM por los artefactos de diseño de Docling (field_method_comparison.csv, llm_field_value_f1, filas sroie_2019). El costo de la convergencia es ~2.0–2.4 s de latencia LLM mediana adicional por documento (llm_median_latency_ms, mismas filas).

¿Este benchmark significa que Docling es malo?

No — significa que las fortalezas de Docling no se miden aquí. Docling es un pipeline de análisis de documentos cuya propuesta de valor — estructura de diseño, tablas, orden de lectura, formularios, documentos largos — es exactamente lo que un benchmark solo de recibos no puede probar. Lo que esta página muestra es más limitado: en un recibo simple de una página, la sobrecarga del pipeline no se justifica (3.0× peor CER, 8.3× costo), y su única ventaja medida (2.9× F1 de campos por regex) se borra con un postprocesador LLM. El encuadre honesto es de alcance, no de veredicto.

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

Dos causas acumulativas que el protocolo 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 ground-truth de CORD — el CER llega a 0.9101 (docTR) y 0.9219 (Docling) (summary_metrics.csv, cer, filas cord_v2). Con un postprocesador LLM, el F1 de campos de docTR se mantiene en 0.5500 vs 0.4695 de Docling — el orden de SROIE, comprimido. Las filas de CORD se citan y nunca se agrupan en un ranking combinado.

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

Para texto de recibos de alto volumen con costo medido, el margen de docTR es decisivo: 108.7 ms p50, 449.3 páginas/min, $0.048 por 1,000 páginas — el motor más rápido y barato en la ejecución subyacente de ocho motores. Si tu pipeline consume texto estructurado listo para usar sin ningún postprocesador, la ventaja de campos regex de Docling (0.2237 vs 0.0766) es una ventaja inicial real. Si el postprocesamiento con LLM es parte del diseño, docTR se mantiene adelante por 0.049 y es más barato de alimentar. Si tu carga de trabajo es documentos con mucho diseño — tablas, formularios, informes largos — este benchmark no es la evidencia correcta para la decisión; solo mide recibos (ver Limitaciones).

¿De dónde salen 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 regex, 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 papers SROIE 2019 y CORD citados a continuación.

Metodología y Fuentes

Protocolo

Esta página reporta un corte directo de una ejecución de benchmark independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros, ni una página de comparación de proveedores. Solo divisiones de prueba fijas: SROIE 2019 test (361 recibos en inglés, campos planos empresa/dirección/fecha/total) y CORD v2 test (100 recibos en indonesio, campos anidados menú/sub_total/total); las divisiones de entrenamiento nunca fueron evaluadas. 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 de estado estable). Ambas ejecuciones completaron con error_rate 0.0 en ambos conjuntos de datos (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, 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 el mismo NVIDIA RTX 4090 (24 GB); el costo de GPU se calculó con la tarifa bajo demanda de RunPod de $0.76/hr, precio con marca de tiempo en el manifiesto redactado de cada ejecución (agosto 2026).
• Motores: fuera de la caja, sin ajuste fino. Versiones bloqueadas: docTR v1.0.1 (OCR neuronal de una sola pasada — etapa de detección + etapa de reconocimiento compuestas en un solo predictor de OCR, GPU) y Docling 2.119.0 (pipeline de análisis de documentos — análisis de diseño, detección de tablas, reconstrucción del orden de lectura escalonados alrededor de un núcleo OCR, GPU) — según la tabla de modelos del repositorio público (README.md) y los manifiestos de ejecución.
• Postprocesador LLM: deepseek-v4-flash vía API a temperatura 0 para salida determinística (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_* en field_method_comparison.csv) — campos extraídos del texto OCR por un conjunto fijo de patrones. Miden OCR + extracción posterior, no la salida estructurada nativa de ningún modelo; las columnas LLM_* miden texto OCR + extracción LLM. Los dos pipelines nunca se mezclan, y el modelo de documento nativo de Docling no se evalúa con este benchmark.

Definiciones de Métricas

• CER (Tasa de Error de Caracteres): distancia de edición (inserciones + eliminaciones + sustituciones) entre el texto OCR y la verdad de terreno, dividida por los caracteres de la verdad de terreno. Menor es mejor.
• WER (Tasa de Error de Palabras): el mismo cálculo de distancia de edición a granularidad de palabra.
• F1 de valor de campo (regex): media armónica de precisión/recuperación sobre los valores de campo extraídos usando patrones regex fijos sobre 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 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 mezclan.
• 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 luego medido, excluye carga de modelo) y rendimiento en tiempo real incluyendo inicialización del modelo. Miden relojes diferentes.
• Costo por 1,000 páginas: horas de GPU facturadas por 1,000 páginas a la tarifa registrada de $0.76/hr, incluyendo la inicialización del modelo.

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 docling aquí.
2. field_method_comparison.csv (GitHub raw). 16 filas; columnas model, dataset, llm_model (= deepseek-v4-flash), regex/llm field-value accuracy y F1, document-fields-exact, llm_median_latency_ms, token counts. Cada número de F1 de campos regex/LLM se remonta a las filas de doctr y docling aquí (y a las ocho filas de sroie_2019 en el contexto de clasificación).
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que alberga los CSV de resultados, manifiestos de ejecución redactados, protocolo congelado y listas de muestras de conjuntos de datos (divisiones de prueba fijas) para reproducción.
4. results/manifests/ (GitHub). Un manifest.json redactado por cada ejecución publicada (16 ejecuciones) con versiones de modelo, GPU/driver, versiones de torch/CUDA/Python, metadatos de 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).
7. Auer et al., "Docling Technical Report" (2024). Solo contexto arquitectónico — describe el pipeline escalonado de Docling (análisis de diseño, detección de tablas, inferencia de orden de lectura, ensamblaje de documentos). Ningún número de referencia en esta página se toma de él.

Limitaciones

• Alcance del documento — solo recibos: SROIE + CORD. Nada aquí mide el manejo de diseño/tabla/orden de lectura/documentos largos que define la propuesta de valor de Docling; esas capacidades están fuera del alcance, no refutadas. No uses esta página para concluir que "Docling es malo". Concluye: en un recibo simple de una página, la sobrecarga del pipeline no justifica su costo.
• 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 brechas documentadas aquí (3,0× CER, 6,7× p50, 8,3× costo) están muy por encima del ruido, pero las diferencias de un solo dígito porcentual 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, con precio registrado en 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 — recalcula 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 cambiaría el F1 de campo absoluto; la ventaja de 0,049 puntos de docTR podría moverse en los márgenes. La latencia del LLM (~1.996–2.365 ms mediana en SROIE, field_method_comparison.csv llm_median_latency_ms) es incurrida por la API y no es parte de la latencia propia de ningún motor.
• 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; la ventaja de 2,9× de Docling sobre regex se mide contra este conjunto de patrones único y fijo.
• La salida nativa de Docling no se puntúa: Docling emite un modelo de documento estructurado, pero el benchmark puntúa texto + postprocesadores, no la salida estructurada nativa. Una variante del benchmark que puntúe los campos nativos de Docling sería un experimento diferente; esta página no lo intenta.
• 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 dos motores fue entrenado predominantemente en indonesio; el CER de CORD (~0,91–0,92) 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 de protocolo).
• Fijación de versiones: los resultados son válidos para docTR v1.0.1 y Docling 2.119.0 (agosto de 2026). Versiones más recientes de cualquiera de los motores podrían cambiar todos los números de esta página.

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

Lecturas relacionadas: AI OCR vs Traditional OCR Accuracy · AI Image Data Extraction vs Traditional OCR · AI Document Extraction Pricing (2026)