De siste seks månedene har jeg laget et system for å bekjempe svindel (svindel, svindel, etc.) uten noen innledende infrastruktur for dette. Dagens ideer som vi har funnet og implementert i systemet vårt hjelper oss med å oppdage og analysere mange uredelige aktiviteter. I denne artikkelen vil jeg gjerne snakke om prinsippene vi fulgte og hva vi gjorde for å oppnå den nåværende tilstanden til systemet vårt, uten å gå inn på den tekniske delen.
Prinsipper for systemet vårt
Når du hører begreper som "automatisk" og "svindel", begynner du mest sannsynlig å tenke på maskinlæring, Apache Spark, Hadoop, Python, Airflow og andre teknologier fra Apache Foundation-økosystemet og Data Science-feltet. Jeg tror det er ett aspekt ved å bruke disse verktøyene som vanligvis ikke blir nevnt: de krever visse forutsetninger i bedriftssystemet før du kan begynne å bruke dem. Kort sagt, du trenger en bedriftsdataplattform som inkluderer en datainnsjø og et lager. Men hva om du ikke har en slik plattform og fortsatt trenger å utvikle denne praksisen? Følgende prinsipper som jeg deler nedenfor, har hjulpet oss å nå et punkt der vi kan fokusere på å forbedre ideene våre i stedet for å finne en som fungerer. Dette er imidlertid ikke et prosjektplatå. Det er fortsatt mange ting i planen fra et teknologisk og produktmessig synspunkt.
Prinsipp 1: Forretningsverdi først
Vi setter "forretningsverdi" i forkant av all vår innsats. Generelt hører ethvert automatisk analysesystem til gruppen av komplekse systemer med høy grad av automatisering og teknisk kompleksitet. Å lage en komplett løsning vil ta mye tid hvis du lager den fra bunnen av. Vi bestemte oss for å sette forretningsverdi først og teknologisk fullstendighet på andreplass. I det virkelige liv betyr dette at vi ikke aksepterer avansert teknologi som dogme. Vi velger den teknologien som fungerer best for oss for øyeblikket. Over tid kan det se ut til at vi må implementere noen moduler på nytt. Dette er kompromisset vi godtok.
Prinsipp 2: Økt intelligens
Jeg vedder på at de fleste som ikke er dypt involvert i å utvikle løsninger for maskinlæring kanskje tror at målet er å erstatte mennesker. Faktisk er maskinlæringsløsninger langt fra perfekte, og bare på visse områder er erstatning mulig. Vi avviste denne ideen fra starten av av flere grunner: ubalanserte data om uredelig aktivitet og manglende evne til å gi en omfattende liste over funksjoner for maskinlæringsmodeller. Derimot valgte vi alternativet for forbedret intelligens. Dette er et alternativt konsept for kunstig intelligens som fokuserer på støtterollen til AI, og understreker det faktum at kognitive teknologier er ment å forbedre menneskelig intelligens i stedet for å erstatte den. [1]
Gitt dette vil det kreve en enorm innsats å utvikle en komplett maskinlæringsløsning fra starten, noe som vil forsinke verdiskapingen for virksomheten vår. Vi bestemte oss for å bygge et system med et iterativt voksende maskinlæringsaspekt under veiledning av våre domeneeksperter. Den utfordrende delen av å utvikle et slikt system er at det må gi våre analytikere saker ikke bare når det gjelder om det er svindel eller ikke. Generelt er enhver anomali i kundeadferd et mistenkelig tilfelle som spesialister må undersøke og svare på en eller annen måte. Bare en brøkdel av disse rapporterte tilfellene kan virkelig klassifiseres som svindel.
Prinsipp 3: Rich Analytics-plattform
Den mest utfordrende delen av systemet vårt er ende-til-ende verifisering av systemets arbeidsflyt. Analytikere og utviklere bør enkelt få tak i historiske datasett med alle beregningene som brukes for analyse. I tillegg bør dataplattformen gi en enkel måte å komplementere et eksisterende sett med beregninger med nye. Prosessene vi oppretter, og disse er ikke bare programvareprosesser, skal gjøre det mulig for oss å enkelt beregne tidligere perioder på nytt, legge til nye beregninger og endre dataprognosen. Vi kunne oppnå dette ved å samle all data som produksjonssystemet vårt genererer. I dette tilfellet vil dataene gradvis bli en plage. Vi må lagre en økende mengde data som vi ikke bruker og beskytte dem. I et slikt scenario vil data bli mer og mer irrelevant over tid, men krever fortsatt vår innsats for å administrere dem. For oss var datahamstring ikke fornuftig, så vi bestemte oss for å ta en annen tilnærming. Vi bestemte oss for å organisere sanntidsdatalagre rundt målenhetene som vi ønsker å klassifisere, og lagre bare dataene som lar oss sjekke de nyeste og relevante periodene. Utfordringen til denne innsatsen er at systemet vårt er heterogent, med flere datalagre og programvaremoduler som krever nøye planlegging for å fungere på en konsistent måte.
Designkonsepter for systemet vårt
Vi har fire hovedkomponenter i systemet vårt: inntakssystem, beregningssystem, BI-analyse og sporingssystem. De tjener spesifikke, isolerte formål, og vi holder dem isolert ved å følge spesifikke designtilnærminger.
Kontraktsbasert design
Først og fremst ble vi enige om at komponenter kun skulle stole på visse datastrukturer (kontrakter) som sendes mellom dem. Dette gjør det enkelt å integrere mellom dem og ikke pålegge en spesifikk sammensetning (og rekkefølge) av komponenter. For eksempel lar dette oss i noen tilfeller direkte integrere inntakssystemet med varslingssporingssystemet. Dette vil i så fall skje i henhold til avtalt varslingskontrakt. Dette betyr at begge komponentene vil bli integrert ved hjelp av en kontrakt som enhver annen komponent kan bruke. Vi vil ikke legge til en tilleggskontrakt for å legge til varsler til sporingssystemet fra inndatasystemet. Denne tilnærmingen krever bruk av et forhåndsbestemt minimum antall kontrakter og forenkler systemet og kommunikasjonen. I hovedsak tar vi en tilnærming kalt "Contract First Design" og bruker den på strømmekontrakter. [2]
Streamer overalt
Lagring og administrasjon av tilstand i et system vil uunngåelig føre til komplikasjoner i implementeringen. Generelt bør tilstand være tilgjengelig fra enhver komponent, den bør være konsistent og gi den mest aktuelle verdien på tvers av alle komponenter, og den bør være pålitelig med de riktige verdiene. I tillegg vil det å ha anrop til vedvarende lagring for å hente den nyeste tilstanden øke antallet I/O-operasjoner og kompleksiteten til algoritmene som brukes i sanntidsrørledningene våre. På grunn av dette bestemte vi oss for å fjerne statlig lagring, hvis mulig, fullstendig fra systemet vårt. Denne tilnærmingen krever at alle nødvendige data inkluderes i den overførte datablokken (meldingen). For eksempel, hvis vi trenger å beregne det totale antallet observasjoner (antall operasjoner eller tilfeller med visse egenskaper), beregner vi det i minnet og genererer en strøm av slike verdier. Avhengige moduler vil bruke partisjon og batching for å dele strømmen i enheter og operere på de nyeste verdiene. Denne tilnærmingen eliminerte behovet for å ha vedvarende disklagring for slike data. Systemet vårt bruker Kafka som meldingsmegler og det kan brukes som en database med KSQL. [3] Men å bruke den ville ha knyttet løsningen vår sterkt til Kafka, og vi bestemte oss for å ikke bruke den. Tilnærmingen vi valgte gjør at vi kan erstatte Kafka med en annen meldingsmegler uten store interne endringer i systemet.
Dette konseptet betyr ikke at vi ikke bruker disklagring og databaser. For å teste og analysere systemytelsen, må vi lagre en betydelig mengde data på disken som representerer ulike beregninger og tilstander. Det viktige poenget her er at sanntidsalgoritmer ikke er avhengige av slike data. I de fleste tilfeller bruker vi de lagrede dataene til offline analyse, feilsøking og sporing av spesifikke saker og resultater som systemet produserer.
Problemer med systemet vårt
Det er visse problemer som vi har løst til et visst nivå, men de krever mer gjennomtenkte løsninger. Nå vil jeg bare nevne dem her fordi hvert punkt er verdt sin egen artikkel.
- Vi må fortsatt definere prosesser og retningslinjer som støtter akkumulering av meningsfulle og relevante data for vår automatiserte dataanalyse, oppdagelse og utforskning.
- Inkorporering av menneskelige analyseresultater i prosessen med å automatisk sette opp systemet for å oppdatere det med de nyeste dataene. Dette er ikke bare å oppdatere modellen vår, men også å oppdatere prosessene våre og forbedre forståelsen av dataene våre.
- Å finne en balanse mellom den deterministiske tilnærmingen til IF-ELSE og ML. Noen sa: "ML er et verktøy for de desperate." Dette betyr at du vil ønske å bruke ML når du ikke lenger forstår hvordan du kan optimalisere og forbedre algoritmene dine. På den annen side tillater ikke den deterministiske tilnærmingen påvisning av anomalier som ikke var forventet.
- Vi trenger en enkel måte å teste våre hypoteser eller korrelasjoner mellom beregninger i dataene.
- Systemet må ha flere nivåer av ekte positive resultater. Svindelsaker er kun en brøkdel av alle saker som kan anses som positive for systemet. For eksempel ønsker analytikere å motta alle mistenkelige saker for verifisering, og bare en liten del av dem er svindel. Systemet skal effektivt presentere alle saker for analytikere, uavhengig av om det er faktisk svindel eller bare mistenkelig oppførsel.
- Dataplattformen skal kunne hente ut historiske datasett med beregninger generert og beregnet i farten.
- Distribuer enkelt og automatisk hvilken som helst av systemkomponentene i minst tre forskjellige miljøer: produksjon, eksperimentell (beta) og for utviklere.
- Og sist men ikke minst. Vi må bygge en rik plattform for ytelsestesting der vi kan analysere modellene våre. [4]
referanser
Kilde: www.habr.com