Qu'est-ce qu'un jeu de données de modèles créatifs ?

Un jeu de données de modèles créatifs est une collection de créations réutilisables, accompagnée d'informations qui rendent ces créations exploitables par des systèmes de calcul. Selon la tâche, ces informations peuvent inclure des aperçus rendus, des fichiers source modifiables, des objets textuels, jeux de données d'images, des vecteurs, des coordonnées de mise en page, la typographie, les relations entre composants, la provenance et des historiques des modifications de conception.

La distinction clé par rapport à un simple jeu d'images plat tient à la représentation. Une affiche rendue indique à un système à quoi ressemble le design fini. Un modèle structuré peut aussi préserver ce que contient le design, comment ses éléments sont positionnés et reliés, quelles parties peuvent être modifiées et, dans certains jeux de données, comment la composition a été créée ou transformée. Le bon niveau de structure dépend de la tâche d'IA ; il n'existe pas de schéma universel de jeu de données.

Un jeu de données de modèles créatifs, également appelé jeu de données de modèles de conception, est une collection de créations visuelles réutilisables organisées avec les informations nécessaires pour analyser, retrouver, modifier, générer ou évaluer ces créations de manière computationnelle.

Les enregistrements courants peuvent inclure des métadonnées de modèle, des rendus d'aperçu, des fichiers source, du texte, des images, des vecteurs, des informations de mise en page, de la typographie, des rôles sémantiques, des relations entre composants, la lignée de la famille de modèles, la provenance et des données d'opérations de conception. Un jeu de données simple peut ne stocker que des aperçus et des étiquettes. Un jeu de données structuré peut préserver beaucoup plus de la composition elle-même.

Cette définition importe car l'expression « jeu de données de modèles » peut décrire des représentations très différentes. L'extension de fichier n'est pas le facteur déterminant. La question utile est de savoir quelle part de la structure de conception sous-jacente reste explicite, lisible par machine et réutilisable.

Certains jeux de données d'images contiennent des annotations étendues, tandis que d'autres, destinés aux modèles, ne renferment guère plus que des aperçus rendus. La distinction n'est donc pas absolue : il vaut mieux la considérer comme une différence dans les informations conservées.

Un rendu et un modèle modifiable peuvent montrer la même composition tout en exposant des informations différentes. Le rendu préserve l'apparence finale. Un modèle modifiable peut conserver les objets individuels, le texte, l'ordre des calques, les dimensions, les styles, les groupes et les relations.

La différence devient importante lorsque l'objectif dépasse la simple récupération visuelle. Un système de recherche peut n'avoir besoin que d'un aperçu et de métadonnées. Un générateur de mise en page peut nécessiter des positions et des relations explicites. Un système d'édition peut avoir besoin de l'identité des composants et de contraintes. Un système qui apprend des flux de travail créatifs peut aussi bénéficier de séquences d'actions et d'états intermédiaires.

Il n'existe pas de schéma standard unique dans l'industrie pour les jeux de données de modèles créatifs. Un schéma pratique doit être guidé par la tâche visée. Les huit types d'informations suivants couvrent les principaux types de structure qu'un jeu de données peut préserver.

1. Métadonnées au niveau du modèle

Les métadonnées décrivent l'enregistrement dans son ensemble et permettent le filtrage, la recherche, l'analyse, la gestion des versions et la gouvernance. Les champs typiques incluent l'ID du modèle, la catégorie, le format, les dimensions, le rapport d'aspect, l'industrie, l'utilisation prévue, la plateforme, la langue, la région, la source, la date de création ou de mise à jour, la licence et la provenance.

2. Représentation visuelle

Les enregistrements visuels relient les données structurées à la composition finale. Ils peuvent inclure des rendus en taille réelle, des vignettes, des états de rendu alternatifs, ou des références aux ressources d'origine telles que photographies, illustrations, logos et éléments graphiques décoratifs.

