Surya2 vs Unlimited-OCR vs PaddleOCR-VL:
Benchmark de VLM para Recibos (2026)

Los tres motores son modelos de visión y lenguaje (VLM) para análisis de documentos: modelos neuronales que leen una imagen de documento completa y producen texto interpretado — con caja unificada, pares etiqueta/valor fusionados en una sola línea, filas reordenadas por orden de lectura — en lugar de los flujos de caracteres crudos con caja original que devuelven los motores OCR tradicionales (Tesseract, PaddleOCR, EasyOCR, docTR — los otros motores en la ejecución subyacente). Esa convención de salida es lo que hace que sus números de extracción de campos sean sólidos de entrada y que sus números de error de caracteres crudos sean engañosos, 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 650 millones de parámetros, centrado en texto, ajustado para transcripción completa de páginas limpias (más de 90 idiomas); PaddleOCR-VL es un generalista compacto de 0.9B construido para amplitud en idiomas, tablas y fórmulas; Unlimited-OCR está orientado al análisis de documentos largados y por lotes (su núcleo comercializado es la lectura en una sola pasada de documentos de más de 40 páginas). Una advertencia importante aplica a cada número de CER a continuación: la tasa de error de caracteres cuenta inserciones, eliminaciones y sustituciones contra 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 métrica más justa entre VLM, y es el eje de esta página.

¿Por qué no usar CER para VLM? La dispersión de 3,4× es convención de salida, no capacidad de lectura

Si solo se lee la columna de CER crudo, Unlimited-OCR parece un modelo fallido (0,6552 en SROIE) mientras que Surya2 parece de nivel mundial (0,1915, empatado con el docTR tradicional de 0,1971 para el mejor CER crudo en la ejecución de 8 motores). Ambas lecturas son artefactos del estilo de salida. El mismo texto de Unlimited-OCR que obtiene 0,6552 de CER obtiene 0,4779 de WER — sus palabras sobreviven mientras que sus caracteres parecen destrozados, porque la unificación de caja reemplaza caracteres sin romper palabras. Los números 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 campos 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 producen texto "interpretado" — 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 caja unificada y línea fusionada se puntúa como un error incluso cuando el valor del campo es correcto. El análisis de descomposición de errores del benchmark de las predicciones de SROIE publicadas atribuye aproximadamente una quinta parte del presupuesto de CER crudo a sustituciones de caja y aproximadamente una décima parte a fusiones/eliminaciones de líneas; los tres motores pagan ese impuesto a diferentes tasas — la intensa unificación de caja de Unlimited-OCR infla su CER mucho más allá de su WER, mientras que la fusión de líneas/etiquetas de PaddleOCR-VL empuja 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 incrusta estructura de anotación (entradas de menú, coordenadas, etiquetas de campos), por lo que el CER se infla sistemáticamente para cada motor además de la desajuste lingüístico genuino — el agrupamiento de CER de CORD de todos los motores de 0,90–1,08 (Tesseract tradicional 0,9523, docTR 0,9101, y cada VLM incluido) confirma que la inflación es de todo 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. Menor es mejor; las tres ejecuciones 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 campos de PaddleOCR-VL en CORD (ver más abajo) son artefactos de convención de salida del tipo exacto que el protocolo de este benchmark señala para 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 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 filas de VLM de análisis de documentos, y es la lente correcta: un pipeline de recibos consume campos (empresa, fecha, dirección, total), no flujos de caracteres.

Extracción de Campos Preconfigurada: La Salida Estructurada es la Característica Familiar de los VLM

Ejecute el texto crudo de cada motor a través de 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 — y los tres VLM se mantienen dentro de una banda de 0,02 puntos: Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368, Surya2 0,3183. Los tres se clasifican entre los cuatro primeros de la ejecución de ocho motores; dos de ellos superan al mejor motor tradicional (0,3254 de PaddleOCR), y el tercero lo supera por 0,007 puntos. Su "texto comprendido" llega a los consumidores de campos incluso sin ningún postprocesador LLM — la característica familiar que faltan a los motores OCR de caracteres crudos.

