AesCode Infographics Content : ce que la métrique évalue, son fonctionnement et les limites à la comparaison directe

Introduction : le rôle de la métrique Content dans AesCode

Générer des infographies sous forme de code pose un double défi : préserver l’exactitude des informations tout en produisant un résultat visuellement convaincant. Le cadre AesCode, développé par Microsoft et ses collaborateurs, traite ces objectifs séparément en distinguant la vérification des éléments vérifiables de l’évaluation visuelle. La dimension « Content » est l’un des composants de la note « Visual » dans le benchmark d’infographies évalué sur 300 exemples.

Contrairement à « Chart » et « Bound », qui contribuent à la note « Rule » à l’aide de vérifications programmatiques, « Content » relève de l’évaluation visuelle. Il ne s’agit pas de vérifier si une valeur apparaît dans le code, mais de déterminer si les éléments demandés sont présents et suffisamment complets dans le rendu final. Cette distinction aide à comprendre pourquoi les scores AesCode ne se transposent pas directement à d’autres benchmarks de génération de code ou d’images.

La distinction entre contenu et exactitude répond à deux questions différentes. Content porte sur la présence des composants attendus et sur leur degré de complétude dans l’image obtenue ; elle ne suffit donc pas à établir que les valeurs représentées sont justes. Une infographie peut inclure les éléments demandés sans que cette dimension, à elle seule, confirme l’exactitude de chaque donnée. Pour interpréter le résultat, il faut garder à l’esprit que la note visuelle et les contrôles programmatiques décrivent des aspects complémentaires.

Le caractère visuel de cette évaluation compte également : un élément peut figurer dans le code sans être suffisamment visible ou complet dans le rendu. C’est précisément pourquoi la simple recherche d’une valeur dans le code ne répond pas à la question posée par Content. La dimension s’intéresse à ce que montre effectivement l’infographie, et sa portée reste limitée aux critères de présence et de complétude décrits pour le benchmark.

Structure de la suite : comment les métriques s’articulent

Le benchmark AesCode distingue deux grandes familles d’évaluation : « Rule » et « Visual ». La note Rule est la moyenne des contrôles programmatiques Text, Bound et Chart. Ces vérifications s’appuient sur le code HTML/CSS, le DOM, le rendu et les données structurées des tableaux et des graphiques ECharts, selon le contrôle concerné.

La note Visual est la moyenne de trois dimensions évaluées à l’aide d’une checklist visuelle : Content, Layout et Style. Content porte sur la présence et le caractère complet des éléments demandés. Layout examine l’organisation, les relations entre éléments et les chevauchements. Style concerne la hiérarchie visuelle, la typographie, les couleurs et la finition. Enfin, Overall correspond à la moyenne de Rule et Visual. Cette structure permet de distinguer la conformité vérifiable de la qualité visuelle, sans les confondre dans une seule dimension.

La séparation entre les deux familles donne une lecture plus nuancée qu’une note unique. Les contrôles Rule portent sur des propriétés vérifiables à partir du code, du rendu et des données structurées, tandis que les dimensions Visual demandent d’examiner l’infographie comme une représentation. Une différence entre les deux résultats n’est donc pas nécessairement contradictoire : elle peut signaler que la conformité programmatiquement vérifiable et la qualité observée dans l’image ne coïncident pas entièrement.

Les dimensions visuelles remplissent, elles aussi, des rôles distincts. Content concerne les éléments requis et leur complétude ; Layout porte sur la manière dont ils sont organisés et sur leurs relations spatiales, y compris les chevauchements ; Style concerne leur hiérarchie et leur traitement visuel. Les lire séparément aide à repérer quel aspect est évalué, sans supposer qu’une dimension résume à elle seule toutes les qualités de l’infographie.

