Lien du github où se trouve le notebook ainsi que les différentes sources:
https://github.com/Nordine67200/P7_Openclassroom
• Dans le cadre du projet 7 de la formation Data Scentist, il est demandé d'implémenter un modèle de scoring de demande de prêt. Cette note présente le processus de modélisation et d'interprétabilité.
• Une société financière, nommée "Prêt à dépenser", qui propose des crédits à la consommation pour des personnes ayant peu ou pas du tout d'historique de prêt, désire mettre en œuvre un modèle de "scoring crédit" qui correspond à la probabilité qu'un client rembourse le prêt.
• Les données utilisées comportent un fichier contenant les demandes de prêts ainsi que d'autres fichiers correspondant à l'historique des précédents prêts dans l'application et auprès d'autres organismes financiers.
Le modèle a été entrainé avec un jeu de donnée issue d'un preprocessing comportant les phases de feature engineering, consolidation, nettoyage et transformation. Le notebook utilisé est consultable sur le site kaggle:
([https://www.kaggle.com/code/nordinerajaoui/notebook708a653bac/notebook#Analyse-univariée])
Le jeu de données étant déséquilibrée: 92% des données ne sont pas des prêts ne présentent pas de risque de défaut de paiement tandis que seul 8% en présente. De ce fait, si l'on sépare le jeu de données en données de training et de test de manière aléatoire, il y a des risques que l'on n'ait que les prêts en risque dans le jeu de training ou de test, ce qui nous donnera un mauvais score.
La séparation se fera en utilisant la fonction train_test_split (sklearn.model_selection) avec l'option stratify=y.
Les données représentant les défauts de paiement étant largement minoritaire (8%), il n'a pas assez de représentants pour que le modèle en apprenne le pattern. Pour éviter ce problème, deux approches ont été testées:
- SMOTE: algorithme qui synthétise des données pour la classe minoritaire. Permet de créer un jeu de données équilibré.
- class weights: plus de poids est appliqué aux données minoritaire (ici les prêts en défaut de paiement) dans la fonction de coût de sorte à accorder une plus grosse pénalité et ainsi modifier les paramètres du model:
TUNING des hyper-paramètres
Etant donné la lenteur de GridSearchCV qui compare les performances pour chaque combinaison de valeurs de plage de chaque paramètre, deux types d'approche ont été testé:
- RandomizedSearchCV: contrairement à GridSearchCV, toutes les valeurs de paramètre ne sont pas testées, mais un nombre fixe de paramètres est échantillonné à partir des distributions spécifiées. Le nombre de paramétrages essayés est donné par n_iter.
- BayesianOptimisation: méthode séquentielle basée sur le processus gaussien pour trouver le minimum d'une fonction (on détermine une fonction qui prend en entrée les hyperparamètres et retourne le score)
Ces deux approches ont été utilisées sur des jeux de données enrichies par la méthode SMOTE puis sans mais en utilisant l'hyperparamètre class_weight sur les algorithmes de machine learning ci-dessous:
- RandomForestClassifier
- XGBoostClassifier
- LGBMClassifier
Fonction de coût
| Algorithme | Fonction de coût |
|---|---|
| RandomForestClassifier | Gini impurity |
| XGBoostClassifer | Log loss |
| LGBMClassifer | Log loss |
Métrique d’évaluation
Dans le jeu de données, il y’a une part de 92 % des clients qui n’ont pas d’incident de paiement tandis que seulement de 8% des clients ont eu des incidents.
La matrice de précision se présente ainsi :
| Clients prédits sans risque | Clients prédits en risque | |
|---|---|---|
| Clients sans défaut | Vrais négatif | Faux positif |
| Clients réellement en défaut | Faux négatif | Vrais positif |
Les pertes financières liées aux défauts de paiement sont bien plus important que la perte potentielle de clients. Il est donc préférable de mieux prédire les clients en risque de défaut de paiement. On essaiera donc de maximiser le recall :
Cela dit, il faudra aussi faire attention à ne pas avoir une précision trop faible pour maximiser le nombre de clients :
Cet arbitrage se fait via le seuil de classification. Plus il sera faible, plus la classification favorisera les vrais positifs mais aussi les faux positifs (hausse du recall et baisse des précisions). Plus il sera élevé et plus il favorisera les vrais négatifs mais aussi les faux négatifs (hausse de la précision et baisse du recall)
Ce choix s’effectue via le dashboard :
Le f1-score effectuant une moyenne harmonique entre le recall et la précision en donnant autant de poids à l'un qu'à l'autre, on se basera sur un fbeta-score avec beta = 2.
Les équipes opérationnelles devant être en mesure d'expliquer les décisions de l'algorithmes, un dashboard est mis à leur disposition avec deux volets principales:
- Volet analyse par prêt: On utilise LIME pour expliquer le score:
- Volet analyse du modèle: permet de visualiser la performance du modèle par seuil de décision (voir plus haut).
Un premier axe d'amélioration est de définir plus finement la métrique d'évaluation avec le métier afin d'obtenir un arbitrage recall/précision plus en accord avec les réalités financières. Cela résulterait sur un f-beta score plus fidèle à leur besoin. Un deuxième axe serait de rajouter plus de variables à nos modèles et éventuellement d'en créer d'autres avec le métier pour aider le modèle à être plus efficace. Enfin, il serait intéressant de transformer plus finement les variables fortement skewed sans dénaturer leur skewness en les rendant symétriques mais en essayant d'avoir, pour chaque variable, une skewness la plus proche de la variable target (environ 10% de données dans le tail).