Jeu de données

Trois usages distincts

Un projet sérieux manipule au moins trois jeux séparés. Le jeu d'entraînement fournit les exemples sur lesquels le modèle ajuste ses paramètres. Le jeu de validation sert pendant la mise au point, pour choisir entre plusieurs réglages sans attendre l'évaluation finale. Le jeu de test reste à l'écart jusqu'au bout et donne la mesure honnête de la performance. Mélanger ces rôles produit des résultats flatteurs et faux : le modèle restitue ce qu'il a mémorisé et l'on croit qu'il généralise.

La séparation doit être étanche, y compris pour les données proches. Deux photos de la même scène, deux variantes du même courriel ou deux passages du même document ne doivent pas se retrouver de part et d'autre de la frontière. Sans cette précaution, le test contient des quasi-doublons et gonfle les scores. La règle vaut aussi pour les données collectées dans le temps : un découpage par date est souvent plus proche de l'usage réel qu'un tirage aléatoire des lignes.

La qualité avant le volume

Un petit jeu propre et bien annoté surpasse souvent un corpus immense et bruité. Les défauts les plus fréquents sont connus : étiquettes incohérentes entre annotateurs, doublons, textes tronqués, images floues, catégories déséquilibrées. Un modèle apprend ces défauts en même temps que la tâche. Il faut donc documenter les règles d'annotation, mesurer l'accord entre annotateurs et corriger les cas litigieux avant l'entraînement, non après la première évaluation décevante. Une relecture croisée d'un échantillon, avant le lancement, révèle souvent plusieurs de ces défauts en quelques heures.

La représentativité compte autant que la propreté. Un jeu constitué uniquement de courriels d'un seul service produira un modèle inefficace ailleurs. Pour une entreprise, cela signifie décrire précisément la population visée : types de clients, langues, formats, saisonnalité. Aux Antilles, le créole, les noms propres locaux, les adresses et les formulations régionales sont souvent absents des corpus génériques ; les inclure explicitement évite un écart de performance que l'on découvre en production, une fois le service en ligne.

Constituer un jeu utile

La constitution commence par un inventaire des sources et de leurs droits d'usage. Un fichier interne n'est pas librement réutilisable si les contrats de travail ou les mentions clients l'interdisent ; une base achetée peut être limitée à certains usages. Il faut ensuite définir le format cible, nettoyer, dédupliquer et conserver une trace des transformations. Cette trace permet de rejouer la préparation et d'expliquer, plus tard, pourquoi une version du modèle se comporte différemment d'une autre. Elle sert aussi de preuve si la qualité du corpus est contestée.

Il reste à prévoir la maintenance. Un jeu de données vieillit : les produits changent, les formulations évoluent, les réglementations aussi. Un modèle évalué sur des exemples de plusieurs années en arrière peut sembler solide et échouer sur les demandes actuelles. Des campagnes d'annotation régulières, un suivi des cas mal traités et une procédure de mise à jour évitent que la qualité se dégrade sans que personne ne s'en aperçoive. Ce coût est modeste au regard de celui d'un modèle qui perd silencieusement en fiabilité.