AesCode Infographics Chart : ce que les éléments disponibles permettent de vérifier et ce qui manque pour comparer

État des preuves : de la documentation et du code, mais pas une reproduction complète

La documentation publique d’AesCode permet d’affirmer davantage que la simple existence d’une suite comprenant un canal nommé Chart. Le dépôt officiel décrit le système d’évaluation, énumère les vérificateurs et fournit des instructions pour les exécuter. La fiche du modèle ajoute des résultats, des conditions de génération et une définition générale du calcul des scores. Il est donc possible d’examiner la conception annoncée et d’exécuter certaines parties du harness avec des données accessibles à l’équipe qui le met en œuvre.

Cela ne signifie pas qu’il soit possible de reproduire de zéro les chiffres publiés. Le dépôt précise qu’il distribue le code, mais pas les jeux de données. Il indique également qu’un échantillon comprend une consigne, des exigences vérifiables et une image de référence. Toutefois, la disponibilité du format ou d’un exemple ne prouve pas que les 300 cas évalués ont été publiés. L’écart principal sépare donc la disponibilité des outils d’évaluation de celle de tous les éléments nécessaires pour répéter l’expérience d’origine.

Les éléments examinés ici proviennent de deux ressources primaires du projet : le dépôt de Microsoft et la fiche d’AesCode-8B. Les deux décrivent le travail sous le nom AesCode et renvoient à l’article identifié comme un préprint arXiv. Les informations consultées ne permettent pas de vérifier indépendamment le statut de publication avec comité de lecture de cet article. Il n’est donc pas présenté comme un travail évalué par les pairs ni comme une réplication indépendante. Les résultats doivent être compris comme des chiffres communiqués par le projet, et non comme une validation externe.

La place de Chart dans la suite

Le tableau des résultats présente Text, Bound et Chart comme des contrôles programmatiques agrégés dans Rule. Content, Layout et Style composent Visual ; Overall est la moyenne de Rule et de Visual. Cette structure est importante : le score Chart n’est ni le résultat total de l’évaluation visuelle ni une mesure autonome de qualité esthétique. Il s’agit d’une dimension de correction vérifiable associée aux graphiques.

Le dépôt décrit les exigences relatives aux graphiques à l’aide de données attendues, par exemple des séries nommées et leurs valeurs ou des listes numériques, ainsi que du type de graphique. Dans la description du système, le canal tablechart vérifie les données des tableaux et des graphiques. La fiche d’AesCode-8B présente Chart comme une composante programmatique de Rule. Cette documentation étaye les relations générales, mais ne suffit pas à établir tous les détails de la fonction de score ni le traitement des cas particuliers.

La nomenclature appelle à la prudence : la proposition initiale cite Bound, Content, Layout et Overall comme des composantes proches, mais la documentation comprend également Text, Chart, Rule et Style. Ce sont des catégories distinctes, pas des synonymes. Bound et Chart ont chacun leur propre score ; Rule les regroupe avec Text. De même, Content, Layout et Style sont combinés dans Visual, qui intervient ensuite dans Overall. Comparer le score Chart d’un modèle au score Overall d’un autre reviendrait à mélanger des niveaux d’agrégation.

Ce que montrent les chiffres — et ce qu’ils ne démontrent pas

Dans le tableau publié, AesCode-8B obtient 87,79 en Chart et AesCode-32B, 90,37. La fiche indique que les résultats ont été calculés sur 300 échantillons d’infographies, avec trois générations par consigne et sans sélection entre les générations. Ces données permettent de décrire le résultat communiqué et la procédure globale qui l’accompagne. À elles seules, elles ne permettent pas de déterminer comment les scores varieraient avec une autre sélection de cas, une autre implémentation ou une répétition indépendante.

La même source indique les paramètres de génération utilisés pour les scores : température de 0,8, top-p de 0,95, jusqu’à 12 000 jetons en sortie et un contexte de 24 576 jetons. Ces précisions aident à délimiter la configuration rapportée. Elles ne constituent pas une spécification exhaustive de toutes les conditions expérimentales de chaque système comparé : les modèles, les outils disponibles, les versions et les environnements peuvent différer. Pour attribuer une différence aux capacités du modèle, il faudrait des configurations comparables et documentées pour chaque système.

Les scores doivent aussi être interprétés à la lumière du périmètre du canal. Chart évalue une facette de la suite liée aux données des graphiques ; il ne démontre pas automatiquement que les visualisations sont esthétiquement réussies, que le résultat est factuel au-delà des exigences fournies ou qu’un modèle est supérieur pour toutes les tâches de génération visuelle. La documentation décrit la composition de Rule et de Visual, mais les éléments disponibles ne comprennent pas d’audit externe du jeu de cas ni d’estimation de l’incertitude statistique pour chaque score.

Les lacunes qui limitent l’audit méthodologique

