Datalab lanza OmniParseBench, un benchmark abierto para el análisis de documentos

Datalab ha publicado OmniParseBench, un benchmark abierto para OCR y análisis de documentos que, según la empresa, está diseñado en torno a 16.288 pruebas. Según la página del proyecto en PyPI y la entrada de blog de Datalab, el benchmark evalúa páginas individuales mediante comprobaciones binarias en lugar de usar distancia de edición frente a una única salida de referencia. En la práctica, cada prueba pregunta si un elemento determinado está presente en la salida de un proveedor, en el orden correcto, en una celda concreta de una tabla o dentro de un bloque de maquetación de un tipo específico. Datalab presenta este enfoque como una forma de centrarse en si los sistemas extrajeron el contenido correcto, y no en si reprodujeron un único estilo de salida preferido.

Un benchmark construido como pruebas unitarias

El protocolo descrito en PyPI se centra en afirmaciones de sí o no a nivel de página. Una prueba puede verificar uno o varios argumentos, cada uno correspondiente a contenido situado en un lugar de la página. El benchmark agrupa los resultados en tres familias: texto, tablas y maquetación. La puntuación principal es la media de esas tres familias.

Este diseño importa porque, según Datalab, los benchmarks anteriores se han vuelto más fáciles de optimizar mediante ajustes de formato o posprocesado específico para el propio benchmark. En su entrada de blog, la empresa sostiene que alternativas muy utilizadas pueden recompensar más el cumplimiento de convenciones de salida esperadas que la calidad subyacente del modelo. Esas críticas son afirmaciones de Datalab, no conclusiones independientes presentes en las fuentes facilitadas, pero explican por qué la empresa dice haber construido OmniParseBench y por qué prevé utilizarlo para informar sobre sus propios lanzamientos.

En cuanto a la cobertura, PyPI indica que cada prueba está etiquetada en varias dimensiones. Entre ellas figuran etiquetas de estructura como table, math, form y multi_column; etiquetas de renderizado como handwriting, tiny, rotated y degraded; etiquetas de función como heading, caption, footnote, list, code, figure y header_footer; etiquetas de escritura basadas en ISO 15924; y etiquetas de idioma basadas en ISO 639-3. Las etiquetas no determinan si una prueba se supera o no. Más bien, permiten a los usuarios segmentar el benchmark y puntuar subconjuntos de los datos. Como una misma prueba puede llevar varias etiquetas, las puntuaciones por etiqueta se solapan y no vuelven a promediarse hasta el valor principal.

Cómo funcionan la puntuación y las ejecuciones

El benchmark puede ejecutarse sobre el conjunto de datos de Datalab alojado en Hugging Face o sobre un conjunto de datos propio del usuario, según la descripción en PyPI. También expone primitivas de puntuación y predicción de nivel más bajo para que los equipos puedan integrarlo en sus propios flujos de evaluación. Una ejecución se puede reanudar, y cada configuración de proveedor se trata como una ejecución independiente. El proyecto indica que cada ejecución escribe un archivo scores.jsonl con una línea por prueba, mientras que los resultados resumidos pueden leerse en summary.json.

La puntuación no reduce todos los resultados a aprobado o suspenso. PyPI enumera cuatro veredictos:

• pass
• fail
• unsupported, cuando un proveedor no puede producir la salida solicitada
• error, cuando la propia evaluación plantea un problema en lugar de que falle el proveedor

Una decisión metodológica destacable es que los veredictos unsupported y error se excluyen de toda puntuación en lugar de contarse como fallos. PyPI afirma que esto pretende evitar penalizar a los proveedores por salidas que no pueden producir o por errores en el evaluador. Al mismo tiempo, eso significa que las comparaciones entre sistemas pueden depender en parte de qué tipos de salida admite cada proveedor. Un sistema que no puede emitir una determinada representación puede dejar esas pruebas fuera de su puntuación en lugar de recibir ceros en ellas.

El proyecto también afirma que los adaptadores de proveedores usan el mismo tiempo límite por llamada y, por defecto, la configuración de mayor precisión de cada proveedor. Las herramientas de Datalab pueden llamar a las API de los proveedores, pero piden confirmación antes de hacerlo porque esas llamadas tienen coste. El paquete requiere Python 3.11 o posterior y se distribuye bajo licencia Apache 2.0 para el código, mientras que los datos y las pruebas tienen licencias mixtas según su origen.

