Détectez les transactions frauduleuses à l'aide de l'apprentissage automatique avec Amazon SageMaker

Les entreprises peuvent perdre des milliards de dollars chaque année en raison d'utilisateurs malveillants et de transactions frauduleuses. Alors que de plus en plus d'opérations commerciales se déplacent en ligne, la fraude et les abus dans les systèmes en ligne sont également en augmentation. Pour lutter contre la fraude en ligne, de nombreuses entreprises utilisent des systèmes de détection de fraude basés sur des règles.

Cependant, les systèmes traditionnels de détection de fraude reposent sur un ensemble de règles et de filtres élaborés à la main par des spécialistes humains. Les filtres peuvent souvent être fragiles et les règles peuvent ne pas saisir tout le spectre des signaux frauduleux. De plus, alors que les comportements frauduleux sont en constante évolution, la nature statique des règles et des filtres prédéfinis rend difficile la maintenance et l'amélioration efficaces des systèmes traditionnels de détection des fraudes.

Dans cet article, nous vous montrons comment créer un système de détection de fraude par carte de crédit dynamique, auto-amélioré et maintenable avec l'apprentissage automatique (ML) en utilisant Amazon Sage Maker.

Alternativement, si vous recherchez un service entièrement géré pour créer des modèles de détection de fraude personnalisés sans écrire de code, nous vous recommandons de consulter Détecteur de fraude Amazon. Amazon Fraud Detector permet aux clients sans expérience en ML d'automatiser la création de modèles de détection de fraude personnalisés pour leurs données, en s'appuyant sur plus de 20 ans d'expertise en détection de fraude d'AWS et d'Amazon.com.

Vue d'ensemble de la solution

Cette solution constitue le cœur d'un système de détection de fraude par carte de crédit utilisant SageMaker. Nous commençons par entraîner un modèle de détection d'anomalies non supervisé à l'aide de l'algorithme Forêt à Coupe Aléatoire (RCF). Ensuite, nous formons deux modèles de classification supervisée en utilisant l'algorithme XGBoost, l'un comme modèle de base et l'autre pour faire des prédictions, en utilisant différentes stratégies pour remédier au déséquilibre extrême des classes dans les données. Enfin, nous formons un modèle XGBoost optimal avec optimisation des hyperparamètres (HPO) pour améliorer encore les performances du modèle.

Pour l'échantillon de données, nous utilisons les transactions par carte de crédit publiques et anonymisées jeu de données qui a été initialement publié dans le cadre d'un un article collaboration de Worldline et du Groupe Machine Learning de l'ULB (Université Libre de Bruxelles). Dans la procédure pas à pas, nous expliquons également comment vous pouvez personnaliser la solution pour utiliser vos propres données.

Les sorties de la solution sont les suivantes :

• Un sans surveillance SageMaker RCF maquette. Le modèle génère un score d'anomalie pour chaque transaction. Une valeur de score faible indique que la transaction est considérée comme normale (non frauduleuse). Une valeur élevée indique que la transaction est frauduleuse. Les définitions de faible et élevé dépendent de l'application, mais la pratique courante suggère que les scores au-delà de trois écarts-types par rapport au score moyen sont considérés comme anormaux.
• Un supervisé SageMaker XGBoost modèle formé à l'aide de son schéma de pondération intégré pour résoudre le problème des données très déséquilibrées.
• Un modèle supervisé SageMaker XGBoost formé à l'aide du Technique de suréchantillonnage de la minorité sythétique (SMOTE).
• Un modèle SageMaker XGBoost formé avec HPO.
• Prédictions de la probabilité que chaque transaction soit frauduleuse. Si la probabilité estimée d'une transaction dépasse un certain seuil, elle est classée comme frauduleuse.

Pour montrer comment vous pouvez utiliser cette solution dans vos infrastructures d'entreprise existantes, nous incluons également un exemple d'appels d'API REST vers le point de terminaison du modèle déployé, à l'aide de AWS Lambda pour déclencher à la fois les modèles RCF et XGBoost.

Le diagramme suivant illustre l'architecture de la solution.

Pré-requis

