Garder une évaluation qui puisse encore vous surprendre.

Définir ce que chaque exemple représente

Commencez par une phrase de décision : reconnaître la catégorie d’un nouveau ticket, extraire trois champs d’un document ou répondre à une question avec ses pièces jointes. Décrivez l’entrée disponible au moment de la prédiction, la sortie attendue et les cas hors périmètre. Une information ajoutée après la résolution du ticket ne doit pas apparaître dans une entrée censée représenter son arrivée.

Distinguez ensuite ligne et unité indépendante. Cinq messages d’une conversation partagent un contexte ; dix pages d’un dossier partagent leur origine. Si votre objectif porte sur de nouveaux dossiers, gardez chaque dossier dans une seule partition. Une séparation par utilisateur, document, équipement ou période répond à des questions différentes : choisissez celle qui ressemble à l’usage futur, puis inscrivez sa justification dans le manifeste.

Sources techniques : scikit-learn 1.9 — validation avec groupes et dépendances temporelles

Attribuer un rôle à chaque ensemble

Le jeu d’apprentissage sert aux ajustements du modèle. Le jeu de validation guide les décisions de développement : prompt, seuil, hyperparamètres ou choix d’une variante. Le test final répond à une question déjà fixée. Le consulter pour retenir le meilleur réglage transforme progressivement ce test en outil de développement, même si aucun gradient n’est calculé dessus.

Séparez également les données utilisées pour apprendre une transformation. Une normalisation, une sélection de variables ou une imputation ajustée sur tout le corpus peut transmettre de l’information au modèle. Apprenez ces transformations sur la partition autorisée, puis appliquez la transformation conservée aux autres ensembles. Un pipeline facilite ce contrôle ; il ne corrige pas à lui seul des groupes mal séparés.

Sources techniques : scikit-learn 1.9 — fuite de données et transformations

Traiter les doublons sans effacer les cas difficiles

Conservez le corpus brut, puis construisez un inventaire de travail avec identifiant, origine et groupe. Une empreinte du contenu détecte les copies exactes selon la représentation choisie. Documentez cette représentation : retirer toute ponctuation ou mettre un texte en minuscules peut fusionner des entrées dont la différence compte pour la tâche. Gardez la correspondance entre copie écartée et exemplaire conservé.

Les quasi-doublons demandent une revue supplémentaire : export modifié, réponse reformulée, passage commun ou document réédité. Une forte similarité est un signal à examiner, pas une preuve que deux annotations sont interchangeables. Regroupez les variantes liées avant de répartir les données. Si deux copies portent des références contradictoires, ouvrez une question d’annotation ; ne choisissez pas automatiquement celle que le modèle prédit le mieux.

Exemple travaillé : 1 200 lignes ne sont pas 1 200 observations indépendantes

Cet exemple est entièrement illustratif : aucun corpus ni modèle n’a été mesuré. Supposons 240 conversations, chacune exportée sur cinq lignes. Une ligne est une copie exacte dans chaque conversation ; les quatre autres sont distinctes. Retirer ces 240 copies laisse 960 exemples, toujours organisés en 240 groupes. Le choix pédagogique suivant réserve 70 % des groupes à l’apprentissage, 15 % à la validation et 15 % au test.

On obtient 168, 36 et 36 conversations, soit 672, 144 et 144 exemples. L’égalité des proportions en lignes et en groupes vient ici des quatre exemples par conversation. Dans un corpus réel de tailles variables, elle ne serait pas automatique. Ces proportions ne sont pas une règle universelle : elles doivent laisser assez de groupes et de cas importants dans chaque ensemble.

Sources techniques : scikit-learn 1.9 — GroupShuffleSplit compte les groupes

Vérifier classes, longueurs et chronologie

Après la partition, comptez les classes et les groupes qui les portent. Une classe présente sur beaucoup de lignes mais dans une seule conversation n’offre pas beaucoup de cas indépendants. Examinez également longueurs, langues réellement couvertes, documents incomplets et catégories importantes pour la décision. Une moyenne rassurante peut masquer une partition sans aucun exemple d’un cas critique.

Une stratification avec groupes cherche à préserver les proportions de classes sans disperser les groupes. Elle ne garantit pas un équilibre parfait lorsque les groupes sont peu nombreux ou très inégaux. Si la tâche consiste à prévoir des observations futures, une séparation chronologique peut être plus pertinente qu’un mélange aléatoire. Vérifiez aussi que les variables étaient disponibles à la date de la prédiction.

Sources techniques : scikit-learn 1.9 — StratifiedGroupKFold et ses limites · scikit-learn 1.9 — validation de données temporelles

Rendre la référence assez précise pour juger une sortie

Écrivez une consigne d’annotation avec exemples et cas limites. Pour une extraction, précisez le sens d’un champ absent, le format des dates, la devise et les équivalences acceptées. Pour une classification, décrivez les frontières entre catégories. Une réponse différente de la référence n’est pas toujours une erreur du modèle : la référence peut être ambiguë ou incorrecte.

Faites relire une sélection variée, en particulier les désaccords et les cas importants, puis consignez l’arbitrage. Conservez les corrections dans une nouvelle version du jeu. Si une correction change le résultat d’une comparaison, recalculez toutes les variantes concernées sur la même référence ; ne corrigez pas seulement la ligne défavorable à votre modèle préféré.

Produire le paquet d’évaluation avant la campagne GPU

Le livrable de cette préparation est un ensemble identifiable, accompagné de ses règles. Il permet de reproduire la sélection des données sans dépendre d’un souvenir de notebook. Préparer ce paquet avant la location évite de consommer la période de calcul à résoudre des différences de fichiers ou de critères.

• Fixez les identifiants, les groupes, les partitions et leur justification ; conservez le script ou la liste qui les produit.
• Vérifiez les intersections d’identifiants, de groupes et d’empreintes entre partitions. Toute intersection inattendue doit être expliquée ou corrigée.
• Exportez les effectifs par partition, classe et sous-groupe utile, ainsi que la liste des exclusions et leur motif.
• Figez la référence, les règles de normalisation, la métrique principale et les seuils avant la comparaison.
• Conservez révision, empreintes, droits d’utilisation et emplacement des données. Une empreinte assure une identification, pas un anonymat.
• Réservez l’accès au test final jusqu’à la décision prévue ; gardez un journal des consultations et changements de protocole.

Savoir ce que le contrôle démontre

La préparation est acceptable lorsque les effectifs se réconcilient avec l’inventaire, que les chevauchements sont maîtrisés et que chaque sortie peut être jugée selon une règle explicite. Elle ne prouve pas que le modèle réussira, ni que tous les futurs usages sont représentés. Un petit jeu peut décrire un problème précis tout en restant insuffisant pour conclure sur une classe rare.

Si vous utilisez les erreurs du test final pour améliorer le système, conservez ce test comme historique et préparez une nouvelle confirmation indépendante. Pour un modèle préentraîné dont les données d’origine sont inconnues, votre partition ne peut pas certifier l’absence d’exposition antérieure. Documentez cette limite plutôt que de qualifier le jeu de totalement vierge.

Questions pratiques