Aller au contenu
English

L'apprentissage automatique est itératif

  • Leçon 14
  • 50 min
  • Module 5 : Essayer d'autres familles de modèles
Leçon 14 sur 27 · Apprentissage automatique : du problème à un modèle fiableL'apprentissage automatique est itératif

Ce que vous saurez faire

Personne ne peut dire d’avance quel modèle fonctionnera le mieux sur les billets de soutien de Larkfield. Apprenez la boucle utilisée en pratique pour le découvrir : changer une chose, la mesurer comme avant et garder ce qui aide. Notez chaque résultat dans un journal d’expériences.

Carnet JupyterFaites cette leçon dans un carnet JupyterColab · Kaggle · GitHub · en anglais

Le carnet (notebook) Jupyter contient toutes les cellules de code, les tâches et les vérifications de cette leçon, avec les consignes. Ses cellules de préparation installent les paquets, téléchargent les données d’exercice et écrivent ticket_model.py. Elles définissent aussi les fonctions utilitaires du journal d’expériences. Le carnet fonctionne donc sans le projet local.

Le carnet est en anglais. Colab et Kaggle ouvrent votre propre copie. Il faut un compte Google ou Kaggle gratuit. Vous êtes bloqué ? Consultez le carnet de solution.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 50 minutes

Ce que vous devez savoir

Ce qu’il vous faut sur votre ordinateur (seulement pour le travail local; le carnet n’en a pas besoin)

  • Le dossier de projet ~/projects/ticket-model, avec son environnement .venv actif dans un terminal. Les carnets des leçons doivent être ouverts dans VS Code ou JupyterLab. Vous les avez créés dans Définir une référence de base : préparer votre projet. Si python -c "import sklearn" échoue, activez de nouveau .venv (source .venv/bin/activate sur macOS et Linux, .venv\Scripts\Activate.ps1 sur Windows).
  • data/train.csv et data/valid.csv, de Définir une référence de base : télécharger les données. Si un fichier manque ou a changé, exécutez python get_data.py --reset.
  • ticket_model.py avec 6 nombres dans NUMBERS, de Prétraiter avec un pipeline : écrire ticket_model.py. S’il manque ou ne fonctionne plus, réécrivez-le à partir de cette section. Ne copiez pas encore le fichier terminé de C05/project : il contient une caractéristique supplémentaire ajoutée au module 6. Vos nombres seraient donc différents.
  • Cette leçon crée un nouveau fichier, experiment_log.csv. Le carnet l’écrit dans son propre dossier ticket-model.

Testé sur macOS avec Python 3.14.6, pandas 3.0.6 et scikit-learn 1.9.1. Les étapes pour Windows et Linux ne sont pas testées. Le carnet a été testé dans Jupyter.

Imaginez une cuisinière qui veut faire le meilleur pain de sa ville. Elle part d’une recette simple et fait cuire un pain. Il est bon, mais un peu sec. Le lendemain, elle ajoute un peu plus d’eau et ne change rien d’autre. Elle goûte le pain et écrit dans son carnet : « plus d’eau : plus moelleux, meilleur, à garder ». Le jour suivant, elle essaie un four plus chaud. La croûte brûle, alors elle écrit : « four plus chaud : moins bon, revenir en arrière ».

Après deux semaines, son carnet montre ce qui a aidé, ce qui n’a pas aidé et pourquoi. Trois habitudes rendent sa méthode efficace :

  • Elle change une seule chose à la fois. Si elle changeait l’eau et le four ensemble, elle ne pourrait pas dire quel changement a aidé.
  • Elle goûte de la même façon chaque fois : le même type de pain, au même moment après la cuisson.
  • Elle note tout, même les changements qui ont échoué. Sans ces notes, elle essaierait de nouveau le four plus chaud le mois suivant.

L’apprentissage automatique fonctionne de la même façon. Cette leçon montre pourquoi et comment bien le faire.

Pourquoi vous ne pouvez pas connaître le meilleur modèle d’avance

Section intitulée « Pourquoi vous ne pouvez pas connaître le meilleur modèle d’avance »

Tomás, l’ingénieur en IA, pose une question directe à Priya : « Quel algorithme est le meilleur? Utilisons celui-là et terminons. » La question semble raisonnable, mais personne ne peut y répondre pour les billets de Larkfield sans essayer.

