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 :

Aujourd'hui, je vais te poser une question.

Mais avant ça, imagine que tu es en train de construire un modèle de machine learning supervisé.

Tu utilises la cross-validation pour déterminer un ensemble optimal d'hyperparamètres.

Un peu de contexte :

La cross-validation consiste à partitionner plusieurs fois les données disponibles en sous-ensembles, à entraîner le modèle sur certains d'entre eux, puis à le valider sur les sous-ensembles restants.

Le principal avantage de la cross-validation, c'est qu'elle fournit une estimation plus robuste et moins biaisée de la performance du modèle, comparée à la méthode de validation traditionnelle.

Autrement dit, ajuster des modèles de machine learning sur un seul validation set peut être trompeur et donner parfois des résultats trop optimistes.

Cela peut arriver à cause d'un découpage aléatoire des données un peu trop chanceux, ce qui donne un modèle qui performe exceptionnellement bien sur le validation set, mais mal sur des données nouvelles et jamais vues.

Voici un post complet sur la cross-validation si tu veux creuser le sujet : 5 techniques de cross-validation à connaître, expliquées en images.

Pour revenir à notre sujet...

En résumé, chaque configuration d'hyperparamètres correspond à une performance de cross-validation :

Une fois qu'on a obtenu les meilleurs hyperparamètres, il faut finaliser un modèle (disons pour la production), sinon à quoi bon tout ce travail ?

Voici donc la question :

Une fois les hyperparamètres optimaux obtenus, que serais-tu le plus enclin à faire ?

1. Réentraîner le modèle sur l'intégralité des données (train + validation + test) avec les hyperparamètres optimaux ?

Si on fait ça, il faut garder en tête qu'on ne peut plus valider ce nouveau modèle de façon fiable, puisqu'il ne reste plus de données jamais vues.

2. Simplement garder le modèle le plus performant selon la performance de cross-validation elle-même.

Si on fait ça, il faut garder en tête qu'on laisse de côté des données importantes, avec lesquelles on aurait pu entraîner notre modèle.

Toi, tu ferais quoi ?

Note ta réponse ci-dessous avant de lire la réponse (le sondage est anonyme) :

Ma recommandation

Ma préférence a presque toujours été de réentraîner un nouveau modèle avec toutes les données.

Il y a bien sûr certaines choses à garder en tête, que j'ai appris au fil des modèles que j'ai construits et déployés.

Cela dit, dans la plupart des cas, réentraîner reste la meilleure façon de procéder.

Laisse-moi t'expliquer.

Pourquoi réentraîner le modèle ?

On a envie de réentraîner un nouveau modèle parce que, d'une certaine manière, on est déjà satisfait de la performance de cross-validation, qui, par nature, est une métrique out-of-fold.

Autrement dit, on croit déjà que le modèle se comportera comme prévu sur des données jamais vues.

Ainsi, intégrer ce validation set jamais vu dans les données d'entraînement et réentraîner le modèle n'aura TRÈS PROBABLEMENT AUCUN effet sur sa performance sur des données jamais vues après le déploiement (en supposant qu'aucun covariate shift soudain ne soit entré en jeu, ce qui est un tout autre sujet).

Si, en revanche, on n'était pas satisfait de la performance de cross-validation elle-même, on ne penserait même pas à finaliser un modèle en premier lieu.

À la place, on chercherait plutôt des façons d'améliorer le modèle en travaillant sur le feature engineering, en testant de nouveaux hyperparamètres, en expérimentant avec différents modèles, etc.

Ce raisonnement a aussi du sens intuitivement.

J'ai du mal à me souvenir d'un cas où réentraîner a eu un effet catastrophique sur le modèle global.

En fait, je me souviens très bien d'une fois où, pendant que je mettais le modèle en production (ça m'a pris quelques jours après le réentraînement), l'équipe avait rassemblé un peu plus de données labellisées.

Le modèle n'a montré aucune dégradation de performance quand je l'ai évalué (histoire de vérifier, juste au cas où).

Comme bénéfice supplémentaire, ça m'a aussi permis de m'assurer que je n'avais fait aucune erreur en mettant mon modèle en production.

Quelques points à garder en tête

Attention, ce n'est pas une règle absolue : il ne faut pas toujours réentraîner un nouveau modèle.

Le domaine lui-même, et les problèmes qu'on peut résoudre, sont très divers. Il faut donc rester ouvert d'esprit face au problème qu'on a sous les yeux.

Une des raisons pour lesquelles je ne voudrais pas réentraîner un nouveau modèle, c'est que ça prend des jours, voire des semaines, pour entraîner le modèle.

En fait, même si on réentraîne un nouveau modèle, il existe DE NOMBREUSES situations business où les enjeux sont tout simplement trop élevés.

On ne peut donc jamais se permettre d'être négligent et de déployer un modèle sans le réévaluer, la fraude transactionnelle, par exemple.

Dans ce genre de cas, j'ai vu des équipes travailler sur la mise en production du modèle, pendant que les data engineers rassemblaient un peu plus de données en parallèle.

Avant de déployer, l'équipe faisait quelques vérifications finales sur ce dataset.

Les nouvelles données rassemblées sont ensuite prises en compte dans les itérations suivantes d'amélioration du modèle.

👉 À toi de jouer : quelles autres considérations ajouterais-tu ici ?

La plupart des programmeurs Python se trompent sur la méthode magique __init__() en programmation orientée objet (POO). Ils pensent qu'elle crée un nouvel objet, c'est-à-dire qu'elle lui alloue de la mémoire.

Par exemple, prends la classe Point2D ci-dessous :

Suppose qu'il existe aussi une méthode __repr__(), même si elle n'est pas montrée ici.

Quand on crée un objet (comme ci-dessous), les programmeurs pensent qu'en arrière-plan, c'est la méthode __init__() qui alloue de la mémoire à leur objet :

Mais ce n'est pas vrai.

Quand on crée N'IMPORTE QUEL objet en Python, la méthode __init__() n'alloue JAMAIS de mémoire à cet objet.

Comme son nom l'indique, __init__() se contente d'assigner des valeurs aux attributs d'un objet, c'est-à-dire d'initialiser ses attributs.

C'est en réalité la méthode magique __new__() qui crée un nouvel objet et lui alloue de la mémoire.

Pour mieux comprendre, prends l'implémentation de classe ci-dessous.

Ici, on a implémenté la méthode __new__(), qui vérifie si les arguments passés sont bien de type entier (integer).

Maintenant, si on essaie de créer un objet de cette classe, Python va d'abord valider les vérifications spécifiées dans la méthode __new__(), et ne créer un nouvel objet que si les conditions spécifiées sont vraies.

C'est ce que montre l'image ci-dessous :

Un autre cas d'usage populaire de la méthode __new__() est de définir des classes singleton, des classes qui ne peuvent avoir qu'un seul objet.

Par exemple, prends l'implémentation de classe suivante :

Dans le code ci-dessus, la méthode __new__() définit une variable de classe _class_count.

Quand un nouvel objet est instancié, si la valeur de _class_count vaut 0, la valeur de _class_count est mise à jour à 1 et l'objet est retourné.

Après la création du premier objet, aucun nouvel objet ne peut plus jamais être créé, car la valeur de _class_count ne sera plus jamais égale à 0.

C'est ce que montre l'image ci-dessous :

Si tu veux creuser la POO avancée en Python, voici une deep dive complète sur 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 d'autres cas d'usage de la méthode magique __new__() ?

J'ai vu beaucoup de personnes avoir du mal à comprendre intuitivement la Precision et le Recall.

Ces métriques, pourtant assez simples, en intimident plus d'un.

Pourtant, adopter la "technique du mindset" peut énormément aider.

Laisse-moi te guider aujourd'hui.

Precision

Formellement, la Precision répond à la question suivante :

"Quelle proportion des prédictions positives étaient réellement positives ?"

Comprenons ça sous l'angle du mindset.

Quand on est dans un Mindset Precision, on ne se soucie pas de classifier correctement chaque sample positif.

Mais il est important que chaque prédiction positive soit effectivement positive.

Par exemple, imagine un système de recommandation de livres où une prédiction positive signifie qu'on a aimé le livre recommandé.

Dans un Mindset Precision, on accepte que le modèle ne recommande pas tous les bons livres du monde.

Mindset Precision : Ce n'est pas grave de passer à côté de certains bons livres, tant qu'on ne recommande que des bons livres

Mais ce qu'il recommande doit être bon.

Donc même si ce système ne recommandait qu'un seul livre et qu'on l'a aimé, ça donne une Precision de 100%.

C'est parce que ce qu'il a classifié comme "Positif" était bien "Positif".

En résumé, dans un mindset haute Precision, toutes les prédictions positives doivent effectivement être positives.

Recall

Le Recall, c'est un peu différent. Il répond à la question suivante :

"Quelle proportion des vrais positifs a été correctement identifiée par le modèle ?"

Quand on est dans un Mindset Recall, on veut que chaque sample positif soit correctement classifié, sans exception.

Ce n'est pas grave si certaines prédictions positives n'étaient pas réellement positives.

En revanche, tous les samples positifs doivent être classifiés comme positifs.

Par exemple, imagine un système de présélection de candidats pour un entretien, basé sur leur CV. Une prédiction positive signifie que le candidat devrait être invité en entretien.

Dans un Mindset Recall, tu acceptes que le modèle sélectionne quelques candidats incompétents.

