Qu'est-ce qu'un ensemble de données ? Explications pour les débutants

Notre point de vue, qui est modeste : nous sommes Geonode et nous vendons des proxys à des personnes qui collectent des données sur le Web ; nous voyons donc beaucoup d’ensembles de données au moment même de leur création. Ce qu’il convient de retenir, c’est que les erreurs coûteuses se produisent au moment de la collecte et ne sont découvertes que des mois plus tard. Ne pas noter la date de collecte des données, ne pas signaler les champs susceptibles de manquer, ne pas conserver les réponses brutes : rien de tout cela ne semble gênant au premier abord, mais tout cela rend un ensemble de données inutilisable dès qu’une question à laquelle vous n’aviez pas pensé est posée. Rien dans cet article ne vous oblige à acheter quoi que ce soit ; ces bonnes habitudes sont gratuites et la plupart ne prennent que quelques minutes.

La structure de base

La plupart des ensembles de données présentent la même structure, quel que soit leur format.

Enregistrements — les éléments individuels. Les lignes d’un tableau, les objets d’un tableau JSON, les fichiers d’un répertoire. Un enregistrement correspond à un élément que vous décrivez : une personne, une transaction, un produit, une photographie.

Champs — les attributs de chaque enregistrement. Les colonnes d’un tableau, les clés d’un objet. Nom, prix, date, catégorie.

Valeurs — ce que contient un champ donné pour un enregistrement donné.

Schéma — la description des champs existants, de leurs types de données et de ceux qui sont obligatoires. Parfois formel et imposé, parfois une entente informelle, et parfois rien du tout — ce qui est justement ce qui pose problème par la suite.

Métadonnées — données concernant l’ensemble de données lui-même. Quand il a été collecté, par qui, où, sous quelle licence, avec quelles limitations connues.

C’est ce dernier élément que les débutants ont tendance à négliger et sur lequel les professionnels expérimentés insistent. Un ensemble de données sans métadonnées n’est qu’un ensemble de chiffres dont on ne peut en aucun cas déterminer s’ils répondent à votre question.

Données structurées, semi-structurées et non structurées

Une distinction en trois catégories très utile, car elle détermine ce que vous pouvez faire sans prétraitement.

Les données structurées possèdent un schéma fixe et des types cohérents. Une table de base de données, un fichier CSV avec un en-tête stable, une feuille de calcul. Vous pouvez les interroger, les filtrer et les agréger directement.

Les données semi-structurées sont organisées mais ne suivent pas de schéma rigide. Il s'agit par exemple de fichiers JSON dont les enregistrements peuvent comporter des champs différents, de fichiers XML ou de lignes de journal. Il existe une structure à analyser, mais celle-ci varie d'un enregistrement à l'autre.

Les données non structurées ne possèdent aucune structure inhérente aux enregistrements. Il s’agit par exemple de documents texte, d’images, de fichiers audio ou vidéo. Ce n’est pas qu’elles ne contiennent aucune information ; c’est simplement que l’extraction de champs nécessite un modèle ou une intervention humaine.

Dans la pratique, les frontières sont floues. Un répertoire d’images accompagné d’un fichier CSV répertoriant les noms de fichiers, les dimensions et les étiquettes constitue un contenu non structuré doté d’un index structuré — ce qui est la configuration standard pour les ensembles de données d’apprentissage automatique et, de manière générale, une bonne pratique.

La plupart des tâches concrètes consistent à effectuer des conversions entre ces deux types de données. Le scraping transforme des pages web non structurées en enregistrements structurés ; c’est lors de cette conversion que la plupart des erreurs se glissent, et c’est pourquoi il est important de conserver la source brute.

Les formats et ce qu’ils vous coûtent

Ce choix a plus d’importance qu’il n’y paraît.

Trois points qui font la différence dans la plupart des cas.

Le format CSV ne dispose d’aucune spécification formelle. La RFC 4180 le précise elle-même, en décrivant ce qui « semble être suivi par la plupart des implémentations ». C’est là l’origine des problèmes de délimiteurs, d’encodage et de guillemets que tout le monde a déjà rencontrés. Il est également compact et universellement lisible, ce qui explique sa persistance.

