OCR Tradicional vs VLMs de Análisis de Documentos
Resultados del Benchmark de Recibos (2026)

La Tasa de Error de Caracteres (CER) mide qué fracción de caracteres individuales se lee mal — eliminaciones, inserciones y sustituciones divididas por los caracteres de la verdad de referencia. Es la medida clásica de OCR, y es donde la narrativa de la "superioridad de los VLM" colapsa en recibos en inglés.

En SROIE 2019, los dos mejores reconocedores de texto son un VLM y un motor tradicional, separados por 0,006 puntos: Surya2 con 0,191 y docTR con 0,197, con PaddleOCR en tercer lugar (0,204). Los tres VLM restantes — PaddleOCR-VL 0,337, Docling 0,591, Unlimited-OCR 0,655 — se sitúan por debajo o al nivel de motores tradicionales como EasyOCR (0,283) y Tesseract (0,335).

Precisión de Caracteres por Modelo en SROIE (Recibos en Inglés)

Fuente: summary_metrics.csv — columna cer, filas sroie_2019 (8 filas). Surya2 0,1915, docTR 0,1971, PaddleOCR 0,2045, EasyOCR 0,2833, Tesseract 0,3347, PaddleOCR-VL 0,3370, Docling 0,5909, Unlimited-OCR 0,6552. Menor es mejor. Tesseract es solo CPU.

Tabla: summary_metrics.csv — columnas cer y wer, filas sroie_2019, 361 muestras cada una (error_rate 0.0 para los 8 modelos). CER = tasa de error de caracteres, WER = tasa de error de palabras; menor es mejor. Valores exactos: Surya2 cer 0.19147 / wer 0.27352; docTR cer 0.19707 / wer 0.31990.

La tasa de error de palabras cuenta la misma historia con una granularidad diferente: puntúa errores de palabras completas en lugar de caracteres. Surya2 lidera el WER con 0.274, docTR le sigue con 0.320. Observe el valor atípico al final: Unlimited-OCR tiene el peor CER (0.655) pero un WER en el rango medio (0.478) — su salida está fuertemente normalizada en cuanto a mayúsculas y formato (una convención de salida que se discute en la sección de metodología), lo que infla las ediciones a nivel de caracteres incluso cuando las palabras están en gran medida intactas.

Docling merece una nota de clasificación antes de aparecer en comparaciones: no es un motor OCR tradicional puro ni un VLM. Docling es un analizador por pipeline — una cadena de herramientas escalonada que ejecuta análisis de diseño, detección de tablas y reconstrucción del orden de lectura alrededor de un núcleo OCR. En un recibo simple, esa sobrecarga del pipeline aporta poco, lo que es parte de la razón por la que su CER bruto (0.591 en SROIE) queda por detrás de los motores de paso único.

Costo y Latencia: La Ventaja del Motor Tradicional

Si la precisión de caracteres no decide nada entre las dos familias, el costo y la latencia deciden casi todo. En el mismo conjunto de pruebas, docTR mantiene 449 páginas/min con 108.7 ms p50 por página por $0.048 por 1,000 páginas; Surya2 mantiene 12 páginas/min con 2,668 ms p50 por $1.061 por 1,000 páginas — aproximadamente 37× el rendimiento, 24.5× la latencia por página, y 22× el costo por mil páginas.

El costo se calcula como tiempo de ejecución real × la tarifa de RunPod RTX 4090 ($0.76/hora, precio con marca de tiempo en los manifiestos de ejecución) — el precio que realmente pagarías por el tiempo de GPU, incluyendo la inicialización del modelo. Tesseract es el caso especial: solo CPU, no tiene costo de GPU en absoluto y aun así logra 78.6 páginas/min en SROIE; su celda de costo está vacía en el CSV por diseño, no porque sea gratuito sino porque no consume horas de GPU facturables.

Fuente: summary_metrics.csv — columna latency_p50_ms, filas sroie_2019. docTR 108.7, PaddleOCR 297.0, EasyOCR 413.6, Tesseract 670.9 (CPU), PaddleOCR-VL 694.3, Docling 732.0, Unlimited-OCR 1600.7, Surya2 2668.0. Latencia en estado estable, modo de medición caliente-para-puntuar (excluye carga del modelo).

Fuente: summary_metrics.csv — columna cost_per_1000_pages, filas sroie_2019. docTR 0.0479, EasyOCR 0.1098, PaddleOCR-VL 0.2048, PaddleOCR 0.2214, Unlimited-OCR 0.3879, Docling 0.3978, Surya2 1.0609. Tesseract solo CPU: celda vacía en el CSV (sin costo de GPU); el costo incluye inicialización del modelo, no solo el rendimiento en estado estable puro.

