Datalab publie OmniParseBench, un benchmark ouvert pour l’analyse de documents

Datalab a publié OmniParseBench, un benchmark ouvert pour l’OCR et l’analyse de documents que l’entreprise présente comme conçu autour de 16 288 tests. D’après la page du projet sur PyPI et l’article de blog de Datalab, le benchmark évalue des pages individuelles au moyen de vérifications binaires, plutôt qu’en mesurant une distance d’édition par rapport à une seule sortie de référence. Concrètement, chaque test vérifie si un élément donné est présent dans la sortie d’un fournisseur, s’il apparaît dans le bon ordre, dans une cellule précise d’un tableau, ou à l’intérieur d’un bloc de mise en page d’un certain type. Datalab présente cette approche comme un moyen de se concentrer sur la capacité des systèmes à extraire le bon contenu, et non sur leur conformité à un seul style de sortie jugé préférable.

Un benchmark conçu comme une batterie de tests unitaires

Le protocole décrit sur PyPI repose sur des assertions binaires, page par page. Un test peut vérifier un ou plusieurs arguments, chacun correspondant à un contenu situé à un endroit précis d’une page. Le benchmark regroupe les résultats en trois familles : texte, tableaux et mise en page. Le score principal affiché correspond à la moyenne de ces trois familles de scores.

Ce choix de conception est important car, selon Datalab, les benchmarks plus anciens sont devenus plus faciles à optimiser grâce à des ajustements de formatage ou à des post-traitements spécifiques au benchmark. Dans son billet de blog, l’entreprise soutient que certaines alternatives largement utilisées peuvent davantage récompenser le respect des conventions de sortie attendues que la qualité intrinsèque du modèle. Ces critiques relèvent des affirmations de Datalab et non de constats indépendants présents dans les sources fournies, mais elles éclairent la raison pour laquelle l’entreprise dit avoir construit OmniParseBench et pourquoi elle prévoit de l’utiliser pour ses propres publications de résultats.

Concernant la couverture, PyPI indique que chaque test est étiqueté selon plusieurs dimensions. Celles-ci incluent des tags de structure comme table, math, form et multi_column ; des tags de rendu comme handwriting, tiny, rotated et degraded ; des tags de rôle comme heading, caption, footnote, list, code, figure et header_footer ; des tags d’écriture fondés sur la norme ISO 15924 ; et des tags de langue fondés sur l’ISO 639-3. Ces tags ne déterminent pas à eux seuls si un test est réussi ou non. Ils servent plutôt à permettre aux utilisateurs de découper le benchmark en sous-ensembles et d’en calculer les scores. Comme un même test peut porter plusieurs tags, les scores par tag se recoupent et ne se recomposent pas mécaniquement pour retrouver le score principal.

Fonctionnement des scores et des exécutions

Le benchmark peut être exécuté sur le jeu de données de Datalab hébergé sur Hugging Face ou sur le propre jeu de données d’un utilisateur, selon la description PyPI. Il expose aussi des primitives de plus bas niveau pour le scoring et la prédiction, afin que les équipes puissent l’intégrer à leurs propres pipelines d’évaluation. Une exécution peut être reprise en cours, et chaque configuration de fournisseur est traitée comme une exécution distincte. Le projet indique en outre que chaque exécution écrit un fichier scores.jsonl avec une ligne par test, tandis que les résultats de synthèse peuvent être lus dans summary.json.

Le calcul des scores ne réduit pas tous les résultats à une simple réussite ou à un échec. PyPI énumère quatre verdicts :

• pass
• fail
• unsupported, lorsqu’un fournisseur ne peut pas produire la sortie demandée
• error, lorsque l’évaluation elle-même rencontre un problème au lieu d’un échec du fournisseur

Un choix méthodologique notable est que les verdicts unsupported et error sont exclus de tous les scores, au lieu d’être comptés comme des échecs. PyPI explique que l’objectif est d’éviter de pénaliser les fournisseurs pour des sorties qu’ils ne peuvent pas produire ou pour des bogues du système d’évaluation. En même temps, cela signifie que les comparaisons entre systèmes peuvent dépendre en partie des types de sortie qu’un fournisseur prend en charge. Un système incapable d’émettre une représentation donnée peut voir ces tests retirés de son score, au lieu d’obtenir des zéros sur ces cas.

Le projet précise également que les adaptateurs de fournisseurs utilisent le même délai d’expiration par appel et, par défaut, les réglages les plus précis de chaque fournisseur. Les outils de Datalab peuvent appeler les API des éditeurs, mais ils demandent une confirmation avant de le faire, car ces appels sont payants. Le package nécessite Python 3.11 ou une version ultérieure et est distribué sous licence Apache 2.0 pour le code, tandis que les données et les tests relèvent de licences mixtes selon leur source.