El F1 de valor de campo es la media armónica de precisión y recuperación sobre los valores de campo extraídos contra la verdad fundamental: 1,0 significa que cada campo del recibo se recuperó perfectamente, 0 significa nada. El mecanismo detrás de la ventaja de la familia VLM es la forma de salida descrita anteriormente — el mismo texto estructurado con etiquetas y plegado de mayúsculas que infla la CER resulta coincidir con los patrones de extracción. Las columnas de "extracción de campos regex" son las métricas postprocessed_sroie_receipt_regex_* del benchmark: miden el texto OCR + la extracción basada en reglas posterior, no la salida estructurada nativa, y se aplicó el mismo conjunto de patrones a cada motor. Para contraste, el F1 de campos regex de los motores tradicionales llega a 0,0766 (docTR), 0,1477 (EasyOCR), 0,2237 (Docling) y 0,2335 (Tesseract) — seis de los siete motores no VLM se sitúan 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 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 las métricas postprocessed_sroie_receipt_regex_*: patrones fijos aplicados al texto OCR de cada motor (posprocesado, no extracción nativa). El 0.3183 de Surya2 es el más bajo del trío, pero aún ocupa el cuarto lugar de ocho motores y está 0.007 por debajo del mejor motor tradicional (PaddleOCR 0.3254, field_f1_regex de summary_metrics.csv, fila paddleocr/sroie_2019).

La Palanca del LLM: Los Tres Motores Convergen

Alimenta el texto OCR de los tres motores a un postprocesador LLM (deepseek-v4-flash, temperatura 0) con un prompt de extracción estructurada, y la banda fuera de lo común se estrecha hasta un empate casi perfecto: Surya2 0.6139, Unlimited-OCR 0.6054, PaddleOCR-VL 0.5921 — una diferencia de 0.022 puntos, completamente dentro de la banda de convergencia del benchmark (0.57–0.62) para motores saludables. El postprocesador, 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 la semántica (números, fechas, nombres) en lugar de coincidir con 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 suficientemente legible para trabajar con él. Los tres VLMs califican; los tres caen dentro de la banda. La palanca conlleva un costo: una llamada a 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 y de naturaleza idéntica), lo que favorece el procesamiento por lotes asíncrono sobre las esperas síncronas por página. La exactitud a nivel de documento — la fracción de recibos donde todos los cuatro campos coincidieron — se mantiene baja para los tres (0.1219–0.1551), un recordatorio de que la puntuación F1 por campo es el número operativo significativo.

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 está separada de la latencia del motor (summary_metrics.csv latency_p50_ms).

CORD (Recibos Indonesios): El Generalista Compacto Gana

CORD v2 (100 recibos indonesios, campos anidados menu/sub_total/total) es la prueba de estrés interlingüística del benchmark—y es donde los tres VLMs realmente se separan. A través de los mismos patrones regex en formato inglés, PaddleOCR-VL extrae campos de recibos indonesios con 0.3412 campo F1—el más alto de los 8 motores en todo el benchmark—mientras Surya2 logra 0.2458 y Unlimited-OCR cae a 0.1079. La amplitud de entrenamiento del generalista compacto se muestra exactamente donde los modelos centrados en texto y de documentos largos pierden terreno.

Todos los valores de CER de CORD están cuarentenados por el protocolo del benchmark y nunca se fusionan en ningún ranking de SROIE: la verdad de campo de CORD incrusta la estructura de anotación (inflando el CER bruto para cada motor además del verdadero desajuste lingüístico—el clúster de CER de CORD de 0.90–1.08 para todos los motores), y los patrones regex fueron escritos para formatos ingleses. La comparación de CORD a continuación es solo de métricas de campo. Bajo un postprocesador LLM, el shock lingüístico se absorbe como en SROIE: el trío reconverge a 0.4678–0.5203 campo F1 (Surya2 0.5203, PaddleOCR-VL 0.5198, Unlimited-OCR 0.4678)—el postprocesador, no el motor, hace el trabajo interlingüístico pesado.