Tabla: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, filas sroie_2019. Ejecuciones en GPU con RTX 4090 ($0.76/hr, precio con marca de tiempo en manifiestos); Tesseract ejecutado solo en CPU (celda de costo vacía, no cero). El rendimiento es páginas/min en tiempo real, incluyendo la inicialización del modelo.

La columna de latencia de cola importa si le interesa el comportamiento en el peor caso, no solo las medianas. La p95 de PaddleOCR de 3,331 ms y la de Docling de 3,240 ms están lejos de sus valores de p50 — los efectos de la primera página y los picos de prefill dominan la cola en motores GPU — mientras que la p95 de docTR (281 ms) se mantiene ajustada. Para cargas de trabajo interactivas (un usuario esperando por una página), esa diferencia en p95 es la diferencia entre una espera de 0,3 segundos y una de más de 3 segundos.

CORD (Recibos Indonesios): Desajuste Lingüístico e Inflación del Ground-Truth

CORD v2 es un conjunto de datos de recibos en idioma indonesio con campos anidados (menu, sub_total, total). Ninguno de los 8 motores fue entrenado predominantemente en recibos indonesios, por lo que CORD funciona como una prueba de estrés entre idiomas — y el CER de cada motor colapsa a 0.90–1.08. Estos números deben leerse con la advertencia de que el texto ground-truth de CORD incrusta la estructura de anotación, lo que infla el CER bruto para cada motor; los resultados de CORD se mantienen estrictamente separados del ranking de SROIE y no son fusionables en una tabla de clasificación única.

Dos fuerzas distintas empujan el CER de CORD hacia 1.0, y solo una de ellas es el idioma en sí. Primero, el idioma: los motores entrenados en inglés leen erróneamente palabras indonesias — los nombres indonesios, direcciones callejeras y formatos de moneda (Rp) están fuera de sus distribuciones de entrenamiento. Segundo, el ground truth: las anotaciones de texto publicadas de CORD incrustan la estructura de anotación (etiquetas de campo con coordenadas) en lugar de texto visible puro, por lo que el CER bruto mide la distancia de edición contra una cadena aumentada estructuralmente. Los ejemplos de VLM más limpios son los más penalizados — PaddleOCR-VL con un CER de 1.080 es el artefacto extremo de ese mecanismo, no una lectura de su calidad de texto.

La comparación justa entre familias en CORD es, por lo tanto, la métrica de campo, no el CER (ver la siguiente sección). Lo que las columnas de CER aún muestran de manera útil es que el desajuste lingüístico es real y universal en todas las arquitecturas — cada familia, tanto tradicional como VLM, cae en la misma banda de 0.90–1.08 sin ventaja estructural para ninguna.

Tabla: summary_metrics.csv — columna cer, filas cord_v2, 100 muestras cada una. No compare estos números con SROIE en un ranking combinado: El CER de CORD combina una discrepancia lingüística genuina con una inflación de la estructura de anotación en el ground truth (metodología a continuación). Un CER superior a 1.0 (PaddleOCR-VL 1.0805) es un artefacto de distancia de edición de ese ground truth inflado.

F1 de Campo: El Postprocesamiento con LLM Converge el Campo

La precisión de caracteres clasifica los motores; la extracción de campos es lo que los usuarios de producción realmente pagan. El benchmark extrae cuatro campos de recibos (empresa, fecha, dirección, total) del texto OCR de cada motor usando dos postprocesadores — patrones regex fijos (el enfoque tradicional de OCR + KIE basado en reglas) y un LLM (deepseek-v4-flash) con un prompt estructurado. El resultado: el LLM casi borra la brecha entre motores en SROIE, llevando seis de ocho motores a una banda de F1 de campo de 0.57–0.62 — donde sus resultados con regex se extendían en un rango de 0.26 puntos.

El F1 de valor de campo es la media armónica de precisión y exhaustividad sobre los valores de campo extraídos, puntuados contra la verdad de referencia — 1.0 significa que cada valor de campo se extrajo perfectamente, 0 significa que no se recuperó nada. Las columnas de regex usan un conjunto de patrones fijo por dataset; las columnas de LLM usan deepseek-v4-flash a temperatura 0 para una salida determinista (la columna llm_model en el CSV de comparación). Las dos métricas miden pipelines diferentes y nunca se combinan.

