Contexte

Une entreprise décide de développer un moteur de validation de qualité automatique pour des pièces produites industriellement. Le moteur devra donc calculer une probabilité d'appartenance à une catégorie, celle des pièces "valides" (V) et celle des pièces "non-valides" (NV). Elle souhaite donc développer un algorithme de classification binaire en s’appuyant sur des sources de données variées (données de processus de production, données mesurées...).

De plus, il est important pour l'entreprise d'avoir accès aux explications du choix final de validation ou non-validation, donc d'avoir accès à l"'interprétabilité" du moteur de classification. Également, elle souhaite un accès simplifié à toutes ces données, par conséquent un dashboard interactif est développé afin que les responsables de production puissent à la fois comprendre et expliquer de façon la plus claire possible les décisions de validation.

Pour ce projet, les différentes étapes ont été suivies :

• Développement d’un modèle de classification qui donnera une prédiction sur la validité d'une pièce. ;
• Construction d’un dashboard interactif ;
• Mise en production du modèle de classification à l’aide d’une API, ainsi que le dashboard interactif qui appelle l’API pour les prédictions.

Données

Les données sont divisées en 10 data sets, avec des informations sur les pièces (couleur, dimensions,…) ainsi que sur le process de production (température, temps…). Un jeu d’entraînement est fourni, avec la variable cible inclue, qui donne la décision finale (0 : Valide, 1 : Non-Valide), ainsi qu'un jeu de test, cette fois-ci sans la variable cible, pour tester le modèle déjà entraîné.

Analyse exploratoire

TARGET

En observant les données du jeu d’entraînement, on s’aperçoit que les données sont déséquilibrées : on observe une grande majorité de classe V ou 0 (92 %) comparée à la classe NV ou 1 (8 %). Nous sommes donc face à un problème de Class Imbalance.

Il existe plusieurs méthodes pour gérer un problème de Class Imbalance dans les données d’entraînement (SMOTE, Under-sampling, Over-sampling…). La méthode Class Weight est sélectionnée : on ajuste la fonction de coût du modèle de sorte que la mauvaise classification d’une observation de classe minoritaire soit plus lourdement pénalisée que la mauvaise classification d’une observation de la classe majoritaire.

Préparation des données

Split Train/Validation

Le jeu de données avec la variable cible est divisé en train set/validation set, avec une proportion 80 %/ 20 %.

Nettoyage des données

Après une séparation du jeu de données en données train et données validation pour le modèle, elles sont séparément nettoyées (traitement des valeurs manquantes, valeurs aberrantes…). Puis les variables quantitatives sont normalisées, les variables catégorielles binarisées.

Modèle de notation

Algorithme testés

Les modèles testés sont :

• Dummy Classifier : modèle de référence
• Logistic Regression
• Random Forest Classifier

La recherche des hyper-paramètres optimaux pour les algorithmes de Logistic Regression et Random Forest est faite à l’aide de GridSearchCV.

Comparaison des performances

Afin de comparer les algorithmes, l’AUC est calculée, un indicateur de la capacité discriminatoire du modèle, entre la classe 1 et la classe 0. On ajoute le temps de calcul, toujours un élément intéressant.

L’algorithme de Logistic Regression est sélectionné, prouvant que complexité n'est pas toujours synonyme d'efficacité.

Fonction Coût Métier

Les pertes financières par mauvaise prédiction de qualité ne sont pas souhaitables. Cependant, il est impossible de les supprimer totalement. On peut tout de même optimiser le modèle ainsi que la fonction Coût-Métier afin de les limiter.

Les prédictions peuvent être classées comme suit :

• Faux Positifs : les cas où la prédiction est positive mais où la valeur réelle est négative. On a ici une perte d’opportunité si la pièce n'est pas validée et jétée, alors qu'elle ne présentait au final aucun problème.
• Faux Négatifs : les cas où la prédiction est négative, mais où la valeur réelle est positive. On a ici une perte réelle doublée d'une brèche de sécurité, si la pièce est acceptée tout en ne présentant pas les caractéristiques exigées, et est par la suite utilisée.
• Vrais Positifs : cas d’acceptation où la pièce est réelle valide.
• Vrais Négatifs : cas de refus où la pièce n'est effectivement pas valide.
  

Dans notre cas, on comprend qu’il est nécessaire de minimiser particulièrement les Faux Négatifs, ce cas présentant non seulement des risques de pertes financières mais également de sécurité.

On considère alors deux critères : Recall et Precision.

Il est nécessaire de maximiser les deux valeurs, en particulier Recall.

Pour ce faire, on utilise la fonction Fbeta Score, avec beta > 1 pour que Recall ait un poids plus important :

Cette fonction est sélectionnée comme fonction coût métier, et doit être maximisée.

Afin de déterminer le seuil pour l’algorithme de régression logistique, un paramètre important de l'algorithme, on trace le Fbeta score en fonction du seuil de décision de l’algorithme de classification.

On remarque que le Fbeta score est maximisé pour un seuil de Logistic Regression de 0.67, donc 67% de probabilité de non validité.

On définit les seuils de décision pour les classes 1 (Non-Validité) et 0 (Validité) :

• 1 : 0.67
• 0 : 0.33

Interprétabilité

Dans un souci de transparence de la décision finale, il est important de pouvoir expliquer cette décision. Pour cela, on détaille le score obtenu et l’impact des différentes variables. On interprète le résultat.

L’"interprétabilité" désigne donc l’évaluation globale ou locale du processus de prise de décision. Elle vise à représenter l’importance relative de chaque variable dans le processus de décision.

On trace donc par ordre décroissant les coefficients associés à chaque variable, sachant qu’ils peuvent être positifs ou négatifs.

API & Dashboard

Pour mettre en place l’API, on commence par charger le modèle pré-entraîné sur les données d’apprentissage.

On définit une page d’accueil, ainsi qu’une page de prédiction. Elle reçoit en entrée les données test choisie, et renvoie la probabilité de non validité, ainsi que le statut de la décision.

Les fonctionnalités suivantes sont implémentées :

• Visualisation du score et interprétation de ce score pour chaque pièce de façon intelligible pour une personne non experte en data science.
• Visualisation des informations descriptives relatives à une pièce (via un système de filtre).
• Possibilité de comparaison des informations descriptives relatives à une pièce à l’ensemble des pièces.

Le dashboard :

• demande à l’utilisateur un numéro de dossier ;
• envoi une requête à l’URL de l’API avec les données test sélectionnée à partir du numéro de dossier ;
• reçoit la valeur de probabilité pour la classe 1 (Non-Valide);
• affiche le résultat ;