Chaque algorithme suppose une certaine forme de régularité dans les données. La régression logistique suppose que chaque fait ajoute ou enlève du risque, indépendamment des autres. Un arbre de décision, présenté dans la prochaine leçon, suppose que quelques questions posées dans l’ordre donnent la réponse. Par exemple : « priorité 1 et un long message ». Les données déterminent quelle hypothèse convient le mieux. Sur un jeu de données, les arbres gagnent. Sur un autre, la régression logistique gagne. Des chercheurs ont prouvé une forme de ce principe : aucun algorithme n’est le meilleur pour tous les problèmes. Ils l’appellent le théorème « no free lunch » : impossible d’obtenir un bon résultat sans effort, sans examiner vos données.

Les spécialistes ne choisissent donc pas le modèle selon sa réputation. Ils en essaient plusieurs, mesurent chacun de la même façon et gardent ce qui aide. C’est pourquoi on dit que l’apprentissage automatique est itératif : le travail avance par cycles, ou itérations. Chaque cycle tire des leçons du précédent. Ce qu’est l’apprentissage automatique présentait le processus d’apprentissage automatique comme une boucle, pas une ligne. Ce module couvre la partie de la boucle où vous essayez d’autres modèles.

Voici les étapes d’un cycle. La première fois, vous commencez en haut. Ensuite, vous parcourez la boucle encore et encore.

  1. Référence de base. Connaissez le résultat d’une règle simple, sans apprentissage automatique. La règle de Larkfield est « signaler les billets de priorité 1 ».
  2. Un premier modèle. Commencez par un modèle simple et rapide : la régression logistique.
  3. Évaluer. Évaluez le modèle avec la même validation croisée et la même métrique chaque fois.
  4. Examiner et noter. Comparez le résultat à la référence de base et au meilleur modèle jusqu’ici. Notez-le dans le journal, avec votre décision.
  5. Arrêter ou changer une chose. Si vous continuez, changez une chose et évaluez de nouveau.
Une boucle de cinq étapes. 1 Référence de base, la règle à battre. 2 Un premier modèle, simple et rapide. 3 Évaluer, avec la même validation croisée et la même métrique. 4 Examiner et noter : les erreurs et le journal d'expériences. Puis une question : arrêter? Les conditions d'arrêt sont : la cible est atteinte, le gain est inférieur au bruit ou le temps est écoulé. Si non : 5 changer une chose (données, caractéristiques, algorithme, hyperparamètres ou seuil), puis revenir à l'étape 3. Si oui : passer le modèle, le tester une fois, puis le documenter.
La boucle de développement d'un modèle. Les étapes 3, 4 et 5 se répètent jusqu'à ce qu'une condition d'arrêt soit remplie. Les données de test servent seulement après la boucle.
Description textuelle du diagramme

Le schéma comporte cinq étapes et une question. L’étape 1 est la référence de base, la règle à battre. L’étape 2 est un premier modèle, simple et rapide. L’étape 3 l’évalue avec la même validation croisée et la même métrique. L’étape 4 examine le résultat et le note dans le journal d’expériences. Vient ensuite la question « arrêter? ». La réponse est oui si la cible est atteinte, si le gain est inférieur au bruit ou si le temps est écoulé. Si la réponse est non, l’étape 5 change une chose : les données, les caractéristiques, l’algorithme, les hyperparamètres ou le seuil. La boucle revient alors à l’étape 3. Si la réponse est oui, le travail passe à la passation. Les données de test servent une fois, puis le modèle est documenté.

À l’étape 5, il existe cinq types de changements. Chacun a sa place dans ce cours :

  • Les données. Ajoutez des lignes, corrigez des étiquettes erronées ou utilisez des lignes plus récentes. Chez Larkfield, le module 8 prévoit de réentraîner le modèle avec les billets de mai et juin, après le changement de politique de garantie.
  • Les caractéristiques. Ajoutez une colonne qui apporte de l’information, ou retirez-en une qui n’apporte rien. Le module 6 teste quatre nouvelles colonnes. Il trouve une colonne utile et deux qui révèlent la réponse.
  • L’algorithme. Essayez une autre famille de modèles. Les prochaines leçons essaient les arbres de décision, les forêts aléatoires et le gradient boosting (renforcement par gradient).
  • Les hyperparamètres. Ce sont les réglages d’un algorithme que vous choisissez avant l’entraînement, comme la profondeur d’un arbre. Contrôler la complexité les explique, et le module 6 les règle.
  • Le seuil. Le score à partir duquel un billet est signalé. Le module 6 le choisit selon la capacité de Grace de 20 %.

