Récemment, je faisais des tests avec un modèle de régression logistique sur l'un de mes projets.

En observant sa convergence via la valeur de la loss (fonction de perte) époque par époque, j'ai découvert une particularité de la régression logistique dont je ne m'étais jamais rendu compte :

Tu es surpris ?

Permets-moi de te détailler mon raisonnement.

Rappels

Nous savons tous que la régression logistique prédit la probabilité d'appartenance à une classe, donnée par la formule :

De plus, sa fonction de perte est l'entropie croisée binaire (ou log loss), qui s'écrit ainsi :

où yᵢ est l'étiquette réelle, et ŷᵢ est la probabilité prédite

• Quand l'étiquette réelle yᵢ = 1, la valeur de la perte est → -log(ŷᵢ).

• Quand l'étiquette réelle yᵢ = 0, la valeur de la perte est → -log(1-ŷᵢ).

Et comme nous le savons tous, le modèle tente de déterminer les paramètres (θ₀, θ₁) en minimisant cette fonction de perte.

Démonstration

La probabilité de sortie ci-dessus peut être réécrite de la façon suivante :

Pour faire simple, nous avons exprimé la fonction de probabilité de sortie en fonction de deux autres paramètres.

C'est clair jusqu'ici ?

Prenons maintenant le dataset 1D suivant, avec des classes bien séparées :

En modélisant cela avec la régression logistique de sklearn, nous obtenons ceci :

En affichant les valeurs (m, c) à partir de la formulation ci-dessous, nous obtenons m = 2.21 et c = -2.33.

Voyons maintenant si nous pouvons obtenir une meilleure courbe de régression.

Plus précisément, nous allons essayer d'ajuster notre modèle avec différentes valeurs de m.

Les résultats sont présentés ci-dessous :

À partir du visuel ci-dessus, il est clair qu'augmenter le paramètre m conduit systématiquement à :

• Une valeur de loss plus faible (bien que non nulle).

• Un meilleur ajustement (fit) de la régression.

Or, pour obtenir le meilleur ajustement possible, la courbe sigmoïde devrait être parfaitement verticale au milieu, ce qui est mathématiquement impossible.

Par conséquent, l'affirmation précédente : "La régression logistique ne peut jamais ajuster parfaitement des classes bien séparées" est totalement valide.

C'est pourquoi de nombreuses implémentations open-source (comme sklearn, par exemple) s'arrêtent après un certain nombre d'itérations.

Il est donc important de noter qu'elles laissent toujours une petite marge d'amélioration si nécessaire.

J'adorerais avoir tes avis sur cette petite expérience en commentaire ! 👇

D'ailleurs, t’es-tu déjà posé les questions suivantes :

1. Pourquoi utilisons-nous la fonction Sigmoïde dans la régression logistique ?

2. Pourquoi utilisons-nous la log loss pour entraîner une régression logistique ?

Pourquoi pas d'autres fonctions ?

Elles ne sortent pas de nulle part, n'est-ce pas ? Il doit bien y avoir une origine mathématique derrière tout ça, non ?

Jette un œil à ces deux mini-cours approfondis pour le découvrir :

• Pourquoi utilise-t-on la fonction Sigmoïde en Régression Logistique ?

• Pourquoi utilise-t-on la "log loss" pour entraîner une Régression Logistique ?

Dans la première partie de cette analyse approfondie sur la calibration des modèles, nous avons posé les bases en détail : définition de la calibration, et techniques pour mesurer le degré de miscalibration dans les modèles de Machine Learning.

Calibration des modèles (Partie 1) : tes réseaux de neurones sont-ils trop sûrs d'eux ?

Découvre pourquoi tes réseaux de neurones sont mal calibrés : comprends le paradoxe des modèles modernes et apprends à mesurer leur certitude réelle en production.

Nous avons également compris quelques éléments historiques sur l'évolution des modèles et pourquoi ils sont devenus de plus en plus mal calibrés au fil du temps.

Voici la partie 2, dans laquelle nous allons explorer certaines limites des méthodes vues en partie 1, et discuter des techniques courantes pour calibrer les modèles de Machine Learning.

Récapitulatif rapide

Pour rappel, revenons sur le graphique suivant, qui compare un LeNet (développé en 1998) avec un ResNet (développé en 2016) sur le dataset CIFAR-100.

Sur ce graphique, la confiance (confidence) moyenne est déterminée en utilisant l'étiquette (label) ayant la probabilité softmax la plus élevée, sur l'ensemble des échantillons du dataset

Ce graphique nous montre clairement que :

• La confiance moyenne du LeNet (un modèle plus ancien) correspond de près à sa précision réelle.

• En revanche, la confiance moyenne du ResNet (un modèle relativement plus récent) est nettement supérieure à sa précision réelle.

Ainsi, on peut voir que le modèle LeNet est bien calibré, puisque sa confiance correspond étroitement à la précision attendue. En revanche, la précision du ResNet est meilleure (0,7 > 0,5), mais cette précision ne correspond pas à sa confiance.

Autrement dit, le modèle ResNet, bien qu'il soit globalement plus précis, est surconfiant dans ses prédictions. Ainsi, tandis que la confiance moyenne du LeNet s'aligne bien avec ses performances réelles — ce qui indique une bonne calibration — la confiance moyenne du ResNet, plus élevée que sa précision, montre qu'il prédit souvent les résultats avec une certitude supérieure à ce qui est justifié.

Pourquoi cela arrive-t-il ?

Dans la partie 1, nous avons également abordé certaines raisons techniques (liées à la procédure d'entraînement) qui nous ont aidés à comprendre pourquoi les modèles modernes se miscalibrent davantage, etc.

Pourquoi la calibration est-elle importante ?

Une question revient souvent à ce stade :

La motivation est assez similaire à ce que nous avons également abordé dans le mini-cours sur la prédiction conforme (lien ci-dessous) :

Maîtriser l'incertitude en Machine Learning avec la Prédiction Conforme

Maîtrise l'incertitude en Machine Learning avec la Prédiction Conforme : construis des intervalles de confiance robustes et déploie tes modèles en toute sécurité.

Faire confiance aveuglément aux prédictions d'un modèle ML peut parfois être fatal, surtout dans des environnements à hauts enjeux où les décisions basées sur ces prédictions peuvent affecter des vies humaines, la stabilité financière ou des infrastructures critiques.

Si une précision de "95%" paraît bonne sur le papier, le modèle ne te dira jamais quels sont les 5% spécifiques de ses prédictions qui sont incorrects lorsqu'il est utilisé en production.

Autrement dit, même si l'on sait que les prédictions du modèle sont généralement correctes un certain pourcentage du temps, le modèle ne peut généralement pas nous en dire davantage sur une prédiction spécifique.

En conséquence, dans des situations à haut risque comme le diagnostic médical, par exemple, faire confiance aveuglément à chaque prédiction peut entraîner de graves conséquences sur la santé.

Ainsi, pour atténuer ces risques, il est essentiel de ne pas se fier uniquement aux prédictions, mais aussi de comprendre et quantifier l'incertitude associée à ces prédictions.

Mais comme les modèles modernes s'avèrent de plus en plus surconfiants dans leurs prédictions (comme on l'a vu ci-dessus), il est important de s'assurer que notre modèle n'en fait pas partie.

Cette surconfiance peut être problématique, surtout dans des applications où les probabilités prédites sont utilisées pour prendre des décisions critiques.

Par exemple, reprenons le cas du diagnostic médical automatisé. Dans ce contexte, le contrôle devrait être transmis à des médecins humains lorsque la confiance du modèle de diagnostic de maladies est faible.

Plus précisément, un réseau devrait fournir une mesure de confiance calibrée en plus de sa prédiction. En d'autres termes, la probabilité associée à l'étiquette de classe prédite devrait refléter sa vraisemblance de correction réelle.

Et ce n'est pas seulement une question de communiquer la vraie confiance. Des estimations de confiance calibrées sont également cruciales pour l'interprétabilité du modèle.

Les humains ont une intuition cognitive naturelle pour les probabilités. De bonnes estimations de confiance fournissent une information supplémentaire précieuse pour établir la confiance avec l'utilisateur — en particulier pour les réseaux de neurones, dont les décisions de classification sont souvent difficiles à interpréter.

Mais si on n'a aucun moyen de vraiment comprendre la confiance du modèle, alors une prédiction correcte et une supposition peuvent sembler identiques.

Enfin, dans de nombreux systèmes de Machine Learning complexes, les modèles dépendent les uns des autres et peuvent aussi interagir entre eux. Les classifieurs individuels sont souvent des entrées pour des systèmes plus larges qui prennent les décisions finales.

Si les modèles sont calibrés, cela simplifie les interactions. La calibration permet à chaque modèle de se concentrer sur l'estimation de ses probabilités particulières du mieux possible. Et puisque l'interprétation est stable, les autres composants du système n'ont pas besoin d'ajustements lorsque les modèles changent.

Les diagrammes de fiabilité