Fuente: summary_metrics.csv— columna field_f1_regex, filas cord_v2 (0–1 decimales almacenados mostrados como %). PaddleOCR-VL 0.3412 es el máximo field_f1_regex en 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 fusiones los números de CORD en ningún ranking de SROIE: El CER de CORD combina una discrepancia lingüística genuina con una inflación por la estructura de anotación en el ground truth (todos los motores se agrupan entre 0.90–1.08 — Tesseract tradicional 0.9523, docTR 0.9101 incluidos); 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 estructura del ground truth de CORD — mientras que su F1 de campos por regex es el mejor del benchmark.

La Envoltura Operativa: 3.8× Latencia, 5.2× Costo

La precisión de los campos converge; el costo operativo no. En la misma RTX 4090 con la misma tarifa registrada de $0.76/hr, PaddleOCR-VL mantiene 68.2 páginas/min con 694.3 ms p50 por página para $0.205 por 1,000 páginas; Unlimited-OCR se sitúa en el medio de la envoltura con 34.4 páginas/min, 1,600.7 ms p50, $0.388 por 1,000 páginas; Surya2 es el outlier en precio y latencia con 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 reloj × la tarifa de RunPod RTX 4090 ($0.76/hora, precio con marca de tiempo en los manifiestos de ejecución), incluyendo la inicialización del modelo — el precio que realmente pagarías por el tiempo de GPU. El rendimiento son páginas por minuto de reloj incluyendo esa misma inicialización. La latencia p50/p95 son tiempos de inferencia por página en estado estable medidos en caliente-y-luego-puntuados (excluyendo 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 comparar entre sí: PaddleOCR-VL tiene el p50 más bajo pero es superado en rendimiento de reloj por Unlimited-OCR en CORD (73.99 vs 67.13 páginas/min) — las cifras de reloj incluyen la inicialización del modelo, y el manejo por lotes de 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 real × $0.76/hr incluyendo inicialización del modelo, precio con marca de tiempo en los manifiestos de ejecución (agosto 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 $0.76/hr con marca de tiempo en manifiestos); el costo incluye la inicialización del modelo, no es un rendimiento puro en estado estable. Valores exactos: Surya2 p50 2668.0 / p95 5872.2 / 12.1 pg/min / $1.0609; Unlimited-OCR p50 1600.7 / p95 2521.9 / 34.4 pg/min / $0.3879; PaddleOCR-VL p50 694.3 / p95 1154.3 / 68.2 pg/min / $0.2048.

Quién Gana Cuándo: La Cuadrícula de Resumen

“Mejor” depende de la carga de trabajo, y entre estos tres VLM los ejes se separan claramente: la precisión de campos converge (regex y LLM), el texto crudo 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 la pipeline, la elección del VLM importa poco — y sin uno, el generalista compacto y barato vence a los especialistas costosos en los ejes que suelen importar.

Preguntas Frecuentes

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

En extracción de campos, hay un empate cercano entre tres en recibos en inglés: SROIE regex field F1 0.3183–0.3376 y LLM field F1 0.5921–0.6139 en Surya2, Unlimited-OCR y PaddleOCR-VL (field_method_comparison.csv, filas sroie_2019). En recibos indonesios la respuesta cambia: PaddleOCR-VL’s CORD regex field F1 de 0.3412 es el mejor de los 8 motores en el benchmark (summary_metrics.csv, field_f1_regex, filas cord_v2). La CER en bruto no debe usarse para clasificar VLMs — 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” arriba).

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

Porque las dos métricas evalúan salidas diferentes. 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 WER de 0.4779 lo delata — mientras que el mismo texto normalizado coincide mejor con los patrones de extracción fijos que cualquier otro motor: SROIE regex field F1 0.3376, el máximo de los 8 motores (summary_metrics.csv cer / wer, field_method_comparison.csv regex_field_value_f1, filas sroie_2019).

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

Porque la verdad de referencia de CORD incrusta estructura de anotación y la salida de PaddleOCR-VL es la más limpia y normalizada — la más alejada de ese texto cargado de estructura, por lo que su distancia de edición es la mayor (CER 1.0805). El mismo estilo de salida alimenta bien los patrones de extracción: CORD regex field F1 0.3412, el mejor de los 8 motores (summary_metrics.csv, cer / field_f1_regex, filas cord_v2). Esta inversión es la demostración del benchmark de que la 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 vs 2.668,0 ms), 5,6× mayor rendimiento (68,2 vs 12,1 páginas/min) y 5,2× menor costo por 1.000 páginas ($0,205 vs $1,061) en la misma RTX 4090 a $0,76/hr (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, filas sroie_2019).