Fuente: field_method_comparison.csv — columnas regex_field_value_f1 / llm_field_value_f1, filas sroie_2019 (decimales 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 — regex_field_value_f1 / llm_field_value_f1, filas sroie_2019. LLM = postprocesamiento deepseek-v4-flash (columna llm_model). docTR regex 0.0766 → LLM 0.6171 (mejora de 8,1×); los 6 motores no rezagados abarcan 0,5685–0,6171.

Hay dos resultados contraintuitivos en esta tabla. Primero, docTR tiene el peor F1 de campo regex en SROIE (0,077) y el mejor F1 de campo LLM (0,617) — el mismo texto OCR limpio que regex convirtió en el 7,7% de los campos produjo el 61,7% bajo el LLM. El cuello de botella era el postprocesador, no el OCR. Segundo, los dos motores que caen fuera de la banda 0,57–0,62 son exactamente los dos con bases OCR degradadas: EasyOCR (0,372, CER de SROIE 0,283) y Tesseract — cuyo resultado en CORD (F1 de campo LLM 0,163) demuestra que un LLM no puede extraer campos de un texto que fundamentalmente no puede leer (CER de CORD 0,9523). El techo de cualquier postprocesador es la calidad de la base OCR subyacente.

En CORD, el LLM también absorbe parte del choque lingüístico: el F1 de campos del LLM se mantiene en 0.47–0.55 para los motores saludables (PaddleOCR 0.553, docTR 0.550, PaddleOCR-VL 0.520, Surya2 0.520) aunque regex colapsa a casi cero (docTR 0.0, EasyOCR 0.7%) — los patrones fueron escritos para formatos en inglés, y la penalización de "un idioma más" la pagan casi en su totalidad las reglas, no el LLM (field_method_comparison.csv, llm_field_value_f1 / regex_field_value_f1, filas cord_v2).

Por qué el CER Subestima los VLM de Análisis de Documentos

El CER compara la salida del VLM y la verdad de campo carácter por carácter, y los VLM son penalizados por dos comportamientos legítimos que no son errores de reconocimiento: normalización de mayúsculas y fusión de etiqueta/valor. La descomposición del CER del benchmark en SROIE atribuye aproximadamente el 18% del CER del VLM a diferencias de formato de mayúsculas (ej., TAN CHAY YEE → tan chay yee) y aproximadamente el 10% a fusión de líneas o líneas separadoras omitidas — con los valores de campo en sí (empresa, total, fecha) realmente correctos (análisis de descomposición del CER registrado en las notas de protocolo del benchmark, ejecuciones SROIE).

La tensión de diseño es real y estructural: los motores de OCR tradicionales producen texto crudo con mayúsculas intactas, por lo que están optimizados por diseño para la puntuación CER; los VLM de análisis de documentos producen texto "comprendido" (mayúsculas normalizadas, pares etiqueta-valor fusionados, líneas reordenadas), que está más cerca de lo que un sistema aguas abajo quiere pero más lejos de las coincidencias exactas de caracteres. Por eso el titular de la página usa el CER solo donde es una comparación justa entre salidas similares, y por eso la comparación justa entre familias vive en las métricas de campo — y por qué el CER de CORD (que además soporta inflación por estructura de anotación) está cuarentenado en su propia sección. El punto más amplio: una brecha de CER entre familias no es automáticamente una brecha de precisión, y cualquiera que compare modelos entre familias debe verificar qué está midiendo el CER antes de concluir que una familia "lee mejor".

Cómo Elegir: Qué Eje es Clave para Tu Carga de Trabajo

"Mejor" no tiene sentido sin una carga de trabajo. La conclusión honesta del benchmark es que las dos familias ganan en ejes diferentes, y los recibos específicamente miden los ejes donde los motores tradicionales ganan y los ejes donde el postprocesamiento — no la familia del motor — decide la calidad de los campos.

La guía de selección se deriva directamente de las filas CSV citadas; es una ayuda de lectura basada en datos, no un respaldo de proveedor. Tus resultados exactos varían con el hardware, la mezcla de documentos y las versiones de los modelos.

Preguntas Frecuentes

¿Son más precisos los VLM de análisis de documentos que el OCR tradicional en recibos?

No en precisión de caracteres cruda — el mejor VLM y el mejor motor tradicional están estadísticamente empatados en SROIE 2019 (Surya2 CER 0.191 vs docTR 0.197, summary_metrics.csv sroie_2019 rows), y PaddleOCR (0.204) es tercero. Cuando el objetivo es la extracción de campos, con o sin VLM, el postprocesamiento con LLM es el factor decisivo (banda de convergencia 0.57–0.62, field_method_comparison.csv).

¿Cuándo tiene más sentido el OCR tradicional que un VLM de análisis de documentos?

Cuando el volumen es alto, el costo se mide por uso o la latencia debe ser interactiva. En SROIE, docTR procesó 449 páginas/min a $0.048 por 1,000 páginas y 108.7 ms p50; Surya2 procesó 12 páginas/min a $1.061 por 1,000 páginas y 2,668 ms p50 (summary_metrics.csv, doctr and surya2 sroie_2019 rows). Para una espera interactiva por página, la diferencia es 0.1 segundos vs 2.7 segundos.

¿Por qué los VLM de análisis de documentos a veces obtienen un CER peor que el OCR básico?

Porque el CER mide coincidencias exactas de caracteres, y los VLM son penalizados por la normalización de mayúsculas y la fusión de etiquetas/valores, que son convenciones de salida, no errores de lectura. La descomposición del CER en el benchmark en SROIE atribuye aproximadamente 18% del CER de los VLM a diferencias de formato de mayúsculas y ~10% a la fusión de líneas/separadores omitidos — con los valores de campo a menudo correctos (ver Metodología). El CER de CORD está adicionalmente inflado por la estructura de anotación dentro de su ground truth, por lo que esta página aísla el CER de CORD de cualquier ranking y utiliza métricas de campo para la comparación entre familias.

¿Cuánto cuesta el OCR de recibos por página en una RTX 4090?

Entre $0.048 (docTR) y $1.061 (Surya2) por 1,000 páginas en una RTX 4090 a $0.76/hr, precio con marca de tiempo de agosto de 2026 en los manifiestos de ejecución (summary_metrics.csv cost_per_1000_pages, filas sroie_2019). Tesseract es solo CPU y no consume horas de GPU. El costo incluye la inicialización del modelo, por lo que el costo por página disminuye a medida que crece el tamaño del lote.

¿Por qué todos los modelos obtienen un CER superior a 0.90 en recibos CORD?

Dos causas acumulativas: una verdadera incompatibilidad lingüística (recibos en indonesio fuera del enfoque de entrenamiento de cada motor) y una inflación de la estructura de anotación dentro del texto de referencia de CORD. Ninguna familia escapa a esto — los 8 modelos se sitúan en la banda de 0.90–1.08 (summary_metrics.csv cer, filas cord_v2). CORD es un conjunto de estrés de robustez lingüística/diseño, mantenido separado del ranking de SROIE.

¿Un LLM simplemente arreglará mi salida de OCR mala?

Solo hasta la calidad del texto base. En SROIE, el LLM elevó seis motores a una banda de F1 de campo de 0.57–0.62 independientemente del motor (field_method_comparison.csv), pero el caso de CORD con Tesseract muestra el límite: con un CER de 0.9523, su F1 de campo con LLM es 0.163 — un LLM no puede extraer campos de un texto que no puede leer.

¿Cuál es el OCR más rápido para recibos?

docTR en este benchmark: 108.7 ms p50 por página y 449 páginas/min en SROIE 2019 (summary_metrics.csv doctr/sroie_2019: latency_p50_ms, pages_per_minute). El más lento probado, Surya2, fue 24.5× más lento en p50 (2,668 ms) y 37× más lento en rendimiento (12 páginas/min).

¿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 (8 modelos × 2 conjuntos de datos: CER/WER, F1 de campo, latencia, costo, rendimiento) y results/field_method_comparison.csv (regex vs postprocesamiento LLM) — 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 informa la comparación de análisis de documentos de un benchmark independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros. 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. Cada par (modelo × conjunto de datos) reutiliza las mismas imágenes, la misma verdad de terreno 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). Las 16 ejecuciones completadas tuvieron error_rate 0.0 (columna error_rate de summary_metrics.csv).

