Opdag svigagtige transaktioner ved hjælp af maskinlæring med Amazon SageMaker

Virksomheder kan miste milliarder af dollars hvert år på grund af ondsindede brugere og svigagtige transaktioner. Efterhånden som flere og flere forretningsaktiviteter bevæger sig online, er svindel og misbrug i onlinesystemer også stigende. For at bekæmpe onlinesvig har mange virksomheder brugt regelbaserede svindeldetekteringssystemer.

Traditionelle systemer til opdagelse af svindel er dog afhængige af et sæt regler og filtre, der er håndlavet af menneskelige specialister. Filtrene kan ofte være skøre, og reglerne fanger muligvis ikke hele spektret af svigagtige signaler. Desuden, mens svigagtig adfærd er i konstant udvikling, gør den statiske karakter af foruddefinerede regler og filtre det vanskeligt at vedligeholde og forbedre traditionelle svindeldetektionssystemer effektivt.

I dette indlæg viser vi dig, hvordan du opbygger et dynamisk, selvforbedrende og vedligeholdeligt system til registrering af kreditkortsvindel med maskinlæring (ML) vha. Amazon SageMaker.

Alternativt, hvis du leder efter en fuldt administreret service til at bygge skræddersyede modeller for registrering af svindel uden at skrive kode, anbefaler vi at tjekke ud Amazon svindeldetektor. Amazon Fraud Detector gør det muligt for kunder uden ML-erfaring at automatisere opbygning af svindeldetektionsmodeller, der er skræddersyet til deres data, ved at udnytte mere end 20 års ekspertise i bedrageridetektering fra AWS og Amazon.com.

Løsningsoversigt

Denne løsning bygger kernen i et system til registrering af kreditkortsvindel ved hjælp af SageMaker. Vi starter med at træne en uovervåget anomalidetektionsmodel ved hjælp af algoritmen Random Cut Forest (RCF). Derefter træner vi to overvågede klassifikationsmodeller ved hjælp af algoritmen XGBoost, den ene som en basismodel og den anden til at lave forudsigelser ved at bruge forskellige strategier til at adressere den ekstreme klasseubalance i data. Til sidst træner vi en optimal XGBoost model med hyperparameter optimering (HPO) for yderligere at forbedre modellens ydeevne.

Til prøvedatasættet bruger vi de offentlige, anonymiserede kreditkorttransaktioner datasæt der oprindeligt blev udgivet som en del af en forskning samarbejde mellem Worldline og Machine Learning Group af ULB (Université Libre de Bruxelles). I gennemgangen diskuterer vi også, hvordan du kan tilpasse løsningen til at bruge dine egne data.

Løsningens output er som følger:

• En uden opsyn SageMaker RCF model. Modellen udsender en anomali-score for hver transaktion. En lav scoreværdi indikerer, at transaktionen betragtes som normal (ikke-svigagtig). En høj værdi indikerer, at transaktionen er svigagtig. Definitionerne af lav og høj afhænger af applikationen, men almindelig praksis tyder på, at score ud over tre standardafvigelser fra gennemsnitsscoren betragtes som unormale.
• En overvåget SageMaker XGBoost model trænet ved hjælp af dets indbyggede vægtningsskema til at løse det meget ubalancerede dataproblem.
• En overvåget SageMaker XGBoost-model trænet ved hjælp af Syntetisk minoritetsoverprøvetagningsteknik (SMOTE).
• En trænet SageMaker XGBoost-model med HPO.
• Forudsigelser af sandsynligheden for, at hver transaktion er svigagtig. Hvis den estimerede sandsynlighed for en transaktion er over en tærskel, er den klassificeret som svigagtig.

For at demonstrere, hvordan du kan bruge denne løsning i din eksisterende virksomhedsinfrastruktur, inkluderer vi også et eksempel på at foretage REST API-kald til det implementerede modelslutpunkt, vha. AWS Lambda at udløse både RCF- og XGBoost-modellerne.