¿La adición de un postprocesador LLM iguala a los tres VLM?

Casi — 0,5921 a 0,6139 F1 de campos LLM en SROIE, una diferencia de 0,022 puntos dentro de la banda de convergencia del benchmark de 0,57–0,62 (field_method_comparison.csv, llm_field_value_f1, filas 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 debe elegir un pipeline de recibos?

Depende del eje que consuma tu pipeline. Para campos multilingües nativos sin postprocesador, el F1 de regex CORD de PaddleOCR-VL (0,3412) es el único nivel útil medido. Para servicio VLM más barato y rápido, de nuevo PaddleOCR-VL (694,3 ms, $0,205/1K páginas). Para texto en inglés puro y limpio 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 campos SROIE fuera de la caja). Con un postprocesador LLM en el pipeline, la elección importa poco en recibos — los tres caen en la banda de convergencia. Estos resultados son válidos para recibos en inglés e indonesio en un nivel de GPU en agosto de 2026; cualquier decisión de producción debe re-ejecutarse en el corpus objetivo (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, campo F1, latencia, costo, rendimiento) y results/field_method_comparison.csv (regex vs. posprocesamiento LLM, llm_model = deepseek-v4-flash) — alojados en ImageToTableai/benchmark-ocr, con un manifest.json redactado por ejecución para huellas de entorno. Las definiciones de los conjuntos de datos provienen de los artículos SROIE 2019 y CORD citados a continuación.

Metodología y Fuentes

Protocolo