Les cinq mêmes types, en résumé :

Ce que vous changez Exemple chez Larkfield Où dans le cours
Données Réentraîner avec les billets reçus après le changement de politique Module 8
Caractéristiques Ajouter prior_escalations_90d Sélectionner les caractéristiques utiles
Algorithme Un arbre, une forêt aléatoire, le gradient boosting Ce module
Hyperparamètres max_depth d’un arbre, C de la régression logistique Contrôler la complexité, Régler les hyperparamètres
Seuil Signaler à partir d’un score de 0,19 Seuils et calibration

La boucle n’a pas de fin naturelle. Vous décidez donc d’avance quand arrêter. Il existe trois bonnes raisons :

  • La cible est atteinte. Larkfield vise à signaler au plus 20 % des nouveaux billets et à détecter au moins 40 % des escalades. Quand un modèle atteint cette cible sur le mois de validation, il est utile. Vous pouvez encore l’améliorer, mais chaque cycle supplémentaire doit valoir son coût.
  • Les gains sont inférieurs au bruit. Si les derniers changements ont fait varier le score de moins que son écart-type, les données ne montrent aucune différence. D’autres cycles ne trouveront que des résultats dus à la chance.
  • Le temps ou le budget est épuisé. Un modèle qui aide l’équipe de Grace le mois prochain vaut souvent plus qu’un modèle légèrement meilleur l’année prochaine.

Chaque cycle compare un nouveau résultat au meilleur résultat jusqu’ici. La comparaison est juste seulement si les cycles suivent les mêmes règles. Chaque règle ci-dessous évite une erreur qui ressemble à un progrès.

  • Les mêmes données, les mêmes plis, la même métrique. Chaque modèle utilise les mêmes 5 plis des données d’entraînement et le même score, la précision moyenne. Si deux modèles sont évalués sur des billets différents, une différence peut venir des billets, pas des modèles.
  • La référence de base chaque fois. Présentez chaque nouveau résultat à côté de la règle et du meilleur modèle jusqu’ici. Un nombre seul ne veut rien dire.
  • Choisissez avec les données d’entraînement; confirmez avec les données de validation; gardez les données de test fermées. La validation croisée sur les données d’entraînement sert à choisir. Le mois de validation sert seulement à confirmer un choix, une fois. Ce sont les données gardées pour vérifier le modèle pendant votre travail. Les données de test servent une fois, après la boucle. Données d’entraînement, de validation et de test expliquait pourquoi : chaque consultation d’un ensemble réduit un peu son utilité.
  • Une différence inférieure au bruit n’est pas une différence. L’écart-type des scores des 5 plis montre à quel point un score varie par hasard. Si un changement fait varier la moyenne de moins que cela, écrivez « aucune différence réelle ».
  • Un changement à la fois. Si vous changez deux choses et que le score augmente, vous ne savez pas quel changement a aidé. L’un d’eux pourrait même rendre le modèle moins bon.

Omar, le responsable produit, demande : « Pourquoi être aussi strict? Si un modèle obtient un score plus élevé, il est meilleur. » Priya répond avec un nombre. La régression logistique obtient 0,310 sur un pli et 0,342 sur un autre, sans aucun changement. Une comparaison peu rigoureuse peut facilement trouver un gain de 0,03 qui n’existe pas. Larkfield paierait alors pour un modèle plus complexe sans rien obtenir en retour.

Le carnet de la cuisinière porte un nom en apprentissage automatique : le journal d’expériences. C’est un tableau avec une ligne par expérience, dans l’ordre où vous les avez réalisées. Une expérience est un essai : un modèle, avec un ensemble de caractéristiques et de réglages, évalué de la façon convenue.

Voici le journal de la cuisinière sous forme de tableau, pour vous montrer sa structure :

id changement résultat décision raison
1 La recette simple bon, un peu sec référence de base le point de départ
2 Plus d’eau plus moelleux garder meilleur, sans coût supplémentaire
3 Four plus chaud la croûte brûle rejeter moins bon