Mindset Recall : Concentre-toi simplement sur la classification correcte de tous les samples positifs

Mais il ne doit surtout pas passer à côté d'un candidat compétent.

Donc même si ce système dit que tous les candidats (bons ou mauvais) sont aptes pour un entretien, ça donne un Recall de 100%.

C'est parce qu'il n'a manqué aucun des samples positifs.

La métrique à choisir dépend entièrement de ce qui compte pour le problème en question :

Optimise la Precision si :

1. Tu veux obtenir UNIQUEMENT des prédictions positives de haute qualité.

2. Tu acceptes que certains samples de qualité (ou positifs) soient laissés de côté.

Optimise le Recall si :

1. Tu veux identifier TOUS les samples de qualité (ou positifs) correctement.

2. Tu acceptes que certains samples de moindre qualité (ou négatifs) se glissent dans le lot.

Mais en pratique, optimiser uniquement pour un Recall élevé n'est pas très utile.

C'est parce que même si tu implémentes une simple fonction qui prédit toujours "positif", le classifieur aura quand même un Recall de 100%. Car notre modèle naïf classifie correctement toutes les instances positives.

En revanche, optimiser pour une Precision élevée demande un vrai travail d'ingénierie.

J'espère que c'était utile :)

👉 À toi : quelle analogie as-tu utilisée la première fois pour comprendre la Precision et le Recall ?

Introduction

Grâce aux avancées des frameworks open-source comme PyTorch, exploiter un GPU pour accélérer l'entraînement d'un modèle de deep learning tient en une seule ligne, comme illustré ci-dessous :

Si cette encapsulation est aussi simple que possible, l'implémentation sous-jacente, celle qui permet aux GPU d'accélérer les calculs, reste un mystère pour beaucoup.

Plus précisément : que se passe-t-il réellement quand on appelle .cuda() ?

Dans ce deep dive, on va décortiquer la mécanique de la programmation GPU.

Plus précisément, on va comprendre comment CUDA, une interface de programmation développée par NVIDIA, permet aux développeurs d'exécuter des processus sur leurs GPU, et comment cette implémentation fonctionne en coulisses.

Pour ça, on va faire un vrai travail pratique de programmation CUDA et implémenter des versions parallélisées de plusieurs opérations qu'on utilise en permanence en deep learning.

C'est parti !

Qu'est-ce que CUDA ?

En résumé, CUDA (Compute Unified Device Architecture) est une plateforme de calcul parallèle et un modèle d'interface de programmation (API) créés par NVIDIA.

Il permet aux développeurs d'utiliser un GPU compatible CUDA pour du calcul généraliste.

Pour exploiter la puissance de calcul du GPU, CUDA fournit une interface implémentée en C/C++. Elle permet d'accéder à la mémoire du GPU et d'y exécuter des opérations de calcul.

Dans le contexte du deep learning, ce sont typiquement des opérations mathématiques et générales comme :

• Additionner des matrices/vecteurs

• Multiplier des matrices

• Transformer une matrice en lui appliquant une fonction, comme une fonction d'activation, un dropout, etc.

• Déplacer des données du CPU vers le GPU, puis les rapatrier

• Et bien plus encore

Autrement dit : tout comme Pandas permet aux développeurs d'interagir facilement avec des données tabulaires via des structures et opérations haut niveau, CUDA offre un niveau d'abstraction équivalent, mais pour le calcul sur GPU NVIDIA.

En masquant la complexité sous-jacente liée au GPU (gestion de la mémoire, gestion des threads, gestion des blocs), CUDA permet aux développeurs de se concentrer sur le problème de calcul à résoudre plutôt que sur les subtilités du matériel sur lequel il tourne.

Bien sûr, comme évoqué plus haut, CUDA fournit une interface C/C++, et les frameworks de deep learning comme PyTorch ont simplifié tout ça en construisant un wrapper Python autour :

Donc quand on développe des modèles de deep learning, on utilise une API Python qui, en coulisses, s'appuie sur des instructions C/C++ fournies par CUDA pour dialoguer avec le GPU.

Pour être clair, l'objectif de ce dossier est de comprendre ce chemin CUDA → instructions GPU, et comment il est implémenté.

Une certaine aisance en C/C++ est un plus, mais ce n'est pas indispensable : le design de l'API est plutôt intuitif. Cela dit, je t'apporterai des explications complémentaires à chaque étape si tu n'as jamais touché au C++.

Le problème avec les CPU

