Surya2 vs Unlimited-OCR vs PaddleOCR-VL:
Comparativa VLM de recibos (2026)

Los tres motores son modelos de visión y lenguaje (VLM) para el análisis de documentos: modelos neuronales que leen una imagen de documento completa y generan texto comprendido —con minúsculas, pares etiqueta/valor fusionados en líneas únicas, filas reordenadas según el orden de lectura— en lugar de las secuencias de caracteres sin procesar con el formato original que devuelven los motores OCR tradicionales (Tesseract, PaddleOCR, EasyOCR, docTR —los otros motores de la ejecución subyacente). Esa convención de salida es lo que hace que sus cifras de extracción de campos sean sólidas de serie y que sus cifras de error de caracteres sin procesar resulten engañosas, como muestra la siguiente sección. Dentro de la familia VLM, los tres difieren notablemente en tamaño y objetivo de entrenamiento: Surya2 es un modelo de 650M de parámetros, centrado en texto, ajustado para la transcripción limpia de páginas completas (más de 90 idiomas); PaddleOCR-VL es un generalista compacto de 0.9B diseñado para abarcar idiomas, tablas y fórmulas; Unlimited-OCR está orientado al análisis de documentos largos y por lotes (la lectura en una sola pasada de documentos de más de 40 páginas es su núcleo comercial). Una advertencia importante se aplica a cada cifra de CER a continuación: la tasa de error de caracteres cuenta inserciones, eliminaciones y sustituciones frente a los caracteres de referencia, por lo que penaliza exactamente las normalizaciones que los VLM están entrenados para realizar. La puntuación F1 a nivel de campo es la referencia más justa entre VLM, y es la columna vertebral de esta página.

Por qué no usar CER para VLM: la dispersión de 3,4× es una convención de salida, no capacidad de lectura

Si lees solo la columna de CER sin procesar, Unlimited-OCR parece un modelo fallido (0,6552 en SROIE) mientras que Surya2 parece de primer nivel (0,1915, empatado con el 0,1971 del docTR tradicional como el mejor CER sin procesar de la ejecución de 8 motores). Ambas lecturas son artefactos del estilo de salida. El mismo texto de Unlimited-OCR que obtiene un CER de 0,6552 obtiene 0,4779 de WER —sus palabras sobreviven mientras que sus caracteres parecen destrozados, porque la conversión a minúsculas sustituye caracteres sin romper palabras. Las cifras de PaddleOCR-VL invierten el patrón: su CER de CORD de 1,0805 es el peor de los 8 motores, mientras que su F1 de campo de CORD de 0,3412 es el mejor de los 8 —el propio CSV del benchmark contradice la clasificación por CER.

El mecanismo tiene dos capas. Capa 1 — impuesto de normalización: los VLM de análisis de documentos generan texto “comprendido” —TAN CHAY YEE se convierte en tan chay yee, INVOICE NO : PEGIV fusiona una etiqueta y un valor en una sola línea. El CER es una coincidencia exacta de caracteres, por lo que cada minúscula y cada línea fusionada se puntúa como error incluso cuando el valor del campo es correcto. El análisis de descomposición de errores del benchmark sobre las predicciones publicadas de SROIE atribuye aproximadamente una quinta parte del presupuesto de CER sin procesar a sustituciones de mayúsculas/minúsculas y aproximadamente una décima parte a fusiones/eliminaciones de líneas; los tres motores pagan ese impuesto a ritmos distintos —la fuerte conversión a minúsculas de Unlimited-OCR infla su CER muy por encima de su WER, mientras que la fusión de líneas/etiquetas de PaddleOCR-VL eleva su WER (0,6462) por encima de su propio CER (0,3370). Capa 2 — inflación de la estructura de referencia en CORD: el texto de referencia de CORD incorpora estructura de anotación (entradas de menú, coordenadas, etiquetas de campo), por lo que el CER se infla sistemáticamente para todos los motores además del verdadero desajuste de idioma —el grupo de CER de CORD de todos los motores de 0,90–1,08 (Tesseract tradicional 0,9523, docTR 0,9101 y todos los VLM incluidos) confirma que la inflación es generalizada en el corpus, no específica del modelo.