Le journal de Priya pour Larkfield suit la même idée, avec des nombres. Il contient ces colonnes :

  • id : E01, E02 et ainsi de suite, dans l’ordre.
  • date : le jour où vous avez réalisé l’expérience.
  • change : la seule chose qui a changé, décrite en mots.
  • cv_ap et cv_std : la moyenne des précisions moyennes des 5 plis et leur écart-type.
  • valid_ap : la précision moyenne sur le mois de validation. Remplissez cette colonne seulement pour un candidat vérifié une fois afin de confirmer une décision. Laissez-la vide pour les autres.
  • decision : baseline (référence de base), keep (garder) ou reject (rejeter).
  • reason : une phrase qui explique pourquoi.

Un journal aide de trois façons. Il sert de mémoire : vous ne répétez pas une expérience ratée. Il vous oblige à rester rigoureux : les expériences rejetées restent visibles, donc personne ne peut montrer seulement le meilleur résultat. Il raconte aussi le parcours aux autres : Grace ou une personne qui révise le travail peut comprendre le choix du modèle final.

Écrivez le journal pendant votre travail, pas à la fin. Vous garderez ce journal pour le reste du module 5 et tout le module 6.

Exemple détaillé : les premières lignes du journal

Section intitulée « Exemple détaillé : les premières lignes du journal »

Priya commence le journal avec ce que Larkfield connaît déjà : les deux références de base et la régression logistique. Pour les comparer équitablement, elle évalue les trois sur les mêmes 5 plis des données d’entraînement.

Les références de base n’apprennent pas, mais elles donnent quand même un score à chaque billet. « Un score pour tous les billets » donne à chaque billet le taux des données d’entraînement, 0,117. Ce score ne peut pas classer les billets. Son AP égale donc la proportion d’escalades. C’est le plancher de La précision moyenne : 0,117 sur les données d’entraînement. La règle donne 1 à un billet de priorité 1 et 0 aux autres. rule_scores() calcule l’AP de cette règle fixe sur chacun des 5 plis. cv_scores() fait la même chose pour un pipeline, avec la validation croisée.

import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import average_precision_score
from sklearn.model_selection import StratifiedKFold, cross_val_score
from ticket_model import FEATURES, TARGET, build_pipeline, load
train, valid = load("train"), load("valid")
cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=0)
def cv_scores(pipeline):
"""The AP of a pipeline on each of the 5 folds of train (cross-validation)."""
return cross_val_score(pipeline, train[FEATURES], train[TARGET], cv=cv, scoring="average_precision")
def rule_scores(score_of):
"""The AP of a fixed rule (it learns nothing) on each of the same 5 folds."""
return np.array([average_precision_score(train[TARGET].iloc[rows], score_of(train.iloc[rows]))
for _, rows in cv.split(train, train[TARGET])])

Avant d’exécuter la prochaine cellule, faites une prédiction : de combien la règle dépasse-t-elle le plancher de 0,117? Et la régression logistique?

one_score = rule_scores(lambda tickets: [0.117] * len(tickets))
priority_rule = rule_scores(lambda tickets: (tickets["priority"] == 1).astype(int))
logistic = cv_scores(build_pipeline())
for name, folds in [("one score for all", one_score), ("rule: priority 1", priority_rule),
("logistic regression", logistic)]:
print(f"{name:20s} folds {folds.round(3)} CV AP {folds.mean():.3f} ± {folds.std():.3f}")

La sortie :

Sortie
one score for all folds [0.117 0.117 0.117 0.117 0.117] CV AP 0.117 ± 0.000
rule: priority 1 folds [0.185 0.164 0.182 0.173 0.186] CV AP 0.178 ± 0.008
logistic regression folds [0.316 0.31 0.342 0.339 0.327] CV AP 0.327 ± 0.012

La règle dépasse le plancher de 0,061. La régression logistique dépasse la règle de 0,149, soit plus de dix fois son écart-type. Cette différence est réelle. Le mois de validation confirme l’ordre une fois :