Følgende diagram illustrerer løsningsarkitekturen.

Forudsætninger

For at prøve løsningen på din egen konto skal du sørge for, at du har følgende på plads:

Når Studio-instansen er klar, kan du starte Studio og få adgang til JumpStart. JumpStart-løsninger er ikke tilgængelige i SageMaker notebook-forekomster, og du kan ikke få adgang til dem via SageMaker API'er eller AWS kommandolinjegrænseflade (AWS CLI).

Start løsningen

Udfør følgende trin for at starte løsningen:

1. Åbn JumpStart ved at bruge JumpStart launcher i Kom i gang sektion eller ved at vælge JumpStart-ikonet i venstre sidebjælke.
2. Under Løsninger, vælg Opdag ondsindede brugere og transaktioner for at åbne løsningen i en anden Studio-fane.
   
3. Vælg på løsningsfanen Launch at lancere løsningen.
   
   Løsningsressourcerne klargøres, og en anden fane åbnes, der viser implementeringsforløbet. Når implementeringen er afsluttet, vil en Åbn Notesbog knappen vises.
4. Vælg Åbn Notesbog for at åbne løsningsnotesbogen i Studio.
   

Undersøg og bearbejd dataene

Standarddatasættet indeholder kun numeriske funktioner, fordi de originale funktioner er blevet transformeret vha Principal Component Analysis (PCA) for at beskytte brugernes privatliv. Som følge heraf indeholder datasættet 28 PCA-komponenter, V1–V28, og to funktioner, der ikke er blevet transformeret, mængde og tid. Beløb refererer til transaktionsbeløbet, og Tid er de sekunder, der er forløbet mellem enhver transaktion i dataene og den første transaktion.

Klassekolonnen svarer til, om en transaktion er svigagtig eller ej.

Vi kan se, at størstedelen er ikke-svigagtig, for ud af de i alt 284,807 eksempler er kun 492 (0.173%) bedrageriske. Dette er et tilfælde af ekstrem klasseubalance, hvilket er almindeligt i scenarier for opdagelse af svindel.

Derefter forbereder vi vores data til indlæsning og træning. Vi opdeler dataene i et togsæt og et testsæt, hvor vi bruger førstnævnte til at træne og sidstnævnte til at evaluere vores models ydeevne. Det er vigtigt at opdele dataene, før du anvender nogen teknikker til at afhjælpe klasseubalancen. Ellers kan vi lække information fra testsættet ind i togsættet og skade modellens ydeevne.

Hvis du vil medbringe dine egne træningsdata, så sørg for at det er tabeldata i CSV-format, upload dataene til en Amazon Simple Storage Service (Amazon S3) bucket, og rediger S3-objektstien i notebook-koden.

Hvis dine data inkluderer kategoriske kolonner med ikke-numeriske værdier, skal du én-hot-indkode disse værdier (ved at bruge f.eks. sklearns OneHotEncoder), fordi XGBoost-algoritmen kun understøtter numeriske data.

Træn en uovervåget Random Cut Forest-model

I et scenarie for opdagelse af svindel har vi normalt meget få mærkede eksempler, og mærkningssvig kan tage meget tid og kræfter. Derfor ønsker vi også at udtrække information fra de umærkede data. Vi gør dette ved hjælp af en anomalidetektionsalgoritme, der drager fordel af den høje dataubalance, der er almindelig i datasæt til registrering af svindel.

Anomalidetektion er en form for uovervåget læring, hvor vi forsøger at identificere unormale eksempler udelukkende baseret på deres egenskaber. Random Cut Forest er en avanceret anomalidetektionsalgoritme, der er både nøjagtig og skalerbar. Med hvert dataeksempel knytter RCF en anomali-score.

Vi bruger den indbyggede SageMaker RCF-algoritme til at træne en anomalidetektionsmodel på vores træningsdatasæt og derefter lave forudsigelser på vores testdatasæt.