3. Composants et structure des calques

Les composants sont les objets qui composent un design : blocs de texte, images, vecteurs, formes, icônes, logos, boutons et autres éléments. Lorsque les données sources le permettent, l'ordre des calques, la visibilité, le groupement et la hiérarchie peuvent aussi être représentés.

Pour une création promotionnelle, un enregistrement structuré peut distinguer un arrière-plan, un logo, un titre, une image produit, un texte d'accompagnement, un prix, un CTA et une forme décorative. Ces rôles peuvent être représentés séparément au lieu de forcer le système à les déduire à partir des pixels.

4. Mise en page et relations spatiales

Les données de mise en page peuvent inclure des coordonnées x/y, des boîtes englobantes, des largeurs et hauteurs, l'alignement, l'espacement, les marges, les positions dans la grille, l'échelle, la rotation, l'inclusion et l'ordre en z. Les informations spatiales explicites sont particulièrement utiles lorsqu'un modèle doit générer ou adapter une composition plutôt que simplement la reconnaître.

5. Typographie

La typographie peut être stockée sous forme de propriétés structurées telles que famille de polices, taille, graisse, interlignage, espacement des lettres, alignement, couleur et hiérarchie du texte. Cela diffère du simple fait d'observer la typographie dans une image, car les attributs sous-jacents peuvent être interrogés ou modifiés lorsqu'ils sont préservés.

6. Rôles sémantiques et intention de conception

L'annotation sémantique explique ce que font les éléments. Un objet texte peut être étiqueté comme titre, corps de texte, prix ou CTA. Une image peut être étiquetée comme image produit, arrière-plan ou portrait. Une forme peut être décorative ou fonctionnelle. Ces étiquettes aident à séparer l'apparence visuelle de la fonction communicative.

L'intention de conception peut aller plus loin en enregistrant ce que la composition cherche à communiquer, le public visé ou les contraintes qui ont guidé la mise en page. Ces champs ne devraient être inclus que lorsqu'ils sont définis de manière suffisamment cohérente pour être utiles.

7. Relations

Un design structuré peut encoder des relations telles que l'appartenance parent-enfant, le regroupement, l'alignement, la proximité, l'inclusion, la répétition, la superposition et la dépendance. Les données de relations sont particulièrement précieuses lorsque le design doit rester cohérent après qu'un élément ait été modifié ou déplacé.

8. Opérations de conception et données de processus

Certains jeux de données enregistrent le processus ayant produit une conception plutôt que seulement son état final. Un enregistrement de processus peut contenir le type d'opération, le composant affecté, l'état précédent, l'état résultant, l'outil ou l'action, la position dans la séquence, l'instruction d'édition, la ressource d'origine et le rendu intermédiaire.

Les données d'état final décrivent ce qu'est devenue la conception. Les données d'opération peuvent décrire comment elle a changé. Cette distinction est pertinente pour les systèmes d'utilisation d'outils, d'édition automatisée, d'apprentissage des flux de travail créatifs et de génération prenant en compte les révisions.

Le nombre de fichiers peut surestimer la diversité des designs, car plusieurs enregistrements peuvent appartenir à une même famille de modèles sous-jacente. Une campagne peut comporter une version carrée, une version verticale destinée aux stories, une bannière au format paysage, une version localisée, une adaptation de couleur et plusieurs dérivés. Ces fichiers sont des enregistrements utiles, mais ils ne constituent pas nécessairement des concepts de design indépendants.

Conserver explicitement la filiation lorsque les variantes représentent des adaptations significatives. Un schéma pratique peut séparer l'identité stable de l'enregistrement des relations de parenté :

Cela crée une distinction cruciale en matière de mesure : le nombre de fichiers et le nombre de designs indépendants sont deux métriques différentes. Un corpus contenant de nombreuses variantes redimensionnées ou localisées peut comporter un grand nombre d'actifs sans pour autant augmenter la diversité des designs indépendants.