pipeline = build_pipeline().fit(train[FEATURES], train[TARGET])
print("one score for all ", round(average_precision_score(valid[TARGET], [0.117] * len(valid)), 3))
print("rule: priority 1 ", round(average_precision_score(valid[TARGET], (valid["priority"] == 1).astype(int)), 3))
print("logistic regression", round(average_precision_score(valid[TARGET], pipeline.predict_proba(valid[FEATURES])[:, 1]), 3))
Sortie
one score for all 0.155
rule: priority 1 0.228
logistic regression 0.353

Les nombres sont plus élevés en mai, car 15,5 % des billets de mai ont été escaladés, contre 11,7 % des données d’entraînement. L’ordre reste le même. Priya écrit maintenant les trois lignes. log_experiment() ajoute une ligne à experiment_log.csv avec la date d’aujourd’hui, et show_log() affiche le journal. Le carnet définit ces deux fonctions utilitaires dans ses cellules de préparation.

log_experiment("E01", "Baseline: one score for every ticket (the train rate)", one_score.mean(), one_score.std(),
0.155, "baseline", "The floor: any useful model must be above it.")
log_experiment("E02", "Baseline: the rule 'flag priority 1', as a 0/1 score", priority_rule.mean(), priority_rule.std(),
0.228, "baseline", "What Larkfield does today: the model must beat it.")
log_experiment("E03", "Logistic regression, the 10 C04 features", logistic.mean(), logistic.std(),
0.353, "keep", "Far above both baselines; train AP 0.328, so it does not overfit.")
show_log()
Sortie
id change cv_ap cv_std valid_ap decision
E01 Baseline: one score for every ticket (the train rate) 0.117 0.000 0.155 baseline
E02 Baseline: the rule 'flag priority 1', as a 0/1 score 0.178 0.008 0.228 baseline
E03 Logistic regression, the 10 C04 features 0.327 0.012 0.353 keep

Tomás a une idée. « Seulement 11,7 % des billets d’entraînement ont été escaladés. Le modèle voit peu d’escalades, donc il les apprend mal. Disons-lui de compter davantage chaque billet escaladé. » scikit-learn propose un réglage pour cela : class_weight="balanced". Pendant l’entraînement, il donne à chaque billet escaladé environ 7,5 fois le poids d’un autre billet. C’est comme si les deux groupes avaient la même taille.

C’est une bonne expérience : elle apporte un seul changement au meilleur modèle jusqu’ici. Avant de lire la sortie, faites une prédiction : l’AP en validation croisée va-t-elle augmenter, diminuer ou rester à peu près identique?

balanced = cv_scores(build_pipeline(LogisticRegression(max_iter=1000, class_weight="balanced")))
print("logistic regression", logistic.round(3), f"CV AP {logistic.mean():.3f} ± {logistic.std():.3f}")
print("balanced ", balanced.round(3), f"CV AP {balanced.mean():.3f} ± {balanced.std():.3f}")
print("balanced − logistic", (balanced - logistic).round(3))
Sortie
logistic regression [0.316 0.31 0.342 0.339 0.327] CV AP 0.327 ± 0.012
balanced [0.314 0.309 0.339 0.335 0.32 ] CV AP 0.323 ± 0.012
balanced − logistic [-0.002 -0.002 -0.003 -0.004 -0.007]

Le modèle équilibré obtient un score inférieur sur les 5 plis. Comme les plis sont les mêmes, Priya peut comparer pli par pli. Le changement n’aide pas. Pourquoi? La précision moyenne dépend seulement de l’ordre des billets selon leur score. Les poids augmentent tous les scores, mais changent très peu l’ordre. Le changement a aussi un coût : les scores ne correspondent plus au taux réel d’escalade. Cela compte dans Seuils et calibration.

Décision : rejeter. L’expérience va quand même dans le journal, pour que personne ne la réessaie le mois prochain sans nouvelle raison.

Le journal d'expériences après cette leçon : l'AP en validation croisée de chaque expérience, avec une barre d'un écart-type de chaque côté. E03, la régression logistique, est la meilleure jusqu'ici.
Description textuelle du graphique

Le graphique montre cinq lignes, une par expérience, sur un axe de 0,10 à 0,35. Une ligne pointillée marque le plancher, 0,117. E01, un score pour tous les billets : 0,117, sans dispersion. E02, la règle « signaler les billets de priorité 1 » : 0,178, de 0,170 à 0,186. E03, la régression logistique : 0,327, de 0,315 à 0,339, mise en évidence comme modèle à garder. E04, la régression logistique avec des poids de classes équilibrés : 0,323, de 0,311 à 0,335. Sa barre chevauche celle de E03. E05, la règle « signaler les billets de priorité 1 ou de l’équipe payment » : 0,172, de 0,166 à 0,178, un peu sous E02.

