I de sidste omkring seks måneder har jeg lavet et system til at bekæmpe bedrageri (svigagtig aktivitet, bedrageri osv.) uden nogen indledende infrastruktur til dette. Dagens idéer, som vi har fundet og implementeret i vores system, hjælper os med at opdage og analysere mange svigagtige aktiviteter. I denne artikel vil jeg gerne tale om de principper, vi fulgte, og hvad vi gjorde for at opnå den nuværende tilstand af vores system, uden at gå ind i den tekniske del.
Principper for vores system
Når du hører udtryk som "automatisk" og "svindel", begynder du højst sandsynligt at tænke på maskinlæring, Apache Spark, Hadoop, Python, Airflow og andre teknologier fra Apache Foundation-økosystemet og Data Science-feltet. Jeg tror, der er et aspekt ved at bruge disse værktøjer, som normalt ikke bliver nævnt: de kræver visse forudsætninger i dit virksomhedssystem, før du kan begynde at bruge dem. Kort sagt, du har brug for en virksomhedsdataplatform, der inkluderer en datasø og et lager. Men hvad hvis du ikke har sådan en platform og stadig skal udvikle denne praksis? Følgende principper, som jeg deler nedenfor, har hjulpet os med at nå et punkt, hvor vi kan fokusere på at forbedre vores ideer i stedet for at finde en, der virker. Dette er dog ikke et projektplateau. Der er stadig mange ting i planen ud fra et teknologisk og produktmæssigt synspunkt.
Princip 1: Forretningsværdi først
Vi sætter "forretningsværdi" i højsædet i alle vores bestræbelser. Generelt hører ethvert automatisk analysesystem til gruppen af komplekse systemer med et højt niveau af automatisering og teknisk kompleksitet. At skabe en komplet løsning vil tage meget tid, hvis du laver den fra bunden. Vi besluttede at sætte forretningsværdi først og teknologisk fuldstændighed i anden række. I det virkelige liv betyder det, at vi ikke accepterer avanceret teknologi som dogme. Vi vælger den teknologi, der fungerer bedst for os i øjeblikket. Med tiden kan det se ud til, at vi bliver nødt til at genimplementere nogle moduler. Det er det kompromis, vi accepterede.
Princip 2: Øget intelligens
Jeg vil vædde på, at de fleste mennesker, der ikke er dybt involveret i at udvikle maskinlæringsløsninger, måske tror, at det er målet at erstatte mennesker. Faktisk er maskinlæringsløsninger langt fra perfekte, og kun på visse områder er udskiftning mulig. Vi afviste denne idé fra starten af flere grunde: ubalancerede data om svigagtig aktivitet og manglende evne til at levere en omfattende liste over funktioner til maskinlæringsmodeller. I modsætning hertil valgte vi muligheden for forbedret intelligens. Dette er et alternativt koncept for kunstig intelligens, der fokuserer på AIs understøttende rolle, og understreger det faktum, at kognitive teknologier har til formål at forbedre menneskelig intelligens i stedet for at erstatte den. [1]
I lyset af dette vil udvikling af en komplet maskinlæringsløsning fra starten kræve en enorm indsats, hvilket ville forsinke skabelsen af værdi for vores virksomhed. Vi besluttede at bygge et system med et iterativt voksende maskinlæringsaspekt under vejledning af vores domæneeksperter. Den udfordrende del af at udvikle et sådant system er, at det skal give vores analytikere sager, ikke kun med hensyn til, om det er svigagtig aktivitet eller ej. Generelt er enhver anomali i kundeadfærd et mistænkeligt tilfælde, som specialister skal undersøge og reagere på en eller anden måde. Kun en brøkdel af disse rapporterede sager kan virkelig klassificeres som bedrageri.
Princip 3: Rich Analytics Platform
Den mest udfordrende del af vores system er ende-til-ende-verifikation af systemets arbejdsgang. Analytikere og udviklere bør nemt få historiske datasæt med alle de målinger, der bruges til analyse. Derudover bør dataplatformen give en nem måde at komplementere et eksisterende sæt metrics med nye. De processer, vi opretter, og disse er ikke kun softwareprocesser, skulle give os mulighed for nemt at genberegne tidligere perioder, tilføje nye metrics og ændre dataprognosen. Det kunne vi opnå ved at samle alle de data, som vores produktionssystem genererer. I dette tilfælde vil dataene gradvist blive til gene. Vi bliver nødt til at gemme en voksende mængde data, som vi ikke bruger, og beskytte dem. I et sådant scenarie vil data blive mere og mere irrelevante over tid, men det kræver stadig vores indsats for at administrere dem. For os gav datahamstring ikke mening, så vi besluttede at tage en anden tilgang. Vi besluttede at organisere realtidsdatalagre omkring de målenheder, som vi ønsker at klassificere, og kun gemme de data, der giver os mulighed for at kontrollere de seneste og relevante perioder. Udfordringen ved denne indsats er, at vores system er heterogent med flere datalagre og softwaremoduler, der kræver omhyggelig planlægning for at fungere på en ensartet måde.
Designkoncepter for vores system
Vi har fire hovedkomponenter i vores system: indtagelsessystem, beregningssystem, BI-analyse og sporingssystem. De tjener specifikke, isolerede formål, og vi holder dem isolerede ved at følge specifikke designtilgange.
Kontraktbaseret design
Først og fremmest blev vi enige om, at komponenter kun skulle være afhængige af bestemte datastrukturer (kontrakter), der sendes mellem dem. Dette gør det nemt at integrere mellem dem og ikke påtvinge en specifik sammensætning (og rækkefølge) af komponenter. For eksempel giver dette os i nogle tilfælde mulighed for direkte at integrere indsugningssystemet med alarmsporingssystemet. I så fald vil dette ske i overensstemmelse med den aftalte alarmkontrakt. Det betyder, at begge komponenter vil blive integreret ved hjælp af en kontrakt, som enhver anden komponent kan bruge. Vi vil ikke tilføje en ekstra kontrakt for at tilføje alarmer til sporingssystemet fra inputsystemet. Denne tilgang kræver brug af et forudbestemt minimumsantal af kontrakter og forenkler systemet og kommunikationen. Grundlæggende tager vi en tilgang kaldet "Contract First Design" og anvender den på streamingkontrakter. [2]
Streamer overalt
Lagring og styring af tilstand i et system vil uundgåeligt føre til komplikationer i dets implementering. Generelt skal tilstand være tilgængelig fra enhver komponent, den skal være konsistent og give den mest aktuelle værdi på tværs af alle komponenter, og den skal være pålidelig med de korrekte værdier. Derudover vil opkald til vedvarende lagring for at hente den seneste tilstand øge antallet af I/O-operationer og kompleksiteten af de algoritmer, der bruges i vores realtidspipelines. På grund af dette besluttede vi at fjerne statens opbevaring, hvis det var muligt, helt fra vores system. Denne tilgang kræver, at alle nødvendige data inkluderes i den transmitterede datablok (meddelelse). For eksempel, hvis vi skal beregne det samlede antal af nogle observationer (antallet af operationer eller tilfælde med visse karakteristika), beregner vi det i hukommelsen og genererer en strøm af sådanne værdier. Afhængige moduler vil bruge partition og batching til at opdele strømmen i entiteter og operere på de seneste værdier. Denne tilgang eliminerede behovet for at have vedvarende disklagring til sådanne data. Vores system bruger Kafka som meddelelsesmægler, og det kan bruges som en database med KSQL. [3] Men at bruge det ville have bundet vores løsning stærkt til Kafka, og vi besluttede ikke at bruge det. Den tilgang, vi valgte, giver os mulighed for at erstatte Kafka med en anden meddelelsesmægler uden større interne ændringer i systemet.
Dette koncept betyder ikke, at vi ikke bruger disklager og databaser. For at teste og analysere systemets ydeevne skal vi gemme en betydelig mængde data på disken, der repræsenterer forskellige metrikker og tilstande. Det vigtige her er, at realtidsalgoritmer ikke afhænger af sådanne data. I de fleste tilfælde bruger vi de lagrede data til offline analyse, fejlretning og sporing af specifikke sager og resultater, som systemet producerer.
Problemer med vores system
Der er visse problemer, som vi har løst til et vist niveau, men de kræver mere gennemtænkte løsninger. Nu vil jeg lige nævne dem her, fordi hvert punkt er sin egen artikel værd.
- Vi mangler stadig at definere processer og politikker, der understøtter akkumulering af meningsfulde og relevante data til vores automatiserede dataanalyse, opdagelse og udforskning.
- Inkorporering af menneskelige analyseresultater i processen med automatisk opsætning af systemet til at opdatere det med de seneste data. Dette er ikke kun en opdatering af vores model, men også en opdatering af vores processer og en forbedring af vores forståelse af vores data.
- At finde en balance mellem den deterministiske tilgang af IF-ELSE og ML. Nogen sagde, "ML er et værktøj for de desperate." Det betyder, at du vil bruge ML, når du ikke længere forstår, hvordan du optimerer og forbedrer dine algoritmer. På den anden side tillader den deterministiske tilgang ikke påvisning af anomalier, der ikke var forudset.
- Vi har brug for en enkel måde at teste vores hypoteser eller sammenhænge mellem metrik i dataene.
- Systemet skal have flere niveauer af ægte positive resultater. Svigsager er kun en brøkdel af alle sager, der kan betragtes som positive for systemet. For eksempel ønsker analytikere at modtage alle mistænkelige sager til verifikation, og kun en lille del af dem er svindel. Systemet skal effektivt præsentere alle sager for analytikere, uanset om det er faktisk svindel eller blot mistænkelig adfærd.
- Dataplatformen skal være i stand til at hente historiske datasæt med beregninger genereret og beregnet i farten.
- Implementer nemt og automatisk enhver af systemkomponenterne i mindst tre forskellige miljøer: produktion, eksperimentel (beta) og for udviklere.
- Og sidst men ikke mindst. Vi skal bygge en rig platform til test af ydeevne, hvorpå vi kan analysere vores modeller. [4]
RЎSЃS <P "RєRё
Kilde: www.habr.com