docTR vs Docling en recibos
Velocidad de una sola pasada vs. pipeline de documentos (2026)

Qué es Docling (y qué no es): OCR de una sola pasada frente a un pipeline 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 una sola pasada: una etapa de detección localiza los cuadros delimitadores del texto y una etapa de reconocimiento transcribe los caracteres dentro de ellos, compuestas en un único predictor de OCR cuya pasada frontal produce líneas de texto sin procesar. No hay modelo de diseño, ni analizador de tablas, ni reconstrucción del orden de lectura: lo que está impreso 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 y lenguaje; es un pipeline de análisis de documentos. Según su propio informe técnico (citado para contextualizar la arquitectura, no por ninguna cifra de esta página), organiza 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 texto, razón por la cual su salida lleva estructura (etiquetas, orden, zonas) que las líneas de docTR no tienen.

Por qué este mecanismo importa 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 sencillo no tiene casi nada de eso: una sola columna, unas pocas zonas, una ruta de arriba a abajo en su mayoría predecible, sin tablas. La maquinaria escalonada sigue ejecutándose en cada página —por eso es más lenta y costosa—, pero sin estructura que explotar, la sobrecarga no puede convertirse en 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 de 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 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 ocupa el puesto 7 de 8 motores en la ejecución subyacente, solo por delante de Unlimited-OCR (0.6552, columna cer de summary_metrics.csv, todas las filas sroie_2019) — la comparación directa 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 (solo por delante del 0.6552 de Unlimited-OCR) — la precisión de caracteres en bruto es donde el impuesto del pipeline aparece primero.

La inversión: la extracción de campos con regex invierte el resultado

Si se comparan los textos 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 (KIE) basada en reglas—, la clasificación se invierte: Docling extrae campos con un F1 de campo de 0.2237 frente al 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 salida estructurada nativa de ninguno de los dos motores, y el modelo de documento nativo de Docling no se puntúa aquí.

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 —un 1.0 significa que cada campo del recibo se recuperó perfectamente, un 0 significa que nada. El mecanismo detrás de la inversión es la misma diferencia de arquitectura que causó la brecha de CER, actuando 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 tiene una forma más cercana a lo que los patrones fijos esperan; el texto de línea limpio pero crudo de docTR —preciso según CER, pero con mayúsculas originales, ruido de separadores y sin marco de etiquetas— hace que los patrones fallen. El F1 de campo 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 de summary_metrics.csv, todas las filas sroie_2019); el 0.2237 de Docling ocupa el sexto lugar. El mismo desacoplamiento que el enfrentamiento hermano documentó en la parte superior de la escalera 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 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, no extracción estructurada nativa. Ninguno de los dos motores obtiene los cuatro campos exactamente correctos mediante regex en ningún recibo SROIE (0.0000, un cero literal registrado en el CSV). El F1 de campo regex de docTR de 0.0766 es el más bajo de los ocho motores en la ejecución subyacente.

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 ventaja: F1 de campo 0.6171 frente a 0.5685 — una diferencia de 0.049 puntos, pequeña comparada con la brecha de CER bruto pero no eliminada. El texto base más limpio revela más valores de campo recuperables; el LLM compensa parcialmente los artefactos de diseño de Docling pero no los elimina por completo.

Esta es la misma banda de convergencia observada en el benchmark completo de ocho motores — el postprocesamiento con LLM acerca a los motores saludables porque comprende la semántica (números, fechas, nombres) en lugar de comparar formas de caracteres — y la brecha residual importa: el 0.6171 de docTR es el mejor F1 de campo 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). El criterio más estricto — documentos donde los cuatro campos coinciden exactamente — los separa 2.7×: docTR 0.1496 frente a Docling 0.0554. La palanca conlleva dos costos: una llamada al 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 e idénticos en naturaleza), y no puede rescatar texto que un motor no logró leer en absoluto.

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 la incurre la API y es independiente de la latencia del motor (summary_metrics.csv latency_p50_ms). Ambas filas se completaron con llm_ok_count 361.

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