Un flux de travail utile commence par les exigences du modèle, pas par le nombre de fichiers disponibles. Un processus en sept étapes suffit pour la plupart des projets :

1. Définissez la tâche cible — jeux de données d'entraînement pour l'IA. Précisez si le jeu de données prend en charge la recherche, la recommandation, la classification, la génération, l'édition, la génération de mise en page, la localisation, le redimensionnement ou l'évaluation.

2. Récupérez des modèles et vérifiez la provenance et les droits. Enregistrez l'origine, la propriété, l'étendue des licences, les autorisations d'entraînement pour l'IA, les restrictions sur les éléments intégrés et toute condition de redistribution avant tout traitement à grande échelle.

3. Normalisez les formats, les identifiants et les métadonnées. Standardisez les noms, les dimensions, les systèmes de coordonnées, le traitement des couleurs, les types de composants, les références de fichiers et les champs de métadonnées requis.

4. Extrayez la structure modifiable. Lorsque les fichiers sources le permettent, extrayez les calques, objets, textes, images, vecteurs, groupes, coordonnées, typographie, styles et relations.

5. Ajoutez des annotations pertinentes pour la tâche. Définissez la portée d'annotation minimale nécessaire pour atteindre l'objectif du modèle. Davantage d'annotations n'est pas forcément mieux.

6. Identifiez les doublons, variantes et familles de modèles. Consolidez les véritables doublons tout en préservant la filiation de conception légitime.

7. Validez le jeu de données et créez des partitions résistantes aux fuites. Vérifiez les fichiers, les rendus, les annotations, les métadonnées, la provenance et les droits, puis regroupez les enregistrements liés avant de procéder à la répartition train/validation/test lorsque l'objectif est la généralisation à de nouveaux designs.

La déduplication ne doit pas effacer l'historique de conception significatif. Les doublons exacts et les enregistrements dupliqués dans la base de données peuvent généralement être supprimés ou consolidés. Les variantes nécessitent un traitement plus attentif.

Un design redimensionné ne doit pas être automatiquement traité comme un doublon. Un changement de format peut provoquer un réagencement du texte, le déplacement d'éléments, le recadrage d'images, une mise à l'échelle ou des modifications de la hiérarchie. Ces transformations peuvent elles-mêmes constituer des informations utiles pour l'entraînement ou l'évaluation.

Un fichier jamais vu n'est pas nécessairement un design inédit. Si plusieurs fichiers proviennent de la même famille de modèles, placer différentes variantes dans les ensembles d'entraînement et de test peut donner à l'évaluation une apparence d'indépendance plus grande qu'elle ne l'est en réalité.

Lorsque le test vise à mesurer la généralisation à de nouveaux designs, regroupez les enregistrements liés avant la séparation. Les clés potentielles de regroupement incluent la famille de modèles, le design parent, la campagne, le projet source, la structure de composants partagée ou la lignée dérivée.

La stratégie de séparation appropriée dépend de la question d'évaluation. Un modèle conçu pour s'adapter à des modèles connus peut légitimement être évalué sur des variantes de ces mêmes familles. Un benchmark visant la généralisation à des designs inédits devrait normalement exclure ces familles.

Une répartition inégale n'est pas automatiquement un biais nuisible. La question pertinente est de savoir si la distribution des données est inadaptée à la tâche visée ou si elle entraîne des performances systématiquement médiocres dans des contextes importants.

Un jeu de données dominé par des publications carrées sur les réseaux sociaux peut convenir à un générateur de publications carrées, mais être mal adapté à un système censé gérer des affiches, des diapositives de présentation, des publicités au format paysage et des motion graphics. Mesurez la couverture par catégorie, format, langue, plateforme, source, famille de modèles et schéma structurel là où ces dimensions importent.

