Aller au contenu principal
iaPréparer les données

Préparer les données

Ce que ce chapitre apporte

  • Ordonner les étapes de préparation et dire pourquoi cet ordre.
  • Supprimer les doublons et normaliser les libellés incohérents.
  • Convertir une valeur sentinelle en valeur manquante déclarée.
  • Choisir une stratégie d'imputation et nommer le biais qu'elle introduit.
  • Encoder une variable ordinale et une variable nominale, et justifier la différence.
  • Traiter les valeurs aberrantes par écrêtage plutôt que par suppression aveugle.
  • Choisir entre mise à l'échelle, standardisation et transformation logarithmique.
  • Reconnaître une fuite de données, sous ses deux formes.
C'est l'étape qui occupe la majeure partie du travail réel et la portion la plus mince des cours. Elle consiste à transformer un tableau tel qu'on l'a reçu en un tableau qu'un algorithme peut consommer : sans trou, sans texte là où il faut des nombres, sans variable qui écrase les autres par son échelle. Chaque geste y est un choix, et chaque choix introduit une hypothèse. Ce chapitre les rend explicites, puis se termine sur la faute qui invalide silencieusement plus de projets que toutes les autres réunies : la fuite de données.

L'ordre des opérations

Sept étapes, et l'ordre n'est pas arbitraire
1. Dédoublonner, avant tout calcul : un doublon fausse toutes les statistiques qui suivent.
2. Normaliser les libellés, sans quoi les regroupements seront faux.
3. Convertir les sentinelles en valeurs manquantes déclarées, pour cesser de les compter comme des mesures.
4. Imputer ou supprimer les valeurs manquantes, maintenant qu'elles sont toutes visibles.
5. Traiter les valeurs aberrantes, une fois les fausses valeurs écartées.
6. Encoder les variables qualitatives.
7. Mettre à l'échelle, en dernier, sur des colonnes toutes numériques et complètes.
Inverser deux de ces étapes produit rarement une erreur visible, et souvent un résultat faux. Imputer avant de convertir les sentinelles, par exemple, laisse vingt-huit zéros dans le calcul de la médiane qui servira à imputer.

Nettoyer

main.py
Sortie
>_ Prêt à exécuter…
Le nettoyage n'a pas dégradé le signal, il l'a révélé
Avant nettoyage, la salle C était à 28,9 °C contre 22,5 et 23,0 pour les autres. Après, elle est à 31,9 °C contre 23,5 et 23,6.
L'écart est passé de six degrés à plus de huit. Rien n'a été inventé : les vingt-huit zéros tiraient toutes les moyennes vers le bas, et les douze serveurs de la salle fantôme « a » manquaient au calcul de la salle A.
C'est le résultat qu'on doit attendre d'un nettoyage réussi. Il ne rend pas les données plus belles, il les rend plus fidèles, et le signal qui existait devient mesurable.

Les valeurs manquantes

Trois mécanismes, trois conséquences

Manquant complètement au hasard : la disparition ne dépend de rien. Supprimer ces lignes ne biaise rien, on perd seulement de la taille d'échantillon.

Manquant au hasard conditionnellement : la disparition dépend d'autres variables observées. Un capteur absent dans les salles récentes, par exemple. On peut corriger, à condition d'utiliser ces autres variables.

Manquant non au hasard : la disparition dépend de la valeur elle-même. Les salaires les plus élevés sont ceux qu'on ne déclare pas. Aucune imputation ne répare cela, et c'est le cas le plus fréquent.

Toute imputation ment, la question est de savoir comment
Supprimer la ligne : simple, et perd tout le reste de la ligne. Sur une colonne où 40 % manquent, cela supprime 40 % du jeu.
Remplacer par la moyenne ou la médiane : conserve la taille, mais réduit artificiellement la variance et crée un pic sur une valeur qui n'a été mesurée nulle part. Toutes les corrélations impliquant cette colonne sont affaiblies.
Remplacer par la médiane du groupe : nettement mieux quand un groupe explique la variable, ce qui est le cas ici avec la salle. C'est l'imputation employée ci-dessus.
Prédire la valeur par une régression sur les autres colonnes : le plus fidèle, et le plus risqué, parce qu'il renforce artificiellement les relations qu'il utilise.
Aucune de ces options n'est neutre. La seule faute est de ne pas savoir laquelle on a prise.
Le fait qu'une valeur manque est parfois l'information
Ajouter une colonne booléenne « cette valeur était manquante » coûte une colonne et sauve parfois le modèle.
Si les capteurs tombent en panne surtout sur les machines les plus vieilles, l'absence de mesure est corrélée à la cible. Imputer sans garder cette trace efface une information réelle.
Le geste est bon marché et il faut le faire dès que le taux de valeurs manquantes dépasse quelques pour cent.