JSON Lines est sous-utilisé et convient généralement bien à la collecte de données. Un document JSON par ligne : il s’écoule en mémoire constante, s’ajoute en toute sécurité, et un fichier tronqué fournit toujours tous les enregistrements complets. Un tableau JSON ne permet rien de tout cela, et une tâche de collecte qui plante laisse un fichier impossible à analyser.

Parquet est la destination idéale pour tout ce qui est volumineux et destiné à l’analyse. Le stockage en colonnes signifie qu’une requête portant sur trois colonnes parmi quarante ne lit que ces trois-là ; la compression est bien meilleure qu’avec le texte car les valeurs similaires sont regroupées, et les types sont préservés à l’identique. Il n’est pas lisible par l’homme, ce qui constitue le compromis.

Un pipeline judicieux collecte les données au format JSON Lines, car celui-ci tolère les interruptions, puis les convertit par lots au format Parquet pour l’analyse. Nous avons comparé en détail les formats texte dans JSON vs CSV.

Qu'est-ce qui rend un ensemble de données utilisable : FAIR

La communauté scientifique a formalisé ce concept, et ce cadre s'applique bien au-delà du domaine de la recherche.

Les principes FAIR, publiés en 2016, définissent quatre propriétés.

Findable (facile à trouver). Le principe F1 exige que « les (méta)données se voient attribuer un identifiant unique au monde et persistant » ; le principe F2 que « les données soient décrites à l’aide de métadonnées riches » ; le principe F3 que les métadonnées « incluent clairement et explicitement l’identifiant des données qu’elles décrivent » ; et le principe F4 qu’elles soient « enregistrées ou indexées dans une ressource consultable ».

Accessibilité. A1 exige que les données puissent être récupérées « grâce à leur identifiant à l’aide d’un protocole de communication normalisé ». A2 est celle qui surprend le plus et qui est sans doute la plus précieuse : « Les métadonnées sont accessibles, même lorsque les données ne sont plus disponibles. » La description d’un ensemble de données doit survivre à l’ensemble de données lui-même, afin que quiconque lisant un article des années plus tard puisse savoir quelles données ont été utilisées.

Interopérabilité. I1 exige « un langage formel, accessible, partagé et largement applicable pour la représentation des connaissances » ; I2 préconise des vocabulaires qui respectent eux-mêmes les principes FAIR ; I3 préconise des « références qualifiées à d’autres (méta)données ».

Réutilisable. R1 exige que les données soient « richement décrites à l’aide d’une pluralité d’attributs précis et pertinents ».

Concrètement, pour un projet ordinaire : attribuez à votre ensemble de données un identifiant stable, notez ce qu’il contient et d’où il provient, utilisez des noms de champs et des unités standardisés lorsqu’ils existent, précisez la licence et conservez la documentation même si vous supprimez les données.

Documenter un ensemble de données

Les principes FAIR soulignent l’importance de la documentation. Le document « Datasheets for Datasets » précise ce qu’il convient d’y inclure.

Cette proposition de 2018 s’inspire de l’industrie électronique, où chaque composant est livré avec une fiche technique. Elle soutient que chaque ensemble de données devrait être accompagné d’une documentation couvrant « sa motivation, sa composition, son processus de collecte, ses utilisations recommandées, etc. », afin de « faciliter une meilleure communication entre les créateurs et les utilisateurs d’ensembles de données, et d’encourager la communauté de l’apprentissage automatique à privilégier la transparence et la responsabilité ».

En voici la liste de contrôle pratique qui en découle :

Pourquoi ce jeu de données existe-t-il ? À quelle question visait-il à répondre ? Cela permet de déterminer s’il répond à la vôtre.

Que contient-il ? Enregistrements, champs, types, unités et ce qui est considéré comme manquant.

Comment a-t-il été collecté ? Méthode, dates, sources, échantillonnage. Un ensemble de données extrait d’un site en une semaine est un objet différent de celui agrégé sur une année.

Qu’est-ce qu’il n’est pas ? Lacunes connues, biais, populations exclues, périodes manquantes. La section la plus précieuse et celle qui fait le plus souvent défaut.

Comment doit-il être utilisé, et comment ne doit-il pas l’être ? Applications prévues et utilisations connues comme inappropriées.

Quelle est la licence ? Et qui contacter.

Comment est-il mis à jour ? S’il sera mis à jour et comment les versions sont identifiées.

