Introduction

Plus que jamais, on a besoin de méthodes capables de communiquer (ou d'expliquer) de façon fiable le comportement d'un modèle.

Pourquoi ? Parce que faire aveuglément confiance aux prédictions d'un modèle de ML peut être fatal, surtout dans les environnements à enjeux élevés, où les décisions prises à partir de ces prédictions peuvent affecter des vies humaines, la stabilité financière ou des infrastructures critiques.

Par exemple, si un modèle prédit qu'un patient est en bonne santé et n'a besoin d'aucun traitement, cette information n'est pas forcément très utile à un médecin.

En réalité, un médecin procède à un diagnostic différentiel, et comprendre les nuances est crucial. Par exemple : une probabilité de 10 % que le patient ait un cancer, d'après une IRM.

Dans ce type de situation, il ne s'agit pas seulement de produire des prédictions, mais aussi de comprendre les raisons qui les sous-tendent.

Des méthodes comme les conformal predictions sont généralement bien adaptées pour fournir aux utilisateurs non techniques des intervalles de confiance ou des ensembles de prédiction (on en a déjà parlé juste en 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é.

...mais les data scientists et les ML engineers qui construisent ces modèles ont souvent besoin d'aller plus loin, avec des indications beaucoup plus techniques sur le fonctionnement interne du modèle.

Autrement dit, tu as besoin d'outils qui te donnent une compréhension fine de la façon dont chaque feature influence les prédictions. Dans ce cas, un ensemble de prédiction ou un score de confiance ne te servira pas à grand-chose.

Dans de nombreux cas, les Partial Dependence Plots (PDP) et les Individual Conditional Expectation (ICE) plots sont mes outils de prédilection pour ce genre d'analyse. Ils permettent d'aller au-delà des simples intervalles de confiance, pour explorer la relation entre des features précises et les prédictions du modèle, et comprendre comment il les construit.

Si tu as déjà vu le visuel suivant, où l'on présentait les 11 graphiques les plus importants en data science, tu as peut-être remarqué que les PDP en faisaient partie :

Dans ce dossier, on va voir en détail comment sont construits les PDP et les ICE plots, et comment les interpréter (sans se laisser piéger).

C'est parti !

#1) Partial Dependence Plots (PDP)

Introduction

D'après mon expérience, ce nom (Partial Dependence Plots) sème la pagaille dans la tête de beaucoup d'apprenants, alors qu'il devient très simple une fois décomposé.

• Partial signifie qu'on ne s'intéresse pas à l'ensemble de l'espace des features, mais seulement à un sous-ensemble.

• On doit donc isoler une ou deux features d'intérêt en maintenant toutes les autres constantes, d'où le terme « partial ».

• Cela permet d'étudier l'impact de features précises sur les prédictions du modèle, sans interférence des autres.

• Dependence désigne la relation entre ces features isolées et les prédictions du modèle.

• On cherche à comprendre comment les variations de ces features influencent le résultat prédit.

• Autrement dit, on trace à quel point les prédictions dépendent de ces features particulières.

En combinant les deux, la Partial Dependence désigne donc la relation entre une feature précise (ou une paire de features) et le résultat prédit, en supposant que toutes les autres features restent fixes.

Cette simplification est la clé pour comprendre l'effet marginal d'une ou deux features à la fois, et rend le comportement du modèle beaucoup plus facile à interpréter.

Rendons tout cela concret en passant par les étapes de construction d'un PDP.

Créer un PDP

Voyons comment construire un PDP pas à pas, avec des explications de code en Python (sklearn et numpy) et un modèle Random Forest.

Pour ce tutoriel, on va créer un dataset factice, entraîner le modèle, puis calculer le Partial Dependence Plot (PDP) sans le tracer tout de suite.

1) Dataset factice

On commence par créer un dataset factice avec sklearn, puis on entraîne un Random Forest.

Pour l'instant, l'overfitting ne nous préoccupe pas : l'objectif de ce tutoriel n'est pas d'entraîner le meilleur modèle possible.

2) Choisir la ou les features d'intérêt

Ici, j'ai choisi un dataset à cinq features et entraîné un Random Forest regressor. On va se concentrer sur la feature d'indice 0 pour générer le PDP.

3) Maintenir les autres features constantes

Ensuite, on doit maintenir toutes les autres features constantes pendant qu'on fait varier les valeurs de la feature sélectionnée (celle d'indice 0 dans notre cas).

Simplifions un peu, car cette étape est essentielle.

Rappelle-toi que notre dataset contient 1000 observations (montrées à nouveau ci-dessous) :

Pour chaque échantillon du dataset :

• On fixe toutes les autres features.

• On fait varier les valeurs de la feature sélectionnée.

Disons qu'on fait varier la valeur de la feature sélectionnée dix fois. Cela signifie que :

• Pour le premier échantillon d'entraînement, on doit générer dix instances différentes.

• Pour le deuxième échantillon, on doit aussi générer dix instances différentes.

• Et ainsi de suite.

Plus formellement, cette étape consiste à créer plusieurs versions de chaque échantillon en modifiant la valeur de la feature sélectionnée, tout en gardant les autres inchangées.

Le code suivant s'en charge :

• D'abord, on définit la plage de valeurs de la feature choisie (par exemple, dix valeurs entre le min et le max de la feature).

• Ensuite, pour chaque valeur de la feature, on copie le dataset d'origine et on remplace les valeurs de la feature sélectionnée :

Dans ces deux morceaux de code, on utilise np.linspace pour créer dix valeurs entre le minimum et le maximum de la feature sélectionnée. On copie ensuite le dataset et on remplace la feature choisie par ces nouvelles valeurs, en gardant les autres constantes.

Si on regarde la taille du dataset obtenu, on constate qu'il est bien dix fois plus grand que le dataset d'origine :

Parfait !

C'est bien connu : plus on augmente le nombre de paramètres d'un modèle, plus il a tendance à faire de l'overfitting.

Prends par exemple une régression polynomiale entraînée sur ce dataset fictif :

age

Quand on augmente le degré (m) et qu'on entraîne le modèle, voilà ce qui est attendu :

• La loss d'entraînement se rapproche de plus en plus de zéro.

• La loss de test (ou de validation) baisse d'abord, puis grimpe de plus en plus.

C'est logique : avec un degré élevé, le modèle arrive plus facilement à contorsionner sa courbe pour passer par chaque point d'entraînement.

Le graphique de loss ci-dessous le confirme :

Mais regarde ce qui se passe quand on continue d'augmenter le degré (m) :

Étrange, non ?

Pourquoi la loss de test augmente jusqu'à un certain point, puis redescend ?

Tu ne t'y attendais pas, hein ?

Eh bien, ce que tu vois s'appelle le "double descent" (double descente). C'est un phénomène très courant dans de nombreux modèles de ML, surtout en deep learning.

Il montre que, de façon contre-intuitive, augmenter la complexité du modèle au-delà du point d'interpolation peut améliorer la généralisation.

Cette idée est d'ailleurs au cœur de la raison pour laquelle les LLM, pourtant gigantesques (des milliards, voire des milliers de milliards de paramètres), arrivent malgré tout à bien généraliser.

Et c'est difficile à accepter, parce que ce phénomène remet directement en cause le bias-variance trade-off (compromis biais-variance) qu'on apprend dans n'importe quel cours d'intro au ML :

Autrement dit, entraîner de très gros modèles, même avec plus de paramètres que de points d'entraînement, peut quand même donner une bonne généralisation.

À ma connaissance, la question reste ouverte, et on ne sait pas vraiment pourquoi les réseaux de neurones se comportent ainsi.

Il existe quand même des pistes autour de la régularisation, comme celle-ci :

Le modèle appliquerait une forme de régularisation implicite, qui lui permettrait de se concentrer précisément sur le bon nombre de paramètres pour généraliser.

Mais soyons honnêtes, rien n'est clair pour l'instant.

👉 À toi de jouer : j'aimerais savoir ce que tu penses de ce phénomène et de ses causes possibles.

👉 Envie d'aller plus loin ? DataXp t'attend → dataxp.fr

Une fois l'entraînement du réseau terminé, il te reste presque toujours un tas de neurones inutiles : des neurones qui ne contribuent quasiment pas à la performance du réseau, mais qui continuent à consommer de la mémoire.

Autrement dit, il existe un pourcentage élevé de neurones qui, si on les retire du réseau entraîné, n'affecteront pas la performance de façon notable :

Et bien sûr, je ne dis pas ça au hasard ou sans fondement.

J'ai vérifié ça expérimentalement, encore et encore, sur mes différents projets.

Voici l'idée de base.

Une fois l'entraînement terminé, on fait passer le dataset dans le modèle (sans backpropagation cette fois) et on analyse l'activation moyenne de chaque neurone.

On observe alors souvent que de nombreuses activations de neurones restent proches de zéro.

Ces neurones peuvent donc être supprimés du réseau (on parle de pruning), car ils auront très peu d'impact sur la sortie du modèle.

Pour ça, on peut fixer un seuil de pruning (λ) et supprimer tous les neurones dont l'activation est inférieure à ce seuil.

Ça a aussi du sens intuitivement.

Plus précisément, si un neurone atteint rarement une activation élevée, on peut raisonnablement supposer qu'il ne contribue pas à la sortie du modèle, et on peut donc le supprimer sans risque.

Le tableau suivant compare la précision du modèle pruné à celle du modèle original (complet), pour différents seuils de pruning (λ) :

Remarque un truc ici.

Avec un seuil de pruning λ=0.4, la précision de validation du modèle ne baisse que de 0,62 %, mais le nombre de paramètres chute, lui, de 72 %.

C'est une réduction énorme, alors que les deux modèles restent quasiment aussi bons !

Bien sûr, il y a un compromis, puisqu'on ne fait pas aussi bien que le modèle original.

Mais dans beaucoup de cas, surtout quand on déploie des modèles de ML en production, la précision n'est pas la seule métrique qui compte.

D'autres métriques opérationnelles, comme l'efficacité, la vitesse ou la consommation mémoire, entrent aussi en jeu, et de façon décisive.

C'est pour ça que les techniques de compression de modèles sont si importantes dans ces cas-là.

Si tu veux creuser le sujet, on en parle en détail dans ce dossier complémentaire : Model Compression : une étape critique vers un Machine Learning efficace.

Aujourd'hui, on n'a vu qu'une seule technique (l'activation pruning), mais le mini-cours en couvre 6, avec leur implémentation en PyTorch.

Compression de modèles : un levier clé pour un machine learning efficace

Apprends les techniques essentielles de compression de modèles ML : pruning, factorisation et quantification pour réduire l'empreinte et accélérer l'inférence.

👉 À toi de jouer : quelles sont, selon toi, d'autres façons de rendre les modèles de ML plus adaptés à la production ?

👉 Envie d'aller plus loin ? DataXp t'attend → dataxp.fr

La duplication de données est un gros problème auquel de nombreuses organisations sont confrontées.

Ça pose problème parce que :

• Ça gaspille de l'espace de stockage.

• Ça peut mener à des analyses de données incorrectes.

• Ça peut entraîner des erreurs de reporting, et bien plus encore.

En lisant ça, tu te dis peut-être qu'on peut supprimer les doublons avec des méthodes classiques comme df.drop_duplicates().

