Stable Diffusion 3.5 Large à l’épreuve : comment mesurer le suivi des prompts

À quelle question ce benchmark répond-il ?

Une évaluation du suivi des prompts cherche à déterminer si une image générée contient les éléments demandés par l’instruction et si ceux-ci présentent les attributs et les relations spécifiés. À elle seule, elle ne permet pas de savoir si le résultat est beau, original ou adapté à tous les usages. Elle ne permet pas non plus de déclarer un modèle « meilleur » dans l’absolu : elle décrit son comportement pour un ensemble de tâches, une configuration et une méthode de notation bien définis.

Pour Stable Diffusion 3.5 Large, la question pratique pourrait être la suivante : à quelle fréquence les générations respectent-elles des exigences vérifiables, comme inclure trois objets, placer l’un à gauche de l’autre ou afficher un mot donné ? La comparaison proposée avec Stable Diffusion 3.5 Medium doit être considérée comme un nouveau test. Dans les sources disponibles ici, aucun résultat quantitatif vérifié ni protocole complet ne permet de présenter un classement déjà établi.

Une page consacrée à un modèle, une recette logicielle ou une démonstration visuelle peut aider à identifier une implémentation ou à la faire fonctionner. Rien de cela ne remplace une évaluation contrôlée. Cet article explique donc comment produire et communiquer des données probantes ; il n’attribue aucun score de suivi des prompts à Large ou à Medium.

Ce qui est vérifié et ce qui reste inconnu

La communication de Stability AI annonce la disponibilité de Stable Diffusion 3.5 Large et de code d’inférence. La fiche hébergée dans l’espace Stability AI sur Hugging Face identifie Large comme un modèle de génération d’images à partir de texte et le décrit comme un Multimodal Diffusion Transformer. Ces informations permettent d’identifier le modèle et sa provenance, mais les extraits disponibles ne fournissent pas de mesures du suivi des instructions.

La documentation d’Amazon Bedrock décrit une offre de SD 3.5 Large dotée de huit milliards de paramètres et produisant des images d’un mégapixel. Ces données se rapportent à la documentation et à la configuration de cette plateforme ; elles ne doivent pas être transposées automatiquement à toutes les implémentations ni interprétées comme des preuves de qualité. Une recette vLLM mentionne, au sein de la famille, une variante Medium de 2,5 milliards de paramètres et une variante Large de 8,1 milliards. Identifier ces tailles ne démontre pas non plus laquelle suit le mieux un prompt.

Le dépôt de Stability AI se présente comme une implémentation de référence consacrée à l’inférence. La disponibilité du code facilite l’examen d’un mode d’exécution, mais ne détermine pas à elle seule les paramètres adaptés à une comparaison. De même, les essais informels partagés sur Reddit relèvent de témoignages anecdotiques : ils peuvent suggérer des cas à étudier, mais ne remplacent pas un jeu de test dont les critères ont été définis à l’avance.

La conclusion méthodologique est limitée, mais importante : au vu des éléments fournis, on ne peut pas affirmer quel modèle obtient les meilleurs résultats en suivi des prompts, quelle différence sépare Large de Medium ni quelle configuration a produit des résultats comparables. Le fait que ces données ne figurent pas dans cet ensemble de sources ne prouve pas qu’aucune évaluation n’a été publiée ailleurs ; cela signifie qu’il ne faut pas attribuer de résultats qui n’ont pas été vérifiés ici.

Concevoir des prompts permettant de vérifier des exigences

Le jeu d’évaluation doit décomposer le suivi en dimensions observables, au lieu de s’appuyer sur une impression générale. Il est utile d’inclure la présence d’objets, leur quantité, les relations spatiales, les attributs visuels et le texte demandé. Chaque prompt doit préciser l’exigence évaluée et les conditions de réussite avant la génération des images. Si une phrase se prête à plusieurs interprétations, il faut la reformuler ou la marquer comme ambiguë, plutôt que de trancher après avoir vu le résultat.