Le déséquilibre des classes est une propriété mesurable d'un jeu de données. Le biais du jeu de données est plus large : il concerne la manière dont la collecte des données et leur représentation affectent les performances, la couverture ou le comportement du système visé. Ces deux termes ne doivent pas être traités comme des synonymes.

Les métadonnées décrivent l’enregistrement du jeu de données ; les annotations décrivent ou étiquettent des informations sur son contenu. La distinction est pratique. La source, la licence, le format de fichier, les dimensions et la provenance sont des métadonnées. Des étiquettes telles que titre, image du produit, CTA, boîte englobante, design ou jugement de qualité sont des annotations.

La qualité doit être évaluée selon plusieurs axes. Vérifiez l’exactitude, la cohérence, la couverture, la lisibilité par machine, la gestion des versions du schéma et la validation. Les consignes d’annotation devraient définir les limites des catégories et les cas limites avant la production à grande échelle.

Une étiquette manquante n’est pas automatiquement une étiquette négative. Lorsque l’absence peut être ambiguë, le schéma devrait distinguer « inconnu », « non fourni », « non applicable » et les états négatifs confirmés lorsque la tâche exige cette distinction.

La disponibilité publique n'est pas la même chose que l'autorisation pour l'entraînement d'IA à des fins commerciales ou pour la redistribution. Un jeu de données peut contenir des droits qui s'appliquent à différents niveaux : le modèle lui-même, les photographies intégrées, les polices, les icônes, les logos, les fichiers sources et les enregistrements dérivés.

Au minimum, les acheteurs devraient pouvoir déterminer d'où provient le matériel, quel accord s'applique, quelles utilisations sont autorisées, si l'entraînement d'IA est couvert, si des dérivés peuvent être créés, si la redistribution est permise, et quelles informations de provenance sont disponibles.

CreativePSD est un exemple utile pour la recherche. Sa fiche publique actuelle du jeu de données indique une licence CC BY-NC 4.0 et mentionne des considérations de recherche non commerciale. Cela en fait une référence utile pour la recherche, mais il ne faut pas la considérer comme automatiquement adaptée à l'entraînement d'IA à des fins commerciales.

Pour les projets commerciaux, l'examen juridique devrait se fonder sur l'accord réel, la juridiction, les droits sur le contenu source et l'utilisation prévue du modèle. Un jeu de données public de recherche, une licence de stock média et un accord commercial sur les données d'IA ne sont pas des catégories interchangeables.

Les modèles créés par des humains peuvent révéler des conventions de production, des choix de conception authentiques et des variations du monde réel.

Aucune de ces catégories n'est automatiquement supérieure. Les données synthétiques peuvent reproduire des artefacts spécifiques au générateur ou une structure irréaliste. Human activity recognition datasets : les bibliothèques peuvent être très répétitives ou concentrées dans certains styles. Le test pertinent est de savoir si l'ajout d'une source de données améliore la couverture ou les performances lors d'une évaluation indépendante du domaine cible.

Un enregistrement structuré peut être représenté de plusieurs façons. Le JSON suivant est donné à titre d'exemple et n'est pas une norme universelle :

{
  "schema_version": "1.0",
  "template_id": "T - 00124",
  "template_family_id": "TF - 00042",
  "variant_id": "square - en - v1",
  "metadata": {
    "category": "social_media",
    "format": "square",
    "language": "en"
  },
  "components": [],
  "relationships": [],
  "provenance": {
    "source_record_id": "SRC - 101",
    "rights_record_id": "RIGHTS - 204"
  }
}

Les noms de champs exacts peuvent varier. Les choix architecturaux principaux sont l'identité explicite, la traçabilité, les composants structurés, les relations et les références à des enregistrements faisant autorité pour la provenance et les droits.

Les recherches actuelles montrent que les données de conception graphique dépassent les images plates et évoluent vers des structures en couches, des représentations éditables, des informations sur le processus et des évaluations spécifiques à la conception. Les exemples ci‑dessous illustrent différentes facettes de ce changement ; aucun ne doit être considéré comme un repère universel pour tous les projets de jeux de données basés sur des modèles.

