Machine Learning
D’un tableau sale à un modèle que vous pouvez défendre en réunion.
La plupart des cours de machine learning commencent par l’algorithme. C’est prendre le problème par le mauvais bout. Dans la vraie vie, vous passerez peut-être un dixième de votre temps à choisir un estimateur, et tout le reste à déterminer ce qu’une ligne représente réellement, pourquoi quatre pour cent de vos dates tombent dans le futur, et si la colonne qui prédit tout ne fuite pas tout simplement la réponse que vous cherchez à prédire. Ce parcours est construit autour de cette réalité. Vous démarrez avec Python et pandas — non comme de la programmation, mais comme un instrument pour interroger la donnée — et vous apprenez à regarder avant de modéliser, parce que le graphique que vous n’avez pas tracé est le bug que vous mettrez en production. Vous construisez ensuite : les features, qui constituent le modèle bien plus que l’estimateur, puis la régression et la classification avec ces baselines sans gloire qui battent discrètement les réseaux de neurones sur données tabulaires, année après année. La dernière phase est la plus décisive et la moins enseignée : une validation qui ne vous ment pas, et des métriques qui parlent à celui qui paie le modèle. Quatre-vingt-dix-huit pour cent d’accuracy sur un taux de fraude de deux pour cent, c’est un modèle qui a appris à dire non. Vous finirez capable de mener un jeu de données métier sale jusqu’à un modèle défendable — et, tout aussi important, capable de dire à voix haute quand il n’y a pas de modèle à en tirer.
Ce que vous allez apprendre
Prérequis
- Bases de programmation dans un langage quelconque
- Algèbre de niveau lycée ; lire une formule sans paniquer
- Accepter de passer plus de temps sur la donnée que sur les modèles
Débouchés
- Ingénieur machine learning
- Data scientist
- Applied scientist
- Analyste quantitatif / risque
Phases
Phase 1 — La donnée d’abord
Apprendre à interroger un jeu de données jusqu’aux aveux. Aucune modélisation avant de savoir décrire chaque colonne.
Durée estimée · 8-10 semainesPython et pandas comme instrument
Il ne s’agit pas d’apprendre le génie logiciel, mais de savoir poser des questions à un tableau, vite. Le danger avec pandas, c’est qu’il proteste rarement : un merge à la mauvaise cardinalité triple vos lignes en silence, une affectation chaînée ne fait rien du tout, et votre modèle s’entraîne joyeusement sur du n’importe quoi. Vous apprendrez où il vous ment et comment le prendre en flagrant délit : vérifier vos comptages de lignes, contrôler vos clés de jointure, et ne jamais croire une moyenne dont vous n’avez pas vu l’histogramme.
Sujets couverts
Ce que vous allez construire
- Charger un jeu de plus d’un million de lignes et produire un dictionnaire de données d’une page : chaque colonne, son type, son taux de manquants, sa plage plausible
- Reprendre un notebook écrit le mois dernier, redémarrer le kernel et l’exécuter de haut en bas — réparer tout ce qui casse
- Écrire cinq assertions qui auraient attrapé une duplication de jointure silencieuse, et prouver qu’elles se déclenchent sur un merge cassé
Regarder la donnée avant de la modéliser
L’analyse exploratoire n’est pas une phase décorative qu’on expédie pour atteindre la partie amusante : c’est là qu’on trouve les bugs qui mettraient sinon trois semaines à remonter depuis la production. Tracez chaque distribution. Demandez-vous pourquoi le taux de la cible a bondi tel mois. Découvrez qu’une colonne n’est renseignée que depuis une migration de système, donc qu’elle n’existe que sur la moitié récente de vos données et ne vaudra rien le jour du déploiement. Tout praticien expérimenté a une cicatrice pour avoir sauté cette étape, et aucun ne la saute deux fois.
Sujets couverts
Ce que vous allez construire
- Produire un rapport d’EDA sur un jeu réel qui se termine par trois constats concrets changeant la façon de modéliser
- Trouver au moins une colonne dont la disponibilité change dans le temps, et documenter la date de son apparition
- Tracer le taux de la cible par mois sur deux ans et écrire un paragraphe expliquant chaque rupture de la courbe
Phase 2 — Les features, puis les modèles
Construire la représentation, puis laisser une baseline ennuyeuse et solide faire le travail.
Durée estimée · 8-12 semainesLes features sont le modèle
Changer d’estimateur vous rapporte deux points. Encoder une date en « nombre de jours depuis la commande précédente du client » plutôt qu’en timestamp brut vous en rapporte vingt. Le feature engineering est le point d’entrée de la connaissance métier dans le système, et c’est pourquoi l’analyste qui comprend le business bat l’ingénieur qui ne comprend que la librairie. C’est aussi là que naît la fuite : dès l’instant où vous calculez une feature avec une information qui n’existait pas au moment de la prédiction, votre score de validation devient une fiction.
Sujets couverts
Ce que vous allez construire
- Battre de 10 points une baseline sur colonnes brutes, à estimateur constant, uniquement par feature engineering
- Écrire un contrôle point-in-time : pour chaque feature, indiquer l’instant où elle devient connaissable, et supprimer toutes celles qui échouent
- Prendre une feature en target encoding et démontrer la fuite qu’elle provoque quand elle est ajustée hors du fold
Régression, classification, et la baseline que vous avez sautée
Commencez par prédire la moyenne, ou la classe majoritaire. Si votre modèle sophistiqué ne bat pas ça nettement, vous n’avez pas un modèle, vous avez un graphique. Apprenez ensuite correctement la régression linéaire et logistique — non parce qu’elles gagnent toujours, mais parce qu’elles sont assez interprétables pour vous dire quand votre donnée est fausse. Passez ensuite aux arbres boostés par gradient, qui restent le défaut honnête sur données tabulaires. Quiconque vous vend un réseau de neurones pour un tableur vous vend un réseau de neurones.
Sujets couverts
Ce que vous allez construire
- Livrer un tableau comparant baseline naïve, régression logistique et gradient boosting sur les mêmes folds, features et métrique
- Reprendre votre meilleur modèle boosté et reproduire 90 % de son score avec une régression logistique et de meilleures features
- Lancer une recherche d’hyperparamètres et rapporter honnêtement combien de points elle a réellement gagnés sur les valeurs par défaut
Phase 3 — Validation, métriques et vérité
S’assurer que le chiffre que vous annoncez est celui que le métier obtiendra.
Durée estimée · 8-12 semainesUne validation qui ne ment pas
Un split train/test aléatoire sur des données qui ont une dimension temporelle est le bug silencieux le plus répandu du métier, et il est commis chaque jour par des gens très bien classés sur Kaggle. Si vous prédisez demain, vous validez sur demain. Si le même client apparaît dans les deux folds, votre modèle a mémorisé le client, pas le motif. La fuite ne s’annonce pas par une erreur : elle s’annonce par un score suspicieusement bon, c’est-à-dire précisément au moment où personne n’a envie d’y regarder de plus près.
Sujets couverts
Ce que vous allez construire
- Prendre un modèle validé par split aléatoire, le revalider par split temporel, et rapporter le score réellement perdu
- Construire volontairement un pipeline qui fuit et score 0,99, puis le démonter et expliquer chaque fuite par écrit
- Mettre en place une validation croisée groupée sur un jeu à entités répétées et montrer l’écart avec un k-fold naïf
Métriques, seuils et le coût de l’erreur
L’accuracy est la métrique de ceux qui n’ont pas réfléchi au problème. Sur un taux d’événement de deux pour cent, prédire toujours « non » donne quatre-vingt-dix-huit et n’aide personne. La vraie question est ce que coûte un faux positif face à un faux négatif, et c’est une conversation métier, pas mathématique. Vous apprendrez à choisir une métrique qui se traduit en argent ou en préjudice, à fixer un seuil délibérément au lieu d’accepter 0,5 par défaut, et à vérifier la calibration — car si vous annoncez soixante-dix pour cent, il vaut mieux que soixante-dix pour cent de ces cas se produisent.
Sujets couverts
Ce que vous allez construire
- Écrire une matrice de coûts avec un vrai décideur, puis choisir le seuil opérationnel qu’elle implique et le justifier en une page
- Tracer une courbe de fiabilité pour votre classifieur et corriger sa calibration ; montrer l’avant et l’après
- Simuler trois mois de dérive sur une période retenue et indiquer la date à laquelle vous réentraîneriez
Questions
Faut-il de lourdes mathématiques pour faire du machine learning en professionnel ?
Moins que ce que prétend internet, plus que ce qu’admettent les bootcamps. Vous ne redémontrerez rien au travail, mais vous serez perdu sans l’intuition de trois choses : ce que fait un gradient, pourquoi la régularisation échange du biais contre de la variance, et ce qu’une probabilité affirme réellement. Cela représente quelques semaines de travail sérieux, pas un diplôme. Les mathématiques qui bloquent vraiment les gens, c’est la pensée statistique : comprendre qu’un écart de deux points sur huit cents lignes est du bruit. Si vous tenez fermement cette idée, vous dépasserez beaucoup de gens capables de réciter des preuves et qui valident quand même sur un split aléatoire.
Pourquoi ce parcours parle-t-il si peu de réseaux de neurones ?
Parce que sur les données tabulaires, qui constituent l’écrasante majorité des problèmes métier, les arbres boostés restent la bonne réponse et s’entraînent en quelques secondes sur un ordinateur portable. Le deep learning gagne sur les images, l’audio et le langage — sur la donnée non structurée où le modèle doit apprendre sa propre représentation. Enseigner les réseaux de neurones en premier produit des ingénieurs qui sortent une architecture profonde pour une table de churn, brûlent trois semaines, et perdent contre un modèle qui tient en un appel de fonction. Une fois que vous savez faire le travail décrit ici, le deep learning est la suite naturelle, et vous y arriverez avec ce qui manque à beaucoup de ses praticiens : le réflexe de vérifier si la donnée dit la vérité.
J’ai fait plusieurs compétitions Kaggle. Ce parcours est-il redondant pour moi ?
Probablement pas, et voici la raison inconfortable. Une compétition vous remet un jeu propre, une métrique fixée et un leaderboard qui garantit l’absence de fuite. Aucun de ces cadeaux n’existe en entreprise. Votre vrai travail commence avant que la donnée n’existe : décider quoi prédire, si prédire est seulement la bonne intervention, quelles lignes sont légitimes, et ce que coûte le modèle quand il se trompe. Les compétences de compétition se transfèrent bien à la phase deux de ce parcours, et quasiment pas aux phases un et trois — celles qui décident si votre modèle atteint la production ou meurt dans un notebook. Survolez ce que vous savez ; ne sautez pas ce qui semble évident.
Parcours liés
Envie de suivre ce parcours avec un coach et une cohorte ?
Découvrir la 212AY Academy →