Les moyennes indiquées décrivent l’organisation du benchmark, mais elles ne rendent pas interchangeables les contrôles qui les composent. Rule rassemble Text, Bound et Chart ; Visual rassemble Content, Layout et Style ; Overall combine ensuite les deux notes de famille. Ainsi, une note agrégée donne une vue d’ensemble, tandis que les résultats détaillés restent nécessaires pour comprendre ce que cette moyenne recouvre et ce qu’elle ne permet pas de conclure.

Méthode et exécution de la dimension Content

La dimension Content ne repose pas uniquement sur des règles de syntaxe fixes : elle appartient à une évaluation visuelle fondée sur des questions de checklist. Dans le dispositif décrit pour l’entraînement, un Visual Graph Rubric propre à chaque exemple contient des questions oui/non liées aux nœuds, aux attributs et aux relations d’un graphe de conception. Le dépôt indique que ces questions sont évaluées à partir du rendu candidat.

Il faut toutefois distinguer le mécanisme de récompense utilisé pendant l’entraînement de la méthode de notation finale du benchmark. Dans le protocole d’évaluation publié, Content, Layout et Style sont les dimensions de la checklist visuelle, et un modèle de vision-langage répond à des questions fixes à partir du rendu candidat. Les éléments disponibles ne justifient pas de traiter automatiquement les détails du Visual Graph Rubric d’entraînement comme une description complète du protocole d’évaluation final, ni d’affirmer une formule précise pour Content au-delà de ce qui est documenté.

Les questions de checklist rendent l’évaluation liée aux exigences de chaque exemple plutôt qu’à une règle de syntaxe identique appliquée mécaniquement à tous les rendus. Dans le dispositif d’entraînement décrit, les exigences sont rapportées à un graphe de conception et aux relations entre ses éléments. Cela explique le lien entre la checklist et la structure attendue, mais ne permet pas de supposer que chaque détail du mécanisme d’entraînement constitue, sans distinction, le protocole de notation finale.

Pour l’évaluation finale, la description disponible situe Content parmi les dimensions de la checklist visuelle et indique que le rendu candidat est examiné par un modèle de vision-langage à partir de questions fixes. Il convient de s’en tenir à cette description : les informations disponibles ne précisent pas une formule indépendante et complète d’agrégation des réponses propre à Content. En particulier, elles ne suffisent pas à affirmer que sa note finale est nécessairement une simple proportion de réponses positives, ni à reconstruire un protocole reproductible au-delà des étapes documentées.

La prudence est importante lorsqu’on décrit la production des questions. Une checklist peut être liée au prompt et aux éléments attendus, tandis que le mécanisme précis qui la construit, la sélection des questions et leur éventuelle pondération ne sont pas tous établis ici pour la notation finale. Distinguer ces niveaux évite de transformer une description du dispositif d’entraînement en affirmation non vérifiée sur le calcul de la note publiée.

Le rendu constitue le point d’observation de l’évaluation visuelle : les questions portent sur ce qui apparaît dans l’infographie générée, et non uniquement sur la présence de chaînes dans le code. Le parcours général peut donc être résumé sans ajouter de détail non documenté : les exigences sont prises en compte, le code produit un rendu, puis celui-ci est évalué dans les dimensions visuelles prévues. Les modalités exactes de génération et de combinaison des questions doivent rester ouvertes lorsque la documentation ne les fixe pas.

Limites et comparabilité avec d’autres benchmarks

Une comparaison directe avec d’autres benchmarks exige de connaître précisément leurs critères, leurs prompts, leurs modèles évaluateurs, leurs paramètres d’inférence et leur méthode d’agrégation. Une dimension de checklist visuelle évaluée par un VLM ne mesure pas nécessairement la même chose qu’un score calculé par règles, une similarité pixel à pixel ou une autre évaluation par modèle. Il ne suffit donc pas de mettre des scores portant des noms proches sur une même échelle pour les rendre comparables.