Først undersøger og plotter vi de forudsagte anomali-scores for positive (svigagtige) og negative (ikke-svigagtige) eksempler separat, fordi antallet af positive og negative eksempler adskiller sig væsentligt. Vi forventer, at de positive (svigagtige) eksempler har relativt høje anomali-scores, og de negative (ikke-svigagtige) har lave anomali-scores. Fra histogrammerne kan vi se følgende mønstre:

• Næsten halvdelen af ​​de positive eksempler (venstre histogram) har anomali-score højere end 0.9, mens de fleste af de negative eksempler (højre histogram) har anomali-score lavere end 0.85.
• Den uovervågede læringsalgoritme RCF har begrænsninger til at identificere svigagtige og ikke-svigagtige eksempler nøjagtigt. Dette skyldes, at der ikke bruges etiketoplysninger. Vi løser dette problem ved at indsamle etiketoplysninger og bruge en overvåget læringsalgoritme i senere trin.

Derefter antager vi et mere virkeligt scenarie, hvor vi klassificerer hvert testeksempel som enten positivt (svigagtigt) eller negativt (ikke-svigagtigt) baseret på dets anomali-score. Vi plotter scorehistogrammet for alle testeksempler som følger, idet vi vælger en cutoff-score på 1.0 (baseret på mønsteret vist i histogrammet) til klassificering. Specifikt, hvis et eksempels anomali-score er mindre end eller lig med 1.0, klassificeres det som negativt (ikke-svigagtigt). Ellers klassificeres eksemplet som positivt (svigagtigt).

Til sidst sammenligner vi klassificeringsresultatet med jordsandhedsmærkerne og beregner evalueringsmetrikkene. Fordi vores datasæt er ubalanceret, bruger vi evalueringsmetrikkene afbalanceret nøjagtighed, Cohens Kappa-score, f1 scoreog ROC AUC, fordi de tager højde for hyppigheden af ​​hver klasse i dataene. For alle disse metrics indikerer en større værdi en bedre prædiktiv ydeevne. Bemærk, at vi i dette trin ikke kan beregne ROC AUC endnu, fordi der ikke er nogen estimeret sandsynlighed for positive og negative klasser fra RCF-modellen på hvert eksempel. Vi beregner denne metrik i senere trin ved hjælp af overvågede læringsalgoritmer.

.	RCF
Afbalanceret nøjagtighed	0.560023
Cohens Kappa	0.003917
F1	0.007082
ROC AUC	-

Fra dette trin kan vi se, at den uovervågede model allerede kan opnå en vis adskillelse mellem klasserne, med højere anomali-score korreleret med svigagtige eksempler.

Træn en XGBoost-model med det indbyggede vægtningsskema

Efter at vi har indsamlet en tilstrækkelig mængde mærkede træningsdata, kan vi bruge en overvåget læringsalgoritme til at opdage sammenhænge mellem funktionerne og klasserne. Vi vælger XGBoost-algoritmen, fordi den har en dokumenteret track record, er meget skalerbar og kan håndtere manglende data. Vi skal håndtere dataubalancen denne gang, ellers vil majoritetsklassen (de ikke-svigagtige eller negative eksempler) dominere læringen.

Vi træner og implementerer vores første overvågede model ved hjælp af SageMaker indbyggede XGBoost-algoritmecontainer. Dette er vores basismodel. For at håndtere dataubalancen bruger vi hyperparameteren scale_pos_weight, som skalerer vægtene af de positive klasseeksempler mod de negative klasseeksempler. Fordi datasættet er meget skævt, sætter vi denne hyperparameter til en konservativ værdi: sqrt(num_nonfraud/num_fraud).

Vi træner og implementerer modellen som følger:

