Viimased umbes kuus kuud olen töötanud pettustevastase süsteemi (fraudulent activity, fraud, jne) loomisega ilma igasuguse algse infrastruktuurita. Tänased ideed, mille leidsime ja rakendasime oma süsteemis, aitavad meil tuvastada palju pettustegevusi ja neid analüüsida. Selles artiklis soovin rääkida printsiipidest, millele me toetunud oleme, ja sellest, mida me oleme teinud, et saavutada meie süsteemi praegune seis, süvenemata tehnikasse.
Meie süsteemi printsiibid
Kui kuulete selliseid termineid nagu "automatic" ja "fraud", hakkate tõenäoliselt mõtlema masinõppele, Apache Sparkile, Hadoopile, Pythonile, Airflowle ja teistele Apache Foundationi ökosüsteemi ning andeteaduse valdkonna tehnoloogiatele. Arvan, et on üks aspekt nende tööriistade kasutamisel, mida tavaliselt ei mainita: nad vajavad teie ettevõtte süsteemis teatud eeltingimuste olemasolu, enne kui hakkate neid kasutama. Lühidalt öeldes vajate ettevõtte andmeplatvormi, mis sisaldab andmejärve ja andmehunnikut. Kuid mis siis, kui teil ei ole sellist platvormi ja peate ikkagi seda praktikat arendama? Alljärgnevad printsiibid, millest räägin, aitasid meil jõuda hetkeni, mil saame keskenduda oma ideede arendamisele, mitte töötava lahenduse leidmisele. Siiski ei tähenda see, et projekt oleks "platool". Tehnilise ja tooteaspektide poolest on veel palju asju, mis vajavad tähelepanu.
Printsiip 1: Ärikasu esmajoones
Kõikide meie jõupingutuste tipus oleme seadnud "ärikasu". Üldiselt kuulub iga automaatsete analüüsisüsteemide rühm keeruliste süsteemide hulka, mille automaatika ja tehniline keerukus on kõrge. Valmislahenduse loomine võtab tohutult aega, kui ehitate selle nullist. Otsustasime seada esikohale äriväärtuse ning teisele kohale tehnilise täiuslikkuse. Reaalses elus tähendab see, et me ei võta tipptasemel tehnoloogiaid dogmina. Valime tehnoloogia, mis töötab meile praegusel hetkel par najbolje. Aja jooksul võib tunduda, et peame mõningaid mooduleid uuesti rakendama. See on kompromiss, millega me oleme nõustunud.
Printsiip 2: Inimese täiendav intelligentsus (augmented intelligence)
Ma väidan, et enamik inimesi, kes ei ole sügavalt seotud masinõppe lahenduste arendamisega, võib arvata, et inimesi asendamine on eesmärk. Tegelikult on masinõppe lahendused kaugel täiuslikkusest ja ainult teatud valdkondades on asendamine võimalik. Oleme sellest ideest algusest peale loobunud mitmel põhjusel: tasakaalustamata andmed petmise kohta ja võimetus esitada põhjalikku loetelu funktsioonidest masinõppe mudelite jaoks. Vastupidiselt sellele valisime laiendatud intelligentsuse lähenemise. See on alternatiivne tehisintellekti kontseptsioon, mis keskendub AI abistavale rollile, rõhutades, et kognitiivsed tehnoloogiad on mõeldud inimintellekti parandamiseks, mitte selle asendamiseks. [1]
Arvestades seda, nõudis täieliku masinõppe lahenduse arendamine algusest peale tohutult pingutusi, mis viivitaks meie äri väärtuse loomist. Otsustasime luua süsteemi, millel on itereerivalt kasvav masinõppe aspekt meie valdkonna ekspertide juhtimisel. Sellise süsteemi arendamise keeruline osa seisneb selles, et see peab meie analüütikutele esitama juhtumeid mitte ainult selle vaatenurgast, kas see on pettus või mitte. Üldiselt on iga klientide käitumise anomaalia kahtlane juhtum, mida spetsialistid peavad uurima ja millele nad peavad mingil moel reageerima. Ainult osa nendest fikseeritud juhtumitest võib tõeliselt kuuluda pettuse kategooriasse.
Põhimõte 3: ulatuslike analüütiliste andmete platvorm
Meie süsteemi kõige keerulisem osa on protsessi pidev ülevaatus. Analüütikud ja arendajad peavad saama hõlpsasti juurde varasemate perioodide andmestikele koos kõikide metrikatega, mida analüüsi jaoks on kasutatud. Lisaks peab andmeplatvorm pakkuma lihtsat viisi, kuidas täiendada olemasolevat näitajate kogumit uute andmetega. Protsessid, mida me loome, mitte ainult mitteprogrammilised, peavad võimaldama varasemate perioodide lihtsat ümberarvutamist, uute metrikate lisamist ja andmete prognooside muutmist. Saaksime selle saavutada, kogudes kogu teabe, mida meie tootmissüsteem genereerib. Sel juhul muutuks teave järk-järgult segavaks. Me peaksime ladustama kasvava hulga andmeid, mida me ei kasuta, ning neid kaitsmiseks. Sellises stsenaariumis muutuvad andmed aja jooksul üha ebaolulisemaks, kuid nõuavad meie pingutusi nende haldamiseks. Meie jaoks ei olnud andmete kogumine (data hoarding) mõistlik ja otsustasime läheneda erinevalt. Otsustasime korraldada reaalaja andmehulkade ümber sihitud entiteetide, mida soovime klassifitseerida, ja salvestada ainult need andmed, mis võimaldavad kontrollida kõige uuemaid ja asjakohasemaid perioode. Nende jõupingutuste keerukus seisneb selles, et meie süsteem on heterogeene mitme andmehoidla ja programmimooduliga, mis nõuab hoolikat planeerimist kooskõlastatud tööks.
Meie süsteemi konstruktiivsed mõisted
Meie süsteemis on neli põhikomponenti: andmete kogumise süsteem (ingestion system), arvutussüsteem (computational), analüüsi süsteem (BI analysis) ja jälgimissüsteem (tracking system). Need teenivad spetsiifilisi isoleeritud eesmärke ja me hoian neid isoleerituna, järgides teatud arendusuunnat.
Lepingualusel kujundamine
Esiteks, me leppisime kokku, et komponendid peavad toetuma ainult teatud andmestruktuuridele (lepingutele), mis nende vahel edastatakse. See võimaldab lihtsat integreerimist nende vahel ja ei sunni kindlat koosseisu (ja järjekorda) komponente. Näiteks mõningatel juhtudel võimaldab see meil otse integreerida vastuvõtusüsteemi hoiatuste jälgimise süsteemiga. Sel juhul tehakse see vastavalt kokkulepitud hoiatuste lepingule. See tähendab, et mõlemad komponendid on integreeritud lepinguga, mida võib kasutada iga teine komponent. Me ei lisa täiendavat lepingut hoiatuste lisamiseks jälgimise süsteemi sisendisüsteemist. Selline lähenemine nõuab eelnevalt määratud minimaalset hulka lepinguid ja lihtsustab süsteemi ja suhtlemist. Sisuliselt kasutame lähenemist, mida nimetatakse 'Lepingu Eelnevalt Kujundamine', ja rakendame seda andmevoogude lepingutele. [2]
Voogedastus igal pool
Süsteemi oleku säilitamine ja haldamine toob paratamatult kaasa keerukusi selle rakendamisel. Üldiselt peaks olek olema kergesti kätte saadav igast komponendist, olema kooskõlas ja pakuma kõigi komponentide jaoks kõige ajakohasemaid väärtusi ning olema usaldusväärne õige väärtuste osas. Lisaks suurendab pideva salvestusruumi väljakutse kutsumine viimase oleku saamiseks sisend-väljundite operatsioonide arvu ja suurendab meie reaalajas voogudes kasutatavate algoritmide keerukust. Seetõttu otsustasime proovida võtta oleku säilitamine meie süsteemist täielikult välja. See lähenemine nõuab, et kõik vajalikud andmed kaasataks edastatavasse andmeplokki (sõnumisse). Näiteks kui me peame arvutama mõningate tähelepanekute koguarvu (operatsioonide või juhtumite arv, millel on teatud omadused), arvutame selle mälus ja genereerime nende väärtuste vooge. Sõltuvad moodulid kasutavad voogude jagamiseks (partition) ja pakettide (batch) kombineerimiseks viimaste väärtuste peenestamist. See lähenemine on elimineerinud vajaduse pideva ketassalvestuse järele nende andmete jaoks. Meie süsteem kasutab Kafka sõnumibrokerina ja seda saab kasutada andmebaasina KSQL-ga. [3] Kuid selle kasutamine seoks meie lahenduse tugevalt Kafka külge, mistõttu otsustasime seda mitte kasutada. Meie valitud lähenemine võimaldab asendada Kafka teise sõnumibrokeriga ilma tõsiste sisemiste muudatusteta.
See kontseptsioon ei tähenda, et me ei kasutaks ketassalvestusi ja andmebaase. Süsteemi jõudluse kontrollimiseks ja analüüsimiseks on meil vajalik salvestada ketta peale märkimisväärne osa andmeid, mis esindavad erinevaid näitajaid ja olekuid. Oluline on märkida, et reaalajas algoritmid ei sõltu nendest andmetest. Enamasti kasutame salvestatud andmeid iseseisvaks analüüsiks, tõrkeotsinguks ja konkreetsete juhtumite ning süsteemi tulemuste jälgimiseks.
Meie süsteemi probleemid
On teatud probleemid, mille oleme lahendanud teatud tasemel, kuid need vajavad enam mõtlevaid lahendusi. Praegu sooviksin lihtsalt neid siin mainida, kuna iga punkt väärib eraldi artiklit.
- Meil on endiselt vaja määratleda protsessid ja poliitikad, mis soodustavad oluliste ja asjakohaste andmete kogumist meie automaatseks analüüsiks, tuvastamiseks ja andmete uurimiseks.
- Inimese analüüsi tulemuste rakendamine süsteemi automaatse kohandamise protsessis, et ajakohastada seda viimaste andmete põhjal. See pole ainult meie mudeli ajakohastamine, vaid ka protsesside ajakohastamine ja meie andmete arusaamise parandamine.
- Tuleb leida tasakaal määratletud IF-ELSE lähenemise ja ML vahel. Keegi ütles: „ML on meeleheitlike tööriist“. See tähendab, et soovite kasutada ML, kui te enam ei mõista, kuidas oma algoritme optimeerida ja parandada. Teisest küljest ei võimalda määratletud lähenemine avastada anomaaliaid, mis pole ette nähtud.
- Me vajame lihtsat viisi, et testida oma hüpoteese või korrelatsioone mõõdikute vahel andmetes.
- Süsteem peab omama mitu taset tõeliselt positiivsetest (true positive) tulemustest. Petturlikud juhtumid on vaid osa kõigist juhtumitest, mida saab süsteemi jaoks pidada positiivseks. Näiteks soovivad analüütikud saada kõiki kahtlaseid juhtumeid kontrollimiseks ning neist vaid väike osa on pettus. Süsteem peab tõhusalt esitama analüütikutele kõik juhtumid, sõltumata sellest, kas need on tõelised pettused või lihtsalt kahtlane käitumine.
- Andmete platvorm peab võimaldama hankida andmekogumeid varasemate perioodide jaoks, mille arvutused on loodud ja arvutatud reaalajas.
- Lihtne ja automaatne mis tahes süsteemi komponente juurutada vähemalt kolmes erinevas keskkonnas: tootmis-, eksperimentaalses (béta) ja arendajate jaoks.
- Ja viimasena, kuid mitte vähem tähtsana. Me peame looma ulatusliku jõudluse kontrollimise platvormi, kus saame analüüsida oma mudeleid. [4]
Viidatud lingid
Allikas: habr.com
