Ek het die afgelope sowat ses maande 'n stelsel geskep om bedrog (bedrog, bedrog, ens.) te bekamp sonder enige aanvanklike infrastruktuur hiervoor. Vandag se idees wat ons gevind en in ons stelsel geïmplementeer het, help ons om baie bedrieglike aktiwiteite op te spoor en te ontleed. In hierdie artikel wil ek praat oor die beginsels wat ons gevolg het en wat ons gedoen het om die huidige toestand van ons stelsel te bereik, sonder om in die tegniese deel in te gaan.
Beginsels van ons stelsel
Wanneer jy terme soos "outomaties" en "bedrog" hoor, begin jy heel waarskynlik aan masjienleer, Apache Spark, Hadoop, Python, Airflow en ander tegnologieë uit die Apache Foundation-ekosisteem en die Data Science-veld dink. Ek dink daar is een aspek van die gebruik van hierdie instrumente wat gewoonlik nie genoem word nie: dit vereis sekere voorvereistes in jou ondernemingstelsel voordat jy dit kan begin gebruik. Kortom, jy benodig 'n ondernemingsdataplatform wat 'n datameer en pakhuis insluit. Maar wat as jy nie so 'n platform het nie en steeds hierdie praktyk moet ontwikkel? Die volgende beginsels wat ek hieronder deel, het ons gehelp om 'n punt te bereik waar ons kan fokus op die verbetering van ons idees eerder as om een te vind wat werk. Dit is egter nie 'n projekplato nie. Daar is nog baie dinge in die plan uit 'n tegnologiese en produk-oogpunt.
Beginsel 1: Besigheidswaarde eerste
Ons plaas "besigheidswaarde" op die voorpunt van al ons pogings. Oor die algemeen behoort enige outomatiese ontledingstelsel tot die groep komplekse stelsels met 'n hoë vlak van outomatisering en tegniese kompleksiteit. Die skep van 'n volledige oplossing sal baie tyd neem as jy dit van nuuts af skep. Ons het besluit om besigheidswaarde eerste te stel en tegnologiese volledigheid tweede. In die werklike lewe beteken dit dat ons nie gevorderde tegnologie as dogma aanvaar nie. Ons kies die tegnologie wat op die oomblik die beste vir ons werk. Met verloop van tyd kan dit lyk asof ons sommige modules sal moet herimplementeer. Dit is die kompromie wat ons aanvaar het.
Beginsel 2: Verhoogde intelligensie
Ek wed dat die meeste mense wat nie diep betrokke is by die ontwikkeling van masjienleeroplossings nie dalk dink dat die vervanging van mense die doel is. Trouens, masjienleeroplossings is ver van perfek en slegs in sekere gebiede is vervanging moontlik. Ons het hierdie idee van die begin af om verskeie redes verwerp: ongebalanseerde data oor bedrieglike aktiwiteite en die onvermoë om 'n omvattende lys kenmerke vir masjienleermodelle te verskaf. Daarteenoor het ons die verbeterde intelligensie-opsie gekies. Dit is 'n alternatiewe konsep van kunsmatige intelligensie wat fokus op die ondersteunende rol van KI, wat die feit beklemtoon dat kognitiewe tegnologieë bedoel is om menslike intelligensie te verbeter eerder as om dit te vervang. [1]
Gegewe dit, sou die ontwikkeling van 'n volledige masjienleeroplossing van die begin af 'n groot poging verg, wat die skepping van waarde vir ons besigheid sou vertraag. Ons het besluit om 'n stelsel te bou met 'n iteratief groeiende masjienleer-aspek onder leiding van ons domeinkundiges. Die uitdagende deel van die ontwikkeling van so 'n stelsel is dat dit ons ontleders van gevalle moet voorsien, nie net in terme van of dit bedrieglike aktiwiteit is of nie. Oor die algemeen is enige anomalie in kliëntgedrag 'n verdagte saak wat spesialiste moet ondersoek en op een of ander manier moet reageer. Slegs 'n fraksie van hierdie aangemelde gevalle kan werklik as bedrog geklassifiseer word.
Beginsel 3: Rich Analytics Platform
Die mees uitdagende deel van ons stelsel is end-tot-end verifikasie van die stelsel se werkvloei. Ontleders en ontwikkelaars behoort maklik historiese datastelle te bekom met al die maatstawwe wat vir ontleding gebruik word. Daarbenewens moet die dataplatform 'n maklike manier bied om 'n bestaande stel metrieke met nuwes aan te vul. Die prosesse wat ons skep, en dit is nie net sagtewareprosesse nie, behoort ons in staat te stel om vorige periodes maklik te herbereken, nuwe maatstawwe by te voeg en die datavoorspelling te verander. Ons kan dit bereik deur al die data wat ons produksiestelsel genereer, te versamel. In hierdie geval sal die data geleidelik 'n oorlas word. Ons sal 'n groeiende hoeveelheid data wat ons nie gebruik nie moet stoor en dit moet beskerm. In so 'n scenario sal data mettertyd meer en meer irrelevant word, maar dit verg steeds ons pogings om dit te bestuur. Vir ons het dataopgaar nie sin gemaak nie, so ons het besluit om 'n ander benadering te volg. Ons het besluit om intydse datawinkels te organiseer rondom die teikenentiteite wat ons wil klassifiseer, en net die data te stoor wat ons in staat stel om die mees onlangse en relevante periodes na te gaan. Die uitdaging vir hierdie poging is dat ons stelsel heterogeen is, met veelvuldige datawinkels en sagtewaremodules wat noukeurige beplanning verg om op 'n konsekwente manier te werk.
Ontwerpkonsepte van ons stelsel
Ons het vier hoofkomponente in ons stelsel: innamestelsel, rekenaar-, BI-analise en opsporingstelsel. Hulle dien spesifieke, geïsoleerde doeleindes, en ons hou hulle geïsoleer deur spesifieke ontwerpbenaderings te volg.
Kontrakgebaseerde ontwerp
Eerstens het ons ooreengekom dat komponente slegs moet staatmaak op sekere datastrukture (kontrakte) wat tussen hulle aangegaan word. Dit maak dit maklik om tussen hulle te integreer en nie 'n spesifieke samestelling (en volgorde) van komponente af te dwing nie. Byvoorbeeld, in sommige gevalle stel dit ons in staat om die innamestelsel direk met die waarskuwingsopsporingstelsel te integreer. In so 'n geval sal dit gedoen word in ooreenstemming met die ooreengekome waarskuwingskontrak. Dit beteken dat beide komponente geïntegreer sal word deur 'n kontrak te gebruik wat enige ander komponent kan gebruik. Ons sal nie 'n bykomende kontrak byvoeg om waarskuwings vanaf die invoerstelsel by die opsporingstelsel te voeg nie. Hierdie benadering vereis die gebruik van 'n voorafbepaalde minimum aantal kontrakte en vereenvoudig die stelsel en kommunikasie. In wese volg ons 'n benadering genaamd "Contract First Design" en pas dit toe op stroomkontrakte. [2]
Stroom oral
Die redding en bestuur van staat in 'n stelsel sal onvermydelik lei tot komplikasies in die implementering daarvan. Oor die algemeen moet staat toeganklik wees vanaf enige komponent, dit moet konsekwent wees en die mees huidige waarde oor alle komponente verskaf, en dit moet betroubaar wees met die korrekte waardes. Boonop sal oproepe na aanhoudende berging om die nuutste toestand te herwin die aantal I/O-bewerkings en kompleksiteit van die algoritmes wat in ons intydse pyplyne gebruik word, verhoog. As gevolg hiervan het ons besluit om staatberging, indien moontlik, heeltemal uit ons stelsel te verwyder. Hierdie benadering vereis dat alle nodige data by die versendte datablok (boodskap) ingesluit word. Byvoorbeeld, as ons die totale aantal waarnemings (die aantal bewerkings of gevalle met sekere eienskappe) moet bereken, bereken ons dit in die geheue en genereer 'n stroom van sulke waardes. Afhanklike modules sal partisie en groepering gebruik om die stroom in entiteite te verdeel en op die nuutste waardes te werk. Hierdie benadering het die behoefte uitgeskakel om aanhoudende skyfberging vir sulke data te hê. Ons stelsel gebruik Kafka as 'n boodskapmakelaar en dit kan as 'n databasis met KSQL gebruik word. [3] Maar die gebruik daarvan sou ons oplossing baie aan Kafka verbind het, en ons het besluit om dit nie te gebruik nie. Die benadering wat ons gekies het, stel ons in staat om Kafka met 'n ander boodskapmakelaar te vervang sonder groot interne veranderinge aan die stelsel.
Hierdie konsep beteken nie dat ons nie skyfberging en databasisse gebruik nie. Om stelselwerkverrigting te toets en te ontleed, moet ons 'n aansienlike hoeveelheid data op skyf stoor wat verskeie maatstawwe en toestande verteenwoordig. Die belangrike punt hier is dat intydse algoritmes nie van sulke data afhanklik is nie. In die meeste gevalle gebruik ons die gestoorde data vir vanlyn analise, ontfouting en opsporing van spesifieke gevalle en resultate wat die stelsel produseer.
Probleme van ons stelsel
Daar is sekere probleme wat ons tot 'n sekere vlak opgelos het, maar dit vereis meer deurdagte oplossings. Nou wil ek hulle net hier noem want elke punt is sy eie artikel werd.
- Ons moet steeds prosesse en beleide definieer wat die ophoping van betekenisvolle en relevante data vir ons outomatiese data-analise, ontdekking en verkenning ondersteun.
- Inkorporering van menslike ontledingsresultate in die proses om die stelsel outomaties op te stel om dit met die nuutste data op te dateer. Dit is nie net die opdatering van ons model nie, maar ook om ons prosesse op te dateer en ons begrip van ons data te verbeter.
- Om 'n balans te vind tussen die deterministiese benadering van IF-ELSE en ML. Iemand het gesê: "ML is 'n hulpmiddel vir die desperate." Dit beteken dat jy ML sal wil gebruik wanneer jy nie meer verstaan hoe om jou algoritmes te optimaliseer en te verbeter nie. Aan die ander kant laat die deterministiese benadering nie die opsporing van anomalieë toe wat nie verwag is nie.
- Ons het 'n eenvoudige manier nodig om ons hipoteses of korrelasies tussen metrieke in die data te toets.
- Die stelsel moet verskeie vlakke van ware positiewe resultate hê. Bedrogsake is slegs 'n fraksie van alle sake wat as positief vir die stelsel beskou kan word. Ontleders wil byvoorbeeld alle verdagte sake vir verifikasie ontvang, en slegs 'n klein deel daarvan is bedrog. Die stelsel moet alle gevalle doeltreffend aan ontleders voorlê, ongeag of dit werklike bedrog of net verdagte gedrag is.
- Die dataplatform moet in staat wees om historiese datastelle te herwin met berekeninge wat onmiddellik gegenereer en bereken word.
- Ontplooi enige van die stelselkomponente maklik en outomaties in ten minste drie verskillende omgewings: produksie, eksperimentele (beta) en vir ontwikkelaars.
- En laaste, maar nie minste nie. Ons moet 'n ryk prestasietoetsplatform bou waarop ons ons modelle kan analiseer. [4]
verwysings
Bron: will.com