Les diagrammes de fiabilité (Reliability Diagrams sont un moyen visuel d'inspecter à quel point le modèle est actuellement calibré. Plus précisément, ce diagramme trace la précision empirique attendue en fonction de la valeur de confiance correspondante (sortie softmax) du modèle.

Si le modèle est parfaitement calibré, le diagramme doit tracer la fonction identité comme représenté ci-dessus.

Pour estimer la précision attendue, on regroupe les prédictions en M bins d'intervalle, chacun de taille 1/M (comme indiqué ci-dessus), et on calcule la précision de chaque bin.

Soit Bₘ l'ensemble des instances dont les valeurs de confiance tombent dans l'intervalle correspondant. Alors, la précision du modèle pour ces prédictions est donnée par :

• où ŷᵢ est la classe prédite pour l'échantillon i

• yᵢ est la vraie étiquette de classe pour l'échantillon i

Ensuite, on peut définir la confiance moyenne au sein du bin Bₘ comme suit :

• où p̂ᵢ est la confiance donnée par le modèle pour l'échantillon i

Intuitivement, pour un modèle parfaitement calibré, on aura accuracy(Bₘ) = confidence(Bₘ) pour tout m ∈ {1, 2, ..., M}.

L'Erreur de Calibration Attendue (ECE)

Les diagrammes de fiabilité sont un outil extrêmement utile pour évaluer visuellement si un modèle est bien calibré ou non. Ils permettent même d'identifier les valeurs de confiance spécifiques pour lesquelles le modèle sous-estime ou surestime, et on peut alors inspecter ces instances si nécessaire.

Cela dit, il est souvent utile de calculer une valeur scalaire qui mesure l'ampleur de la miscalibration.

Une façon d'approximer l'erreur de calibration attendue est de partitionner les prédictions en M bins équidistants (similaire aux diagrammes de fiabilité ci-dessus) et de prendre une moyenne pondérée de la différence précision/confiance des bins. Cela est noté ci-dessous :

• où n est le nombre total d'échantillons

• |Bₘ| est la taille de l'ensemble des instances dont la confiance tombe dans l'intervalle divisé

Pour plus de détails sur l'ECE, tu peux lire la partie 1 :

Calibration des modèles (Partie 1) : tes réseaux de neurones sont-ils trop sûrs d'eux ?

Découvre pourquoi tes réseaux de neurones sont mal calibrés : comprends le paradoxe des modèles modernes et apprends à mesurer leur certitude réelle en production.

Méthodes de calibration

Dans cette section, nous allons discuter de certaines méthodes de post-traitement qui nous aident à produire des probabilités calibrées.

Pour ce faire, chaque méthode nécessite un ensemble de validation hold-out qui, en pratique, peut être le même ensemble utilisé pour le réglage des hyperparamètres lors de l'entraînement du modèle.

Modèles de classification binaire

Commençons par discuter de la calibration dans le cas binaire (yᵢ ∈ {0, 1}).

La mise à l'échelle des variables (feature scaling) et la standardisation sont deux méthodes courantes pour modifier la plage de valeurs d'une variable.

Par exemple :

• Le MinMaxScaler ramène la plage de valeurs d'une variable à [0, 1] :

• La Standardisation fait en sorte que la moyenne de la variable soit de 0 et son écart-type de 1 :

Comme tu le sais peut-être déjà, ces opérations sont nécessaires car :

• Elles empêchent une variable spécifique d'influencer de manière disproportionnée la sortie du modèle.

• Elles rendent le modèle plus robuste face aux grandes variations dans les données.

Par exemple, dans l'image ci-dessous, l'échelle de la variable "revenu" pourrait impacter massivement la prédiction globale.

Mettre à l'échelle (ou standardiser) les données sur une plage similaire permet d'atténuer ce problème et d'améliorer les performances du modèle.

D'ailleurs, l'image suivante (tirée d'un de mes précédents shots data) le confirme précisément :

Comme illustré ci-dessus, le feature scaling est nécessaire pour optimiser les performances de nombreux modèles ML.

Mais bien que l'importance de ces techniques soit claire et reconnue, je vois souvent des personnes les interpréter à tort comme des solutions pour éliminer l'asymétrie (skewness).

Contrairement à cette croyance populaire, la mise à l’échelle (scaling) et la standardisation ne modifient JAMAIS la distribution sous-jacente.

Ils se contentent d'altérer la plage des valeurs.

Ainsi, après un scaling (ou une standardisation) :

• Une distribution normale → reste normale

• Une distribution uniforme → reste uniforme

• Une distribution asymétrique (skewed) → reste asymétrique

• ...et ainsi de suite.

Nous pouvons d'ailleurs le vérifier avec les deux illustrations ci-dessous :

Il est clair que la mise à l'échelle et la standardisation n'ont aucun effet sur la forme de la distribution.

Rappelle-toi donc toujours de ceci : si ton objectif est de corriger l'asymétrie (skewness), le scaling ou la standardisation ne t’aideront jamais.

Essaye plutôt les transformations de variables (feature transformations).

Il en existe beaucoup, mais les plus couramment utilisées sont :

• La transformation logarithmique (Log transform)

• La transformation racine carrée (Sqrt transform)

• La transformation de Box-Cox

Leur efficacité est évidente sur l'image ci-dessous :

Comme on le voit ici, l'application de ces opérations transforme les données asymétriques en une variable (plus ou moins) normalement distribuée.

Avant de conclure, note que bien que la transformation logarithmique soit couramment utilisée pour éliminer l'asymétrie, ce n'est pas toujours la solution idéale.

Nous avons couvert ce sujet en détail ici :

4 mythes sur la transformation logarithmique en Data Science

Découvre les limites de la transformation logarithmique : quand et pourquoi elle ne corrige pas toujours l'asymétrie des données en statistiques.

Et si tu te demandes pourquoi nous avons converti ces données asymétriques en une distribution normale, et quel en était le but, jette un œil à ce shot data :

11 méthodes pour tester la normalité d’une distribution

Découvre les 11 méthodes essentielles pour tester la normalité d'une distribution en data science, des techniques visuelles aux tests statistiques.

👉 À toi de jouer : Quelles autres méthodes connais-tu pour éliminer l'asymétrie (skewness) ?

Tout le monde connaît le rôle d'une fonction d'activation dans un réseau de neurones : elle permet au modèle d'apprendre des relations non linéaires.

Rien de nouveau jusque-là, et je suis sûr que tu le savais déjà.

Cependant, j'ai souvent remarqué que beaucoup de personnes ont du mal à se représenter intuitivement ce qu'un réseau de neurones essaie réellement d'accomplir lors de ses transformations, couche après couche.

Aujourd'hui, laisse-moi te partager une perspective unique qui t’aidera vraiment à visualiser le fonctionnement interne d'un réseau de neurones.

Pour plus de clarté, nous prendrons l'exemple d'un cas de classification binaire.

C'est parti !

Le fonctionnement de base

Dans un réseau de neurones, les données ne sont jamais utilisées telles quelles : elles sont progressivement transformées à chaque couche cachée.

Concrètement, chaque couche applique toujours la même séquence d’opérations :

• une transformation linéaire des données issues de la couche précédente

• suivie d’une transformation non linéaire via une fonction d’activation (ReLU, sigmoïde, tanh, etc.)

Ces étapes sont répétées sur chaque couche cachée du réseau.

Mais il y a un point essentiel à bien comprendre.

Imaginons que les données viennent de traverser la toute dernière couche cachée.

À partir de là, elles sont envoyées vers la couche de sortie pour une dernière transformation… qui, elle, est entièrement linéaire.

Cette dernière étape est 100% linéaire car toutes les sources de non-linéarité (les fonctions d'activation) se trouvent au niveau de la dernière couche cachée, ou avant.

Ainsi, lors de la passe avant (forward pass), une fois que les données quittent la dernière couche cachée, il n'y a plus aucune place pour la non-linéarité.

Par conséquent, pour pouvoir générer des prédictions précises, les données reçues par la couche de sortie DOIVENT ÊTRE linéairement séparables.

L’idée clé à retenir…

En transformant les données à travers toutes ses couches cachées, et juste avant d'atteindre la couche de sortie, le but ultime d'un réseau de neurones est de projeter les données dans un espace où elles deviennent linéairement séparables.

Si cet objectif est atteint, alors la couche de sortie peut faire son travail très facilement — un peu comme une simple régression logistique qui trace une frontière de décision.

On peut même observer ce phénomène en pratique.

Pour cela, on ajoute une couche cachée “factice” avec seulement deux neurones juste avant la sortie, puis on entraîne le réseau.

Pourquoi une couche avec seulement deux neurones ?

Parce que cela nous permet de visualiser les activations en 2D !

Si tout se passe comme prévu, les activations de cette couche devraient être linéairement séparables.

C'est exactement ce que montre le visuel ci-dessous :

Comme on peut le voir, bien que les données d'entrée d'origine n'étaient pas linéairement séparables (à gauche), les données transformées et reçues par la couche de sortie le sont bel et bien (à droite).

Le réseau a donc “remodelé” l’espace des données pour simplifier au maximum le travail de la couche finale.

En résumé…

Un réseau de neurones ne fait rien de magique : il apprend simplement à tordre et transformer l’espace des données jusqu’à ce qu’une séparation linéaire devienne possible juste avant la sortie.

👉 À toi de jouer : ici, on parlait de classification binaire. À ton avis, dans un problème de régression, que cherche à faire le réseau avec les données juste avant la couche de sortie ?

Le problème

Les architectures de réseaux de neurones que nous concevons aujourd'hui sont indéniablement beaucoup plus précises qu'elles ne l'ont jamais été dans toute leur histoire.

Cependant, de nombreuses expériences ont révélé que les réseaux de neurones modernes ne sont plus bien calibrés.

Pour faire simple, un modèle est parfaitement calibré si les probabilités de prédiction correspondent étroitement aux résultats réels. Si un modèle prédit un événement avec une probabilité de 70 %, alors idéalement, sur 100 prédictions de ce type, l'événement devrait se produire environ 70 fois.

Par exemple, supposons que sur plusieurs jours (consécutifs ou non), un modèle ait prédit 50 % de chances de pluie. Pour mesurer si ces prédictions sont bien calibrées, il faudrait calculer à quelle fréquence il a réellement plu.

Si, sur le long terme, il a effectivement plu environ 50 % du temps, cela signifie que les prédictions (ou prévisions) du modèle étaient bien calibrées. En revanche, s'il n'a plu que 25 % ou, disons, 70 % du temps, le modèle était mal calibré.

Bien que la calibration semble être une propriété évidente, et peut-être même triviale, que tous les réseaux devraient implicitement posséder, de nombreuses études ont montré que les réseaux de neurones modernes semblent avoir perdu cette capacité. Par conséquent, ils ont tendance à être trop confiants (sur-confiants) dans leurs prédictions.

Par exemple, observons le graphique suivant, qui compare un modèle LeNet (développé en 1998) avec un modèle ResNet (développé en 2016) sur le jeu de données CIFAR-100.

Sur ce graphique, la confiance (confidence) moyenne est déterminée en utilisant l'étiquette (label) ayant la probabilité softmax la plus élevée, sur l'ensemble des échantillons du dataset

D'après le graphique ci-dessus, il est clair que :

• La confiance moyenne de LeNet (l'ancien modèle) correspond étroitement à son exactitude (accuracy).

• À l'inverse, la confiance moyenne du ResNet (le modèle plus moderne) est nettement supérieure à son exactitude.

Ainsi, nous pouvons constater que le modèle LeNet est bien calibré, car sa confiance s'aligne presque parfaitement sur l'exactitude attendue. En revanche, bien que l'exactitude du ResNet soit meilleure (0,7 > 0,5), celle-ci ne correspond pas du tout à son niveau de confiance.

Autrement dit, cela signifie que le modèle ResNet, bien qu'il soit globalement plus performant, est trop confiant dans ses prédictions. Alors que la confiance moyenne de LeNet s'aligne bien sur ses performances réelles (indiquant une bonne calibration), la confiance excessive de ResNet montre qu'il prédit souvent des résultats avec une certitude bien plus grande que ce qui est justifié.

Pourquoi la calibration est-elle importante ?

Une question qui revient souvent à ce stade est la suivante :

La motivation est assez similaire à celle que nous avons abordée dans notre exploration approfondie sur la prédiction conforme, disponible ici :

Maîtriser l'incertitude en Machine Learning avec la Prédiction Conforme

Maîtrise l'incertitude en Machine Learning avec la Prédiction Conforme : construis des intervalles de confiance robustes et déploie tes modèles en toute sécurité.

Faire aveuglément confiance aux prédictions d'un modèle ML peut parfois être fatal, surtout dans des environnements à enjeux élevés où les décisions fondées sur ces algorithmes peuvent affecter des vies humaines, la stabilité financière ou des infrastructures critiques.

Bien qu'une précision de "95 %" soit excellente sur le papier, le modèle ne te dira jamais quelles sont les 5 % de prédictions incorrectes lorsqu'il sera utilisé en production sur de nouvelles tâches.

En d'autres termes, bien que nous sachions que les prédictions du modèle sont globalement correctes un certain pourcentage du temps, le modèle ne peut généralement pas nous dire grand-chose sur la fiabilité d'une prédiction spécifique.

Par conséquent, dans des situations à haut risque comme les diagnostics médicaux, faire aveuglément confiance à chaque prédiction peut avoir de graves conséquences.

Pour atténuer ces risques, il est donc essentiel de ne pas s'appuyer uniquement sur la prédiction brute, mais aussi de comprendre et de quantifier l'incertitude qui y est associée.

Mais étant donné que les modèles modernes se révèlent souvent trop confiants dans leurs prédictions (comme nous l'avons vu plus haut), il est crucial de s'assurer que notre modèle ne fait pas partie du lot.

Une telle sur-confiance pose problème, particulièrement dans les applications où les probabilités prédites sont utilisées pour prendre des décisions critiques.

Reprenons l'exemple du diagnostic médical automatisé. Dans un tel cas, le contrôle devrait être transféré à des médecins humains lorsque la confiance d'un réseau diagnostiquant une maladie est jugée trop faible.

Plus précisément, un réseau devrait fournir une mesure de confiance calibrée en plus de sa prédiction. Autrement dit, la probabilité associée à la classe prédite devrait refléter sa probabilité réelle d'être correcte.

Et il ne s'agit pas seulement de communiquer la véritable confiance. Des estimations de confiance calibrées sont également cruciales pour l'interprétabilité du modèle.

Les humains ont une intuition cognitive naturelle face aux probabilités. De bonnes estimations de confiance fournissent une information supplémentaire précieuse pour instaurer un climat de confiance avec l'utilisateur – particulièrement avec les réseaux de neurones, dont les décisions de classification sont souvent difficiles à interpréter.

Si nous n'avons aucun moyen de véritablement comprendre la confiance d'un modèle, alors une prédiction exacte et une simple supposition aléatoire peuvent sembler identiques.

Enfin, dans de nombreux systèmes complexes, les modèles de machine learning dépendent les uns des autres et interagissent entre eux. Des classifieurs individuels servent souvent de données d'entrée (inputs) à des systèmes plus vastes qui prennent les décisions finales.

Si les modèles sont calibrés, cela simplifie considérablement ces interactions. La calibration permet à chaque modèle de se concentrer sur l'estimation la plus précise possible de ses propres probabilités. Et comme l'interprétation reste stable, les autres composants du système n'ont pas besoin d'être modifiés à chaque fois que les modèles changent.

En aparté, la calibration de modèle peut également fonctionner au niveau conditionnel. Par exemple, dans notre précédent cas de prévisions météorologiques, nous n'avons mesuré la calibration qu'en fonction de la probabilité prédite par le modèle et de la confirmation (ou non) de cette probabilité sur le long terme dans la réalité. C'est ce qui est illustré ci-dessous :

Cependant, un modèle calibré pourrait aussi impliquer des probabilités conditionnelles.

Autrement dit, alors que le modèle ci-dessus prédisait la pluie pour un jour précis de manière isolée, il est logique de s'attendre à ce que la probabilité de pluie soit généralement plus élevée s'il a également plu la veille.

Ainsi, un modèle qui prend en compte la météo de la veille et prédit Pr(Pluie|Pluie_Hier = 1 ) = 0.7 et Pr(Pluie|Pluie_Hier = 0 ) = 0.3 peut être un modèle parfaitement calibré (et bien plus utile), à condition que ces probabilités correspondent aux observations réelles.

Revenons à notre sujet...

L'objectif de ce mini-cours en deux parties est multiple :

1. Comprendre pourquoi les réseaux de neurones actuels sont devenus plus mal calibrés que ceux produits il y a des années.

2. Formuler le concept exact de la mauvaise calibration (dé-calibration) des modèles.

3. Définir des techniques pour mesurer l'étendue de cette mauvaise calibration.

4. Découvrir les méthodes qui peuvent nous aider à la réduire, voire à l'éliminer.

5. Et bien plus encore.

En plus de cela, nous partagerons également quelques perspectives et intuitions sur les techniques d'entraînement et les architectures qui peuvent être à l'origine de ce défaut de calibration.

Définir la calibration

Avant toute chose, définissons la calibration en termes mathématiques simples.

Pour commencer, considérons une tâche de classification multiclasse supervisée :

Ceci est modélisé à l'aide d'un réseau de neurones qui produit la probabilité que la sortie soit correcte (il ne s'agit pas de vraies probabilités, mais de probabilités estimées par le modèle) :

• Ŷ est la classe prédite.

• P̂ est la confiance correspondante (via la fonction softmax).

Le but, comme discuté précédemment, est de s'assurer que l'estimation de confiance P̂ est calibrée, ce qui signifie que P̂ représente une probabilité réelle de l'événement.

En d'autres termes, si le modèle a prédit P̂ = 0,75 sur 100 prédictions, on s'attend à ce qu'environ 75 de ces prédictions soient correctement classifiées.

Ainsi, nous pouvons définir une calibration parfaite de la manière suivante :

Cette définition signifie que pour un modèle parfaitement calibré, la probabilité que l'étiquette prédite Ŷ corresponde à la vraie étiquette Y, sachant que la probabilité prédite par le modèle est p, doit être exactement égale à p.

En d'autres termes, la probabilité prédite p doit correspondre directement à la fréquence réelle des prédictions correctes. Si le modèle prédit 75 % de chances qu'un événement se produise, celui-ci devrait effectivement se produire 75 % du temps sur le long terme.

Ce concept peut être visualisé à l'aide de diagrammes de fiabilité ou de graphiques de calibration.

Les diagrammes de fiabilité

Les diagrammes de fiabilité sont un moyen visuel d'inspecter le niveau de calibration actuel d'un modèle. Plus précisément, ce diagramme trace l'exactitude (accuracy) attendue de l'échantillon en fonction de la valeur de confiance correspondante (softmax) produite par le modèle.

Si le modèle est parfaitement calibré, le diagramme devrait tracer la fonction identité (une diagonale parfaite), comme illustré ci-dessus.

Tout écart par rapport à cette diagonale parfaite représente un défaut de calibration, comme illustré ci-dessous :

Lors du développement d'un modèle, l'une des techniques que beaucoup n'expérimentent pas est la discrétisation des variables (ou feature discretization). Comme son nom l'indique, l'idée est de transformer une variable continue en plusieurs variables discrètes.

Pourquoi, quand et comment ferait-on cela ?

C'est ce que nous allons voir aujourd'hui.

Pourquoi utiliser la discrétisation ?

Ma logique pour utiliser la discrétisation a presque toujours été très simple : "Il est tout simplement plus logique de discrétiser cette variable."

Par exemple, supposons que ton dataset contienne une variable représentant l'âge :

Dans de nombreux cas d'usage, comme l'analyse des comportements de dépense basés sur l'historique des transactions, ces variables continues sont bien plus faciles à interpréter lorsqu'elles sont découpées en groupes significatifs → les jeunes, les adultes et les seniors.

Imaginons que nous modélisions ce jeu de données de transactions sans discrétisation.

Cela produirait des coefficients pour chaque variable, nous indiquant l'influence de chacune sur la prédiction finale.

Mais en y repensant, dans notre objectif de comprendre les habitudes de dépense, sommes-nous vraiment intéressés par la corrélation entre l'âge exact et la dépense ? 

Cela n'a pas beaucoup de sens.

Il est bien plus pertinent d'apprendre la corrélation entre différents groupes d'âge et les dépenses.

Par conséquent, discrétiser la variable d'âge peut potentiellement révéler des insights bien plus précieux que de l'utiliser à l'état brut.

Les 2 techniques de discrétisation les plus courantes

Maintenant que nous comprenons le principe, il existe 2 techniques qui sont largement privilégiées.

La première méthode consiste à découper la variable en intervalles de taille égale (binning).

Tous les intervalles (bins) ont la même largeur

Une autre technique consiste à découper la variable en intervalles à fréquence égale (contenant le même nombre d'observations) :

La largeur de chaque intervalle peut être différente dans ce cas

Ensuite, ces valeurs discrètes sont encodées en one-hot (encodage disjonctif complet).

L'un des grands avantages de la discrétisation est qu'elle permet d'introduire un comportement non linéaire, même si le modèle sous-jacent est linéaire.

Cela peut potentiellement conduire à une meilleure précision, comme le montre l'image ci-dessous :

Un modèle linéaire couplé à la discrétisation des variables produit :

• une frontière de décision non linéaire.

• une meilleure précision (accuracy) sur l’ensemble de test.

Ainsi, d'une certaine manière, nous conservons la simplicité d'un modèle linéaire tout en capturant des relations plus complexes et non linéaires dans les données.

Simple et efficace, non ?

La discrétisation des variables continues présente aussi un autre avantage clé : elle améliore le ratio signal/bruit.

Concrètement, le “signal” correspond à l’information réellement utile dans les données, celle qui permet de prendre de bonnes décisions.

En regroupant une variable en intervalles, on réduit l’impact des petites variations souvent aléatoires — autrement dit, du bruit — pour mieux faire ressortir les tendances importantes.

Chaque intervalle agit comme un moyen de "lisser" le bruit au sein de segments de données spécifiques.

Le mot de la fin

Avant de conclure, garde un point important en tête : la discrétisation, combinée au one-hot encoding, augmente le nombre de variables… et donc la dimensionnalité de tes données.

Or, plus le nombre de dimensions est élevé, plus il devient facile pour un modèle de séparer les données de manière linéaire. Par conséquent, cela peut favoriser le surapprentissage (overfitting).

La clé, c’est donc la modération. Inutile de discrétiser toutes tes variables systématiquement. 

Privilégie les cas où cela fait réellement sens, comme on l’a vu précédemment.

Dans la pratique, son intérêt dépend beaucoup du contexte. Mais avec l’expérience, certains cas reviennent souvent :

• Les données géospatiales (latitude, longitude), où regrouper par zones peut être très efficace.

• Les variables comme l’âge ou le poids, qui se prêtent naturellement à des catégories.

• Les variables bornées (revenus, épargne…), pour lesquelles raisonner par tranches est souvent plus pertinent que valeur brute.

👉 À toi de jouer : selon toi, quels autres points de vigilance faut-il avoir en tête lorsqu’on utilise la discrétisation des variables ?

Le shot data d'aujourd'hui est le dernier de notre série en trois parties sur la détection du covariate shift (décalage de covariables) multivarié.

Lis les deux premières éditions ici si tu les as loupés :

• Partie 1 : Le Covariate Shift est bien plus problématique que la plupart des gens ne le pensent.

• Partie 2 : Comment détecter un Covariate Shift multivarié dans les modèles de Machine Learning ?

La semaine dernière, nous avons abordé une technique intéressante pour détecter le covariate shift multivarié dans les modèles de ML.

Pour rappel, l’approche repose sur la reconstruction des données : on apprend une transformation qui projette les données d’entraînement dans un espace de dimension réduite, avant de tenter de reconstruire les données originales à partir de cette représentation compacte.

La reconstruction de données vise à reconstituer les données d'origine après projection

Les autoencodeurs peuvent être utilisés ici :

Utilisation des Autoencodeurs pour la reconstruction de données

Ce sont des réseaux de neurones qui apprennent à encoder des données dans un espace de dimension inférieure, puis à les décoder pour retrouver les données d'origine.

Comment utiliser ce modèle pour détecter un covariate shift ?

Imaginons que nous avons déployé notre modèle et qu'il génère des prédictions sur de nouvelles données.

Prédictions sur de nouvelles données

Dans un premier temps, nous pouvons entraîner un autoencodeur (ou d'autres modèles de reconstruction de données adaptés) sur les données d'entraînement.

Utilisation d'autoencodeurs pour la reconstruction de données

Ainsi, l'autoencodeur capturera l'essence de nos données d'entraînement et de leur distribution.

Ensuite, au fur et à mesure que de nouvelles données arrivent et que le modèle effectue des prédictions, nous pouvons évaluer périodiquement le changement de distribution des données en calculant l'erreur de reconstruction (reconstruction loss) sur ces nouvelles données à l'aide de l'autoencodeur :

• Si l'erreur de reconstruction est élevée, cela indique que la distribution a changé.

• Si l'erreur de reconstruction est faible, cela indique que la distribution est restée presque identique.

Mais la question est : « Comment interpréter cette erreur de reconstruction ? »

Par exemple, si la perte de reconstruction est de 0.4, comment déterminer si c'est significatif ?

Nous avons besoin de plus de contexte.

Voyons comment nous pouvons résoudre ce problème.

Le Contexte

Contrairement à ce que beaucoup pensent, le covariate shift se produit de manière graduelle dans les modèles de ML.

En d'autres termes, il est peu probable que notre modèle soit très performant un jour, et que le lendemain, il commence soudainement à sous-performer.

En revanche, la dégradation des performances due au covariate shift se fait progressivement.

Et durant cette phase de dégradation, nous devons à un moment donné décider de mettre à jour le modèle pour l'ajuster à ces changements de distribution.

Bien que l'erreur de reconstruction soit utile pour décider des mises à jour du modèle, elle n'a que très peu de sens en soi.

En termes simples, nous avons besoin d'une perte de reconstruction de base pour la comparer à nos futures erreurs de reconstruction.

Voici donc ce que nous pouvons faire.

Disons que nous décidons d'évaluer notre modèle chaque semaine.

Après avoir entraîné le modèle sur les données collectées :

• Nous déterminons notre score de reconstruction de référence (baseline) à l'aide des nouvelles données collectées au cours de la première semaine de la phase post-entraînement.

• Nous utilisons ce score de référence pour le comparer aux erreurs futures de chaque semaine suivante.

Une différence importante entre l'erreur de reconstruction observée et le score de référence indiquera un covariate shift.

Plutôt simple et intuitif, non ?

Cette métrique de reconstruction, couplée aux performances du modèle, devient un moyen fiable de déterminer si un covariate shift s'est installé.

Bien sûr, comme nous l'avons évoqué la semaine dernière les vraies étiquettes (true labels) ne sont parfois pas immédiatement disponibles.

Il peut donc être difficile d'évaluer les performances en production.

Pour pallier cela, toutes les équipes ML s'efforcent de recueillir en continu les retours des utilisateurs finaux afin de savoir si le modèle a bien performé ou non.

On l'observe particulièrement dans les systèmes de recommandation :

• Cette publicité était-elle pertinente pour vous ?

• Cette nouvelle vidéo t’a-t-elle intéressé ?

• Etc.

Ces éléments font partie de la phase de logging du modèle, où nous suivons ses performances en production.

Cela nous aide à décider si nous devons mettre à jour notre modèle ou non.

Cependant, les mises à jour de modèles ne se résument pas à : « Entraîner un nouveau modèle aujourd'hui et supprimer le précédent. » 

Jamais !

Au contraire, tous les déploiements sont gérés par un système rigoureux de contrôle de version.

J'ai écrit plusieurs mini-cours sur le contrôle de version des déploiements, que tu peux lire ensuite pour acquérir cette compétence ML cruciale dans le monde professionnel :

• Tu ne peux pas construire de grands projets data tant que tu n’as pas appris le Data Version Control (DVC) !

• Compression de modèles : une étape critique vers un Machine Learning efficace

👉 À toi de jouer : Quelles sont les autres méthodes pour détecter un covariate shift dans les modèles de ML ? Dis-le-moi en commentaire :)

Le problème

Faire aveuglément confiance aux prédictions d'un modèle ML peut parfois s'avérer fatal, en particulier dans des environnements à forts enjeux où les décisions basées sur ces prédictions peuvent affecter des vies humaines, la stabilité financière ou des infrastructures critiques.

Bien qu'une précision de "95%" soit rassurante sur le papier, le modèle ne te dira jamais quels sont les 5% de prédictions spécifiques qui sont incorrectes lorsqu'il est utilisé dans des tâches en aval.

Autrement dit, même si nous savons que les prédictions du modèle sont globalement correctes un certain pourcentage du temps, le modèle est généralement incapable de nous en dire beaucoup sur une prédiction spécifique.

Par conséquent, dans des situations à haut risque comme les diagnostics médicaux, faire aveuglément confiance à chaque prédiction peut avoir des conséquences graves sur la santé du patient.

De même, en finance, une seule prédiction erronée pourrait entraîner des pertes monétaires substantielles ou des stratégies d'investissement malavisées.

Ainsi, pour atténuer ces risques, il est essentiel de ne pas se fier uniquement aux prédictions brutes, mais aussi de comprendre et de quantifier l'incertitude qui y est associée.

Si nous n'avons aucun moyen d'évaluer la confiance du modèle, alors une prédiction très précise et une simple devinette peuvent sembler identiques.

Développons un peu plus cette idée et voyons pourquoi nous avons besoin d'intervalles de prédiction pour des modèles complexes comme les réseaux de neurones.

Pour commencer, nous savons que ces modèles seront très probablement utilisés dans des processus de prise de décision en aval.

Par exemple, si tu es médecin et que tu reçois l'analyse d'une IRM, une sortie du modèle suggérant que la personne est en bonne santé et n'a besoin d'aucun traitement ne te sera probablement pas d'une grande utilité.

C'est parce que le travail d'un médecin consiste à poser un diagnostic différentiel. Ainsi, ce qui l'intéresse vraiment, c'est de savoir s'il y a 10% de chances que cette personne ait un cancer, en se basant sur cette IRM.

Une autre chose bien plus utile serait d'obtenir un ensemble de prédictions, c'est-à-dire un groupe de diagnostics garantis avec une forte probabilité.

Par exemple, cet ensemble de prédictions pourrait indiquer qu'il y a 90% de probabilité que le véritable diagnostic soit contenu dans cet ensemble.

Si la sortie se présente sous cette forme, le médecin peut l'intégrer dans son processus clinique et écarter méthodiquement certains diagnostics.

La solution

Les prédictions conformes, également connues sous le nom d'inférence conforme, fournissent un cadre pour générer des intervalles ou des ensembles de prédictions assortis de solides garanties statistiques.

Ce qui distingue la prédiction conforme, c'est sa nature indépendante de la distribution, ce qui signifie qu'elle ne repose sur aucune hypothèse concernant la distribution sous-jacente des données ou le modèle spécifique utilisé.

De plus, elle ne nécessite aucun entraînement supplémentaire. L'ensemble du modèle peut être considéré comme une boîte noire et tout de même être utilisé pour formuler des prédictions conformes.

Grâce à cette caractéristique, l'intégration de la prédiction conforme à n'importe quel modèle de Machine Learning pré-entraîné permet aux praticiens de transformer des prédictions ponctuelles en intervalles ou en ensembles qui sont (presque) garantis de contenir le véritable résultat avec une probabilité définie par l'utilisateur.

Par exemple, dans une tâche de classification comme un diagnostic médical, l'approche traditionnelle produirait une seule étiquette de classe. Cette prédiction ponctuelle ne laisse aucune place pour évaluer la confiance dans la prédiction ou pour envisager d'autres diagnostics plausibles.

À l'inverse, une approche de prédiction conforme générera un ensemble de diagnostics possibles, garantissant que le diagnostic correct est inclus dans cet ensemble avec un niveau de confiance spécifié, tel que 95%.

Par exemple, au lieu de prédire simplement la "maladie A" avec une probabilité de 95%, un prédicteur conforme pourrait renvoyer un ensemble incluant la "maladie A" et la "maladie B", garantissant que le bon diagnostic se trouve dans cet ensemble 95% du temps.

Ce n'est pas grave si tout n'est pas encore parfaitement clair pour toi, car nous allons détailler tout cela dans la section suivante.

Plus spécifiquement, dans les sections suivantes :

• Nous explorerons les fondements théoriques de la prédiction conforme, en détaillant comment elle obtient ses garanties indépendantes de la distribution et pourquoi elle est si efficace pour quantifier l'incertitude.

• Nous nous plongerons également dans des applications pratiques, en démontrant comment implémenter la prédiction conforme dans diverses tâches de Machine Learning, comme la classification.

Commençons !

Prédiction Conforme

Prenons un exemple : nous avons un dataset d'images classifiées en K catégories :

Dans les prédictions conformes, un nouvel ensemble, appelé "ensemble de calibration", est extrait des données d'entraînement. Il n'est pas nécessaire qu'il soit très grand. Par exemple, dans le cas d'un dataset de 60 000 images, il serait tout à fait acceptable d'isoler seulement 500 à 750 images pour constituer cet ensemble de calibration :

La taille relative de l'ensemble de calibration par rapport à l'ensemble d'entraînement sur cette image ne correspond pas au ratio réel. C'est uniquement à des fins de démonstration.

Pour faire simple, imagine également que nous avons déjà entraîné un modèle sur le jeu de données d'entraînement ci-dessus, disons un réseau de neurones :

Mathématiquement, ce modèle peut être noté de la manière suivante :

• f_y(x) désigne la probabilité prédite par le modèle que la variable cible Y prenne la valeur y (y pouvant être n'importe quelle valeur parmi les étiquettes de classe ci-dessus) pour une entrée spécifique X = x.

• P[Y = y|X = x] représente la véritable probabilité conditionnelle de Y = y sachant X = x.

Ainsi, f_y(x) est l'approximation par le modèle de la véritable probabilité conditionnelle sous-jacente P[Y = y|X = x]. L'objectif du modèle est d'estimer cette probabilité avec précision, permettant ainsi des prédictions fiables et une quantification de l'incertitude.

Une fois le modèle entraîné, notre but est de prendre un nouvel exemple quelconque X' (disons que le modèle est utilisé dans une application en aval, l'étiquette est donc inconnue) et de générer un ensemble de prédictions ϕ(X′) de telle sorte qu'il contienne la véritable classe Y' avec une forte probabilité.

Les nuages de points (scatter plots), les diagrammes en barres, les courbes, les boîtes à moustaches (box plots) et les cartes de chaleur (heatmaps) sont les graphiques les plus fréquemment utilisés pour la visualisation de données.

Bien qu'ils soient simples et connus de presque tout le monde, je pense qu'ils ne constituent pas toujours le meilleur choix pour couvrir tous les scénarios possibles.

En réalité, de nombreux autres graphiques dérivés de ces formats standards peuvent s'avérer bien plus adaptés s'ils sont utilisés judicieusement.

C'est pourquoi, aujourd'hui, nous allons aborder quelques alternatives à ces graphiques populaires.

J'expliquerai également dans quelles situations spécifiques ils peuvent s'avérer plus utiles que les graphiques standards.

Commençons !

#1) Cartes de chaleur avec encodage par la taille

Une carte de chaleur traditionnelle représente les valeurs à l'aide d'une échelle de couleurs. Cependant, associer mentalement la couleur d'une cellule à un nombre exact reste difficile.

Intégrer une composante de taille aux cartes de chaleur peut s'avérer extrêmement utile dans ces cas-là. 

En résumé, plus la taille est grande, plus la valeur absolue est élevée :

Tes Heatmaps sont illisibles ? L'astuce qui change tout.

Découvre une astuce simple pour enrichir tes heatmaps avec une composante de taille. Rends tes analyses plus claires en filtrant visuellement le bruit.

C'est particulièrement utile pour rendre les cartes de chaleur plus lisibles, car de nombreuses valeurs proches de zéro vont visuellement rétrécir et s'effacer.

#2) Graphiques en cascade

Pour visualiser l'évolution d'une valeur au fil du temps, un graphique en courbes (ou en barres) n'est pas toujours le choix le plus judicieux.

Cela s'explique par le fait qu'un graphique en courbes (ou en barres) représente les valeurs absolues. Il est donc difficile d'estimer visuellement l'ampleur et la direction des changements incrémentaux.

À la place, tu peux utiliser un graphique en cascade (waterfall chart).

Il illustre de manière élégante ces différences cumulées, comme on le voit ci-dessous :

Diagrammes en cascade : Une meilleure alternative au tracé linéaire

Visualise tes données avec les diagrammes en cascade : une alternative élégante au tracé linéaire pour représenter les changements progressifs en Python avec waterfall_chart.

Ici, les valeurs initiale et finale sont représentées par la première et la dernière barre.

De plus, les variations consécutives sont automatiquement codées par couleur, ce qui les rend beaucoup plus faciles à interpréter.

#3) Graphiques d'évolution des rangs

Lorsqu'il s'agit de visualiser l'évolution du classement de plusieurs catégories au fil du temps, l'utilisation d'un diagramme en barres n'est pas forcément appropriée.

En effet, les diagrammes en barres deviennent rapidement illisibles lorsqu'il y a de nombreuses catégories.

Essaye plutôt les Bump Charts. Ils sont spécifiquement conçus pour visualiser l'évolution du rang de différents éléments dans le temps.

Visualiser l'évolution d'un classement ? Oublie les barres.

Ne te limite pas aux barres ! Découvre comment créer un Bump Chart (graphique d'évolution du classement) en Python pour visualiser les rangs dans le temps.

En comparant le diagramme en barres et le bump chart ci-dessus, il est beaucoup plus facile d'interpréter le changement de classement avec ce dernier.

#4) Graphiques en nuage de pluie

Visualiser la distribution de données à l'aide de boîtes à moustaches et d'histogrammes peut parfois s'avérer trompeur.

Cela pour deux raisons :

• Il est possible d'obtenir la même boîte à moustaches avec des données complètement différentes

• Modifier le nombre de classes (bins) change la forme d'un histogramme

Ainsi, pour éviter de tirer des conclusions erronées, il est toujours recommandé de tracer la distribution des données aussi précisément que possible.

Les Raincloud plots offrent un moyen concis de combiner et de visualiser trois types de graphiques différents en un seul.

Ceux-ci incluent :

• Les boîtes à moustaches (box plots) pour les statistiques de base.

• Les graphiques en bandes (strip plots) pour un aperçu global des points de données.

• Les graphiques d'estimation de densité (KDE plots) pour la distribution de probabilité des données.

Raincloud plots : une visualisation à (re)découvrir

Découvre les raincloud plots, une technique de visualisation innovante qui combine trois graphiques pour une analyse de données plus claire et précise.

Avec les Raincloud plots, tu peux :

• Combiner plusieurs graphiques pour éviter les conclusions incorrectes ou trompeuses.

• Réduire l'encombrement visuel et améliorer la clarté.

• Améliorer les comparaisons entre différents groupes.

• Capturer différents aspects des données à travers un seul graphique.

#5-6) Graphiques à bacs hexagonaux et Graphiques de densité

Les nuages de points (scatter plots) peuvent devenir trop denses pour être interprétés lorsque tu as des milliers de points de données.

Tu peux alors les remplacer par des graphiques Hexbin.

Les graphiques hexagonaux divisent la zone du graphique en régions hexagonales. Une intensité de couleur est attribuée à chaque région en fonction de la méthode d'agrégation utilisée (le nombre de points, par exemple).

Les diagrammes à hexagones, une alternative plus riche aux diagrammes de dispersion

Les diagrammes à hexagones sont particulièrement utiles pour comprendre la dispersion des données. Ils divisent la zone d'un graphique en régions hexagonales.

Une autre option est le graphique de densité, qui illustre la distribution des points dans un espace bidimensionnel.

Le diagramme de densité, une alternative plus riche aux diagrammes de dispersion

Lorsqu'il y a des milliers de points de données, un diagramme de densité permet d'identifier les régions à forte et à faible densité.

Un contour est créé en reliant les points de densité égale. En d'autres termes, une seule ligne de contour représente une densité identique de points de données.

#7-8) Graphiques à bulles et Graphiques à points

Comme nous l'avons vu précédemment, les diagrammes en barres deviennent rapidement brouillons et surchargés à mesure que le nombre de catégories augmente.

Un graphique à bulles est souvent une meilleure alternative dans ces cas-là.

Ils ressemblent aux nuages de points, mais :

• avec un axe catégoriel

• et un axe continu

Tes diagrammes en barres sont illisibles ?

Remplace tes diagrammes en barres illisibles par des graphiques à bulles : une alternative élégante et claire pour visualiser efficacement des données catégorielles complexes.

Comme illustré ci-dessus :

• Il est difficile d'interpréter le diagramme en barres car il y a trop de barres entassées dans un espace restreint

• En revanche, les bulles encodées par la taille permettent de visualiser assez facilement l'évolution dans le temps

Une autre alternative aux diagrammes en barres dans ce genre de situation est le graphique à points (dot plot).

Diagramme à points : une alternative aux diagrammes à barres

Un diagramme à points peut être un meilleur choix dans de tels cas. Il s'agit d'un diagramme de dispersion, mais avec un axe catégoriel et un axe continu.

Les graphiques à points comme les graphiques à bulles reposent sur l'idée que, parfois, face à un diagramme comportant de nombreuses barres, nous ne prêtons pas vraiment attention à la longueur individuelle de chaque barre.

Nous regardons plutôt les extrémités qui indiquent la valeur totale.

Ces graphiques nous aident précisément à illustrer cela, tout en éliminant les longues barres qui n'ont que peu ou pas d'utilité.

👉 À toi de jouer : Y a-t-il d'autres graphiques méconnus mais précieux que je n'ai pas abordés ici ? Si oui, dans quels cas les utilises-tu ?

La régression linéaire part du principe mathématique que les résidus du modèle (c'est-à-dire la différence entre les valeurs réelles et les valeurs prédites) suivent une distribution normale.

Si ton modèle donne de mauvais résultats, c’est très souvent parce que cette hypothèse fondamentale n’est pas respectée.

Dans ce cas, j’ai souvent recours à un graphique de distribution des résidus pour vérifier ce point et juger de la fiabilité du modèle.

Comme son nom l’indique, ce graphique représente simplement la répartition des erreurs (Réel - Prédit), comme illustré ci-dessous :

Un bon graphique de résidus va :

• Se rapprocher d’une distribution normale (la fameuse forme en cloche)

• Ne montrer aucune tendance ni structure particulière dans les erreurs

À l’inverse, un mauvais graphique de résidus va :

• Présenter une forte asymétrie (skewness)

• Faire apparaître des motifs ou structures visibles dans la répartition des erreurs

Ainsi, plus la distribution des résidus se rapproche d’une loi normale, plus on peut avoir confiance dans la robustesse du modèle.

C’est d’autant plus utile lorsque la ligne de régression est impossible à visualiser (par exemple avec des données en haute dimension comportant de nombreuses variables).

Pourquoi ?

Parce qu’un graphique de distribution des résidus reflète l’erreur globale du modèle — il est donc toujours unidimensionnel.

Ainsi, il peut être généré et interprété très facilement d'un simple coup d'œil, quel que soit le niveau de complexité de tes données d'entrée.

Bien sûr, nous nous sommes ici limités à la validation d’une seule hypothèse : la normalité des résidus.

Or, la régression linéaire repose sur plusieurs autres hypothèses essentielles (linéarité, homoscédasticité, indépendance) qui doivent elles aussi être testées avec rigueur.

Pour cela, la bibliothèque Python statsmodels propose un rapport statistique particulièrement complet :

Si tu souhaites apprendre à interpréter ce rapport en détail, je t’invite à lire ce précédent shot data :

Statsmodels : arrête de faire semblant de comprendre le summary

Apprends à décoder un rapport de régression avec statsmodels : guide détaillé pour comprendre chaque section et interpréter les résultats comme un expert.

Et si tu veux comprendre l’origine de ces hypothèses mathématiques, je t’invite à découvrir cette analyse approfondie du Cercle des Experts :

Régression Linéaire : d'où viennent vraiment ses hypothèses ?

Démystifie les hypothèses cachées de la régression linéaire : comprends les conditions essentielles pour maîtriser cet algorithme fondamental en machine learning.

👉 À toi de jouer : Quelles autres méthodes ou quels graphiques utilises-tu pour évaluer les performances d’un modèle linéaire ?

Introduction

J’ai eu l’opportunité de travailler sur de nombreux projets de machine learning en conditions réelles — d’abord comme data scientist à plein temps, puis en tant qu’indépendant, où j’accompagnais des entreprises sur leurs projets data.

Construire des projets de data science de bout en bout — du nettoyage des données jusqu’au déploiement des modèles — m’a confronté à une multitude de pièges, de biais et de bonnes pratiques… que je n’ai quasiment jamais vus formalisés clairement.

Honnêtement, tout ce que je vais partager ici, ce sont des leçons que j’aurais aimé apprendre beaucoup plus tôt.

La bonne nouvelle, c’est que tu n’as pas besoin de passer par les mêmes erreurs.

Dans ce mini-cours, j’ai rassemblé 8 pièges que tu rencontreras très probablement, ainsi que les réflexes à adopter pour les éviter.

D’après mon expérience, ces pièges sont presque toujours présents — mais rarement visibles au premier coup d’œil. Et c’est précisément ce qui fait dérailler un grand nombre de projets.

Commençons !

1) Inspecter ses arbres de décision

Si l’on visualise les règles de décision (les conditions évaluées à chaque nœud) de n’importe quel arbre de décision, on constate qu’elles sont toujours perpendiculaires aux axes des features, comme ci‑dessous :

En d’autres termes, un arbre de décision segmente progressivement l’espace des features au moyen de frontières perpendiculaires pour séparer les données.

En soi, ce n’est pas un “problème”.

C’est même précisément cette manière de découper l’espace qui rend l’arbre de décision capable de sur‑apprendre à la perfection n’importe quel dataset (voir la section sur l’expérience d’overfitting pour plus de détails).

Mais cela soulève un point intéressant, souvent ignoré lorsqu’on ajuste des arbres de décision.

Plus précisément : que se passe‑t‑il si notre dataset est séparé par une frontière de décision diagonale, comme ci‑dessous ?

Il est alors assez intuitif de voir que la frontière de décision construite par un arbre prendra cette forme :

En visualisant cet arbre, on constate qu'il est contraint de multiplier les divisions pour s'adapter à un dataset pourtant très simple à séparer. À l'inverse, un algorithme comme la régression logistique, un SVM (Support Vector Machine) ou un réseau de neurones basique résoudrait ce problème de façon beaucoup plus élégante :

Cela devient encore plus évident si l’on zoome sur cet arbre et qu’on observe à quel point les seuils de split sont proches les uns des autres :

Et là, c’est un peu inquiétant : on voit clairement que l’arbre essaie laborieusement de mimer une frontière diagonale, ce qui laisse penser que ce n’est peut‑être pas le meilleur modèle pour ce problème.

Pour vérifier cette intuition, voici une méthode de diagnostic simple que j'utilise régulièrement : 

• Préparation : On part de notre jeu d'entraînement classique, avec la matrice de features X 

  • X de dimensions n × m)

  • la cible y (de dimension n × 1).

• Rotation de l'espace : On applique une Analyse en Composantes Principales (PCA) sur X. L'objectif ici n'est pas de réduire la dimension, mais de projeter les données dans un nouvel espace orthogonal. On obtient ainsi X_pca, qui conserve les mêmes dimensions (n × m).

• Modélisation et visualisation : On entraîne un nouvel arbre de décision sur ces données transformées (X_pca). Profitons du grand atout des arbres : leur interprétabilité visuelle ! On affiche donc le graphe de l'arbre obtenu.

• Diagnostic : Si la profondeur de ce nouvel arbre est drastiquement inférieure à celle de l'arbre initial, le diagnostic est confirmé : la frontière de décision était bien diagonale par rapport aux axes d'origine.

Par exemple, voici les projections PCA du dataset utilisé plus haut :

Il apparaît distinctement que, suite à la projection, la frontière de décision devient quasi orthogonale à la seconde composante principale (X2).

L'ajustement d'un arbre de décision sur la matrice X_pca s'en trouve alors grandement simplifié, ce qui se traduit par une réduction drastique de sa complexité et de sa profondeur.

L'illustration ci-dessous en témoigne :

Ce constat nous amène à une conclusion claire : face à de telles données, nous aurions tout intérêt à changer d'algorithme.

L'alternative serait d'investir du temps dans un feature engineering spécifique, afin de fournir à l'arbre des variables sur lesquelles il pourra appliquer ses découpes orthogonales efficacement.

Une question légitime se pose alors : pourquoi ne pas simplement déployer en production l'arbre entraîné sur X_pca ?

Si rien ne l'interdit techniquement, n'oublions pas le prix à payer : la perte d'interprétabilité. Les composantes principales étant des combinaisons linéaires abstraites, nous sacrifions le sens métier des variables d'origine, ce qui est souvent rédhibitoire en entreprise.

Le mot de la fin : Ne considère jamais un arbre de décision comme une boîte noire ; prends toujours le temps d'inspecter sa structure.

Mon but n'est évidemment pas de te dissuader de les utiliser — ils restent, après tout, les briques fondatrices des modèles ensemblistes les plus puissants du marché (Random Forest, XGBoost...).

L'objectif est plutôt d'apprendre à 'penser' comme l'algorithme, pour maîtriser ses limites géométriques et savoir exactement quand il est le bon outil pour le bon problème.

2) Séparation aléatoire des données

Dans quasiment tous les cours d’introduction au machine learning, on nous explique qu’il faut séparer les données de façon ALÉATOIRE en un ensemble d’entraînement et un ensemble de validation :

Le shot data de vendredi sur le covariate shift (décalage de covariables) a été très apprécié par beaucoup d'entre vous.

Si tu es nouveau ici ou si tu l’as manqué, je t’invite fortement à le lire avant de continuer :

Covariate Shift : Pourquoi tes méthodes de détection échouent ?

La plupart des modèles de ML se dégradent à cause du covariate shift. Le problème ? Les méthodes classiques, feature par feature, ne capturent pas les changements conjoints.

Dans ce shot data, je t’avais laissé avec une question :

C'est le sujet que nous allons aborder aujourd'hui.

Pour rappel, le covariate shift se produit lorsque la distribution des caractéristiques des données (les features ou covariables) évolue au fil du temps après le déploiement du modèle :

Évolution de la distribution des données au fil du temps

C'est un problème majeur, car nous déployons un modèle entraîné sur une distribution spécifique.

Mais peu à peu, le covariate shift s'installe et dégrade les performances du modèle, car l'environnement de production commence à l'évaluer sur une distribution différente :

Les approches courantes pour identifier ce décalage entre les données d'entraînement et les données de production incluent :

• La comparaison de leurs statistiques descriptives (moyenne, médiane, etc.).

• L'inspection visuelle des différences à l'aide de graphiques de distribution.

• La réalisation de tests d'hypothèse.

• La mesure des distances entre les distributions (distance de Bhattacharyya, test KS, etc.).

Mais le problème de ces approches est qu'elles ne peuvent détecter qu'un covariate shift univarié : elles ne fonctionnent que sur une seule feature à la fois.

Or, comme nous l'avons vu vendredi, les modèles en conditions réelles peuvent également subir un covariate shift multivarié, comme le montre clairement l'image ci-dessous :

Bleu → Données d'entraînement ; Rouge → Données de production.

• D'après les graphiques KDE (en haut et à droite), il est clair que la distribution individuelle des deux variables reste presque identique.

• Cependant, le nuage de points révèle que leur distribution conjointe lors de l'entraînement (en bleu) diffère de celle en production (en rouge).

Alors, comment détecter ce covariate shift multivarié ?

Pour commencer, il faut comprendre qu'il s'agit d'un problème complexe et qu'il n'existe pas d'approche unique (ou miracle) pour le gérer.

Voici quelques idées que j’utilise régulièrement et que j’ai également vues appliquées par d’autres experts.

Idée n°1 : La faible probabilité d'un covariate shift multivarié pur

Tant que l'on vérifie deux (voire trois) features à la fois, l'inspection visuelle peut suffire.

C’est pourquoi, en pratique, la majorité passe à côté des décalages dès qu’on dépasse trois dimensions.

Sélectionner <= 3 features pour détecter le covariate shift multivarié

La logique est la suivante : au-delà de trois features, il est très improbable que :

1. P(X1), P(X2), P(X3), P(X4), ... → restent individuellement presque identiques.

2. Mais que leur distribution conjointe P(X1, X2, X3, X4, … ) change radicalement.

Ainsi, il peut être raisonnable de limiter l'analyse multivariée à des combinaisons de une, deux ou trois variables à la fois.

Bien sûr, cela n'est pas une vérité absolue, ce qui nous amène à une deuxième approche :

Idée n°2 : La reconstruction de données

Il s'agit d'une approche à la fois élégante et très pratique que j'ai pu utiliser dans l'un de mes projets.

La reconstruction de données consiste à apprendre une transformation qui projette les données dans un espace de dimension plus faible, puis à reconstruire les données d’origine à partir de cette représentation.

L'objectif de la reconstruction est de recréer la donnée initiale après projection

Au passage, c'est exactement ce que font les Autoencodeurs.

Ce sont des réseaux de neurones qui apprennent à projeter les données dans un espace latent, puis à les reconstruire pour revenir à l’espace d’origine.

Utilisation des Autoencodeurs pour la reconstruction de données

L'objectif est de minimiser l'erreur de reconstruction.

C'est comme demander au modèle d'apprendre une fonction qui :

• Prend des données en entrée.

• Les projette en basse dimension.

• Restitue exactement les données d'entrée.

Voici donc comment procéder :

1. Entraîne un autoencodeur sur le jeu de données initial afin qu’il apprenne à reconstruire au mieux cette distribution.

2. Utilise ensuite ce modèle sur les nouvelles données pour vérifier le covariate shift :

   • Une perte de reconstruction élevée indique que la distribution a changé.

   • Une perte de reconstruction faible indique que la distribution est globalement restée la même.

Cette approche est très intuitive.

Mais l'un de ses plus grands avantages est qu'elle ne nécessite pas de données étiquetées.

Par nature, les autoencodeurs apprennent à reconstruire directement les données.

C’est particulièrement utile en pratique, car les étiquettes des données de production ne sont généralement pas disponibles immédiatement — elles arrivent presque toujours avec un certain délai.

Mais grâce aux Autoencodeurs, nous pouvons tout de même calculer l'erreur de reconstruction sur ces données non étiquetées.

En réalité, l'utilisation d'Autoencodeurs n'est qu'un exemple.

D’autres techniques de reconstruction existent, comme l’Analyse en Composantes Principales (PCA).

Cependant, quelle que soit la méthode choisie, un point crucial mérite toute notre attention.

Comme nous l’avons vu :

• Perte élevée → changement de distribution.

• Perte faible → distribution stable.

Mais attention : l’interprétation de la perte de reconstruction reste relativement subjective et dépend du contexte.

Par exemple, si la perte de reconstruction est de 0,4, comment savoir si cette valeur est vraiment significative ?

Étant donné l’importance de ce sujet, je ne veux pas le traiter à la légère.

Nous approfondirons donc cette discussion dans un prochain shot data

En attendant, c’est à toi de jouer :

• Comment interpréterais-tu l’erreur de reconstruction pour détecter un éventuel covariate shift ?

• Quelles pourraient être les limites des approches basées sur la reconstruction pour identifier ce décalage ?

J’ai hâte de découvrir tes réponses ! :)

Presque tous les modèles de Machine Learning en production voient leurs performances se dégrader progressivement à cause du Covariate Shift (ou décalage de covariables).

La distribution des données change au fil du temps

Le Covariate Shift se produit lorsque la distribution des features change au fil du temps, alors que la véritable relation entre l'entrée et la sortie reste la même.

La distribution des échantillons de test diffère de celle des données d'entraînement

C'est un problème sérieux : nous avons entraîné le modèle sur une certaine distribution, mais il est utilisé pour faire des prédictions sur une distribution différente en production.

Il est donc critique de détecter ce décalage tôt pour que les modèles continuent de bien fonctionner.

L'une des méthodes les plus courantes et intuitives pour détecter le Covariate Shift consiste simplement à comparer la distribution des features entre les données d'entraînement et celles de production.

Cela peut se faire de plusieurs manières, par exemple :

• Comparer les statistiques sommaires (moyenne, médiane, etc.).

• Inspecter visuellement via des graphiques de distribution.

• Effectuer des tests d'hypothèse.

• Mesurer les distances entre les distributions (entraînement vs production) en utilisant la distance de Bhattacharyya, le test KS, etc.

Bien que ces approches soient souvent efficaces, leur problème majeur est qu'elles fonctionnent sur une seule feature à la fois.

Or, dans la vraie vie, nous pouvons aussi observer un Covariate Shift Multivarié.

Le Covariate Shift Multivarié se produit lorsque :

1. La distribution des variables individuelles reste la même :

   • P(X1) et P(X2) restent individuellement identiques.

2. Mais leur distribution conjointe change :

   • P(X1, X2) change.

C'est flagrant sur l'image ci-dessous :

Bleu : données d’entraînement — Rouge : données de production

• Les courbes KDE (en haut et à droite) montrent que les distributions marginales sont quasi identiques.

• Pourtant, le nuage de points (scatter plot) révèle que la distribution conjointe en entraînement (Bleu) diffère totalement de celle en production (Rouge).

Il est facile de deviner que les méthodes de détection univariées mentionnées plus haut donneront des résultats trompeurs ici.

Par exemple, comme démontré ci-dessous, mesurer la distance de Bhattacharyya entre une feature d'entraînement et de production donne une valeur très basse, indiquant une forte similarité :

En réalité, même si la distribution individuelle des features est la même, nous pouvons confirmer expérimentalement que cela entraînera une chute de performance du modèle.

Comme illustré ci-dessus, la performance du modèle chute de 20% en production, ce qui est énorme.

Ici, nous pourrions complètement écarter la possibilité d'un Covariate Shift si nous partons du principe que ce décalage ne peut jamais être de nature multivariée.

Bien sûr, dans la figure précédente, il était facile d'identifier le changement multivarié car nous ne regardions que deux features.

Mais le Covariate Shift multivarié peut aussi survenir avec bien plus de deux features.

Contrairement au cas bivarié ci-dessus, l'inspection visuelle devient impossible dans des dimensions plus élevées.

Maintenant, tu connais le problème.

Alors, comment pouvons-nous détecter cela ?

Aujourd'hui, au lieu de te donner la solution tout de suite, je veux te laisser réfléchir à ce problème.

Plus spécifiquement, pose-toi la question :

Nous continuerons cette discussion semaine prochaine, mais d'ici là, j'aimerais avoir ton avis :)

Le Covariate Shift multivarié est un problème fréquent dont souffrent de nombreux modèles ML dans le monde réel.

Il est donc critique de le détecter tôt pour garantir que les modèles fonctionnent comme prévu.

Introduction

KMeans est un algorithme de clustering non supervisé qui regroupe les données en fonction des distances. Il est largement reconnu pour sa simplicité et son efficacité. Essentiellement, l'idée centrale est de partitionner un jeu de données en clusters distincts, chaque point appartenant au cluster dont le centroïde est le plus proche.

Données Clusterisées

Les limites de KMeans

Bien que sa simplicité en fasse souvent l'algorithme de clustering préféré, KMeans présente de nombreuses limitations qui entravent son efficacité dans plusieurs scénarios.

1) KMeans ne prend pas en compte la variance et la forme des clusters

Par exemple, KMeans ne tient pas compte de la variance ni de la forme des clusters.

En d'autres termes, l'une des principales limites de KMeans est son hypothèse de clusters sphériques.

Une façon intuitive et graphique de comprendre l'algorithme KMeans est de placer un cercle au centre de chaque cluster, qui englobe les points.

Résultats de KMeans sur des clusters circulaires

Comme KMeans consiste essentiellement à placer des cercles, ses résultats ne sont pas idéaux lorsque le jeu de données présente des formes irrégulières ou des tailles variables, comme indiqué ci-dessous :

Forme des clusters imposée par KMeans sur des données à clusters ovales

Au lieu de cela, un clustering idéal devrait regrouper les données comme suit :

Forme idéale des clusters pour des données à clusters ovales

On peut observer la même chose dans le jeu de données suivant :

Cette rigidité de KMeans à ne former que des clusters globulaires conduit souvent à des erreurs de classification et à des assignations de clusters sous-optimales.

2) Chaque point de données est assigné à un cluster

Une autre limitation significative de l'algorithme KMeans est son hypothèse inhérente que chaque point de données doit être assigné à un cluster.

Plus précisément, KMeans part du principe que chaque point appartient à un et un seul cluster, ne laissant aucune place pour la représentation du bruit ou des outliers (données aberrantes).

Cette caractéristique peut être problématique dans les scénarios où le jeu de données contient des irrégularités, des anomalies ou du bruit qui ne se conforment pas à des frontières de clusters claires.

Par conséquent, KMeans peut assigner par inadvertance des points à des clusters même lorsqu'ils n'appartiennent véritablement à aucun modèle discernable.

Ceci est illustré dans l'image ci-dessous :

Cette tendance peut conduire à des résultats de clustering sous-optimaux, en particulier dans les jeux de données à densités variables, aux formes irrégulières ou en présence de données bruitées.

Dans les datasets réels où la structure sous-jacente n'est pas adaptée aux hypothèses de KMeans, l'assignation rigide de tous les points limite son efficacité.

Nous devons être conscients de cette limitation et envisager des approches alternatives, telles que les méthodes basées sur la densité ou hiérarchiques, lorsque nous traitons des données présentant beaucoup de bruit ou d'outliers.

3) Spécification du nombre de clusters

Une contrainte notable de l'utilisation de KMeans est la nécessité d'une connaissance préalable ou d'hypothèses sur le nombre exact de clusters dans le jeu de données.

Contrairement à d'autres algorithmes capables de déterminer automatiquement le nombre optimal de clusters basé sur la structure inhérente des données, KMeans repose sur une valeur prédéfinie (souvent notée 'k').

Bien sûr, ce n'est pas un problème insurmontable, et il existe diverses méthodes pour déterminer une valeur fiable pour le paramètre k, mais cette contrainte pose des défis lorsque le vrai nombre de clusters est inconnu à l'avance, menant à des inexactitudes potentielles.

Note en passant : Nous utilisons couramment la méthode du Coude (Elbow curve) pour déterminer le nombre de clusters (k) pour KMeans.

Cependant, le problème avec la courbe du Coude est qu'elle :

• a une interprétation subjective

• implique une ambiguïté pour déterminer le point de coude avec précision

• ne considère que la distance intra-cluster, entre autres

Le score de Silhouette est une mesure alternative pour évaluer la qualité du clustering, et il est généralement considéré comme plus fiable que la courbe du Coude.

Le mesurer à travers une plage de centroïdes (k) peut révéler quels résultats de clustering sont les plus prometteurs.

Le visuel ci-dessous compare la courbe du Coude et le graphique de Silhouette :

Il est clair que la courbe du Coude est très trompeuse et imprécise. Dans un dataset avec 25 clusters :

• La courbe du Coude suggère que 4 est le nombre optimal de clusters.

• La courbe de Silhouette suggère que 25 est le nombre optimal.

Nous avons déjà couvert cela dans quelques éditions précédentes de la newsletter si tu souhaites plus de détails :

Revenons à nos moutons...

Les limitations ci-dessus soulignent l'importance extrême d'apprendre d'autres algorithmes plus performants pour pallier ces manques.

Bien que KMeans fasse partie des algorithmes basés sur les centroïdes, il existe de nombreux types d'algorithmes de clustering (montrés ci-dessous) utilisables selon la situation :

Nous avons déjà couvert le clustering basé sur la distribution auparavant :

Comprendre les Modèles de Mélange Gaussien (GMMs)

Découvre les Modèles de Mélange Gaussien (GMMs), une alternative puissante à KMeans pour un clustering avancé et robuste des données en machine learning.

L'objectif de ce mini-cours est donc le clustering basé sur la densité, et plus spécifiquement DBSCAN++, qui est une amélioration significative de l'algorithme DBSCAN classique.

Comprenons cela en détail !

Mais avant de comprendre DBSCAN++, comprenons ce qu'est DBSCAN.

Qu'est-ce que DBSCAN ?

DBSCAN, qui signifie Density-Based Spatial Clustering of Applications with Noise, est un algorithme populaire en machine learning et data mining.

Comme son nom l'indique, l'idée centrale derrière DBSCAN est de regrouper les points de données basés sur la "densité", c'est-à-dire les points proches les uns des autres dans une région à haute densité, séparés par des régions de plus faible densité.

Il excelle à chercher des zones dans les données avec une forte densité de points, par opposition aux zones peu denses en observations.

La notion de densité dans DBSCAN lui permet de trier les données en clusters de formes variées également, ce qui est son avantage substantiel sur les algorithmes traditionnels comme KMeans.

En conséquence, il résout immédiatement chacune des limitations de KMeans discutées plus haut :

• Comme il clusterise basé sur la notion de "densité", les clusters n'ont pas nécessairement une forme globulaire. Ils peuvent avoir des formes arbitraires, comme illustré ci-dessous :

• Contrairement à KMeans, DBSCAN n'alloue pas chaque point à un cluster. C'est parce que DBSCAN opère sur un principe fondamentalement différent. Les outliers sont des régions de très faible densité, et nous verrons bientôt que DBSCAN peut rapidement identifier ces régions et classifier les points s'y trouvant comme des outliers.

• De plus, un autre avantage est qu'il ne nécessite pas de spécifier le nombre de clusters à l'avance. Il identifie les clusters basés sur la densité des points.

Comment ça marche ?

Parcourons un exemple simple pour comprendre le fonctionnement de l'algorithme.

Disons que nous avons un dataset de points comme suit :

Clairement, nous avons deux clusters distincts et un point de bruit au centre. Notre objectif est de regrouper ces points en groupes denséments peuplés.

Premièrement, nous comptons le nombre de points au voisinage de chaque point de données. Par exemple, si nous commençons avec le point vert, nous dessinons un cercle autour de lui.

Le rayon epsilon du cercle est le premier paramètre que nous devons spécifier en utilisant DBSCAN. En d'autres termes, c'est un hyperparamètre.

Après avoir dessiné le cercle, nous comptons le nombre de points qui tombent dans ce cercle de rayon ϵ. Par exemple, pour notre point vert, il y a six points proches.

De même, nous comptons le nombre de points proches pour tous les points restants.

Après avoir compté les points au voisinage de chaque donnée, nous classifions chaque point dans l'une des trois catégories :

• Point cœur : Un point qui a au moins minPts voisins (incluant le point lui-même) à une distance inférieure ou égale à epsilon. Par exemple, si minPts=5, le point vert ci-dessous est un point cœur :

• Point frontière : Un point qui n'a pas au moins minPts voisins à distance epsilon, mais qui se trouve dans le voisinage d'un point cœur. Par exemple, ci-dessous, le point vert est un point frontière.

• Point de bruit (outlier) : Un point qui n'est ni un point cœur ni un point frontière. Par exemple, le point violet ci-dessous est un point de bruit :

Et bien sûr, comme tu l’as deviné, minPts est un autre hyperparamètre de DBSCAN.

Après avoir classifié tous les points, nous procédons au clustering.

L'idée est simple :

• Commence avec n'importe quel point cœur (appelons-le A) et assigne-le à un cluster avec un ID, disons 1 (pour commencer).

• Tous les points dans le voisinage de ce point cœur A appartiendront au même cluster (ID 1).

• Si un point dans le voisinage de A est aussi un point cœur, comme montré ci-dessous...

• ...alors nous incluons les points de son voisinage dans le même cluster (ID 1).

• L'étape ci-dessus est exécutée récursivement sous le même ID de cluster jusqu'à ce que nous ne trouvions plus de nouveau point cœur.

• À ce stade, nous pouvons encore avoir des points cœurs dans le dataset, mais ils n'appartiennent pas au cluster précédent. Nous répétons les étapes avec un nouvel ID de cluster.

L'algorithme termine son exécution une fois qu'il ne reste plus de points cœurs non visités.

Comment trouver la valeur optimale d'Epsilon

Dans DBSCAN, déterminer le paramètre epsilon est souvent délicat. Mais la courbe du Coude est souvent utile ici.

Pour commencer, DBSCAN a deux hyperparamètres :

1. epsilon : deux points sont voisins s'ils sont plus proches que cette distance.

2. minPts : le nombre minimum de voisins pour qu'un point soit un "point cœur".

Nous pouvons utiliser la courbe du Coude pour trouver epsilon :

Pour chaque point, trace la distance vers son k-ième voisin le plus proche (en ordre croissant), où k est l'hyperparamètre minPts. C'est ce qu'on appelle le k-distance plot.

La valeur optimale d'epsilon se trouve près du point de coude.

Pourquoi ça marche ?

Rappelle-toi que dans ce graphique, nous mesurons la distance vers un voisin spécifique (le k-ième) pour tous les points. Ainsi, le point de coude suggère une distance vers un point plus isolé ou un point dans un cluster différent.

Le point où le changement est le plus prononcé suggère un epsilon optimal. L'efficacité est évidente sur l'image ci-dessus.

Comme illustré, choisir la valeur du coude fournit de meilleurs résultats de clustering.

Avantages de DBSCAN

• Clustering basé sur la densité efficace :

  • Intuitivement, DBSCAN excelle à séparer les clusters de haute densité de ceux de faible densité.

  • Il peut identifier des clusters de formes et tailles variées.

• Gestion robuste des outliers :

  • DBSCAN est particulièrement adepte pour gérer les outliers.

  • Comme discuté, si un point n'a pas de point cœur proche de lui, il sera intuitivement considéré comme un outlier.

  • En fait, DBSCAN est parfois utilisé principalement comme technique de détection d'anomalies.

  • Il n’est même pas nécessaire d’effectuer un clustering complet pour détecter les outliers ; il suffit de déterminer si un point est un point de bruit en utilisant les paramètres epsilon et minPts.

Inconvénients de DBSCAN

Les algorithmes basés sur la densité ont grandement impacté l'analyse de données (vision par ordinateur, imagerie médicale, etc.).

Dans de nombreuses applications pratiques, à mesure que les volumes de données augmentent, il devient difficile de collecter des labels pour l'apprentissage supervisé.

Dans ce contexte, les algorithmes non supervisés non paramétriques deviennent particulièrement importants.

Cependant, l'un des plus gros problèmes de DBSCAN est son temps d'exécution.

Jusqu'à récemment, on pensait que DBSCAN avait un temps d'exécution de O(nlog⁡n), jusqu'à ce qu'il soit prouvé qu'il est de O(n² ) dans le pire des cas.

Il y a donc un besoin croissant de versions plus efficaces de DBSCAN.

Bien que nous n'entrions pas dans les détails ici, on peut prouver que DBSCAN tourne en O(nlog⁡n) quand la dimension est au maximum de 2, ce qui est rarement le cas.

Cependant, il commence rapidement à exhiber un comportement quadratique en hautes dimensions et/ou quand n devient grand.

Cela peut être vérifié sur la figure ci-dessous :

Dans cette expérience (jeu de données 2D simple avec un nombre de points variable), on observe clairement que le temps d’exécution de DBSCAN croît de manière quadratique avec le nombre de points.

Ce temps quadratique vient du fait que DBSCAN doit implicitement calculer des estimations de densité pour chaque point, ce qui prend un temps linéaire dans le pire des cas pour chaque requête.

Comme ces requêtes sont basées sur la proximité pour chaque paire de points, cela donne une performance quadratique.

DBSCAN++

DBSCAN++ est un pas vers un DBSCAN rapide et scalable.

Simplement dit, DBSCAN++ est basé sur l'observation que...

...nous n'avons besoin de calculer les estimations de densité que pour un sous-ensemble m des n points du dataset, où m peut être bien plus petit que n (typiquement autour de 10-15% seulement) pour clusteriser correctement.

Pourquoi ?

Comprenons cela.

Lorsque tu souhaites visualiser l'évolution d'un rang ou d'un classement au fil du temps, l'utilisation d'un diagramme en barres n'est pas toujours appropriée. Essaye plutôt les Graphiques d'évolution du classement (ou Bump Charts).

Ce type de graphique est spécifiquement conçu pour visualiser le rang de différents éléments sur une période donnée.

Contrairement aux diagrammes en barres classiques, les Bump Charts sont clairs, élégants et faciles à interpréter.

Retrouve le code Python pour créer un Graphiques d'évolution du classement ici : Notebook Bump chart.

👉 À toi de jouer : Quelles autres alternatives aux diagrammes en barres recommandes-tu pour ce type de cas ? Dis-le-moi en commentaire :)