Tabla: summary_metrics.csv — columnas cer y wer, filas sroie_2019. Valores exactos: Surya2 cer 0.19147 / wer 0.27352; Unlimited-OCR cer 0.65524 / wer 0.47788; PaddleOCR-VL cer 0.33696 / wer 0.64623. Cuanto más bajo, mejor; las tres ejecuciones se completaron con error_rate 0.0. No clasifiques los VLM por CER: la divergencia CER/WER de Unlimited-OCR (0.6552 vs 0.4779) y la inversión CER-vs-F1-de-campo en CORD de PaddleOCR-VL (ver más abajo) son artefactos de convención de salida del tipo exacto que el protocolo de este benchmark señala para las filas de VLM.

La consecuencia de las Capas 1 y 2 es que cada sección restante de esta página compara los tres VLM en la puntuación F1 de extracción de campos (las métricas que alimentan directamente su salida estructurada) y en el envelope operativo (latencia, rendimiento, costo) — y cita el CER solo junto con sus advertencias. Esta es la regla del protocolo del benchmark para las filas de VLM de análisis de documentos, y es el enfoque correcto: un pipeline de recibos consume campos (empresa, fecha, dirección, total), no flujos de caracteres.

Extracción de campos lista para usar: la salida estructurada es el rasgo distintivo de la familia VLM

Al pasar el texto bruto de cada motor por 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—, los tres VLM se sitúan dentro de una banda de 0.02 puntos: Unlimited-OCR 0.3376, PaddleOCR-VL 0.3368, Surya2 0.3183. Los tres se ubican entre los cuatro primeros de la ejecución de ocho motores; dos superan al mejor motor tradicional (PaddleOCR con 0.3254), y el tercero queda a 0.007 puntos por detrás. Su “texto comprendido” llega a los consumidores de campos incluso sin ningún posprocesador LLM —el rasgo familiar del que carecen los motores OCR de caracteres brutos.

La puntuación F1 de valores de campo es la media armónica de precisión y exhaustividad sobre los valores de campos extraídos frente a la verdad de referencia: 1.0 significa que cada campo del recibo se recuperó perfectamente, 0 significa que no se recuperó nada. El mecanismo detrás de la ventaja de la familia VLM es la forma de salida descrita anteriormente —el mismo texto con etiquetas estructuradas y minúsculas que infla el CER coincide con los patrones de extracción. Las columnas de “extracción de campos por regex” son las métricas postprocessed_sroie_receipt_regex_* del benchmark: miden texto OCR + extracción posterior basada en reglas, no salida estructurada nativa, y el mismo conjunto de patrones se aplicó a cada motor. En contraste, la F1 de campos por regex de los motores tradicionales se sitúa en 0.0766 (docTR), 0.1477 (EasyOCR), 0.2237 (Docling) y 0.2335 (Tesseract) —seis de los siete motores no VLM quedan por debajo del miembro más bajo del trío.

Fuente: field_method_comparison.csv — columnas regex_field_value_f1 / llm_field_value_f1, filas sroie_2019 (decimales almacenados de 0–1 mostrados como %). Posprocesador LLM: deepseek-v4-flash (columna llm_model). 361 muestras por motor (llm_ok_count).

Tabla: field_method_comparison.csv — columnas de regex, filas sroie_2019. Son métricas postprocessed_sroie_receipt_regex_*: patrones fijos aplicados al texto de OCR de cada motor (postprocesado, no extracción nativa). El 0.3183 de Surya2 es el más bajo del trío, pero aun así ocupa el cuarto puesto de ocho motores y queda 0.007 por debajo del mejor motor tradicional (PaddleOCR 0.3254, fila paddleocr/sroie_2019 de summary_metrics.csv field_f1_regex).

La palanca del LLM: los tres motores convergen

Si se alimenta el texto OCR de los tres motores a un posprocesador LLM (deepseek-v4-flash, temperatura 0) con un prompt de extracción estructurada, la banda fuera de caja se estrecha hasta casi empatar: Surya2 0.6139, Unlimited-OCR 0.6054, PaddleOCR-VL 0.5921 — una diferencia de 0.022 puntos, totalmente dentro de la banda de convergencia de 0.57–0.62 del benchmark para motores saludables. El posprocesador, no el VLM, se convierte en el componente decisivo.