Qué es público y qué no

A partir de las fuentes facilitadas, la publicación pública incluye claramente código, documentación y un benchmark empaquetado en PyPI. PyPI también indica que el repositorio contiene una forma de ejecutar el benchmark usando el conjunto de datos de Datalab en Hugging Face o datos propios del usuario. La misma página remite a documentación sobre la API, el diseño del benchmark, la construcción de pruebas, los proveedores y el etiquetado. También indica que, si los usuarios detectan una prueba incorrecta, pueden abrir una incidencia, lo que sugiere que el benchmark está pensado para poder inspeccionarse y corregirse.

Sin embargo, las fuentes disponibles no aportan un desglose completo de las 16.288 pruebas por familia, idioma, escritura o tipo de documento. Tampoco incluyen resultados agregados de clasificación para el propio OmniParseBench. La cifra de 16.288 pruebas se recoge aquí, por tanto, como parte del planteamiento del benchmark, pero los textos facilitados no detallan el reparto exacto que hay detrás de ese total. Del mismo modo, en el material de origen no hay cifras globales de rendimiento que muestren qué proveedores lideran en texto, tablas o maquetación.

Resultados reivindicados en torno a otros benchmarks

En lugar de publicar resultados de clasificación de OmniParseBench en los materiales facilitados, el blog de Datalab se centra en explicar por qué considera insuficientes los benchmarks existentes. La empresa afirma que olmOCR está saturado y cita ejemplos en los que el posprocesado puede cambiar las puntuaciones publicadas en torno a uno o dos puntos. También sostiene que ParseBench puede verse fuertemente influido por la redacción de los prompts, las convenciones de formato y las canalizaciones especializadas, especialmente para gráficos y grounding visual. Se trata de acusaciones de fondo formuladas por Datalab, pero deben leerse como la versión de la empresa. En las fuentes proporcionadas no se incluye una validación independiente.

Aun así, esas afirmaciones ayudan a entender qué intenta optimizar OmniParseBench. Sus comprobaciones de sí o no se presentan explícitamente como más difíciles de manipular que los enfoques basados en comparación con una referencia. Datalab sostiene que esta estructura debería producir señales de error más claras, porque una prueba fallida corresponde a un error concreto en una página concreta. Eso podría facilitar a desarrolladores de modelos y compradores empresariales ver si un sistema tiene problemas, por ejemplo, con texto girado, formularios, escritura manuscrita o estructura tabular, en lugar de limitarse a ver una única puntuación combinada.

Límites visibles en la propia publicación

El propio diseño de OmniParseBench también genera límites. En primer lugar, las fuentes facilitadas no muestran resultados completos a nivel de benchmark, de modo que los lectores externos todavía no pueden evaluar si produce clasificaciones materialmente distintas de las alternativas anteriores. En segundo lugar, como las salidas no compatibles se omiten del cómputo, el benchmark puede premiar la calidad dentro del rango de salidas que admite un proveedor más que la amplitud de tipos de salida. En tercer lugar, los cortes por etiquetas se solapan por diseño, lo que resulta útil para el diagnóstico, pero puede hacer menos intuitiva la interpretación de los resúmenes.

También hay restricciones prácticas. Ejecutar pruebas con proveedores requiere claves de API y llamadas de pago. El benchmark puede reanudarse y compararse entre ejecuciones, pero la reproducibilidad aún puede variar con la configuración de los proveedores, porque cada configuración constituye una ejecución distinta. Por último, el conjunto de datos hereda licencias mixtas de sus fuentes, y Datalab señala que también deben citarse los conjuntos de datos ascendentes. Eso no reduce el valor del benchmark, pero sí implica que su adopción en flujos de evaluación de producción puede requerir una revisión jurídica y operativa.

Para las empresas españolas y, en general, para las organizaciones hispanohablantes, el cambio concreto es que OmniParseBench ofrece una forma más inspeccionable de probar sistemas de IA documental página por página, con segmentaciones para tablas, maquetación, escrituras y condiciones de renderizado difíciles en lugar de una única puntuación opaca. En la práctica, esto podría ayudar a los equipos a comparar proveedores o modelos internos según las características documentales que realmente les importan, pero también deberían comprobar qué salidas aparecen marcadas como unsupported, revisar las condiciones de licencia del benchmark y evitar tratar una sola puntuación principal como una medida completa de la calidad de comprensión documental.