Les variables qualitatives

Deux traitements, selon qu'il y a un ordre

Ordinale : les modalités sont ordonnées. On les remplace par des entiers respectant cet ordre. faible → 0, moyen → 1, fort → 2.

Nominale : aucun ordre. On crée une colonne binaire par modalité, valant 1 si l'individu la porte. C'est l'encodage dit « un parmi n ».

Coder une nominale par un entier invente une géométrie
Écrire salle A = 0, B = 1, C = 2 affirme que B est entre A et C, et que la distance de A à C vaut le double de celle de A à B.
Tout algorithme qui calcule des distances, des sommes ou des moyennes prendra ces affirmations au sérieux. Un partitionnement rapprochera A et B parce que leurs codes sont voisins, ce qui n'a aucun sens.
Le prix de l'encodage « un parmi n » est de créer des colonnes supplémentaires. C'est un prix qu'il faut payer.
main.py
Sortie
>_ Prêt à exécuter…
Quand il y a trop de modalités
Une colonne « ville » à trois mille valeurs distinctes produirait trois mille colonnes, dont presque toutes seraient à zéro presque partout. C'est inexploitable.
Trois parades. Regrouper selon une hiérarchie métier : ville, puis département, puis région. Rassembler la queue : garder les vingt modalités les plus fréquentes et coder le reste en « autre ». Ou remplacer la modalité par une statistique calculée dessus, comme le taux de panne moyen de la salle, ce qui est puissant et qui est aussi une porte d'entrée pour la fuite de données décrite plus bas.

Les valeurs aberrantes

Les détecter relève du module Sciences fondamentales, chapitre 5, qui donne le z-score, sa version robuste et l'écart interquartile. Ce qu'il faut décider ici, c'est ce qu'on en fait.

Trois traitements, du plus brutal au plus prudent
Supprimer l'observation. À réserver aux cas où l'on a établi que la mesure est fausse : une température de 400 °C, un âge négatif. Supprimer une valeur simplement parce qu'elle est extrême revient à jeter l'information la plus intéressante du jeu.
Écrêter. Ramener toute valeur au-delà d'un seuil à ce seuil, par exemple au 99e centile. On conserve l'observation et l'on borne son influence. C'est le traitement par défaut raisonnable.
Ne rien faire. Certains modèles, les arbres notamment, sont insensibles aux valeurs extrêmes puisqu'ils ne raisonnent que sur des seuils. Il est inutile de traiter ce qui ne gêne pas.
Un aberrant peut être exactement ce qu'on cherche
Dans une détection de fraude, une supervision d'incidents ou un contrôle qualité, les cas rares sont la cible.
Les écrêter revient à effacer les exemples positifs, et à produire un modèle qui ne détecte plus rien tout en affichant d'excellentes statistiques.
La question à poser avant tout traitement est donc : cette valeur extrême est-elle une erreur de mesure ou un événement rare ? La réponse ne se lit pas dans le tableau, elle vient du métier.

La mise à l'échelle

Trois transformations, trois usages

Mise à l'échelle min-max : x=xxminxmaxxminx' = \dfrac{x - x_{\min}}{x_{\max} - x_{\min}}, qui ramène tout entre 0 et 1. Simple, et très sensible aux valeurs extrêmes, puisque deux valeurs suffisent à fixer l'échelle.

Standardisation, ou Z-score : x=xμσx' = \dfrac{x - \mu}{\sigma}, qui donne une moyenne nulle et un écart-type de 1. Moins sensible aux extrêmes, et c'est le choix par défaut.

Transformation logarithmique : x=log(x)x' = \log(x), qui redresse une distribution à queue lourde. Elle change la forme, pas seulement l'échelle, et elle exige des valeurs strictement positives.

Pourquoi c'est indispensable, et pour quels algorithmes
Une variable qui varie de 1 à 100 000 et une autre de 0 à 1 ne pèsent pas le même poids dans un calcul de distance : la première écrase la seconde, quel que soit son intérêt réel.
Les algorithmes concernés sont tous ceux qui calculent des distances ou des sommes pondérées : partitionnement, plus proches voisins, régressions ajustées par descente de gradient, réseaux de neurones, machines à vecteurs de support.
Les algorithmes indifférents sont ceux qui ne comparent que des seuils, variable par variable : les arbres de décision et tout ce qui en dérive. Mettre à l'échelle avant un arbre ne coûte rien et ne sert à rien.
main.py
Sortie
>_ Prêt à exécuter…
La distinction qui compte
Une mise à l'échelle est une transformation affine : elle déplace et redimensionne, sans rien changer à la forme de la distribution ni aux corrélations. L'asymétrie reste identique au dix-millième près, ce que la figure vérifie.
Une transformation logarithmique comprime les grandes valeurs plus que les petites. Elle change la forme, réduit l'asymétrie, et modifie les corrélations.
Confondre les deux mène à standardiser une distribution à queue lourde en croyant l'avoir corrigée. Il faut souvent faire les deux, et dans cet ordre : le logarithme d'abord, la standardisation ensuite.