Ce qui est public, et ce qui ne l’est pas

D’après les sources fournies, la publication publique comprend clairement du code, de la documentation et un benchmark empaqueté sur PyPI. PyPI indique aussi que le dépôt contient un moyen d’exécuter le benchmark à l’aide du jeu de données de Datalab sur Hugging Face ou des propres données d’un utilisateur. La même page renvoie vers une documentation couvrant l’API, la conception du benchmark, la construction des tests, les fournisseurs et le système de tags. Elle précise également que si des utilisateurs repèrent un test erroné, ils peuvent ouvrir un ticket, ce qui laisse entendre que le benchmark a vocation à être inspectable et amendable.

En revanche, les sources disponibles ne fournissent pas de ventilation complète des 16 288 tests par famille, langue, écriture ou type de document. Elles ne contiennent pas non plus de résultats agrégés de classement pour OmniParseBench lui-même. Le chiffre de 16 288 tests est donc rapporté ici comme un élément du cadrage du benchmark, mais les textes fournis ne détaillent pas la répartition exacte derrière ce total. De même, aucun chiffre de performance à l’échelle du benchmark n’apparaît dans les sources pour montrer quels fournisseurs dominent sur le texte, les tableaux ou la mise en page.

Des résultats revendiqués autour d’autres benchmarks

Au lieu de publier, dans les documents fournis, des résultats de classement d’OmniParseBench, le blog de Datalab met l’accent sur les raisons pour lesquelles l’entreprise estime les benchmarks existants insuffisants. La société affirme que olmOCR est saturé et cite des exemples où un post-traitement peut modifier les scores rapportés d’environ un ou deux points. Elle soutient aussi que ParseBench peut être fortement influencé par la formulation du prompt, les conventions de formatage et des pipelines spécialisés, en particulier pour les graphiques et l’ancrage visuel. Il s’agit d’allégations substantielles formulées par Datalab, mais elles doivent être lues comme le récit de l’entreprise. Aucune validation indépendante n’est incluse dans les sources fournies.

Ces affirmations éclairent néanmoins ce qu’OmniParseBench cherche à optimiser. Les vérifications binaires du benchmark sont explicitement présentées comme plus difficiles à contourner que les approches fondées sur la comparaison à une sortie de référence. Datalab soutient que cette structure devrait produire des signaux d’erreur plus clairs, parce qu’un test échoué correspond à une erreur précise sur une page précise. Cela pourrait faciliter, pour les développeurs de modèles comme pour les acheteurs en entreprise, l’identification des difficultés d’un système face, par exemple, au texte pivoté, aux formulaires, à l’écriture manuscrite ou à la structure des tableaux, au lieu de ne voir qu’un seul score agrégé.

Des limites visibles dans la publication elle-même

La conception même d’OmniParseBench crée aussi des limites. Premièrement, les sources fournies ne montrent pas de résultats complets à l’échelle du benchmark, de sorte que les observateurs extérieurs ne peuvent pas encore évaluer si le benchmark produit des classements sensiblement différents de ceux des alternatives plus anciennes. Deuxièmement, puisque les sorties unsupported sont omises du calcul des scores, le benchmark peut récompenser la qualité à l’intérieur du périmètre de sortie pris en charge par un fournisseur plutôt que l’étendue des types de sortie disponibles. Troisièmement, les découpages par tags se recoupent par conception, ce qui est utile pour le diagnostic, mais peut rendre l’interprétation des synthèses moins intuitive.

Il existe aussi des contraintes pratiques. L’exécution sur des fournisseurs nécessite des clés d’API et des appels payants. Le benchmark peut être repris et comparé entre plusieurs exécutions, mais la reproductibilité peut tout de même varier selon les réglages des fournisseurs, puisque chaque réglage constitue sa propre exécution. Enfin, le jeu de données hérite de licences sources mixtes, et Datalab précise que les jeux de données amont doivent eux aussi être cités. Cela ne diminue pas la valeur du benchmark, mais signifie que son adoption dans des workflows d’évaluation en production peut nécessiter un examen juridique et opérationnel.

Pour les entreprises françaises et, plus largement, les organisations francophones, le changement concret est qu’OmniParseBench propose une manière plus inspectable de tester des systèmes d’IA documentaire page par page, avec des découpages portant sur les tableaux, la mise en page, les écritures et les conditions de rendu difficiles, plutôt qu’un seul score opaque. En pratique, cela pourrait aider les équipes à comparer des fournisseurs ou des modèles internes sur les caractéristiques documentaires qui comptent réellement pour elles, mais elles ont aussi intérêt à vérifier quelles sorties sont marquées unsupported, à examiner les conditions de licence du benchmark et à éviter de considérer un unique score principal comme une mesure complète de la qualité de compréhension des documents.