Pour essayer la solution dans votre propre compte, assurez-vous que vous disposez des éléments suivants :

Lorsque l'instance de Studio est prête, vous pouvez lancer Studio et accéder à JumpStart. Les solutions JumpStart ne sont pas disponibles dans les instances de bloc-notes SageMaker et vous ne pouvez pas y accéder via les API SageMaker ou le Interface de ligne de commande AWS (AWS CLI).

Lancer la solution

Pour lancer la solution, procédez comme suit:

1. Ouvrez JumpStart en utilisant le lanceur JumpStart dans le Débuter ou en choisissant l'icône JumpStart dans la barre latérale gauche.
2. Sous Solutions, choisissez Détecter les utilisateurs et les transactions malveillants pour ouvrir la solution dans un autre onglet Studio.
   
3. Dans l'onglet Solution, choisissez Lancement pour lancer la solution.
   
   Les ressources de la solution sont provisionnées et un autre onglet s'ouvre indiquant la progression du déploiement. Lorsque le déploiement est terminé, un Cahier ouvert Le bouton apparaît.
4. Selectionnez Cahier ouvert pour ouvrir le bloc-notes de solutions dans Studio.
   

Enquêter et traiter les données

Le jeu de données par défaut ne contient que des entités numériques, car les entités d'origine ont été transformées à l'aide de Analyse en composantes principales (ACP) pour protéger la vie privée des utilisateurs. Par conséquent, le jeu de données contient 28 composants PCA, V1 à V28, et deux caractéristiques qui n'ont pas été transformées, Amount et Time. Le montant fait référence au montant de la transaction et le temps correspond aux secondes écoulées entre toute transaction dans les données et la première transaction.

La colonne Classe correspond au caractère frauduleux ou non d'une transaction.

Nous pouvons voir que la majorité est non frauduleuse, car sur un total de 284,807 492 exemples, seuls 0.173 (XNUMX %) sont frauduleux. Il s'agit d'un cas de déséquilibre de classe extrême, courant dans les scénarios de détection de fraude.

Nous préparons ensuite nos données pour le chargement et la formation. Nous avons divisé les données en un ensemble de train et un ensemble de test, en utilisant le premier pour former et le second pour évaluer les performances de notre modèle. Il est important de diviser les données avant d'appliquer des techniques pour atténuer le déséquilibre des classes. Sinon, nous pourrions divulguer des informations du jeu de test dans le train et nuire aux performances du modèle.

Si vous souhaitez apporter vos propres données d'entraînement, assurez-vous qu'il s'agit de données tabulaires au format CSV, téléchargez les données sur un Service de stockage simple Amazon (Amazon S3) et modifiez le chemin d'accès à l'objet S3 dans le code du bloc-notes.

Si vos données incluent des colonnes catégorielles avec des valeurs non numériques, vous devez encoder ces valeurs à chaud (en utilisant, par exemple, OneHotEncoder de sklearn) car l'algorithme XGBoost ne prend en charge que les données numériques.

Entraîner un modèle de forêt de coupe aléatoire non supervisé

Dans un scénario de détection de fraude, nous avons généralement très peu d'exemples étiquetés, et l'étiquetage de la fraude peut prendre beaucoup de temps et d'efforts. Par conséquent, nous souhaitons également extraire des informations des données non étiquetées disponibles. Pour ce faire, nous utilisons un algorithme de détection d'anomalies, tirant parti du déséquilibre élevé des données qui est courant dans les ensembles de données de détection de fraude.

La détection d'anomalies est une forme d'apprentissage non supervisé dans laquelle nous essayons d'identifier des exemples anormaux en nous basant uniquement sur leurs caractéristiques. Random Cut Forest est un algorithme de détection d'anomalies de pointe qui est à la fois précis et évolutif. A chaque exemple de données, RCF associe un score d'anomalie.

Nous utilisons l'algorithme RCF intégré de SageMaker pour former un modèle de détection d'anomalies sur notre jeu de données de formation, puis faire des prédictions sur notre jeu de données de test.