Esta página presenta un corte triple de una ejecución de benchmark independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros, ni una página de comparación de proveedores. Solo se usaron divisiones de prueba fijas: prueba SROIE 2019 (361 recibos en inglés, campos planos empresa/dirección/fecha/total) y prueba CORD v2 (100 recibos en indonesio, campos anidados menú/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: un pase de calentamiento fijo precede al pase de puntuación, por lo que las cifras de latencia son en estado estable). Las tres ejecuciones 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 OCR Tradicional vs VLMs de 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ó con la tarifa bajo demanda de RunPod de $0.76/hr, con el precio registrado en el manifest 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úblicamente fijada (ver Limitaciones) — según la tabla de modelos del repositorio público (README.md) y los manifests de ejecución.
• Posprocesador LLM: deepseek-v4-flash vía API a temperatura 0 para salida determinística (la columna llm_model en field_method_comparison.csv); fue el único modelo utilizado para todas las filas de campos LLM en los tres motores.
• Base de costos: tiempo de ejecución real × $0.76/hr, incluyendo la inicialización del modelo — el procesamiento por lotes reduce el costo por página.
• Posprocesamiento 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 OCR por un conjunto fijo de patrones. Miden OCR + extracción posterior, no la salida estructurada nativa de ningún modelo; las columnas LLM_* miden texto OCR + extracción LLM. Las dos canalizaciones nunca se combinan.

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. Injusto para VLMs de análisis de documentos: penaliza la normalización de mayúsculas/minúsculas, la fusión de etiquetas/valores y la reordenación de líneas como errores, incluso cuando los valores de los campos son correctos. Se cita en esta página solo con sus advertencias.
• WER (tasa de error de palabras): el mismo cálculo de distancia de edición a nivel de palabra. Donde CER y WER divergen fuertemente (Unlimited-OCR: 0.6552 vs 0.4779), la brecha marca dónde la normalización de la salida, y no la mala lectura, está causando el daño.
• F1 de valor de campo (regex): media armónica de precisión/recall sobre valores de campos extraídos usando patrones regex fijos en el texto OCR (pipeline de OCR tradicional + 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 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.
• Campos de documento exactos: fracción de documentos donde todos los campos objetivo coincidieron exactamente — un umbral mucho más estricto que el F1 por campo.
• Latencia p50/p95 y páginas/min: tiempo de inferencia por página en estado estable (calentado y luego medido, excluye carga 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.

Lista de Fuentes

1. summary_metrics.csv (GitHub raw). 16 filas = 8 modelos × 2 conjuntos de datos. Columnas: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Cada número de CER/WER, latencia, costo y rendimiento en esta página se remonta a las filas de surya2, unlimited_ocr y paddleocr_vl_vllm aquí.
2. field_method_comparison.csv (GitHub raw). 16 filas; columnas model, dataset, llm_model (= deepseek-v4-flash), precisión y F1 de campos regex/llm, document-fields-exact, llm_median_latency_ms, conteo de tokens. Cada número de F1 de campos regex/LLM se remonta a las tres filas de motores nombrados aquí.
3. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que alberga los CSV de resultados, manifiestos de ejecución redactados, protocolo congelado y listas de muestras de conjuntos de datos (divisiones de prueba fijas) para reproducción.
4. results/manifests/ (GitHub). Un manifest.json redactado por cada ejecución publicada (16 ejecuciones) con versiones de modelo, GPU/driver, versiones de torch/CUDA/Python, metadatos de costos 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 de la CER hacia los VLM es la razón por la que esta página se basa en métricas de campo: los VLM de análisis de documentos fusionan mayúsculas y minúsculas, combinan líneas de etiqueta/valor y reordenan el texto, por lo que las puntuaciones CER crudas contabilizan convenciones de salida como errores — la divergencia de Unlimited-OCR (CER 0.6552 vs WER 0.4779) y la inversión de CORD de PaddleOCR-VL (peor CER 1.0805, mejor F1 de campo 0.3412) son artefactos de ese impuesto. Cualquier clasificación que ordene 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 análisis de documentos afirman sus mayores ventajas; las fortalezas comercializadas de los tres motores (incluido el análisis de más de 40 páginas en un solo pase de Unlimited-OCR) están sin medir. No use esta página para concluir “VLM X gana en todo.”
• Tamaño de la muestra: 361 recibos en inglés + 100 en indonesio. La F1 de campo y la CER son sensibles al corpus; las diferencias de un solo dígito de unos pocos centésimos (incluida la variación de 0.022 puntos de la F1-LLM) deben tratarse como ruido, no como verdad de ingeniería.
• Tier de GPU y precio únicos: todos los números provienen de una RTX 4090 a $0.76/hr, con marca de tiempo de precio de agosto de 2026 en los manifiestos de ejecución. Otras GPUs, servicio multi-GPU, programación por lotes o cambios de precio cambiarán la latencia, el rendimiento y el costo — recalcule los costos a las tarifas actuales antes de presupuestar.
• Postprocesador LLM único: todas las filas de LLM usan deepseek-v4-flash a temperatura 0. Un LLM diferente cambia la F1 de campo absoluta; el orden de convergencia puede moverse en los márgenes. La latencia del LLM (~1.9–2.3 s mediana, field_method_comparison.csv llm_median_latency_ms) es incurrida por la API y no es parte de la latencia de ningún motor.
• Cuarentena de CORD: la verdad de referencia de CORD incrusta la estructura de anotación y los patrones regex fueron escritos para formatos en inglés; la CER de CORD (0.90–1.08 en todos los motores) refleja la discordancia de idioma + la inflación de la verdad de referencia, no la calidad por modelo. Las filas de CORD se citan con encuadre y nunca se fusionan en ninguna clasificación de SROIE (regla de protocolo).
• Fijación de versión: 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 puede rastrearse a una versión exacta; versiones más nuevas de cualquier motor pueden cambiar cada número en esta página.
• Ajuste de regex: el conjunto de patrones se escribió una vez por conjunto de datos. Una biblioteca de patrones ajustada por formato podría obtener una puntuación más alta en sus propios diseños — a costa del mantenimiento que el LLM elimina.

Referencias relacionadas: Benchmark de Recibos docTR vs Surya2 · OCR Tradicional vs VLM de Análisis de Documentos · Regex vs Extracción de Campos con LLM · Precisión a Nivel de Campo vs a Nivel de Carácter · Precisión de OCR de Recibos

Lectura relacionada: Precisión de OCR con IA vs OCR Tradicional · Extracción de Datos de Imágenes con IA vs OCR Tradicional · Precios de Extracción de Documentos con IA (2026)