É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.
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
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 ».
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.