Este es el mismo patrón de convergencia que muestra la ejecución completa de 8 motores: un LLM entiende semántica (números, fechas, nombres) en lugar de comparar formas de caracteres, por lo que absorbe la mayoría de las diferencias en la calidad del texto aguas arriba — siempre que el texto sea lo bastante legible para trabajar. Los tres VLM califican; los tres caen dentro de la banda. La palanca tiene un costo: una llamada al LLM añade aproximadamente 1.9–2.3 s de latencia mediana por documento además del tiempo de OCR (1,946.7 ms para el texto de PaddleOCR-VL, 1,982.0 ms para el de Unlimited-OCR, 2,261.7 ms para el de Surya2 — incurridos por la API e idénticos en naturaleza), lo que favorece el procesamiento por lotes asíncrono sobre las esperas síncronas página por página. La exactitud a nivel de documento — la fracción de recibos donde todos los cuatro campos coincidieron — sigue siendo baja para los tres (0.1219–0.1551), un recordatorio de que la puntuación F1 por campo es la cifra operativa significativa.

Tabla: field_method_comparison.csv — columnas llm_*, filas sroie_2019. Modelo LLM: deepseek-v4-flash a temperatura 0 (columna llm_model). La latencia del LLM es incurrida por la API y separada de la latencia del motor (summary_metrics.csv latency_p50_ms).

CORD (recibos de Indonesia): el generalista compacto gana

CORD v2 (100 recibos de Indonesia, campos anidados menú/subtotal/total) es la prueba de estrés multilingüe del benchmark — y es donde los tres VLM realmente se separan. Con los mismos patrones de regex en formato inglés, PaddleOCR-VL extrae campos de recibos de Indonesia con una puntuación F1 de campo de 0.3412 — la más alta de los 8 motores en todo el benchmark — mientras que Surya2 alcanza 0.2458 y Unlimited-OCR cae a 0.1079. La amplitud de entrenamiento del generalista compacto muestra exactamente dónde pierden terreno los modelos centrados en texto y los de documentos largos.

Todos los valores de CER de CORD están aislados por el protocolo del benchmark y nunca se fusionan en ninguna clasificación de SROIE: el ground truth de CORD incorpora estructura de anotación (lo que infla el CER bruto de cada motor además del genuino desajuste de idioma — el grupo de CER de CORD de todos los motores es de 0.90–1.08), y los patrones de regex se escribieron para formatos en inglés. La comparación de CORD a continuación es solo de métricas de campo. Con un postprocesador LLM, el choque de idioma se absorbe como en SROIE: el trío vuelve a converger a una puntuación F1 de campo de 0.4678–0.5203 (Surya2 0.5203, PaddleOCR-VL 0.5198, Unlimited-OCR 0.4678) — el postprocesador, no el motor, hace el trabajo pesado multilingüe.

Fuente: summary_metrics.csv — columna field_f1_regex, filas cord_v2 (decimales almacenados de 0–1 mostrados como %). PaddleOCR-VL 0.3412 es el field_f1_regex máximo entre las 16 filas del archivo; el siguiente mejor en regex de CORD es Surya2 0.2458.

Tabla: summary_metrics.csv (field_f1_regex / cer) y field_method_comparison.csv (llm_field_value_f1), filas cord_v2. No combines los números de CORD con ninguna clasificación de SROIE: el CER de CORD combina un desajuste lingüístico genuino con una inflación de la estructura de anotación en la verdad de referencia (todos los motores se agrupan en 0.90–1.08 — incluidos Tesseract tradicional 0.9523 y docTR 0.9101); el CER de PaddleOCR-VL de 1.0805 es el más alto de los 8 motores precisamente porque su salida limpia y normalizada es la más alejada de la verdad de referencia cargada de estructura de CORD — mientras que su F1 de campo regex es la mejor del benchmark.

El Envolvente Operativo: 3.8× de Latencia, 5.2× de Costo

La precisión de campo converge; el costo operativo no. En la misma RTX 4090 a la misma tarifa registrada de $0.76/hr, PaddleOCR-VL mantiene 68.2 páginas/min a 694.3 ms p50 por página por $0.205 por 1,000 páginas; Unlimited-OCR se sitúa en el medio del envolvente a 34.4 páginas/min, 1,600.7 ms p50, $0.388 por 1,000 páginas; Surya2 es el valor atípico en precio y latencia a 12.1 páginas/min, 2,668.0 ms p50, $1.061 por 1,000 páginas. El VLM más rápido es 3.8× más rápido y 5.2× más barato que el más lento en hardware idéntico.

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), incluida la inicialización del modelo — el precio que realmente pagarías por el tiempo de GPU. El rendimiento es páginas por minuto 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 (excluida la carga del modelo); la cola de Surya2 es proporcionalmente peor — 5,872.2 ms p95 frente a los 1,154.3 ms de PaddleOCR-VL — porque los picos de prefill/decode del VLM dominan la cola en las primeras páginas. Dos números para leer juntos en lugar de uno contra otro: PaddleOCR-VL tiene el p50 más bajo pero es superado en rendimiento de pared por Unlimited-OCR en CORD (73.99 vs 67.13 páginas/min) — las cifras de pared incluyen la inicialización del modelo, y el manejo de lotes vLLM de Unlimited-OCR es lo suficientemente eficiente como para invertir el orden allí.