Exercice guidé : consigner l’expérience de Tomás

Section intitulée « Exercice guidé : consigner l’expérience de Tomás »

Faites ceci dans le carnet Jupyter. Chaque étape comprend une vérification.

  1. Exécutez les cellules de préparation, puis celles de l’exemple détaillé. Vous devriez voir le journal avec trois lignes, de E01 à E03.
  2. Exécutez la cellule qui calcule balanced. Vous devriez voir CV AP 0.323 ± 0.012 (AP en validation croisée : moyenne ± écart-type).
  3. Écrivez la ligne E04 avec log_experiment(). Utilisez la modification "E03 with class_weight='balanced'" (E03 avec des poids de classe équilibrés), la moyenne et l’écart-type de balanced, aucune AP de validation (None), et la décision "reject" (rejeter).
  4. Écrivez une raison en une phrase, dans vos propres mots.
  5. Exécutez show_log(). Vous devriez voir quatre lignes.
  6. Exécutez la cellule de vérification. Vous devriez voir Check passed: the row E04 is right. (Vérification réussie : la ligne E04 est correcte).
Afficher un exemple de réponse
log_experiment("E04", "E03 with class_weight='balanced'", balanced.mean(), balanced.std(),
None, "reject", "Lower than E03 on all 5 folds; one more setting for no gain.")
show_log()
Sortie
id change cv_ap cv_std valid_ap decision
E01 Baseline: one score for every ticket (the train rate) 0.117 0.000 0.155 baseline
E02 Baseline: the rule 'flag priority 1', as a 0/1 score 0.178 0.008 0.228 baseline
E03 Logistic regression, the 10 C04 features 0.327 0.012 0.353 keep
E04 E03 with class_weight='balanced' 0.323 0.012 reject

L’AP de validation reste vide. Une modification qui perd sur chaque pli n’est pas une candidate. Il n’y a donc rien à confirmer.

Changez une condition : pas le modèle, mais la référence de base. Grace demande si une règle plus large ferait mieux : « signaler les billets de priorité 1, ou tout billet de l’équipe des paiements ». L’équipe des paiements a le taux d’escalade le plus élevé dans les données d’entraînement, soit 20,7 %.

Calculez l’AP en validation croisée de cette règle avec rule_scores(), sur les mêmes plis. Avant de l’exécuter, faites une prédiction : battra-t-elle la règle « signaler les billets de priorité 1 » (0,178)? Écrivez ensuite la ligne E05 dans le journal, avec votre décision et votre raison.

wider_rule = rule_scores(lambda tickets: ((tickets["priority"] == 1) | (tickets["team"] == "payment")).astype(int))
print(wider_rule.round(3), f"CV AP {wider_rule.mean():.3f} ± {wider_rule.std():.3f}")
Afficher la réponse
Sortie
[0.171 0.172 0.166 0.166 0.182] CV AP 0.172 ± 0.006

La règle plus large obtient un résultat un peu plus bas que la règle « signaler les billets de priorité 1 » (0,178 ± 0,008). Les billets de paiement font plus souvent l’objet d’une escalade que la moyenne. Mais la plupart n’en font toujours pas l’objet (79,3 %). La règle plus large signale beaucoup plus de billets, et la part des véritables escalades parmi les billets signalés diminue. Décision : rejeter. Une raison possible : « Résultat inférieur à celui de la règle plus simple E02. »

log_experiment("E05", "Baseline: the rule 'flag priority 1 or team payment'", wider_rule.mean(), wider_rule.std(),
None, "reject", "Lower than the simpler rule E02.")

Erreur courante

Un gain qui venait des plis

Symptôme : Tomás a essayé le modèle équilibré avant Priya. Il rapporte : « Les poids équilibrés ajoutent 0,029 d’AP. La régression logistique a obtenu 0,310, et le modèle équilibré, 0,339. » Ses chiffres sont réels :