Quand il s'agit de paralléliser, l'approche traditionnelle avec les CPU repose sur les threads (fils d'exécution), qui portent des instructions que le processeur peut exécuter indépendamment.

Prenons par exemple cette simple boucle for en C, qui réalise les opérations d'une couche linéaire classique :

Observe cette boucle for dans le code ci-dessus. Elle parcourt les éléments des tableaux un par un, calcule le résultat individuel, et le stocke dans le tableau de sortie.

Si tu regardes de près, toutes ces opérations individuelles sont indépendantes les unes des autres.

la i-ème opération ne dépend pas de la j-ème opération

Elles pourraient donc être exécutées en parallèle. Pourtant, l'implémentation ci-dessus utilise une approche séquentielle : chaque opération attend que la précédente se termine avant de démarrer.

Les CPU modernes peuvent gérer plusieurs threads simultanément grâce à des techniques comme le multi-threading. On peut donc s'en servir pour que la boucle génère plusieurs threads, potentiellement un par cœur, afin de traiter différentes parties du tableau en même temps.

Et c'est assez intuitif : plus on ajoute de threads, plus le niveau de parallélisme qu'on peut atteindre est élevé.

En deep learning, les choses sont différentes.

Les briques de base des modèles de deep learning, les vecteurs et les matrices, peuvent contenir des millions d'éléments.

Or, par nature, les CPU sont limités dans leur degré de parallélisme à cause d'un nombre de cœurs restreint (même les CPU grand public haut de gamme dépassent rarement 16 cœurs).

Les GPU, eux, sont des architectures modernes capables de faire tourner des millions de threads en parallèle. Ça améliore considérablement les performances de ces opérations mathématiques quand on manipule des vecteurs et des matrices de très grande taille.

Un exemple pour illustrer

Prenons l'opération de multiplication matricielle ci-dessous, omniprésente en deep learning :

Fondamentalement, une multiplication matricielle n'est qu'une série de produits scalaires indépendants entre vecteurs, comme illustré dans l'animation ci-dessous :

• La 1ʳᵉ ligne de la matrice de gauche est multipliée avec :

  • La 1ʳᵉ colonne de la matrice de droite

  • La 2ᵉ colonne de la matrice de droite

  • La 3ᵉ colonne de la matrice de droite

• Et ainsi de suite

• La 2ᵉ ligne de la matrice de gauche est multipliée avec :

  • La 1ʳᵉ colonne de la matrice de droite

  • La 2ᵉ colonne de la matrice de droite

  • La 3ᵉ colonne de la matrice de droite

  • Et ainsi de suite

• Et ainsi de suite...

Si tu regardes bien, toutes ces opérations sont indépendantes les unes des autres. Elles pourraient donc, en théorie, toutes être exécutées en parallèle.

Mais comme on l'a vu, les CPU disposant d'un nombre de threads assez limité, ils ne sont pas idéaux pour exploiter tout le potentiel de parallélisation de ces multiplications matricielles.

Autrement dit, les CPU ne gèrent généralement qu'une poignée de dizaines de threads simultanément, ce qui limite leur efficacité pour exécuter un grand nombre d'opérations indépendantes en même temps, comme celles requises par des multiplications matricielles à grande échelle.

Comment les GPU aident-ils ?

Il faut clarifier un point important : les CPU ne sont pas "mauvais".

Il y a une raison pour laquelle tous les ordinateurs modernes embarquent systématiquement un CPU, mais pas nécessairement un GPU "rapide". C'est parce que le CPU et le GPU sont conçus pour atteindre des objectifs complètement différents.

Pour commencer, les calculs CPU sont généralement plus rapides que ceux du GPU pour une opération unique. Autrement dit, ils sont conçus pour exécuter rapidement une séquence d'opérations mono-thread. Pour maintenir cette vitesse, ils ne peuvent exécuter qu'un nombre limité de threads en parallèle.

À l'inverse, les GPU sont conçus pour exécuter des millions de threads en parallèle, au prix de la vitesse de chaque thread pris individuellement.

Donc même si un thread met moins de temps à s'exécuter sur un CPU, le fait que les GPU puissent en exécuter des millions en parallèle démultiplie considérablement le temps d'exécution global.

Une analogie tirée de la vraie vie

Une analogie que j'ai entendue il y a des années, quand j'ai découvert ces concepts, compare le CPU à une voiture de F1 et le GPU à un bus.

Si l'objectif est de déplacer une seule personne d'un point A à un point B, alors la voiture de F1, c'est-à-dire le CPU, sera le choix idéal.

En revanche, si l'objectif est de déplacer beaucoup de personnes d'un point à un autre, alors le bus, c'est-à-dire le GPU, sera le choix idéal. Et ce, même si une F1 mettra moins de temps à parcourir la distance entre A et B.

Le bus peut transporter tout le monde en un seul trajet, là où la F1 devrait multiplier les allers-retours.

Même si Python est probablement l'un des langages de programmation les plus faciles pour débuter, il y a BEAUCOUP de choses qui le rendent parfois étrange et contre-intuitif.

Aujourd'hui, je veux te partager une particularité des dictionnaires Python que la plupart des développeurs Python ignorent.

C'est parti !

Supposons qu'on déclare le dictionnaire Python suivant :

On ajoute quatre clés lors de cette déclaration de dictionnaire :

• Le type Integer 1

• Le type Float 1.0

• Le type Boolean True

• Le type String '1'

Ces quatre clés sont quatre objets différents, ce qu'on peut aussi vérifier en affichant leurs identifiants d'objet respectifs avec la méthode id() :

On pourrait donc s'attendre à ce que le dictionnaire final contienne quatre clés.

Pourtant, quand on affiche le dictionnaire ci-dessus, on constate qu'il n'y a que deux clés :

Où sont passées les deux autres clés ?

Qu'est-ce qui nous échappe ?

Fonctionnement interne d'un dictionnaire Python

La plupart des développeurs Python pensent que les dictionnaires recherchent/insèrent/suppriment une clé en se basant sur l'ID de l'objet ajouté comme clé.

Mais ce n'est pas vrai.

En réalité, les dictionnaires font cela en utilisant l'équivalence de hash, calculée via la méthode hash().

Ainsi, si deux objets ont la même valeur de hash, le dictionnaire les considérera comme des clés identiques.

C'est exactement ce qu'on observe avec les objets « Integer 1 », « Float 1.0 » et « Boolean True ».

Comme illustré ci-dessous, ces trois objets ont la même valeur de hash :

En conséquence, un dictionnaire Python les considère comme des clés identiques, bien qu'il s'agisse d'objets totalement différents.

Un point important à noter : le dictionnaire final conserve la clé « Integer 1 », mais sa valeur est celle correspondant à la clé « Boolean True ».

Cela s'explique par l'ordre dans lequel on a spécifié les clés lors de la déclaration du dictionnaire :

Décomposons les étapes :

• Quand l'objet dictionnaire est créé, le dictionnaire est vide. À partir de là, les clés vont être ajoutées une par une.

• D'abord, « Integer 1 » est ajouté, et le dictionnaire devient :

• Ensuite, en ajoutant « Float 1.0 », Python détecte une équivalence de hash avec la clé existante « Integer 1 ». La clé existante (« Integer 1 ») est donc conservée, mais sa valeur est mise à jour :

• En continuant, lors de l'ajout de « Boolean True », une nouvelle équivalence de hash se produit avec la clé existante « Integer 1 ». Encore une fois, la clé existante (« Integer 1 ») est conservée, mais sa valeur est mise à jour :

• Enfin, en ajoutant « String 1 », aucune équivalence de hash ne se produit, et une nouvelle clé est ajoutée, ce qui nous donne le dictionnaire suivant :

On peut valider ce raisonnement en changeant l'ordre dans lequel on a spécifié les clés lors de la déclaration du dictionnaire :

Cette fois, on obtient un résultat différent, mais il est cohérent avec le raisonnement ci-dessus.

Ce qu'il faut retenir

Contrairement à une croyance répandue, les dictionnaires Python ne recherchent/insèrent/suppriment jamais les clés en se basant sur l'identité des objets. Ils utilisent l'équivalence de hash.

Consulte ces autres shots data pour découvrir d'autres particularités ou subtilités techniques de Python souvent mal interprétées :

• Une fonctionnalité vicieuse de Python que beaucoup de développeurs ignorent

• L'erreur la plus courante sur l'immutabilité des tuples

• Comment Python nous empêche d'ajouter une liste comme clé de dictionnaire

• Une idée reçue courante sur la suppression d'objets en Python

• Un for-loop et une list comprehension sont fondamentalement différents au niveau du scope

👉 À toi : quels sont les autres concepts techniques de Python que la plupart des développeurs interprètent mal ?

Une des choses qui me rend toujours un peu prudent et sceptique quand j'utilise kNN, c'est sa HAUTE sensibilité au paramètre k.

Pour mieux comprendre, considère ce dataset fictif en 2D ci-dessous. Le point rouge est une instance de test pour laquelle on veut générer une prédiction avec kNN.

Disons qu'on fixe k=7.

La prédiction pour l'instance rouge se fait en deux étapes :

1. D'abord, on identifie les 7 plus proches voisins du point rouge.

2. Ensuite, on l'assigne à la classe la plus représentée parmi ces 7 voisins.

C'est illustré ci-dessous :

Le problème, c'est que l'étape 2 repose entièrement sur la notion de contribution de classe : la classe qui contribue le plus parmi les k plus proches voisins est assignée au point.

Mais ça peut échouer lamentablement dans certains cas, surtout quand une classe a peu d'échantillons.

Par exemple, comme montré ci-dessous, avec k=7, le point rouge ne pourra JAMAIS être assigné à la classe jaune, peu importe à quel point il est proche de ce cluster :

S'il est facile d'ajuster visuellement l'hyperparamètre k dans cette démo, cette approche est inapplicable sur des datasets en haute dimension.

Il existe deux façons de résoudre ce problème.

Solution #1 : Utiliser un kNN pondéré par la distance

Les kNN pondérés par la distance sont une alternative bien plus robuste aux kNN traditionnels.

Comme leur nom l'indique, à l'étape 2, ils prennent en compte la distance au plus proche voisin.

Résultat : plus un voisin est proche, plus il aura d'impact sur la prédiction finale.

Son efficacité est évidente sur l'image ci-dessous.

• Sur le premier graphique, le kNN traditionnel (avec k=7) ne peut jamais prédire la classe bleue.

• Sur le second graphique, le kNN pondéré par la distance se montre bien plus robuste dans sa prédiction.

D'après mon observation, un kNN pondéré par la distance fonctionne généralement bien mieux qu'un kNN traditionnel. Et intuitivement, ça se tient.

Pourtant, ça peut passer inaperçu parce que, par défaut, l'implémentation kNN de sklearn utilise une pondération "uniform".

Solution #2 : Mettre à jour dynamiquement l'hyperparamètre k

Reprenons la démo ci-dessus :

Ici, on pourrait arguer qu'il ne faut jamais fixer l'hyperparamètre k à une valeur supérieure au nombre minimum d'échantillons d'une classe dans le dataset.

Bien sûr, je suis d'accord avec ça, dans une certaine mesure.

Mais laisse-moi t'expliquer l'inconvénient de cette approche.

Fixer une valeur très basse de k peut être très problématique dans le cas de datasets extrêmement déséquilibrés.

Pour te donner plus de contexte, j'ai personnellement utilisé kNN sur des datasets qui ne contenaient qu'une ou deux instances pour une classe donnée dans le training set.

Et j'ai constaté que fixer un k bas (disons 1 ou 2) menait à des performances sous-optimales parce que le modèle n'évaluait pas les patterns de voisinage de manière aussi globale que lorsqu'un k élevé était utilisé.

Autrement dit, fixer une valeur relativement plus grande de k donne généralement des prédictions plus éclairées qu'avec des valeurs basses.

Mais on vient de voir que si on fixe un k élevé, la classe majoritaire peut dominer le résultat de classification :

Pour résoudre ce problème, j'ai trouvé que mettre à jour dynamiquement l'hyperparamètre k était bien plus efficace.

Plus précisément, cette approche se décompose en trois étapes.

Pour chaque instance de test :

1. Commence avec une valeur standard de k comme d'habitude et identifie les k plus proches voisins.

2. Ensuite, mets à jour la valeur de k comme suit :

• Pour toutes les classes uniques présentes parmi les k plus proches voisins, trouve le nombre total d'instances d'entraînement qu'elles contiennent.

• Mets à jour la valeur de k en :

3. Effectue maintenant le vote majoritaire uniquement sur les k' premiers voisins.

Intuitivement, ça se tient aussi :

• Si une classe minoritaire apparaît dans les k plus proches voisins, on doit réduire la valeur de k pour que la classe majoritaire ne domine pas.

• Si une classe minoritaire N'apparaît PAS dans les k plus proches voisins, on ne modifiera probablement pas la valeur de k et on procédera à une classification plus globale.

Le seul inconvénient, c'est que tu ne trouveras pas cette approche dans des implémentations open-source. D'ailleurs, dans mes propres projets aussi, j'ai dû écrire une implémentation custom, donc garde ça en tête.

👉 À toi : Quelles sont d'autres façons de rendre les kNN plus robustes quand une classe a peu d'échantillons ?

La méthode apply() de Pandas est l'approche la plus courante pour appliquer une fonction le long d'un axe d'un DataFrame/Series.

D'après mon expérience, la plupart des utilisateurs de Pandas sont convaincus qu'apply() est une méthode vectorisée.

Autrement dit, ils pensent qu'apply() opère efficacement, élément par élément, comme les autres opérations vectorisées de Pandas.

Mais c'est FAUX.

Contrairement à cette croyance répandue, chaque utilisateur de Pandas DOIT savoir que la méthode apply() n'est PAS vectorisée.

En réalité, c'est simplement une boucle for Python déguisée, qui n'offre aucune des optimisations liées à la vectorisation auxquelles on pourrait s'attendre.

Résultat : le code s'exécute toujours à la vitesse native de Python. Autrement dit, lentement.

Quelles sont les solutions ?

Une solution consiste à éliminer la méthode apply() en utilisant une approche vectorisée à la place.

Mais je comprends que parfois, trouver une approche vectorisée n'est pas simple.

Une autre solution que je trouve pratique est de paralléliser la méthode apply() en utilisant des bibliothèques tierces optimisées.

L'image ci-dessous compare le run-time de Pandas apply() avec quatre alternatives qui supportent la parallélisation :

Il est évident que la méthode apply() de Pandas n'est pas la façon optimale d'appliquer une fonction. C'est même la plus lente des cinq.

Il y a deux raisons à cela :

1. Pandas s'exécute TOUJOURS sur un seul cœur du CPU. Il ne possède donc aucune capacité de parallélisation qu'il pourrait exploiter.

2. La méthode apply() de Pandas n'est pas vectorisée. Elle ne possède donc aucune capacité de vectorisation non plus.

Honnêtement, si les quatre bibliothèques externes présentées dans le visuel ci-dessus ne possèdent pas non plus de capacités de vectorisation, elles exploitent en revanche la parallélisation.

C'est comme ça qu'on observe une amélioration massive du run-time en les utilisant.

Note bien ici que même si mapply() est la plus rapide dans cet exemple, cela ne signifie pas qu'elle le sera toujours. Pense à faire un benchmark sur ton propre dataset d'abord.

De plus, je sais que la méthode add_row() que j'ai utilisée dans l'image ci-dessus peut facilement être vectorisée. J'ai choisi cet exemple particulier uniquement par souci de simplicité.

En guise de mot de la fin, retiens que ta première tentative doit TOUJOURS être d'écrire des opérations vectorisées.

N'envisage ces bibliothèques tierces que lorsque tu ne vois aucune possibilité d'écrire du code vectorisé, et que tu n'as pas d'autre choix que d'utiliser apply().

Pour démarrer avec ces bibliothèques :

• Swifter : https://github.com/jmcarpenter2/swifter

• Pandarallel : https://github.com/nalepae/pandarallel

• Parallel Pandas : https://pypi.org/project/parallel-pandas/

• Mapply : https://pypi.org/project/mapply/

👉 À toi : Quelles autres techniques utilises-tu couramment pour optimiser les opérations Pandas ?

D'expérience, beaucoup d'erreurs inattendues dans les bibliothèques, outils et langages sont liées à la présence de valeurs manquantes.

Par exemple, considère un array NumPy 1D contenant des valeurs NaN.

Quand on agrège cet array NumPy pour calculer, disons, sa somme, on obtient le résultat suivant :

Étrange, non ?

Alors qu'un résultat de 6 aurait eu plus de sens ici, NumPy produit une valeur NaN à la place.

Bref, ce n'est pas le sujet du jour, mais tu vois l'idée.

Une erreur silencieuse similaire existe aussi en SQL, plus précisément dans l'utilisation de la clause NOT IN, et beaucoup d'utilisateurs SQL ne la connaissent pas.

Voyons ça !

Imaginons qu'on a les tables suivantes (students et names) dans notre base de données :

L'objectif est de sélectionner les enregistrements de la table students où first_name n'est pas dans la table names.

Une façon de faire est d'utiliser la clause NOT IN, comme ci-dessous :

Et on obtient bien les résultats attendus.

Tout va bien jusque-là !

Maintenant, supposons que notre table names contienne une valeur NULL :

Si on relance la même requête, on n'obtient aucun résultat cette fois :

Petite parenthèse : si on avait utilisé la clause IN pour sélectionner les lignes de la table students où first_name est dans la table names, on constate que ça fonctionne comme prévu :

image

C'est étrange, non ?

Pourquoi n'obtient-on aucun résultat avec NOT IN ?

La raison pour laquelle NOT IN ne retourne aucun résultat alors que IN fonctionne comme prévu tient au fonctionnement interne de ces deux clauses.

Pour simplifier, imaginons qu'on vérifie le premier enregistrement (où first_name est "John") de la table students :

La clause WHERE a besoin d'une valeur booléenne pour déterminer si un enregistrement doit être retenu ou non.

Quand on utilise IN, cette valeur booléenne est évaluée avec l'opérateur OR comme suit :

Si n'importe quelle condition est TRUE, la ligne est retenue.

En revanche, quand on utilise NOT IN, la valeur booléenne est évaluée avec l'opérateur AND comme suit :

Pour que cette expression soit TRUE, toutes les conditions individuelles DOIVENT être TRUE.

Mais la condition (JOHN != None) pose problème car, en règle générale, elle produit une valeur UNKNOWN.

L'expression entière s'évalue donc à UNKNOWN, et aucun enregistrement n'est retourné.

C'est le cas pour chaque enregistrement de la table students. Résultat : la requête ne retourne aucun enregistrement :

Que faire à la place ?

Il existe plusieurs façons d'éviter ça.

Puisque notre objectif est de sélectionner les enregistrements de la table students où first_name n'est pas dans la table names, on peut :

• Filtrer les valeurs NULL dans la sous-requête :

• Utiliser un Anti Join : un anti join retourne uniquement les lignes de la table de gauche qui n'ont aucune correspondance dans la table de droite. C'est exactement ce qu'il nous faut ici, et voici comment l'implémenter :

Ce genre d'erreurs peut parfois prendre un temps considérable à débugger si tu n'en as pas conscience au préalable.

J'espère que ça t'a été utile !

Si tu veux expérimenter avec ce qu'on a vu sur la clause NOT IN aujourd'hui, télécharge ce Jupyter Notebook : Notebook Clause NOT IN.

👉 À toi : peux-tu proposer une autre solution au problème ci-dessus ?

Dans un précédent deep dive consacré à la compression de modèles, nous avons passé en revue différentes façons de compresser un modèle ML une fois qu'il est entraîné.

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.

• Tu as peut-être entraîné un modèle, mais il est trop gros pour être déployé. Les techniques de compression t'aident à régler ça.

• Ou alors, tu veux utiliser un modèle open-source sur ta machine locale, et il est trop volumineux pour tenir en mémoire.

Dans ce deep dive là, nous avons vu plusieurs techniques qui permettent de réduire l'empreinte mémoire des modèles ML et de les rendre plus accessibles et plus déployables.

L'une de ces techniques était la quantization. Nous l'avions abordée avec un certain niveau de détail, mais pas avec toute la précision que ce sujet mérite vraiment pour un ingénieur ML.

Dans ce dossier, on plonge donc dans les détails techniques de la quantization : ce que c'est, comment ça marche, et pourquoi c'est l'une des techniques les plus puissantes pour exploiter de gros modèles sur des machines ordinaires.

C'est parti !

Motivation

En règle générale, les paramètres d'un réseau de neurones (les poids des couches) sont représentés avec des nombres à virgule flottante sur 32 bits.

Le raisonnement est le suivant : comme les paramètres d'un modèle ML ne sont contraints à aucune plage de valeurs précise, assigner un type de données capable de couvrir une large plage est une décision prudente. Ça évite l'instabilité numérique et maintient une haute précision pendant l'entraînement comme à l'inférence.

Évidemment, le gros inconvénient de cette approche, c'est qu'utiliser le plus grand type de données signifie aussi que le modèle consomme plus de mémoire.

Imagine qu'on puisse représenter ces mêmes paramètres avec des formats plus compacts : 16 bits, 8 bits, 4 bits, voire 1 bit, tout en préservant l'essentiel de l'information.

Plutôt cool, non ?

Ça réduirait drastiquement la quantité de mémoire nécessaire pour stocker les paramètres du modèle, sans compromettre significativement sa précision.

C'est exactement ce que permettent les techniques de quantization.

Dans ce dossier, on va comprendre en détail pourquoi la quantization est nécessaire et à quel moment il vaut mieux quantizer le modèle, puis explorer les différents types de données et les méthodes de quantization modernes.

Qu'est-ce que la quantization ?

Formellement, la quantization est le processus qui consiste à convertir des valeurs depuis une représentation riche en information (généralement un ensemble continu) vers une représentation plus compacte (généralement un ensemble discret).

Un bon exemple de quantization, c'est l'échantillonnage d'un signal analogique : chaque valeur d'un signal continu se voit assigner une valeur tirée d'un ensemble discret prédéfini.

Dans le contexte des réseaux de neurones, la quantization consiste à convertir la précision des nombres (principalement les paramètres) utilisés dans notre modèle, en passant d'une haute précision (comme un float 32 bits) à une précision plus basse (comme un entier 4 bits).

Pourquoi quantizer ?

La raison est assez évidente.

Ça économise de la mémoire, ce qui, à son tour, économise de l'argent.

Pour te donner un ordre de grandeur, prends un modèle ML avec plus d'un million de paramètres, chacun représenté par un float 32 bits.

Si on peut les représenter avec des nombres sur 8 bits, on obtient une baisse significative de l'usage mémoire (environ 75 %), tout en conservant la capacité de représenter une large plage de valeurs.

De plus, les modèles quantizés nécessitent moins de ressources de calcul et sont plus rapides. Résultat : ils font économiser de l'argent et améliorent l'expérience utilisateur.

Enfin, tout le monde n'a pas accès à de gros clusters de GPU pour faire tourner d'énormes modèles ML. Avec la quantization, les chercheurs et passionnés sans cluster GPU personnel peuvent expérimenter facilement avec de gros modèles modernes. Autrement dit, on peut exécuter efficacement des calculs directement sur les appareils des utilisateurs.

Bien sûr, la quantization introduit un compromis entre efficacité (taille du modèle) et précision (accuracy). En réduisant la précision numérique, les prédictions du modèle deviennent plus approximatives que celles du modèle original en pleine précision.

Quantization vs entraînement en précision mixte

L'entraînement en précision mixte (mixed precision training) est une technique similaire qui repose elle aussi sur l'usage de plusieurs types de données.

Quantization et précision mixte servent toutes deux à optimiser l'efficacité computationnelle des modèles ML, mais elles s'attaquent à des aspects différents, avec des approches d'implémentation et des compromis distincts.

Avant de passer aux techniques de quantization, il est donc important de bien comprendre ce qui les sépare.

Quantization

Comme on l'a vu plus haut, la quantization consiste à réduire la précision des poids et des activations, en passant de formats haute précision (comme le float 32 bits) à des formats basse précision (comme les entiers 16 ou 8 bits).

Son objectif premier est de rendre les modèles plus petits et plus rapides à l'inférence, ce qui est particulièrement utile pour déployer des modèles sur des appareils aux ressources limitées.

Entraînement en précision mixte

L'entraînement en précision mixte, lui, vise à accélérer le processus d'entraînement en utilisant à la fois de l'arithmétique haute précision (float 32 bits) et basse précision (float 16 bits) au sein du même modèle.

On a déjà couvert ce sujet dans ce shot data ci-dessous :

Mixed Precision Training avec PyTorch — Guide pratique

Entraîne tes modèles deep learning 2,5× plus vite avec la mix précision training. Réduis la mémoire, augmente la vitesse sans sacrifier la précision.

…mais faisons un rapide rappel de son fonctionnement.

Comment fonctionne l'entraînement en précision mixte ?

Les bibliothèques de deep learning classiques sont très conservatrices dans l'attribution des types de données.

Par défaut, le type assigné est souvent du 64 bits ou du 32 bits, alors qu'il y aurait par exemple de la marge pour du 16 bits. C'est ce qu'illustre le code ci-dessous :

Résultat : on n'est pas du tout optimal dans l'allocation mémoire.

Bien sûr, ce choix vise à garantir une meilleure précision dans la représentation de l'information.

Mais cette précision a toujours un coût : une consommation mémoire supplémentaire, pas toujours souhaitable selon les situations.

On observe d'ailleurs que beaucoup d'opérations sur les tenseurs, en particulier la multiplication matricielle, sont bien plus rapides avec des types de données de plus faible précision, comme le montre l'exemple ci-dessous :

Par ailleurs, comme le float16 ne fait que la moitié de la taille du float32, son usage réduit la mémoire nécessaire pour entraîner le réseau.

Ça permet aussi d'entraîner de plus gros modèles, ou de travailler sur des mini-batches plus grands (ce qui accélère encore davantage l'entraînement), etc.