LICA rapporte 1 550 244 compositions multicouches et 971 850 modèles uniques, plus 27 261 mises en page animées comprenant des informations de mouvement au niveau des composants. GraphicDesignBench organise 50 tâches professionnelles de design graphique réparties en cinq axes, montrant que l'évaluation s'étend au-delà de la simple similarité d'images. Ces chiffres constituent des éléments de preuve utiles quant à l'orientation de la recherche, mais ils ne prescrivent pas la taille qu'un jeu de données commercial doit comporter.

Les données de modèles structurés peuvent prendre en charge plusieurs tâches différentes. La représentation requise varie en fonction de la tâche.

Recherche et recommandation

Les systèmes de recherche peuvent combiner l'intention sémantique, la similarité visuelle, la catégorie, le format, la mise en page et les métadonnées de modèle. Des enregistrements structurés facilitent la recherche de propriétés telles que “une promotion de produit épurée avec une grande image et un CTA percutant” sans se fier uniquement aux mots-clés exacts.

Classification et recherche sémantique de design

Les modèles peuvent être classés par catégorie, format, secteur, style visuel, type de mise en page, structure des composants, typographie ou usage prévu. Des étiquettes structurées peuvent permettre le filtrage et la recherche sémantique au sein de grandes collections.

Adaptation et localisation

Une représentation structurée peut prendre en charge des modifications contrôlées telles que passer du format carré au format vertical, du desktop au mobile, d'une langue à une autre, ou d'un produit à un autre. Le défi consiste à préserver la hiérarchie et les relations lorsque le format cible change.

Génération éditable et automatisation des flux de travail

Générer une image qui ressemble à une affiche est différent de générer une affiche éditable avec des composants distincts de texte, image, forme et mise en page. Cette dernière exige une représentation de la structure éditable, pas seulement de l'apparence.

Les données de processus peuvent ajouter une couche supplémentaire en décrivant les actions utilisées pour modifier un design. CreativePSD et PSDesigner illustrent cette orientation en combinant la structure du design avec les trajectoires d'outils. 

Évaluation de la qualité du design

Les données structurées peuvent aussi permettre l'évaluation de la typographie, de la mise en page, de la hiérarchie, de l'alignement, de la lisibilité, de la composition et de la cohérence sémantique. PosterReward et GraphicDesignBench sont des exemples de recherches qui considèrent le design graphique professionnel comme un domaine ayant ses propres défis d'évaluation.

Il est préférable de considérer cela comme une décision liée aux exigences, et non comme une simple comparaison générale de la qualité. Un corpus existant est intéressant lorsqu'il répond déjà aux exigences du modèle. La production sur mesure devient plus utile lorsque le projet a besoin de catégories, de formats, de langues, d'annotations, de systèmes de conception ou d'une provenance contrôlée qui font défaut.

Par exemple, un acheteur commercial peut consulter la bibliothèque de jeux de données d'un fournisseur, puis examiner sa documentation sur les licences et la conformité avant de décider si une collection existante répond aux exigences du projet.

Une règle utile en matière d'approvisionnement est de séparer les exigences strictes des caractéristiques comparatives. La structure modifiable requise, les droits exigés, les formats obligatoires ou la provenance requise doivent être considérés comme des critères éliminatoires. La couverture, la richesse des métadonnées, la qualité des annotations et la diversité des familles peuvent ensuite être comparées entre les jeux de données qui remplissent ces critères.

Une liste de contrôle axée sur l'acheteur peut également aider à structurer cet examen. Consultez un guide d'achat de jeux de données pour un flux de travail d'approvisionnement plus large.

Avant l'achat, posez des questions qui rendent le jeu de données auditable plutôt que de vous fier aux seuls chiffres des fichiers.

