Med ökningen av antagandet av onlineapplikationer och det ökande antalet internetanvändare ökar digitala bedrägerier år från år. Amazon bedrägeri detektor tillhandahåller en fullständigt hanterad tjänst för att hjälpa dig att bättre identifiera potentiellt bedrägliga onlineaktiviteter med hjälp av avancerade maskininlärningstekniker (ML) och mer än 20 års expertis för bedrägeriupptäckt från Amazon.
För att hjälpa dig fånga bedrägerier snabbare i flera fall erbjuder Amazon Fraud Detector specifika modeller med skräddarsydda algoritmer, berikningar och funktionstransformationer. Modellutbildningen är helautomatiserad och problemfri, och du kan följa instruktionerna i Användarguide eller relaterade blogginlägg för att starta. Men med utbildade modeller måste du bestämma om modellen är redo för driftsättning. Detta kräver viss kunskap inom ML, statistik och bedrägeriupptäckt, och det kan vara bra att känna till några typiska tillvägagångssätt.
Det här inlägget hjälper dig att diagnostisera modellprestanda och välja rätt modell för implementering. Vi går igenom statistiken som tillhandahålls av Amazon Fraud Detector, hjälper dig att diagnostisera potentiella problem och ger förslag för att förbättra modellens prestanda. Tillvägagångssätten är tillämpliga på både Online Fraud Insights (OFI) och Transaction Fraud Insights (TFI) modellmallar.
Lösningsöversikt
Det här inlägget ger en heltäckande process för att diagnostisera din modellprestanda. Den introducerar först alla modellmått som visas på Amazon Fraud Detector-konsolen, inklusive AUC, poängfördelning, förvirringsmatris, ROC-kurva och modellvariabelvikt. Sedan presenterar vi en trestegsmetod för att diagnostisera modellprestanda med hjälp av olika mätetal. Slutligen ger vi förslag för att förbättra modellens prestanda för typiska problem.
Förutsättningar
Innan du dyker djupt in i din Amazon Fraud Detector-modell måste du uppfylla följande förutsättningar:
- Skapa ett AWS-konto.
- Skapa en händelsedatauppsättning för modellutbildning.
- Ladda upp din data till Amazon enkel lagringstjänst (Amazon S3) eller mata in din händelsedata i Amazon Fraud Detector.
- Bygg en Amazon Fraud Detector-modell.
Tolka modellmått
När modellutbildningen är klar utvärderar Amazon Fraud Detector din modell med hjälp av en del av modelleringsdata som inte användes i modellutbildningen. Den returnerar utvärderingsmåtten på Modellversion sida för den modellen. Dessa mätvärden återspeglar modellens prestanda du kan förvänta dig på verkliga data efter implementeringen till produktion.
Följande skärmdump visar exempel på modellprestanda som returneras av Amazon Fraud Detector. Du kan välja olika trösklar för poängfördelning (vänster), och förvirringsmatrisen (höger) uppdateras därefter.
Du kan använda följande resultat för att kontrollera prestanda och besluta om strategiregler:
- AUC (area under kurvan) – Den övergripande prestandan för denna modell. En modell med AUC på 0.50 är inte bättre än en myntvändning eftersom den representerar en slumpmässig slump, medan en "perfekt" modell kommer att ha ett betyg på 1.0. Ju högre AUC, desto bättre kan din modell skilja mellan bedrägerier och legitima.
- Poängfördelning – Ett histogram över modellpoängfördelningar som antar en exempelpopulation på 100,000 0 händelser. Amazon Fraud Detector genererar modellpoäng mellan 1000–XNUMX, där ju lägre poäng desto lägre är bedrägerisken. Bättre åtskillnad mellan legitima (gröna) och bedrägerier (blå) befolkningar indikerar vanligtvis en bättre modell. För mer information, se Modellpoäng.
- Förvirringsmatris – En tabell som beskriver modellens prestanda för den valda givna poängtröskeln, inklusive sann positiv, sann negativ, falsk positiv, falsk negativ, sann positiv frekvens (TPR) och falsk positiv frekvens (FPR). Räkningen på bordet antar en exempelpopulation på 100,0000 XNUMX händelser. För mer information, se Modellens prestandamätvärden.
- ROC-kurva (Receiver Operator Characteristic). – En plot som illustrerar modellens diagnostiska förmåga, som visas i följande skärmdump. Den plottar den sanna positiva frekvensen som en funktion av falsk positiv frekvens över alla möjliga modellpoängtrösklar. Se detta diagram genom att välja Avancerade mätvärden. Om du har tränat flera versioner av en modell kan du välja olika FPR-trösklar för att kontrollera prestandaförändringen.
- Modell variabel betydelse – Rangeringen av modellvariabler baserat på deras bidrag till den genererade modellen, som visas i följande skärmdump. Modellvariabeln med det högsta värdet är viktigare för modellen än de andra modellvariablerna i datamängden för den modellversionen, och listas överst som standard. För mer information, se Modell variabel betydelse.
Diagnostisera modellens prestanda
Innan du distribuerar din modell i produktion bör du använda statistiken som Amazon Fraud Detector returnerade för att förstå modellens prestanda och diagnostisera möjliga problem. De vanliga problemen med ML-modeller kan delas in i två huvudkategorier: datarelaterade frågor och modellrelaterade frågor. Amazon Fraud Detector har tagit hand om de modellrelaterade problemen genom att noggrant använda validerings- och testset för att utvärdera och finjustera din modell på backend. Du kan slutföra följande steg för att verifiera om din modell är redo för implementering eller har möjliga datarelaterade problem:
- Kontrollera modellens övergripande prestanda (AUC och poängfördelning).
- Granska affärskrav (förvirringsmatris och tabell).
- Kontrollera betydelsen av modellens variabel.
Kontrollera övergripande modellprestanda: AUC och poängfördelning
Mer exakt förutsägelse av framtida händelser är alltid det primära målet för en prediktiv modell. AUC som returneras av Amazon Fraud Detector beräknas på en korrekt samplade testuppsättning som inte används under träning. I allmänhet anses en modell med en AUC större än 0.9 vara en bra modell.
Om du observerar en modell med prestanda mindre än 0.8 betyder det vanligtvis att modellen har utrymme för förbättringar (vi diskuterar vanliga problem för låg modellprestanda längre fram i detta inlägg). Observera att definitionen av "bra" resultat i hög grad beror på din verksamhet och grundmodellen. Du kan fortfarande följa stegen i det här inlägget för att förbättra din Amazon Fraud Detector-modell även om dess AUC är större än 0.8.
Å andra sidan, om AUC är över 0.99 betyder det att modellen nästan perfekt kan separera bedrägeri och legitima händelser på testsetet. Detta är ibland ett "för bra för att vara sant"-scenario (vi diskuterar vanliga problem för mycket hög modellprestanda senare i det här inlägget).
Förutom den övergripande AUC kan poängfördelningen också berätta hur väl modellen är monterad. Helst bör du se huvuddelen av legitima och bedrägerier i de två ändarna av skalan, vilket indikerar att modellpoängen korrekt kan rangordna händelserna i testsetet.
I följande exempel har poängfördelningen en AUC på 0.96.
Om den legitima distributionen och bedrägerifördelningen överlappade eller koncentrerades i centrum betyder det förmodligen att modellen inte fungerar bra när det gäller att skilja bedrägerihändelser från legitima händelser, vilket kan tyda på att historisk datadistribution har ändrats eller att du behöver mer data eller funktioner.
Följande är ett exempel på poängfördelning med en AUC på 0.64.
Om du kan hitta en splitpunkt som nästan perfekt kan dela upp bedrägerier och legitima händelser, finns det en stor chans att modellen har problem med etikettläckage eller att bedrägerimönstren är för lätta att upptäcka, vilket borde fånga din uppmärksamhet.
I följande exempel har poängfördelningen en AUC på 1.0.
Granska affärskrav: Förvirringsmatris och tabell
Även om AUC är en bekväm indikator på modellprestanda, kanske det inte direkt översätts till ditt affärsbehov. Amazon Fraud Detector tillhandahåller också mätvärden såsom bedrägerifångstfrekvens (verklig positiv frekvens), procentandel av legitima händelser som felaktigt förutspås som bedrägeri (falsk positiv frekvens) och mer, som oftare används som affärskrav. När du har tränat en modell med en någorlunda bra AUC måste du jämföra modellen med ditt affärsbehov med dessa mätvärden.
Förvirringsmatrisen och tabellen ger dig ett gränssnitt för att granska effekten och kontrollera om den uppfyller dina affärsbehov. Observera att siffrorna beror på modelltröskeln, där händelser med poäng som är högre än tröskelvärdet klassificeras som bedrägeri och händelser med poäng lägre än tröskeln klassificeras som legitima. Du kan välja vilken tröskel du vill använda beroende på dina affärskrav.
Till exempel, om ditt mål är att fånga 73 % av bedrägerierna, kan du (som visas i exemplet nedan) välja en tröskel som 855, vilket gör att du kan fånga 73 % av alla bedrägerier. Men modellen kommer också att felklassificera 3 % legitima händelser som bedrägliga. Om denna FPR är acceptabel för ditt företag är modellen bra för implementering. Annars måste du förbättra modellens prestanda.
Ett annat exempel är om kostnaden för att blockera eller utmana en legitim kund är extremt hög, då vill man ha låg FPR och hög precision. I så fall kan du välja ett tröskelvärde på 950, som visas i följande exempel, vilket kommer att missklassificera 1 % av legitima kunder som bedrägerier, och 80 % av identifierade bedrägerier kommer faktiskt att vara bedrägliga.
Dessutom kan du välja flera trösklar och tilldela olika utfall, såsom blockera, undersöka, godkänna. Om du inte kan hitta rätt trösklar och regler som uppfyller alla dina affärskrav bör du överväga att träna din modell med mer data och attribut.
Kontrollera modellvariabelns betydelse
Smakämnen Modell variabel betydelse rutan visar hur varje variabel bidrar till din modell. Om en variabel har ett betydligt högre betydelsevärde än de andra, kan det tyda på att etiketten läcker eller att bedrägerimönstren är för lätta att upptäcka. Observera att variabelns betydelse aggregeras tillbaka till dina indatavariabler. Om du observerar något högre vikt av IP_ADDRESS
, CARD_BIN
, EMAIL_ADDRESS
, PHONE_NUMBER
, BILLING_ZIP
, eller SHIPPING_ZIP
, det kanske på grund av anrikningens kraft.
Följande exempel visar modellvariabel betydelse med ett potentiellt etikettläckage med hjälp av investigation_status
.
Modellvariabelns betydelse ger dig också tips om vilka ytterligare variabler som potentiellt kan ge modellen lyft. Om du till exempel observerar låg AUC och säljarrelaterade funktioner visar hög betydelse kan du överväga att samla in fler beställningsfunktioner som t.ex. SELLER_CATEGORY
, SELLER_ADDRESS
och SELLER_ACTIVE_YEARS
, och lägg till dessa variabler till din modell.
Vanliga problem för låg modellprestanda
I det här avsnittet diskuterar vi vanliga problem du kan stöta på när det gäller låg modellprestanda.
Historisk datafördelning har ändrats
Historisk datadistributionsdrift inträffar när du har en stor affärsförändring eller ett problem med datainsamling. Till exempel, om du nyligen lanserade din produkt på en ny marknad, IP_ADDRESS
, EMAIL
och ADDRESS
relaterade funktioner kan vara helt annorlunda, och bedrägerimetoden kan också ändras. Amazon Fraud Detector använder EVENT_TIMESTAMP
för att dela upp data och utvärdera din modell på lämplig delmängd av händelser i din datauppsättning. Om din historiska datafördelning ändras avsevärt, kan utvärderingsuppsättningen skilja sig mycket från träningsdata, och den rapporterade modellens prestanda kan vara låg.
Du kan kontrollera eventuella förändringar av datadistributionen genom att utforska dina historiska data:
- Använd Amazon Fraud Detector Data Profiler verktyg för att kontrollera om bedrägerifrekvensen och den saknade andelen av etiketten har förändrats över tiden.
- Kontrollera om variabelfördelningen över tiden förändrats avsevärt, särskilt för funktioner med hög variabelviktighet.
- Kontrollera variabelfördelningen över tid efter målvariabler. Om du observerar betydligt fler bedrägerihändelser från en kategori i de senaste uppgifterna, kanske du vill kontrollera om ändringen är rimlig med hjälp av dina affärsmässiga bedömningar.
Om du upptäcker att andelen saknas på etiketten är mycket hög eller att bedrägerifrekvensen konsekvent har sjunkit under de senaste datumen, kan det vara en indikator på att etiketter inte är helt mogna. Du bör utesluta de senaste uppgifterna eller vänta längre med att samla in de korrekta etiketterna och sedan träna om din modell.
Om du observerar en kraftig ökning av bedrägerifrekvensen och variabler på specifika datum, kanske du vill dubbelkolla om det är ett extremvärde eller datainsamlingsproblem. I så fall bör du ta bort dessa händelser och träna om modellen.
Om du upptäcker att den föråldrade informationen inte kan representera din nuvarande och framtida verksamhet, bör du utesluta den gamla dataperioden från utbildningen. Om du använder lagrade händelser i Amazon Fraud Detector kan du helt enkelt träna om en ny version och välja rätt datumintervall medan du konfigurerar träningsjobbet. Det kan också tyda på att bedrägerimetoden i ditt företag förändras relativt snabbt över tiden. Efter modelldistributionen kan du behöva träna om din modell ofta.
Felaktig mappning av variabeltyp
Amazon Fraud Detector berikar och transformerar data baserat på variabeltyperna. Det är viktigt att du mappar dina variabler till rätt typ så att Amazon Fraud Detector-modell kan ta det maximala värdet av din data. Till exempel om du kartlägger IP
till CATEGORICAL
typ istället för IP_ADDRESS
, du fattar inte IP-
relaterade anrikningar i backend.
I allmänhet föreslår Amazon Fraud Detector följande åtgärder:
- Mappa dina variabler till specifika typer, som t.ex
IP_ADDRESS
,EMAIL_ADDRESS
,CARD_BIN
ochPHONE_NUMBER
, så att Amazon Fraud Detector kan extrahera och berika ytterligare information. - Om du inte kan hitta den specifika variabeltypen, mappa den till en av de tre generiska typerna:
NUMERIC
,CATEGORICAL
, ellerFREE_FORM_TEXT
. - Om en variabel är i textform och har hög kardinalitet, såsom en kundrecension eller produktbeskrivning, bör du mappa den till
FREE_FORM_TEXT
variabel typ så att Amazon Fraud Detector extraherar textfunktioner och inbäddningar på backend åt dig. Till exempel om du kartläggerurl_string
tillFREE_FORM_TEXT
, kan den tokenisera webbadressen och extrahera information för att matas in i nedströmsmodellen, vilket hjälper den att lära sig fler dolda mönster från webbadressen.
Om du upptäcker att någon av dina variabeltyper är felaktigt mappade i variabelkonfigurationen kan du ändra din variabeltyp och sedan träna om modellen.
Otillräckliga data eller funktioner
Amazon Fraud Detector kräver minst 10,000 400 poster för att träna en Online Fraud Insights (OFI) eller Transaction Fraud Insights (TFI) modell, med minst 100 av dessa poster identifierade som bedrägliga. TFI kräver också att både bedrägliga poster och legitima poster kommer från minst XNUMX olika enheter var och en för att säkerställa mångfalden av datamängden. Dessutom kräver Amazon Fraud Detector att modelleringsdatan har minst två variabler. Det är minimikraven för data för att bygga en användbar Amazon Fraud Detector-modell. Men att använda fler poster och variabler hjälper vanligtvis ML-modellerna att bättre lära sig de underliggande mönstren från dina data. När du observerar en låg AUC eller inte kan hitta trösklar som uppfyller dina affärskrav bör du överväga att omskola din modell med mer data eller lägga till nya funktioner i din modell. Vanligtvis hittar vi EMAIL_ADDRESS
, IP
, PAYMENT_TYPE
, BILLING_ADDRESS
, SHIPPING_ADDRESS
och DEVICE
relaterade variabler är viktiga för att upptäcka bedrägerier.
En annan möjlig orsak är att vissa av dina variabler innehåller för många saknade värden. För att se om det händer, kontrollera modellträningsmeddelandena och hänvisa till Felsök problem med träningsdata för förslag.
Vanliga problem för mycket hög modellprestanda
I det här avsnittet diskuterar vi vanliga problem relaterade till mycket hög modellprestanda.
Etikettläckage
Etikettläckage uppstår när träningsdatauppsättningarna använder information som inte skulle förväntas vara tillgänglig vid förutsägelsetidpunkten. Den överskattar modellens användbarhet när den körs i en produktionsmiljö.
Hög AUC (nära 1), perfekt separerad poängfördelning och signifikant högre variabelvikt för en variabel kan vara indikatorer på potentiella problem med etikettläckage. Du kan också kontrollera korrelationen mellan funktionerna och etiketten med hjälp av Dataprofiler. De Korrelation mellan egenskaper och etiketter plot visar korrelationen mellan varje funktion och etiketten. Om en funktion har över 0.99 korrelation med etiketten, bör du kontrollera om funktionen används korrekt baserat på affärsmässiga bedömningar. Till exempel, för att bygga en riskmodell för att godkänna eller avslå en låneansökan, bör du inte använda funktioner som AMOUNT_PAID
, eftersom betalningarna sker efter emissionsprocessen. Om en variabel inte är tillgänglig vid den tidpunkt då du gör förutsägelse bör du ta bort den variabeln från modellkonfigurationen och träna om en ny modell.
Följande exempel visar korrelationen mellan varje variabel och etikett. investigation_status
har en hög korrelation (nära 1) med etiketten, så du bör dubbelkolla om det finns ett problem med etikettläckage.
Enkla bedrägerimönster
När bedrägerimönstren i dina data är enkla kan du också observera mycket hög modellprestanda. Anta till exempel att alla bedrägerihändelser i modelleringsdata kommer via samma interna tjänsteleverantör; det är enkelt för modellen att välja IP-
relaterade variabler och returnera en "perfekt" modell med hög vikt av IP
.
Enkla bedrägerimönster indikerar inte alltid ett dataproblem. Det kan vara sant att bedrägerimetoden i ditt företag är lätt att fånga. Innan du drar en slutsats måste du dock se till att etiketterna som används i modellutbildningen är korrekta och att modelleringsdata täcker så många bedrägerimönster som möjligt. Till exempel om du märker dina bedrägerihändelser baserat på regler, som att märka alla ansökningar från en specifik BILLING_ZIP
plus PRODUCT_CATEGORY
som bedrägeri kan modellen enkelt fånga dessa bedrägerier genom att simulera reglerna och uppnå en hög AUC.
Du kan kontrollera etikettfördelningen över olika kategorier eller papperskorgar för varje funktion med hjälp av Dataprofiler. Om du till exempel observerar att de flesta bedrägerihändelser kommer från en eller några produktkategorier kan det vara en indikator på enkla bedrägerimönster, och du måste bekräfta att det inte är ett datainsamlings- eller processmisstag. Om funktionen är som CUSTOMER_ID
, bör du utesluta funktionen i modellträning.
Följande exempel visar etikettfördelning över olika kategorier av product_category
. Allt bedrägeri kommer från två produktkategorier.
Felaktig datasampling
Felaktig datasampling kan inträffa när du samplade och bara skickade en del av din data till Amazon Fraud Detector. Om data inte är korrekt samplade och inte är representativ för trafiken i produktionen kommer den rapporterade modellens prestanda att vara felaktig och modellen kan vara värdelös för produktionsförutsägelse. Till exempel, om alla bedrägerihändelser i modelleringsdata är samplade från Asien och alla legitima händelser är samplade från USA, kan modellen lära sig att separera bedrägeri och legit baserat på BILLING_COUNTRY
. I så fall är modellen inte generisk för att tillämpas på andra populationer.
Vanligtvis föreslår vi att du skickar alla de senaste händelserna utan provtagning. Baserat på datastorleken och bedrägerifrekvensen gör Amazon Fraud Detector provtagning innan modellträning för dig. Om din data är för stor (över 100 GB) och du bestämmer dig för att ta ett urval och bara skicka en delmängd, bör du slumpmässigt ta ett urval av dina data och se till att urvalet är representativt för hela populationen. För TFI bör du sampla dina data per enhet, vilket innebär att om en enhet samplas bör du inkludera all dess historik så att aggregaten på enhetsnivån beräknas korrekt. Observera att om du bara skickar en delmängd av data till Amazon Fraud Detector, kan realtidsaggregaten under slutledning vara felaktiga om de tidigare händelserna för enheterna inte skickas.
En annan felaktig datasampling kan vara att bara använda en kort period av data, som en dags data, för att bygga modellen. Uppgifterna kan vara partiska, särskilt om ditt företag eller bedrägerisattacker har säsongsvariationer. Vi rekommenderar vanligtvis att inkludera minst två cykler (som 2 veckor eller 2 månader) av data i modelleringen för att säkerställa mångfalden av bedrägerityper.
Slutsats
Efter att ha diagnostiserat och löst alla potentiella problem bör du skaffa en användbar Amazon Fraud Detector-modell och vara säker på dess prestanda. För nästa steg, du kan skapa en detektor med modellen och dina affärsregler, och var redo att distribuera den till produktion för en skugglägesutvärdering.
Appendix
Hur man utesluter variabler för modellträning
Efter djupdykningen kan du identifiera en variabel läckagemålinformation och vill utesluta den från modellträning. Du kan träna om en modellversion som exkluderar de variabler du inte vill ha genom att utföra följande steg:
- På Amazon Fraud Detector-konsolen, i navigeringsfönstret, välj Modeller.
- På Modeller sida, välj den modell du vill omskola.
- På Handlingar meny, välj Träna ny version.
- Välj det datumintervall du vill använda och välj Nästa.
- På Konfigurera träning sida, avmarkera variabeln du inte vill använda i modellträning.
- Ange dina bedrägerietiketter och legitima etiketter och hur du vill att Amazon Fraud Detector ska använda omärkta händelser och välj sedan Nästa.
- Granska modellkonfigurationen och välj Skapa och träna modell.
Hur man ändrar typ av händelsevariabel
Variabler representerar dataelement som används för att förebygga bedrägeri. I Amazon Fraud Detector är alla variabler globala och delas över alla händelser och modeller, vilket innebär att en variabel kan användas i flera händelser. Till exempel kan IP associeras med inloggningshändelser, och det kan också associeras med transaktionshändelser. Naturligtvis låste Amazon Fraud Detector variabeltypen och datatypen när en variabel har skapats. För att ta bort en befintlig variabel måste du först ta bort alla associerade händelsetyper och modeller. Du kan kontrollera resurserna som är kopplade till den specifika variabeln genom att navigera till Amazon Fraud Detector och välja variabler i navigeringsfönstret och välja variabelnamnet och Tillhörande resurser.
Ta bort variabeln och alla associerade händelsetyper
Utför följande steg för att ta bort variabeln:
- På Amazon Fraud Detector-konsolen, i navigeringsfönstret, välj variabler.
- Välj den variabel du vill ta bort.
- Välja Tillhörande resurser för att se en lista över alla händelsetyper som användes av denna variabel.
Du måste ta bort de associerade händelsetyperna innan du tar bort variabeln. - Välj händelsetyperna i listan för att gå till den associerade händelsetypsidan.
- Välja Lagrade händelser för att kontrollera om någon data lagras under denna händelsetyp.
- Om det finns händelser lagrade i Amazon Fraud Detector, välj Ta bort lagrade händelser för att radera de lagrade händelserna.
När borttagningsjobbet är klart visas meddelandet "De lagrade händelserna för denna händelsetyp raderades framgångsrikt". - Välja Tillhörande resurser.
Om detektorer och modeller är associerade med denna händelsetyp måste du först radera dessa resurser. - Om detektorer är associerade, utför följande steg för att ta bort alla associerade detektorer:
- Välj detektorn att gå till Detektordetaljer sida.
- I Modellversioner rutan, välj detektorns version.
- Välj på sidan för detektorversionen Handlingar.
- Om detektorversionen är aktiv, välj Avaktiveraväljer Inaktivera denna detektorversion utan att ersätta den med en annan version, och välj Inaktivera detektorversion.
- När detektorversionen har avaktiverats, välj Handlingar och då Radera.
- Upprepa dessa steg för att ta bort alla detektorversioner.
- På Detektordetaljer sida, välj Tillhörande regler.
- Välj regeln som ska raderas.
- Välja Handlingar och Ta bort regelversion.
- Ange regelnamnet för att bekräfta och välja Ta bort version.
- Upprepa dessa steg för att ta bort alla associerade regler.
- Efter att alla detektorversioner och tillhörande regler har raderats, gå till Detektordetaljer sida, välj Handlingar, och välj Ta bort detektor.
- Ange detektorns namn och välj Ta bort detektor.
- Upprepa dessa steg för att radera nästa detektor.
- Om några modeller är associerade med händelsetypen, utför följande steg för att ta bort dem:
- Välj namnet på modellen.
- I Modellversioner rutan, välj version.
- Om modellstatus är
Active
väljer Handlingar och Avinstallera modellversion. - ange
undeploy
för att bekräfta och välja Avinstallera modellversion.
Statusen ändras tillUndeploying
. Processen tar några minuter att slutföra. - Efter status blir
Ready to deploy
, välj Åtgärder och Ta bort. - Upprepa dessa steg för att ta bort alla modellversioner.
- På sidan Modelldetaljer väljer du Åtgärder och Ta bort modell.
- Ange namnet på modellen och välj Ta bort modell.
- Upprepa dessa steg för att ta bort nästa modell.
- När alla associerade detektorer och modeller har raderats, välj Handlingar och Ta bort händelsetyp på Evenemangsdetaljer sida.
- Ange namnet på händelsetypen och välj Ta bort händelsetyp.
- Välj i navigeringsfönstret variableroch välj den variabel du vill ta bort.
- Upprepa de tidigare stegen för att ta bort alla händelsetyper som är associerade med variabeln.
- På Varierande detaljer sida, välj Handlingar och Ta bort.
- Ange namnet på variabeln och välj Ta bort variabel.
Skapa en ny variabel med rätt variabeltyp
Efter att du har tagit bort variabeln och alla associerade händelsetyper, lagrade händelser, modeller och detektorer från Amazon Fraud Detector kan du skapa en ny variabel med samma namn och mappa den till rätt variabeltyp.
- På Amazon Fraud Detector-konsolen, i navigeringsfönstret, välj variabler.
- Välja Skapa.
- Ange variabelnamnet du vill ändra (det du raderade tidigare).
- Välj rätt variabeltyp du vill ändra till.
- Välja Skapa variabel.
Ladda upp data och träna om modellen
När du har uppdaterat variabeltypen kan du ladda upp data igen och träna en ny modell. För instruktioner, se Upptäck onlinetransaktionsbedrägeri med nya Amazon Fraud Detector-funktioner.
Hur man lägger till nya variabler till en befintlig händelsetyp
För att lägga till nya variabler till den befintliga händelsetypen, utför följande steg:
- Lägg till de nya variablerna till den tidigare tränings-CVS-filen.
- Ladda upp den nya träningsdatafilen till en S3-hink. Notera Amazon S3-platsen för din träningsfil (till exempel,
s3://bucketname/path/to/some/object.csv
) och ditt rollnamn. - På Amazon Fraud Detector-konsolen, i navigeringsfönstret, välj Evenemang.
- På Händelsetyper sida, välj namnet på händelsetypen du vill lägga till variabler.
- På Event typ informationssida, välj Handlingaroch sedan Lägg till variabler.
- Enligt Välj hur du definierar händelsens variablerväljer Välj variabler från ett träningsdataset.
- För IAM-roll, välj en befintlig IAM-roll eller skapa en ny roll för att komma åt data i Amazon S3.
- För Dataläge, ange S3-platsen för den nya träningsfilen och välj Ladda upp.
De nya variablerna som inte finns i den befintliga händelsetypen bör visas i listan.
- Välja Lägg till variabler.
Nu har de nya variablerna lagts till den befintliga händelsetypen. Om du använder lagrade händelser i Amazon Fraud Detector, saknas fortfarande de nya variablerna för de lagrade händelserna. Du måste importera träningsdata med de nya variablerna till Amazon Fraud Detector och sedan träna om en ny modellversion. När du laddar upp den nya träningsdatan med densamma EVENT_ID
och EVENT_TIMESTAMP
, skriver de nya händelsevariablerna över de tidigare händelsevariablerna som lagrats i Amazon Fraud Detector.
Om författarna
Julia Xu är en forskare med Amazon Fraud Detector. Hon brinner för att lösa kunders utmaningar med hjälp av maskininlärningsteknik. På fritiden tycker hon om att vandra, måla och utforska nya kaféer.
Hao Zhou är en forskare med Amazon Fraud Detector. Han har en doktorsexamen i elektroteknik från Northwestern University, USA. Han brinner för att tillämpa maskininlärningstekniker för att bekämpa bedrägerier och missbruk.
Abhishek Ravi är senior produktchef med Amazon Fraud Detector. Han brinner för att utnyttja teknisk kapacitet för att bygga produkter som gläder kunderna.
- "
- 000
- 10
- 100
- 20 år
- 9
- a
- förmåga
- Om oss
- tillgång
- i enlighet med detta
- Konto
- exakt
- tvärs
- åtgärder
- aktiv
- aktiviteter
- lagt till
- Dessutom
- Annat
- Antagande
- avancerat
- algoritmer
- Alla
- tillåter
- alltid
- amason
- tillämplig
- Ansökan
- tillämpningar
- tillämpas
- Tillämpa
- tillvägagångssätt
- tillvägagångssätt
- lämpligt
- godkänna
- OMRÅDE
- asien
- associerad
- uppmärksamhet
- attribut
- Automatiserad
- tillgänglig
- AWS
- Baslinje
- därför att
- innan
- nedan
- Bättre
- mellan
- Blockera
- gränsen
- föra
- SLUTRESULTAT
- företag
- beräknat
- kapacitet
- fånga
- vilken
- Vid
- fall
- brottning
- Kategori
- Orsak
- vissa
- utmaningar
- utmanande
- byta
- Välja
- klassificerad
- Kaffe
- Coin
- samla
- Samla
- samling
- bekämpa
- komma
- Gemensam
- fullborda
- fullständigt
- fullborda
- säker
- konfiguration
- förvirring
- Tänk
- Konsol
- Bekväm
- kunde
- skapa
- skapas
- Aktuella
- kurva
- kund
- Kunder
- datum
- Datum
- djup
- beroende
- beror
- distribuera
- utplacera
- utplacering
- beskrivning
- detaljer
- Detektering
- olika
- digital
- direkt
- diskutera
- displayer
- fördelning
- Distributioner
- Mångfald
- inte
- tappade
- under
- varje
- lätt
- element
- början till slut
- slutar
- Teknik
- berika
- ange
- enheter
- enhet
- Miljö
- speciellt
- utvärdera
- utvärdering
- händelse
- händelser
- exempel
- exklusive
- befintliga
- förvänta
- förväntat
- expertis
- extrakt
- snabbare
- Leverans
- Funktioner
- Slutligen
- Förnamn
- följer
- efter
- formen
- bedrägeri
- Fri
- från
- fungera
- framtida
- Allmänt
- genereras
- Välgörenhet
- Målet
- god
- större
- Grön
- Tillväxt
- hända
- hjälpa
- hjälp
- hjälper
- Hög
- högre
- höggradigt
- historisk
- historia
- innehar
- Hur ser din drömresa ut
- How To
- Men
- HTTPS
- identifiera
- Inverkan
- vikt
- med Esport
- förbättra
- förbättring
- innefattar
- Inklusive
- indikerar
- informationen
- ingång
- insikter
- Gränssnitt
- Internet
- undersöka
- IP
- fråga
- problem
- IT
- Jobb
- domar
- Vet
- kunskap
- etikett
- märkning
- Etiketter
- Large
- större
- senaste
- lanserades
- läckage
- LÄRA SIG
- inlärning
- Nivå
- hävstångs
- Lista
- Noterade
- läge
- låst
- Maskinen
- maskininlärning
- göra
- Framställning
- förvaltade
- chef
- karta
- marknad
- Matris
- betyder
- meddelanden
- Metrics
- kanske
- minsta
- ML
- modell
- modeller
- månader
- mer
- mest
- multipel
- navigerande
- Navigering
- behov
- negativ
- Nya funktioner
- New Market
- Nästa
- antal
- nummer
- Erbjudanden
- nätet
- Operatören
- beställa
- Övriga
- annat
- övergripande
- del
- brinner
- betalningar
- procentuell
- prestanda
- perioden
- Punkt
- befolkning
- positiv
- möjlig
- potentiell
- kraft
- förutsägelse
- presentera
- Förebyggande
- föregående
- primär
- problem
- process
- Produkt
- Produktion
- Produkter
- ge
- förutsatt
- leverantör
- ger
- snabbt
- område
- realtid
- rimlig
- senaste
- nyligen
- rekommenderar
- register
- reflektera
- om
- representerar
- representativ
- representerar
- Krav
- Kräver
- forskning
- Resurser
- avkastning
- återgår
- översyn
- stigande
- Risk
- Roll
- regler
- Körning
- Samma
- Skala
- Forskare
- vald
- service
- in
- skugga
- delas
- affärer
- Kort
- show
- visas
- Enkelt
- Storlek
- So
- fast
- Lösa
- några
- specifik
- delas
- igång
- statistik
- status
- Fortfarande
- förvaring
- Strategi
- Framgångsrikt
- Målet
- Teknisk
- tekniker
- mallar
- testa
- Testning
- Smakämnen
- tre
- tröskelvärde
- Genom
- tid
- verktyg
- topp
- TPR
- trafik
- Tåg
- Utbildning
- transaktion
- transformationer
- typer
- typiskt
- under
- förstå
- universitet
- Uppdatering
- us
- USA
- användning
- användare
- vanligen
- verktyg
- godkännande
- värde
- version
- utsikt
- vänta
- Vad
- om
- medan
- utan
- värt
- skulle
- år
- år
- Din