La fuite de données

Fuite de données

Il y a fuite lorsqu'une information qui ne sera pas disponible au moment de la prédiction se retrouve dans les données d'apprentissage.

Le modèle affiche alors d'excellentes performances en évaluation, et s'effondre en production.

C'est l'erreur la plus coûteuse du domaine
Elle ne provoque aucun message, aucune anomalie, aucun avertissement. Au contraire : elle améliore tous les indicateurs, ce qui la rend indétectable par les moyens habituels et parfaitement convaincante en réunion.
Elle se découvre en production, quand le modèle qui affichait 95 % en fait 60, et il est alors difficile de comprendre pourquoi.
Deux formes principales, et le code ci-dessous les montre toutes les deux.
main.py
Sortie
>_ Prêt à exécuter…
Ce que ces deux exemples montrent
La fuite par variable conséquence. Le nombre d'interventions est corrélé à 0,83 avec la panne, et une règle d'une ligne donne 95 % de bonnes réponses. C'est logique : les interventions ont eu lieu parce que la machine est tombée en panne. Au moment où l'on voudrait prédire, ce chiffre vaut zéro pour tout le monde.
La fuite par choix informé. Sur des données sans le moindre signal, choisir les cinq variables les plus corrélées à la cible en regardant tout le jeu produit une performance apparente de près de 67 % sur le jeu de test. Le même choix fait sur les seules données d'entraînement retombe au niveau du hasard, aux fluctuations d'échantillonnage près.
Dans les deux cas, aucun code n'est faux et aucune erreur n'est signalée.
Les deux questions qui l'attrapent
Pour chaque colonne : cette information est-elle disponible au moment où je voudrai prédire ? Une date de clôture, un montant de remboursement, un nombre d'interventions, un statut final : tout ce qui est postérieur à l'événement doit sortir.
Pour chaque traitement : ai-je regardé le jeu de test pour le décider ? Sélection de variables, médiane d'imputation, moyenne et écart-type de standardisation, seuils d'écrêtage : tous doivent être calculés sur l'entraînement seul, puis appliqués tels quels au test.
La deuxième règle a une conséquence pratique forte : la découpe entraînement-test doit avoir lieu avant la préparation, pas après. Le chapitre 7 en fait un principe.

Exercices type

Une colonne « statut » vaut « actif », « suspendu » ou « résilié ». Quel encodage ?

Nominal, donc « un parmi n » : trois colonnes binaires.

Il est tentant d'y voir un ordre, du plus au moins actif. Mais rien ne dit que l'écart entre actif et suspendu vaut l'écart entre suspendu et résilié, et un algorithme de distance prendrait cette affirmation au sérieux.

L'exception serait un ordre métier établi et des écarts qui ont un sens, comme des niveaux de service contractuels numérotés. Dans le doute, l'encodage un parmi n ne coûte que des colonnes.

Et si « résilié » est la cible qu'on cherche à prédire, alors le statut ne doit pas figurer parmi les variables explicatives du tout : ce serait une fuite.

Quarante pour cent d'une colonne manquent. Faut-il la supprimer ?

Pas automatiquement. Trois questions, dans cet ordre.

Que vaut la colonne ? Si c'est la variable la plus explicative, garder 60 % d'information vaut mieux que zéro.

Le manque est-il informatif ? Ajouter une colonne « valeur absente » et regarder si elle est corrélée à la cible. Si oui, l'absence est une donnée, et supprimer la colonne détruirait aussi cette information.

Le manque est-il concentré ? Si les 40 % manquants sont sur une période, une salle ou un fournisseur, c'est un problème de collecte à documenter, et l'imputation globale serait franchement trompeuse.

Ce qui n'est jamais acceptable, c'est d'imputer 40 % d'une colonne par sa médiane sans le dire : quatre valeurs sur dix seraient alors identiques et fabriquées.

Faut-il standardiser avant un arbre de décision ?

Non, c'est inutile. Un arbre ne compare jamais deux variables entre elles : à chaque nœud il choisit une variable et un seuil, et ne regarde que l'ordre des valeurs de cette variable.

Or toute mise à l'échelle affine préserve l'ordre. Les mêmes découpes seront trouvées, aux valeurs de seuil près.

Cela reste vrai pour tout ce qui dérive des arbres. En revanche, dès qu'un algorithme calcule une distance ou une somme pondérée, la mise à l'échelle devient indispensable : partitionnement, plus proches voisins, régressions par gradient, réseaux de neurones.