• Combien de designs indépendants sont inclus, et comment l'unicité est-elle mesurée ?

• Comment les familles de modèles, les variantes et les ressources sources partagées sont-elles représentées ?

• Quels formats de fichiers sont éditables, et quelle structure y est préservée ?

• Quels champs sont des métadonnées, lesquels sont des annotations, et comment les deux sont-ils validés ?

• Comment les doublons et quasi-doublons sont-ils détectés ?

• Comment sont construits les ensembles d'entraînement, de validation et de test ?

• Quels enregistrements de provenance et de droits sont fournis pour les modèles et les ressources intégrées ?

• Quelles utilisations sont autorisées par l'accord applicable, y compris l'entraînement d'IA, l'utilisation commerciale, les dérivés et la redistribution ?

• Quel schéma, quels enregistrements d'exemple, quel historique de versions et quelle documentation de qualité le fournisseur peut-il fournir ?

• Comment les mises à jour du jeu de données seront-elles versionnées, afin que les équipes en charge des modèles puissent reproduire des expériences antérieures ?

DesignWizard fournit un exemple concret au niveau du produit montrant pourquoi la structure des modèles est importante. Sa documentation publique indique que certains modèles sélectionnés sont modifiables au niveau des éléments et décrit la modification ou le téléchargement de fonds, d'images,jeux de données vidéo, de polices, de couleurs et de texte, ainsi que le redimensionnement des créations. 

Ces fonctionnalités illustrent ce qu'un flux de travail créatif modifiable expose à un utilisateur. Elles ne prouvent pas, à elles seules, quelles données sont stockées en interne ni ce que contiendrait unjeu de données d'entraînement pour l'IA dérivé de la plateforme. Cette distinction est importante : la fonctionnalité du produit est la preuve d'un flux de travail modifiable, mais pas la preuve d'un schéma back-end non divulgué.

Une étude crédible de première partie pourrait renforcer cet article en auditant un échantillon documenté de vrais jeux de données de modèles. Les champs utiles comprendraient le nombre d'éléments, le nombre d'objets texte, le nombre d'objets image/vidéo, les polices, les dimensions du canevas, les rapports d'aspect, les catégories, le statut statique ou animé, la taille de la famille de modèles et le nombre de versions adaptées. La méthodologie devrait publier la taille de l'échantillon, la méthode de sélection, la date d'analyse, les règles de regroupement, les champs mesurés et les limites avant la communication de tout résultat agrégé.

Compter les fichiers plutôt que les designs indépendants. De grandes familles de variantes peuvent gonfler la taille du corpus sans créer une diversité structurelle équivalente.

Aplatir trop tôt les données sources modifiables. Convertir les gabarits sources en images peut supprimer les calques, les objets textuels, les limites des composants et les relations.

Considérer les étiquettes manquantes comme des négatifs. Un champ vide peut signifier « inconnu », « non applicable » ou simplement « non annoté ».

Utiliser des divisions aléatoires au niveau des fichiers lorsque l'objectif est la généralisation à de nouveaux designs. Regrouper d'abord par famille lorsque des variantes apparentées risquent de traverser la frontière de la partition.

Considérer l'accès public comme une preuve de droits commerciaux. Les conditions de distribution du jeu de données et les droits sur le contenu sous-jacent peuvent être différents.

Optimiser uniquement pour la diversité visuelle. La diversité structurelle, la couverture sémantique et la couverture des tâches ciblées peuvent être tout aussi importantes.

Une page de qualité pour la publication peut tirer parti d'un petit nombre d'illustrations explicatives pour transmettre des informations utiles. Celles-ci doivent communiquer la structure, et non servir de décoration.

Qu'est-ce qu'un jeu de données de modèles créatifs ?