La mutabilité est probablement l'un des concepts les plus mal compris et sous-estimés en Python.

Ci-dessous, nous allons examiner un exemple avec lequel de nombreux développeurs Python peinent à se familiariser.

Considère la fonction suivante :

Invoquons-la plusieurs fois :

Que s'est-il passé ?

Pourquoi plusieurs appels successifs ajoutent-ils les arguments passés à la même liste ?

As-tu une idée ?

Si non, comprenons-le ensemble dès maintenant.

Le cœur du problème

En Python, les paramètres par défaut d'une fonction sont évalués au moment où la fonction est définie, et non à chaque appel.

Cela contraste avec d'autres langages comme C++, où les paramètres sont évalués à chaque invocation.

Ainsi, dès qu'une fonction est définie, l'objet fonction stocke ses paramètres par défaut dans l'attribut __defaults__.

Nous pouvons le vérifier ci-dessous :

Dans le code ci-dessus :

• Nous avons défini une méthode my_function mais ne l'avons pas encore invoquée.

• Pourtant, les paramètres par défaut sont déjà accessibles via l'attribut __defaults__.

Cela prouve que les paramètres par défaut d'une fonction sont évalués dès sa définition.

Par conséquent, si tu spécifies un paramètre par défaut mutable dans une fonction et que tu le modifies, tu altères involontairement et inconsciemment ce paramètre pour tous les appels futurs de cette fonction.