El costo del pipeline es más alto 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 pared × 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ía por el tiempo de GPU. El rendimiento es páginas por minuto en tiempo de pared, 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). docTR es el motor más rápido y 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 encuentra en la mitad inferior de la tabla del envolvente operativo (summary_metrics.csv, columnas 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 la 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 pared × $0.76/hr incluyendo la inicialización del modelo, precio con marca de tiempo en los manifiestos de ejecución (agosto de 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 en GPU (RTX 4090, $0.76/h con precio registrado en los 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 de Indonesia): Ambos Colapsan, la Recuperación de Campos por LLM de docTR Sigue Liderando

Ningún motor fue entrenado predominantemente con recibos de Indonesia, por lo que CORD v2 (100 muestras, campos anidados menú/sub_total/total) funciona como una prueba de estrés entre idiomas — y ambos colapsan en CER crudo: 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 SROIE — nunca se fusionan en ninguna clasificación — porque el texto de referencia de CORD incorpora la estructura de anotación, lo que infla el CER crudo para cada motor además del desajuste de idioma real.

En las métricas de campo, la única ventaja conservada 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 — frente al 0.0612 de Docling, porque los patrones de formato en inglés nunca se escribieron para texto en indonesio). El postprocesador LLM absorbe el impacto del idioma en ambos lados, pero mantiene a docTR por delante: F1 de campo 0.5500 frente a 0.4695. CORD se cita aquí para dar contexto de robustez lingüística; deliberadamente nunca se agrupa con los números de SROIE en una sola tabla de clasificación.

Tabla: summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) y field_method_comparison.csv (field F1), filas cord_v2. No mezcles los números de CORD en ninguna clasificación de SROIE: el CER de CORD combina un desajuste lingüístico real con una inflación de la estructura de anotaciones en la verdad de campo, y los patrones regex se escribieron para formatos en inglés. El F1 de campo regex de CORD 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, y este cara a cara divide los ejes con claridad: en un recibo en inglés sencillo, cada eje de velocidad/coste y de texto sin formato favorece a docTR; la inversión de campos regex de fábrica favorece a Docling; un posprocesador LLM los devuelve a una ventaja de 0.049 puntos para docTR; y las capacidades para las que existe Docling — maquetación, 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 en bruto, docling es 3.0× peor: SROIE CER 0.5909 vs 0.1971, y WER 0.7596 vs 0.3199 (summary_metrics.csv, cer / wer, sroie_2019 rows). Docling “gana” solo un eje medido: extracción de campos con regex lista para usar (0.2237 vs 0.0766 field F1) — y un postprocesador LLM devuelve esa ventaja a docTR (0.6171 vs 0.5685).

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

Porque las dos métricas evalúan cosas distintas, y la forma de salida de Docling encaja 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 es estructuralmente más cercano a lo que esperan los patrones regex fijos; docTR emite líneas de texto en bruto limpias y precisas según CER, pero que no cumplen los patrones (0.0766 field F1, el peor de los ocho motores, frente a un CER de primera clase). Estas son puntuaciones postprocessed_sroie_receipt_regex_* — texto OCR procesado con patrones fijos — no salida estructurada nativa (field_method_comparison.csv, regex_field_value_f1, sroie_2019 rows). Esta misma separación entre 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 aprovechar. En SROIE ese costo se mide en 6.7× en p50 (108.7 vs 732.0 ms), 11.5× en p95, 7.9× menor rendimiento (449.3 vs 56.7 páginas/min) y 8.3× mayor costo por 1,000 páginas ($0.048 vs $0.398) — misma GPU, mismo protocolo (summary_metrics.csv, sroie_2019 rows).

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

En su mayoría, pero no por completo: el F1 de campos con posprocesamiento LLM en SROIE sitúa a docTR en 0.6171 frente a Docling en 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 de sroie_2019). El costo de la convergencia es de ~2.0–2.4 s de latencia LLM mediana adicional por documento (llm_median_latency_ms, mismas filas).

