Création de modèles : définition de problèmes, sélection d'algorithmes et répartition formation/test

Gains :

• Capacité à définir le type de problème (classification, régression, clustering) et les critères de réussite en fonction du coût réel du travail
• Capacité à diviser les données honnêtement (sans toucher à l'ensemble de test ; chronologiquement dans la série chronologique) et à établir une base d'évaluation sans fuite
• Capacité à choisir un modèle interprétable en commençant par une base de référence simple et en ajoutant de la complexité uniquement lorsque cela le mérite.

Jusqu’à présent, nous avons collecté des données, les avons nettoyées, explorées et produit des fonctionnalités. Passons maintenant au vrai travail : construire un modèle. Un modèle est une structure mathématique qui apprend un modèle à partir de données et produit des prédictions pour de nouvelles situations. Mais la partie la plus critique de la construction d’un modèle n’est pas le code lui-même, mais les deux décisions qui le précèdent : définir le bon problème et diviser correctement les données. L'IA est un puissant conseiller en matière de sélection d'algorithmes, d'écriture de code et de réglage des paramètres ; mais c'est à chacun de décider quoi prédire et ce que signifie le succès. Un problème mal défini ne fonctionnera pas même avec un modèle parfaitement écrit.

Définition du problème d'abord : que prédit-on

Chaque travail de modélisation commence par une question, et cette question détermine le type de modèle. Classification — le résultat est une catégorie : « Ce client partira-t-il ou restera-t-il ? », « Cette transaction est-elle fausse ? Régression (en anglais régression - le résultat est un nombre) : « Combien vaut cette maison ? », « Combien de commandes arriveront le mois prochain ? ». Clustering (diviser les données non étiquetées en groupes naturels) : "En combien de segments naturels mes clients sont-ils divisés ?".

La deuxième partie de l'énoncé du problème est le critère de réussite : qu'est-ce que cela signifie pour ce modèle d'être « bon » ? Dans un modèle de fraude, manquer un fraudeur coûte beaucoup plus cher que bloquer accidentellement un client honnête ; Par conséquent, ce n’est pas « l’exactitude générale » qui prime, mais « le taux de détection des fraudeurs ». Si vous ne définissez pas ce critère dès le début, en collaboration avec le propriétaire de l'entreprise, vous vous retrouverez avec un modèle « très précis » qui ne fonctionne pas (nous approfondirons les métriques dans l'unité 7).

Attention : « Précision » peut être trompeuse. Si 10 transactions sur 1 000 sont frauduleuses, un modèle stupide qui dit « aucune n’est frauduleuse » donnera une précision de 99 % mais ne détectera pas un seul fraudeur. Choisissez des critères de réussite en fonction du coût réel du problème.

Répartition entraînement/test : examen honnête du modèle

Tester un modèle avec les données qu'il a apprises revient à poser à l'étudiant les mêmes questions qu'il a étudiées lors de l'examen ; Il obtient des notes élevées mais ne montre pas ce qu'il sait vraiment. Nous divisons donc les données en deux (souvent trois) :

• Ensemble de formation (ensemble de formation en anglais, généralement 70 à 80 %) : le modèle apprend à ce sujet.
• Ensemble de test (ensemble de test, généralement 20 à 30 %) : le modèle ne voit pas cela du tout ; la performance réelle est mesurée ici.
• Ensemble de validation : ensemble intermédiaire utilisé pour le paramétrage du modèle (quel paramètre est le meilleur) ; pour garder l'ensemble de test "propre".

La règle la plus élémentaire : l’ensemble de test n’est jamais touché pendant l’entraînement. Mise à l'échelle, codage, sélection des fonctionnalités : tout est simplement appris à partir de l'ensemble de formation, puis appliqué aux tests (principe de fuite de l'unité 5). L'ensemble de test est la première fois que le modèle voit le monde réel ; Si vous l'allumez trop tôt, vous ne connaîtrez jamais les véritables performances.

Exception de série chronologique : si vos données dépendent du temps (ventes, bourse, demande), la répartition aléatoire n'est pas effectuée. Parce que la division aléatoire amène le modèle à voir l’avenir et à prédire le passé, il s’agit d’une fuite. Divisez plutôt chronologiquement : entraînez-vous avec l’ancienne période, testez avec la nouvelle période.

Sélection d'algorithmes : du simple au complexe

L’erreur la plus courante des débutants est de commencer par le modèle le plus complexe. L’approche correcte est inverse : établissez d’abord une base de référence simple. « toujours deviner la classe majoritaire » dans un classement ; "toujours estimer la moyenne" dans une régression. Ce modèle stupide donne une base de référence ; Si votre modèle actuel ne parvient pas à résoudre ce problème, il y a un problème. Passez ensuite à des modèles simples et interprétables.

modèle

Type de problème

point fort

faiblesse

Base de référence (majoritaire/moyenne)

les deux

Donne une référence

n'apprend pas

Régression logistique

Classement

Simple, interprétable

Relation linéaire uniquement

Régression linéaire

régression

Simple, rapide

hypothèse linéaire

arbre de décision

les deux

interprétable

Mémorisations faciles

forêt aléatoire

les deux

Solide, durable

Moins interprétable

Augmentation du dégradé (XGBoost etc.)

les deux

très fort

Difficile à régler, risque de mémorisation

Règle : choisir le modèle « assez bon » le plus simple. L'interprétabilité est plus précieuse que le pouvoir dans la plupart des contextes commerciaux ; Il est préférable d'expliquer un refus de prêt « parce que votre ratio d'endettement est élevé » plutôt que « parce que la boîte noire l'a dit ».

trois mini-cases

Cas 1 — Définition incorrecte du problème. Une équipe a construit un modèle de classification basé sur « le client est-il satisfait » mais a choisi « l'exactitude » comme critère de réussite. Dans les données, 88 % des clients étaient satisfaits ; Le modèle a obtenu une précision de 88 % en qualifiant tout le monde de "satisfait" et n'a jamais détecté les personnes insatisfaites, même si le véritable objectif était de les trouver. Leçon : choisissez des critères de réussite basés sur un objectif réel.

Cas 2 — Fuite temporelle dans le compartiment. Dans un projet de prévision de la demande, les données ont été réparties de manière aléatoire. Le modèle a donné une précision de 93 %, mais s'est écrasé en production parce qu'en formation, il avait prédit janvier, puis novembre, avec les données de décembre – il avait vu l'avenir. Lorsque nous sommes passés à la division chronologique, la performance réelle est passée à 74 %. Leçon : division chronologique en séries temporelles.

Cas 3 — Complexité inutile. Un analyste a commencé directement avec un réseau neuronal profond, l'a réglé pendant des semaines et a obtenu une précision de 81 %. Ensuite, un collègue a obtenu 80 % avec 20 lignes de régression logistique – beaucoup plus rapide, interprétable et plus facile à maintenir. Leçon : commencez avec une base de référence et un modèle simple, ajoutez de la complexité quand cela le mérite.

Quatre modèles copiables

1) Clarifier la définition du problème :

Votre rôle : consultant en modélisation. Aidez-moi à définir ce travail : « Je veux réduire le taux de désabonnement des clients. » Demandez-moi et clarifiez : (1) s'agit-il d'une classification ou d'une régression, (2) quelle est exactement la variable cible et comment doit-elle être définie, (3) quels devraient être les critères de succès et pourquoi. La décision m’appartient ; vous présentez les questions et les options.

2) Compartiment de formation/test sécurisé :

Divisez mon df en entraînement/test 80 %/20 %. Maintenir la distribution des classes (stratifier).random_state=42. Il ne s'agit PAS d'une SÉRIE CHRONOLOGIQUE (observations indépendantes). Imprimez le ratio de classe de chaque ensemble après la division. Donnez simplement le code de fractionnement à l'ensemble de test sans appliquer aucune transformation.

3) Division chronologique des séries chronologiques :

