Datalab lance OmniExtractBench pour corriger les biais et le manque de transparence des benchmarks d'extraction
Datalab a publié OmniExtractBench, un benchmark ouvert dédié à l'extraction structurée de documents : on fournit à un système un PDF et un schéma JSON, et l'on mesure la fidélité avec laquelle il remplit ce schéma. Le jeu de test regroupe 620 documents issus de quatre benchmarks existants : 329 viennent d'ExtractBench (LlamaIndex), 202 d'une suite synthétique interne de Datalab, 47 de LongExtractBench (micro1, commandé par Reducto) et 42 de LongArray-Extract (Extend). Les formulaires réglementaires forment la plus grande catégorie, avec 88 documents ; 128 documents tiennent sur une page, tandis que 33 documents de plus de 100 pages concentrent 40 % de toutes les pages. Un unique scorer déterministe note l'ensemble et justifie chaque décision. Il s'installe depuis PyPI sous le nom omni-extract-bench (version 0.1.7, Python 3.11 ou supérieur, SciPy comme seule dépendance) sous licence Apache 2.0, le code est sur GitHub et les données sur Hugging Face sous CC BY 4.0. Relancer les évaluations des éditeurs suppose toutefois d'utiliser ses propres clés d'API et des crédits payants.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de MarkTechPost. Lire l'article original →
Le scorer aplatit les JSON de prédiction et de référence en adresses, c'est-à-dire des chemins vers des valeurs isolées, puis normalise chaque valeur, de sorte que « 03/31/2024 » équivaut à « 2024-03-31 ». Les tableaux, point délicat, sont appariés par contenu grâce à l'algorithme hongrois plutôt que par position. Lors d'un test sur un tableau de 100 lignes privé de sa première ligne, la comparaison positionnelle donne 0 %, contre 99 % pour OmniExtractBench. Chaque valeur reçoit l'un de six verdicts : matched (appariée et identique), misread (appariée mais différente), unfound (présente dans la référence, absente de la prédiction), fabricated (champ autorisé mais vide dans la référence, rempli par le système), inventeditem (ligne prédite sans correspondance) et inventedfield (adresse non déclarée dans le schéma). L'exactitude rapporte les valeurs correctes à l'ensemble des verdicts, la précision aux valeurs prédites, le rappel aux valeurs de référence. Les chaînes vides, None et espaces sont traitées comme des omissions, ce qui empêche de gonfler artificiellement son score en remplissant le schéma de champs optionnels vides : dans le test de Datalab, ils n'ajoutent aucun verdict.
L'enjeu est la comparabilité. Datalab dénonce quatre travers récurrents : des documents ou un scoring qui avantagent l'éditeur auteur du benchmark, des protocoles opaques où un mauvais score peut venir d'un banc de test défaillant plutôt que du modèle, une notation inexplicable et une variété documentaire étroite, certaines suites ne contenant que des tableaux denses, d'autres que des fichiers propres. En distinguant les valeurs manquées, mal lues ou inventées, le benchmark permet de savoir quels systèmes omettent des champs et lesquels fabriquent des valeurs, un critère décisif pour les entreprises qui automatisent le traitement de factures, de dépôts réglementaires ou de contrats.
Cette publication intervient alors que les fournisseurs d'extraction publient chacun leur propre classement, difficilement comparables ou auditables. Plusieurs de ces suites sont d'ailleurs reprises ici : ExtractBench et LongArray-Extract alignaient déjà les lignes par l'algorithme hongrois, alors que LongExtractBench s'appuie sur une clé de ligne. Il faut toutefois noter que Datalab est lui-même un acteur du marché et que sa suite synthétique représente la deuxième part du corpus, ce qui rend l'indépendance du résultat dépendante de la transparence du scorer, publié en open source. La suite dépendra de l'adoption par les autres éditeurs.
Pas d'impact direct sur la France/UE