Med væksten i adoptionen af onlineapplikationer og det stigende antal internetbrugere er digital svindel stigende år for år. Amazon svindeldetektor leverer en fuldt administreret service, der hjælper dig med bedre at identificere potentielt svigagtige onlineaktiviteter ved hjælp af avancerede maskinlæringsteknikker (ML) og mere end 20 års ekspertise i svigopdagelse fra Amazon.
For at hjælpe dig med at fange svindel hurtigere på tværs af flere tilfælde tilbyder Amazon Fraud Detector specifikke modeller med skræddersyede algoritmer, berigelser og funktionstransformationer. Modeluddannelsen er fuldautomatisk og problemfri, og du kan følge instruktionerne i brugervejledning eller beslægtet blogindlæg at komme i gang. Men med trænede modeller skal du beslutte, om modellen er klar til udrulning. Dette kræver en vis viden inden for ML, statistik og svindeldetektion, og det kan være nyttigt at kende nogle typiske tilgange.
Dette indlæg hjælper dig med at diagnosticere modellens ydeevne og vælge den rigtige model til implementering. Vi gennemgår de metrics, der leveres af Amazon Fraud Detector, hjælper dig med at diagnosticere potentielle problemer og giver forslag til forbedring af modellens ydeevne. Fremgangsmåderne er anvendelige til både Online Fraud Insights (OFI) og Transaction Fraud Insights (TFI) modelskabeloner.
Løsningsoversigt
Dette indlæg giver en ende-til-ende-proces til at diagnosticere din models ydeevne. Den introducerer først alle de modelmetrikker, der vises på Amazon Fraud Detector-konsollen, inklusive AUC, scorefordeling, forvirringsmatrix, ROC-kurve og modelvariabel betydning. Derefter præsenterer vi en tre-trins tilgang til at diagnosticere modellens ydeevne ved hjælp af forskellige metrics. Til sidst giver vi forslag til forbedring af modellens ydeevne for typiske problemer.
Forudsætninger
Før du dykker dybt ned i din Amazon Fraud Detector-model, skal du opfylde følgende forudsætninger:
- Opret en AWS-konto.
- Opret et hændelsesdatasæt til modeltræning.
- Upload dine data til Amazon Simple Storage Service (Amazon S3) eller indtag dine begivenhedsdata i Amazon Fraud Detector.
- Byg en Amazon Fraud Detector-model.
Fortolk modelmetrics
Når modeltræningen er afsluttet, evaluerer Amazon Fraud Detector din model ved hjælp af en del af de modelleringsdata, der ikke blev brugt i modeltræningen. Det returnerer evalueringsmetrikken på Modelversion side for den model. Disse målinger afspejler den modelydeevne, du kan forvente på rigtige data efter implementering til produktion.
Følgende skærmbillede viser eksempel på modelydeevne returneret af Amazon Fraud Detector. Du kan vælge forskellige tærskler for scorefordeling (venstre), og forvirringsmatricen (højre) opdateres i overensstemmelse hermed.
Du kan bruge følgende resultater til at kontrollere ydeevne og beslutte dig for strategiregler:
- AUC (areal under kurven) – Den overordnede ydeevne af denne model. En model med AUC på 0.50 er ikke bedre end en møntvending, fordi den repræsenterer tilfældige tilfældigheder, hvorimod en "perfekt" model vil have en score på 1.0. Jo højere AUC, jo bedre kan din model skelne mellem bedrageri og legitime.
- Scorefordeling – Et histogram over modelscorefordelinger, der antager en eksempelpopulation på 100,000 hændelser. Amazon Fraud Detector genererer modelscore mellem 0-1000, hvor jo lavere score, jo lavere svindelrisiko. Bedre adskillelse mellem legitime (grønne) og svindel (blå) befolkninger indikerer typisk en bedre model. For flere detaljer, se Modelscore.
- Forvirringsmatrix – En tabel, der beskriver modellens ydeevne for den valgte givne scoretærskel, inklusive sand positiv, sand negativ, falsk positiv, falsk negativ, sand positiv rate (TPR) og falsk positiv rate (FPR). Optællingen på bordet antager en eksempelpopulation på 100,0000 begivenheder. For flere detaljer, se Modelpræstationsmålinger.
- ROC (Receiver Operator Characteristic) kurve – Et plot, der illustrerer modellens diagnostiske evne, som vist på det følgende skærmbillede. Den plotter den sande positive rate som en funktion af falsk positiv rate over alle mulige modelscoretærskler. Se dette diagram ved at vælge Avancerede målinger. Hvis du har trænet flere versioner af én model, kan du vælge forskellige FPR-tærskler for at kontrollere ydeevneændringen.
- Model variabel betydning – Rangeringen af modelvariabler baseret på deres bidrag til den genererede model, som vist på det følgende skærmbillede. Modelvariablen med den højeste værdi er vigtigere for modellen end de andre modelvariabler i datasættet for den modelversion og er som standard angivet øverst. For flere detaljer, se Model variabel betydning.
Diagnostiser modellens ydeevne
Før du implementerer din model i produktion, bør du bruge de målinger, Amazon Fraud Detector returnerede til at forstå modellens ydeevne og diagnosticere de mulige problemer. De almindelige problemer med ML-modeller kan opdeles i to hovedkategorier: data-relaterede problemer og model-relaterede problemer. Amazon Fraud Detector har taget sig af de modelrelaterede problemer ved omhyggeligt at bruge validerings- og testsæt til at evaluere og tune din model på backend. Du kan udføre følgende trin for at validere, om din model er klar til implementering eller har mulige datarelaterede problemer:
- Tjek den overordnede modelydelse (AUC og scorefordeling).
- Gennemgå forretningskrav (forvirringsmatrix og tabel).
- Tjek vigtigheden af modellens variable.
Tjek overordnet modelydelse: AUC og scorefordeling
Mere præcis forudsigelse af fremtidige begivenheder er altid det primære mål for en forudsigelsesmodel. AUC, der returneres af Amazon Fraud Detector, beregnes på et korrekt samplet testsæt, der ikke bruges i træningen. Generelt anses en model med en AUC større end 0.9 for at være en god model.
Hvis du observerer en model med ydeevne mindre end 0.8, betyder det normalt, at modellen har plads til forbedringer (vi diskuterer almindelige problemer for lav modelydelse senere i dette indlæg). Bemærk, at definitionen af "god" præstation i høj grad afhænger af din virksomhed og basismodellen. Du kan stadig følge trinene i dette indlæg for at forbedre din Amazon Fraud Detector-model, selvom dens AUC er større end 0.8.
På den anden side, hvis AUC er over 0.99, betyder det, at modellen næsten perfekt kan adskille svindel og legitime hændelser på testsættet. Dette er nogle gange et "for godt til at være sandt"-scenarie (vi diskuterer almindelige problemer for meget høj modelydelse senere i dette indlæg).
Udover den overordnede AUC kan scorefordelingen også fortælle dig, hvor godt modellen er tilpasset. Ideelt set bør du se hovedparten af lovlig og svig placeret i de to ender af skalaen, hvilket indikerer, at modelresultatet nøjagtigt kan rangere begivenhederne på testsættet.
I det følgende eksempel har scorefordelingen en AUC på 0.96.
Hvis den legitime distribution og svigfordelingen overlappede eller koncentrerede sig i centrum, betyder det sandsynligvis, at modellen ikke klarer sig godt til at skelne svighændelser fra legitime hændelser, hvilket kan indikere, at historisk datafordeling er ændret, eller at du har brug for flere data eller funktioner.
Det følgende er et eksempel på scorefordeling med en AUC på 0.64.
Hvis du kan finde et splitpunkt, der næsten perfekt kan opdele svindel og legitime begivenheder, er der stor chance for, at modellen har et problem med etiketlækage, eller at svindelmønstrene er for nemme at opdage, hvilket burde fange din opmærksomhed.
I det følgende eksempel har scorefordelingen en AUC på 1.0.
Gennemgå forretningskrav: Forvirringsmatrix og tabel
Selvom AUC er en praktisk indikator for modellens ydeevne, kan den muligvis ikke direkte oversættes til dine forretningskrav. Amazon Fraud Detector giver også metrics såsom svindelfangstrate (sand positiv rate), procentdel af legitime hændelser, der er forkert forudsagt som svindel (falsk positiv rate) og mere, som er mere almindeligt brugt som forretningskrav. Når du har trænet en model med en rimelig god AUC, skal du sammenligne modellen med dit forretningskrav med disse målinger.
Forvirringsmatricen og tabellen giver dig en grænseflade til at gennemgå virkningen og kontrollere, om den opfylder dine forretningsbehov. Bemærk, at tallene afhænger af modeltærsklen, hvor hændelser med scorer større end tærskelværdien klassificeres som bedrageri, og hændelser med scores lavere end tærsklen klassificeres som lovlige. Du kan vælge, hvilken tærskel du vil bruge, afhængigt af dine forretningskrav.
For eksempel, hvis dit mål er at fange 73% af svindel, så (som vist i eksemplet nedenfor) kan du vælge en tærskel som 855, som giver dig mulighed for at fange 73% af al svindel. Modellen vil dog også fejlklassificere 3 % legitime begivenheder som svigagtige. Hvis denne FPR er acceptabel for din virksomhed, er modellen god til implementering. Ellers skal du forbedre modellens ydeevne.
Et andet eksempel er, hvis omkostningerne ved at blokere eller udfordre en legitim kunde er ekstremt høje, så ønsker du en lav FPR og høj præcision. I så fald kan du vælge en tærskel på 950, som vist i følgende eksempel, hvilket vil fejlklassificere 1 % af legitime kunder som bedrageri, og 80 % af identificeret bedrageri vil faktisk være svigagtigt.
Derudover kan du vælge flere tærskler og tildele forskellige resultater, såsom blokering, undersøgelse, beståelse. Hvis du ikke kan finde ordentlige tærskler og regler, der opfylder alle dine forretningskrav, bør du overveje at træne din model med flere data og attributter.
Tjek modelvariablens betydning
Model variabel betydning ruden viser, hvordan hver variabel bidrager til din model. Hvis en variabel har en væsentlig højere vigtighed end de andre, kan det tyde på lækage af etiketter, eller at svindelmønstrene er for lette at opdage. Bemærk, at variabelens betydning aggregeres tilbage til dine inputvariabler. Hvis du observerer lidt højere betydning af IP_ADDRESS
, CARD_BIN
, EMAIL_ADDRESS
, PHONE_NUMBER
, BILLING_ZIP
eller SHIPPING_ZIP
, måske på grund af berigelsens kraft.
Følgende eksempel viser modellens variable betydning med en potentiel etiketlækage ved hjælp af investigation_status
.
Betydning af modelvariabler giver dig også hints om, hvilke yderligere variabler der potentielt kan bringe løft til modellen. Hvis du f.eks. observerer lav AUC og sælgerrelaterede funktioner viser stor betydning, kan du overveje at indsamle flere ordrefunktioner som f.eks. SELLER_CATEGORY
, SELLER_ADDRESS
og SELLER_ACTIVE_YEARS
, og føj disse variable til din model.
Almindelige problemer for lav modelydelse
I dette afsnit diskuterer vi almindelige problemer, du kan støde på med hensyn til lav modelydelse.
Historisk datafordeling ændret
Historisk datadistributionsforskydning sker, når du har en stor virksomhedsændring eller et problem med dataindsamling. For eksempel, hvis du for nylig lancerede dit produkt på et nyt marked, IP_ADDRESS
, EMAIL
og ADDRESS
relaterede funktioner kan være helt anderledes, og svig modus operandi kan også ændre sig. Amazon Fraud Detector bruger EVENT_TIMESTAMP
at opdele data og evaluere din model på den relevante undergruppe af hændelser i dit datasæt. Hvis din historiske datafordeling ændres væsentligt, kan evalueringssættet være meget forskelligt fra træningsdataene, og den rapporterede modelydelse kan være lav.
Du kan kontrollere det potentielle problem med ændring af datadistribution ved at udforske dine historiske data:
- Brug Amazon Fraud Detector Data Profiler værktøj til at kontrollere, om svindelfrekvensen og den manglende sats for mærket ændrede sig over tid.
- Tjek, om den variable fordeling over tid ændrede sig væsentligt, især for funktioner med høj variabel betydning.
- Tjek variabelfordelingen over tid efter målvariable. Hvis du observerer væsentligt flere svindelhændelser fra én kategori i de seneste data, vil du måske tjekke, om ændringen er rimelig ved hjælp af dine forretningsmæssige vurderinger.
Hvis du finder ud af, at den manglende andel af etiketten er meget høj, eller at svindelprocenten konsekvent er faldet i løbet af de seneste datoer, kan det være en indikator for, at etiketter ikke er fuldt modne. Du bør ekskludere de seneste data eller vente længere med at indsamle de nøjagtige etiketter og derefter genoplære din model.
Hvis du observerer en kraftig stigning i svindelrate og variabler på bestemte datoer, vil du måske dobbelttjekke, om det er et afvigende eller dataindsamlingsproblem. I så fald bør du slette disse hændelser og genoptræne modellen.
Hvis du finder ud af, at de forældede data ikke kan repræsentere din nuværende og fremtidige forretning, bør du udelukke den gamle periode med data fra træning. Hvis du bruger lagrede begivenheder i Amazon Fraud Detector, kan du blot genoplære en ny version og vælge det korrekte datointerval, mens du konfigurerer træningsjobbet. Det kan også indikere, at svigmetoden i din virksomhed ændrer sig relativt hurtigt over tid. Efter modelimplementering skal du muligvis genoptræne din model ofte.
Forkert variabel type mapping
Amazon Fraud Detector beriger og transformerer data baseret på variabeltyperne. Det er vigtigt, at du kortlægger dine variabler til den korrekte type, så Amazon Fraud Detector-model kan tage den maksimale værdi af dine data. Hvis du for eksempel kortlægger IP
til CATEGORICAL
type i stedet for IP_ADDRESS
, du får ikke IP-
relaterede berigelser i backend.
Generelt foreslår Amazon Fraud Detector følgende handlinger:
- Map dine variabler til bestemte typer, som f.eks
IP_ADDRESS
,EMAIL_ADDRESS
,CARD_BIN
ogPHONE_NUMBER
, så Amazon Fraud Detector kan udtrække og berige yderligere information. - Hvis du ikke kan finde den specifikke variabeltype, skal du knytte den til en af de tre generiske typer:
NUMERIC
,CATEGORICAL
ellerFREE_FORM_TEXT
. - Hvis en variabel er i tekstform og har høj kardinalitet, såsom en kundeanmeldelse eller produktbeskrivelse, bør du kortlægge den til
FREE_FORM_TEXT
variabel type, så Amazon Fraud Detector udtrækker tekstfunktioner og indlejringer på backend for dig. Hvis du for eksempel kortlæggerurl_string
tilFREE_FORM_TEXT
, er den i stand til at tokenisere URL'en og udtrække information for at føres ind i downstream-modellen, hvilket vil hjælpe den med at lære flere skjulte mønstre fra URL'en.
Hvis du finder ud af, at nogen af dine variabeltyper er kortlagt forkert i variabelkonfigurationen, kan du ændre din variabeltype og derefter genoptræne modellen.
Utilstrækkelige data eller funktioner
Amazon Fraud Detector kræver mindst 10,000 poster for at træne en Online Fraud Insights (OFI) eller Transaction Fraud Insights (TFI) model, med mindst 400 af disse poster identificeret som svigagtige. TFI kræver også, at både svigagtige registreringer og legitime optegnelser kommer fra mindst 100 forskellige enheder hver for at sikre mangfoldigheden af datasættet. Derudover kræver Amazon Fraud Detector, at modelleringsdataene har mindst to variabler. Det er minimumsdatakravene for at bygge en nyttig Amazon Fraud Detector-model. Brug af flere registreringer og variabler hjælper dog normalt ML-modellerne med at lære de underliggende mønstre fra dine data bedre. Når du observerer en lav AUC eller ikke kan finde tærskler, der opfylder dine forretningskrav, bør du overveje at omskole din model med flere data eller tilføje nye funktioner til din model. Normalt finder vi EMAIL_ADDRESS
, IP
, PAYMENT_TYPE
, BILLING_ADDRESS
, SHIPPING_ADDRESS
og DEVICE
relaterede variabler er vigtige ved afsløring af svindel.
En anden mulig årsag er, at nogle af dine variabler indeholder for mange manglende værdier. For at se, om det sker, skal du kontrollere modeltræningsmeddelelserne og henvise til Fejlfind problemer med træningsdata for forslag.
Almindelige problemer for meget høj modelydelse
I dette afsnit diskuterer vi almindelige problemer relateret til meget høj modelydelse.
Etiketlækage
Etiketlækage opstår, når træningsdatasættene bruger information, som ikke forventes at være tilgængelig på forudsigelsestidspunktet. Den overvurderer modellens anvendelighed, når den køres i et produktionsmiljø.
Høj AUC (tæt på 1), perfekt adskilt scorefordeling og signifikant højere variabel betydning af én variabel kunne være indikatorer for potentielle problemer med etiketlækage. Du kan også kontrollere sammenhængen mellem funktionerne og etiketten ved hjælp af Data Profiler. Det Korrelation af egenskaber og etiketter plot viser sammenhængen mellem hver funktion og etiketten. Hvis en funktion har over 0.99 korrelation med etiketten, bør du kontrollere, om funktionen bruges korrekt baseret på forretningsmæssige vurderinger. For at opbygge en risikomodel for at godkende eller afslå en låneansøgning, bør du for eksempel ikke bruge funktioner som f.eks. AMOUNT_PAID
, fordi betalingerne sker efter tegningsprocessen. Hvis en variabel ikke er tilgængelig på det tidspunkt, du laver forudsigelse, bør du fjerne denne variabel fra modelkonfigurationen og genoptræne en ny model.
Følgende eksempel viser sammenhængen mellem hver variabel og etiket. investigation_status
har en høj korrelation (tæt på 1) med etiketten, så du bør dobbelttjekke, om der er et problem med etiketlækage.
Simple svindelmønstre
Når svindelmønstrene i dine data er enkle, kan du muligvis også observere meget høj modelydelse. Antag for eksempel, at alle svindelhændelser i modelleringsdataene kommer gennem den samme interne tjenesteudbyder; det er ligetil for modellen at vælge IP-
relaterede variabler og returnere en "perfekt" model med høj betydning af IP
.
Simple svindelmønstre indikerer ikke altid et dataproblem. Det kan være rigtigt, at svindel modus operandi i din virksomhed er let at fange. Men før du laver en konklusion, skal du sikre dig, at de etiketter, der bruges i modeltræning, er nøjagtige, og at modelleringsdataene dækker så mange svindelmønstre som muligt. For eksempel, hvis du mærker dine svindelhændelser baseret på regler, såsom at mærke alle applikationer fra en bestemt BILLING_ZIP
plus PRODUCT_CATEGORY
som svindel kan modellen nemt fange disse svindel ved at simulere reglerne og opnå en høj AUC.
Du kan kontrollere etiketfordelingen på tværs af forskellige kategorier eller beholdere for hver funktion ved hjælp af Data Profiler. For eksempel, hvis du observerer, at de fleste svindelhændelser kommer fra en eller nogle få produktkategorier, kan det være en indikator for simple svindelmønstre, og du skal bekræfte, at det ikke er en dataindsamlings- eller procesfejl. Hvis funktionen er som CUSTOMER_ID
, bør du udelukke funktionen i modeltræning.
Følgende eksempel viser etiketfordeling på tværs af forskellige kategorier af product_category
. Al svindel kommer fra to produktkategorier.
Forkert datasampling
Ukorrekt datasampling kan ske, når du samplede og kun sendte en del af dine data til Amazon Fraud Detector. Hvis dataene ikke er samplet korrekt og ikke er repræsentative for trafikken i produktionen, vil den rapporterede modelydeevne være unøjagtig, og modellen kan være ubrugelig til produktionsforudsigelse. For eksempel, hvis alle svindelhændelser i modelleringsdataene er samplet fra Asien, og alle legitime hændelser er samplet fra USA, kan modellen lære at adskille svig og legit baseret på BILLING_COUNTRY
. I så fald er modellen ikke generisk til at blive anvendt på andre populationer.
Normalt foreslår vi at sende alle de seneste begivenheder uden stikprøver. Baseret på datastørrelsen og svindelfrekvensen udfører Amazon Fraud Detector prøveudtagning før modeltræning for dig. Hvis dine data er for store (over 100 GB), og du beslutter dig for kun at sample og sende en delmængde, bør du stikprøve dine data tilfældigt og sikre dig, at stikprøven er repræsentativ for hele populationen. For TFI bør du stikprøve dine data efter enhed, hvilket betyder, at hvis en enhed er samplet, skal du inkludere hele dens historie, så enhedsniveauaggregaterne beregnes korrekt. Bemærk, at hvis du kun sender en delmængde af data til Amazon Fraud Detector, kan realtidsaggregaterne under inferens være unøjagtige, hvis de tidligere begivenheder for enhederne ikke sendes.
En anden ukorrekt datasampling kunne være kun at bruge en kort periode med data, f.eks. én dags data, til at bygge modellen. Dataene kan være partiske, især hvis din virksomheds- eller svindelangreb er sæsonbestemte. Vi anbefaler normalt at inkludere mindst to cyklusser (såsom 2 uger eller 2 måneder) af data i modelleringen for at sikre mangfoldigheden af svindeltyper.
Konklusion
Efter at have diagnosticeret og løst alle de potentielle problemer, bør du få en nyttig Amazon Fraud Detector-model og være sikker på dens ydeevne. Til næste trin, dig kan lave en detektor med modellen og dine forretningsregler, og vær klar til at implementere den til produktion til en skyggetilstandsevaluering.
Tillæg
Sådan udelukker du variabler til modeltræning
Efter det dybe dyk kan du muligvis identificere en variabel lækagemålinformation og ønsker at udelukke den fra modeltræning. Du kan genoptræne en modelversion, der ekskluderer de variabler, du ikke ønsker, ved at udføre følgende trin:
- På Amazon Fraud Detector-konsollen skal du i navigationsruden vælge Modeller.
- På Modeller side, skal du vælge den model, du vil genoptræne.
- På handlinger menu, vælg Træn ny version.
- Vælg det datointerval, du vil bruge, og vælg Næste.
- På Konfigurer træning side, skal du fravælge den variabel, du ikke vil bruge i modeltræning.
- Angiv dine svindeletiketter og legitime etiketter, og hvordan du vil have Amazon Fraud Detector til at bruge umærkede begivenheder, og vælg derefter Næste.
- Gennemgå modelkonfigurationen og vælg Opret og træne model.
Sådan ændres hændelsesvariabeltype
Variabler repræsenterer dataelementer, der bruges til forebyggelse af svindel. I Amazon Fraud Detector er alle variabler globale og deles på tværs af alle hændelser og modeller, hvilket betyder, at én variabel kan bruges i flere hændelser. For eksempel kan IP være forbundet med log-in-hændelser, og det kan også være forbundet med transaktionsbegivenheder. Naturligvis låste Amazon Fraud Detector variabeltypen og datatypen, når en variabel er oprettet. For at slette en eksisterende variabel skal du først slette alle tilknyttede hændelsestyper og modeller. Du kan kontrollere ressourcerne forbundet med den specifikke variabel ved at navigere til Amazon Fraud Detector, vælge Variabler i navigationsruden og vælge variabelnavnet og Tilknyttede ressourcer.
Slet variablen og alle tilknyttede hændelsestyper
For at slette variablen skal du udføre følgende trin:
- På Amazon Fraud Detector-konsollen skal du i navigationsruden vælge Variabler.
- Vælg den variabel, du vil slette.
- Vælg Tilknyttede ressourcer for at se en liste over alle de hændelsestyper, der er brugt i denne variabel.
Du skal slette de tilknyttede hændelsestyper, før du sletter variablen. - Vælg begivenhedstyperne på listen for at gå til den tilknyttede begivenhedstypeside.
- Vælg Gemte begivenheder for at kontrollere, om nogen data er gemt under denne hændelsestype.
- Hvis der er hændelser gemt i Amazon Fraud Detector, skal du vælge Slet gemte begivenheder for at slette de gemte begivenheder.
Når sletteopgaven er fuldført, vises meddelelsen "De lagrede hændelser for denne hændelsestype blev slettet". - Vælg Tilknyttede ressourcer.
Hvis detektorer og modeller er knyttet til denne hændelsestype, skal du først slette disse ressourcer. - Hvis detektorer er tilknyttet, skal du udføre følgende trin for at slette alle tilknyttede detektorer:
- Vælg detektoren for at gå til Detektor detaljer .
- I Modelversioner rude, vælg detektorens version.
- På detektorversionssiden skal du vælge handlinger.
- Hvis detektorversionen er aktiv, skal du vælge Deaktiver, vælg Deaktiver denne detektorversion uden at erstatte den med en anden version, og vælg Deaktiver detektorversion.
- Når detektorversionen er deaktiveret, skal du vælge handlinger og så Slette.
- Gentag disse trin for at slette alle detektorversioner.
- På Detektor detaljer side, vælg Tilknyttede regler.
- Vælg den regel, der skal slettes.
- Vælg handlinger , Slet regelversion.
- Indtast regelnavnet for at bekræfte og vælge Slet version.
- Gentag disse trin for at slette alle tilknyttede regler.
- Når alle detektorversioner og tilhørende regler er slettet, skal du gå til Detektor detaljer side, vælg handlinger, og vælg Slet detektor.
- Indtast detektorens navn og vælg Slet detektor.
- Gentag disse trin for at slette den næste detektor.
- Hvis nogen modeller er knyttet til hændelsestypen, skal du udføre følgende trin for at slette dem:
- Vælg navnet på modellen.
- I Modelversioner rude, vælg versionen.
- Hvis modelstatus er
Active
, vælg handlinger , Afinstaller modelversion. - Indtast
undeploy
for at bekræfte og vælge Afinstaller modelversion.
Status ændres tilUndeploying
. Processen tager et par minutter at fuldføre. - Efter status bliver
Ready to deploy
, vælg Handlinger og Slet. - Gentag disse trin for at slette alle modelversioner.
- På siden Modeldetaljer skal du vælge Handlinger og Slet model.
- Indtast navnet på modellen og vælg Slet model.
- Gentag disse trin for at slette den næste model.
- Når alle tilknyttede detektorer og modeller er slettet, skal du vælge handlinger , Slet begivenhedstype på den Begivenhedsdetaljer .
- Indtast navnet på begivenhedstypen og vælg Slet begivenhedstype.
- Vælg i navigationsruden Variabler, og vælg den variabel, du vil slette.
- Gentag de tidligere trin for at slette alle hændelsestyper, der er knyttet til variablen.
- På Variable detaljer side, vælg handlinger , Slet.
- Indtast navnet på variablen og vælg Slet variabel.
Opret en ny variabel med den korrekte variabeltype
Når du har slettet variablen og alle tilknyttede hændelsestyper, gemte hændelser, modeller og detektorer fra Amazon Fraud Detector, kan du oprette en ny variabel af samme navn og tilknytte den til den korrekte variabeltype.
- På Amazon Fraud Detector-konsollen skal du i navigationsruden vælge Variabler.
- Vælg Opret.
- Indtast det variabelnavn, du vil ændre (det, du slettede tidligere).
- Vælg den korrekte variabeltype, du vil ændre til.
- Vælg Opret variabel.
Upload data og genoptræn modellen
Når du har opdateret variabeltypen, kan du uploade dataene igen og træne en ny model. For instruktioner, se Opdag online transaktionsbedrageri med nye Amazon Fraud Detector-funktioner.
Sådan tilføjer du nye variabler til en eksisterende hændelsestype
For at tilføje nye variabler til den eksisterende hændelsestype skal du udføre følgende trin:
- Tilføj de nye variabler til den tidligere trænings-CVS-fil.
- Upload den nye træningsdatafil til en S3-spand. Bemærk Amazon S3-placeringen af din træningsfil (f.eks.
s3://bucketname/path/to/some/object.csv
) og dit rollenavn. - På Amazon Fraud Detector-konsollen skal du i navigationsruden vælge Begivenheder.
- På Begivenhedstyper side, skal du vælge navnet på den hændelsestype, du vil tilføje variabler.
- På Begivenhedstype detaljer side, vælg handlinger, derefter Tilføj variabler.
- Under Vælg, hvordan denne hændelses variabler skal defineres, vælg Vælg variabler fra et træningsdatasæt.
- For IAM-rolle skal du vælge en eksisterende IAM-rolle eller oprette en ny rolle for at få adgang til data i Amazon S3.
- Til Dataplacering, indtast S3-placeringen for den nye træningsfil og vælg upload.
De nye variabler, der ikke er til stede i den eksisterende hændelsestype, bør dukke op på listen.
- Vælg Tilføj variabler.
Nu er de nye variabler blevet tilføjet til den eksisterende hændelsestype. Hvis du bruger lagrede hændelser i Amazon Fraud Detector, mangler de nye variabler for de gemte hændelser stadig. Du skal importere træningsdataene med de nye variabler til Amazon Fraud Detector og derefter genoplære en ny modelversion. Når du uploader de nye træningsdata med samme EVENT_ID
, EVENT_TIMESTAMP
, overskriver de nye hændelsesvariable de tidligere hændelsesvariabler gemt i Amazon Fraud Detector.
Om forfatterne
Julia Xu er forsker med Amazon Fraud Detector. Hun brænder for at løse kundernes udfordringer ved hjælp af Machine Learning-teknikker. I sin fritid nyder hun at vandre, male og udforske nye kaffebarer.
Hao Zhou er forsker med Amazon Fraud Detector. Han har en PhD i elektroteknik fra Northwestern University, USA. Han brænder for at anvende maskinlæringsteknikker til at bekæmpe svindel og misbrug.
Abhishek Ravi er Senior Product Manager med Amazon Fraud Detector. Han brænder for at udnytte tekniske muligheder til at bygge produkter, der glæder kunder.
- Coinsmart. Europas bedste Bitcoin og Crypto Exchange.
- Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. FRI ADGANG.
- CryptoHawk. Altcoin radar. Gratis prøveversion.
- Kilde: https://aws.amazon.com/blogs/machine-learning/diagnose-model-performance-before-deployment-for-amazon-fraud-detector/
- "
- 000
- 10
- 100
- 20 år
- 9
- a
- evne
- Om
- adgang
- derfor
- Konto
- præcis
- tværs
- aktioner
- aktiv
- aktiviteter
- tilføjet
- Desuden
- Yderligere
- Vedtagelse
- fremskreden
- algoritmer
- Alle
- tillader
- altid
- Amazon
- anvendelig
- Anvendelse
- applikationer
- anvendt
- Anvendelse
- tilgang
- tilgange
- passende
- Godkend
- OMRÅDE
- asia
- forbundet
- opmærksomhed
- attributter
- Automatiseret
- til rådighed
- AWS
- Baseline
- fordi
- før
- jf. nedenstående
- Bedre
- mellem
- Bloker
- grænse
- bringe
- bygge
- virksomhed
- beregnet
- kapaciteter
- fange
- hvilken
- tilfælde
- tilfælde
- brydning
- Boligtype
- Årsag
- vis
- udfordringer
- udfordrende
- lave om
- Vælg
- klassificeret
- Kaffe
- Coin
- indsamler
- Indsamling
- samling
- bekæmpe
- Kom
- Fælles
- fuldføre
- fuldstændig
- færdiggøre
- sikker
- Konfiguration
- forvirring
- Overvej
- Konsol
- Praktisk
- kunne
- skabe
- oprettet
- Nuværende
- skøger
- kunde
- Kunder
- data
- Datoer
- dyb
- Afhængigt
- afhænger
- indsætte
- implementering
- implementering
- beskrivelse
- detaljer
- Detektion
- forskellige
- digital
- direkte
- diskutere
- displays
- fordeling
- Distributioner
- Mangfoldighed
- Er ikke
- droppet
- i løbet af
- hver
- nemt
- elementer
- ende til ende
- ender
- Engineering
- berige
- Indtast
- enheder
- enhed
- Miljø
- især
- evaluere
- evaluering
- begivenhed
- begivenheder
- eksempel
- Eksklusive
- eksisterende
- forvente
- forventet
- ekspertise
- Uddrag
- hurtigere
- Feature
- Funktionalitet
- Endelig
- Fornavn
- følger
- efter
- formular
- bedrageri
- Gratis
- fra
- funktion
- fremtiden
- Generelt
- genereret
- Global
- mål
- godt
- større
- Grøn
- Vækst
- ske
- hjælpe
- hjælpsom
- hjælper
- Høj
- højere
- stærkt
- historisk
- historie
- besidder
- Hvordan
- How To
- Men
- HTTPS
- identificere
- KIMOs Succeshistorier
- betydning
- vigtigt
- Forbedre
- omfatter
- Herunder
- angiver
- oplysninger
- indgang
- indsigt
- grænseflade
- Internet
- undersøge
- IP
- spørgsmål
- spørgsmål
- IT
- Job
- domme
- Kend
- viden
- etiket
- mærkning
- Etiketter
- stor
- større
- seneste
- lanceret
- lække
- LÆR
- læring
- Niveau
- løftestang
- Liste
- Børsnoterede
- placering
- låst
- maskine
- machine learning
- lave
- Making
- lykkedes
- leder
- kort
- Marked
- Matrix
- midler
- beskeder
- Metrics
- måske
- minimum
- ML
- model
- modeller
- måned
- mere
- mest
- flere
- navigering
- Navigation
- behov
- negativ
- Nye funktioner
- New Market
- næste
- nummer
- numre
- Tilbud
- online
- operatør
- ordrer
- Andet
- Ellers
- samlet
- del
- lidenskabelige
- betalinger
- procentdel
- ydeevne
- periode
- Punkt
- befolkning
- positiv
- mulig
- potentiale
- magt
- forudsigelse
- præsentere
- Forebyggelse
- tidligere
- primære
- problemer
- behandle
- Produkt
- produktion
- Produkter
- give
- forudsat
- udbyder
- giver
- hurtigt
- rækkevidde
- realtid
- rimelige
- nylige
- for nylig
- anbefaler
- optegnelser
- afspejler
- om
- repræsentere
- repræsentativt
- repræsenterer
- Krav
- Kræver
- forskning
- Ressourcer
- afkast
- afkast
- gennemgå
- stigende
- Risiko
- roller
- regler
- Kør
- samme
- Scale
- Videnskabsmand
- valgt
- tjeneste
- sæt
- Shadow
- delt
- butikker
- Kort
- Vis
- vist
- Simpelt
- Størrelse
- So
- solid
- Løsning
- nogle
- specifikke
- delt
- påbegyndt
- statistik
- Status
- Stadig
- opbevaring
- Strategi
- Succesfuld
- mål
- Teknisk
- teknikker
- skabeloner
- prøve
- Test
- tre
- tærskel
- Gennem
- tid
- værktøj
- top
- TPR
- Trafik
- Tog
- Kurser
- transaktion
- transformationer
- typer
- typisk
- under
- forstå
- universitet
- Opdatering
- us
- USA
- brug
- brugere
- sædvanligvis
- nytte
- validering
- værdi
- udgave
- Specifikation
- vente
- Hvad
- hvorvidt
- mens
- uden
- værd
- ville
- år
- år
- Din