Rédiger ces informations prend une heure lorsque le jeu de données est récent, mais cela devient pratiquement impossible dix-huit mois plus tard, lorsque la personne qui l’a collecté est partie.

Évaluation de la qualité

Six dimensions, chacune pouvant faire l’objet d’une vérification concrète.

Exhaustivité. Quelle est l’ampleur des données manquantes, et ces lacunes sont-elles aléatoires ? Comptez le nombre de valeurs nulles par champ. Un champ vide à 40 % est révélateur : il s’agit soit d’un échec de collecte, soit d’un véritable caractère facultatif que vous devriez documenter.

Exactitude. Les valeurs reflètent-elles la réalité ? Difficile à vérifier de manière générale, mais faisable dans le détail : comparez manuellement un échantillon aléatoire avec la source. Vingt enregistrements prennent quinze minutes et permettent de détecter la plupart des erreurs systématiques.

Cohérence. Les mêmes éléments apparaissent-ils de la même manière ? Des dates dans des formats mélangés, des pays sous la forme « UK » et « United Kingdom », des prix avec et sans symboles monétaires. Comptez les valeurs distinctes par champ catégoriel : un champ comportant trois cents « pays » distincts présente un problème de normalisation.

Actualité. Quand ces données ont-elles été collectées, et cela a-t-il une importance pour votre question ? Les prix du dernier trimestre relèvent davantage de l’histoire que des données.

Représentativité. L’échantillon correspond-il à la population qui vous intéresse ? Un ensemble de données constitué d’avis est un ensemble de données constitué de personnes qui rédigent des avis.

Provenance. Pouvez-vous remonter jusqu’à la source de chaque enregistrement ? C’est ce qui vous permet de recalculer, de vérifier et de corriger — et c’est pourquoi il vaut la peine de conserver les réponses brutes parallèlement aux enregistrements analysés, même si cela occupe de l’espace de stockage.

Effectuez ces vérifications avant l’analyse, et non après. Découvrir un problème de normalisation dans un graphique coûte considérablement plus cher que de le découvrir lors d’un comptage de valeurs.

Répartition des données pour l'apprentissage automatique

Si l'ensemble de données sert à entraîner un modèle, la répartition est tout aussi importante que les données elles-mêmes.

Ensemble d'entraînement — ce à partir de quoi le modèle apprend. Il s'agit généralement de la majeure partie des données. Ensemble de validation — utilisé pour affiner les modèles et choisir entre eux. Ensemble de test — entièrement mis de côté, utilisé une seule fois pour estimer les performances en conditions réelles.

Trois erreurs courantes peuvent se produire.

Fuite d’informations. Les informations issues de l’ensemble de test influencent l’entraînement. La mise à l’échelle ou l’imputation à l’aide de statistiques calculées sur l’ensemble des données avant le fractionnement en est un exemple classique, et cela gonfle vos résultats de manière insidieuse.

Enregistrements en double entre les divisions. Des éléments quasi-identiques à la fois dans l’ensemble d’entraînement et dans l’ensemble de test signifient que le modèle a déjà vu la réponse. Les données collectées sur le Web sont particulièrement sujettes à ce problème, car un même contenu apparaît à plusieurs adresses URL.

Fuite temporelle. Pour les données ordonnées dans le temps, un fractionnement aléatoire permet au modèle d’apprendre à partir de l’avenir. Optez plutôt pour un fractionnement par date.

Le principe général : l’ensemble de test doit ressembler à la situation à laquelle vous serez réellement confronté. Si vous devez prédire demain à partir d’aujourd’hui, effectuez un fractionnement par heure. Si vous allez accueillir de nouveaux utilisateurs, effectuez un fractionnement par utilisateur.

Les licences : ce qui détermine ce que vous pouvez faire

Un ensemble de données que vous ne pouvez pas utiliser légalement n’est pas un ensemble de données dont vous disposez. On vérifie les licences bien moins souvent qu’il ne le faudrait, généralement parce que c’est un sujet ennuyeux… jusqu’au moment où c’est la seule chose qui compte.