Utiliser Pandas pour supprimer les doublons

Mais que se passe-t-il si tes données contiennent des doublons flous ?

Les doublons flous, ce sont des enregistrements qui ne sont pas des copies exactes les uns des autres, mais qui, d'une manière ou d'une autre, semblent désigner la même chose. C'est ce que montre l'exemple ci-dessous :

Les enregistrements ont le même prénom, une adresse similaire, et un numéro de téléphone presque identique.

La méthode Pandas sera inefficace, car elle ne supprime que les doublons exacts.

Alors, que faire ?

Imaginons que tes données contiennent plus d'un million d'enregistrements.

Comment identifierais-tu les doublons flous dans ce dataset ?

Une première option serait de comparer naïvement chaque paire d'enregistrements, comme illustré ci-dessous :

Comparer chaque paire d'enregistrements

On peut définir une métrique de distance pour chaque champ et générer un score de similarité pour chaque paire d'enregistrements.

Mais cette approche est irréalisable à grande échelle.

Par exemple, sur un dataset d'à peine un million d'enregistrements, comparer chaque paire donnerait 10¹² comparaisons (n²).

Complexité de l'approche naïve

Même en supposant une vitesse correcte de 10 000 comparaisons par seconde, cette approche prendrait environ 3 ans pour se terminer.

Peut-on faire mieux ?

Bien sûr que oui !

Mais d'abord, il faut comprendre une propriété particulière des doublons flous.

Si deux enregistrements sont des doublons, ils vont forcément partager un certain chevauchement lexical (ou textuel).

Par exemple, prends le dataset ci-dessous :

Ici, comparer le prénom "Daniel" à "Philip" ou "Shannon" à "Julia" n'a aucun sens. Il n'y a littéralement aucun chevauchement lexical.

Ils sont donc garantis d'être des enregistrements distincts.

Ça fait aussi sens intuitivement.

Si on appelle deux enregistrements des "doublons", il doit forcément y avoir un chevauchement lexical.

Pourtant, l'approche naïve va quand même perdre du temps à les comparer.

On peut exploiter cette propriété de "chevauchement lexical" des doublons pour réduire intelligemment le nombre total de comparaisons.

Plus précisément, on segmente les données en plus petits buckets en appliquant certaines règles.

Par exemple, reprends le dataset précédent. Une règle possible serait de créer des buckets basés sur les trois premières lettres du prénom.

Grouper les données selon des règles

Ainsi, on ne comparera deux enregistrements que s'ils se trouvent dans le même bucket.

Si les trois premières lettres sont différentes, les enregistrements tomberont dans des buckets différents. Ils ne seront donc jamais comparés.

Après avoir segmenté les enregistrements, on aurait éliminé près de 98-99 % des comparaisons inutiles qui auraient eu lieu sinon.

Enfin, on peut appliquer notre algorithme de comparaison naïf sur chaque bucket, individuellement.

Grouper les enregistrements selon des règles

L'approche optimisée peut tourner en quelques heures seulement, au lieu de prendre des années.

De cette manière, on réduit drastiquement le temps d'exécution tout en obtenant une excellente précision de dédoublonnage.

Plutôt cool, non ?

Bien sûr, il faudra analyser les données en profondeur pour définir ces règles de segmentation.

Mais qu'est-ce qui est le plus malin :

• Utiliser l'approche naïve, qui prend trois ans à tourner, OU,

• Passer un peu de temps à analyser les données, concevoir des règles, et exécuter le dédoublonnage en quelques heures ?

👉 À toi de jouer : peux-tu encore optimiser cette approche ?

👉 Envie d'aller plus loin ? DataXp t'attend → dataxp.fr

Introduction

Dans le dossier de la semaine dernière, tu as découvert les rouages internes des Kolmogorov Arnold Networks (KAN) et leur fonctionnement.

Kolmogorov Arnold Networks (KAN) : le guide complet pour les data scientists

Découvre comment fonctionnent les Kolmogorov Arnold Networks : théorèmes fondateurs, B-splines, entraînement, et comparaison détaillée face aux MLP.

À la fin de ce mini-cours, on avait annoncé un second volet consacré à l'implémentation concrète des KAN avec PyTorch. Le voici.

Pourquoi ce sujet ?

Ce dossier me semble important parce qu'on sait tous construire et entraîner un réseau de neurones avec des matrices de poids classiques.

Mais les KAN reposent sur une idée différente. Les matrices que possède un KAN dans une couche ne contiennent pas des poids, mais des fonctions, appliquées à l'entrée de cette couche.

En implémentant les KAN, tu vas donc comprendre comment on entraîne un réseau qui ne repose pas sur les matrices de poids traditionnelles, mais sur des fonctions univariées.

C'est parti !

Comme on l'a vu dans ce dossier précédent, les KAN remettent en question la conception classique des réseaux de neurones et proposent un nouveau paradigme pour les concevoir et les entraîner.

En résumé, l'idée est que plutôt que d'empiler simplement des couches les unes sur les autres (qui sont toujours des transformations linéaires, la non-linéarité étant introduite volontairement via des fonctions d'activation), les KAN proposent une approche alternative.

Les auteurs utilisent des fonctions apprenables complexes (appelées B-splines) qui permettent de représenter directement des transformations non linéaires de l'entrée, avec relativement moins de paramètres qu'un réseau traditionnel.

Si tu observes bien l'image ci-dessus :

• Dans un réseau de neurones classique, les fonctions d'activation sont fixes sur tout le réseau, et elles existent sur chaque nœud (illustré ci-dessous).

• Dans un KAN, en revanche, les fonctions d'activation existent sur les arêtes (qui correspondent aux poids d'un réseau traditionnel), et chaque arête possède sa propre fonction d'activation.

Il paraît donc logique de s'attendre à ce qu'un KAN soit beaucoup plus précis et interprétable, avec moins de paramètres.

Les KAN s'appuient sur le théorème de représentation de Kolmogorov-Arnold, qui affirme que toute fonction continue multivariée peut être représentée comme la composition d'un nombre fini de fonctions continues à une seule variable.

Si on développe les termes de la somme, on obtient ceci :

En résumé, tout ce qu'on fait dans une couche KAN, c'est prendre l'entrée (x₁, x₂, ..., xₙ) et lui appliquer une transformation φ.

φ₁ désigne la transformation de la première couche.

La matrice de transformation φ₁ (correspondant à la première couche) peut donc être représentée ainsi :

Dans cette matrice :

• n désigne le nombre d'entrées.

• m désigne le nombre de nœuds de sortie de cette couche.

• [IMPORTANT] Les éléments de la matrice ne sont pas des nombres, ce sont des fonctions univariées. Par exemple :

  • φ₁₁ pourrait être 2x² − 3x + 4.

  • φ₁₂ pourrait être 4x³ + 5x² + x − 2.

  • et ainsi de suite...

Pour générer une transformation, il suffit donc de prendre le vecteur d'entrée et de le faire passer à travers les fonctions correspondantes de cette matrice de transformation :

On obtient alors le vecteur suivant :

Ce vecteur est la sortie de la première couche, qui est ensuite transmise à la couche suivante pour une nouvelle transformation.

Le réseau KAN complet peut donc se condenser en une seule formule :

Où :

• x désigne le vecteur d'entrée

• φₖ désigne la matrice de transformation fonctionnelle de la couche k.

• KAN(x) est la sortie du réseau KAN.

Dans un KAN, les matrices φₖ sont elles-mêmes des matrices de transformation non linéaires, et chaque fonction univariée peut être très différente d'une autre.

Mais comment estime-t-on les fonctions univariées de chacune de ces matrices de transformation ?

Comme on l'a vu dans le dossier d'introduction aux KAN, on utilise des B-splines pour cela.

Rappelle-toi que dès qu'on crée une B-spline, on dispose déjà de points de contrôle (P₁, P₂, …, Pₙ), ainsi que des fonctions de base sous-jacentes déterminées par le degré k.

Et en faisant varier la position des points de contrôle, on obtient différentes courbes, comme le montre l’animation ci-dessous :

Voici donc l'idée centrale des KAN :

C'est tout.

En ajustant la position des points de contrôle pendant l'entraînement, le modèle KAN peut façonner dynamiquement les fonctions d'activation qui correspondent le mieux aux données.

• On part de positions initiales pour les points de contrôle, exactement comme on le fait pour des poids.

• Pendant l'entraînement, on met à jour la position de ces points de contrôle par rétropropagation, de la même manière qu'on met à jour les poids d'un réseau de neurones.

• On utilise un algorithme d'optimisation (par exemple la descente de gradient) pour ajuster les points de contrôle afin que le modèle minimise la fonction de perte.

Mathématiquement, dans un KAN, chaque fonction d'activation φ(x) est définie ainsi :

Où :

• Le calcul fait intervenir une fonction de base b(x) (un peu comme une connexion résiduelle).

• spline(x) est apprenable, plus précisément les paramètres cᵢ, qui désignent la position des points de contrôle.

• Il y a un autre paramètre, w. Les auteurs précisent que, en théorie, w est redondant puisqu'il peut être absorbé dans b(x) et spline(x). Ils l'ont néanmoins conservé pour mieux contrôler l'amplitude globale de la fonction d'activation.

Une fois cette définition posée, le réseau s'entraîne exactement comme n'importe quel autre réseau de neurones.

Plus précisément :

• On initialise chacune des matrices phi comme ceci :

• On exécute la forward pass :

• On calcule la perte et on effectue la rétropropagation.

Voilà !

Implémentation d'un KAN

Dans cette section, on va implémenter un KAN avec PyTorch.

Mais on va se limiter à une implémentation simplifiée des KAN.

Le plan de travail

Voici les étapes :

• On doit d'abord définir une entité "arête" (edge) du réseau, qui sera une fonction univariée composée d'une spline, d'une SiLU, et d'un unique paramètre de poids :

• Ensuite, on doit définir une couche personnalisée du réseau, composée d'un arrangement matriciel de ces fonctions univariées :

• On définira ensuite notre classe réseau, qui sera une composition de ces couches personnalisées connectées entre elles.

• Enfin, on créera un jeu de données factice, on définira un optimiseur et une fonction de perte, et on entraînera le modèle.

Cela posé, passons à l'implémentation.

Quand on repère des valeurs manquantes dans un dataset, la plupart des gens se lancent directement dans leur imputation.

Mais aussi contre-intuitif que ça puisse paraître, la première étape vers l'imputation des données manquantes ne doit JAMAIS être l'imputation.

La vraie première étape, c'est de comprendre la raison derrière cette absence de données. Pourquoi ? Parce que la stratégie d'imputation dépend en grande partie du POURQUOI ces données manquent.

Plus précisément, l'absence de données peut être de trois types :

• Missing completely at random (MCAR).

• Missing at random (MAR).

• Missing not at random (MNAR).

C'est seulement une fois qu'on a identifié la raison qu'on peut passer aux bonnes techniques d'imputation.

C'est quoi le MCAR, le MAR et le MNAR ? On décortique tout ça aujourd'hui.

1) Missing completely at random (MCAR)

Le MCAR, c'est une situation où les données manquent vraiment au hasard, sans aucun lien avec une variable observée ou non observée.

Autrement dit, les points de données manquants ne suivent aucun schéma identifiable.