L'entraînement en précision mixte est une technique fiable et largement adoptée dans l'industrie pour atteindre cet objectif.

Comme son nom l'indique, l'idée est d'employer du float16 basse précision (partout où c'est faisable, comme dans les convolutions et les multiplications matricielles) en complément du float32. D'où le nom de « précision mixte ».

Voici une liste de quelques modèles que j'ai trouvés et qui ont été entraînés en précision mixte :

On voit clairement que la précision mixte est bien plus utilisée qu'on ne le croit, même si on en entend rarement parler.

Si tu veux entrer dans le détail technique et l'implémentation, jette un œil à cette newsletter :

Mixed Precision Training avec PyTorch — Guide pratique

Entraîne tes modèles deep learning 2.5× plus vite avec la mix précision training. Réduis la mémoire, augmente la vitesse sans sacrifier la précision.

Pour bien marquer la différence une dernière fois :

• La quantization se concentre avant tout sur l'optimisation de l'inférence : rendre les modèles plus petits et plus rapides pour le déploiement (même s'il existe aussi des façons de l'utiliser pendant l'entraînement).

• L'entraînement en précision mixte sert principalement pendant la phase d'entraînement, pour l'accélérer et réduire l'usage mémoire.

Dans un récent shot data, on a abordé une différence fondamentale entre les boucles for et les list comprehensions en Python.

Voici le visuel de ce post pour un rappel rapide :

En résumé :

• Après l'exécution d'une boucle for, la variable de boucle reste accessible.

• Après l'exécution d'une list comprehension, la variable de boucle N'EST PAS accessible.

Comme je l'ai mentionné dans ce shot data, c'est étroitement lié à la notion de scope en Python.

Voyons ça aujourd'hui.

Qu'est-ce que le scope d'une variable et pourquoi en a-t-on besoin ?

En termes simples, le scope d'une variable désigne les zones de ton programme dans lesquelles une variable donnée est accessible.

Ce concept n'est pas propre à Python. Il s'applique à la programmation en général.

L'objectif est de limiter l'accès aux variables à des zones précises du code, afin d'éviter qu'elles soient modifiées depuis n'importe quel endroit du programme.

Ainsi, quand tu accèdes à N'IMPORTE QUELLE variable, c'est le scope qui détermine entièrement comment les noms seront recherchés dans ton code.

En Python, la résolution de scope se fait sur quatre niveaux.

Chaque fois que tu accèdes à un nom en Python (nom de variable, nom de fonction, nom de classe, etc.), l'interpréteur Python le recherche dans l'ordre suivant :

1. Local

2. Enclosing (englobant)

3. Global

4. Built-in

C'est ce qu'on appelle la règle LEGB.

Résolution de scope LEGB en Python

Voyons chacun de ces niveaux !

#1) Scope local

L'exemple le plus simple de scope local, ce sont des variables déclarées à l'intérieur d'une fonction, comme illustré ci-dessous :

La variable myVar a un scope local dans funcA, ce qui signifie qu'elle n'est accessible qu'à l'intérieur de la fonction.

Si tu essaies d'accéder à myVar en dehors de funcA, tu obtiens, sans surprise, une erreur car la variable est locale à funcA :

Ensuite, si tu as deux fonctions non imbriquées, tu remarqueras que les variables déclarées dans une fonction ne sont pas accessibles dans l'autre :

C'est le principe du scope local, et en Python, il a la priorité la plus haute lors de la résolution de scope.

Autrement dit, si le même nom de variable existe à plusieurs endroits dans un programme, Python utilisera la variable qui se trouve dans le scope local depuis lequel elle a été accédée.

Par exemple, dans le code ci-dessous, myVar est déclarée dans funcA et dans funcB. Quand on appelle funcA(), Python trouve myVar dans le scope local et l'affiche :

Si la variable est trouvée dans le scope local, parfait.

Sinon, Python passe au scope englobant (s'il existe) pour trouver la variable.

#2) Scope englobant (Enclosing)

En Python, le scope englobant apparaît quand tu as des fonctions imbriquées, c'est-à-dire une ou plusieurs fonctions à l'intérieur d'une autre fonction.

Par exemple, reprends le dernier code ci-dessus. Déclarons funcB à l'intérieur de funcA.

Le scope local et le scope englobant par rapport à funcB sont illustrés ci-dessous :

Considère maintenant le code suivant, où myVar n'est pas disponible dans le scope local de funcB :

Comme le scope local ne contient pas de variable myVar, Python va d'abord vérifier s'il existe un scope englobant.

Oui, il y en a un : funcA !

Ensuite, il va vérifier si myVar est déclarée dans funcA.

Bien sûr que oui !

Python utilise la valeur déclarée dans le scope englobant pour myVar :

#3) Scope global

Le scope global, comme tu l'as probablement deviné, est le scope le plus large.

Ici, les variables et fonctions sont déclarées en dehors de tout bloc, fonction ou classe spécifique.

Elles sont donc accessibles (mais pas directement modifiables) depuis n'importe quelle partie du programme, peu importe où elles sont définies.

Par exemple, dans le code ci-dessous, ni funcA ni funcB n'ont la variable myVar définie dans leur scope local respectif :

Il n'y a pas non plus de scope englobant.

Python vérifie donc si myVar est disponible dans le scope global, et elle l'est effectivement.

Ainsi, lors des print, on obtient la valeur globale de myVar, à savoir 10.

En guise d'exercice, peux-tu dire quel sera l'output dans ce cas :

#4) Scope built-in

Le dernier dans l'ordre de priorité de la résolution de scope est le scope built-in.

Ce sont des noms de variables qui sont automatiquement chargés dans le scope global de Python quand tu :

• exécutes un script,

• ou ouvres une session Python interactive.

Ces variables built-in sont accessibles via le nom __builtins__, et il y en a plus de 150 :

Parmi les plus courants : float, int, len, set, dict, range, str, zip, et bien d'autres.

Si une variable n'est pas trouvée dans le scope local, ni dans le scope englobant, ni même dans le scope global, Python tente de la trouver dans le scope built-in.

Et c'est ainsi que fonctionne la résolution de scope en Python.

Retour à l'exemple : list comprehension vs. boucle for 👇

La variable de boucle (loop_var) n'est pas accessible après l'exécution d'une list comprehension parce qu'elle est définie dans son scope local.

En revanche, la variable de boucle est définie dans le scope global dans la boucle for du code ci-dessus. Elle reste donc accessible après l'exécution de la boucle.

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

👉 À toi de jouer : sais-tu comment modifier une variable globale depuis le scope local d'une fonction ?

Les algorithmes non paramétriques non supervisés sont largement utilisés en entreprise pour analyser de grands jeux de données.

La raison est simple : dans beaucoup d'applications concrètes, obtenir les vraies étiquettes (labels) est très difficile, voire impossible.

Dans ces cas-là :

• Soit les équipes data annotent les données, ce qui peut s'avérer infaisable en pratique,

• Soit on utilise des méthodes non supervisées pour identifier des patterns.

Si KMeans est très répandu ici grâce à sa simplicité et son efficacité en tant qu'algorithme de clustering, il a de nombreuses limites :

• Il ne prend pas en compte la covariance des clusters.

• Il ne peut produire que des clusters sphériques. Comme tu peux le voir ci-dessous, même si les données forment des clusters non circulaires, il produit quand même des clusters ronds.

Les algorithmes basés sur la densité, comme DBSCAN, répondent assez efficacement à ces limitations.

L'idée centrale derrière DBSCAN est de regrouper les points de données en fonction de la "densité", c'est-à-dire que les points proches les uns des autres dans une région de haute densité sont groupés ensemble, et séparés des autres par des régions de plus faible densité.

Mais malheureusement, avec DBSCAN, on se heurte à un autre problème souvent sous-estimé.

L'un des éléments qui rend DBSCAN parfois inutilisable en pratique, c'est son temps d'exécution.

Jusqu'à récemment, on pensait que DBSCAN avait une complexité de O(nlogn), mais il a été prouvé qu'elle est de O(n²) dans le pire des cas.

D'ailleurs, on peut aussi le vérifier sur la figure ci-dessous. Elle montre le temps d'exécution de DBSCAN en fonction du nombre d'échantillons :

C'est clair : DBSCAN a une relation quadratique avec la taille du jeu de données.

Il y a donc un besoin croissant de développer des versions plus efficaces de DBSCAN.

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

En résumé, DBSCAN++ repose sur l'observation suivante : on n'a besoin de calculer les estimations de densité que pour un sous-ensemble "m" des "n" points du jeu de données, où "m" peut être bien plus petit que "n" pour obtenir un clustering correct.

L'efficacité de DBSCAN++ est évidente sur l'image ci-dessous :

Sur un jeu de données de 60 000 points :

• DBSCAN++ est 20x plus rapide que DBSCAN.

• DBSCAN++ produit de meilleurs scores de clustering que DBSCAN.

Mais comment ça fonctionne de bout en bout ?

• Pourquoi sélectionner un sous-ensemble de points reste efficace ?

• Quelles stratégies peut-on utiliser pour sélectionner ce sous-ensemble ?

• Quelles autres limitations DBSCAN++ résout-il ?

• DBSCAN++ est un algorithme récent. Quels sont les points à garder en tête pour l'utiliser efficacement ?

Si tu es curieux, le dernier deep dive en machine learning traite exactement de ce sujet : DBSCAN++ : l'alternative plus rapide et scalable au clustering DBSCAN.

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.

La plupart des jeux de données réels sont non supervisés et naturellement très volumineux :

• KMeans n'est généralement pas adapté à cause des hypothèses strictes mentionnées plus haut.

• DBSCAN peut fonctionner, mais il souffrira du temps d'exécution.

• Du coup, connaître des algorithmes comme DBSCAN++ devient vraiment essentiel.

Bien sûr, je sais que beaucoup d'entre vous n'ont pas forcément une compréhension claire de DBSCAN lui-même.

J'ai donc aussi fourni une présentation détaillée de DBSCAN, qui sert de base naturelle pour comprendre DBSCAN++.

Autre point : un problème avec DBSCAN++, c'est qu'il n'est pas intégré dans Sklearn.

Mais pas de panique.

Pour cet article, j'ai écrit une implémentation entièrement vectorisée de DBSCAN++, qui est liée dans l'article et que tu peux utiliser dans tes projets.

Lis le deep dive ici : DBSCAN++ : l'alternative plus rapide et scalable au clustering DBSCAN.

Je suis convaincu qu'apprendre DBSCAN++ sera extrêmement précieux pour tes compétences et tes projets futurs :)

Dans la Partie 1, on a couvert 5 techniques puissantes : la régression de Huber, le kNN pondéré par la distance, la mise à jour dynamique de k, la discrétisation de features, et le label smoothing.

Booste tes modèles ML sans changer d'algorithme (Partie 1)

Régression de Huber, kNN dynamique, discrétisation de features, label smoothing : 5 techniques ML concrètes avec code pour améliorer tes modèles sans les complexifier.

Dans cette Partie 2, on plonge dans les 6 techniques restantes. Des sujets encore plus avancés, moins connus, et qui peuvent faire une vraie différence sur tes modèles en production.

C'est parti.

Technique #6 : Data Shuffling

Motivation

Les modèles de deep learning peuvent échouer à converger pour de nombreuses raisons.

Certaines causes sont évidentes et faciles à corriger : un learning rate trop élevé ou trop faible, l'absence de normalisation des données, l'absence de batch normalization, etc.

Le vrai problème, c'est quand la cause n'est pas évidente. Dans ce cas, le debugging peut prendre un temps considérable si tu n'es pas au courant de certains pièges.

Prenons un réseau de neurones de classification entraîné avec le mini-batch gradient descent :

On entraîne ici deux réseaux de neurones distincts :

• Version 1 : le dataset est ordonné par labels.

• Version 2 : le dataset est correctement mélangé.

Bien sûr, avant l'entraînement, on s'assure que les deux réseaux ont les mêmes poids initiaux, le même learning rate et les mêmes paramètres.

Le graphique ci-dessous illustre les performances des deux modèles epoch par epoch. À gauche, le modèle entraîné sur les données ordonnées par label. À droite, le modèle entraîné sur les données mélangées.

Le constat est sans appel : le modèle recevant les données ordonnées par label échoue complètement à converger, tandis que l'autre converge sans problème.

Pourquoi mélanger les données ?

Si on y réfléchit, les deux modèles ont reçu exactement les mêmes données, non ?

Pourtant, l'ordre dans lequel ces données leur ont été présentées a totalement déterminé leurs performances.

Je me souviens très bien d'avoir rencontré ce problème. Je savais que mes données étaient ordonnées par labels. Mais l'idée que cet ordre puisse influencer les performances du modèle ne m'avait jamais traversé l'esprit, puisque les données restent les mêmes quel que soit l'ordre.

J'ai compris plus tard que ce raisonnement n'est valable que lorsque le modèle voit toutes les données d'un coup et met à jour ses poids en une seule fois, c'est-à-dire en batch gradient descent :

Mais en mini-batch gradient descent, les poids sont mis à jour après chaque mini-batch.

Ainsi, la prédiction et la mise à jour des poids sur un mini-batch donné sont influencées par les mini-batchs précédents.

Dans le contexte de données ordonnées par label, où les exemples d'une même classe sont regroupés ensemble, le mini-batch gradient descent va pousser le modèle à apprendre des patterns spécifiques à la classe vue en majorité en début d'entraînement.

À l'inverse, des données aléatoirement mélangées garantissent que chaque mini-batch contient une représentation équilibrée des classes. Le modèle apprend ainsi un ensemble de features plus complet tout au long de l'entraînement.

La bonne nouvelle : si tu utilises le DataLoader de PyTorch, tu es protégé. Il implémente déjà le shuffling par défaut. Mais si tu as une implémentation personnalisée, vérifie que tu ne commets pas cette erreur.

Avant de passer au point suivant, retiens ceci : les réseaux de neurones sont capables d'apprendre des patterns totalement inexistants dans tes données. Ne leur en donne jamais l'occasion.

Technique #7 : Régression Zero-Inflated

Motivation

La variable cible d'un dataset de régression classique suit généralement une distribution relativement équilibrée.

Mais parfois, la variable cible contient un grand nombre de zéros. On appelle ces datasets des datasets zero-inflated.

Ils posent des problèmes lors de la modélisation en régression, car un modèle de régression ne peut pas toujours prédire exactement "zéro" quand il le devrait.

Prenons la régression linéaire simple. La droite de régression ne produira exactement "zéro" qu'une seule fois (si sa pente est non nulle).

Ce problème persiste :

• Dans les dimensions supérieures.

• Dans les modèles complexes comme les réseaux de neurones pour la régression.

Une excellente façon de résoudre ce problème consiste à combiner un modèle de classification et un modèle de régression. Voici comment :

• Marque toutes les cibles non nulles comme "1" et les autres comme "0".

• Entraîne un classifier binaire sur ce dataset.

• Entraîne ensuite un modèle de régression uniquement sur les points de données avec une cible non nulle.

Lors de la prédiction :

• Si la sortie du classifier est 0, la prédiction finale est aussi zéro.

• Si la sortie du classifier est 1, on utilise le modèle de régression pour prédire la valeur finale.

Expérience

Pour cette expérience, considère le dataset fictif suivant :

Le code pour générer ce dataset est un peu long, mais il ne contient que quatre étapes simples :

• Définir un tableau NumPy 2D avec des valeurs dans la 1ère colonne de [0, 100] et la 2ème colonne remplie de zéros.

• Définir un deuxième tableau NumPy 2D avec des valeurs dans la 1ère colonne de [300, 400] et la 2ème colonne remplie de zéros.

• Définir un troisième tableau NumPy 2D avec des valeurs dans la 1ère colonne de [100, 300] et la 2ème colonne linéairement dépendante de la 1ère colonne, avec du bruit aléatoire.

• Concaténer ces trois tableaux pour obtenir le dataset final, qu'on appellera data.

En entraînant un modèle de régression linéaire sur ce dataset, on obtient le fit suivant :

Il est clair que la régression linéaire sous-fitte largement les données.

Pour construire le modèle classification + régression, on peut utiliser la librairie sklego, qui propose des blocs supplémentaires pour les pipelines scikit-learn. Elle fournit notamment la classe ZeroInflatedRegressor, qui permet de définir un pipeline sklearn avec un DecisionTreeClassifier suivi d'un modèle LinearRegression.

On l'installe comme suit :

On entraîne ensuite le modèle ZeroInflatedRegressor :

En visualisant le fit, on obtient :

L'efficacité de la régression zero-inflated par rapport à la régression linéaire classique est évidente :

• La régression linéaire seule sous-fittait les données.

• La régression linéaire combinée à un classifier performe comme attendu.

"Les boucles for et les list comprehensions fonctionnent de la même manière et font la même chose."

C'est une affirmation qu'on retrouve dans quasi tous les cours, vidéos et blogs d'introduction à Python (ou une variante de cette affirmation… tu vois l'idée).

Mais ce n'est pas tout à fait vrai.

Bien sûr, en termes d'objectif, elles font exactement la même chose, et je ne dis pas le contraire.

Mais ce que la plupart des développeurs Python ignorent, c'est qu'il existe une différence assez subtile dans la façon dont une list comprehension et une boucle for fonctionnent en interne au niveau du scope. Et c'est quelque chose que tout développeur Python devrait connaître.

Aujourd'hui, je veux partager ça avec toi.

C'est parti !

Prenons ce simple code avec une boucle for :

Après l'exécution de cette boucle for, si on essaie d'accéder à la variable de boucle (loop_var), on constate que la variable est toujours accessible, comme illustré ci-dessous :

Jusque-là, tout va bien.

Maintenant, faisons la même chose avec une list comprehension. Le code suivant est l'équivalent en list comprehension de la boucle for ci-dessus :

Après l'exécution de cette list comprehension, si on essaie d'accéder à la variable de boucle (loop_var), on constate que la variable n'est PAS accessible :

Étrange, non ?

Pourquoi la variable de boucle est-elle accessible avec une boucle for, mais pas avec une list comprehension ?

Cela nous amène à une différence essentielle dans le fonctionnement fondamental de la boucle for et de la list comprehension. Et c'est un point que la plupart des tutoriels Python n'abordent pas.

Quand on utilise une boucle for, Python laisse "fuiter" la variable de boucle dans le scope englobant. Autrement dit, on peut toujours accéder à la variable de boucle une fois la boucle terminée.

Mais une list comprehension ne fonctionne pas de cette manière. La variable de boucle reste toujours locale à la list comprehension et ne fuite jamais à l'extérieur.

De plus, si on utilise une variable préexistante comme variable de boucle, la boucle for mettra à jour sa valeur, tandis que la list comprehension la laissera inchangée.

On peut le vérifier sur l'image ci-dessous :

La valeur de la variable existante (loop_var) :

• est mise à jour quand elle est utilisée dans une boucle for.

• reste inchangée quand elle est utilisée dans une list comprehension.

La list comprehension ne met pas à jour la valeur parce que, comme on l'a vu plus haut, elle crée une copie locale de la variable de boucle.

Cette discussion est étroitement liée au concept de "scope" en Python, qui peut être de quatre types et constitue un sujet fondamental en Python.

👉 À toi de jouer : quels sont les autres concepts techniques de Python que la plupart des développeurs interprètent mal ?

Matplotlib a toujours été ma librairie de référence pour la visualisation de données.

Mais il y a un truc qui me dérange quand je l'utilise dans Jupyter Notebook : les graphiques deviennent ternes et flous dès qu'on les agrandit ou qu'on zoome dessus.

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

Pourquoi ?

Parce que par défaut, Matplotlib rend ses graphiques sous forme d'image. Du coup, le moindre agrandissement ou zoom dégrade fortement leur qualité.

Si tu utilises Matplotlib régulièrement dans Jupyter Notebook, tu as forcément déjà remarqué ça toi aussi.

Pourtant, il existe un hack plutôt sympa pour améliorer leur qualité de façon spectaculaire.

Au lieu du rendu image par défaut, commence à générer tes graphiques en SVG (scalable vector graphic), autrement dit en image vectorielle.

Comme son nom l'indique, ce format peut être mis à l'échelle sans aucune perte de qualité, ce qui saute aux yeux sur l'image ci-dessous :

Comme le montre l'image ci-dessus, le graphique rendu en SVG surclasse clairement le graphique par défaut. Il reste bien plus net, même en zoomant.

Le code suivant te permet de basculer le format de rendu en SVG.

from matplotlib_inline.backend_inline import set_matplotlib_formats
set_matplotlib_formats('svg')

Tu peux aussi utiliser celui-ci :

%config InlineBackend.figure_format = 'svg'

Si la différence ne te paraît pas évidente sur l'image ci-dessus, je te conseille vraiment de l'essayer pour la constater par toi-même.

Télécharge ce Jupyter Notebook pour tester : Notebook Matplotlib-SVG.

👉 À toi de jouer : quels autres hacks Matplotlib sympas connais-tu ?

Sklearn est LA librairie de référence pour toutes sortes de tâches de machine learning (ML) traditionnel.

Mais les choses deviennent vite préoccupantes dès qu'on veut déployer N'IMPORTE QUEL modèle basé sur sklearn.

Pourquoi ?

C'est ce qu'on va comprendre aujourd'hui.

Les modèles sklearn reposent essentiellement sur NumPy, qui s'exécute TOUJOURS sur un seul cœur de CPU.

NumPy n'utilise qu'un seul cœur

Ça laisse une marge de progression énorme, car il n'y a aucune parallélisation. Et ça devient logiquement un vrai problème pour les équipes data qui voudraient confier leurs systèmes de production à sklearn.

Autre limitation majeure : les modèles scikit-learn ne peuvent pas tourner sur GPU.

Les modèles Sklearn tournent sur CPU mais pas sur GPU

Les GPU sont importants parce que beaucoup de systèmes déployés exigent des prédictions ultra-rapides.

Pourtant, reposant entièrement sur NumPy (qui ne tourne que sur CPU), les modèles sklearn ne peuvent pas s'exécuter sur GPU.

Malgré tout, il existe une façon d'activer le support GPU sur les modèles sklearn et d'accélérer massivement l'inférence.

L'idée centrale : compiler un modèle de ML traditionnel déjà entraîné (un random forest, par exemple) en calculs tensoriels.

Compile le modèle sklearn en modèle tensoriel

Reposant désormais sur des tenseurs, le modèle peut profiter sans friction des fonctionnalités offertes par les systèmes d'inférence basés sur le deep learning, comme :

• La facilité de déploiement.

• Le chargement sur des accélérateurs matériels.

• L'accélération de l'inférence grâce au support GPU.

L'efficacité de cette technique de compilation saute aux yeux sur l'image ci-dessous :

Modèle Random Forest Sklearn standard vs. modèle RF tensoriel sur CPU vs. modèle RF tensoriel sur GPU

• Ici, on a entraîné un modèle random forest.

• Le modèle compilé tourne :

  • Plus de deux fois plus vite sur CPU.

  • Environ 40 fois plus vite sur GPU, ce qui est énorme.

• Tous les modèles affichent la même accuracy, signe qu'aucune information n'est perdue pendant la compilation.

Maintenant, si tu te demandes :

• Quelles sont ces stratégies de compilation ?

• Comment fonctionnent-elles ?

• Comment les implémenter ?

• Comment représenter un random forest sous forme de calculs matriciels, alors que ça n'a rien d'intuitif ?

...c'est exactement ce qu'on a exploré dans un récent deep dive machine learning :

Accélère tes modèles sklearn jusqu'à 40x sans changer ton code

Découvre comment compiler tes modèles sklearn en opérations tensorielles PyTorch et les faire tourner sur GPU grâce à Hummingbird — sans réécrire ton code.

Le temps d'inférence est une métrique business critique dans le déploiement de modèles de ML.

Comme les entreprises travaillent surtout sur des données tabulaires, les techniques de ML classique comme les modèles linéaires et les méthodes d'ensemble à base d'arbres sont essentielles pour les modéliser.

Pourtant, dans le paysage actuel, on se retrouve souvent forcé d'entraîner et de déployer des modèles de deep learning, juste parce qu'ils offrent des opérations matricielles optimisées via des tenseurs qu'on peut charger sur GPU.

Apprendre ces techniques de compilation et les utiliser m'a énormément aidé à déployer des modèles de ML classique avec support GPU.

Donc, les maîtriser te sera extrêmement précieux si tu envisages d'en faire autant.

👉 Si ça t'intéresse, c'est à lire ici : Les modèles Sklearn ne sont pas faits pour le déploiement ! Booste-les avec les calculs tensoriels.

Beaucoup d'ingénieurs ML et de data scientists passent trop vite à un nouveau type de modèle dès qu'ils n'obtiennent pas les résultats escomptés avec le modèle en cours.

On n'exploite pas toujours toutes les possibilités des modèles existants, et on se tourne vers des architectures plus complexes alors que quelques ajustements ciblés sur un modèle simple suffiraient à obtenir des résultats très satisfaisants.

Au fil de la construction de nombreux modèles ML, j'ai utilisé différentes techniques qui permettent de révéler des nuances et des optimisations capables d'améliorer significativement les performances, sans pour autant augmenter la complexité du modèle.

Dans ce deep dive, je vais te partager 5 de ces techniques puissantes, issues d'une liste de 11 au total, que tu pourras utiliser immédiatement pour tirer le maximum de tes modèles.

Pour chacune, je t'explique la motivation derrière son usage, et je te fournis le code correspondant.

C'est parti.

Technique #1 : Rendre la régression linéaire robuste aux outliers

Le problème des modèles de régression

Le problème majeur de la plupart des modèles de régression, c'est leur sensibilité aux outliers.

Prenons la régression linéaire, par exemple.

Même quelques outliers peuvent impacter significativement ses performances, comme illustré ci-dessous :

La cause de ce problème n'est pas difficile à identifier.

La fonction de loss MSE (Mean Squared Error) croît rapidement avec le terme résiduel (vrai - prédit) :

Ainsi, même quelques points de données avec un résidu élevé peuvent fortement influencer l'estimation des paramètres.

La régression de Huber

La Huber loss (utilisée par la régression de Huber) répond précisément à ce problème.

En résumé, elle cherche à réduire la contribution des points de données ayant un résidu élevé.

Comment ?

Une façon simple, intuitive et évidente d'y parvenir consiste à appliquer un seuil (δ) sur le terme résiduel :

• Si le résidu est inférieur au seuil, on utilise la MSE (aucun changement).

• Sinon, on utilise une fonction de loss dont la sortie est plus petite que la MSE, une fonction linéaire, par exemple.

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

• Pour les résidus inférieurs au seuil (δ), on utilise la MSE.

• Sinon, on applique une fonction de loss linéaire, dont la sortie est plus faible que celle de la MSE.

Mathématiquement, la Huber loss est définie comme suit :

Expérience

Prenons le dataset 2D fictif présenté plus haut.

Pour l'instant, ce dataset ne contient aucun outlier. Ajoutons-en quelques-uns :

On obtient le dataset suivant :

Entraînons un modèle de régression linéaire sur ce dataset :

On visualise ensuite le fit de régression en traçant les valeurs y_pred :

Ce qui donne le graphique suivant :

Il est clair que la régression linéaire est affectée par les outliers.

Regardons maintenant la régression de Huber, qui, comme on l'a vu, applique une pénalité linéaire à tous les résidus supérieurs au seuil δ.

Pour entraîner un modèle de régression de Huber, on reprend les mêmes étapes, mais cette fois avec la classe HuberRegressor de sklearn.

On obtient le fit de régression suivant :

La robustesse de la régression de Huber est évidente.

Comment choisir δ ?

Le trial and error est une option, mais construire un graphique des résidus est bien plus utile. Voici comment procéder :

• Étape 1 : Entraîne un modèle de régression linéaire classique sur le dataset contenant les outliers.

• Étape 2 : Calcule la valeur absolue des résidus (= vrai - prédit) sur les données d'entraînement.

• Étape 3 : Trace le tableau des résidus absolus pour chaque point de données.

Ce qui donne le graphique suivant :

D'après ce graphique, δ = 4 semble être une bonne valeur seuil.

L'avantage de cette approche, c'est qu'elle fonctionne pour un dataset de n'importe quelle dimensionnalité. On ne fait que tracer les valeurs (vrai - prédit), qui sont toujours en 1D.

L'idée centrale reste la même : réduire la contribution des outliers dans le fit de régression.

Techniques #2 et #3 : Booster les modèles kNN

Le problème des kNNs

Ce qui me rend toujours un peu prudent avec les kNNs, c'est leur forte sensibilité au paramètre k.

Pour mieux comprendre, considère ce dataset 2D fictif ci-dessous. Le point rouge est une instance de test pour laquelle on souhaite générer une prédiction avec un kNN.

Supposons k = 7.

La prédiction pour le point rouge se fait en deux étapes :

1. On identifie les 7 voisins les plus proches du point rouge.

2. On lui attribue la classe la plus représentée parmi ces 7 voisins.

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

Le problème, c'est que l'étape 2 repose entièrement sur la notion de contribution de classe : la classe qui contribue le plus parmi les k voisins les plus proches est celle qui est attribuée au point de données.

Mais cette notion échoue parfois, notamment quand une classe est peu représentée.

Par exemple, avec k = 7, le point rouge ne pourra JAMAIS être attribué à la classe jaune, aussi proche qu'il soit de ce cluster :

Si ajuster visuellement k est facile sur cet exemple, la démarche devient inapplicable sur des datasets haute dimensionnalité.

Il existe deux façons d'y remédier.

Solution #1 : kNN pondéré par la distance

Le kNN pondéré par la distance est une alternative bien plus robuste au kNN classique.

Comme son nom l'indique, à l'étape 2, on tient compte de la distance par rapport au voisin le plus proche. Résultat : plus un voisin est proche, plus il a d'impact sur la prédiction finale.

Prenons ce dataset 2D fictif :

Avec une instance de test fictive :

En entraînant un kNN classifier avec la stratégie uniforme (basée sur le comptage), le modèle prédit la Classe 0 (le rouge) pour la nouvelle instance :

En revanche, le kNN pondéré par la distance se révèle plus robuste :

Cette fois, on obtient la Classe 1 (le bleu), ce qui est correct.

D'après mon expérience, un kNN pondéré par la distance fonctionne généralement bien mieux qu'un kNN classique. C'est d'ailleurs intuitif.

Pourtant, cette option passe souvent inaperçue : par défaut, l'implémentation kNN de sklearn utilise une pondération uniforme.

Solution #2 : Mise à jour dynamique du paramètre k

Rappelle-toi le schéma de départ :

On pourrait arguer qu'il faut éviter de fixer k à une valeur supérieure au nombre minimal d'exemples appartenant à une classe dans le dataset.

Je suis d'accord dans une certaine mesure, mais voici le revers de la médaille.

Fixer une valeur de k trop faible peut s'avérer très problématique sur des datasets fortement déséquilibrés.

Pour te donner une idée concrète : j'ai personnellement utilisé des kNNs sur des datasets où une classe ne comptait qu'une ou deux instances dans le training set.

Et j'ai constaté qu'un k trop faible (1 ou 2) produisait des performances sous-optimales, car le modèle n'évaluait pas les patterns de voisinage de façon assez globale, contrairement à ce qu'il faisait avec un k plus élevé.

En d'autres termes, un k plus grand donne généralement des prédictions plus éclairées qu'un k faible.

Mais on vient de voir que si k est trop grand, la classe majoritaire peut dominer la classification :

Pour résoudre ce problème, j'ai trouvé que la mise à jour dynamique de k était bien plus efficace.

Voici les trois étapes de cette approche, appliquées à chaque point de données de test :

• Étape 1 : Commence avec une valeur standard de k et identifie les k voisins les plus proches.

• Étape 2 : Mets à jour la valeur de k comme suit :

  • Pour toutes les classes uniques présentes parmi les k voisins les plus proches, identifie le nombre total d'instances d'entraînement qu'elles comportent.

• Mets à jour k ainsi :
  k′ = min(k, nombre_minimal_d'instances_parmi_les_classes_présentes)

Exemple avec les images ci-dessus : les deux classes présentes comptent 40 et 3 instances → k′ = min(7, 3) = 3

• Étape 3 : Effectue le vote majoritaire uniquement sur les k′ premiers voisins.

Cette approche est intuitivement solide :

• Si une classe minoritaire apparaît parmi les k voisins les plus proches, on réduit k pour éviter que la classe majoritaire ne domine.

• Si une classe minoritaire n'apparaît PAS parmi les k voisins les plus proches, k ne sera vraisemblablement pas mis à jour, et la classification reste globale.

L'inconvénient, c'est qu'il n'existe aucune implémentation open source de cette approche.

D'après mon expérience, la plupart des projets ML n'ont pas de système dédié à la gestion et au suivi des expériences.

Comme le nom l'indique, ce type de système permet de tracer :

• La configuration du modèle, critique pour la reproductibilité.

• Les performances du modèle, indispensables pour comparer différentes approches.

...et ce, à travers toutes les expériences.

Pourtant, la plupart des projets ML s'appuient sur des systèmes manuels qui ne capturent que des détails limités :

• La performance finale (sans les courbes de convergence époque par époque)

• Les hyperparamètres, etc.

Or, d'une expérience à l'autre, énormément de choses peuvent changer :

• Les hyperparamètres

• Les données

• Le type de modèle

Tout tracer avec précision peut vite devenir fastidieux et chronophage.

Et ce n'est pas tout. Imagine que ton pipeline ML comporte trois étapes :

Si tu n'as modifié que l'entraînement du modèle (étape 3), disons que tu as changé un hyperparamètre, est-ce qu'il est utile de relancer les deux premières étapes ?

Non, clairement pas.

Pourtant, la plupart des pipelines ML relancent tout depuis le début, gaspillant du temps et des ressources de calcul.

On peut bien sûr ajouter des flags manuels pour éviter ça :

Mais une solution manuelle reste toujours sujette aux erreurs.

Pour éviter cette friction inutile, un système de suivi efficace doit être capable de :

• Détecter tous les changements apportés au pipeline ML.

• Identifier les étapes qu'il peut éviter de relancer.

• N'exécuter que les étapes strictement nécessaires pour produire les résultats finaux.

La motivation est évidente. Pourtant, c'est une compétence que beaucoup ignorent, et on continue à voir des systèmes manuels inefficaces partout : Sheets, Docs, et compagnie.