La sélection devrait couvrir des cas simples ainsi que des combinaisons plus exigeantes. Par exemple, un prompt peut demander deux tasses ; un autre, une tasse rouge à gauche d’un livre bleu ; un troisième, une scène comportant une étiquette sur laquelle un mot donné doit être lisible. Il s’agit d’exemples de conception du protocole, et non de résultats attribués aux modèles. Les consignes doivent éviter les détails sans rapport avec l’évaluation qui rendraient difficile l’identification de l’exigence ayant échoué.

Il est utile d’équilibrer les catégories et d’en consigner la composition. Si la plupart des prompts portent sur la présence d’objets et que très peu portent sur le texte, un score global risque de masquer des performances inégales. Il faut également définir les exclusions à l’avance : par exemple, déterminer si le texte sera évalué uniquement lorsqu’il est clairement visible ou si des variations typographiques sont acceptables. Il ne faut pas écarter des prompts parce que leurs résultats gênent une conclusion attendue.

Fixer les conditions d’exécution

Avant toute génération, il faut consigner l’identification exacte du modèle et des poids, ainsi que la version du logiciel, l’implémentation et toute modification du pipeline. Il faut également publier la résolution, le nombre d’étapes, les paramètres de guidage, la précision numérique, le matériel et les options d’accélération. Si une plateforme masque une partie de ces informations, il faut le préciser et limiter les conclusions en conséquence.

La graine aléatoire et le nombre de générations par prompt doivent être documentés. Une seule image par instruction peut laisser le hasard dominer le résultat ; plusieurs générations permettent d’observer cette variabilité, au prix d’un coût supérieur. Le protocole doit fixer le nombre d’échantillons avant l’examen des résultats et appliquer le même critère aux deux modèles. Pour que la comparaison soit interprétable, il est également utile d’indiquer si les graines ont été appariées entre les modèles et ce que signifie cet appariement dans les implémentations utilisées.

Il ne suffit pas d’indiquer une résolution ou un nombre d’étapes si Large et Medium sont exécutés avec des pipelines différents. La comparaison la plus nette conserve les paramètres communs lorsque cela est possible et documente toute différence inévitable. Si les contraintes de mémoire imposent de modifier la précision, la taille des lots ou d’autres options, ces écarts font partie du protocole et peuvent empêcher d’attribuer le résultat au seul modèle.

Noter les exigences et recourir à des évaluateurs à l’aveugle

L’unité principale de notation devrait être l’exigence vérifiable. Pour chaque image, les évaluateurs peuvent indiquer si l’objet est présent, si la quantité est correcte, si l’attribut demandé est visible, si la relation spatiale est respectée et si le texte est lisible et conforme. Une échelle binaire facilite le décompte, mais une catégorie supplémentaire « non évaluable » peut être nécessaire pour les images corrompues ou les consignes réellement ambiguës. Les règles d’utilisation de cette catégorie doivent être établies avant l’examen des résultats.

L’évaluation humaine doit masquer le modèle à l’origine de chaque image et présenter les images dans un ordre mélangé. Les évaluateurs ont besoin de consignes communes, d’exemples d’application de la grille et d’un moyen de noter leurs incertitudes. Il est préférable de faire participer plusieurs personnes et de publier à la fois leur accord et leurs désaccords ; si les divergences sont fréquentes, la définition de l’exigence est peut-être insuffisante. Il ne faut ni régler les désaccords sans le signaler, ni présenter le consensus comme une certitude absolue.

Les métriques automatiques peuvent servir d’appui, mais ne remplacent pas universellement le jugement humain pour toutes les exigences. Avant de les utiliser, il faut expliquer ce qu’elles mesurent, dans quels cas elles s’appliquent et comment elles ont été vérifiées sur un échantillon examiné par des personnes. Une mesure globale de similarité ne prouve pas à elle seule qu’il y a exactement trois objets, que l’un se trouve à gauche de l’autre ou qu’un mot est correctement lisible. Si une métrique n’est pas validée pour une dimension donnée, le rapport doit le préciser plutôt que de la traiter comme un arbitre.

Comparer Large et Medium sans attribution abusive

La comparaison doit utiliser le même jeu de prompts et la même grille de notation. Dans la mesure permise par les implémentations, il faut harmoniser la résolution, le nombre de générations, les paramètres d’inférence et les conditions d’évaluation. Pour chaque exigence, il est préférable de présenter les résultats par modèle et par catégorie, avec le nombre d’échantillons et une description de la variabilité, plutôt qu’une simple moyenne générale.