La première limite concerne la disponibilité des données. Le dépôt indique qu’il publie le code, mais pas les jeux de données, et décrit un format d’échantillon composé d’une consigne, d’exigences vérifiables et d’une image de référence. Sans l’ensemble complet des cas de Chart, il est impossible de vérifier les types de graphiques présents, la répartition des niveaux de difficulté, l’existence de doublons ou le poids relatif de certaines familles de graphiques. Un exemple fourni dans le dépôt aide à comprendre le format, mais ne représente pas nécessairement l’évaluation complète.

La deuxième limite tient à la spécification opérationnelle complète. Le code d’évaluation est disponible et la documentation explique les canaux et leurs dépendances, mais un audit des résultats doit fixer les versions, les paramètres, le traitement des échecs, les règles d’agrégation et le comportement lorsqu’une exigence ne peut pas être vérifiée. Le dépôt avertit lui-même qu’en l’absence de PaddleOCR, un canal de Layout renvoie zéro au lieu de s’abstenir. Cet avertissement concerne Layout et ne démontre pas un défaut de Chart ; il montre néanmoins pourquoi les dépendances et les chemins d’erreur doivent être consignés lors de la reproduction d’un score.

La troisième limite concerne la comparabilité entre modèles. La documentation fournit les paramètres de génération des scores d’AesCode-8B, mais une comparaison équitable suppose de connaître et d’aligner les conditions pertinentes pour tous les systèmes : versions des modèles, gabarits, entrées, outils, limites de sortie et règles de nouvelle tentative ou de sélection. Les éléments disponibles ne suffisent pas à affirmer que tous les modèles du tableau ont reçu exactement le même traitement sur chacun de ces aspects. Le tableau constitue donc un rapport du projet, mais ne dispense pas de vérifier la comparabilité avant de l’utiliser pour des décisions importantes.

Ce qu’il faudrait pour un audit futur

Une évaluation reproductible nécessiterait au minimum la version exacte du code utilisé, une description sans ambiguïté de la métrique Chart, les spécifications de ses entrées et une explication de l’agrégation des résultats, du niveau de chaque graphique jusqu’au score publié. Elle devrait également documenter les dépendances et l’environnement d’exécution, ainsi que les critères appliqués aux erreurs de rendu, aux graphiques non détectés, aux données manquantes et aux cas non applicables. Le dépôt fournit du code et des étapes de configuration, mais la liste des éléments nécessaires reste incomplète tant que le jeu évalué n’est pas disponible ou accessible selon une procédure transparente.

La publication des cas permettrait d’examiner leur couverture et d’établir des partitions reproductibles. S’il existe des éléments sensibles, il serait possible de publier des identifiants, des spécifications, des scripts de génération ou un accès contrôlé assorti de règles claires. L’essentiel est que des tiers autorisés puissent vérifier ce qui a été évalué et que le jeu ne change pas silencieusement d’une version à l’autre. Un identifiant de version et une empreinte de contrôle des fichiers aideraient à détecter les modifications.

Il faudrait aussi distinguer réplication et extension. Répliquer consisterait à exécuter la même évaluation avec le même jeu et la même configuration, puis à comparer les résultats. Étendre l’étude consisterait à tester d’autres domaines, types de graphiques ou modèles ; cela peut être utile, mais ne vérifie pas à lui seul les chiffres d’origine. Enfin, les résultats devraient être communiqués par cas, avec des mesures de variabilité entre générations, et pas seulement sous forme de moyennes agrégées. On pourrait ainsi distinguer une amélioration régulière d’un écart concentré sur quelques exemples.

Conclusion : la comparaison est possible, mais sa portée est limitée

On peut aujourd’hui affirmer qu’AesCode documente un canal Chart intégré à une évaluation plus vaste, publie des scores pour des modèles précis et fournit du code pour exécuter l’évaluation. On peut également affirmer que le projet décrit 300 échantillons, trois générations par consigne et une agrégation dans laquelle Chart fait partie de Rule. Ces éléments permettent de comprendre la structure présentée et d’examiner le logiciel.

En revanche, les éléments disponibles ne permettent pas d’affirmer que toutes les équipes peuvent reproduire exactement le tableau publié : le dépôt indique que les données ne sont pas distribuées. Ils n’établissent pas non plus l’existence d’une réplication indépendante ni celle d’une comparaison entièrement contrôlée entre tous les modèles. La position rigoureuse consiste à traiter les scores comme des résultats communiqués par le projet, utiles pour orienter les questions et les expériences, mais à vérifier par des tiers avant de les utiliser comme critère définitif de sélection.

Pour les chercheurs et les équipes d’évaluation, la décision pratique dépend de l’usage envisagé. À titre exploratoire, les résultats peuvent aider à repérer les différences rapportées entre les systèmes. Pour établir un classement concluant, justifier un achat ou soutenir une affirmation générale de performance, il est préférable d’exiger les données, les versions, les spécifications opérationnelles et les résultats par cas. Sans ces éléments, les preuves disponibles permettent de décrire le benchmark, mais pas de clore l’audit de sa comparabilité.

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.