¿Significa este benchmark 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 muestra esta página es más acotado: en un recibo simple de una página, la sobrecarga del pipeline no se justifica (CER 3.0× peor, costo 8.3× mayor), y su única ventaja medida (F1 de campos regex 2.9×) se elimina con un posprocesador LLM. El encuadre honesto es de alcance, no de veredicto.

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

Dos causas combinadas que el protocolo mantiene separadas del ranking SROIE: un desajuste lingüístico genuino (recibos indonesios fuera del enfoque de entrenamiento de ambos motores) e inflación por la estructura de anotaciones dentro del texto de referencia de CORD — el CER se sitúa en 0.9101 (docTR) y 0.9219 (Docling) (summary_metrics.csv, cer, filas de cord_v2). Con un posprocesador LLM, el F1 de campos de docTR se mantiene en 0.5500 frente al 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 debería elegir un pipeline de recibos, docTR o Docling?

Para texto de recibos de alto volumen con costo medido, la ventaja de docTR es decisiva: 108.7 ms p50, 449.3 páginas/min, $0.048 por cada 1,000 páginas — el motor más rápido y económico de los ocho evaluados. Si tu pipeline consume texto estructurado listo para usar sin ningún postprocesador, la ventaja de Docling en campos regex (0.2237 vs 0.0766) es una ventaja inicial real. Si el postprocesamiento con LLM es parte del diseño, docTR sigue por delante por 0.049 y es más barato de alimentar. Si tu carga de trabajo son documentos con mucho diseño — tablas, formularios, informes largos — este benchmark no es la evidencia adecuada 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 campos regex, latencia, costo, rendimiento) y results/field_method_comparison.csv (regex vs postprocesamiento con LLM, llm_model = deepseek-v4-flash) — alojados en ImageToTableai/benchmark-ocr, con un manifest.json redactado por ejecución para las huellas del entorno. Las definiciones de los conjuntos de datos provienen de los artículos SROIE 2019 y CORD citados abajo.

Metodología y fuentes

Protocolo

Esta página informa un segmento comparativo de una ejecución de benchmark 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 company/date/address/total) y prueba CORD v2 (100 recibos en indonesio, campos anidados menu/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: una pasada de calentamiento fija precede a la pasada evaluada, por lo que las cifras de latencia son de estado estable). Ambas ejecuciones se completaron con error_rate 0.0 en ambos conjuntos de datos (columna error_rate de summary_metrics.csv). La ejecución subyacente contiene ocho motores en total; esta página compara solo los dos motores nombrados, y los demás se citan únicamente como contexto de clasificación. Los resultados completos de los 8 motores se publican por separado en Traditional OCR vs Document Parsing VLMs.

Entorno de ejecución

