prof404
← Retour aux ressources du module
Sommaire (5 sections) · 7 min
Ce que tu travailles iciMachine learningPourquoi ces compétences ?
  • BC03Machine learning. Choisir et entraîner un modèle d'apprentissage automatique, et savoir juger ce qu'il vaut.

Ce sont les compétences du titre RNCP 38616, celles sur lesquelles le jury évalue.

Évaluer un modèle de classification

Un modèle peut afficher beaucoup de bonnes réponses en prédisant toujours la catégorie la plus fréquente, alors que le cas recherché est rare. Avant de parler de performance, il faut comparer ses erreurs à une règle de référence.

Utilise cette règle fixée pour l'exercice : annoncer un avis faible quand le nombre maximal de mensualités d'une commande atteint six. Un avis faible vaut ici 1 ou 2 sur 5. Cette règle n'est pas apprise par un modèle : elle sert à comparer des mesures d'évaluation sur les commandes historiques d'Olist.

1. Construire une ligne par commande

Une commande peut avoir plusieurs lignes de paiement et plusieurs lignes d'avis. On les résume séparément avant de les joindre pour ne pas multiplier les commandes. MAX conserve le plus grand nombre de mensualités, sans les additionner. MIN conserve la note la plus basse : la cible vaut donc vrai si la commande a au moins un avis faible.

La jointureRapprocher deux tables sur une colonne commune, pour lire ensemble des informations qui sont stockées séparément. conserve seulement les commandes ayant un paiement et un avis. Les mensualités et notes sont non nulles dans cette base. Un moyen de paiement unique donne le groupe de la commande ; plusieurs moyens différents donnent le groupe « plusieurs moyens ». Ce regroupement reste au niveau commande.

SQL
WITH paiements AS (
    SELECT payment_order_id AS order_id,
           MAX(payment_installments) AS mensualites,
           CASE WHEN COUNT(DISTINCT payment_type) = 1 THEN MIN(payment_type)
                ELSE 'plusieurs moyens'
           END AS groupe_paiement
    FROM order_payments
    GROUP BY payment_order_id
),
avis AS (
    SELECT order_id, MIN(review_score) AS note
    FROM order_reviews
    GROUP BY order_id
)
SELECT COUNT(*) AS commandes,
       COUNT(*) FILTER (WHERE note <= 2) AS avis_faibles
FROM paiements
JOIN avis USING (order_id);

Avant d'exécuter, prédis si les deux comptes peuvent être égaux. Le second est un sous-ensemble du premier ; il ne peut pas le dépasser. Ils seraient égaux si toutes les commandes retenues avaient un avis faible. Ici, le contrôle donne 98 672 commandes, dont 14 532 avec au moins un avis faible.

2. Compter les quatre résultats possibles

SQL
WITH paiements AS (
    SELECT payment_order_id AS order_id,
           MAX(payment_installments) AS mensualites,
           CASE WHEN COUNT(DISTINCT payment_type) = 1 THEN MIN(payment_type)
                ELSE 'plusieurs moyens'
           END AS groupe_paiement
    FROM order_payments
    GROUP BY payment_order_id
),
avis AS (
    SELECT order_id, MIN(review_score) AS note
    FROM order_reviews
    GROUP BY order_id
),
evaluation AS (
    SELECT mensualites >= 6 AS prediction_faible,
           groupe_paiement,
           note <= 2 AS faible_reel
    FROM paiements
    JOIN avis USING (order_id)
)
SELECT prediction_faible, faible_reel, COUNT(*) AS commandes
FROM evaluation
GROUP BY prediction_faible, faible_reel
ORDER BY prediction_faible DESC, faible_reel DESC;

La justesseLa part des cas où un modèle a eu raison, dans un sens comme dans l'autre. Sur une population déséquilibrée elle monte très haut toute seule : répondre « à l'heure » à toutes les commandes Olist livrées donne 93,23 %. est la proportion des réponses correctes, toutes catégories confondues. Avant de calculer, choisis les deux cases où prédiction et réalité sont identiques. Additionne-les, divise par toutes les commandes, puis multiplie par 100.

Contrôler la justesse de la règle

(2713 + 70923) / 98672 × 100 = 74,63 %, arrondi à deux décimales. Le dénominateur comprend toutes les commandes retenues, y compris celles sans avis faible. Un pourcentage élevé peut donc masquer de nombreux avis faibles manqués.

Pour distinguer ces erreurs, la fiche Lire une matrice de confusionLe tableau à quatre cases qui compte, pour un modèle qui répond oui ou non, chaque croisement de sa réponse et de la réalité. « Positif » y désigne la catégorie qu'on cherche à détecter, comme le retard, et ne veut pas dire bon. fait calculer le rappel parmi les cas recherchés et la précision parmi les alertes. Ici, tu vas surtout comparer la justesse à une référence, puis vérifier si les erreurs se répartissent de la même façon dans les groupes.

