OCR tradicional vs. VLM de análisis de documentos
Resultados de referencia de recibos (2026)

La tasa de error de caracteres (CER) mide qué fracción de caracteres individuales se leen incorrectamente: eliminaciones, inserciones y sustituciones divididas entre los caracteres de referencia. Es el criterio clásico de OCR, y es donde la narrativa de la "superioridad de los VLM" se derrumba en los 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 al nivel o por debajo 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; cuanto menor, 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 distinta: puntúa errores de palabras completas en lugar de caracteres. Surya2 lidera el WER con 0.274, docTR le sigue con 0.320. Nótese el valor atípico al final: Unlimited-OCR tiene el peor CER (0.655) pero un WER intermedio (0.478) — su salida está fuertemente normalizada en cuanto a mayúsculas y formato (una convención de salida discutida en la sección de metodología), lo que infla las ediciones a nivel de caracteres incluso cuando las palabras están en gran parte intactas.

Docling merece una nota de clasificación antes de aparecer en comparaciones: no es ni un motor OCR tradicional puro ni un VLM. Docling es un analizador por pipeline — una cadena de herramientas por etapas 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 explica en parte por qué su CER bruto (0.591 en SROIE) va por detrás de los motores de una sola pasada.

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 la misma división de prueba, docTR mantiene 449 páginas/min a 108.7 ms p50 por página por $0.048 por 1,000 páginas; Surya2 mantiene 12 páginas/min a 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 de pared × 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ía por el tiempo de GPU, incluida la inicialización del modelo. Tesseract es el caso especial: solo CPU, no tiene ningún costo de GPU y aun así gestiona 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 facturadas.

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 cálido y luego puntuado (excluye la 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 la inicialización del modelo, no el rendimiento puro en estado estable.

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/h, precio con marca de tiempo en los manifiestos); Tesseract se ejecutó solo en CPU (celda de costo vacía, no cero). El rendimiento es páginas/min en tiempo real, incluida la inicialización del modelo.

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

CORD (Recibos de Indonesia): Desajuste de Idioma e Inflación de la Verdad Terrenal

CORD v2 es un conjunto de datos de recibos en indonesio con campos anidados (menú, subtotal, total). Ninguno de los 8 motores fue entrenado predominantemente con 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 de la verdad terrenal de CORD incorpora la estructura de anotación, lo que infla el CER bruto para todos los motores; los resultados de CORD se mantienen estrictamente separados de la clasificación de SROIE y no se pueden fusionar en una única tabla de clasificación.

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 realmente leen mal las palabras indonesias — los nombres indonesios, las direcciones y los formatos de moneda (Rp) están fuera de sus distribuciones de entrenamiento. Segundo, la verdad terrenal: las anotaciones de texto publicadas de CORD incorporan 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 estructuralmente aumentada. Los ejemplos de VLM más limpios son penalizados con mayor dureza — PaddleOCR-VL con CER 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 de idioma es real y universal en todas las arquitecturas — cada familia, tanto tradicional como VLM, se sitúa 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 una clasificación combinada: el CER de CORD combina un desajuste lingüístico real con una inflación de la estructura de anotación en el ground truth (metodología más abajo). Un CER superior a 1.0 (PaddleOCR-VL 1.0805) es un artefacto de distancia de edición de ese ground truth inflado.

Campo F1: 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 elimina la brecha entre motores en SROIE, llevando a seis de ocho motores a una banda de F1 de campo de 0.57–0.62 — mientras que sus resultados con regex se distribuí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 conjunto de datos; 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 almacenados 0–1 mostrados como %). Postprocesador LLM: deepseek-v4-flash (columna llm_model). 361 muestras por motor (llm_ok_count).

Tabla: field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1, filas sroie_2019. LLM = postprocesamiento con deepseek-v4-flash (columna llm_model). docTR regex 0.0766 → LLM 0.6171 (8.1× de mejora); los 6 motores no rezagados abarcan de 0.5685 a 0.6171.