• Hardware: ambos motores se ejecutaron en la misma 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: configuración estándar, sin ajuste fino. Versiones fijadas: docTR v1.0.1 (OCR neuronal de una sola pasada — etapa de detección + etapa de reconocimiento compuestas en un 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 organizadas alrededor de un núcleo de 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 determinista (la columna llm_model en field_method_comparison.csv); fue el único modelo utilizado para todas las filas de campos LLM en ambos motores.
• Base de costo: tiempo de ejecución en reloj de 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 con regex de SROIE son postprocessed_sroie_receipt_regex_* (columnas regex_* en field_method_comparison.csv) — campos extraídos del texto de OCR mediante un conjunto fijo de patrones. Miden OCR + extracción posterior, no la salida estructurada nativa de ningún modelo; las columnas LLM_* miden texto de OCR + extracción con LLM. Los dos pipelines nunca se combinan, y el modelo de documento nativo de Docling no se puntúa en este benchmark.

Definiciones de métricas

• CER (tasa de error de caracteres): distancia de edición (inserciones + eliminaciones + sustituciones) entre el texto de OCR y la verdad de referencia, dividida por los caracteres de la verdad de referencia. Cuanto menor, mejor.
• WER (tasa de error de palabras): el mismo cálculo de distancia de edición a nivel de palabras.
• F1 de valores de campo (regex): media armónica de precisión/recuperación sobre los valores de campo extraídos usando patrones regex fijos en el texto de OCR (pipeline tradicional de OCR + KIE basado en reglas). Columna: regex_field_value_f1. Una puntuación de 0 significa que no se recuperó ningún valor de campo.
• F1 de valores de campo (LLM): la misma métrica sobre la salida del postprocesador LLM (texto de OCR → deepseek-v4-flash → campos). Columna: llm_field_value_f1. Los dos pipelines son diferentes y nunca se combinan.
• Exactitud de campos de documento: fracción de documentos donde todos los campos objetivo coincidieron exactamente — un estándar mucho más estricto que el F1 por campo.
• Latencia p50/p95 y páginas/min: tiempo de inferencia por página en estado estable (calentado y luego puntuado, excluye la carga del modelo) y rendimiento en reloj de pared incluida la 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/hora, incluida 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 cifra de CER/WER, latencia, costo y rendimiento en esta página proviene de las filas doctr y docling aquí.
2. field_method_comparison.csv (GitHub raw). 16 filas; columnas model, dataset, llm_model (= deepseek-v4-flash), precisión y F1 de valores de campo regex/llm, document-fields-exact, llm_median_latency_ms, recuentos de tokens. Cada cifra de F1 de campo regex/LLM proviene de las filas doctr y docling aquí (y de las ocho filas sroie_2019 en el contexto de clasificación).
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que aloja los CSV de resultados, manifiestos de ejecución redactados, protocolo congelado y listas de muestras de conjuntos de datos (divisiones de prueba fijas) para 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).
7. Auer et al., "Docling Technical Report" (2024). Solo antecedentes de arquitectura — describe el pipeline por etapas de Docling (análisis de diseño, detección de tablas, inferencia de orden de lectura, ensamblaje de documentos). Ninguna cifra de referencia en esta página proviene de él.

Limitaciones

• Alcance del documento — solo recibos: SROIE + CORD. Nada de esto mide el manejo de diseño/tablas/orden de lectura/documentos largos que define la propuesta de valor de Docling; esas capacidades están fuera de alcance, no refutadas. No uses esta página para concluir “Docling es malo”. Concluye: en un recibo simple de una página, la sobrecarga del pipeline no justifica su costo.
• Tamaño de muestra: 361 recibos en inglés + 100 en indonesio. El F1 por campo y el CER dependen del corpus; las brechas documentadas aquí (3.0× CER, 6.7× p50, 8.3× costo) están muy por encima del margen de ruido, pero diferencias de un solo punto 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/hora, precio con fecha de agosto de 2026 en los manifiestos de ejecución. Otras GPUs, servicio multi-GPU, programación por lotes o cambios de precio alterará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 cambia el F1 absoluto por campo; la ventaja de 0.049 puntos de docTR puede 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) 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; la ventaja de regex de 2.9× de Docling se mide contra este único conjunto fijo de patrones.
• 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 puntuara 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 fundamental de CORD incorpora 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 fundamental. Las filas de CORD se citan con contexto y nunca se fusionan en ninguna clasificación de SROIE (regla del protocolo).
• Fijación de versiones: los resultados corresponden a docTR v1.0.1 y Docling 2.119.0 (agosto de 2026). Versiones más recientes de cualquiera de los motores pueden cambiar cada número de esta página.

Referencias relacionadas: Benchmark de recibos docTR vs Surya2 · Benchmark de recibos PaddleOCR vs EasyOCR · OCR tradicional vs VLMs de análisis de documentos · Extracción basada en reglas vs extracción con LLM · Precisión a nivel de campo vs a nivel de carácter

Lectura relacionada: la brecha de precisión entre la IA y el OCR tradicional · extracción de imágenes con IA comparada con el OCR tradicional · Precios de extracción de documentos con IA (2026)