3. Comparer à une référence

La règle de référence annonce toujours la catégorie la plus fréquente. Ici, elle prédit toujours « avis non faible ».

SQL
WITH paiements AS (
    SELECT DISTINCT payment_order_id AS order_id
    FROM order_payments
),
avis AS (
    SELECT order_id, MIN(review_score) AS note
    FROM order_reviews
    GROUP BY order_id
)
SELECT ROUND(100.0 * COUNT(*) FILTER (WHERE note > 2) / NULLIF(COUNT(*), 0), 2) AS justesse_reference
FROM avis
JOIN paiements USING (order_id);

Avant d'exécuter, prédis si cette règle peut obtenir une bonne justesse sans repérer le moindre avis faible. Compare ensuite les deux règles sur les mêmes commandes et écris ce que la référence manque par construction.

Contrôler la comparaison

La référence donne (98672 - 14532) / 98672 × 100 = 85,27 % de bonnes réponses, contre 74,63 % pour la règle des six mensualités. Elle ne déclenche aucune alerte : son rappel vaut 0 % et sa précision est non définie.

La référence est meilleure pour la justesse sur ces données. Cela ne décide pas laquelle serait utile pour une action métier : il reste à établir le coût des erreurs et les cas qu'on cherche à repérer. NULLIF évite une division par zéro si la population est vide ; le résultat serait alors NULL, pas un score.

4. Comparer les erreurs entre groupes

Garde le seuil de six. La CTECommon Table Expression : un résultat intermédiaire auquel on donne un nom avec WITH, pour s'en servir ensuite comme d'une table. paiements classe déjà chaque commande par moyen de paiement unique ou dans « plusieurs moyens ». Compare les groupes avec une mesure définie à l'avance : la proportion de prédictions incorrectes. Son numérateur compte les lignes où prediction_faible <> faible_reel ; son dénominateur contient toutes les commandes du groupe.

À partir des CTE de la section 2, remplace le dernier SELECT pour obtenir, pour chaque groupe, son effectif, son nombre d'erreurs et ce pourcentage. Trie par pourcentage décroissant, puis par groupe pour départager les égalités. Un grand groupe peut compter davantage d'erreurs sans avoir la plus forte proportion. Même un taux élevé sur un groupe minuscule appelle de la prudence. Si un libellé ne décrit pas un moyen de paiement identifiable, signale cette limite avant de lui donner une interprétation métier.

Construire le calcul sans changer la population

Dans le SELECT, utilise groupe_paiement, COUNT(*) pour l'effectif et COUNT(*) FILTER (WHERE prediction_faible <> faible_reel) pour les erreurs. Le pourcentage est 100.0 × erreurs / effectif, arrondi à deux décimales. Le GROUP BY doit porter seulement sur groupe_paiement : conserver les deux booléens découperait chaque groupe en cases au lieu de calculer son taux global.

Contrôle que les effectifs des groupes totalisent 98 672 commandes, et les erreurs 25 036 (13217 + 11819). La moyenne des taux de groupes ne donne pas le taux global si leurs tailles diffèrent : reprends la somme des erreurs divisée par la somme des effectifs, soit 25,37 %. Explique ensuite si ton constat porte sur un volume, une proportion ou un petit effectif fragile.

5. Écarter les fuites de données

Les calculs précédents sont rétrospectifs : ils utilisent la population historique retenue, sans jeu de test indépendant. Ils ne prouvent ni une performance future ni un effet causal du paiement sur l'avis.

Une variable d'entrée doit être connue au moment où la prédiction sera faite. La note elle-même, un commentaire écrit après livraison ou une information créée après l'événement ne peut pas servir à prédire la note à l'avance. Ce serait une fuite de donnéesUne variable d'entrée qui ne sera pas connue au moment où on prédit, comme la date de livraison réelle. Elle rend le modèle excellent sur les exemples passés et inutile ensuite, sans produire la moindre erreur. : le modèle lirait une partie de la réponse.

Pour ton transfert, choisis une cible, un moment de prédiction et trois variables connues à ce moment. Pour chacune, écris comment tu vérifieras sa date de disponibilité. Le résultat attendu est une critique du modèle avec sa référence, ses erreurs et une limite précise, pas seulement un score.

À la fin de la leçon

Le quiz de la leçon

Choisis une réponse, puis lis l’explication avant de continuer.

  • 6 questions
  • 3 min par question
  • Une explication après chaque réponse

Le chrono démarre à la première question. Un clic sur une réponse valide ton choix.