Entorno de Ejecución

• Hardware: todas las ejecuciones en GPU se realizaron en una NVIDIA RTX 4090 (24 GB); el costo de GPU se calculó con la tarifa bajo demanda de RunPod de $0.76/hr, con la marca de tiempo del precio registrada en el manifiesto redactado de cada ejecución (agosto de 2026). Tesseract se ejecutó solo en CPU y no tiene costo de GPU (celda de costo vacía en el CSV).
• Motores: todos los modelos se ejecutan listos para usar, sin ajuste fino. Versiones bloqueadas según 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.
• Base de costo: tiempo de ejecución 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 SROIE son variantes postprocessed_sroie_receipt_regex_* / LLM — es decir, campos extraídos del texto OCR por un conjunto fijo de regex o el LLM. Miden OCR + extracción posterior, no la salida estructurada nativa de los modelos.

Versiones según se registraron en la tabla de modelos del benchmark (README.md) y los manifiestos redactados por ejecución (results/manifests/, uno por ejecución publicada, 16 en total) — cada manifiesto registra el id de ejecución, versión del modelo, hash del script de ejecución, GPU/driver, versiones de torch/CUDA/Python, hash de pip-freeze, metadatos de costo con marca de tiempo del precio y hashes de artefactos para reproducibilidad.

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. Sensible a mayúsculas/minúsculas y convenciones de formato.
• 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/recall sobre valores de campo extraídos usando patrones regex fijos en el texto OCR (pipeline de OCR tradicional + KIE basado en reglas). Columna: regex_field_value_f1.
• 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.
• Latencia p50/p95 y páginas/min: tiempo de inferencia por página en estado estable (calentado y luego medido, 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; vacío para Tesseract solo con CPU.

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 una fila 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, conteo de tokens. Cada número de F1 de campo regex/LLM se remonta a una fila 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 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 la huella del entorno, versión del modelo, metadatos de costo 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). Esta referencia no mide nada sobre el manejo de diseño/tablas/fórmulas, documentos largos o campos que no sean de recibos — los tipos de documento donde los VLM de análisis de documentos afirman sus mayores ventajas no se miden aquí. No use esta página para concluir que "el OCR tradicional es mejor en todas partes."
• 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 unas pocas centésimas deben tratarse como ruido, no como una verdad de ingeniería.
• Tier de GPU único: todos los números de GPU provienen de una sola RTX 4090 a $0.76/hr. Otras GPUs, servicio multi-GPU o programación por lotes cambiarán la latencia, el rendimiento y el costo.
• Asimetría CPU/GPU: Tesseract (CPU) se compara con motores acelerados por GPU; su latencia/tiempo refleja hardware CPU mientras que su ventaja de costo refleja la ausencia de facturación por GPU. Esto está marcado en cada tabla relevante, pero la asimetría es inherente a la comparación.
• El postprocesador LLM es un solo modelo: todas las filas de campos LLM usan deepseek-v4-flash. Un LLM diferente produciría un F1 absoluto diferente; el orden de convergencia podría cambiar en los márgenes. La latencia del LLM (~1.8–2.4 s mediana, field_method_comparison.csv llm_median_latency_ms) es incurrida por la API y no es parte de la latencia del propio motor OCR.
• Marcador de tiempo de costo: el precio de GPU de $0.76/hr se registró en los manifiestos de ejecución en agosto de 2026. Los precios de GPU spot/bajo demanda cambian; recalcule los costos a las tarifas actuales antes de presupuestar.
• El CER de CORD no es una lectura de calidad: la verdad de referencia de CORD incorpora la estructura de anotación y los motores no fueron entrenados en indonesio. El CER de CORD (0.90–1.08 en los 8 modelos) refleja la discrepancia lingüística + la inflación de la verdad de referencia, no la calidad de lectura por modelo; las filas de CORD no se fusionan intencionalmente en ninguna clasificación de SROIE.
• Ajuste de regex: el conjunto de patrones regex se escribió una vez por conjunto de datos. Una biblioteca de patrones ajustada por proveedor podría puntuar más alto en sus propios formatos — al costo de mantenimiento que el LLM elimina.
• Sin modelos en la nube/API: AWS Textract, Google Document AI, Azure AI Document Intelligence y APIs VLM alojadas (por ejemplo, servicios de OCR en la nube) no están incluidos; 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 las versiones de modelo de agosto de 2026 listadas arriba; las versiones más recientes de cualquier motor podrían cambiar los resultados, y las latencias p50 de las dos mediciones con grandes picos p95 (PaddleOCR, Docling) reflejan efectos de prellenado/primera página bajo el patrón de lotes de esta ejecución.

Referencias relacionadas: Regex vs Extracción de Campos con LLM · Precisión a Nivel de Campo vs a Nivel de Carácter · Precisión del OCR de Recibos · Precisión del OCR por Tipo de Documento

Lecturas relacionadas: Precisión de AI OCR vs OCR Tradicional · Extracción de Datos de Imagen con AI vs OCR Tradicional · Precios de Extracción de Documentos con AI (2026)