Par exemple, dans des réponses à un sondage avec des valeurs manquantes, supposer le MCAR reviendrait à dire que certains participants ont, sans le faire exprès, sauté au hasard telle ou telle question.

Cela dit, d'après mon expérience, le MCAR est le plus souvent une hypothèse peu réaliste. Autrement dit, dans la grande majorité des datasets réels avec des valeurs manquantes, les données ne sont généralement pas MCAR.

Pourquoi ? Parce que dans des scénarios réels, l'apparition de données manquantes est souvent influencée par un facteur, observé ou non.

Le comportement humain, la manière dont le sondage a été administré, ou n'importe quel événement externe peuvent être à l'origine de valeurs manquantes dans un dataset.

Par exemple, des participants peuvent choisir volontairement de ne pas répondre à des questions sensibles, ou certains groupes peuvent être plus enclins à ne pas répondre du tout, ce qui crée des données manquantes.

C'est pour ça que supposer le MCAR n'est une hypothèse raisonnable que si tu connais le processus de collecte de données de bout en bout et/ou que tu as une expertise métier sur le sujet.

C'est là qu'il devient essentiel, pour un data scientist, d'échanger avec les data engineers et de comprendre le processus de collecte des données. D'ailleurs, ça ne concerne pas que le MCAR, ça s'applique aussi aux deux autres situations qu'on va voir juste après.

Comprendre le processus de collecte de données ne fera JAMAIS de mal.

Cela dit, rien ne nous empêche de supposer que les valeurs manquantes sont MCAR, si ça semble être une hypothèse raisonnable au vu de l'analyse, et/ou des retours d'experts métier, et/ou après avoir compris le mécanisme de collecte des données.

Tu peux alors utiliser les techniques d'imputation univariée les plus simples.

2) Missing at random (MAR)

Le MAR, c'est une situation où l'absence de valeurs pour une feature peut s'expliquer par d'autres features observées dans le dataset.

Contrairement au MCAR, le MAR est bien plus fréquent en pratique.

Dans ce cas, l'absence de données peut être expliquée avec une précision raisonnable grâce à des méthodes statistiques adaptées.

Ainsi, même si la donnée est manquante, son apparition peut (dans une certaine mesure) être estimée à partir des informations déjà disponibles dans le dataset.

Une façon courante d'identifier le MAR consiste à conditionner sur une autre feature observée, et à observer si la probabilité de valeur manquante augmente.

Par exemple, dans une enquête sur la performance scolaire, les étudiants avec de meilleures notes seraient peut-être moins enclins à révéler le nombre d'heures qu'ils passent à étudier (par esprit de compétition, sans doute).

C'est là que des techniques comme l'imputation par kNN, Miss Forest, etc., se montrent particulièrement efficaces. Elles utilisent d'autres features observées pour imputer la feature manquante.

Si tu veux creuser le sujet, on en a déjà parlé ici :

• Le shot data sur l'imputation par kNN. Voici comment ça fonctionne :

• Le shot data sur l'imputation par Miss Forest. Voici comment ça fonctionne :

3) Missing not at random (MNAR)

Le MNAR est la situation la plus compliquée des trois.

Dans le MNAR, l'absence de données est due soit à la valeur manquante elle-même, soit aux features pour lesquelles on n'a pas collecté de données.

Autrement dit, dans le MNAR, il existe un schéma bien défini dans les variables manquantes. Sauf que ce schéma n'a aucun lien avec les features observées.

Par exemple, dans une enquête de santé, des participants avec un niveau de stress très élevé pourraient choisir consciemment de ne pas révéler ce niveau de stress, par peur du jugement ou de la stigmatisation.

Résultat : l'absence de données sur le niveau de stress n'a rien d'aléatoire. Elle est directement influencée par le niveau de stress lui-même.

En quelque sorte, plus le niveau de stress est élevé, moins la personne est susceptible de le révéler, et plus la valeur a de chances de manquer dans le dataset collecté.

L'absence de données dépend donc directement de la variable qui manque elle-même.

C'est piégeux, non ?

Il n'y a pas grand-chose à faire pour régler ça, à part collecter plus de données ou de features. Et l'expertise métier devient alors extrêmement précieuse pour gérer intelligemment le MNAR et améliorer le processus de collecte.

Parfois, j'ai aussi préféré utiliser les techniques d'imputation classiques (celles employées pour le MCAR et le MAR), tout simplement parce que collecter plus de données n'est pas toujours faisable.

Mais comme on l'a vu plus haut, il existe un schéma d'absence de données bien défini dans le MNAR, et il peut être important. Or, une imputation directe fera disparaître cette information.

Une façon de conserver ce schéma est d'ajouter une feature binaire, qui indique si la valeur a été imputée ou non.

Ainsi, l'algorithme de ML peut quand même accéder à ces schémas de données manquantes, et les apprendre.

👉 À toi de jouer : quels autres points aimerais-tu ajouter sur le MCAR, le MAR et le MNAR ?

👉 Envie d'aller plus loin ? DataXp t'attend → dataxp.fr

Le maximum likelihood estimation (MLE) et l'expectation maximization (EM) sont deux techniques populaires pour déterminer les paramètres de modèles statistiques.

En raison de leur application dans DE NOMBREUX modèles statistiques, j'ai vu cette distinction revenir dans pas mal d'entretiens en data science, en particulier la différence entre les deux.

Alors aujourd'hui, on va les comprendre en détail : comment ils fonctionnent, et quelles sont leurs différences.

C'est parti !

Maximum likelihood estimation (MLE)

Le MLE part d'un jeu de données labellisé et vise à déterminer les paramètres du modèle statistique qu'on essaie d'ajuster.

Étant donné des données labellisées, trouve les paramètres du modèle.

Le processus est plutôt simple et direct.

Avec le MLE, on :

• Commence par supposer un processus de génération des données. En clair, ce processus de génération des données reflète notre hypothèse sur la distribution du label de sortie (y), étant donné l'entrée (X).

Suppose un processus de génération des données

• Ensuite, on définit la vraisemblance (likelihood) d'observer les données. Comme chaque observation est indépendante, la vraisemblance d'observer l'ensemble des données correspond au produit des vraisemblances de chaque observation individuelle :

Définis la fonction de vraisemblance

• La fonction de vraisemblance ci-dessus dépend des valeurs des paramètres (θ). Notre objectif est de déterminer les valeurs de paramètres spécifiques qui maximisent cette fonction de vraisemblance. On procède comme suit :

Cela nous donne les estimations de paramètres qui auraient le plus vraisemblablement généré les données observées.

C'était plutôt simple, non ?

Mais que fait-on si on n'a pas de vrais labels ?

On veut quand même estimer les paramètres, non ?

Données non labellisées

Le MLE, comme tu l'as peut-être deviné, ne s'applique pas ici. Le vrai label (y), n'étant pas observé, rend impossible la définition d'une fonction de vraisemblance comme on l'a fait précédemment.

Dans ce genre de cas, des techniques plus avancées comme l'expectation maximization sont bien utiles.

Expectation maximization (EM)

L'EM est une technique d'optimisation itérative pour estimer les paramètres de modèles statistiques. Elle est particulièrement utile quand on a un label non observé (ou caché).

Voici un exemple de situation type :

Données issues de plusieurs distributions

Comme illustré ci-dessus, on suppose que les données ont été générées à partir de plusieurs distributions (un mélange). Cependant, les données observées/complètes ne contiennent pas cette information.

Autrement dit, le jeu de données observé ne précise pas si une ligne donnée a été générée par la distribution 1 ou la distribution 2.

L'EM nous aide à estimer les paramètres de ce type de jeux de données.

L'idée centrale derrière l'EM est la suivante :

• On fait une hypothèse sur les paramètres initiaux (θ).

• Étape Expectation (E) : on calcule les probabilités a posteriori du label non observé (appelons-le « z ») à l'aide des paramètres ci-dessus.

• Puisqu'on dispose désormais d'un proxy (pas précis, certes) pour le vrai label, on peut définir une fonction de « vraisemblance espérée ». On utilise donc les probabilités a posteriori ci-dessus pour ça :