print("Tomás's check of logistic regression, fold 2:", logistic[1].round(3))
print("Tomás's check of the balanced model, fold 3: ", balanced[2].round(3))
Sortie
Tomás's check of logistic regression, fold 2: 0.31
Tomás's check of the balanced model, fold 3: 0.339

Cause : il a évalué les deux modèles sur des billets différents. Le pli 3 est plus facile que le pli 2. La régression logistique elle-même obtient 0,342 sur le pli 3 et 0,310 sur le pli 2. Tout le « gain » vient des billets, pas de la modification. Sur les mêmes plis, le modèle équilibré obtient un résultat inférieur sur les cinq.

Correction : évaluez chaque expérience avec le même objet cv (les mêmes 5 plis) et la même métrique. Comparez la moyenne ± l’écart-type, ou comparez les résultats pli par pli. Écrivez le résultat dans le journal seulement s’il a été mesuré de la façon convenue.

Conséquence dans le travail en IA : une comparaison inéquitable fait adopter des modifications inutiles, ou qui dégradent même le modèle. Chacune ajoute de la complexité. Après quelques mois, personne ne sait quelles parties du modèle aident vraiment.

Vérifiez votre compréhension

Tomás change deux choses dans une expérience : il ajoute une variable et passe à une forêt aléatoire. L'AP en validation croisée passe de 0,327 à 0,345 ± 0,012. Que peut conclure Priya, et que devrait-elle faire ensuite?

Afficher la réponse

Elle peut conclure que la combinaison pourrait être meilleure : 0,018 représente environ un écart-type et demi. Mais elle ne peut pas dire quelle modification a aidé. La variable seule pourrait expliquer tout le gain, et la forêt pourrait même être moins bonne. Elle devrait mener deux expériences, chacune avec une seule modification : la régression logistique avec la nouvelle variable, et la forêt sans elle. Elle consigne ensuite les deux.

Vérifiez votre compréhension

L'expérience A a une AP en validation croisée de 0,331 ± 0,015. Le meilleur modèle actuel, E03, obtient 0,327 ± 0,012 sur les mêmes plis. A est plus complexe. Qu'écrivez-vous dans les colonnes de décision et de raison?

Afficher la réponse

Décision : rejeter. Raison, par exemple : « Égalité avec E03 : la différence, 0,004, est inférieure à un écart-type; A est plus complexe. » Une différence inférieure au bruit n’est pas une différence, donc on garde le modèle plus simple. Regardez aussi les plis : si A obtenait un meilleur résultat sur les cinq plis, les arguments en sa faveur seraient plus solides.

Vérifiez votre compréhension

Omar demande pourquoi le journal conserve les expériences rejetées. « Seul le modèle final compte. » Donnez deux raisons de les conserver.

Afficher la réponse

D’abord, la mémoire : l’équipe ne répète pas une expérience qui a déjà échoué, comme les poids équilibrés. Ensuite, l’honnêteté : le lecteur voit combien d’idées ont été essayées. Si on montre seulement le meilleur de nombreux essais, son score paraît meilleur qu’il ne l’est. Certains essais gagnent en effet par chance. Une troisième raison : le journal explique à Grace ou à une personne qui révise le travail pourquoi le modèle final a été choisi.

Récapitulatif

  • Aucun algorithme n’est le meilleur pour tous les problèmes. Vous trouvez le meilleur modèle pour vos données en en essayant plusieurs, évalués de la même façon.
  • La boucle : référence de base, premier modèle, évaluation, examen et consignation, puis modification d’une seule chose et nouvelle évaluation. Arrêtez quand la cible est atteinte, que les gains sont inférieurs au bruit ou que le temps est écoulé.
  • Cinq types de modifications : données, variables, algorithme, hyperparamètres, seuil.
  • Gardez la boucle honnête : mêmes plis et même métrique, référence de base à chaque fois, choix sur les données d’entraînement, confirmation unique sur les données de validation, données de test gardées à l’écart, une modification à la fois.
  • Le journal d’expériences a une ligne par expérience : id, date, change, cv_ap, cv_std, valid_ap, decision, reason. Le vôtre a cinq lignes : la régression logistique (0,327 ± 0,012) est la meilleure jusqu’ici.

Ensuite, vous essayez une autre famille de modèles : l’arbre de décision.

Leçon suivante : Les arbres de décision