C'est exactement ce que nous avons observé plus tôt, comme le démontre l'exemple ci-dessous :

Comme illustré ci-dessus, au lieu de créer une nouvelle liste à chaque appel, Python continue d'ajouter l'élément à la même copie.

Comment éviter ce piège ?

La solution est simple.

Évite de spécifier des paramètres par défaut mutables dans la signature d'une fonction.

À la place, remplace-les par None.

Ensuite, si la fonction ne reçoit aucune valeur correspondante lors de l'appel, cela crée l'objet mutable à l'intérieur de la fonction.

Comme montré ci-dessus, nous créons une nouvelle liste si la fonction n'a reçu aucune valeur lors de son appel.

Cela te permet d'éviter le comportement inattendu de mutation du même objet :

👉 À toi de jouer : Quelles autres fonctionnalités sournoises de Python connais-tu et que beaucoup ignorent ?

Dans de nombreux projets concrets d'apprentissage automatique (Machine Learning - ML), il est courant de consolider les données en un lieu central.

Par la suite, les ingénieurs en Machine Learning exploitent ces données centralisées pour :

• L'analyse,

• La réalisation du feature engineering,

• Et finalement pour l'entraînement du modèle, sa validation, sa mise à l'échelle, son déploiement et sa surveillance continue en production.