Un modèle de détection de fraude atteint 99,8 % de bonnes réponses. Que soupçonner ?

Deux choses, et il faut vérifier les deux.

Le déséquilibre des classes. Si la fraude concerne 0,2 % des transactions, répondre toujours « pas de fraude » donne 99,8 %. Le chiffre annoncé peut être celui d'un modèle qui ne détecte rien. Les métriques du chapitre 9 le diraient immédiatement.

Une fuite de données. Une colonne comme « montant remboursé », « dossier contentieux ouvert » ou « transaction annulée » n'existe qu'après que la fraude a été constatée. Elle prédit parfaitement, et pour rien.

Un chiffre très élevé n'est jamais une bonne nouvelle en soi. C'est une invitation à chercher d'où il vient.

Pourquoi calculer la moyenne de standardisation sur l'entraînement seul, alors que l'écart est minuscule ?

Parce que le principe compte plus que l'ampleur dans ce cas particulier.

Pour une standardisation sur un grand jeu bien mélangé, l'écart est effectivement négligeable, et la fuite est théorique.

Mais le même geste appliqué à d'autres traitements est dévastateur, comme le montre la sélection de variables du chapitre : 67 % de performance apparente sur du bruit pur. La sélection de variables, l'imputation par prédiction, le choix des seuils d'écrêtage et le réglage des hyperparamètres sont tous concernés.

Adopter la règle sans exception coûte une ligne de code et supprime toute une catégorie d'erreurs. Chercher à savoir au cas par cas si la fuite est grave coûte du temps et finit par se tromper.

Dans le jeu de données du chapitre, l'âge est tronqué à 120 mois. Que faire ?

Aucune reconstruction n'est possible : l'information a été perdue à la collecte, et rien dans le tableau ne dit si une machine à 120 vaut 121 ou 300 mois.

Trois attitudes défendables.

Documenter et laisser tel quel, en sachant que toute relation avec l'âge sera aplatie au-delà de dix ans.

Ajouter une colonne booléenne « âge tronqué », pour que le modèle puisse au moins traiter ce groupe à part.

Discrétiser l'âge en tranches, la dernière étant « plus de dix ans ». On perd de la finesse là où l'on n'en avait déjà plus, et l'on cesse de faire semblant.

Ce qu'il ne faut pas faire, c'est traiter les 120 comme des mesures ordinaires dans une régression : la pente estimée sera fausse.

Vérification rapideon peut se reprendre

1.Dans quel ordre traiter doublons, sentinelles et imputation ?

2.Une variable « statut marital » doit être encodée…

3.Remplacer les valeurs manquantes par la médiane a pour effet…

4.Le Z-score corrige-t-il une distribution à queue lourde ?

5.Une colonne « nombre d'interventions » prédit la panne à 93 %. Qu'en penser ?

6.Sur quel jeu calculer la moyenne et l'écart-type d'une standardisation ?

La méthode

  1. Dédoublonner avant tout calcul.
  2. Normaliser les libellés : espaces, casse, accents.
  3. Convertir les sentinelles en valeurs manquantes déclarées, avant d'imputer.
  4. Choisir une stratégie d'imputation et écrire le biais qu'elle introduit.
  5. Ajouter une colonne « valeur absente » dès que le taux de manquants dépasse quelques pour cent.
  6. Encoder l'ordinal par un entier, le nominal par une colonne par modalité.
  7. Écrêter plutôt que supprimer, sauf si la mesure est démontrée fausse.
  8. Transformer d'abord la forme, mettre à l'échelle ensuite.
  9. Vérifier colonne par colonne que l'information existera au moment de prédire.
  10. Découper entraînement et test avant de préparer, et n'ajuster aucun paramètre sur le test.

Synthèse

  • L'ordre des étapes n'est pas arbitraire : une inversion produit un résultat faux sans erreur visible.
  • Un bon nettoyage ne rend pas les données plus belles, il révèle le signal qui était masqué.
  • Trois mécanismes de manque, dont un, le non aléatoire, qu'aucune imputation ne répare.
  • Toute imputation ment : la médiane réduit la variance, la prédiction renforce les relations qu'elle utilise.
  • Le fait qu'une valeur manque est parfois lui-même une information à conserver.
  • Ordinal se code par un entier, nominal par une colonne binaire par modalité.
  • Un aberrant est une erreur de mesure ou un événement rare : la réponse vient du métier.
  • Une mise à l'échelle ne change pas la forme ; seul le logarithme redresse une queue lourde.
  • Les algorithmes à distance exigent la mise à l'échelle, les arbres y sont indifférents.
  • Une fuite de données améliore tous les indicateurs, ne signale rien, et se découvre en production.
  • Deux formes : une variable conséquence de la cible, et un choix fait en regardant le test.