• Étape Maximization (M) : on a maintenant une fonction de vraisemblance avec laquelle travailler. La maximiser par rapport aux paramètres nous donne une nouvelle estimation des paramètres (θ').

• Ensuite, on utilise les paramètres mis à jour (θ') pour recalculer les probabilités a posteriori définies lors de l'étape d'expectation.

• On met à jour la fonction de vraisemblance (L) à l'aide des nouvelles probabilités a posteriori.

• Là encore, la maximiser nous donne une nouvelle estimation des paramètres (θ).

• Et ce processus se répète encore et encore jusqu'à convergence.

L'idée, c'est qu'avec l'expectation maximization, on itère continuellement entre les étapes E et M jusqu'à ce que les paramètres convergent.

Un bon point pour l'EM, c'est qu'il converge toujours. Pourtant, il peut parfois converger vers un extremum local.

J'ai préparé le visuel suivant, qui résume bien les différences entre MLE et EM :

MLE vs EM est une question fréquemment posée dans de nombreux entretiens de data science.

Si le MLE est relativement facile à comprendre, l'EM est un peu plus complexe.

Si ça t'intéresse d'apprendre l'expectation maximization de façon pratique, et de le coder from scratch en Python (en utilisant seulement NumPy)...

…alors on a couvert ça en détail dans ce deep dive :

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.

👉 À toi de jouer : dans le résumé visuel ci-dessus, peux-tu ajouter d'autres modèles pour le MLE et pour l'EM ?

👉 Envie d'aller plus loin ? DataXp t'attend → dataxp.fr

D'ailleurs, en parlant de bases solides...

La documentation de NumPy est plutôt intimidante, à mon avis.

Si tu veux apprendre à t'en servir, tu as de fortes chances d'être découragé par ses pages de référence API :

Si tu es dans ce cas, j'ai justement préparé ce cheat sheet NumPy qui regroupe les 40 méthodes les plus utilisées de la librairie :

Après plus de 4,5 ans à utiliser NumPy, je peux te dire sans hésiter que tu utiliseras ces méthodes 95 % du temps quand tu travailles avec NumPy.

Il y a un truc important à comprendre : quand tu apprends une nouvelle librairie, tu n'as pas besoin de maîtriser (ni même de pratiquer) chacune de ses méthodes.

Mets plutôt le principe de Pareto à contribution :)

👉 À toi de jouer : est-ce que j'ai oublié une méthode courante ?

La plupart des réseaux de neurones pour la classification multiclasse sont entraînés avec la cross-entropy loss :

Sauf qu'elle n'est pas toujours adaptée à certaines situations.

Plus précisément, une des plus grosses erreurs qu'on commet, c'est de ne pas vraiment comprendre la nature intrinsèque de son dataset.

Pour illustrer ça, dans beaucoup de tâches de classification réelles, les labels de classe possèdent souvent un ordre relatif entre eux (on parle alors de datasets ordinaux) :

La détection de tranche d'âge (enfant, adolescent, jeune adulte, âge mûr et senior) en est un bon exemple : les labels y ont une relation ordonnée.

Sauf que la cross-entropy ignore complètement cette notion.

Résultat : le modèle a du mal à différencier les labels adjacents, ce qui mène à des performances sous-optimales et à des incohérences de classement.

Par « incohérences de classement », on entend les situations où les probabilités prédites pour des labels adjacents ne respectent pas leur ordre naturel.

Par exemple, si le modèle prédit une probabilité plus faible pour le label child que pour le label teenager, alors que teenager suit logiquement child dans la hiérarchie des âges, ça constitue une incohérence de classement.

On peut aussi voir les choses autrement : disons que le vrai label pour un exemple donné est young adult. Dans ce cas, on voudrait que notre classifieur indique que l'exemple est « au moins un enfant », « au moins un adolescent » et « au moins un jeune adulte ».

Sauf que, comme la cross-entropy loss traite chaque tranche d'âge comme une catégorie séparée sans ordre intrinsèque, le modèle a du mal à apprendre et à généraliser la progression correcte de l'âge.

Les datasets ordinaux sont assez fréquents dans l'industrie, et les modèles de classification classiques produisent presque toujours des résultats sous-optimaux dans ce genre de cas.

Avec une attention particulière et les bonnes techniques, on peut non seulement rendre les modèles de ML plus interprétables, mais aussi produire des modèles plus précis.

Quelles sont ces techniques ?

Si ça t'intrigue, c'est justement le sujet de notre dernier deep dive ML : Tu es probablement en train de construire des modèles de classification incohérents sans même t'en rendre compte.

CORAL : comment forcer tes réseaux de neurones à respecter l'ordre naturel des classes

Découvre CORAL, la méthode qui force tes réseaux de neurones à respecter l'ordre des classes. Théorie, loss function et implémentation PyTorch complète.

La cross-entropy est sans aucun doute l'une des fonctions de loss les plus utilisées pour entraîner des modèles de classification multiclasse, mais elle n'est pas toujours adaptée à certaines situations.

Pourtant, beaucoup de gens continuent d'utiliser la cross-entropy, peu importe le type de dataset auquel ils font face.

Découvrir le framework avancé dont on parle dans l'article ci-dessus t'aidera à prendre des décisions éclairées dans la construction de tes modèles. On y implémente aussi l'idée pour une compréhension complète.

Lis l'article ici : Tu es probablement en train de construire des modèles de classification incohérents sans même t'en rendre compte.

Je suis sûr que tu vas apprendre quelque chose d'utile aujourd'hui.

👉 À toi de jouer : quels sont, selon toi, d'autres défis liés aux modèles de classification nominale ?

C'est exactement la question qu'un doctorant m'a forcé à me poser, le jour où il m'a tendu un échantillon de son dataset à annoter.

Ça a piqué ma curiosité : pourquoi avait-il besoin de labels humains alors qu'il disposait déjà de labels de ground truth ?

Alors j'ai posé la question.

Ce que j'ai appris ce jour-là a changé mon approche de l'amélioration incrémentale des modèles, et je suis sûr que cette idée va aussi te fasciner.

Laisse-moi t'expliquer ce que j'ai appris.

Imagine qu'on construise un modèle de classification multiclasse. Disons que c'est un modèle qui classe une image en entrée comme pierre, feuille ou ciseaux :

En calculant l'accuracy de validation par classe, on obtient les résultats suivants :

• Classe Feuille : 97%

• Classe Pierre : 82%

• Classe Ciseaux : 75%

Question : quelle classe irais-tu inspecter et améliorer en priorité, intuitivement ?

En regardant ces résultats, la plupart des gens pensent que “Ciseaux” est la classe la moins performante et qu'elle mérite d'être approfondie.

Mais ce n'est peut-être pas vrai.

Et c'est précisément ce que ce doctorant voulait vérifier en collectant des labels humains.

Disons que les labels humains nous donnent les résultats suivants :

Au vu de ça, penses-tu toujours que le modèle performe le moins bien sur la classe “Ciseaux” ?

Non, pas vrai ?

Enfin, bien sûr, le modèle a l'accuracy la plus faible sur la classe “Ciseaux”, je ne le nie pas.

Mais avec plus de contexte, on remarque que le modèle s'en sort plutôt bien sur la classe “Ciseaux”. En effet, un humain moyen n'obtient que 2% d'accuracy de plus que ce que notre modèle atteint.

En revanche, ces résultats révèlent, de façon assez surprenante, que c'est en réalité la classe “Pierre” qui mérite le plus d'attention. L'écart d'accuracy entre un humain moyen et le modèle est bien trop élevé (13%).

Sans cette information, on aurait continué à améliorer la classe “Ciseaux”, alors qu'en réalité, c'est “Pierre” qui a le plus besoin d'être travaillée.

Depuis que j'ai appris cette technique, je la trouve super utile pour déterminer mes prochaines étapes d'amélioration de modèle, quand c'est possible.

Je dis « quand c'est possible » parce que je sais que beaucoup de datasets sont difficiles à interpréter et à labelliser pour des humains.

Malgré tout, si c'est faisable de mettre en place une telle « baseline humaine », on y gagne énormément de clarté sur la façon dont le modèle performe.

Résultat : on peut rediriger efficacement ses efforts d'ingénierie dans la bonne direction.

Bien sûr, je ne prétends pas que ça soit universellement utile dans tous les cas d'usage.

Par exemple, si le modèle performe déjà mieux que la baseline, les améliorations suivantes devront s'appuyer sur les résultats passés.

Cela dit, dans ce genre de cas, dépasser une baseline humaine permet au moins de valider que le modèle fait mieux que ce qu'un humain peut faire.

Une super technique, non ?

👉 À toi de jouer : quelles autres méthodes utilises-tu pour orienter tes efforts d'amélioration de modèle ?

Il y a quelques jours, on a vu comment la régularisation L2 nous aide à traiter la multicolinéarité :

La face cachée de la régularisation L2

La régularisation L2 fait bien plus que réduire l'overfitting. Découvre comment elle élimine la multicolinéarité et donne son nom à la ridge regression.

La multicolinéarité apparaît quand deux (ou plusieurs) features sont fortement corrélées OU quand deux (ou plusieurs) features permettent de prédire une autre feature :

L'idée centrale de ce post était la suivante : imagine qu'on utilise une régression linéaire, et que le dataset présente de la multicolinéarité.

Dans ce cas…

• Sans régularisation L2, il est impossible d'obtenir une valeur unique pour les paramètres (θ) qui minimise la RSS.

• La régularisation L2 permet de résoudre ce problème et d'obtenir une solution optimale.

C'est ce qu'illustre le schéma ci-dessous :

Voici le shot data en question si tu ne l'as pas encore lu (ou si tu veux te rafraîchir la mémoire) : La régularisation L2 est bien plus magique qu'on ne le pense.

Je mentionne ce shot data ici parce qu'en plus de réduire l'overfitting et de traiter la multicolinéarité, il y a un autre problème, moins souvent évoqué, que la régularisation L2 résout très bien, et qui est lié à la multicolinéarité.

Aujourd'hui, je veux justement en parler.

C'est parti !

Regarde la solution OLS qu'on obtient avec la régression linéaire :

Lis ce shot data pour comprendre la démonstration

• X est la matrice des variables indépendantes (dimension : n*m).

• y est le vecteur des targets (dimension : n*1).

• θ est le vecteur de poids (dimension : m*1).

Si on regarde de plus près, on voit que la solution OLS n'existe que si la matrice (XᵀX) est inversible.

Mais un problème survient quand le nombre de features (m) dépasse le nombre de points de données (n), c'est à dire quand m>n. Dans ce cas, cette matrice ne sera pas inversible.

Pour simplifier, imagine qu'on a la matrice d'entrée X suivante, qui a plus de features que de lignes :

Ici, il est TOUJOURS possible de représenter, disons, la troisième colonne comme une combinaison linéaire des deux premières colonnes. C'est ce qu'on voit ci-dessous :

Le système d'équations linéaires ci-dessus admet une solution pour ‘a’ et ‘b’.

Ça montre que tous les datasets dont le nombre de features dépasse le nombre de lignes présentent une multicolinéarité parfaite.

C'est parce que n'importe quelle colonne sera TOUJOURS une combinaison linéaire de deux autres colonnes.

En termes plus mathématiques, quand (m>n), on obtient toujours un système d'équations linéaires où le nombre d'inconnues (a et b ci-dessus) est égal au nombre d'équations qu'on peut générer.

En revanche, si notre dataset avait contenu plus de lignes que de colonnes (n>m), il n'aurait pas été possible de résoudre ce système d'équations linéaires (sauf si le dataset possédait lui-même de la multicolinéarité) :

Maintenant, étant donné que tout dataset dont le nombre de colonnes dépasse le nombre de lignes présente une multicolinéarité parfaite, on peut revenir à ce qu'on a vu dans le shot data précédent.

Sans la pénalité L2, le graphique des résidus forme une vallée. Résultat : il est impossible d'obtenir une valeur unique pour les paramètres (θ) qui minimise la RSS. C'est ce qu'on voit ci-dessous :

Avec la pénalité L2, en revanche, on obtient le graphique suivant, qui fait disparaître la vallée observée plus tôt et donne un minimum global à l'erreur RSS :

Désormais, il est possible d'obtenir une valeur unique pour les paramètres (θ) qui minimise la RSS.

En fait, il existe une autre façon de démontrer que si X (peu importe ses dimensions) présente une multicolinéarité parfaite, la régularisation L2 nous aide à l'éliminer.

Reprenons la matrice 2*4 ci-dessus, et appliquons la combinaison linéaire aux troisième et quatrième colonnes :

En calculant XᵀX sur le résultat final, on obtient une matrice non inversible :

Ça montre que si le dataset X (peu importe sa forme) présente une multicolinéarité parfaite, XᵀX ne sera pas inversible (garde ça en tête, on va y revenir bientôt).

Passons à la suite : regardons la fonction de perte avec la pénalité L2 :

L'objectif est de trouver les paramètres θ qui minimisent cette fonction.

On dérive donc l'expression ci-dessus par rapport à θ, et on l'égale à zéro :

Ensuite, on résout pour θ, ce qui donne :

Remarque quelque chose ici.

La solution OLS n'inverse plus XᵀX directement. À la place, une matrice diagonale supplémentaire s'ajoute à XᵀX, ce qui rend le résultat inversible (λ≠0) :

Voilà une autre preuve de comment la régularisation nous aide à éliminer la multicolinéarité.

Retiens donc que la régularisation L2 n'est pas juste un remède pour réduire l'overfitting. Elle est aussi utile pour éliminer la multicolinéarité.

J'espère que tu as appris quelque chose de nouveau aujourd'hui :)

Si tu veux en savoir plus sur l'origine probabiliste de la régularisation L2, va voir ce dossier :

Découvrir la Régularisation par les Probabilités

Découvre comment éviter le surapprentissage en machine learning grâce à la régularisation par probabilités et techniques MLE pour des modèles performants et généralisables.

👉 À toi de jouer : quels sont, selon toi, d'autres avantages de la régularisation L2 ?

Introduction

Tu as sans doute déjà croisé le nom des Kolmogorov Arnold Networks (KAN) dans tes lectures ou tes veilles techniques. Pas de souci si tu ne sais pas exactement ce que c'est ni comment ça fonctionne, c'est précisément l'objet de ce deep dive.

Les KAN suscitent beaucoup d'attention parce qu'ils remettent en question la conception classique des réseaux de neurones et proposent un nouveau paradigme pour les concevoir et les entraîner.