Il s'agit d'une collection de designs réutilisables, accompagnée d'informations qui les rendent analysables ou exploitables par des systèmes informatiques. Selon la tâche, les enregistrements peuvent inclure des rendus, des fichiers source, des composants, la mise en page, la typographie, des rôles sémantiques, des relations, l'historique, la provenance et des données de processus.

Quelle est la différence entre un jeu de données de modèles et un jeu de données d'images ?

Un jeu de données d'images représente principalement le contenu visuel sous forme de pixels. Un jeu de données de modèles peut préserver une structure supplémentaire, comme des composants éditables, des calques, la mise en page, la typographie, les relations et les variantes.

Pourquoi les modèles éditables sont-ils utiles pour l'entraînement de l'IA ?

Les modèles éditables peuvent révéler une structure difficile à reconstituer de manière fiable à partir d'une image aplatie, notamment des objets séparés, du texte, la hiérarchie des calques et les relations spatiales. Cela peut être utile pour la génération structurée, l'édition et l'adaptation.

Comment les variantes de modèles doivent-elles être réparties entre les données d'entraînement et de test ?

Regroupez les variantes apparentées par famille de modèles ou autre filiation significative avant de séparer les jeux de données lorsque l'objectif est de tester la généralisation à de nouveaux designs. Un fichier inédit n'est pas nécessairement un design inédit.

Les fichiers PSD, InDesign ou Illustrator peuvent-ils être utilisés comme données d'entraînement pour l'IA ?

Ils peuvent constituer des sources structurées utiles lorsque les objets, textes, calques et relations requis sont accessibles. Leur adéquation dépend toutefois toujours du contenu des fichiers, de la provenance, des licences, du pipeline d'extraction technique et de l'utilisation prévue pour l'entraînement.

Quels droits doivent être vérifiés avant d'utiliser des modèles pour l'IA ?

Vérifiez la propriété, l'étendue de la licence, l'autorisation d'entraînement par l'IA, les droits dérivés, les droits de redistribution, la provenance et les droits sur les éléments intégrés tels que les images, les polices, les icônes et les logos.

De quelle quantité de données de modèles un projet d'IA a-t-il besoin ?

Il n'existe pas de chiffre universel. Le volume requis dépend de la tâche, de la profondeur de représentation, du domaine cible, de la diversité et du protocole d'évaluation. Plus de fichiers ne compensent pas l'absence d'informations dont le modèle a réellement besoin.

Quand une entreprise devrait-elle utiliser un jeu de données existant plutôt que d'en commander un sur mesure ?

Utilisez un jeu de données existant lorsqu'il satisfait déjà aux exigences strictes du projet en matière de structure, de couverture, de qualité et de droits. La production sur mesure devient plus pertinente lorsque les formats, domaines, langues, annotations, systèmes de design ou contrôles de provenance requis ne sont pas disponibles dans les données existantes.

Un jeu de données pour des modèles créatifs représente une conception à un niveau plus profond que ses pixels finaux lorsque les données sous-jacentes conservent des composants modifiables, la mise en page, la typographie, la sémantique, les relations, la provenance, la traçabilité ou les opérations de conception.

Le bon jeu de données est donc une question de représentation dépendant de la tâche. La récupération peut ne nécessiter que des aperçus et des métadonnées. La génération de mises en page peut exiger des informations spatiales explicites. La génération modifiable peut nécessiter des composants et des relations. Les systèmes axés sur les flux de travail peuvent bénéficier de traces d'opérations. La taille du jeu de données importe, mais seulement si la représentation contient l'information que le modèle est censé apprendre.

Pour les équipes évaluant un jeu de données commercial, les questions pratiques sont tout aussi concrètes : combien de designs indépendants sont présents, comment les variantes sont-elles groupées, quelle structure est effectivement préservée, comment les annotations sont-elles validées, comment les fuites de données sont-elles contrôlées, et quels droits et quelle provenance accompagnent les données ? Ces questions fournissent une base de comparaison plus significative que le simple nombre de fichiers.