Les licences de données ouvertes. Creative Commons est la famille la plus répandue. La licence CC0 place les œuvres dans le domaine public dans la mesure où la loi le permet et n’impose aucune condition. La licence CC BY exige la mention de la source. La licence CC BY-SA ajoute une condition de partage à l’identique, ce qui signifie que les œuvres dérivées doivent être soumises à la même licence — ce qui peut être incompatible avec un produit commercial. La licence CC BY-NC interdit l’utilisation commerciale, et la notion de « non commercial » est définie de manière suffisamment vague pour constituer un risque réel si votre utilisation est ambiguë. Les portails gouvernementaux utilisent souvent des licences ouvertes sur mesure qui sont, dans la pratique, permissives ; lisez-les attentivement plutôt que de faire des suppositions.

Les droits sur les bases de données sont distincts du droit d’auteur. Dans l’UE et au Royaume-Uni, un droit sui generis protège les investissements substantiels réalisés pour obtenir, vérifier ou présenter le contenu d’une base de données — indépendamment du fait que chaque enregistrement individuel soit ou non protégé par le droit d’auteur. Un ensemble de données composé de simples faits peut tout de même être protégé en tant que base de données, ce qui correspond précisément à la situation dans laquelle se trouvent les projets d’agrégation.

Les conditions d’utilisation ont un caractère contractuel. Un ensemble de données collecté sur un site dont les conditions interdisent l’accès automatisé pose ce problème, quelle que soit la nature des enregistrements individuels. Il s’agit d’une question distincte du droit d’auteur et elle s’applique même lorsque les faits eux-mêmes ne sont pas protégés.

Les données à caractère personnel relèvent d’un régime spécifique. Si les enregistrements identifient des personnes — directement ou par recoupement —, la législation sur la protection des données s’applique à leur détention et à leur traitement, et pas seulement à leur collecte. Cela implique une base légale, des délais de conservation et des droits que les personnes concernées peuvent faire valoir à votre encontre. Le fait qu’un ensemble de données ait été « accessible au public » ne constitue pas en soi une base légale.

Et les ensembles de données dérivés héritent de ces contraintes. L’entraînement d’un modèle sur un ensemble de données soumis à une licence « partage à l’identique », ou l’agrégation de plusieurs sources soumises à des licences différentes, engendre des obligations qui correspondent à l’union des conditions d’entrée plutôt qu’à la plus permissive d’entre elles.

Dans la pratique, il est d’usage de consigner la licence dans la documentation de l’ensemble de données au moment de la collecte, en y ajoutant un lien vers les conditions telles qu’elles étaient formulées ce jour-là. Les licences changent, les pages de conditions sont réécrites, et pouvoir montrer ce à quoi vous avez consenti lors de la collecte vaut mieux que de simplement s’en souvenir.

D’où proviennent les ensembles de données ?

Cinq sources, classées par ordre décroissant en fonction de la charge de travail que chacune nécessite.

Ensembles de données ouverts publiés. Portails gouvernementaux, référentiels de recherche, archives institutionnelles. Gratuits, documentés et souvent d’une qualité suffisante. Vérifiez d’abord : la quantité de données déjà disponibles publiquement et qu’il faudrait collecter à nouveau est considérable.

Les API. Structurées, validées, stables. Si une source en publie une, c’est presque toujours la bonne solution.

Les fournisseurs de données commerciaux. Sous licence, avec assistance technique et à un prix adapté. Souvent moins chers que de développer soi-même la même solution, une fois le temps de développement pris en compte.

Vos propres systèmes. Journaux, transactions, télémétrie. Généralement les données les plus précieuses dont dispose une organisation, et les plus négligées.

Collecte sur le Web. Ce que nous commercialisons. Cette méthode est appropriée lorsque les données sont accessibles au public et qu’il n’existe aucun canal validé — mais elle s’accompagne d’obligations : robots.txt, conditions d’utilisation, droits d’auteur, droits sur les bases de données et, lorsque des données à caractère personnel sont concernées, législation sur la protection des données. C’est également la source qui nécessite le plus de documentation, car un ensemble de données extraites sans indication de la date et de la provenance est très difficile à justifier ou à reproduire.

Questions fréquentes

Qu'est-ce qu'un ensemble de données, en termes simples ?

Un ensemble de données liées entre elles, organisées de manière à pouvoir être traitées comme une seule entité — il s'agit généralement d'enregistrements (les éléments) comportant des champs (leurs attributs), ainsi qu'une description de la signification de ces champs. Une feuille de calcul, une table de base de données et un dossier d'images étiquetées sont tous des ensembles de données.