En résumé, l'idée est la suivante. Plutôt que d'empiler simplement des couches les unes sur les autres (qui sont toujours des transformations linéaires, la non-linéarité étant introduite volontairement via des fonctions d'activation), les KAN proposent une approche alternative.

Les auteurs utilisent des fonctions apprenables complexes, appelées B-Splines, qui permettent de représenter directement des transformations non linéaires de l'entrée, avec relativement moins de paramètres qu'un réseau de neurones traditionnel.

Si tu regardes attentivement l'image ci-dessus :

• Dans un réseau de neurones classique, les fonctions d'activation sont fixes sur l'ensemble du réseau, et elles existent sur chaque nœud (illustré ci-dessous).

• Dans un KAN, en revanche, les fonctions d'activation existent sur les arêtes (qui correspondent aux poids d'un réseau traditionnel), et chaque arête possède sa propre fonction d'activation, différente des autres.

Il devient donc naturel de s'attendre à ce qu'un KAN soit beaucoup plus précis et interprétable, avec moins de paramètres.

Dans la suite, on va plonger dans les détails techniques de leur fonctionnement.

C'est parti !

Théorème d'approximation universelle

Le théorème d'approximation universelle (Universal Approximation Theorem, UAT) constitue le fondement théorique des réseaux de neurones que tu utilises au quotidien.

En résumé, il stipule qu'un réseau de neurones possédant une seule couche cachée contenant un nombre fini de neurones peut approximer N'IMPORTE QUELLE fonction continue avec une précision raisonnable sur un sous-ensemble compact de ℝⁿ, à condition d'utiliser des fonctions d'activation adaptées.

Les points clés :

• Structure du réseau : une seule couche cachée.

• Approximation de fonction : n'importe quelle fonction continue peut être approximée.

• Fonction d'activation : elle doit être non linéaire et adaptée (par exemple sigmoïde, ReLU).

Mathématiquement, pour toute fonction continue f et tout ε > 0, il existe toujours un réseau de neurones f̂ tel que :

Ce résultat n'a d'abord été démontré que pour l'activation sigmoïde, lors de sa première formulation en 1989. En 1991, il a été étendu à une large classe de fonctions d'activation non polynomiales.

L'intuition sous-jacente est qu'une fonction constante par morceaux (piecewise) peut approximer n'importe quelle fonction continue sur un ensemble borné.

Par exemple, la courbe du cosinus entre −π/2 et π/2 peut être approximée par plusieurs paliers ajustés à cette courbe.

Naturellement, plus le nombre de paliers augmente, meilleure est l'approximation. Pour généraliser, un réseau de neurones à une seule couche cachée peut associer chacun de ses neurones à une fonction en palier.

En utilisant les poids et les biais comme des portes logiques, chaque neurone peut déterminer si une entrée tombe dans sa région désignée.

Pour les entrées qui tombent dans la section attribuée à un neurone, un poids fortement positif poussera la sortie du neurone vers 1 avec une activation sigmoïde. À l'inverse, un poids fortement négatif poussera la sortie vers 0 si l'entrée n'appartient pas à cette section.

Les réseaux de neurones actuels sont bien plus complexes et volumineux, et ils ne se contentent plus d'estimer de simples fonctions en escalier. Il subsiste néanmoins un certain mécanisme de "gating" : certains neurones s'activent en fonction de motifs spécifiques présents dans l'entrée.

De plus, à mesure que l'on empile des couches cachées supplémentaires, le potentiel d'approximation universelle croît de façon exponentielle. Les neurones de la deuxième couche forment des motifs à partir des motifs de la première couche, et ainsi de suite.

Théorème de représentation de Kolmogorov-Arnold

Voici un autre théorème portant lui aussi sur l'approximation, ou plutôt la représentation, de fonctions continues.

Plus formellement, le théorème de représentation de Kolmogorov-Arnold affirme que toute fonction continue multivariée peut être représentée comme la composition d'un nombre fini de fonctions continues à une seule variable.

Décomposons cette affirmation :

• Une "fonction continue multivariée" est une fonction qui accepte plusieurs paramètres en entrée :

• "Un nombre fini de fonctions continues à une seule variable" signifie ce qui suit :

On ne s'arrête pas là pour autant. La somme ci-dessus est ensuite passée à travers une fonction supplémentaire, psi :

Enfin, on applique également une composition à cette dernière étape pour généraliser encore la formule :

Pour résumer, le théorème de représentation de Kolmogorov-Arnold affirme que toute fonction continue multivariée peut être représentée comme la composition de fonctions continues à une seule variable.

Si on développe les termes de la somme, on obtient ceci :

Voici un exemple simple pour t'aider à visualiser :

Si tu reviens maintenant à l'image du réseau KAN présentée plus haut, c'est exactement ce mécanisme qui est à l'œuvre dans le réseau proposé.

Dans un premier temps :

• L'entrée x₁ passe à travers les fonctions univariées (ϕ₁₁, ϕ₁₂, ⋯, ϕ₁₅) pour obtenir (ϕ₁₁(x₁), ϕ₁₂(x₁), ⋯, ϕ₁₅(x₁)).

• L'entrée x₂ passe à travers les fonctions univariées (ϕ₂₁, ϕ₂₂, ⋯, ϕ₂₅) pour obtenir (ϕ₂₁(x₂), ϕ₂₂(x₂), ⋯, ϕ₂₅(x₂)).

Ensuite, les deux sorties correspondantes sont agrégées (sommées). La fonction ψ se réduit donc ici à l'opération identité (ψ(z) = z) :

Cela constitue une couche KAN.

On passe ensuite cette sortie à travers une couche KAN supplémentaire. La sortie ci-dessus est donc d'abord transmise à la fonction ϕ de la couche suivante, puis sommée pour obtenir la sortie finale :

Différences clés

Du point de vue de la portée, le théorème d'approximation universelle s'applique explicitement aux réseaux de neurones, tandis que le théorème de Kolmogorov-Arnold est un résultat mathématique plus général, que les auteurs de KAN étendent aux réseaux de neurones censés estimer une fonction continue inconnue.

Concernant l'approche, le théorème d'approximation universelle traite de l'approximation de fonctions par des réseaux de neurones. Le théorème de Kolmogorov-Arnold, lui, fournit un moyen de représenter exactement des fonctions continues via des sommes de fonctions univariées, ce qui est censé les rendre plus précises.

Enfin, du point de vue de l'application, le théorème d'approximation universelle est largement utilisé en machine learning pour justifier la puissance des réseaux de neurones, tandis que le théorème de Kolmogorov-Arnold relève davantage d'un éclairage théorique, aujourd'hui étendu au machine learning à travers des architectures comme les Kolmogorov Arnold Networks.

Puisque le théorème de Kolmogorov-Arnold vise une représentation exacte de la fonction multivariée, son intégration dans un réseau de neurones est censée être bien plus efficace et précise.

Cette représentation exacte pourrait d'ailleurs mener à des modèles plus interprétables et nécessitant moins de ressources pour l'entraînement, l'architecture intégrant nativement les propriétés mathématiques des fonctions continues apprises.

Dans la plupart des datasets de machine learning, on retrouve principalement des features qui progressent d'une valeur à une autre :

Par exemple :

• Des features numériques comme l'âge, le revenu, le montant d'une transaction, etc.

• Des features catégorielles comme la taille d'un t-shirt, les tranches de revenu, les tranches d'âge, etc.

Cependant, il existe un autre type de feature qui, dans la plupart des cas, mérite un effort de feature engineering particulier, mais qui est souvent négligé.

Ce sont les features cycliques, c'est-à-dire des features qui suivent un motif récurrent (ou un cycle).

Contrairement aux autres features qui progressent de façon continue (ou qui n'ont pas d'ordre intrinsèque), les features cycliques présentent un comportement périodique et se répètent après un intervalle précis.

Par exemple, l'heure de la journée, le jour de la semaine et le mois de l'année sont tous des exemples courants de features cycliques.

En parlant spécifiquement de l'heure de la journée, sa valeur peut aller de 0 à 23 :

Si on NE considère PAS cette feature comme cyclique et qu'on n'utilise pas les techniques de feature engineering appropriées, on va perdre des informations vraiment essentielles.

Pour mieux comprendre, prends ça en compte :

En toute logique, les valeurs "23" et "0" doivent être proches l'une de l'autre dans notre représentation "idéale" de la feature heure de la journée.

De plus, la distance entre "0" et "1" doit être la même que la distance entre "23" et "0".

Cependant, la représentation standard ne respecte pas ces propriétés.

Ainsi, la valeur "23" est éloignée de "0". En réalité, la propriété de distance n'est pas respectée non plus.

Maintenant, prends un instant pour y réfléchir.

Intuitivement, tu ne penses pas que cette feature mérite un feature engineering particulier, c'est-à-dire un traitement qui préserve sa propriété naturelle intrinsèque ?

Je suis sûr que si !

Voyons comment on procède habituellement.

Encoder les features cycliques

L'une des techniques les plus courantes pour encoder ce type de feature consiste à utiliser des fonctions trigonométriques, plus précisément le sinus et le cosinus.

Elles sont utiles parce que le sinus et le cosinus sont périodiques, bornés, et définis pour toutes les valeurs réelles.

Par exemple, prenons la représentation linéaire de la feature heure de la journée transformée en feature cyclique :

L'angle central (2π) représente 24 heures.

Ainsi, les valeurs de la feature linéaire peuvent facilement être converties en features cycliques comme suit :

L'avantage de cette démarche, c'est de voir à quel point la feature ainsi obtenue respecte parfaitement les propriétés qu'on a évoquées plus haut :

Comme illustré ci-dessus, la distance entre la représentation cyclique de "23" et de "0" est la même que la distance entre "0" et "1".

La représentation linéaire standard de la feature heure de la journée, en revanche, viole cette propriété, ce qui entraîne une perte d'information…

… ou plutôt, je devrais dire que la représentation linéaire standard de la feature heure de la journée entraîne une sous-utilisation de l'information, dont le modèle pourrait pourtant bénéficier.

S'il s'était agi du jour de la semaine à la place, l'angle central (2π) aurait dû représenter 7 jours.

Ça a du sens intuitivement aussi.

La même idée peut s'étendre à tous les types de features cycliques que tu pourrais retrouver dans ton dataset :

• La direction du vent, si elle est représentée de façon catégorielle, suivra cet ordre : N, NE, E, SE, S, SO, O, NO, puis de nouveau N.

• Les phases de la lune, comme la nouvelle lune, le premier quartier, la pleine lune et le dernier quartier, peuvent être représentées comme des catégories suivant un ordre cyclique.

• Les saisons, comme le printemps, l'été, l'automne et l'hiver, sont des features catégorielles au motif cyclique puisqu'elles se répètent chaque année.

Le point important, c'est qu'en inspectant les features de ton dataset, tu sauras intuitivement lesquelles sont cycliques et lesquelles ne le sont pas.

En général, le modèle trouvera plus facile d'interpréter les features ainsi obtenues et de les utiliser pour modéliser précisément le dataset.

👉 À toi de jouer : quelles sont les autres façons de gérer ce type de features ?

On a déjà creusé plusieurs algorithmes de clustering avancés dans les dossiers précédents, notamment ceux-ci :

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.

DBSCAN++ : Passe ton Clustering à l'échelle supérieure