1. Hent SageMaker XGBoost container-URI.
2. Indstil de hyperparametre, vi vil bruge til modeltræningen, inklusive den, vi nævnte, der håndterer dataubalance, scale_pos_weight.
3. Opret en XGBoost-estimator og træne den med vores togdatasæt.
4. Implementer den trænede XGBoost-model til et SageMaker-administreret slutpunkt.
5. Evaluer denne basismodel med vores testdatasæt.

Derefter evaluerer vi vores model med de samme fire metrics som nævnt i sidste trin. Denne gang kan vi også beregne ROC AUC-metrikken.

.	RCF	XGBoost
Afbalanceret nøjagtighed	0.560023	0.847685
Cohens Kappa	0.003917	0.743801
F1	0.007082	0.744186
ROC AUC	-	0.983515

Vi kan se, at en overvåget indlæringsmetode XGBoost med vægtningsskemaet (ved hjælp af hyperparameteren scale_pos_weight) opnår væsentlig bedre præstation end den uovervågede læringsmetode RCF. Der er dog stadig plads til at forbedre ydeevnen. Især vil det generelt være meget gunstigt at hæve Cohen's Kappa-score over 0.8.

Ud over målinger med enkeltværdier er det også nyttigt at se på målinger, der angiver ydeevne pr. klasse. For eksempel kan forvirringsmatricen, præcision pr. klasse, genkaldelse og F1-score give flere oplysninger om vores models ydeevne.

.	præcision	tilbagekaldelse	f1-score	support
ikke-svig	1.00	1.00	1.00	28435
bedrageri	0.80	0.70	0.74	46

Bliv ved med at sende testtrafik til slutpunktet via Lambda

For at demonstrere, hvordan man bruger vores modeller i et produktionssystem, byggede vi en REST API med Amazon API Gateway og en Lambda funktion. Når klientapplikationer sender HTTP-inferensanmodninger til REST API'et, hvilket udløser Lambda-funktionen, som igen kalder RCF- og XGBoost-modellens slutpunkter og returnerer forudsigelserne fra modellerne. Du kan læse Lambda-funktionskoden og overvåge opkaldene på Lambda-konsollen.

Vi har også oprettet et Python-script, der foretager HTTP-inferensanmodninger til REST API'et med vores testdata som inputdata. For at se, hvordan dette blev gjort, skal du tjekke generate_endpoint_traffic.py fil i løsningens kildekode. Forudsigelsesudgangene logges til en S3-bøtte gennem en Amazon Kinesis Data Firehose leveringsstrøm. Du kan finde destinationens S3-bøttenavn på Kinesis Data Firehose-konsollen og kontrollere forudsigelsesresultaterne i S3-bøtten.

Træn en XGBoost-model med oversampling-teknikken SMOTE

Nu hvor vi har en basismodel, der bruger XGBoost, kan vi se, om prøvetagningsteknikker, der er designet specifikt til ubalancerede problemer, kan forbedre modellens ydeevne. Vi bruger Syntetisk minoritet oversampling (SMOTE), som oversampler minoritetsklassen ved at interpolere nye datapunkter mellem eksisterende.

Trinnene er som følger:

1. Brug SMOTE til at oversample minoritetsklassen (den bedrageriske klasse) i vores togdatasæt. SMOTE oversampler minoritetsklassen fra omkring 0.17–50 %. Bemærk, at dette er et tilfælde af ekstrem oversampling af minoritetsklassen. Et alternativ ville være at bruge et mindre resampling-forhold, såsom at have én minoritetsklasseprøve for hver sqrt(non_fraud/fraud) majoritetsprøve eller ved at bruge mere avancerede resamplingteknikker. Se flere muligheder for oversampling Sammenlign over-sampling samplere.
2. Definer hyperparametrene for træning af den anden XGBoost, så scale_pos_weight fjernes, og de andre hyperparametre forbliver de samme, som når du træner baseline XGBoost-modellen. Vi behøver ikke længere håndtere dataubalance med denne hyperparameter, for det har vi allerede gjort med SMOTE.
3. Træn den anden XGBoost-model med de nye hyperparametre på det SMOTE-behandlede togdatasæt.
4. Implementer den nye XGBoost-model til et SageMaker-administreret slutpunkt.
5. Evaluer den nye model med testdatasættet.