Fuente: summary_metrics.csv — columna latency_p50_ms, filas sroie_2019. Surya2 2667.9800, Unlimited-OCR 1600.7459, PaddleOCR-VL 694.2519. Latencia en estado estable (modo de medición warm_then_scored).

Fuente: summary_metrics.csv — columna cost_per_1000_pages, filas sroie_2019. Surya2 1.0609, Unlimited-OCR 0.3879, PaddleOCR-VL 0.2048. Costo = tiempo de ejecución × $0.76/h incluyendo la inicialización del modelo, precio con marca de tiempo en los manifiestos de ejecución (agosto de 2026).

Tabla: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, filas sroie_2019. Los tres motores en GPU (RTX 4090, precio de $0.76/h con marca de tiempo en los manifiestos); el costo incluye la inicialización del modelo, no el rendimiento puro en estado estable. Valores exactos: Surya2 p50 2668.0 / p95 5872.2 / 12.1 págs/min / $1.0609; Unlimited-OCR p50 1600.7 / p95 2521.9 / 34.4 págs/min / $0.3879; PaddleOCR-VL p50 694.3 / p95 1154.3 / 68.2 págs/min / $0.2048.

Quién gana y cuándo: el resumen

“Mejor” depende de la carga de trabajo, y entre estos tres VLM los ejes se dividen claramente: la precisión de campos converge (regex y LLM), el texto bruto favorece a Surya2, los campos multilingües favorecen a PaddleOCR-VL, y todos los ejes de costo/latencia/rendimiento favorecen a PaddleOCR-VL, con Unlimited-OCR en el medio. La conclusión honesta es que en recibos, con cualquier postprocesador en el flujo, la elección del VLM importa poco — y sin uno, el generalista compacto y barato supera a los especialistas costosos en los ejes que suelen importar.

Preguntas frecuentes

¿Qué VLM de análisis de documentos es más preciso en recibos?

En extracción de campos, hay un triple empate técnico en recibos en inglés: F1 de campos regex SROIE 0.3183–0.3376 y F1 de campos LLM 0.5921–0.6139 entre Surya2, Unlimited-OCR y PaddleOCR-VL (field_method_comparison.csv, filas sroie_2019). En recibos indonesios la respuesta cambia: el F1 de campos regex CORD de PaddleOCR-VL de 0.3412 es el mejor de los 8 motores del benchmark (summary_metrics.csv, field_f1_regex, filas cord_v2). El CER bruto no debe usarse para clasificar VLM: cuenta convenciones de salida (normalización de mayúsculas, fusión de líneas) como errores (ver la sección “Por qué no usar CER” más arriba).

¿Por qué Unlimited-OCR tiene el peor CER pero el mejor F1 de campos regex en SROIE?

Porque las dos métricas evalúan salidas distintas. La fuerte normalización de mayúsculas de Unlimited-OCR infla los errores a nivel de carácter — su CER de 0.6552 frente a un WER de 0.4779 lo delata — mientras que ese mismo texto normalizado coincide mejor con los patrones de extracción fijos que cualquier otro motor: F1 de campos regex SROIE 0.3376, el mejor de la ejecución de 8 motores (summary_metrics.csv cer / wer, field_method_comparison.csv regex_field_value_f1, filas sroie_2019).

¿Por qué el CER CORD de PaddleOCR-VL es el peor del benchmark mientras que su F1 de campos CORD es el mejor?

Porque la verdad fundamental de CORD incorpora estructura de anotación y la salida de PaddleOCR-VL es la más limpia y normalizada — la más alejada de ese texto con estructura, por lo que su distancia de edición es la mayor (CER 1.0805). Ese mismo estilo de salida alimenta bien los patrones de extracción: F1 de campos regex CORD 0.3412, el mejor de los 8 motores (summary_metrics.csv, cer / field_f1_regex, filas cord_v2). Esta inversión es la propia demostración del benchmark de que el CER de CORD no es una lectura de calidad por modelo.

¿Cuánto más rápido y barato es PaddleOCR-VL que Surya2?

