Med veksten i bruk av nettapplikasjoner og det økende antallet internettbrukere, øker digital svindel år over år. Amazon-svindeldetektor tilbyr en fullstendig administrert tjeneste for å hjelpe deg med å bedre identifisere potensielt bedragerske nettaktiviteter ved hjelp av avanserte maskinlæringsteknikker (ML), og mer enn 20 års ekspertise på svindeldeteksjon fra Amazon.
For å hjelpe deg å fange svindel raskere på tvers av flere brukssaker, tilbyr Amazon Fraud Detector spesifikke modeller med skreddersydde algoritmer, berikelser og funksjonstransformasjoner. Modellopplæringen er helautomatisert og problemfri, og du kan følge instruksjonene i brukerhåndboken eller relatert blogginnlegg for å komme i gang. Men med trente modeller må du bestemme om modellen er klar for distribusjon. Dette krever viss kunnskap innen ML, statistikk og svindeldeteksjon, og det kan være nyttig å kjenne til noen typiske tilnærminger.
Dette innlegget vil hjelpe deg med å diagnostisere modellytelse og velge riktig modell for distribusjon. Vi går gjennom beregningene levert av Amazon Fraud Detector, hjelper deg med å diagnostisere potensielle problemer og gir forslag for å forbedre modellytelsen. Tilnærmingene gjelder både for Online Fraud Insights (OFI) og Transaction Fraud Insights (TFI) modellmaler.
Løsningsoversikt
Dette innlegget gir en ende-til-ende-prosess for å diagnostisere modellens ytelse. Den introduserer først alle modellberegningene vist på Amazon Fraud Detector-konsollen, inkludert AUC, poengfordeling, forvirringsmatrise, ROC-kurve og modellvariabel betydning. Deretter presenterer vi en tre-trinns tilnærming for å diagnostisere modellytelse ved hjelp av forskjellige beregninger. Til slutt gir vi forslag for å forbedre modellytelsen for typiske problemer.
Forutsetninger
Før du dykker dypt inn i Amazon Fraud Detector-modellen din, må du fullføre følgende forutsetninger:
- Opprett en AWS-konto.
- Opprett et hendelsesdatasett for modelltrening.
- Last opp dataene dine til Amazon enkel lagringstjeneste (Amazon S3) eller innta hendelsesdataene dine i Amazon Fraud Detector.
- Bygg en Amazon Fraud Detector-modell.
Tolk modellberegninger
Etter at modellopplæringen er fullført, evaluerer Amazon Fraud Detector modellen din ved å bruke deler av modelleringsdataene som ikke ble brukt i modellopplæringen. Den returnerer evalueringsberegningene på Modellversjon side for den modellen. Disse beregningene gjenspeiler modellytelsen du kan forvente på reelle data etter distribusjon til produksjon.
Følgende skjermbilde viser eksempelmodellytelse returnert av Amazon Fraud Detector. Du kan velge ulike terskler på poengfordeling (venstre), og forvirringsmatrisen (høyre) oppdateres deretter.
Du kan bruke følgende funn for å sjekke ytelse og bestemme strategiregler:
- AUC (areal under kurven) – Den generelle ytelsen til denne modellen. En modell med AUC på 0.50 er ikke bedre enn en myntvending fordi den representerer tilfeldige tilfeldigheter, mens en "perfekt" modell vil ha en poengsum på 1.0. Jo høyere AUC, desto bedre kan modellen din skille mellom svindel og legitime.
- Poengfordeling – Et histogram av modellpoengfordelinger som antar en eksempelpopulasjon på 100,000 0 hendelser. Amazon Fraud Detector genererer modellscore mellom 1000–XNUMX, der jo lavere poengsum, desto lavere svindelrisiko. Bedre skille mellom legitime (grønne) og svindel (blå) populasjoner indikerer vanligvis en bedre modell. For flere detaljer, se Modellscore.
- Forvirringsmatrise – En tabell som beskriver modellytelsen for den valgte poenggrensen, inkludert sann positiv, sann negativ, falsk positiv, falsk negativ, sann positiv rate (TPR) og falsk positiv rate (FPR). Tellingen på bordet antar en eksempelpopulasjon på 100,0000 XNUMX hendelser. For flere detaljer, se Modell ytelsesberegninger.
- ROC (Receiver Operator Characteristic) kurve – Et plott som illustrerer modellens diagnostiske evne, som vist i følgende skjermbilde. Den plotter den sanne positive raten som en funksjon av falsk positiv rate over alle mulige modellscoreterskler. Se dette diagrammet ved å velge Avanserte beregninger. Hvis du har trent flere versjoner av én modell, kan du velge forskjellige FPR-terskler for å sjekke ytelsesendringen.
- Modellvariabel betydning – Rangeringen av modellvariabler basert på deres bidrag til den genererte modellen, som vist i følgende skjermbilde. Modellvariabelen med høyest verdi er viktigere for modellen enn de andre modellvariablene i datasettet for den modellversjonen, og er oppført øverst som standard. For flere detaljer, se Modellvariabel betydning.
Diagnostiser modellens ytelse
Før du distribuerer modellen din i produksjon, bør du bruke beregningene Amazon Fraud Detector returnerte for å forstå modellens ytelse og diagnostisere mulige problemer. De vanlige problemene med ML-modeller kan deles inn i to hovedkategorier: datarelaterte problemer og modellrelaterte problemer. Amazon Fraud Detector har tatt seg av de modellrelaterte problemene ved å nøye bruke validerings- og testsett for å evaluere og justere modellen din på backend. Du kan fullføre følgende trinn for å validere om modellen din er klar for distribusjon eller har mulige datarelaterte problemer:
- Sjekk den generelle modellens ytelse (AUC og poengfordeling).
- Gjennomgå forretningskrav (forvirringsmatrise og tabell).
- Sjekk modellvariabelens betydning.
Sjekk generell modellytelse: AUC og poengfordeling
Mer nøyaktig prediksjon av fremtidige hendelser er alltid det primære målet for en prediktiv modell. AUC returnert av Amazon Fraud Detector er beregnet på et korrekt samplet testsett som ikke brukes i trening. Generelt anses en modell med en AUC større enn 0.9 å være en god modell.
Hvis du observerer en modell med ytelse mindre enn 0.8, betyr det vanligvis at modellen har rom for forbedring (vi diskuterer vanlige problemer for lav modellytelse senere i dette innlegget). Vær oppmerksom på at definisjonen av "god" ytelse i stor grad avhenger av virksomheten din og grunnmodellen. Du kan fortsatt følge trinnene i dette innlegget for å forbedre Amazon Fraud Detector-modellen din selv om AUC er større enn 0.8.
På den annen side, hvis AUC er over 0.99, betyr det at modellen nesten perfekt kan skille svindel og legitime hendelser på testsettet. Dette er noen ganger et "for godt til å være sant"-scenario (vi diskuterer vanlige problemer for svært høy modellytelse senere i dette innlegget).
Foruten den generelle AUC, kan poengfordelingen også fortelle deg hvor godt modellen er tilpasset. Ideelt sett bør du se hoveddelen av lovlig og svindel plassert i de to endene av skalaen, noe som indikerer at modellpoengsummen kan rangere hendelsene på testsettet nøyaktig.
I følgende eksempel har poengfordelingen en AUC på 0.96.
Hvis den legitime distribusjonen og svindeldistribusjonen overlappet eller konsentrert seg i sentrum, betyr det sannsynligvis at modellen ikke gir gode resultater når det gjelder å skille svindelhendelser fra legitime hendelser, noe som kan indikere at historisk datadistribusjon er endret eller at du trenger mer data eller funksjoner.
Følgende er et eksempel på poengfordeling med en AUC på 0.64.
Hvis du kan finne et splittpunkt som nesten perfekt kan dele svindel og legitime hendelser, er det stor sjanse for at modellen har et problem med etikettlekkasje eller at svindelmønstrene er for enkle å oppdage, noe som burde fange oppmerksomheten din.
I følgende eksempel har poengfordelingen en AUC på 1.0.
Gjennomgå forretningskrav: Forvirringsmatrise og tabell
Selv om AUC er en praktisk indikator på modellytelse, kan det hende at den ikke direkte oversettes til forretningsbehovet ditt. Amazon Fraud Detector gir også beregninger som svindelfangstrate (sann positiv rate), prosentandel av legitime hendelser som er feilaktig spådd som svindel (falsk positiv rate), og mer, som oftere brukes som forretningskrav. Etter at du har trent en modell med en rimelig god AUC, må du sammenligne modellen med forretningskravene dine med disse beregningene.
Forvirringsmatrisen og tabellen gir deg et grensesnitt for å vurdere virkningen og sjekke om den oppfyller forretningsbehovene dine. Legg merke til at tallene avhenger av modellterskelen, der hendelser med skårer høyere enn terskelverdien klassifiseres som svindel og hendelser med skårer lavere enn terskelen klassifiseres som legitime. Du kan velge hvilken terskel du vil bruke, avhengig av bedriftens krav.
For eksempel, hvis målet ditt er å fange opp 73 % av svindelene, kan du (som vist i eksempelet nedenfor) velge en terskel som 855, som lar deg fange opp 73 % av all svindel. Modellen vil imidlertid også feilklassifisere 3 % legitime hendelser til å være uredelige. Hvis denne FPR er akseptabel for virksomheten din, er modellen god for distribusjon. Ellers må du forbedre modellens ytelse.
Et annet eksempel er hvis kostnaden for å blokkere eller utfordre en legitim kunde er ekstremt høy, så vil du ha lav FPR og høy presisjon. I så fall kan du velge en terskel på 950, som vist i følgende eksempel, som vil feilklassifisere 1 % av legitime kunder som svindel, og 80 % av identifisert svindel vil faktisk være svindel.
I tillegg kan du velge flere terskler og tilordne forskjellige utfall, for eksempel blokkere, undersøke, bestå. Hvis du ikke finner riktige terskler og regler som tilfredsstiller alle forretningskravene dine, bør du vurdere å trene modellen din med flere data og attributter.
Sjekk modellvariabelens betydning
De Modellvariabel betydning ruten viser hvordan hver variabel bidrar til modellen din. Hvis en variabel har en betydelig høyere viktighetsverdi enn de andre, kan det tyde på lekkasje på etiketten eller at svindelmønstrene er for enkle å oppdage. Vær oppmerksom på at variabelens betydning aggregeres tilbake til inngangsvariablene dine. Hvis du observerer litt høyere betydning av IP_ADDRESS
, CARD_BIN
, EMAIL_ADDRESS
, PHONE_NUMBER
, BILLING_ZIP
eller SHIPPING_ZIP
, det kan være på grunn av berikelsens kraft.
Følgende eksempel viser modellens variabel betydning med en potensiell etikettlekkasje ved bruk av investigation_status
.
Betydning av modellvariabel gir deg også hint om hvilke tilleggsvariabler som potensielt kan bringe løft til modellen. Hvis du for eksempel observerer lav AUC og selgerrelaterte funksjoner viser stor betydning, kan du vurdere å samle flere bestillingsfunksjoner som f.eks. SELLER_CATEGORY
, SELLER_ADDRESS
og SELLER_ACTIVE_YEARS
, og legg til disse variablene i modellen din.
Vanlige problemer for lav modellytelse
I denne delen diskuterer vi vanlige problemer du kan støte på angående lav modellytelse.
Historisk datadistribusjon endret
Historisk datadistribusjonsdrift skjer når du har en stor bedriftsendring eller et problem med datainnsamling. For eksempel, hvis du nylig har lansert produktet i et nytt marked, IP_ADDRESS
, EMAIL
og ADDRESS
relaterte funksjoner kan være helt annerledes, og svindelmodusen kan også endre seg. Amazon Fraud Detector bruker EVENT_TIMESTAMP
for å dele data og evaluere modellen din på det aktuelle undersettet av hendelser i datasettet. Hvis distribusjonen av historiske data endres betydelig, kan evalueringssettet være svært forskjellig fra treningsdataene, og den rapporterte modellytelsen kan være lav.
Du kan sjekke det potensielle problemet med endring av datadistribusjon ved å utforske de historiske dataene dine:
- Bruke Amazon Fraud Detector Data Profiler verktøy for å sjekke om svindelfrekvensen og den manglende andelen av etiketten endret seg over tid.
- Sjekk om variabelfordelingen over tid endret seg betydelig, spesielt for funksjoner med høy variabel betydning.
- Sjekk variabelfordelingen over tid etter målvariabler. Hvis du observerer betydelig flere svindelhendelser fra én kategori i nyere data, kan det være lurt å sjekke om endringen er rimelig ved å bruke forretningsmessige vurderinger.
Hvis du finner at den manglende andelen av etiketten er svært høy eller svindelfrekvensen konsekvent falt i løpet av de siste datoene, kan det være en indikator på at etikettene ikke er fullstendig modne. Du bør ekskludere de nyeste dataene eller vente lenger med å samle inn de nøyaktige etikettene, og deretter lære opp modellen på nytt.
Hvis du observerer en kraftig økning av svindelfrekvens og variabler på bestemte datoer, kan det være lurt å dobbeltsjekke om det er et avvik eller et problem med datainnsamling. I så fall bør du slette disse hendelsene og trene modellen på nytt.
Hvis du finner ut at de utdaterte dataene ikke kan representere din nåværende og fremtidige virksomhet, bør du ekskludere den gamle perioden med data fra opplæring. Hvis du bruker lagrede hendelser i Amazon Fraud Detector, kan du ganske enkelt lære opp en ny versjon og velge riktig datoperiode mens du konfigurerer treningsjobben. Det kan også indikere at svindelmodusen i virksomheten din endrer seg relativt raskt over tid. Etter modelldistribusjon må du kanskje trene modellen på nytt ofte.
Feil tilordning av variabeltype
Amazon Fraud Detector beriker og transformerer dataene basert på variabeltypene. Det er viktig at du tilordner variablene dine til riktig type slik at Amazon Fraud Detector-modellen kan ta den maksimale verdien av dataene dine. For eksempel hvis du kartlegger IP
til CATEGORICAL
skriv i stedet for IP_ADDRESS
, du skjønner ikke IP-
relaterte berikelser i backend.
Generelt foreslår Amazon Fraud Detector følgende handlinger:
- Kartlegg variablene dine til spesifikke typer, som f.eks
IP_ADDRESS
,EMAIL_ADDRESS
,CARD_BIN
ogPHONE_NUMBER
, slik at Amazon Fraud Detector kan trekke ut og berike tilleggsinformasjon. - Hvis du ikke finner den spesifikke variabeltypen, kan du tilordne den til en av de tre generiske typene:
NUMERIC
,CATEGORICAL
ellerFREE_FORM_TEXT
. - Hvis en variabel er i tekstform og har høy kardinalitet, for eksempel en kundeanmeldelse eller produktbeskrivelse, bør du tilordne den til
FREE_FORM_TEXT
variabel type slik at Amazon Fraud Detector trekker ut tekstfunksjoner og innebygging på backend for deg. For eksempel hvis du kartleggerurl_string
tilFREE_FORM_TEXT
, er den i stand til å tokenisere URL-en og trekke ut informasjon for å mate inn i nedstrømsmodellen, noe som vil hjelpe den å lære flere skjulte mønstre fra URL-en.
Hvis du finner ut at noen av variabeltypene dine er feil kartlagt i variabelkonfigurasjonen, kan du endre variabeltypen og deretter trene modellen på nytt.
Utilstrekkelige data eller funksjoner
Amazon Fraud Detector krever minst 10,000 400 poster for å trene en Online Fraud Insights (OFI) eller Transaction Fraud Insights (TFI) modell, med minst 100 av disse postene identifisert som uredelige. TFI krever også at både falske poster og legitime poster kommer fra minst XNUMX forskjellige enheter hver for å sikre mangfoldet i datasettet. I tillegg krever Amazon Fraud Detector at modelleringsdataene har minst to variabler. Dette er minimumsdatakravene for å bygge en nyttig Amazon Fraud Detector-modell. Men å bruke flere poster og variabler hjelper vanligvis ML-modellene med å lære de underliggende mønstrene fra dataene dine. Når du observerer en lav AUC eller ikke finner terskler som oppfyller forretningskravene dine, bør du vurdere å omskolere modellen med mer data eller legge til nye funksjoner i modellen. Vanligvis finner vi EMAIL_ADDRESS
, IP
, PAYMENT_TYPE
, BILLING_ADDRESS
, SHIPPING_ADDRESS
og DEVICE
relaterte variabler er viktige for å oppdage svindel.
En annen mulig årsak er at noen av variablene dine inneholder for mange manglende verdier. For å se om det skjer, sjekk modelltreningsmeldingene og se Feilsøk problemer med treningsdata for forslag.
Vanlige problemer for svært høy modellytelse
I denne delen diskuterer vi vanlige problemer knyttet til svært høy modellytelse.
Etikettlekkasje
Etikettlekkasje oppstår når treningsdatasettene bruker informasjon som ikke forventes å være tilgjengelig på prediksjonstidspunktet. Den overvurderer modellens nytteverdi når den kjøres i et produksjonsmiljø.
Høy AUC (nær 1), perfekt adskilt poengfordeling og signifikant høyere variabel betydning for én variabel kan være indikatorer på potensielle problemer med etikettlekkasje. Du kan også sjekke korrelasjonen mellom funksjonene og etiketten ved å bruke Dataprofiler. De Funksjons- og etikettkorrelasjon plot viser korrelasjonen mellom hver funksjon og etiketten. Hvis en funksjon har over 0.99 korrelasjon med etiketten, bør du sjekke om funksjonen brukes riktig basert på forretningsmessige vurderinger. For å bygge en risikomodell for å godkjenne eller avslå en lånesøknad, bør du for eksempel ikke bruke funksjoner som AMOUNT_PAID
, fordi betalingene skjer etter underwritingsprosessen. Hvis en variabel ikke er tilgjengelig på det tidspunktet du lager prediksjon, bør du fjerne den variabelen fra modellkonfigurasjonen og lære opp en ny modell på nytt.
Følgende eksempel viser korrelasjonen mellom hver variabel og etikett. investigation_status
har en høy korrelasjon (nær 1) med etiketten, så du bør dobbeltsjekke om det er et problem med etikettlekkasje.
Enkle svindelmønstre
Når svindelmønstrene i dataene dine er enkle, kan du også observere svært høy modellytelse. Anta for eksempel at alle svindelhendelsene i modelleringsdataene kommer gjennom den samme interne tjenesteleverandøren; det er enkelt for modellen å velge IP-
relaterte variabler og returnere en "perfekt" modell med høy betydning av IP
.
Enkle svindelmønstre indikerer ikke alltid et dataproblem. Det kan være sant at svindelmodusen i virksomheten din er lett å fange opp. Før du trekker en konklusjon, må du imidlertid sørge for at etikettene som brukes i modellopplæringen er nøyaktige, og at modelleringsdataene dekker så mange svindelmønstre som mulig. For eksempel hvis du merker svindelhendelsene dine basert på regler, for eksempel merking av alle applikasjoner fra en bestemt BILLING_ZIP
i tillegg til PRODUCT_CATEGORY
som svindel, kan modellen enkelt fange disse svindelene ved å simulere reglene og oppnå høy AUC.
Du kan sjekke etikettfordelingen på tvers av forskjellige kategorier eller søppelkasser for hver funksjon ved å bruke Dataprofiler. Hvis du for eksempel observerer at de fleste svindelhendelser kommer fra én eller noen få produktkategorier, kan det være en indikator på enkle svindelmønstre, og du må bekrefte at det ikke er en datainnsamlings- eller prosessfeil. Hvis funksjonen er som CUSTOMER_ID
, bør du ekskludere funksjonen i modellopplæring.
Følgende eksempel viser etikettfordeling på tvers av ulike kategorier av product_category
. All svindel kommer fra to produktkategorier.
Feil dataprøvetaking
Feil datasampling kan skje når du samplet og bare sendte deler av dataene dine til Amazon Fraud Detector. Hvis dataene ikke er samplet på riktig måte og ikke er representative for trafikken i produksjonen, vil den rapporterte modellytelsen være unøyaktig, og modellen kan være ubrukelig for produksjonsprediksjon. For eksempel, hvis alle svindelhendelser i modelleringsdataene er samplet fra Asia og alle legitime hendelser er samplet fra USA, kan modellen lære å skille svindel og legit basert på BILLING_COUNTRY
. I så fall er modellen ikke generisk for å brukes på andre populasjoner.
Vanligvis foreslår vi at du sender alle de siste hendelsene uten prøvetaking. Basert på datastørrelsen og svindelfrekvensen utfører Amazon Fraud Detector prøvetaking før modelltrening for deg. Hvis dataene dine er for store (over 100 GB) og du bestemmer deg for å prøve og sende bare et delsett, bør du tilfeldig prøve dataene dine og sørge for at utvalget er representativt for hele populasjonen. For TFI bør du sample dataene dine etter enhet, noe som betyr at hvis én enhet er samplet, bør du inkludere all historikk slik at enhetsnivåaggregatene beregnes riktig. Vær oppmerksom på at hvis du bare sender et undersett av data til Amazon Fraud Detector, kan sanntidsaggregatene under slutningen være unøyaktige hvis de tidligere hendelsene til enhetene ikke sendes.
En annen feil datasampling kan være å bare bruke en kort periode med data, som én dags data, for å bygge modellen. Dataene kan være partiske, spesielt hvis virksomheten eller svindelangrepene har sesongvariasjoner. Vi anbefaler vanligvis å inkludere minst to sykluser (som 2 uker eller 2 måneder) med data i modelleringen for å sikre mangfoldet av svindeltyper.
konklusjonen
Etter å ha diagnostisert og løst alle potensielle problemer, bør du få en nyttig Amazon Fraud Detector-modell og være trygg på ytelsen. For neste trinn, du kan lage en detektor med modellen og forretningsreglene dine, og vær klar til å distribuere den til produksjon for en skyggemodusevaluering.
Vedlegg
Hvordan ekskludere variabler for modelltrening
Etter dypdykket kan du identifisere en variabel lekkasjemålinformasjon, og ønsker å ekskludere den fra modelltrening. Du kan omskolere en modellversjon som ekskluderer variablene du ikke vil ha ved å fullføre følgende trinn:
- På Amazon Fraud Detector-konsollen, i navigasjonsruten, velger du Modeller.
- På Modeller side, velg modellen du vil omskolere.
- På handlinger meny, velg Tren ny versjon.
- Velg datoperioden du vil bruke og velg neste.
- På Konfigurer trening side, fjerner du merket for variabelen du ikke vil bruke i modelltrening.
- Spesifiser svindeletikettene og legitime etikettene dine og hvordan du vil at Amazon Fraud Detector skal bruke umerkede hendelser, og velg deretter neste.
- Se gjennom modellkonfigurasjonen og velg Lage og trene modell.
Hvordan endre type hendelsesvariabel
Variabler representerer dataelementer som brukes i svindelforebygging. I Amazon Fraud Detector er alle variabler globale og deles på tvers av alle hendelser og modeller, noe som betyr at én variabel kan brukes i flere hendelser. For eksempel kan IP være assosiert med påloggingshendelser, og det kan også være assosiert med transaksjonshendelser. Naturligvis låste Amazon Fraud Detector variabeltypen og datatypen når en variabel er opprettet. For å slette en eksisterende variabel, må du først slette alle tilknyttede hendelsestyper og modeller. Du kan sjekke ressursene knyttet til den spesifikke variabelen ved å navigere til Amazon Fraud Detector, velge Variabler i navigasjonsruten, og velg variabelnavnet og Tilknyttede ressurser.
Slett variabelen og alle tilknyttede hendelsestyper
For å slette variabelen, fullfør følgende trinn:
- På Amazon Fraud Detector-konsollen, i navigasjonsruten, velger du Variabler.
- Velg variabelen du vil slette.
- Velg Tilknyttede ressurser for å se en liste over alle hendelsestypene som brukes med denne variabelen.
Du må slette de tilknyttede hendelsestypene før du sletter variabelen. - Velg hendelsestypene i listen for å gå til den tilknyttede hendelsestypesiden.
- Velg Lagrede hendelser for å sjekke om noen data er lagret under denne hendelsestypen.
- Hvis det er hendelser lagret i Amazon Fraud Detector, velg Slett lagrede hendelser for å slette de lagrede hendelsene.
Når slettejobben er fullført, vises meldingen "De lagrede hendelsene for denne hendelsestypen ble slettet". - Velg Tilknyttede ressurser.
Hvis detektorer og modeller er knyttet til denne hendelsestypen, må du slette disse ressursene først. - Hvis detektorer er tilknyttet, fullfør følgende trinn for å slette alle tilknyttede detektorer:
- Velg detektoren du vil gå til Detektordetaljer side.
- på Modellversjoner velg detektorens versjon.
- På detektorversjonssiden velger du handlinger.
- Hvis detektorversjonen er aktiv, velg Deaktiver, velg Deaktiver denne detektorversjonen uten å erstatte den med en annen versjon, og velg Deaktiver detektorversjon.
- Etter at detektorversjonen er deaktivert, velg handlinger og deretter Delete.
- Gjenta disse trinnene for å slette alle detektorversjoner.
- På Detektordetaljer side, velg Tilknyttede regler.
- Velg regelen som skal slettes.
- Velg handlinger og Slett regelversjon.
- Skriv inn regelnavnet for å bekrefte og velge Slett versjon.
- Gjenta disse trinnene for å slette alle tilknyttede regler.
- Etter at alle detektorversjoner og tilhørende regler er slettet, gå til Detektordetaljer side, velg handlinger, og velg Slett detektor.
- Skriv inn detektorens navn og velg Slett detektor.
- Gjenta disse trinnene for å slette neste detektor.
- Hvis noen modeller er knyttet til hendelsestypen, fullfør følgende trinn for å slette dem:
- Velg navnet på modellen.
- på Modellversjoner velg versjonen.
- Hvis modellstatusen er
Active
, velg handlinger og Avinstaller modellversjon. - Enter
undeploy
for å bekrefte og velge Avinstaller modellversjon.
Status endres tilUndeploying
. Prosessen tar noen minutter å fullføre. - Etter status blir
Ready to deploy
, velg Handlinger og Slett. - Gjenta disse trinnene for å slette alle modellversjoner.
- På siden Modelldetaljer velger du Handlinger og Slett modell.
- Skriv inn navnet på modellen og velg Slett modell.
- Gjenta disse trinnene for å slette neste modell.
- Etter at alle tilknyttede detektorer og modeller er slettet, velg handlinger og Slett hendelsestype på Arrangementsdetaljer side.
- Skriv inn navnet på hendelsestypen og velg Slett hendelsestype.
- Velg i navigasjonsruten Variabler, og velg variabelen du vil slette.
- Gjenta de tidligere trinnene for å slette alle hendelsestyper knyttet til variabelen.
- På Variable detaljer side, velg handlinger og Slett.
- Skriv inn navnet på variabelen og velg Slett variabel.
Lag en ny variabel med riktig variabeltype
Etter at du har slettet variabelen og alle tilknyttede hendelsestyper, lagrede hendelser, modeller og detektorer fra Amazon Fraud Detector, kan du opprette en ny variabel med samme navn og tilordne den til riktig variabeltype.
- På Amazon Fraud Detector-konsollen, i navigasjonsruten, velger du Variabler.
- Velg Opprett.
- Skriv inn variabelnavnet du vil endre (det du slettet tidligere).
- Velg riktig variabeltype du vil endre til.
- Velg Lag variabel.
Last opp data og omlær modellen
Etter at du har oppdatert variabeltypen, kan du laste opp dataene på nytt og trene opp en ny modell. For instruksjoner, se Oppdag transaksjonssvindel på nettet med nye Amazon Fraud Detector-funksjoner.
Hvordan legge til nye variabler til en eksisterende hendelsestype
For å legge til nye variabler til den eksisterende hendelsestypen, fullfør følgende trinn:
- Legg til de nye variablene til den forrige trenings-CVS-filen.
- Last opp den nye treningsdatafilen til en S3-bøtte. Legg merke til Amazon S3-plasseringen til treningsfilen din (f.eks.
s3://bucketname/path/to/some/object.csv
) og rollenavnet ditt. - På Amazon Fraud Detector-konsollen, i navigasjonsruten, velger du Arrangementer.
- På Hendelsestyper siden, velg navnet på hendelsestypen du vil legge til variabler.
- På Arrangementstype detaljside, velg handlinger, deretter Legg til variabler.
- Under Velg hvordan du vil definere denne hendelsens variabler, velg Velg variabler fra et treningsdatasett.
- For IAM-rolle, velg en eksisterende IAM-rolle eller opprett en ny rolle for å få tilgang til data i Amazon S3.
- Til Dataplassering, skriv inn S3-plasseringen til den nye treningsfilen og velg Laste opp.
De nye variablene som ikke er til stede i den eksisterende hendelsestypen, skal vises i listen.
- Velg Legg til variabler.
Nå er de nye variablene lagt til den eksisterende hendelsestypen. Hvis du bruker lagrede hendelser i Amazon Fraud Detector, mangler fortsatt de nye variablene for de lagrede hendelsene. Du må importere treningsdataene med de nye variablene til Amazon Fraud Detector og deretter trene opp en ny modellversjon. Når du laster opp de nye treningsdataene med samme EVENT_ID
og EVENT_TIMESTAMP
, de nye hendelsesvariablene overskriver de tidligere hendelsesvariablene som er lagret i Amazon Fraud Detector.
Om forfatterne
Julia Xu er en forsker med Amazon Fraud Detector. Hun brenner for å løse kundeutfordringer ved hjelp av maskinlæringsteknikker. På fritiden liker hun å gå tur, male og utforske nye kaffebarer.
Hao Zhou er en forsker med Amazon Fraud Detector. Han har en doktorgrad i elektroteknikk fra Northwestern University, USA. Han brenner for å bruke maskinlæringsteknikker for å bekjempe svindel og misbruk.
Abhishek Ravi er senior produktsjef med Amazon Fraud Detector. Han brenner for å utnytte tekniske evner for å bygge produkter som gleder kunder.
- Myntsmart. Europas beste Bitcoin og Crypto Exchange.
- Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. FRI TILGANG.
- CryptoHawk. Altcoin Radar. Gratis prøveperiode.
- 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 oss
- adgang
- tilsvar
- Logg inn
- nøyaktig
- tvers
- handlinger
- aktiv
- Aktiviteter
- la til
- tillegg
- Ytterligere
- Adopsjon
- avansert
- algoritmer
- Alle
- tillater
- alltid
- Amazon
- aktuelt
- Søknad
- søknader
- anvendt
- påføring
- tilnærming
- tilnærminger
- hensiktsmessig
- godkjenne
- AREA
- asia
- assosiert
- oppmerksomhet
- attributter
- Automatisert
- tilgjengelig
- AWS
- Baseline
- fordi
- før du
- under
- Bedre
- mellom
- Blokker
- grensen
- bringe
- bygge
- virksomhet
- beregnet
- evner
- fangst
- hvilken
- saken
- saker
- Catch
- Kategori
- Årsak
- viss
- utfordringer
- utfordrende
- endring
- Velg
- klassifisert
- Kaffe
- Coin
- samle
- Samle
- samling
- bekjempe
- Kom
- Felles
- fullføre
- helt
- fullført
- trygg
- Konfigurasjon
- forvirring
- Vurder
- Konsoll
- Praktisk
- kunne
- skape
- opprettet
- Gjeldende
- skjøger
- kunde
- Kunder
- dato
- datoer
- dyp
- avhengig
- avhenger
- utplassere
- utplasserings
- distribusjon
- beskrivelse
- detaljer
- Gjenkjenning
- forskjellig
- digitalt
- direkte
- diskutere
- skjermer
- distribusjon
- Distribusjoner
- Mangfold
- ikke
- droppet
- under
- hver enkelt
- lett
- elementer
- ende til ende
- slutter
- Ingeniørarbeid
- berike
- Enter
- enheter
- enhet
- Miljø
- spesielt
- evaluere
- evaluering
- Event
- hendelser
- eksempel
- Eksklusiv
- eksisterende
- forvente
- forventet
- ekspertise
- ekstrakter
- raskere
- Trekk
- Egenskaper
- Endelig
- Først
- følge
- etter
- skjema
- svindel
- Gratis
- fra
- funksjon
- framtid
- general
- generert
- Global
- mål
- god
- større
- Grønn
- Vekst
- skje
- hjelpe
- nyttig
- hjelper
- Høy
- høyere
- svært
- historisk
- historie
- holder
- Hvordan
- Hvordan
- Men
- HTTPS
- identifisere
- Påvirkning
- betydning
- viktig
- forbedre
- forbedring
- inkludere
- Inkludert
- indikerer
- informasjon
- inngang
- innsikt
- Interface
- Internet
- undersøke
- IP
- utstedelse
- saker
- IT
- Jobb
- dommer
- Vet
- kunnskap
- Etiketten
- merking
- etiketter
- stor
- større
- siste
- lansert
- lekke
- LÆRE
- læring
- Nivå
- utnytte
- Liste
- oppført
- plassering
- låst
- maskin
- maskinlæring
- gjøre
- Making
- fikk til
- leder
- kart
- marked
- Matrix
- midler
- meldinger
- Metrics
- kunne
- minimum
- ML
- modell
- modeller
- måneder
- mer
- mest
- flere
- navigere
- Navigasjon
- behov
- negativ
- Nye funksjoner
- Nytt marked
- neste
- Antall
- tall
- Tilbud
- på nett
- operatør
- rekkefølge
- Annen
- ellers
- samlet
- del
- lidenskapelig
- betalinger
- prosent
- ytelse
- perioden
- Point
- befolkningen
- positiv
- mulig
- potensiell
- makt
- prediksjon
- presentere
- Forebygging
- forrige
- primære
- problemer
- prosess
- Produkt
- Produksjon
- Produkter
- gi
- forutsatt
- leverandør
- gir
- raskt
- område
- sanntids
- rimelig
- nylig
- nylig
- anbefaler
- poster
- reflektere
- om
- representere
- representant
- representerer
- Krav
- Krever
- forskning
- Ressurser
- retur
- avkastning
- anmeldelse
- stiger
- Risiko
- Rolle
- regler
- Kjør
- samme
- Skala
- Forsker
- valgt
- tjeneste
- sett
- Shadow
- delt
- butikker
- Kort
- Vis
- vist
- Enkelt
- Størrelse
- So
- solid
- løse
- noen
- spesifikk
- splittet
- startet
- statistikk
- status
- Still
- lagring
- Strategi
- vellykket
- Target
- Teknisk
- teknikker
- maler
- test
- Testing
- De
- tre
- terskel
- Gjennom
- tid
- verktøy
- topp
- TPR
- trafikk
- Tog
- Kurs
- Transaksjonen
- transformasjoner
- typer
- typisk
- etter
- forstå
- universitet
- Oppdater
- us
- USA
- bruke
- Brukere
- vanligvis
- verktøyet
- validering
- verdi
- versjon
- Se
- vente
- Hva
- om
- mens
- uten
- verdt
- ville
- år
- år
- Din