Når vi evaluerer den nye model, kan vi se, at med SMOTE opnår XGBoost en bedre ydeevne på afbalanceret nøjagtighed, men ikke på Cohens Kappa- og F1-score. Årsagen til dette er, at SMOTE har oversamplet svindelklassen så meget, at den har øget dens overlapning i feature-plads med ikke-svigsager. Fordi Cohens Kappa lægger mere vægt på falske positiver, end balanceret nøjagtighed gør, falder metrikken betydeligt, ligesom præcisionen og F1-score for svindeltilfælde.

.	RCF	XGBoost	XGBoost SMOTE
Afbalanceret nøjagtighed	0.560023	0.847685	0.912657
Cohens Kappa	0.003917	0.743801	0.716463
F1	0.007082	0.744186	0.716981
ROC AUC	-	0.983515	0.967497

Vi kan dog bringe balancen mellem metrikker tilbage ved at justere klassifikationstærsklen. Hidtil har vi brugt 0.5 som tærskel for at markere, om et datapunkt er svigagtigt eller ej. Efter at have eksperimenteret med forskellige tærskler fra 0.1-0.9, kan vi se, at Cohens Kappa bliver ved med at stige sammen med tærsklen, uden et væsentligt tab i balanceret nøjagtighed.

Dette tilføjer en nyttig kalibrering til vores model. Vi kan bruge en lav tærskel, hvis det ikke er vores prioritet at gå glip af svigagtige sager (falske negativer), eller vi kan øge tærsklen for at minimere antallet af falske positive.

Træn en optimal XGBoost-model med HPO

I dette trin demonstrerer vi, hvordan man forbedrer modellens ydeevne ved at træne vores tredje XGBoost-model med hyperparameteroptimering. Når man bygger komplekse ML-systemer, er det upraktisk at udforske alle mulige kombinationer af hyperparameterværdier manuelt. HPO-funktionen i SageMaker kan fremskynde din produktivitet ved at prøve mange varianter af en model på dine vegne. Den leder automatisk efter den bedste model ved at fokusere på de mest lovende kombinationer af hyperparameterværdier inden for de områder, du angiver.

HPO-processen har brug for et valideringsdatasæt, så vi opdeler først vores træningsdata yderligere i trænings- og valideringsdatasæt vha. stratificeret prøveudtagning. For at tackle dataubalanceproblemet bruger vi XGBoosts vægtningsskema igen og indstiller scale_pos_weight hyperparameter til sqrt(num_nonfraud/num_fraud).

Vi opretter en XGBoost-estimator ved hjælp af SageMaker indbyggede XGBoost-algoritmebeholder og specificerer den objektive evalueringsmetrik og de hyperparameterområder, inden for hvilke vi gerne vil eksperimentere. Med disse skaber vi så en HyperparameterTuner og sætter gang i HPO-tuning-jobbet, som træner flere modeller parallelt og leder efter optimale hyperparameterkombinationer.

Når tuning-jobbet er fuldført, kan vi se dens analyserapport og inspicere hver models hyperparametre, træningsjoboplysninger og dens ydeevne i forhold til den objektive evalueringsmetrik.

Derefter implementerer vi den bedste model og evaluerer den med vores testdatasæt.

Evaluer og sammenlign al modelydelse på de samme testdata

Nu har vi evalueringsresultaterne fra alle fire modeller: RCF, XGBoost baseline, XGBoost med SMOTE og XGBoost med HPO. Lad os sammenligne deres præstationer.

.	RCF	XGBoost	XGBoost med SMOTE	XGBoost med HPO
Afbalanceret nøjagtighed	0.560023	0.847685	0.912657	0.902156
Cohens Kappa	0.003917	0.743801	0.716463	0.880778
F1	0.007082	0.744186	0.716981	0.880952
ROC AUC	-	0.983515	0.967497	0.981564