3,8× menor latencia p50 (694,3 ms frente a 2.668,0 ms), 5,6× mayor rendimiento (68,2 frente a 12,1 páginas/min) y 5,2× menor costo por cada 1.000 páginas ($0,205 frente a $1,061) en la misma RTX 4090 a $0,76/hora (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, filas de sroie_2019).

¿Añadir un posprocesador LLM iguala a los tres VLM?

Casi — de 0,5921 a 0,6139 de F1 de campo con LLM en SROIE, una diferencia de 0,022 puntos dentro de la banda de convergencia de 0,57–0,62 del benchmark (field_method_comparison.csv, llm_field_value_f1, filas de sroie_2019). El costo de esa convergencia es de aproximadamente 1,9–2,3 s de latencia LLM mediana adicional por documento (llm_median_latency_ms, mismas filas), lo que favorece el procesamiento por lotes asíncrono.

¿Cuál de los tres VLM debería elegir un pipeline de recibos?

Depende del eje que consuma tu pipeline. Para campos nativos multilingües sin posprocesador, el F1 de regex de CORD de PaddleOCR-VL (0,3412) es el único nivel útil medido. Para el servicio VLM más barato y rápido, también PaddleOCR-VL (694,3 ms, $0,205/1K páginas). Para texto limpio en inglés cuando el costo y la latencia no son limitantes, el CER de Surya2 (0,1915) es el más fuerte. Para un punto equilibrado de volumen medio, Unlimited-OCR (1.600,7 ms, $0,388/1K páginas, mejor F1 de campo SROIE de fábrica). Con un posprocesador LLM en el pipeline, la elección importa poco en recibos — los tres caen en la banda de convergencia. Estos resultados se mantienen para recibos en inglés e indonesio en un nivel de GPU en agosto de 2026; cualquier decisión de producción debería reejecutarse sobre el corpus objetivo (ver Limitaciones).

¿De dónde provienen los números de esta página?