Quelle est la différence entre des données et un ensemble de données ?

Les données constituent la matière première ; un ensemble de données est un ensemble délimité et organisé de ces données, constitué dans un but précis. C’est son organisation et ses limites qui le rendent utilisable : on peut compter les enregistrements d’un ensemble de données, décrire ses champs et indiquer d’où il provient.

Qu’entend-on par données structurées et non structurées ?

Les données structurées possèdent un schéma fixe et des types cohérents, à l’image d’une table de base de données. Les données non structurées ne présentent aucune structure inhérente aux enregistrements — texte, images, audio. Les données semi-structurées se situent entre les deux : elles sont organisées mais leur forme est variable, comme le format JSON ou les fichiers journaux.

Quel format dois-je utiliser pour un ensemble de données ?

Le format CSV pour les tableaux plats destinés à être importés dans des feuilles de calcul ou un outil de chargement de base de données. Le format JSON Lines pour tout ce qui est collecté de manière incrémentielle, car il permet un traitement en continu et résiste à la troncature. Le format Parquet pour les données analytiques volumineuses, car le stockage en colonnes et le typage rendent les requêtes bien moins coûteuses.

Qu’est-ce qui fait qu’un ensemble de données est de bonne qualité ?

L’exhaustivité, la précision, la cohérence interne, l’actualité, la représentativité de la population qui vous intéresse et une provenance traçable. Chacun de ces critères fait l’objet d’une vérification concrète : nombre de valeurs nulles, échantillon vérifié manuellement, nombre de valeurs distinctes par champ catégoriel.

Comment dois-je documenter un ensemble de données ?

Indiquez pourquoi il existe, ce qu’il contient, comment et quand il a été collecté, quelles sont ses lacunes et ses biais connus, comment il doit et ne doit pas être utilisé, sa licence et comment il est maintenu. La proposition « Datasheets for Datasets » constitue la référence standard en la matière.

Que sont les principes FAIR ?

Findable (facilement trouvable), Accessible (accessible), Interoperable (interopérable), Reusable (réutilisable) : un cadre de gestion des données publié en 2016. L’exigence la plus sous-estimée est que les métadonnées doivent rester accessibles « même lorsque les données ne sont plus disponibles », de sorte qu’une description survive à l’ensemble de données lui-même.

Comment diviser un ensemble de données pour l’apprentissage automatique ?

En ensembles d’entraînement, de validation et de test, ce dernier n’étant utilisé qu’une seule fois. Effectuez toutes les transformations à partir de l’ensemble d’entraînement uniquement, supprimez les quasi-doublons entre les différents ensembles et, pour les données ordonnées chronologiquement, effectuez le fractionnement par ordre chronologique plutôt que de manière aléatoire — ces trois éléments sont des sources courantes de résultats gonflés de manière imperceptible.

Conclusion

Un ensemble de données se compose d’enregistrements, de champs et de valeurs, ainsi que de la description qui leur donne tout leur sens. C’est cette description qui détermine si quelqu’un pourra encore l’utiliser dans six mois, y compris vous-même.

Les formats importent moins que les habitudes. Utilisez le format CSV lorsque cela convient, JSON Lines pour tout ce que vous collectez de manière incrémentielle (car ce format résiste à une interruption de la tâche), et Parquet lorsque les données sont volumineuses et que les requêtes sont analytiques. N’importe lequel de ces formats fonctionne ; l’erreur à éviter est de choisir un tableau JSON pour une collecte de longue durée et de se retrouver avec un fichier impossible à analyser après un plantage.

Ce qui rapporte le plus d’efforts, c’est la documentation, rédigée tant que l’ensemble de données est encore frais. Pourquoi il existe, comment et quand il a été collecté, ce qui manque et à quoi il ne doit pas servir. Les principes FAIR l’énoncent formellement, la proposition « Datasheets for Datasets » vous fournit une liste de contrôle, et les deux vont dans le même sens : les métadonnées doivent survivre aux données.

Et vérifiez la qualité avant de procéder à l’analyse. Le nombre de valeurs nulles par champ, le nombre de valeurs distinctes par champ catégoriel et une vingtaine d’enregistrements vérifiés manuellement par rapport à la source permettront de détecter la plupart des problèmes systématiques en moins d’une heure — ce qui revient bien moins cher que de les découvrir une fois l’analyse terminée.