AesCode Infographics Rule : la métrique déterministe et son rôle dans l'évaluation du code esthétique
Image générée par l’équipe éditoriale d’Inferama
01

Définition de la métrique Rule et sa fonction dans la suite AesCode Infographics

La métrique Rule dans le benchmark AesCode Infographics est définie comme la moyenne de trois vérifications déterministes : Text, Bound et Chart. Ces contrôles évaluent des aspects structurels et sémantiques du code généré qui peuvent être extraits de manière programmatique depuis le code source, le DOM ou le rendu dans le navigateur.

Contrairement aux métriques visuelles, qui reposent sur un juge VLM (Vision-Language Model) pour évaluer des propriétés non analysables telles que la hiérarchie ou le style, Rule se concentre sur la justesse vérifiable. Son rôle est de garantir que le code respecte les exigences exactes de contenu, de contenance dans la toile et de structure des données, fournissant une base objective avant d'évaluer la qualité esthétique.

La moyenne de Text, Bound et Chart regroupe en une seule valeur des vérifications distinctes, et non trois versions d'une même épreuve. Text examine la présence des chaînes de caractères exigées ; Bound évalue si le contenu reste à l'intérieur du canevas et respecte le rapport d'aspect prévu ; Chart contrôle si les tableaux ou les graphiques présentent la structure et les données attendues. L'interprétation de Rule nécessite donc de se souvenir de la nature de l'exigence observée par chaque composant, plutôt que de traiter la valeur agrégée comme une description exhaustive du résultat final.

La distinction entre les vérifications programmatiques et le jugement visuel répond à la nature de la preuve disponible. Une chaîne attendue peut être recherchée dans le texte rendu, et certaines limites ou données peuvent être confrontées à des informations géométriques ou structurées. En revanche, décider si la hiérarchie d'une infographie est claire ou si son style est cohérent ne se réduit pas à vérifier une condition exacte du code. Rule fournit ainsi une base limitée de correction vérifiable ; elle ne transforme pas automatiquement ces exigences en une mesure de la valeur globale du design.

Le fait que les trois composants soient moyennés facilite la disposition d'une métrique résumée, mais n'élimine pas la nécessité de les distinguer lors de l'analyse d'un résultat. Un score agrégé peut masquer le fait que les vérifications de texte, de limites et de graphiques ne se comportent pas nécessairement de la même manière face à une même sortie. La valeur doit être lue conjointement avec la définition de ses composants et avec la portée de chaque vérification : elle décrit le respect de ces conditions concrètes, et non toute propriété qui pourrait être importante pour évaluer une infographie.

Composants de la métrique Rule

Détail des trois sous-métriques composant le score Rule.

ComposantDescriptionSource de vérification
TextVérifie la présence exacte des chaînes de texte requises.OCR et analyse du texte dans le rendu.
BoundMesure la contenance dans la toile et la concordance du ratio d'aspect.Géométrie des pixels et styles calculés.
ChartVérifie la structure, le sous-type et les données des tableaux et graphiques (ECharts).Analyse du HTML et des données structurées.
02

Méthodologie d'exécution : application des règles de vérification

Le harness d'évaluation d'AesCode nécessite un rendu dans un navigateur (Chromium via Playwright) et l'utilisation de PaddleOCR pour extraire le texte. Chaque score est calculé à partir de ce rendu, et non uniquement du code source, ce qui assure que la métrique reflète le résultat visuel final.