Cette méthode traditionnelle est largement acceptée et employée dans le développement de modèles ML.

Néanmoins, un défi notable associé à cette approche conventionnelle réside dans l'obligation de centraliser physiquement les données avant qu'aucun traitement ultérieur ne puisse avoir lieu.

Comprenons les problèmes que cela implique en détail !

Les problèmes de la modélisation ML traditionnelle

Imaginons que notre application possède une base de millions d'utilisateurs. Il est clair que le volume de données à traiter peut être très important.

Ces données sont précieuses car les appareils modernes ont accès à une richesse d'informations pouvant convenir aux modèles de machine learning.

Ces données peuvent améliorer considérablement l'expérience utilisateur sur l'appareil.

Par exemple :

• S'il s'agit de données textuelles, les modèles de langage peuvent améliorer la reconnaissance vocale et la saisie de texte.

• S'il s'agit de données d'images, de nombreux modèles de traitement d'images peuvent être améliorés, et bien plus encore.

Cependant, l'approche conventionnelle du Machine Learning, qui implique l'agrégation de toutes les données dans un dépôt central, présente de nombreux défis dans de telles situations.

Plus spécifiquement, dans cette approche, le transfert des données depuis les appareils individuels des utilisateurs vers un emplacement central est coûteux tant en bande passante qu'en temps, ce qui décourage les utilisateurs de participer.