Vi kan se, at XGBoost med HPO opnår endnu bedre ydeevne end med SMOTE-metoden. Især Cohens Kappa-score og F1 er over 0.8, hvilket indikerer en optimal modelydelse.

Ryd op

Når du er færdig med denne løsning, skal du sørge for at slette alle uønskede AWS-ressourcer for at undgå at pådrage dig utilsigtede afgifter. I den Slet løsning sektion på din løsningsfane, skal du vælge Slet alle ressourcer for at slette ressourcer, der er oprettet automatisk, når denne løsning startes.

Alternativt kan du bruge AWS CloudFormation at slette alle standardressourcer, der er oprettet automatisk af løsningen og notesbogen. For at bruge denne tilgang skal du på AWS CloudFormation-konsollen finde CloudFormation-stakken, hvis beskrivelse indeholder fraud-detection-using-machine-learning, og slette den. Dette er en overordnet stak, og hvis du vælger at slette denne stak, slettes de indlejrede stakke automatisk.

Med begge fremgangsmåder skal du stadig manuelt slette eventuelle ekstra ressourcer, som du måtte have oprettet i denne notesbog. Nogle eksempler inkluderer ekstra S3 buckets (ud over løsningens standard bucket), ekstra SageMaker-slutpunkter (ved hjælp af et brugerdefineret navn) og ekstra Amazon Elastic Container Registry (Amazon ECR) depoter.

Konklusion

I dette indlæg viste vi dig, hvordan du opbygger kernen i et dynamisk, selvforbedrende og vedligeholdeligt system til registrering af kreditkortsvindel ved hjælp af ML med SageMaker. Vi byggede, trænede og implementerede en uovervåget RCF-anomalidetektionsmodel, en overvåget XGBoost-model som baseline, en anden overvåget XGBoost-model med SMOTE til at tackle dataubalanceproblemet og en endelig XGBoost-model optimeret med HPO. Vi diskuterede, hvordan du håndterer dataubalance og bruger dine egne data i løsningen. Vi inkluderede også et eksempel på REST API-implementering med API Gateway og Lambda for at demonstrere, hvordan du bruger systemet i din eksisterende virksomhedsinfrastruktur.

For at prøve det selv, skal du åbne SageMaker Studio og start JumpStart-løsningen. For at lære mere om løsningen, tjek dens GitHub repository.

---

Om forfatterne

Xiaoli Shen er medlem af Solutions Architect og Machine Learning Technical Field Community (TFC) hos Amazon Web Services. Hun har fokuseret på at hjælpe kunder med at bygge i skyen og udnytte AWS-tjenester til at opnå forretningsværdi. Før hun kom til AWS, var hun tech lead og senior full-stack ingeniør, der byggede dataintensive distribuerede systemer i skyen.

Dr. Xin Huang er en Applied Scientist for Amazon SageMaker JumpStart og Amazon SageMaker indbyggede algoritmer. Han fokuserer på at udvikle skalerbare maskinlæringsalgoritmer. Hans forskningsinteresser er inden for området naturlig sprogbehandling, forklarlig dyb læring på tabeldata og robust analyse af ikke-parametrisk rum-tid-klynger. Han har publiceret mange artikler i ACL, ICDM, KDD-konferencer og Royal Statistical Society: Series A journal.

Vedant Jain er en Sr. AI/ML Specialist Solutions Architect, der hjælper kunder med at få værdi ud af Machine Learning-økosystemet hos AWS. Inden han kom til AWS, har Vedant haft ML/Data Science Specialty-stillinger hos forskellige virksomheder såsom Databricks, Hortonworks (nu Cloudera) og JP Morgan Chase. Uden for sit arbejde brænder Vedant for at lave musik, bruge Science til at leve et meningsfuldt liv og udforske lækkert vegetarisk køkken fra hele verden.