Content doit aussi être interprété à côté des autres dimensions. Dans AesCode, les contrôles de données de graphiques et de tableaux, ainsi que les vérifications de texte et de limites du canevas, appartiennent à la famille Rule. Une note Content élevée ne démontre donc pas, à elle seule, que toutes les valeurs numériques sont exactes. Inversement, une bonne conformité aux contrôles programmatiques ne garantit pas une présentation visuellement satisfaisante. Les résultats doivent être lus dans le contexte de la suite complète et du protocole publié.

La comparabilité dépend autant de la définition de la mesure que du nom qui lui est donné. Deux scores appelés « contenu » peuvent porter sur des critères différents, utiliser des consignes distinctes ou être agrégés selon des règles différentes. Avant de rapprocher des résultats, il faut donc vérifier ce que chaque protocole demande à l’évaluateur d’observer et comment il transforme ces observations en note. Sans cet examen, une proximité numérique ne garantit pas que les résultats décrivent la même propriété.

Cette réserve s’applique aussi à la relation entre évaluation visuelle et appréciation humaine. Les éléments disponibles rapportent une cohérence avec le jugement humain, mais ne permettent pas d’établir ici une validation indépendante de cette relation. Il est donc préférable de ne pas traiter cette indication comme une garantie générale de validité, ni de l’étendre à d’autres modèles, critères ou conditions d’évaluation.

Pour interpréter Content au sein d’AesCode, il faut également conserver la distinction avec les contrôles Rule. La présence et la complétude des éléments dans le rendu ne démontrent pas l’exactitude des données numériques ; à l’inverse, un résultat favorable aux vérifications programmatiques ne suffit pas à établir que l’organisation et la présentation sont satisfaisantes. Les deux familles doivent être considérées ensemble, sans attribuer à l’une les conclusions qui relèvent de l’autre.

Conclusion et recommandations pour les équipes ML

Content apporte une information utile sur la présence et le caractère complet des éléments requis dans le rendu d’une infographie. Son intérêt vient de sa place dans une évaluation à plusieurs dimensions : elle complète les contrôles programmatiques et les évaluations de l’organisation et du style, sans prétendre les remplacer.

Pour exploiter cette métrique, les équipes devraient consulter le protocole et le code officiels, conserver les mêmes conditions d’exécution et rapporter séparément Rule, Content, Layout, Style, Visual et Overall lorsque ces résultats sont disponibles. Les comparaisons avec d’autres benchmarks devraient rester explicitement conditionnelles tant que les critères de notation, les évaluateurs et les données ne sont pas alignés. Enfin, les scores publiés ne constituent pas, à eux seuls, une validation indépendante de la méthode.

Dans la pratique, rapporter les dimensions séparément permet de rendre les résultats plus lisibles. Content renseigne sur la présence et la complétude visuelles ; Rule résume des contrôles programmatiques ; Layout et Style décrivent d’autres aspects de la représentation. Visual et Overall offrent des regroupements plus larges, mais ne remplacent pas le détail lorsque l’objectif est de comprendre les forces et les limites d’un résultat particulier.

Les conditions d’exécution et le protocole utilisé doivent accompagner toute interprétation. Une variation des critères, des évaluateurs ou de la manière de produire les résultats peut modifier ce que signifie une note, même si le nom de la dimension reste le même. Conserver des conditions cohérentes facilite les comparaisons au sein de la suite, mais ne suffit pas à rendre automatiquement comparables des scores issus de benchmarks différents.

Les valeurs de l’exemple doivent être lues comme des résultats propres à deux dimensions distinctes, et non comme une preuve exhaustive de qualité. Une note Rule ne démontre pas à elle seule que toutes les données sont exactes dans le sens voulu, et une note Content ne certifie pas que tous les éléments sont correctement représentés sur tous les plans. Les résultats de Layout, Style, Visual et Overall, ainsi que le protocole de notation, restent nécessaires pour situer ces chiffres sans leur faire dire davantage que ce qu’ils mesurent.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.