Surmonte les limites de DBSCAN. Apprends comment DBSCAN++ et le K-center sampling offrent une alternative rapide et scalable pour tes grands jeux de données.

Dans ce dossier, on continue la série clustering avec HDBSCAN, un algorithme de clustering hiérarchique puissant qui étend les capacités de DBSCAN en ajoutant une dimension hiérarchique et en gérant beaucoup mieux les densités variables.

• DBSCAN signifie Density-Based Spatial Clustering of Applications with Noise.

• HDBSCAN signifie Hierarchical Density-Based Spatial Clustering of Applications with Noise.

Pour rappel, DBSCAN part du principe que la densité locale des points de données est (plus ou moins) uniforme à l'échelle globale. C'est son paramètre eps qui gouverne cette hypothèse.

Regarde par exemple les résultats de clustering obtenus avec DBSCAN sur le dataset factice ci-dessous, où chaque cluster a une densité différente :

Le résultat est clair : DBSCAN produit un mauvais clustering.

Compare maintenant avec les résultats de HDBSCAN sur les mêmes données :

Sur un dataset avec trois clusters de densités variables, HDBSCAN se montre bien plus robuste.

À la fin de ce dossier précédent, beaucoup d'entre vous ont montré de l'intérêt pour un deep dive complet sur HDBSCAN. Ça tombe bien, c'est exactement le sujet du jour.

On va couvrir les concepts clés qui te permettront de comprendre comment HDBSCAN fonctionne, et pourquoi c'est un algorithme de clustering aussi puissant.

C'est parti !

À quoi ressemblent les données ?

Tout problème de clustering démarre avec un dataset (non labellisé) et quelques hypothèses à son sujet.

Avant de concevoir (ou d'utiliser) un algorithme de clustering, la première question à se poser est :

Dans l'idéal, on veut poser le moins d'hypothèses possible. Deux hypothèses de base suffisent pour avancer :

• Le dataset contient du bruit, ce qui veut dire que tous les points n'appartiennent pas forcément à un cluster.

• Il existe un certain nombre de clusters (on ne sait pas combien) de formes arbitraires dans le dataset.

Dans ce dossier, on va construire les fondations de HDBSCAN à partir du dataset 2D suivant :

Comme c'est un dataset en 2D, il est facile de constater visuellement qu'il y a 6 clusters, le reste étant du bruit :

Mais évidemment, l'inspection visuelle n'est pas toujours possible (en particulier sur des données en haute dimension). On a donc besoin d'un algorithme de clustering capable d'identifier des clusters dans n'importe quel espace, quelle que soit sa dimension.

Essayons avec KMeans

Le premier réflexe face à un problème de clustering, c'est souvent d'essayer KMeans. Comme on connaît le nombre de clusters dans ce cas précis, lançons un KMeans et regardons les résultats :

En traçant le dataset avec les labels obtenus, on obtient le graphique suivant :

Imaginons un instant qu'on dispose déjà d'une implémentation de HDBSCAN, et qu'on la lance sur le même dataset :

En traçant le dataset avec les labels obtenus, on obtient :

Malgré le fait qu'on ait spécifié le bon nombre de clusters à KMeans, celui-ci échoue à produire un clustering correct. HDBSCAN, lui, fait un bien meilleur travail (à l'œil nu) sans même qu'on lui précise le nombre de clusters.

Pourquoi KMeans échoue-t-il ? Voyons ça.

Les limites de KMeans

Si sa simplicité en fait souvent l'algorithme de clustering préféré, KMeans a plusieurs limites qui plombent son efficacité dans de nombreux cas.

1) KMeans ne tient pas compte de la variance ni de la forme des clusters

Une des limites principales de KMeans, c'est son hypothèse implicite que les clusters sont sphériques.

Une façon intuitive et visuelle de comprendre l'algorithme KMeans, c'est d'imaginer un cercle placé au centre de chaque cluster, qui englobe les points.

Formes de clusters produites par KMeans quand les données forment des clusters circulaires

Comme KMeans revient essentiellement à placer des cercles, ses résultats sont décevants dès que le dataset présente des formes irrégulières ou des tailles variables, comme ci-dessous :

Formes de clusters produites par KMeans quand les données forment des clusters ovales

À la place, un clustering idéal devrait ressembler à ceci :

Forme de cluster idéale quand les données forment des clusters ovales

On observe le même phénomène sur le dataset suivant :

Cette rigidité de KMeans, qui ne sait clusteriser que des formes globulaires, mène régulièrement à des erreurs de classification et à des assignations de clusters sous-optimales.

2) Chaque point est forcément assigné à un cluster

Autre limite importante de KMeans : son hypothèse implicite que chaque point de données doit appartenir à un cluster.

Plus précisément, KMeans part du principe que chaque point appartient à un cluster, et à un seul, sans aucune place pour représenter du bruit ou des outliers.

Ça devient problématique quand le dataset contient des irrégularités, des anomalies ou du bruit qui ne collent à aucune frontière de cluster claire.

Résultat : KMeans va malgré tout assigner ces points à un cluster, même quand ils ne correspondent en réalité à aucun pattern identifiable.

C'est ce qu'illustre l'image ci-dessous :

Cette tendance peut dégrader la qualité du clustering, en particulier sur des datasets à densités variables, à formes irrégulières, ou contenant du bruit.

Sur des données réelles, où la structure sous-jacente ne colle pas forcément aux hypothèses de KMeans, cette assignation rigide de tous les points à un cluster peut sérieusement limiter l'efficacité de l'algorithme.

C'est une limite à garder en tête, qui pousse à envisager d'autres approches (density-based ou hiérarchiques par exemple) dès qu'un dataset présente du bruit ou des outliers significatifs.

3) La nécessité de spécifier le nombre de clusters

Autre contrainte notable de KMeans : il faut connaître (ou supposer) à l'avance le nombre exact de clusters dans le dataset.

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

Ce n'est pas un problème en soi, il existe plusieurs méthodes pour estimer une valeur fiable de k. Mais cette contrainte devient problématique quand le vrai nombre de clusters est inconnu à l'avance, ce qui peut mener à des résultats imprécis et sous-optimaux.

Ces limites de KMeans montrent bien l'intérêt d'explorer d'autres algorithmes capables d'y répondre.

KMeans fait partie de la famille des algorithmes de clustering par centroïdes, mais il existe de nombreuses autres familles (illustrées ci-dessous), à utiliser selon le contexte :

Pourquoi KMeans a échoué ?

Une fois ces limites de KMeans posées, il devient facile de comprendre pourquoi il a produit des résultats aussi médiocres sur notre dataset d'origine.

Plus précisément, le dataset qu'on a utilisé présente :

• Des clusters de formes et de tailles arbitraires

• Des clusters de densités variables

• Des points de bruit

Ça explique clairement la contre-performance de KMeans sur ce dataset. Mais ça nous donne aussi de bonnes pistes pour construire un algorithme plus robuste.

Poser les bonnes attentes

Les trois points ci-dessus définissent des attentes claires sur notre dataset. Il paraît raisonnable de supposer qu'un dataset réel présentera les mêmes caractéristiques :

1. Les clusters auront des formes et des tailles arbitraires.

2. Les clusters auront des densités arbitraires.

3. Le dataset contiendra des points de bruit.

Si on retire la 2ème caractéristique (densités arbitraires), l'algorithme DBSCAN répond à ces critères.

Mais comme on l'a vu plus haut (et dans le deep dive dédié à DBSCAN), il suppose que la densité locale des points est (plus ou moins) uniforme à l'échelle globale. C'est son paramètre eps qui gouverne ça.

DBSCAN a donc du mal avec un dataset où chaque cluster a une densité différente :

HDBSCAN, en revanche, se montre bien plus robuste.

Les réseaux de neurones utilisent principalement la mémoire de deux façons :

1. Quand ils stockent les poids du modèle (c'est une utilisation mémoire fixe).

2. Quand ils sont entraînés (c'est dynamique). Cela se produit de deux façons :

   1. Pendant le forward pass, lors du calcul et du stockage des activations de toutes les couches.

   2. Pendant le backward pass, lors du calcul des gradients à chaque couche.

Cette seconde catégorie, l'utilisation mémoire dynamique, nous empêche souvent d'entraîner des modèles plus grands avec des batch sizes plus élevés.

C'est parce que l'utilisation mémoire évolue proportionnellement à la taille du batch.

Cela dit, il existe une technique assez incroyable qui permet d'augmenter la batch size tout en maintenant l'utilisation mémoire globale.

Elle s'appelle le Gradient checkpointing, et d'après mon expérience, c'est une technique largement sous-estimée pour réduire la surcharge mémoire des réseaux de neurones.

Voyons ça plus en détail.

Comment fonctionne le gradient checkpointing ?

Le gradient checkpointing repose sur deux observations clés sur le fonctionnement typique des réseaux de neurones :

1. Les activations d'une couche spécifique peuvent être calculées uniquement à partir des activations de la couche précédente. Par exemple, dans l'image ci-dessous, les activations de la "Couche B" peuvent être calculées uniquement à partir des activations de la "Couche A" :

Forward pass

2. La mise à jour des poids d'une couche dépend uniquement de deux choses :

   1. Les activations de cette couche.

   2. Les gradients calculés dans la couche suivante (à droite), ou plutôt les gradients en cours (running gradients).

Backward pass

Le gradient checkpointing exploite ces deux observations pour optimiser l'utilisation mémoire.

Voici comment ça fonctionne :

Étape 1) Diviser le réseau en segments avant le forward pass :

Étape 2) Pendant le forward pass, ne stocker que les activations de la première couche de chaque segment. Le reste est supprimé une fois qu'il a servi à calculer les activations de la couche suivante.

Étape 3) Vient ensuite la rétropropagation (backpropagation). Pour mettre à jour les poids d'une couche, on a besoin de ses activations. On recalcule donc ces activations à partir de la première couche de ce segment.

Par exemple, comme le montre l'image ci-dessous, pour mettre à jour les poids des couches rouges, on recalcule leurs activations à partir des activations de la couche cyan, déjà disponibles en mémoire.

Voilà !

C'est ainsi que fonctionne le gradient checkpointing.

Pour résumer, l'idée est qu'on n'a pas besoin de stocker toutes les activations intermédiaires en mémoire.

À la place, en stocker quelques-unes et recalculer le reste uniquement quand c'est nécessaire permet de réduire significativement les besoins en mémoire.

Et cette idée est assez intuitive.

En fait, cela permet aussi d'entraîner le réseau sur des batches de données plus grands.

D'après ce que j'ai pu observer, le gradient checkpointing (GCP) permet généralement de réduire l'utilisation mémoire d'au moins 50 à 60 %, ce qui est énorme.

Bien sûr, comme certaines activations sont calculées deux fois, cela se fait au prix d'un temps d'exécution accru, généralement entre 15 et 25 %.

Il y a donc toujours un compromis entre mémoire et temps d'exécution.

Cela dit, un autre avantage est que ça permet d'utiliser une batch size plus grande, ce qui peut légèrement (mais pas totalement) compenser cette augmentation du temps d'exécution.

Malgré tout, le gradient checkpointing reste une technique extrêmement puissante pour entraîner des modèles plus grands. Je l'ai trouvée vraiment utile à plusieurs reprises, sans avoir à recourir à des techniques plus lourdes comme le distributed training, par exemple.