Les données dépendent du temps (colonne date : order_date). PAS aléatoire, divisez par ordre chronologique : 80 % de formation la plus ancienne, 20 % de tests les plus récents. Imprimez les plages de dates de formation et de test afin que je puisse vérifier que l'avenir n'a pas fuité.

4) Définir une référence :

J'ai un problème de classification (cible : churn 0/1). Établissez d’abord une référence : mesurez la précision de la formation/des tests avec DummyClassifier, qui prédit toujours la classe majoritaire. Entraînez ensuite une simple régression logistique et comparez si elle dépasse la ligne de base. Montrez les métriques des deux côte à côte.

Invite faible/Invite forte

Invite faible :

Construisez le meilleur modèle avec ces données.

« Meilleur » n'est pas défini ; Il n’y a aucun type de problème, aucun objectif, aucun critère de réussite et aucune stratégie de division. L'IA génère un motif aléatoire, éventuellement fuyant.

Invite puissante :

Votre rôle : assistante mannequin. Problème : classification, cible « churn » (0/1), il y a un déséquilibre de classe (~12% de churn). Critère de réussite : Rappeler ceux qui désabonnement sont une priorité. Observation indépendante des données (pas de séries chronologiques). Tâche : (1) répartition stratifiée à 80/20 %, (2) référence de DummyClassifier, (3) régression logistique, toutes les transformations en cours de pipeline et apprises uniquement de la formation. Ne touchez pas l’ensemble de test avant de le diviser.