Des valeurs identiques dans un tableau de paramètres ne garantissent pas des exécutions équivalentes si le pipeline, la précision, les options d’échantillonnage ou le logiciel diffèrent. Tout écart doit donc être clairement visible. Si une différence importante ne peut pas être contrôlée, le rapport doit décrire une comparaison entre deux configurations complètes, et non un test isolé permettant d’affirmer que la taille ou la variante du modèle a causé le résultat.

Il ne faut pas compléter les champs non exécutés avec des valeurs supposées. Le rapport peut publier le protocole envisagé et laisser les résultats en attente. Une fois les données disponibles, chaque conclusion devra être reliée au jeu de test, à la configuration et à la grille qui l’étayent. L’évaluation proposée ne permet pas de prédire si Large suivra mieux les instructions que Medium.

Contamination, sélection des échantillons et limites

Un benchmark peut être biaisé si ses prompts sont publics, ont été utilisés à maintes reprises dans des démonstrations ou ressemblent à des exemples rencontrés pendant le développement du système. Sans accès aux informations sur les données d’entraînement, il n’est pas toujours possible de confirmer ou d’exclure une exposition préalable. L’équipe d’évaluation peut réduire les risques en rédigeant des prompts pour le test, en en limitant l’accès jusqu’à son exécution et en publiant ensuite le jeu de données. Elle doit toutefois présenter ces mesures comme des garde-fous partiels, et non comme la preuve d’une absence de contamination.

La sélection des images introduit également un biais si seules les générations les plus convaincantes sont retenues et montrées. Pour l’éviter, il faut conserver toutes les générations prévues et définir à l’avance les règles d’exclusion. Des galeries d’exemples peuvent illustrer des réussites ou des échecs, mais elles ne remplacent pas les décomptes complets. Une graine unique, une sélection manuelle a posteriori ou une catégorie ne comportant que peu de cas peuvent donner une impression trompeuse.

La grille repose sur des décisions humaines : ce qui constitue une relation spatiale suffisante, le moment où un texte devient lisible ou le niveau de détail nécessaire pour considérer un attribut comme respecté. Des définitions opérationnelles, une évaluation indépendante et la publication des désaccords sont donc nécessaires. Les résultats ne doivent pas être combinés sans précaution avec les scores d’autres jeux de données, configurations ou méthodes : lorsque les tâches et les règles de mesure diffèrent, les chiffres ne décrivent pas nécessairement le même phénomène.

Liste de vérification pour publier le benchmark

Une évaluation utile doit permettre à une autre personne de répéter la procédure et d’en comprendre les limites, même si elle n’obtient pas des images identiques. Les éléments publiés devraient inclure les prompts, les critères d’inclusion et d’exclusion, les graines, le nombre de générations, les versions et les configurations, ainsi que les images ou une explication claire de leur non-distribution. Il faut également fournir la grille, les formulaires d’évaluation, la méthode de mise à l’aveugle et les résultats détaillés par dimension.

Le rapport devrait séparer les faits observés, les choix méthodologiques et les interprétations. Par exemple, le décompte des réponses des évaluateurs est un résultat de l’exécution ; la définition de ce qui constitue une « relation spatiale respectée » est un choix de grille ; affirmer qu’un écart est dû au modèle est une interprétation qui exige des conditions comparables et des éléments probants suffisants. Cette séparation aide les lecteurs à ne pas confondre une recommandation de protocole avec un résultat déjà mesuré.

Tant qu’un test de ce type n’a pas été publié et reproduit, il est plus rigoureux de présenter Stable Diffusion 3.5 Large et Medium comme des variantes à évaluer dans des conditions explicites, et non comme les gagnants ou les perdants d’un benchmark de suivi des prompts. L’index des benchmarks peut fournir un contexte éditorial, et la fiche d’évaluation de SD 3.5 Large peut servir de référence pour le test, à condition de ne pas présenter les résultats en attente comme des mesures. La conclusion pratique est simple : publier la méthode avant d’interpréter les images, puis publier les données avec tout score communiqué.

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.