Heureusement, le gradient checkpointing est aussi implémenté par de nombreux frameworks de deep learning open source comme PyTorch, entre autres.

Le gradient checkpointing avec PyTorch

Pour l'utiliser, on commence par importer les bibliothèques et fonctions nécessaires :

Ensuite, on définit notre réseau de neurones :

Comme montré ci-dessus, dans la méthode forward, on utilise la méthode checkpoint_sequential pour appliquer le gradient checkpointing et diviser le réseau en deux segments.

Ensuite, on peut entraîner le réseau normalement, comme d'habitude.

Plutôt simple, non ?

👉 À toi de jouer : quelles sont tes techniques préférées pour optimiser l'entraînement d'un réseau de neurones ?

PyTorch a toujours été ma bibliothèque de référence pour construire des modèles de deep learning, grâce à sa flexibilité, son API Pythonic intuitive et sa facilité d'utilisation.

Cependant, déployer des modèles basés sur PyTorch dans des systèmes de production se heurte à de sérieuses limitations en matière de scalabilité et de performance, un point souvent négligé.

Pour commencer, une contrainte majeure de PyTorch est sa dépendance quasi totale à Python.

Si Python offre simplicité, polyvalence et lisibilité, il est aussi connu pour être relativement plus lent que d'autres langages comme C++ ou Java.

Cela pose problème dans les scénarios où la faible latence et le haut débit sont essentiels, comme les applications et services en temps réel.

D'ailleurs, il est fort possible que le serveur sur lequel tu comptes déployer ton modèle utilise n'importe quel autre langage que Python, comme C++, Java, et bien d'autres.

Ainsi, les modèles que l'on construit DOIVENT être portables vers différents environnements conçus pour gérer des requêtes concurrentes à grande échelle.

Mais, comme évoqué plus haut, la nature Python-centrique des modèles PyTorch peut limiter leur intégration à ce type de systèmes ou de plateformes.

Une solution simple et élégante consiste à développer tes modèles PyTorch en script mode, spécialement conçu pour les cas d'usage en production.

Dans PyTorch, le script mode désigne un ensemble d'outils et de fonctionnalités qui permettent aux développeurs de faire tourner leurs modèles d'une manière plus adaptée à la production.

Si tu es curieux d'en savoir plus, j'ai récemment publié un dossier complet sur le sujet : Les modèles PyTorch ne sont pas faits pour le déploiement ! Boost-les avec TorchScript

Déployer PyTorch en C++ : Guide complet TorchScript & Production

Apprends à convertir tes modèles PyTorch en TorchScript pour le déploiement C++. Élimine la dépendance Python et optimise l'inférence en production.

Tu y apprendras comment rendre tes modèles PyTorch plus adaptés à la production et indépendants du langage.

Les compétences en déploiement sont absolument essentielles dans une carrière en data science et en machine learning.

Le plus grand atout de PyTorch, c'est sa simplicité et son design Pythonic.

Mais cet atout introduit aussi une limite majeure au moment de déployer des modèles basés sur PyTorch.

Apprendre à construire des modèles PyTorch en script mode fera une vraie différence dans ta carrière.

Il y a quelques semaines, une startup tech m'a invité à mener leurs entretiens ML.

J'ai interviewé 12 candidats et je leur ai posé principalement des questions pratiques de ML.

Mais il y avait aussi quelques questions conceptuelles, comme celle-ci, que j'ai posée intentionnellement à chaque candidat :

• Comment fonctionne le Dropout ?

Plutôt simple, non ?

Et pourtant, chaque candidat m'a donné une réponse incomplète, que voici :

Réponse des candidats

En résumé, l'idée est de mettre à zéro des neurones de façon aléatoire dans un réseau de neurones. Ça sert à régulariser le réseau.

Le Dropout n'est appliqué que pendant l'entraînement, et le choix des activations de neurones à mettre à zéro (ou à "dropper") est déterminé à l'aide d'une loi de Bernoulli :

"p" est la probabilité de dropout spécifiée,
par exemple dans PyTorch → nn.Dropout(p).

Ma question de relance : Ok, parfait ! Est-ce qu'on fait autre chose dans le Dropout ?

Les candidats : Non, c'est tout. On met juste des neurones à zéro et on entraîne le réseau normalement.

Revenons maintenant à ce Shot Data.

Bien sûr, je ne dis pas que les détails ci-dessus sont faux.

Ils sont corrects.

Sauf que ça ne représente que 50% du fonctionnement du Dropout, et malheureusement, la plupart des ressources ne couvrent pas les 50% restants.

Si toi aussi tu ne connaissais que les 50% que je viens de mentionner, continue à lire, il y a du nouveau pour toi.

Comment fonctionne réellement le Dropout ?

Pour commencer, il faut noter que le Dropout n'est appliqué que pendant l'entraînement, pas pendant la phase d'inférence ou d'évaluation :

Maintenant, imagine qu'un neurone reçoive son entrée à partir de 100 neurones de la couche cachée précédente :

Pour simplifier, faisons deux hypothèses :

• L'activation de chaque neurone jaune est de 1.

• Le poids de chaque connexion entre les neurones jaunes et le neurone bleu est aussi de 1.

Résultat, l'entrée reçue par le neurone bleu sera de 100, comme illustré ci-dessous :

Jusque-là tout va bien ?

Maintenant, pendant l'entraînement, si on utilisait le Dropout avec, disons, un taux de 40%, alors environ 40% des activations des neurones jaunes seraient mises à zéro.

Résultat, l'entrée reçue par le neurone bleu serait d'environ 60, comme illustré ci-dessous :

Cela dit, ce dernier point n'est valable que pour la phase d'entraînement.

Si le même scénario se produisait pendant la phase d'inférence, l'entrée reçue par le neurone bleu serait de 100.

Donc, dans des conditions similaires :

• Entrée reçue pendant l'entraînement → 60.

• Entrée reçue pendant l'inférence → 100.

Tu vois le problème ?

Pendant l'entraînement, la moyenne des entrées des neurones est nettement plus faible que celle reçue pendant l'inférence.

Plus formellement, l'utilisation du Dropout affecte significativement l'échelle des activations.

Or, on veut que les neurones du modèle reçoivent, tout au long du réseau, à peu près la même moyenne (ou espérance) d'activations pendant l'entraînement et pendant l'inférence.

Pour corriger ça, le Dropout effectue une étape supplémentaire.

L'idée est de mettre à l'échelle les entrées restantes actives pendant l'entraînement.

La façon la plus simple de faire ça est de multiplier toutes les activations pendant l'entraînement par un facteur 1/(1-p), où p est le taux de dropout.

Par exemple, en appliquant cette technique à l'entrée de neurone de 60, on obtient ce qui suit (rappel, on avait fixé p=40%) :

Comme illustré ci-dessus, la mise à l'échelle de l'entrée du neurone la ramène dans la plage souhaitée, ce qui rend les phases d'entraînement et d'inférence cohérentes pour le réseau.

Vérification expérimentale

On peut d'ailleurs vérifier que les implémentations classiques du Dropout, celle de PyTorch par exemple, effectuent bien cette étape.

Définissons une couche de dropout comme suit :

Maintenant, prenons un tenseur aléatoire et appliquons cette couche de dropout dessus :

Comme illustré ci-dessus, les valeurs conservées ont augmenté.

• La deuxième valeur passe de 0.13 → 0.16.

• La troisième valeur passe de 0.93 → 1.16.

• et ainsi de suite…

Mieux encore, les valeurs conservées sont exactement les mêmes que celles qu'on aurait obtenues en mettant explicitement le tenseur d'entrée à l'échelle avec 1/(1-p) :

Si on faisait la même chose en mode évaluation, on remarque qu'aucune valeur n'est supprimée et qu'aucune mise à l'échelle n'a lieu non plus, ce qui est logique puisque le Dropout n'est utilisé que pendant l'entraînement :

Voilà les 50% restants, que, d'après mon expérience, la plupart des ressources ne couvrent pas, et que la plupart des gens ignorent donc.

Mais c'est une étape vraiment importante dans le Dropout, qui maintient la cohérence numérique entre les phases d'entraînement et d'inférence.

Avec ça, tu connais maintenant 100% du fonctionnement du Dropout.

👉 À toi de jouer : quelles sont les autres façons de régulariser un réseau de neurones ?

Quasi tous les tutoriels, cours ou articles de blog parlant de la régularisation L2 que j'ai pu voir n'abordent qu'une seule chose :

Bien sûr, ces affirmations sont tout à fait correctes, et je ne le nie absolument pas.

D'ailleurs, on peut le vérifier avec le schéma ci-dessous :

Sur l'image ci-dessus, plus on se déplace vers la droite, plus le paramètre de régularisation augmente, et le modèle crée une frontière de décision plus simple sur les 5 datasets.

Revenons à notre sujet…

Ce qui me déçoit le plus, c'est que la plupart des ressources ne mentionnent pas que la régularisation L2 est un excellent remède contre la multicolinéarité.

La multicolinéarité apparaît quand deux (ou plusieurs) features sont fortement corrélées, OU quand deux (ou plusieurs) features permettent de prédire une autre feature :

Quand on utilise la régularisation L2 dans une régression linéaire, l'algorithme est aussi appelé Ridge regression.

Mais comment la régularisation L2 élimine-t-elle la multicolinéarité ?

Aujourd'hui, je vais te donner une intuition démonstrative sur ce sujet, qui expliquera aussi pourquoi la "ridge regression" porte ce nom.

C'est parti !

Dataset factice

Pour la démonstration, prenons ce dataset factice à deux features :

Comme montré ci-dessus, on a volontairement rendu featureB fortement corrélée à featureA. Cela nous donne un dataset factice avec lequel travailler.

Régression linéaire sans pénalité L2

Lors de la modélisation par régression, l'objectif est de déterminer les paramètres spécifiques (θ₁, θ₂) qui minimisent la somme des carrés des résidus (RSS) :

Voici ce qu'on va faire :

On va tracer la valeur du RSS pour de nombreuses combinaisons différentes de paramètres (θ₁, θ₂). Cela va créer un graphique 3D :

• axe x → θ₁

• axe y → θ₂

• axe z → valeur du RSS

Ensuite, on va examiner visuellement ce graphique pour repérer les paramètres spécifiques (θ₁, θ₂) qui minimisent la valeur du RSS.

Allons-y.