Même si les utilisateurs étaient incités à contribuer, la redondance d'avoir les données à la fois sur l'appareil de l'utilisateur et sur le serveur central pourrait être logistiquement irréalisable en raison du volume de données à traiter.

De plus, les données contiennent souvent des informations personnelles telles que des photos, des textes privés et des notes vocales.

Demander aux utilisateurs de télécharger de telles données sensibles met non seulement en péril leur vie privée, mais soulève également des questions juridiques. Stocker ces données dans une base centralisée devient problématique, introduisant des problèmes de faisabilité et des violations de la confidentialité.

Bref, cela crée des problèmes de stockage centralisé. Simplement dit, cela peut être à la fois irréalisable et source de nombreuses violations de la vie privée.

Déplacer de grandes quantités de données vers un serveur central peut être coûteux en termes de bande passante utilisateur et de temps.

Mais ces données nous sont toujours précieuses, n'est-ce pas ? Nous voulons les utiliser d'une manière ou d'une autre.

L'apprentissage fédéré (Federated Learning) est une technique incroyable d'entraînement de modèles de Machine Learning qui minimise le transfert de données, la rendant adaptée aux environnements à faible bande passante et à forte latence.

Comprenons comment !

Comment l'apprentissage fédéré résout ces préoccupations

Formellement, l'apprentissage fédéré représente une approche décentralisée du Machine Learning, où les données d'entraînement restent localisées sur les appareils individuels, tels que les smartphones.