En esta tabla hay dos resultados contraintuitivos. Primero, docTR tiene el peor F1 de campo con regex en SROIE (0.077) y el mejor F1 de campo con LLM (0.617) — el mismo texto OCR limpio que el regex convirtió en 7.7% de los campos rindió 61.7% con el LLM. El cuello de botella era el postprocesador, no el OCR. Segundo, los dos motores que quedan fuera de la banda de 0.57–0.62 son exactamente los dos con bases de OCR degradadas: EasyOCR (0.372, CER de SROIE 0.283) y Tesseract — cuyo resultado en CORD (F1 de campo con 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 de OCR que tiene debajo.

En CORD, el LLM también absorbe parte del choque lingüístico: el F1 de campo 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) incluso cuando las regex colapsan a casi cero (docTR 0,0, EasyOCR 0,7%) — los patrones se escribieron para formatos en inglés, y la penalización de "un idioma más" la pagan casi por completo 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 a los VLM de análisis de documentos

El CER compara la salida del VLM y la verdad de referencia carácter por carácter, y los VLM se penalizan por dos comportamientos legítimos que no son errores de reconocimiento: la normalización de mayúsculas/minúsculas y la fusión de etiqueta/valor. La descomposición del CER del benchmark en SROIE atribuye aproximadamente 18% del CER del VLM a diferencias de formato de mayúsculas/minúsculas (p. ej., TAN CHAY YEE → tan chay yee) y aproximadamente 10% a la fusión de líneas o a 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 de SROIE).

La tensión de diseño es real y estructural: los motores OCR tradicionales generan texto sin procesar con mayúsculas/minúsculas intactas, por lo que están optimizados por diseño para la puntuación CER; los VLM de análisis de documentos generan texto "comprendido" (mayúsculas/minúsculas normalizadas, pares etiqueta-valor fusionados, líneas reordenadas), que está más cerca de lo que quiere un sistema posterior, pero más lejos de las coincidencias carácter por carácter. 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 reside en las métricas de campo — y por eso el CER de CORD (que además arrastra inflación por la estructura de anotaciones) se aísla en su propia sección. El punto general: una brecha de CER entre familias no es automáticamente una brecha de precisión, y cualquiera que compare modelos entre familias debería verificar qué está midiendo el CER antes de concluir que una familia "lee mejor".

Cómo elegir: qué eje importa para su carga de trabajo

"Mejor" no significa nada sin una carga de trabajo. La conclusión honesta del benchmark es que las dos familias ganan en ejes distintos, y los recibos miden específicamente los ejes donde ganan los motores tradicionales y los ejes donde el postprocesamiento — no la familia de motores — 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. Sus resultados exactos varían según el hardware, la mezcla de documentos y las versiones de los modelos.

Preguntas Frecuentes

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

No en precisión de caracteres en bruto — el mejor VLM y el mejor motor tradicional están estadísticamente empatados en SROIE 2019 (Surya2 CER 0.191 vs docTR 0.197, filas sroie_2019 de summary_metrics.csv), y PaddleOCR (0.204) es tercero. Cuando el objetivo es la extracción de campos, con VLM o sin él, 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 es 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, filas doctr y surya2 de sroie_2019). Para una espera interactiva por página, la diferencia es de 0.1 segundos frente a 2.7 segundos.

¿Por qué los VLM de análisis de documentos a veces obtienen peores resultados en CER que el OCR económico?

Porque el CER puntúa coincidencias exactas de caracteres, y los VLM se ven penalizados por la normalización de mayúsculas/minúsculas y la fusión de etiqueta/valor que son convenciones de salida, no errores de lectura. La descomposición del CER del benchmark en SROIE atribuye aproximadamente 18% del CER de los VLM a diferencias de formato de mayúsculas y ~10% a fusión de líneas/separadores omitidos — con los valores de campo en sí a menudo correctos (ver Metodología). El CER de CORD se ve además 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 clasificación y usa 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 cada 1,000 páginas en una RTX 4090 a $0.76/hora, 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 solo usa 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 una puntuación superior a 0.90 de CER en recibos CORD?