Cada cifra es una fila de los CSV publicados del benchmark de primera parte — results/summary_metrics.csv (CER/WER, F1 de campo, latencia, 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 a continuación.

Metodología y fuentes

Protocolo

Esta página informa un corte de tres vías de una ejecución de benchmark independiente y reproducible (nivel oficial) — no es un estudio 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. Los tres motores vieron las mismas imágenes, la misma verdad de referencia y el mismo protocolo de medición (warm_then_scored: una pasada de calentamiento fija precede a la pasada puntuada, por lo que las cifras de latencia son de estado estable). Las tres ejecuciones se completaron con error_rate 0.0 (columna error_rate de summary_metrics.csv). La ejecución subyacente contiene ocho motores en total; esta página compara solo los tres VLM nombrados, y los resultados completos de los 8 motores se publican por separado en VLM de OCR tradicional vs análisis de documentos.

Entorno de ejecución

• Hardware: los tres motores se ejecutaron en la misma NVIDIA RTX 4090 (24 GB); el costo de GPU se calculó a la tarifa bajo demanda de RunPod de $0.76/hora, con el precio con marca de tiempo en el manifiesto redactado de cada ejecución (agosto de 2026).
• Motores: listos para usar, sin ajuste fino. Versiones fijadas: Surya2 (surya-ocr 0.22.1) y PaddleOCR-VL 1.6, ambos servidos con vLLM; Unlimited-OCR servido con vLLM sin una versión pública fijada (ver Limitaciones) — 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 los tres motores.
• Base de costo: tiempo de ejecución en pared × $0.76/hora, incluida la inicialización del modelo — el procesamiento por lotes reduce el costo por página.
• Postprocesamiento de campos: las métricas de campos regex de SROIE son postprocessed_sroie_receipt_regex_* (columnas regex_* de field_method_comparison.csv) — campos extraídos del texto de OCR mediante un conjunto de patrones fijo. Miden OCR + extracción posterior, no salida estructurada nativa de ningún modelo; las columnas LLM_* miden texto de OCR + extracción con LLM. Los dos pipelines nunca se combinan.

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. Injusto para los VLM de análisis de documentos: penaliza el cambio de mayúsculas/minúsculas, la fusión de etiquetas/valores y la reorganización de líneas como errores, incluso cuando los valores de los campos son correctos. En esta página solo se cita junto con sus advertencias.
• WER (tasa de error de palabras): el mismo cálculo de distancia de edición a nivel de palabras. Cuando CER y WER divergen notablemente (Unlimited-OCR: 0.6552 frente a 0.4779), la diferencia marca dónde la normalización de la salida, y no una lectura errónea, está causando el daño.
• F1 de valores de campo (regex): media armónica de precisión/recuperación sobre los valores de campo extraídos mediante patrones regex fijos en el texto del OCR (OCR tradicional + pipeline 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 posprocesador LLM (texto del 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 (medido en caliente, excluye la carga del modelo) y rendimiento en tiempo real, incluida la inicialización del modelo.
• Costo por cada 1,000 páginas: horas de GPU facturadas por 1,000 páginas a la tarifa registrada de $0.76/hora.

Lista de fuentes

1. summary_metrics.csv (GitHub raw). 16 filas = 8 modelos × 2 conjuntos de datos. Columnas: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Todas las cifras de CER/WER, latencia, costo y rendimiento de esta página provienen de las filas surya2, unlimited_ocr y paddleocr_vl_vllm.
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. Todas las cifras de F1 de campo regex/LLM provienen de las filas de los tres motores nombrados 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 su reproducción.
4. results/manifests/ (GitHub). Un manifest.json redactado por ejecución publicada (16 ejecuciones) con versiones de modelo, GPU/controlador, versiones de torch/CUDA/Python, metadatos de costo con marca de tiempo de precio y hashes de artefactos.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definición del conjunto de datos SROIE 2019, estructura de tareas y licencia (CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definición del conjunto de datos CORD v2, esquema de campos anidados y licencia (CC-BY-4.0).

Limitaciones

• La injusticia del CER hacia los VLM es la razón por la que esta página se basa en métricas de campo: los VLM de parseo de documentos normalizan mayúsculas, fusionan líneas de etiqueta/valor y reordenan texto, por lo que las puntuaciones CER crudas marcan las convenciones de salida como errores — la divergencia de Unlimited-OCR entre CER (0.6552) y WER (0.4779) y la inversión de CORD de PaddleOCR-VL (peor CER 1.0805, mejor F1 de campo 0.3412) son ambos artefactos de ese impuesto. Cualquier comparación que clasifique VLM por CER — incluida esta página — debe tratarse como una medida del estilo de salida, no de la capacidad de lectura.
• Alcance del documento — solo recibos: SROIE + CORD. Nada aquí mide el manejo de diseño/tablas/fórmulas/documentos largos donde los VLM de parseo de documentos reclaman sus mayores ventajas; las fortalezas comercializadas de los tres motores (incluido el parseo de una sola pasada de más de 40 páginas de Unlimited-OCR) están sin medir. No use esta página para concluir “el VLM X gana en todo”.
• Tamaño de muestra: 361 recibos en inglés + 100 en indonesio. El F1 de campo y el CER son sensibles al corpus; diferencias de un solo dígito de unas pocas centésimas (incluida la diferencia de 0.022 puntos en el F1 del LLM) deben tratarse como ruido, no como verdad de ingeniería.
• Un solo nivel de GPU y un solo precio: todos los números provienen de una RTX 4090 a $0.76/hora, con precio con marca de tiempo de agosto de 2026 en los manifiestos de ejecución. Otras GPU, servicio multi-GPU, programación por lotes o cambios de precio alterarán la latencia, el rendimiento y el costo — recalcule 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 de campo absoluto; el orden de convergencia puede moverse en los márgenes. La latencia del LLM (~1.9–2.3 s de mediana, field_method_comparison.csv llm_median_latency_ms) la incurre la API y no forma parte de la latencia propia de ningún motor.
• Cuarentena de CORD: la verdad de referencia de CORD incorpora estructura de anotación y los patrones de regex se escribieron para formatos en inglés; el CER de CORD (0.90–1.08 en todos los motores) refleja desajuste de idioma + inflación de la verdad de referencia, no calidad por modelo. 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 Surya2 0.22.1, PaddleOCR-VL 1.6 y Unlimited-OCR servido con vLLM (agosto de 2026). Unlimited-OCR no tiene un número de versión fijado públicamente en la tabla de modelos publicada del benchmark, por lo que su fila no se puede rastrear a una versión exacta; versiones más nuevas de cualquier motor pueden cambiar cada número de esta página.
• 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.

Referencias relacionadas: Benchmark de recibos docTR vs Surya2 · OCR tradicional vs VLM de parseo de documentos · qué método de extracción gana en diseños desordenados · puntuación por campo vs puntuación por carácter · Precisión de OCR de recibos

Lecturas relacionadas: OCR con IA frente al OCR tradicional · extracción de datos de imágenes frente a motores de OCR · Precios de extracción de documentos con IA (2026)