Au lieu de transmettre les données à un serveur central, les modèles sont envoyés vers les appareils, entraînés localement, et seules les mises à jour résultantes du modèle sont collectées et renvoyées au serveur.

En essence, cette approche consiste à laisser les données d'entraînement sur les appareils individuels tout en apprenant un modèle partagé via l'agrégation des mises à jour de gradients calculées localement.

L'un de ses principaux mérites réside dans l'amélioration de la confidentialité et de la sécurité en éliminant toute dépendance à la collecte centralisée de données.

Ceci car chaque client possède un dataset d'entraînement local qui reste exclusivement sur l'appareil et n'est jamais téléchargé sur le serveur.

Au lieu de cela, les clients calculent des mises à jour pour le modèle global maintenu par le serveur, ne transmettant que la "mise à jour du modèle" essentielle.

En conséquence, tout le processus de mise à jour du modèle se déroule côté client, offrant un avantage clé en découplant l'entraînement du modèle de la nécessité d'un accès direct aux données d'entraînement brutes.

Bien qu'un certain degré de confiance envers le serveur coordinateur soit requis, l'apprentissage fédéré répond efficacement aux préoccupations majeures associées à l'approche centralisée conventionnelle de l'entraînement de modèles ML.

En facilitant l'entraînement sur l'appareil et en minimisant le besoin de transferts de données massifs, l'apprentissage fédéré présente des solutions pratiques aux défis inhérents au paradigme traditionnel d'entraînement.

Les motivations principales pour utiliser l'apprentissage fédéré sont :

• Confidentialité :

  • La protection des données des utilisateurs est une priorité absolue, d'autant plus que, dernièrement, de plus en plus d'utilisateurs se soucient de leur vie privée.

  • Les dépôts de données centralisés posent des risques inhérents pour la confidentialité, tandis que l'apprentissage fédéré atténue ces préoccupations en permettant aux données de résider exclusivement sur les appareils des utilisateurs, minimisant ainsi l'exposition.

• Bande passante et Latence :

  • Comme discuté précédemment, le processus gourmand en ressources de transfert de volumes substantiels de données vers un serveur central peut être coûteux en temps et en bande passante.

  • L'apprentissage fédéré minimise stratégiquement le transfert de données, s'avérant particulièrement avantageux dans les environnements caractérisés par une faible bande passante et une latence élevée.

• Propriété des données :

  • Les utilisateurs conservent le contrôle et la propriété de leurs données au sein du cadre de l'apprentissage fédéré.

  • Cela répond non seulement aux préoccupations liées à la propriété des données mais assure également la préservation des droits sur les données, offrant une approche du Machine Learning centrée sur l'utilisateur.