Dos causas que se combinan: un desajuste lingüístico real (recibos indonesios fuera del enfoque de entrenamiento de todos los motores) y una inflación de la estructura de anotaciones dentro del texto de referencia de CORD. Ninguna familia escapa a esto: los 8 modelos se sitúan en la banda de 0.90 a 1.08 (summary_metrics.csv cer, filas cord_v2). CORD es un conjunto de pruebas de robustez de idioma y diseño, que se mantiene separado de la clasificación SROIE.

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

Solo hasta la calidad del texto base. En SROIE, el LLM elevó seis motores a una banda de F1 de campo de 0.57 a 0.62 independientemente del motor (field_method_comparison.csv), pero el caso CORD de 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 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 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 (8 modelos × 2 conjuntos de datos: CER/WER, F1 de campo, latencia, costo, rendimiento) y results/field_method_comparison.csv (regex vs. postprocesamiento con 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 una ejecución de referencia independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros. 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ú/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 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). Las 16 ejecuciones se completaron con error_rate 0.0 (columna error_rate de summary_metrics.csv).

Entorno de ejecución

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

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

Definición de métricas

• CER (tasa de error de caracteres): distancia de edición (inserciones + eliminaciones + sustituciones) entre el texto del OCR y la verdad de referencia, dividida por los caracteres de la verdad de referencia. Cuanto menor, mejor. Es 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 nivel de palabras.
• 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 del OCR (pipeline de OCR tradicional + KIE basado en reglas). Columna: regex_field_value_f1.
• 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.
• Latencia p50/p95 y páginas/min: tiempo de inferencia por página en estado estable (medido en caliente, excluye la carga del modelo) y rendimiento en 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; 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 cifra de CER/WER, latencia, costo y rendimiento en esta página proviene de 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, recuentos de tokens. Cada cifra de F1 de campo regex/LLM proviene de 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 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 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). Este benchmark 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 permanecen sin medir 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 dependen del corpus; diferencias de unas pocas centésimas deben tratarse como ruido, no como verdad de ingeniería.
• Nivel de GPU único: todos los números de GPU provienen de una RTX 4090 a $0.76/hora. Otras GPU, 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 de CPU mientras que su ventaja de costo refleja facturación de GPU cero. Esto se marca 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 puede 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 forma parte de la latencia del propio motor OCR.
• Marca de tiempo del costo: el precio de GPU de $0.76/hora se registró en los manifiestos de ejecución en agosto de 2026. Los precios de GPU spot/on-demand cambian; vuelva a derivar los costos a las tarifas actuales antes de presupuestar.
• El CER de CORD no es una lectura de calidad: la verdad fundamental de CORD incorpora 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 desajuste de idioma + inflación de la verdad fundamental, 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 por proveedor y fuertemente ajustada podría puntuar más alto en sus propios formatos — al costo de mantenimiento que el LLM elimina.
• Sin modelos de nube/API: AWS Textract, Google Document AI, Azure AI Document Intelligence y API 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 versiones: los resultados corresponden a las versiones de modelos de agosto de 2026 listadas arriba; versiones más nuevas de cualquier motor pueden cambiar los resultados, y las latencias p50 de las dos mediciones con grandes picos p95 (PaddleOCR, Docling) reflejan efectos de prefill/primera página bajo el patrón de lote de esta ejecución.

Referencias relacionadas: los límites de regex para extracción de campos · precisión a nivel de campo y a nivel de carácter comparadas · Precisión de OCR de recibos · datos de precisión de OCR por tipo de documento

Lectura relacionada: Precisión de OCR con IA vs OCR clásico · cómo la extracción con visión de IA lee imágenes de manera diferente al OCR · Precios de Extracción de Documentos con IA (2026)