Le processus implique de comparer le graphe de conception cible (dérivé du prompt et de l'image de référence) avec le graphe candidat généré par le modèle. Les propriétés ayant une preuve structurée dans le code ou mesurable dans le rendu sont attribuées aux vérificateurs déterministes. Si un canal comme PaddleOCR échoue ou est absent, le canal retourne zéro au lieu de s'abstenir, ce qui peut corrompre la récompense s'il n'est pas géré correctement.

Le rendu est une étape centrale car l'objet de la vérification n'est pas uniquement le texte HTML/CSS produit, mais le résultat que ce code parvient à afficher dans le navigateur. L'extraction ultérieure permet de confronter la sortie visible au contenu requis et de mesurer les aspects du canevas. Par conséquent, le score dépend du fait que le processus de rendu et les outils de lecture fournissent les preuves attendues par les vérificateurs ; examiner uniquement le code source ne reproduit pas entièrement la procédure décrite.

Le graphe cible et le graphe candidat remplissent des fonctions différentes dans la comparaison : le premier exprime ce qui doit être vérifié à partir du prompt et de l'image de référence, tandis que le second représente le résultat généré par le modèle. Les règles déterministes s'appliquent aux propriétés pour lesquelles un signal structuré ou mesurable existe. Cette affectation délimite la portée de Rule : toute différence entre les deux graphes ne devient pas automatiquement une vérification, en particulier lorsqu'il s'agit de qualités visuelles qui ne sont pas représentées par les exigences observables de Text, Bound ou Chart.

Le traitement d'un échec de PaddleOCR comme un score zéro fait que la disponibilité du canal fait partie de l'interprétation du résultat. Si un problème d'extraction n'est pas séparé d'une absence réelle du texte, la valeur renvoyée peut refléter la défaillance de l'outil en plus du respect du modèle. La même prudence s'applique à l'exécution du navigateur et aux autres étapes du harnais : une valeur reproductible suppose que l'évaluation a été complétée avec les outils nécessaires, et ne doit pas être lue sans prendre en compte cette condition.

L'ordre des opérations aide à comprendre pourquoi la métrique se réfère à un rendu spécifique : d'abord, une sortie est obtenue dans Chromium ; ensuite, le texte et la géométrie sont extraits ; puis les vérificateurs de contenu, de limites et de données sont appliqués ; enfin, leurs scores sont moyennés. Si la preuve disponible change à l'une de ces étapes, la valeur calculée peut changer. La description du flux n'autorise pas à attribuer à Rule une évaluation directe de toute l'image, mais uniquement des propriétés que les étapes indiquées parviennent à vérifier.

Flux de vérification déterministe

Étapes techniques pour calculer la métrique Rule dans le harness.

  1. 01Rendre le code HTML/CSS généré dans un navigateur headless (Chromium).
  2. 02Extraire le texte et la géométrie des pixels du rendu.
  3. 03Exécuter le vérificateur Text pour contrôler les chaînes exactes.
  4. 04Exécuter le vérificateur Bound pour valider les limites de la toile.
  5. 05Exécuter le vérificateur Chart/Table pour valider les données structurées.
  6. 06Calculer la moyenne des trois scores pour obtenir Rule.
03

Comparaison avec les métriques visuelles : stabilité et reproductibilité

Dans le benchmark de 300 instances d'infographies, les scores basés sur les règles (Rule) sont systématiquement plus élevés et plus stables que les scores visuels pour les modèles de code fermés évalués. Cette stabilité découle de la nature déterministe des vérifications : elles ne dépendent pas de la subjectivité d'un modèle de langage visuel.

Cependant, cette stabilité n'implique pas une supériorité absolue dans l'évaluation de la qualité. Alors que Rule mesure la justesse structurelle, les métriques visuelles (Content, Layout, Style) capturent la perception humaine du design. Les modèles faibles montrent une chute plus prononcée dans les métriques visuelles que dans la conformité aux règles, suggérant que Rule peut être moins sensible aux défauts esthétiques subtils.

La stabilité mentionnée correspond au benchmark décrit et aux modèles de code fermé évalués sur leurs 300 instances ; elle n'établit pas une propriété universelle de Rule pour toute collection de cas ou configuration. Dans ce cadre, les vérifications déterministes tendent à produire des scores plus élevés et plus stables que les visuels. La différence s'explique par le fait que les deux canaux observent des choses distinctes : l'un vérifie des exigences délimitées, tandis que l'autre juge des dimensions du design qui ne sont pas capturées par ces règles.

La divergence entre les scores ne signifie pas que l'un d'eux invalide l'autre. Une sortie peut se conformer aux chaînes et aux limites exigées et, néanmoins, offrir une hiérarchie visuelle pauvre ou des couleurs inappropriées. Dans ce cas, Rule fournit une preuve favorable uniquement sur les aspects vérifiés, tandis qu'un score visuel bas signale des problèmes dans les dimensions évaluées par ce canal. La lecture conjointe permet de localiser le type d'écart sans transformer la conformité structurelle en une évaluation esthétique.

La chute plus marquée des modèles faibles dans les métriques visuelles que dans la conformité aux règles suggère une sensibilité différente entre les canaux, et non une équivalence entre les scores. Rule peut passer à côté des défauts esthétiques subtils précisément parce que ses vérifications sont orientées vers le contenu, la contenance et la structure des données. Par conséquent, une différence entre Rule et Visual est informative sur la portée de chaque métrique, mais ne permet pas à elle seule d'inférer qu'un modèle est compétent de manière générale ni de fixer un seuil de compétence que le benchmark ne fournit pas.

04

Limites de la métrique Rule pour évaluer la qualité esthétique réelle

La métrique Rule présente des limites inhérentes pour évaluer la qualité esthétique réelle. Elle ne capture pas des propriétés telles que la typographie, l'utilisation des couleurs, la hiérarchie visuelle ou la cohésion du design, qui sont essentielles à la perception du « bon design ». Ces aspects sont évalués via le canal Visual, qui utilise une grille spécifique à l'échantillon (VGR) et un juge VLM.

De plus, la comparabilité entre modèles peut être affectée si la métrique Rule ne capture pas la perception humaine du design. Un modèle peut avoir une Rule élevée mais une Visual basse, indiquant que le code est structurellement correct mais esthétiquement déficient. Par conséquent, Rule doit être interprétée comme une métrique de justesse, et non de qualité esthétique.

La limite de Rule n'est pas un défaut accidentel que l'on corrige en interprétant la valeur avec plus de confiance : elle découle du fait que ses tests se concentrent sur des conditions vérifiables, tandis que la typographie, la couleur, la hiérarchie et la cohésion appartiennent à des dimensions que la métrique ne capture pas. Une sortie peut satisfaire ce qui est vérifié et rester peu attrayante ou peu cohérente. Pour cette raison, le score exprime la conformité structurelle dans le cadre défini, et non une approbation générale du design.

Le canal Visual complète Rule en abordant des propriétés qui ne se résolvent pas par les vérifications déterministes et en utilisant une grille spécifique à l'échantillon ainsi qu'un juge VLM. Cette complémentarité ne signifie pas que les métriques sont interchangeables ni qu'un score visuel doit corriger ou remplacer le score Rule. Chaque résultat répond à une question différente : si certaines conditions structurelles et de contenu sont respectées, d'une part, et comment les dimensions visuelles évaluées sont perçues, d'autre part.

Pour comparer les résultats, il est judicieux de conserver explicitement cette séparation conceptuelle. Une Rule élevée ne garantit pas que la typographie, les couleurs ou la hiérarchie soient appropriées ; une Visual basse ne démontre pas non plus, à elle seule, que les vérifications de contenu, de contenance ou de structure des graphiques aient échoué. Lorsque les deux valeurs divergent, la conclusion prudente est que les canaux signalent des aspects distincts du résultat. Il n'y a pas de base ici pour transformer cette divergence en une catégorie universelle de qualité ni pour affirmer qu'il existe un niveau de Rule qui assure un design attrayant.

05

Impact sur la comparabilité entre modèles et conclusions

L'utilisation de Rule comme métrique séparée permet une évaluation plus granulaire des modèles de génération de code. En séparant la justesse de la qualité visuelle, les équipes peuvent identifier si un modèle échoue en raison d'erreurs structurelles ou de limites esthétiques. C'est crucial pour l'intégration dans des pipelines de production, où la justesse est un prérequis à la qualité.

Les résultats d'AesCode montrent que les modèles de code fermés ont tendance à avoir des scores plus élevés en Rule qu'en Visual, avec Style comme dimension la plus faible. Cela suggère que la justesse structurelle est plus facile à atteindre que la qualité esthétique, et que les métriques déterministes comme Rule sont utiles mais insuffisantes pour une évaluation complète de la qualité du design.

Séparer Rule de Visual offre un diagnostic plus granulaire car il permet de distinguer, au sein des dimensions mesurées, entre les exigences structurelles vérifiables et l'évaluation visuelle. Cette distinction peut aider à identifier si un résultat présente des erreurs dans les vérifications de code, de contenu ou de limites, ou si ses difficultés apparaissent dans les dimensions esthétiques. Cependant, la granularité dépend de l'interprétation de chaque score selon sa définition ; la moyenne Rule n'identifie pas à elle seule lequel de ses trois composants explique un résultat ni ne remplace l'examen du canal visuel.

Dans le benchmark de 300 instances avec image de référence, les valeurs du tableau montrent Rule au-dessus de Visual pour les modèles sélectionnés. Cette comparaison concrète accompagne l'observation que Style est la dimension la plus faible, mais ne doit pas être extrapolée au-delà des modèles, des instances et de la configuration décrits. Elle ne transforme pas non plus les valeurs en une échelle commune de qualité esthétique : Rule et Visual correspondent à des évaluations différentes, de sorte que leur distance sert à décrire le motif observé, et non à établir à elle seule une mesure universelle de supériorité.

L'utilité de la métrique dépend également du maintien de sa portée visible lorsqu'elle est utilisée pour comparer les modèles. Si les règles ne couvrent que les chaînes, les limites et la structure des tableaux ou des graphiques, les différences dans Rule décrivent la performance dans ces vérifications et non toutes les raisons possibles pour lesquelles une infographie peut être meilleure ou pire. Pour une lecture complète des résultats, il est nécessaire de considérer simultanément les métriques visuelles mentionnées, en particulier parce que la qualité esthétique peut varier sans que les vérifications structurelles ne changent de manière équivalente.

La conclusion soutenue par les résultats est limitée : dans l'ensemble décrit, les modèles de code fermé tendent à obtenir des scores Rule supérieurs à Visual, tandis que Style apparaît comme la dimension la plus faible. Cela suggère que le respect des conditions structurelles peut être plus atteignable que l'obtention de la qualité esthétique évaluée par le canal visuel, mais ne démontre pas que la correction soit toujours plus facile dans toute situation. Rule est utile pour rendre explicite un type de conformité et est insuffisante, par conception, pour résumer à elle seule la qualité du design.

Comparaison des scores Rule et Visual sur des modèles sélectionnés

Scores moyens sur le benchmark de 300 instances (avec image de référence).

ModèleRuleVisualOverall
GPT-5.585.8076.7681.28
Claude Opus 4.883.5577.2380.39
AesCode-8B90.0775.8082.94
AesCode-32B94.3377.4485.89
06

Poursuivre l’exploration

Sources consultées

03

Corrections et transparence

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

Proposer une correction