Ici, le type de problème, le déséquilibre, le critère et la mesure de fuite sont clairs.

Erreurs courantes

• Ne pas choisir les critères de réussite en fonction du véritable objectif. La « précision » des données déséquilibrées est trompeuse ; Si vous voulez capturer la classe minoritaire, le rappel passe au premier plan.
• Toucher l'ensemble de test pendant l'entraînement. Effectuer une mise à l'échelle/un encodage avant le fractionnement présente des fuites et cache les performances réelles.
• Fractionnement aléatoire en séries chronologiques. Le modèle voit l’avenir, s’effondre dans la production ; La division chronologique est essentielle.
• Se lancer dans un modèle complexe sans établir de référence. Sans benchmarks, vous ne pouvez pas savoir si un modèle est vraiment bon ou non.
• Ignorer l’interprétabilité. Dans les décisions commerciales, un modèle simple et explicable a souvent plus de valeur qu’une boîte noire.

Astuce : Avant de commencer à créer un modèle, écrivez une phrase : « Ce modèle prédira _____, son succès sera mesuré par la métrique _____, car le coût réel du travail est de _____. » Si vous ne parvenez pas à remplir cette phrase, vous n'êtes pas encore prêt à écrire du code.

En résumé

La partie la plus critique de la construction d'un modèle n'est pas le code, mais les décisions qui le précèdent : définir le bon problème (classification ou régression, quel est l'objectif, quel est le critère de réussite) et diviser équitablement les données (sans toucher à l'ensemble de test ; chronologique dans la série temporelle). Commencez toujours par une base de référence simple et ajoutez de la complexité uniquement lorsque cela le mérite ; l’interprétabilité est valorisée plutôt que le pouvoir dans la plupart des contextes commerciaux. L’IA est un puissant conseiller en matière de sélection d’algorithmes et de code, mais l’humain décide de ce que vous prédisez et pourquoi.

Tâche de candidature

Définissez un problème de prédiction et complétez la phrase suivante par écrit : « Ce modèle va prédire ___ (classification/régression), la cible est ___, le critère de réussite est ___ car ___. Divisez ensuite les données avec la bonne stratégie (chronologique s'il s'agit d'une série chronologique), établissez une référence et mesurez si un modèle simple rompt cette référence.

liste de contrôle

• [ ] Ai-je clairement défini le type de problème (classification/régression) et la cible ?
• [ ] Ai-je choisi les critères de réussite en fonction du coût réel du travail ?
• [ ] Ai-je laissé l'ensemble de test intact pendant l'entraînement ?
• [ ] S'il s'agit d'une série chronologique, est-ce que je l'ai divisée chronologiquement ?
• [ ] Ai-je établi une base de référence avant de passer au modèle complexe ?