Tout d'abord, nous examinons et traçons séparément les scores d'anomalie prédits pour les exemples positifs (frauduleux) et négatifs (non frauduleux), car les nombres d'exemples positifs et négatifs diffèrent considérablement. Nous nous attendons à ce que les exemples positifs (frauduleux) aient des scores d'anomalie relativement élevés, et que les exemples négatifs (non frauduleux) aient des scores d'anomalie faibles. À partir des histogrammes, nous pouvons voir les modèles suivants :

• Près de la moitié des exemples positifs (histogramme de gauche) ont des scores d'anomalie supérieurs à 0.9, tandis que la plupart des exemples négatifs (histogramme de droite) ont des scores d'anomalie inférieurs à 0.85.
• L'algorithme d'apprentissage non supervisé RCF a des limites pour identifier avec précision les exemples frauduleux et non frauduleux. C'est parce qu'aucune information d'étiquette n'est utilisée. Nous résolvons ce problème en collectant des informations sur les étiquettes et en utilisant un algorithme d'apprentissage supervisé dans les étapes ultérieures.

Ensuite, nous supposons un scénario plus réel dans lequel nous classons chaque exemple de test comme positif (frauduleux) ou négatif (non frauduleux) en fonction de son score d'anomalie. Nous traçons l'histogramme des scores pour tous les exemples de test comme suit, en choisissant un score seuil de 1.0 (basé sur le modèle indiqué dans l'histogramme) pour la classification. Plus précisément, si le score d'anomalie d'un exemple est inférieur ou égal à 1.0, il est classé comme négatif (non frauduleux). Sinon, l'exemple est classé comme positif (frauduleux).

Enfin, nous comparons le résultat de la classification avec les étiquettes de vérité terrain et calculons les métriques d'évaluation. Parce que notre ensemble de données est déséquilibré, nous utilisons les métriques d'évaluation précision équilibrée, Score Kappa de Cohen, Score F1et AUC ROC, car ils tiennent compte de la fréquence de chaque classe dans les données. Pour toutes ces métriques, une valeur plus élevée indique une meilleure performance prédictive. Notez que dans cette étape, nous ne pouvons pas encore calculer le ROC AUC, car il n'y a pas de probabilité estimée pour les classes positives et négatives du modèle RCF sur chaque exemple. Nous calculons cette métrique dans les étapes ultérieures à l'aide d'algorithmes d'apprentissage supervisé.

.	RCF
Précision équilibrée	0.560023
Kappa de Cohen	0.003917
F1	0.007082
AUC ROC	-

À partir de cette étape, nous pouvons voir que le modèle non supervisé peut déjà réaliser une certaine séparation entre les classes, avec des scores d'anomalies plus élevés corrélés avec des exemples frauduleux.

Former un modèle XGBoost avec le schéma de pondération intégré

Une fois que nous avons rassemblé une quantité adéquate de données d'entraînement étiquetées, nous pouvons utiliser un algorithme d'apprentissage supervisé pour découvrir les relations entre les fonctionnalités et les classes. Nous avons choisi l'algorithme XGBoost car il a fait ses preuves, est hautement évolutif et peut traiter les données manquantes. Nous devons gérer le déséquilibre des données cette fois, sinon la classe majoritaire (les exemples non frauduleux ou négatifs) dominera l'apprentissage.

Nous formons et déployons notre premier modèle supervisé à l'aide du conteneur d'algorithme XGBoost intégré à SageMaker. C'est notre modèle de base. Pour gérer le déséquilibre des données, nous utilisons l'hyperparamètre scale_pos_weight, qui met à l'échelle les poids des exemples de classe positifs par rapport aux exemples de classe négatifs. Étant donné que l'ensemble de données est fortement asymétrique, nous définissons cet hyperparamètre sur une valeur prudente : sqrt(num_nonfraud/num_fraud).

Nous formons et déployons le modèle comme suit :

1. Récupérez l'URI du conteneur SageMaker XGBoost.
2. Définissez les hyperparamètres que nous voulons utiliser pour la formation du modèle, y compris celui que nous avons mentionné qui gère le déséquilibre des données, scale_pos_weight.
3. Créez un estimateur XGBoost et entraînez-le avec notre ensemble de données d'entraînement.
4. Déployez le modèle XGBoost formé sur un point de terminaison géré par SageMaker.
5. Évaluez ce modèle de base avec notre ensemble de données de test.

Ensuite, nous évaluons notre modèle avec les quatre mêmes métriques que celles mentionnées à la dernière étape. Cette fois, nous pouvons également calculer la métrique ROC AUC.

.	RCF	XGBoost
Précision équilibrée	0.560023	0.847685
Kappa de Cohen	0.003917	0.743801
F1	0.007082	0.744186
AUC ROC	-	0.983515

On peut voir qu'une méthode d'apprentissage supervisé XGBoost avec le schéma de pondération (utilisant l'hyperparamètre scale_pos_weight) atteint des performances significativement meilleures que la méthode d'apprentissage non supervisée RCF. Cependant, il reste encore de la place pour améliorer les performances. En particulier, relever le score Kappa de Cohen au-dessus de 0.8 serait généralement très favorable.

Outre les métriques à valeur unique, il est également utile d'examiner les métriques qui indiquent les performances par classe. Par exemple, la matrice de confusion, la précision par classe, le rappel et le score F1 peuvent fournir plus d'informations sur les performances de notre modèle.

.	avec précision	rappeler	score f1	Support
non-fraude	1.00	1.00	1.00	28435
fraude	0.80	0.70	0.74	46

Continuez à envoyer du trafic de test au point de terminaison via Lambda

Pour montrer comment utiliser nos modèles dans un système de production, nous avons construit une API REST avec Passerelle d'API Amazon et une fonction Lambda. Lorsque les applications clientes envoient des demandes d'inférence HTTP à l'API REST, ce qui déclenche la fonction Lambda, qui à son tour appelle les points de terminaison des modèles RCF et XGBoost et renvoie les prédictions des modèles. Vous pouvez lire le code de la fonction Lambda et surveiller les appels sur la console Lambda.

Nous avons également créé un script Python qui envoie des requêtes d'inférence HTTP à l'API REST, avec nos données de test comme données d'entrée. Pour voir comment cela a été fait, vérifiez le generate_endpoint_traffic.py fichier dans le code source de la solution. Les sorties de prédiction sont enregistrées dans un compartiment S3 via un Firehose de données Amazon Kinesis flux de livraison. Vous pouvez trouver le nom du compartiment S3 de destination sur la console Kinesis Data Firehose et vérifier les résultats de prédiction dans le compartiment S3.

Entraînez un modèle XGBoost avec la technique de suréchantillonnage SMOTE

Maintenant que nous avons un modèle de référence utilisant XGBoost, nous pouvons voir si les techniques d'échantillonnage conçues spécifiquement pour les problèmes de déséquilibre peuvent améliorer les performances du modèle. Nous utilisons Suréchantillonnage minoritaire sythétique (SMOTE), qui suréchantillonne la classe minoritaire en interpolant de nouveaux points de données entre ceux existants.

Les étapes sont les suivantes:

1. Utilisez SMOTE pour suréchantillonner la classe minoritaire (la classe frauduleuse) de notre ensemble de données de train. SMOTE suréchantillonne la classe minoritaire d'environ 0.17 à 50 %. Notez qu'il s'agit d'un cas de suréchantillonnage extrême de la classe minoritaire. Une alternative serait d'utiliser un rapport de rééchantillonnage plus petit, comme avoir un échantillon de classe minoritaire pour chaque sqrt(non_fraud/fraud) échantillon majoritaire ou en utilisant des techniques de rééchantillonnage plus avancées. Pour plus d'options de suréchantillonnage, reportez-vous à Comparer les échantillonneurs de suréchantillonnage.
2. Définissez les hyperparamètres pour la formation du deuxième XGBoost afin que scale_pos_weight soit supprimé et que les autres hyperparamètres restent les mêmes que lors de la formation du modèle XGBoost de base. Nous n'avons plus besoin de gérer le déséquilibre des données avec cet hyperparamètre, car nous l'avons déjà fait avec SMOTE.
3. Entraînez le deuxième modèle XGBoost avec les nouveaux hyperparamètres sur l'ensemble de données de train traité par SMOTE.
4. Déployez le nouveau modèle XGBoost sur un terminal géré par SageMaker.
5. Évaluez le nouveau modèle avec l'ensemble de données de test.

Lors de l'évaluation du nouveau modèle, nous pouvons voir qu'avec SMOTE, XGBoost atteint une meilleure performance sur la précision équilibrée, mais pas sur les scores Kappa et F1 de Cohen. La raison en est que SMOTE a tellement suréchantillonné la classe de fraude qu'il a augmenté son chevauchement dans l'espace des fonctionnalités avec les cas non frauduleux. Étant donné que le Kappa de Cohen accorde plus de poids aux faux positifs que la précision équilibrée, la métrique chute considérablement, tout comme la précision et le score F1 pour les cas de fraude.

.	RCF	XGBoost	XGBoost SMOTE
Précision équilibrée	0.560023	0.847685	0.912657
Kappa de Cohen	0.003917	0.743801	0.716463
F1	0.007082	0.744186	0.716981
AUC ROC	-	0.983515	0.967497

Cependant, nous pouvons rétablir l'équilibre entre les métriques en ajustant le seuil de classification. Jusqu'à présent, nous avons utilisé 0.5 comme seuil pour indiquer si un point de données est frauduleux ou non. Après avoir expérimenté différents seuils de 0.1 à 0.9, nous pouvons voir que le Kappa de Cohen continue d'augmenter avec le seuil, sans perte significative de précision équilibrée.

Cela ajoute une calibration utile à notre modèle. Nous pouvons utiliser un seuil bas si notre priorité est de ne manquer aucun cas frauduleux (faux négatifs), ou nous pouvons augmenter le seuil pour minimiser le nombre de faux positifs.

Former un modèle XGBoost optimal avec HPO

Dans cette étape, nous montrons comment améliorer les performances du modèle en entraînant notre troisième modèle XGBoost avec l'optimisation des hyperparamètres. Lors de la création de systèmes ML complexes, l'exploration manuelle de toutes les combinaisons possibles de valeurs d'hyperparamètres n'est pas pratique. La fonction HPO de SageMaker peut accélérer votre productivité en essayant de nombreuses variantes d'un modèle en votre nom. Il recherche automatiquement le meilleur modèle en se concentrant sur les combinaisons les plus prometteuses de valeurs d'hyperparamètres dans les plages que vous spécifiez.

Le processus HPO a besoin d'un ensemble de données de validation, nous avons donc d'abord divisé nos données de formation en ensembles de données de formation et de validation à l'aide échantillonnage stratifié. Pour résoudre le problème de déséquilibre des données, nous utilisons à nouveau le schéma de pondération de XGBoost, en définissant le scale_pos_weight hyperparamètre à sqrt(num_nonfraud/num_fraud).

Nous créons un estimateur XGBoost à l'aide du conteneur d'algorithme XGBoost intégré à SageMaker et spécifions la métrique d'évaluation objective et les plages d'hyperparamètres dans lesquelles nous aimerions expérimenter. Avec ceux-ci, nous créons ensuite un HyperparameterTuner et lancez le travail de réglage HPO, qui entraîne plusieurs modèles en parallèle, à la recherche de combinaisons optimales d'hyperparamètres.

Lorsque la tâche de réglage est terminée, nous pouvons voir son rapport d'analyse et inspecter les hyperparamètres de chaque modèle, les informations sur la tâche de formation et ses performances par rapport à la métrique d'évaluation objective.

Ensuite, nous déployons le meilleur modèle et l'évaluons avec notre ensemble de données de test.

Évaluer et comparer toutes les performances du modèle sur les mêmes données de test

Nous avons maintenant les résultats d'évaluation des quatre modèles : RCF, XGBoost baseline, XGBoost avec SMOTE et XGBoost avec HPO. Comparons leurs performances.

.	RCF	XGBoost	XGBoost avec SMOTE	XGBoost avec HPO
Précision équilibrée	0.560023	0.847685	0.912657	0.902156
Kappa de Cohen	0.003917	0.743801	0.716463	0.880778
F1	0.007082	0.744186	0.716981	0.880952
AUC ROC	-	0.983515	0.967497	0.981564

Nous pouvons voir que XGBoost avec HPO atteint des performances encore meilleures qu'avec la méthode SMOTE. En particulier, les scores Kappa de Cohen et F1 sont supérieurs à 0.8, indiquant une performance optimale du modèle.

Nettoyer

Lorsque vous avez terminé avec cette solution, assurez-vous de supprimer toutes les ressources AWS indésirables pour éviter d'encourir des frais imprévus. Dans le Supprimer la solution section sur l'onglet de votre solution, choisissez Supprimer toutes les ressources pour supprimer les ressources créées automatiquement lors du lancement de cette solution.

Alternativement, vous pouvez utiliser AWS CloudFormation pour supprimer toutes les ressources standard créées automatiquement par la solution et le notebook. Pour utiliser cette approche, sur la console AWS CloudFormation, recherchez la pile CloudFormation dont la description contient fraud-detection-using-machine-learning et supprimez-la. Il s'agit d'une pile parent, et choisir de supprimer cette pile supprimera automatiquement les piles imbriquées.

Quelle que soit l'approche, vous devez toujours supprimer manuellement toutes les ressources supplémentaires que vous avez éventuellement créées dans ce bloc-notes. Certains exemples incluent des compartiments S3 supplémentaires (en plus du compartiment par défaut de la solution), des points de terminaison SageMaker supplémentaires (utilisant un nom personnalisé) et des Registre des conteneurs élastiques Amazon (Amazon ECR).

Conclusion

Dans cet article, nous vous avons montré comment créer le noyau d'un système de détection de fraude par carte de crédit dynamique, auto-amélioré et maintenable à l'aide de ML avec SageMaker. Nous avons construit, formé et déployé un modèle de détection d'anomalies RCF non supervisé, un modèle XGBoost supervisé comme référence, un autre modèle XGBoost supervisé avec SMOTE pour résoudre le problème de déséquilibre des données et un modèle XGBoost final optimisé avec HPO. Nous avons discuté de la manière de gérer le déséquilibre des données et d'utiliser vos propres données dans la solution. Nous avons également inclus un exemple d'implémentation d'API REST avec API Gateway et Lambda pour montrer comment utiliser le système dans votre infrastructure d'entreprise existante.

Pour l'essayer vous-même, ouvrez Studio SageMaker et lancez la solution JumpStart. Pour en savoir plus sur la solution, consultez son GitHub référentiel.

---

À propos des auteurs

Xiaoli Shen est un architecte de solutions et un membre de la communauté technique de terrain d'apprentissage automatique (TFC) chez Amazon Web Services. Elle s'attache à aider les clients à créer une architecture sur le cloud et à tirer parti des services AWS pour en tirer une valeur commerciale. Avant de rejoindre AWS, elle était responsable technique et ingénieur senior full-stack, créant des systèmes distribués gourmands en données sur le cloud.

Dr Xin Huang est un scientifique appliqué pour Amazon SageMaker JumpStart et les algorithmes intégrés d'Amazon SageMaker. Il se concentre sur le développement d'algorithmes d'apprentissage automatique évolutifs. Ses intérêts de recherche portent sur le traitement du langage naturel, l'apprentissage en profondeur explicable sur des données tabulaires et l'analyse robuste du clustering spatio-temporel non paramétrique. Il a publié de nombreux articles dans les conférences ACL, ICDM, KDD et Royal Statistical Society: Series A journal.

Vedant Jaïn est un architecte de solutions spécialiste principal en IA/ML, qui aide les clients à tirer parti de l'écosystème d'apprentissage automatique d'AWS. Avant de rejoindre AWS, Vedant a occupé des postes de spécialité ML/Data Science dans diverses sociétés telles que Databricks, Hortonworks (maintenant Cloudera) et JP Morgan Chase. En dehors de son travail, Vedant est passionné par la musique, utilise la science pour mener une vie pleine de sens et explore la délicieuse cuisine végétarienne du monde entier.