Sans la pénalité L2, on obtient le graphique suivant (c'est le même graphique, mais vu sous différents angles) :

Tu as remarqué quelque chose ?

Le graphique 3D présente une vallée. Il existe plusieurs combinaisons de valeurs de paramètres (θ₁, θ₂) pour lesquelles le RSS est minimal.

Il est donc impossible d'obtenir une valeur unique pour les paramètres (θ₁, θ₂) qui minimisent le RSS.

Régression linéaire avec pénalité L2

Quand on utilise une pénalité L2, l'objectif est de minimiser l'expression suivante :

En traçant à nouveau le même graphique que précédemment, on obtient ceci :

Tu remarques quelque chose de différent cette fois-ci ?

Comme le montre l'image ci-dessus, l'utilisation de la régularisation L2 supprime la vallée qu'on avait observée plus tôt et donne un minimum global à l'erreur RSS.

Il est désormais possible d'obtenir une valeur unique pour les paramètres (θ₁, θ₂) qui minimise le RSS.

Comme par magie, la régularisation L2 nous a permis d'éliminer la multicolinéarité.

Pourquoi le nom "ridge regression" ?

C'est d'ailleurs de là que vient le nom "ridge regression" : elle élimine la crête ("ridge") présente dans la fonction de vraisemblance quand on applique la pénalité L2.

Bien sûr, dans les démonstrations qu'on vient de voir, on a observé une vallée, pas une crête.

Cependant, dans ce cas, on considérait la somme des carrés des résidus, une grandeur qu'on minimise pour obtenir les paramètres optimaux.

La fonction d'erreur donne donc logiquement une vallée.

Si on utilisait plutôt la vraisemblance, une grandeur qu'on cherche à maximiser, cela inverserait (en quelque sorte) le graphique et donnerait une crête à la place :

Apparemment, c'est la fonction de vraisemblance qui a été prise en compte au moment de nommer l'algorithme.

Et c'est pour ça qu'on l'a appelé "ridge regression".

Plutôt cool, non ?

Quand j'ai découvert ça il y a quelques années, je n'avais littéralement aucune idée qu'on avait réfléchi aussi profondément avant de nommer la ridge regression.

J'espère que tu as appris quelque chose de nouveau aujourd'hui :)

Si tu veux en savoir plus sur l'origine probabiliste de la régularisation L2, jette un œil à cet article :

Découvrir la Régularisation par les Probabilités

Découvre comment éviter le surapprentissage en machine learning grâce à la régularisation par probabilités et techniques MLE pour des modèles performants et généralisables.

👉 À toi de jouer : quels sont, selon toi, d'autres avantages de la régularisation L2 ?

Utiliser des modificateurs d'accès (public, protégé et privé) est fondamental pour l'encapsulation en POO.

Ce n'est pas propre à Python, c'est valable pour la POO en général.

Mais quand on parle spécifiquement de Python, on remarque qu'il ne propose pas de véritables mécanismes d'encapsulation, ceux-là mêmes qu'on voudrait pourtant exploiter dans son code orienté objet.

Comment ça ?

Voyons ça ensemble aujourd'hui !

Comme tu le sais peut-être déjà, les attributs de classe en POO peuvent être de trois types :

• Un membre public est accessible partout, à l'intérieur comme à l'extérieur de la classe de base, et il est hérité par toutes les classes enfants.

• Un membre protégé est accessible partout dans la classe de base et ses classe(s) enfant(s). Il n'est pas accessible en dehors de la classe.

• Un membre privé n'est accessible qu'à l'intérieur de la classe de base.

Mais avec Python, il n'existe aucune contrainte stricte de ce type. C'est différent de nombreux autres langages, comme le C++.

Ainsi, les membres protégés se comportent exactement comme des membres publics.

Et ce n'est pas tout, les membres privés peuvent eux aussi (d'une certaine manière) être accédés depuis l'extérieur de la classe.

Pour mieux comprendre, regarde l'implémentation de classe suivante :

D'un point de vue syntaxique, en Python :

• Un membre public se déclare sans underscore au début.

• Un membre protégé se déclare avec 1 underscore au début.

• Un membre privé se déclare avec 2 underscores au début.

Ensuite, on instancie un objet de la classe :

Comme on peut s'y attendre, l'attribut public est accessible depuis l'extérieur de la classe :

Cependant, de la même façon, même l'attribut protégé est accessible depuis l'extérieur de la classe, ce qui, en théorie, ne devrait pas arriver :

Enfin, quand on déclare des membres privés, Python effectue ce qu'on appelle le name mangling.

C'est une technique utilisée en programmation pour éviter les conflits de noms entre différentes classes.

Python réalise ce name mangling en ajoutant le nom de la classe précédé d'un underscore (_MyClass) devant tous les membres qui commencent par deux underscores.

Ainsi, même si le membre privé n'est pas directement accessible avec son nom d'origine, il reste accessible avec le nom modifié obtenu grâce au name mangling.

C'est ce que montre l'exemple suivant :

Comme le montrent tous les exemples ci-dessus, les membres protégés et les membres privés (grâce au name mangling) peuvent être accédés comme des membres publics.

Le point essentiel à retenir pour tout développeur Python qui utilise la POO, c'est que Python n'impose jamais l'encapsulation.

En réalité, exploiter les mécanismes d'encapsulation en Python repose surtout sur des conventions.

Elles servent à communiquer aux autres développeurs les règles d'accessibilité des membres d'une classe.

C'est donc à chaque développeur de respecter ces conventions.

Voici un guide complet sur la POO en Python si tu veux approfondir le sujet :

Programmation orientée objet avec Python pour les data scientists (Partie 1)

Apprends la programmation orientée objet en Python : classes, objets, méthodes magiques et héritage, appliqués aux pipelines data pour data scientists.

Programmation orientée objet avec Python pour les data scientists (Partie 2)

Approfondis la POO en Python : polymorphisme, encapsulation, classes avancées et optimisation pour des modèles de machine learning robustes.

👉 À toi de jouer : quels sont les autres points de vigilance à connaître dans la POO en Python ?

Prêt à passer au niveau supérieur ?

Dans le dossier consacré à PyTorch Lightning, on n'avait pas abordé l'entraînement multi-GPU.

Je t'avais prévenu que le sujet demandait des bases supplémentaires : comment ça fonctionne sous le capot, quelles stratégies existent, comment plusieurs GPU restent synchronisés entre eux pendant l'entraînement en environnement distribué, les points de vigilance à avoir, et bien plus encore.

PyTorch Lightning : guide complet pour débuter

Apprends à utiliser PyTorch Lightning pour simplifier l'entraînement de tes modèles deep learning : callbacks, métriques, précision mixte et profiling.

Aujourd'hui, on reprend ce fil. Direction les rouages techniques de l'entraînement multi-GPU : comment ça marche en interne, et les détails propres à l'implémentation.

On va aussi passer en revue les points de vigilance essentiels pour l'entraînement multi-GPU (ou distribué). Mal gérés, ils peuvent entraîner des performances sous-optimales, un entraînement plus lent, voire une instabilité pendant l'entraînement.

C'est parti !

Pourquoi passer au multi-GPU

Par défaut, les modèles de deep learning construits avec PyTorch ne s'entraînent que sur un seul GPU, même si plusieurs GPU sont disponibles.

Cela ne veut pas dire qu'on ne peut pas faire de l'entraînement multi-GPU avec PyTorch, bien au contraire. Mais ça demande de mobiliser explicitement les capacités de traitement parallèle de PyTorch.

De plus, même en exploitant plusieurs GPU avec PyTorch, les procédures d'entraînement classiques restent limitées à une seule machine. Cette limitation vient du comportement par défaut de PyTorch, qui utilise une seule machine pour l'entraînement du modèle.

Ça devient donc un goulot d'étranglement sévère dès qu'on travaille avec des datasets volumineux qui demandent plus de puissance de calcul qu'une seule machine ne peut en fournir.

Mais réaliser qu'on est limité à une seule machine pour l'entraînement, c'est aussi réaliser qu'il reste une marge importante d'optimisation du temps d'exécution.

L'entraînement multi-GPU résout ce problème.

En résumé (et comme son nom l'indique), l'entraînement multi-GPU permet de répartir la charge de travail de l'entraînement sur plusieurs GPU, voire sur plusieurs machines si nécessaire.

Ça réduit considérablement le temps d'entraînement pour les gros datasets et les modèles complexes, en exploitant la puissance de calcul combinée du matériel disponible.

Il existe plusieurs façons (stratégies) de faire du multi-GPU, mais l'une des plus courantes consiste à laisser chaque GPU ou chaque machine traiter une portion des données d'entrée de façon indépendante.

C'est ce qu'on appelle le parallélisme de données (data parallelism).

Le parallélisme de données

Dans le parallélisme de données, l'idée consiste à diviser les données disponibles en petits batches, chaque batch étant traité par un GPU distinct.

À la fin, les mises à jour de chaque GPU sont agrégées et utilisées pour mettre à jour les paramètres du modèle.

Si tu te souviens du dossier sur l'apprentissage fédéré (federated learning), l'idée va te sembler familière :

En apprentissage fédéré, au lieu d'avoir un seul serveur centralisé qui traite toutes les données, le modèle s'entraîne sur plusieurs devices en périphérie décentralisés, chacun avec ses propres données. Les mises à jour de ces devices sont ensuite agrégées pour améliorer le modèle global.

De la même façon, en parallélisme de données, chaque GPU joue le rôle d'un "mini-serveur" : il traite une portion des données et met à jour les paramètres du modèle localement.

Ces mises à jour locales sont ensuite combinées pour mettre à jour le modèle global. Ce traitement parallèle des données accélère non seulement l'entraînement, mais permet aussi une utilisation efficace des ressources en environnement distribué.

Une différence majeure : en apprentissage fédéré, on n'a pas d'accès direct au dataset local, alors qu'en parallélisme de données, les données sont directement accessibles.

Apprentissage Fédéré : Le Guide pour une IA Privée et Performante

Ne centralise plus tes données. Découvre comment implémenter l'apprentissage fédéré pour entraîner des modèles sur des données réelles (non-IID) tout en garantissant la confidentialité.

Cela dit, il est assez évident que cette approche améliore non seulement l'efficacité de l'entraînement, mais permet aussi de scaler l'entraînement pour gérer des datasets plus volumineux et des modèles plus complexes que ce qu'un seul GPU ou une seule machine pourrait gérer.

Les stratégies de parallélisme de données

Comme on vient de le voir, le parallélisme de données est une technique qui consiste à paralléliser l'entraînement d'un modèle en répartissant les données sur plusieurs devices (GPU ou machines), puis en combinant les résultats.

Assez intuitivement, cette approche réduit considérablement le temps d'entraînement des gros modèles et des gros datasets, en exploitant la puissance de calcul combinée de plusieurs devices.

Il existe principalement deux approches pour faire du parallélisme de données.

#1) DataParallel (DP)

Comment ça marche ?

DataParallel implémente le parallélisme de données au niveau du module, sur une seule machine disposant de plusieurs GPU.

En PyTorch (ou PyTorch Lightning), un "module" désigne l'ensemble du modèle de réseau de neurones.

Donc quand on parle de "parallélisme de données au niveau du module", ça veut dire que la parallélisation s'applique à tout le module du réseau de neurones, y compris tous ses paramètres et toutes ses opérations.

Par exemple, si tu as un modèle de deep learning avec plusieurs couches, le parallélisme de données au niveau du module consiste à répliquer ce modèle entier sur plusieurs GPU.

Chaque réplique du modèle traite ensuite une portion des données d'entrée de façon indépendante, et les mises à jour reçues de chaque réplique sont ensuite combinées pour mettre à jour les paramètres du modèle.

Concrètement, la stratégie DataParallel fonctionne ainsi :

• Répliquer le modèle sur tous les GPU.

• Exécuter le forward pass sur le sous-ensemble de données reçu par chaque GPU, et renvoyer les outputs (pas les gradients) à la machine centrale.

• Une fois les outputs reçus, la machine centrale calcule les gradients :

• Enfin, les gradients sont communiqués en retour à chaque GPU pour mettre à jour les répliques individuelles du modèle :