• Scalabilité (Mise à l'échelle) :

  • L'apprentissage fédéré présente une scalabilité naturelle qui s'aligne parfaitement avec le nombre croissant d'appareils.

  • Cette scalabilité inhérente le rend bien adapté aux applications à grande échelle, couvrant les appareils mobiles, les objets connectés (IoT) et les scénarios d'informatique en périphérie (edge computing).

En résumé, l'apprentissage fédéré représente un changement de paradigme en amenant nos modèles là où résident les données, contrairement à l'approche conventionnelle qui consiste à déplacer les données là où se trouve le modèle.

Cette inversion du processus traditionnel d'entraînement souligne l'adaptabilité et l'efficacité de l'apprentissage fédéré dans les applications contemporaines pilotées par les données.

Comment les systèmes d'apprentissage fédéré assurent-ils la confidentialité ?

Certes, à ce stade, on pourrait avancer que l'anonymisation des données avant leur téléchargement sur des serveurs centraux peut répondre aux problèmes de confidentialité.

Simplement dit, anonymiser signifie supprimer toute information personnellement identifiable (PII) d'un dataset.

Cela implique généralement de remplacer ou de chiffrer des éléments de données spécifiques pour empêcher l'identification des individus associés à l'information.

Cependant, contrairement à la croyance populaire, même la manipulation de données anonymisées peut introduire des problèmes de confidentialité.

Considère un scénario avec une base de données de titulaires de cartes bancaires — un dataset hautement sensible.

Bien que le masquage des numéros de carte soit une pratique courante, des détails supplémentaires tels que les adresses des titulaires, nécessaires au traitement, peuvent toujours être présentes.

Ainsi, l'anonymisation du dataset ne garantit pas toujours l'élimination des préoccupations liées à la vie privée.

L'apprentissage fédéré, en revanche, minimise la transmission d'informations spécifiques aux données vers des emplacements centralisés. Comme discuté ci-dessus, l'information transmise est minime, contenant généralement beaucoup moins de données brutes.

Dans ce paradigme, seules les mises à jour du modèle sont envoyées au serveur central et, remarquablement, l'algorithme d'agrégation côté serveur ne nécessite pas de connaître la source de ces mises à jour. Ainsi, l'information sur la source peut être entièrement ignorée.

Cette absence de dépendance envers l'information source garantit un véritable anonymat en assurant que les mises à jour de modèle générées localement peuvent être transmises sans révéler aucun autre détail susceptible de compromettre la vie privée de l'utilisateur.

Cela crée un scénario mutuellement bénéfique.

• Les utilisateurs sont satisfaits car leur expérience est pilotée par des modèles ML de haute qualité sans compromettre leurs données.

• Simultanément, les équipes en bénéficient en résolvant avec succès divers défis, notamment :

1. Préoccupations liées à la confidentialité : L'apprentissage fédéré contourne efficacement les problèmes de confidentialité associés aux approches centralisées traditionnelles.

2. Coût d'entraînement du modèle réduit : L'approche aide à atténuer les coûts associés à l'entraînement centralisé des modèles.

3. Coût de maintenance des données minimisé : L'apprentissage fédéré diminue considérablement le fardeau des coûts de maintenance des données.

4. Entraînement sur de grands jeux de données : Les équipes peuvent entraîner des modèles sur des jeux de données vastes sans avoir besoin de stockage centralisé.

5. Meilleure expérience utilisateur : Malgré l'absence de stockage centralisé des données, des modèles ML de haute qualité peuvent être développés.

En essence, l'apprentissage fédéré offre une solution gagnant-gagnant pour tout le monde.

Avantages supplémentaires de l'apprentissage fédéré

Plus grande exposition aux données

Dans l'apprentissage fédéré, la portée des données utilisées pour l'entraînement du modèle s'étend au-delà de ce que l'ingénierie des données centralisée aurait pu collecter et gérer.

En exploitant tout le spectre des données résidant sur les appareils individuels des utilisateurs, l'apprentissage fédéré permet aux modèles d'apprendre à partir de jeux de données diversifiés et riches.

Cette diversité améliore la robustesse des modèles, les rendant plus représentatifs des scénarios du monde réel.

Bénéfice mutuel

L'apprentissage fédéré améliore non seulement les modèles grâce à l'entraînement collaboratif, mais étend également les avantages directement aux utilisateurs.

Lorsque l'appareil d'un utilisateur participe à l'entraînement du modèle, il reçoit des mises à jour basées sur la connaissance collective, améliorant ainsi l'expérience utilisateur.

Par exemple, dans un système de recommandation personnalisé, un utilisateur bénéficie d'un modèle entraîné sur les préférences d'une base d'utilisateurs plus large, conduisant à des recommandations plus précises et adaptées.

Exigences de calcul limitées

Contrairement aux approches centralisées traditionnelles qui exigent des ressources de calcul substantielles pour le traitement des données et l'entraînement du modèle sur un serveur central, l'apprentissage fédéré redistribue la majeure partie du calcul vers les appareils des utilisateurs.

Ce changement apporte plusieurs avantages :

• Charge serveur réduite : Les serveurs centraux nécessitent moins de puissance de calcul car ils n'ont plus besoin de traiter et d'entraîner sur des quantités massives de données.

• Latence plus faible : Les utilisateurs bénéficient d'une latence réduite puisque les données n'ont pas besoin d'être transmises à un serveur distant pour traitement, améliorant ainsi l'expérience globale.

• Efficacité énergétique : Le calcul local sur les appareils des utilisateurs peut être plus efficace sur le plan énergétique.

Quand l'apprentissage fédéré est-il approprié ?

Avant de comprendre les stratégies clés de l'apprentissage fédéré, il est essentiel de comprendre que son applicabilité n'est pas universelle.

Plutôt que de l'adopter partout, il est critique de comprendre les situations spécifiques où l'apprentissage fédéré est l'approche optimale.

C'est parce que si tu comprends ces types spécifiques de situations et que tu les rencontres un jour, tu sauras immédiatement que l'apprentissage fédéré est la solution.

D'après mon expérience, les problèmes idéaux pour l'apprentissage fédéré possèdent les propriétés suivantes :

Les Heatmaps facilitent grandement l'analyse de données. Pourtant, une simple modification peut les rendre encore plus parlantes.

Une heatmap traditionnelle représente les valeurs via une échelle de couleurs. Cependant, il reste parfois difficile pour l'œil humain d'associer précisément une nuance de couleur à une valeur numérique.

C'est là qu'intervient l'ajout d'une composante de taille. Le principe est simple : plus la valeur absolue est élevée, plus la taille de la cellule est grande.

Cette technique est particulièrement efficace pour épurer tes graphiques : les valeurs proches de zéro rétrécissent visuellement, mettant immédiatement en évidence les corrélations fortes sans bruit visuel inutile.

👉 Consulte le notebook complet pour reproduire cette visualisation : Heatmap-Scatter.ipynb

📚 Plus de détails ici : Documentation Seaborn.

Sans données étiquetées, il est impossible d’évaluer objectivement si l’algorithme de clustering a correctement regroupé les points similaires et séparé les points différents.

La plupart des datasets étant multidimensionnels, tu ne peux pas simplement "regarder" le résultat en 2D pour juger.

Tu dois t’appuyer sur des métriques intrinsèques pour déterminer la qualité du clustering dans de tels cas.

La façon dont je préfère les utiliser est la suivante :

• Supposons que j'utilise KMeans :

  • Exécuter KMeans avec une plage de valeurs de k.

  • Évaluer les performances.

  • Sélectionner la valeur de k en fonction de la métrique de qualité des clusters la plus prometteuse.

Voici les 3 méthodes les plus fiables pour ne plus naviguer à l’aveugle.

#1) Coefficient de Silhouette :

Le Coefficient de Silhouette mesure à quel point chaque point "appartient" bien à son cluster.

L’intuition est simple : Si la distance moyenne avec les points de son propre cluster est faible, mais que la distance avec le cluster voisin est grande, alors les groupes sont bien séparés.

Il se mesure comme suit:

• Pour chaque point de données:

  • trouver la distance moyenne à tous les autres points au sein de son cluster → A

  • trouver la distance moyenne à tous les points dans le cluster le plus proche → B

  • score du point = (B - A) / max(B, A)

• Calculer la moyenne de tous les scores individuels pour obtenir le score global du clustering.

Maintenant, considère ceci :

• Si, pour tous les points de données, B est bien plus grand que A, cela signifie que:

  • La distance moyenne vers les points du cluster le plus proche est grande.

  • La distance moyenne vers les points du même cluster est faible.

  • Ainsi, le score global sera proche de 1, indiquant que les clusters sont bien séparés.

Ainsi, un Coefficient de Silhouette plus élevé signifiera que, de manière générale, tous les points de données s’intègrent dans leurs clusters idéaux.

C’est l’indicateur idéal pour choisir le bon nombre de clusters (k).

Je l’explique ici si tu veux comprendre le Coefficient de Silhouette grâce à des diagrammes.

#2) Indice Calinski-Harabasz

L’Indice Calinski-Harabasz est une autre métrique mesurée de façon assez similaire au Coefficient de Silhouette.

• A → somme des distances au carré entre tous les centroïdes et le centre global du jeu de données.

• B → somme des distances au carré entre tous les points et leur centroïde spécifique.

• La métrique est calculée comme A / B (avec un facteur d’échelle additionnel).

Pourtant, si A est bien plus grand que B :

• La distance des centroïdes par rapport au centre du jeu de données est grande.

• La distance des points par rapport à leur centroïde spécifique est petite.

• Ainsi, cela aboutira à un score plus élevé, indiquant que les clusters sont bien séparés.

La raison pour laquelle je préfère l’Indice Calinski-Harabasz au Coefficient de Silhouette est que :

Pourquoi je préfère souvent l’Indice Calinski-Harabasz au Coefficient de Silhouette ? 

Il est beaucoup plus rapide à calculer. Le coefficient de Silhouette demande de calculer toutes les distances par paires (lourd sur de la Big Data), alors que Calinski-Harabasz est quasi instantané, tout en gardant la même logique d’interprétation.

#3) DBCV

Attention : La Silhouette et Calinski-Harabasz ont un biais majeur. Ils favorisent les clusters convexes (sphériques).

Si tes données ont des formes arbitraires (comme des croissants ou des cercles concentriques traités par DBSCAN), ces métriques peuvent te donner des résultats trompeurs.

Regarde cet exemple :

Comme montré ci-dessus, même si le clustering par KMeans donne un résultat visuellement moins bon, son score Silhouette reste plus élevé que celui du clustering basé sur la densité.

Dans ce cas, DBCV (Density-Based Clustering Validation) est une métrique plus pertinente. Comme son nom l’indique, elle est spécialement conçue pour évaluer les clusters basés sur la densité.

En pratique, DBCV se base sur deux critères :

• La densité à l’intérieur d’un cluster

• Le chevauchement de densité entre les clusters

Un cluster de haute densité et un faible chevauchement entre clusters indiquent un bon clustering.

L’efficacité de DBCV est également visible sur l’image ci-dessous :

Avec DBCV, KMeans obtient un score inférieur, tandis que le clustering basé sur la densité est mieux noté.

Avant de conclure, garde à l’esprit qu’il existe d’autres types d’algorithmes de clustering, comme le montre l’image ci-dessous :

6 alternatives à KMeans : boîte à outils du clustering ML

Découvre 6 alternatives puissantes à KMeans pour enrichir tes techniques de clustering en machine learning et optimiser tes algorithmes non supervisés.

Dans ce shot data, on a exploré l’évaluation par centroïdes et par densité.

Envie de pousser plus loin ? Découvre le clustering distributionnel et son évaluation avec les Gaussian Mixture Models (GMMs) :

👉 À toi: Quelles sont d’autres façons d’évaluer la performance du clustering dans de telles situations?

Introduction

Les bénéfices du versioning

Par exemple, avec le contrôle de version, on peut identifier précisément ce qui a changé, quand cela a changé, et qui a effectué le changement. C’est une information cruciale lorsqu’on essaie de diagnostiquer et de corriger des problèmes survenant lors du déploiement, ou si les modèles commencent à sous-performer après leur mise en production.

Un autre avantage du contrôle de version est la collaboration efficace.

Par exemple, un membre de l'équipe peut travailler sur l'identification de meilleures features pour le modèle, tandis qu'un autre peut être responsable du fine-tuning des hyperparamètres ou de l'optimisation de l'infrastructure de déploiement.

Et c'est bien connu : avec le contrôle de version, les équipes peuvent travailler sur la même base de code/données et améliorer les mêmes modèles sans interférer avec le travail des uns et des autres.

De plus, on peut facilement suivre les modifications, revoir le travail de chacun et résoudre les conflits (s'il y en a).

Enfin, le contrôle de version aide aussi à la reproductibilité d'une expérience.

Il garantit que les résultats peuvent être répliqués et validés par d'autres, ce qui améliore la crédibilité globale de notre travail.

Le contrôle de version nous permet de suivre la version exacte du code et des configurations utilisées pour produire un résultat particulier, rendant plus facile la reproduction des résultats dans le futur.

Cela devient particulièrement utile pour les projets data open-source que de nombreux programmeurs peuvent utiliser.

CEPENDANT !

Les piliers de la reproductibilité des modèles

Laisse-moi te poser une question :

En d'autres termes, est-ce que ce sont les seules exigences pour garantir la reproductibilité d'un modèle ?

Quand nous voulons reproduire un modèle :

• Premièrement, nous avons besoin de la version exacte du code qui a été utilisé pour entraîner le modèle.

Nous avons accès au code via le versioning de code (Git).

• Ensuite, nous avons besoin de la configuration exacte avec laquelle le modèle a été entraîné :

Cela peut inclure la graine aléatoire (random seed), le learning rate, l'optimiseur, etc.

Typiquement, les configurations font partie du code, donc nous connaissons aussi la configuration via le versioning de code.

• Enfin, nous avons besoin du modèle entraîné pour comparer sa performance avec le modèle reproduit.

Nous avons accès au modèle également via le versioning de modèle (MLflow, etc.).

Mais comment pourrions-nous entraîner le modèle sans avoir accès au dataset exact qui a été utilisé à l'origine ? 

En fait, au fil des mises à jour du modèle, nos données peuvent aussi largement varier.

Ainsi, il devient important de suivre la version exacte du dataset qui a été utilisée à une étape spécifique du développement et du déploiement du modèle.

C'est précisément tout l'objet du Data Version Control.

Motivation pour le Data Version Control

La motivation pour maintenir un système de Data Version Control en place est assez intuitive et directe.

Typiquement, tous les modèles de Machine Learning du monde réel sont entraînés en utilisant de grands datasets.

Avant d'entraîner un modèle et même pendant son développement, de nombreuses transformations sont régulièrement appliquées au dataset.

Cela peut inclure :

• Le pré-traitement (Preprocessing)

• La transformation

• Le Feature Engineering

• La tokenisation, et bien plus encore.

À mesure que le nombre de mises à jour (ou d'itérations) du modèle augmente, il peut devenir assez difficile de suivre quelle version spécifique du dataset a été utilisée pour entraîner le modèle de Machine Learning.

Si cela est clair, alors la motivation pour avoir un système de Data Version Control en place devient assez intuitive et simple, car il répond à de nombreux défis spécifiques aux données :

#1) Reproductibilité

Avec un système de Data Version Control, nous pouvons reproduire précisément le même dataset d'entraînement pour n'importe quelle version donnée de notre modèle de Machine Learning.

En suivant et en liant chaque version de dataset à une version spécifique de modèle, nous pouvons facilement recréer les conditions exactes dans lesquelles un modèle a été entraîné, rendant possible la réplication des résultats.

#2) Traçabilité

Comme la traçabilité de la base de code, le Data Version Control permet la traçabilité en documentant l'historique des changements du dataset.

Il offre une lignée claire de comment le dataset a évolué au fil du temps, incluant des informations sur qui a fait les changements, quand ces changements ont eu lieu, et les raisons derrière ces modifications.

Cette traçabilité est cruciale pour comprendre la qualité et l'histoire des données, assurant transparence et responsabilité dans notre pipeline ML.

#3) Collaboration et partage de données

Dans les projets collaboratifs de Machine Learning, les membres de l'équipe doivent travailler sur les mêmes données, appliquer des transformations et accéder à des versions partagées du dataset.

Le Data Version Control simplifie le partage de données et la collaboration en fournissant un dépôt centralisé pour les datasets.

Les membres de l'équipe peuvent facilement accéder et se synchroniser avec les dernières versions des données, assurant que tout le monde est sur la même longueur d'onde.

#4) Efficacité

Comme nous le verrons plus loin dans la démo pratique, les systèmes de Data Version Control aident à optimiser le stockage et l'utilisation de la bande passante en employant des techniques telles que :

• la déduplication de données

• la mise en cache (caching) de données

Cela garantit que nous ne gaspillons pas de ressources à stocker des copies redondantes de grands datasets, rendant le stockage et le transfert de données plus efficaces.

#5) Contrôle qualité des données

Il est courant que les datasets subissent des contrôles qualité et des transformations durant leur préparation.

Le Data Version Control peut aider à identifier des problèmes ou des divergences dans le dataset à mesure qu'il évolue.

En comparant différentes versions de datasets, nous pouvons repérer des changements inattendus et revenir aux versions précédentes si nécessaire.

#6) Gouvernance des données et conformité

De nombreuses industries et organisations ont des exigences strictes en matière de gouvernance des données et de conformité.

Le Data Version Control soutient ces besoins en fournissant un historique bien documenté des changements de données, ce qui peut être crucial pour les audits et la conformité réglementaire.

#7) Rollback facile

Dans des situations où une nouvelle version de modèle performe moins bien ou rencontre des problèmes inattendus en production, avoir accès aux versions précédentes du dataset permet un rollback facile vers un dataset plus fiable.

Cela peut être un sauveur dans de nombreuses situations.

Ici, tu pourrais te demander : pourquoi un rollback de données serait pertinent pour nous alors que c'est le modèle qui doit être "rollbacké" ? 

Tu as raison.

Mais il y a des situations où le rollback de données est utile.

Par exemple, supposons que ton modèle de Machine Learning déployé soit un modèle k-nearest neighbor (kNN).

Le truc, c'est que nous n'entraînons jamais vraiment un kNN.

En fait, il n'y a pas de poids explicitement entraînés dans le cas d'un kNN. Au lieu de cela, il n'y a que le dataset d'entraînement qui est utilisé à des fins d'inférence.

Il n'y a pas de distinction entre le modèle et les données : le modèle, c'est le jeu d'entraînement. Pour prédire, l'algorithme compare simplement les nouveaux points aux instances qu'il a stockées.

Si quelque chose tourne mal avec ce dataset durant la production, avoir un système de Data Version Control en place peut nous aider à revenir rapidement à un dataset fiable précédent.

Qu'est-ce qui pourrait mal tourner ?

• Peut-être que l'équipe de Data Engineering a arrêté de collecter une feature spécifique à cause d'un problème de conformité.

• Peut-être qu'il y a eu des erreurs humaines, comme des suppressions accidentelles de données. Cela rendra le kNN caduc.

• Peut-être qu'il y a eu une corruption de données — Des fichiers ou enregistrements corrompus dus à une panne matérielle, des problèmes réseau ou des bugs logiciels. Cela rendra le kNN caduc.

L'avantage du Data Version Control est que si quelque chose ne va pas avec ce dataset en production, nous pouvons rapidement revenir à une version fiable précédente.

Pendant ce temps, nous pouvons travailler dans l'environnement de développement pour enquêter sur le problème et décider des prochaines étapes.

Considérations pour le Data Version Control

Maintenant que nous avons compris la motivation pour avoir un système de Data Version Control, regardons quelques considérations pour choisir un tel système.

Pourquoi Git n'est pas une solution idéale pour le Data Version Control ?

Nous savons que Git peut gérer le versioning de n'importe quel type de fichier dans un dépôt Git. Cela peut être du code, des modèles, des datasets, des fichiers de config, etc.

Ceux-ci peuvent être hébergés sur des dépôts distants comme GitHub avec quelques commandes.

Donc pour quelqu'un qui utilise GitHub pour héberger ses bases de code, il pourrait être tenté d'étendre la même logique pour versionner ses datasets :

• Il peut gérer différentes versions du dataset avec Git localement.

• Il peut héberger le dépôt sur GitHub (ou d'autres services) pour la collaboration, etc.

La logique derrière cette idée pourrait être que Git peut faire du Data Version Control aussi élégamment qu'il versionne les bases de code.

Ça semble être une bonne chose à faire, non ?

Eh bien, non !

Rappelle-toi notre objectif.

Dans la section précédente, nous avons discuté de l'utilisation du Data Version Control pour les systèmes de production.

Comme les systèmes de production sont bien plus complexes et impliquent de la collaboration, la base de code est typiquement hébergée dans un dépôt distant, comme sur GitHub.

Mais le problème est que les dépôts GitHub (ou d'autres outils d'hébergement similaires comme GitLab) ont toujours une limite supérieure sur la taille de fichier que nous pouvons pousser vers ces dépôts distants.

En d'autres termes, GitHub est conçu uniquement pour des scripts de code légers. Cependant, il n'est pas particulièrement bien adapté pour versionner de grands datasets qui dépassent juste quelques Mo en taille.

Typiquement, dans les projets de Machine Learning, la taille du dataset peut être de l'ordre des Go. Ainsi, il est impossible d'exécuter du Data Version Control avec GitHub.

En fait, nous pouvons aussi vérifier cela expérimentalement.

Considère que nous avons le répertoire de projet suivant :

Comme montré ci-dessus, le fichier data.csv prend environ 200 Mo d'espace.

Créons d'abord un dépôt Git local avant de pousser les fichiers vers un dépôt distant hébergé sur GitHub.

Pour créer un dépôt Git local :

• D'abord, nous initialiserons un dépôt git avec git init.

• Ensuite, nous ajouterons les fichiers à la zone de staging avec git add.

• Enfin, nous utiliserons git commit pour commiter vers le dépôt local.

Ceci est démontré ci-dessous :

Tout est bon jusqu'ici. Les changements ont été commités avec succès vers le dépôt git local.

Nous pouvons vérifier cela en revoyant l'historique des commits du dépôt git local avec la commande git log.

Ensuite, essayons de pousser ces changements vers un dépôt GitHub distant. Pour faire cela, nous avons créé un nouveau dépôt sur GitHub – dvc_project.

Avant de pousser les fichiers vers le dépôt distant, vérifions aussi si le dépôt git local a des changements non commités en utilisant la commande git status :

La sortie dit que l'arbre de travail est propre (clean).

Ainsi, nous pouvons commiter ces changements vers le dépôt GitHub distant créé ci-dessus comme suit :

Comme discuté plus tôt, les dépôts GitHub ont toujours une limite supérieure sur la taille de fichier que nous pouvons pousser. C'est précisément ce que dit le message d'erreur ci-dessus.

Pour cette raison, nous ne pouvons utiliser les dépôts GitHub classiques pour le Data Version Control que tant que la taille du dataset est inférieure à quelques Mo, ce qui est rarement le cas.

Ainsi, nous avons besoin d'un meilleur système de contrôle de version, surtout pour les gros fichiers, qui n'a pas les limitations ci-dessus.

Exigences idéales pour un système de Data Version Control

Un système idéal de Data Version Control doit remplir les exigences suivantes :

• Il devrait nous permettre de suivre tous les changements de données comme Git le fait avec les fichiers.

Dès que nous faisons un changement (ajout, suppression ou modification de fichiers) dans un dépôt git-initialisé, git peut toujours identifier ces changements.

La même chose devrait être vraie pour notre système de Data Version Control.

• Il ne devrait pas être limité au suivi des datasets.

Comme nous en avons discuté plus haut, GitHub fixe une limite supérieure sur la taille de fichier que nous pouvons pousser.

Mais les gros fichiers ne se limitent pas nécessairement aux datasets. En fait, les modèles peuvent aussi être volumineux, et pousser des pickles de modèles vers des dépôts GitHub peut être difficile.

• Il doit avoir le support pour le "branching" et le "committing".

Comme Git, ce système de Data Version Control doit fournir un support pour créer des branches et des commits.

• Sa syntaxe doit être similaire à Git.

  • Bien sûr, c'est optionnel mais bon à avoir.

  • Avoir un système de Data Version Control qui a une syntaxe similaire à git peut simplifier sa courbe d'apprentissage.

• Il doit être compatible avec Git.

Dans tout projet data-driven, les données, le code et le modèle fonctionnent toujours ensemble.

Après avoir utilisé le système de Data Version Control, il ne doit pas arriver que nous suivions le code avec Git et que nous gérions ensuite les modèles/datasets avec un outil entièrement non-compatible.

Ils doivent fonctionner de manière transparente et intégrée pour éviter toute friction inutile.

• Il doit avoir des fonctionnalités collaboratives comme Git.

  • Tout comme git rend extrêmement simple pour les équipes de collaborer et travailler ensemble en partageant leur code, le Data Version Control doit aussi promouvoir la collaboration.

Alors, que pouvons-nous faire ici ?