Posljednjih šest mjeseci stvarao sam sistem za borbu protiv prevara (prevarne aktivnosti, prevare, itd.) bez ikakve početne infrastrukture za to. Današnje ideje koje smo pronašli i implementirali u naš sistem pomažu nam da otkrijemo i analiziramo mnoge prijevarne aktivnosti. U ovom članku želim govoriti o principima koje smo slijedili i šta smo uradili da postignemo trenutno stanje našeg sistema, ne ulazeći u tehnički dio.
Principi našeg sistema
Kada čujete pojmove kao što su „automatsko“ i „prevara“, najverovatnije počinjete da razmišljate o mašinskom učenju, Apache Sparku, Hadoopu, Pythonu, Airflowu i drugim tehnologijama iz ekosistema Apache Foundation i oblasti Data Science. Mislim da postoji jedan aspekt korišćenja ovih alata koji se obično ne pominje: oni zahtevaju određene preduslove u vašem poslovnom sistemu pre nego što počnete da ih koristite. Ukratko, potrebna vam je platforma za poslovne podatke koja uključuje jezero podataka i skladište. Ali što ako nemate takvu platformu, a još uvijek trebate razviti ovu praksu? Sljedeći principi koje dijelim u nastavku pomogli su nam da dođemo do tačke u kojoj se možemo fokusirati na poboljšanje naših ideja umjesto na pronalaženje one koja funkcionira. Međutim, ovo nije projektni plato. U planu je još dosta stvari sa tehnološke i proizvodne tačke gledišta.
Princip 1: Poslovna vrijednost na prvom mjestu
Stavljamo „poslovnu vrijednost“ u prvi plan svih naših napora. Općenito, svaki sistem automatske analize spada u grupu složenih sistema visokog stepena automatizacije i tehničke složenosti. Stvaranje kompletnog rješenja će potrajati puno vremena ako ga kreirate od nule. Odlučili smo da poslovnu vrijednost stavimo na prvo mjesto, a tehnološku kompletnost na drugo. U stvarnom životu, to znači da ne prihvatamo naprednu tehnologiju kao dogmu. Biramo tehnologiju koja nam trenutno najbolje odgovara. Vremenom se može činiti da ćemo neke module morati ponovo implementirati. Ovo je kompromis koji smo prihvatili.
Princip 2: Povećana inteligencija
Kladim se da bi većina ljudi koji nisu duboko uključeni u razvoj rješenja za strojno učenje mogli pomisliti da je zamjena ljudi cilj. Zapravo, rješenja za strojno učenje daleko su od savršenih i samo u određenim područjima moguća je zamjena. Odbacili smo ovu ideju od samog početka iz nekoliko razloga: neuravnoteženih podataka o lažnim aktivnostima i nemogućnosti pružanja sveobuhvatne liste funkcija za modele mašinskog učenja. Nasuprot tome, mi smo odabrali opciju poboljšane inteligencije. Ovo je alternativni koncept umjetne inteligencije koji se fokusira na pomoćnu ulogu AI, naglašavajući činjenicu da su kognitivne tehnologije namijenjene poboljšanju ljudske inteligencije, a ne da je zamjene. [1]
S obzirom na to, razvoj kompletnog rješenja za strojno učenje od samog početka zahtijevao bi ogroman napor, što bi odložilo stvaranje vrijednosti za naše poslovanje. Odlučili smo da izgradimo sistem sa iterativno rastućim aspektom mašinskog učenja pod vođstvom naših stručnjaka iz domena. Izazovni dio razvoja takvog sistema je to što on mora našim analitičarima pružiti slučajeve ne samo u smislu da li je riječ o prijevarnoj aktivnosti ili ne. Općenito, svaka anomalija u ponašanju kupaca je sumnjiv slučaj koji stručnjaci moraju istražiti i nekako odgovoriti. Samo se dio ovih prijavljenih slučajeva zaista može klasificirati kao prijevara.
Princip 3: Platforma bogate analitike
Najizazovniji dio našeg sistema je verifikacija toka rada sistema od kraja do kraja. Analitičari i programeri bi trebali lako doći do historijskih skupova podataka sa svim metrikama koje se koriste za analizu. Osim toga, platforma podataka bi trebala pružiti jednostavan način za dopunu postojećeg skupa metrika novim. Procesi koje kreiramo, a to nisu samo softverski procesi, trebali bi nam omogućiti da lako preračunamo prethodne periode, dodamo nove metrike i promijenimo prognozu podataka. To bismo mogli postići akumuliranjem svih podataka koje naš proizvodni sistem generiše. U ovom slučaju, podaci bi postepeno postali smetnja. Morali bismo pohraniti sve veću količinu podataka koje ne koristimo i zaštititi ih. U takvom scenariju, podaci će vremenom postajati sve irelevantniji, ali i dalje zahtijeva naše napore da njima upravljamo. Za nas gomilanje podataka nije imalo smisla, pa smo odlučili za drugačiji pristup. Odlučili smo organizirati skladišta podataka u realnom vremenu oko ciljnih entiteta koje želimo klasificirati i pohraniti samo one podatke koji nam omogućavaju provjeru najnovijih i relevantnih perioda. Izazov za ovaj napor je što je naš sistem heterogen, sa više skladišta podataka i softverskih modula koji zahtijevaju pažljivo planiranje da bi funkcionisali na dosljedan način.
Koncepti dizajna našeg sistema
Imamo četiri glavne komponente u našem sistemu: sistem za unos podataka, računarstvo, BI analizu i sistem praćenja. Oni služe specifičnim, izoliranim svrhama, a mi ih držimo izolovanim slijedeći specifične pristupe dizajnu.
Dizajn na osnovu ugovora
Prije svega, složili smo se da se komponente trebaju oslanjati samo na određene strukture podataka (ugovore) koji se prenose između njih. Ovo olakšava integraciju između njih i ne nameće specifičan sastav (i red) komponenti. Na primjer, u nekim slučajevima to nam omogućava da direktno integrišemo sistem usisavanja sa sistemom za praćenje upozorenja. U tom slučaju, to će biti urađeno u skladu sa dogovorenim ugovorom o uzbunjivanju. To znači da će obje komponente biti integrirane korištenjem ugovora koji može koristiti bilo koja druga komponenta. Nećemo dodavati dodatni ugovor za dodavanje upozorenja sistemu za praćenje iz sistema za unos. Ovaj pristup zahtijeva korištenje unaprijed određenog minimalnog broja ugovora i pojednostavljuje sistem i komunikacije. U suštini, mi uzimamo pristup koji se zove "Dizajn prvog ugovora" i primjenjujemo ga na ugovore za striming. [2]
Streaming svuda
Čuvanje i upravljanje stanjem u sistemu neminovno će dovesti do komplikacija u njegovoj implementaciji. Uopšteno govoreći, stanju bi trebalo da se pristupi iz bilo koje komponente, trebalo bi da bude konzistentno i da pruža najnoviju vrednost za sve komponente, i trebalo bi da bude pouzdano sa ispravnim vrednostima. Dodatno, pozivanje trajnog skladišta za dohvaćanje najnovijeg stanja povećaće broj I/O operacija i složenost algoritama koji se koriste u našim cevovodima u realnom vremenu. Zbog toga smo odlučili da uklonimo pohranu stanja, ako je moguće, u potpunosti iz našeg sistema. Ovaj pristup zahtijeva da svi potrebni podaci budu uključeni u prenijeti blok podataka (poruku). Na primjer, ako trebamo izračunati ukupan broj nekih opservacija (broj operacija ili slučajeva sa određenim karakteristikama), izračunavamo ga u memoriji i generišemo tok takvih vrijednosti. Zavisni moduli će koristiti particiju i batching da podijele tok na entitete i rade na najnovijim vrijednostima. Ovaj pristup je eliminisao potrebu za postojanim diskovnim skladištem za takve podatke. Naš sistem koristi Kafku kao posrednika poruka i može se koristiti kao baza podataka sa KSQL-om. [3] Ali njegovo korištenje bi naše rješenje u velikoj mjeri vezalo za Kafku, i odlučili smo da ga ne koristimo. Pristup koji smo odabrali omogućava nam da zamijenimo Kafku drugim posrednikom poruka bez većih internih promjena u sistemu.
Ovaj koncept ne znači da ne koristimo pohranu na disku i baze podataka. Da bismo testirali i analizirali performanse sistema, moramo pohraniti značajnu količinu podataka na disk koji predstavljaju različite metrike i stanja. Ovdje je važna stvar da algoritmi u realnom vremenu ne zavise od takvih podataka. U većini slučajeva koristimo pohranjene podatke za offline analizu, otklanjanje grešaka i praćenje specifičnih slučajeva i rezultata koje sistem proizvodi.
Problemi našeg sistema
Postoje određeni problemi koje smo riješili do određenog nivoa, ali oni zahtijevaju promišljenija rješenja. Sada bih ih ovdje samo pomenuo jer svaka točka vrijedi svog članka.
- Još uvijek moramo definirati procese i politike koje podržavaju akumulaciju smislenih i relevantnih podataka za našu automatsku analizu podataka, otkrivanje i istraživanje.
- Ugrađivanje ljudske analize rezultira u proces automatskog postavljanja sistema da ga ažurira najnovijim podacima. Ovo nije samo ažuriranje našeg modela, već i ažuriranje naših procesa i poboljšanje našeg razumijevanja naših podataka.
- Pronalaženje ravnoteže između determinističkog pristupa IF-ELSE i ML. Neko je rekao: "ML je alat za očajnike." To znači da ćete htjeti koristiti ML kada više ne razumijete kako optimizirati i poboljšati svoje algoritme. S druge strane, deterministički pristup ne dozvoljava otkrivanje anomalija koje nisu bile predviđene.
- Potreban nam je jednostavan način da testiramo naše hipoteze ili korelacije između metrika u podacima.
- Sistem mora imati nekoliko nivoa istinski pozitivnih rezultata. Slučajevi prevare samo su dio svih slučajeva koji se mogu smatrati pozitivnim za sistem. Na primjer, analitičari žele sve sumnjive slučajeve primiti na provjeru, a samo mali dio njih su prevare. Sistem mora efikasno predstaviti sve slučajeve analitičarima, bez obzira da li se radi o stvarnoj prevari ili samo o sumnjivom ponašanju.
- Podatkovna platforma bi trebala biti u mogućnosti da dohvati historijske skupove podataka s proračunima generiranim i izračunatim u hodu.
- Lako i automatski implementirajte bilo koju komponentu sistema u najmanje tri različita okruženja: proizvodno, eksperimentalno (beta) i za programere.
- I na kraju, ali ne i najmanje važno. Moramo izgraditi bogatu platformu za testiranje performansi na kojoj možemo analizirati naše modele. [4]
reference
izvor: www.habr.com