Posljednjih otprilike šest mjeseci stvarao sam sustav za borbu protiv prijevara (prevare, prijevare itd.) bez ikakve početne infrastrukture za to. Današnje ideje koje smo pronašli i implementirali u naš sustav pomažu nam otkriti i analizirati mnoge lažne aktivnosti. U ovom članku želio bih govoriti o principima koje smo slijedili i što smo učinili da postignemo trenutno stanje našeg sustava, ne ulazeći u tehnički dio.
Načela našeg sustava
Kada čujete izraze poput "automatski" i "prijevara", najvjerojatnije ćete početi razmišljati o strojnom učenju, Apache Sparku, Hadoopu, Pythonu, Airflowu i drugim tehnologijama iz ekosustava Apache Foundation i polja Data Science. Mislim da postoji jedan aspekt korištenja ovih alata koji se obično ne spominje: oni zahtijevaju određene preduvjete u vašem poslovnom sustavu prije nego što ih možete početi koristiti. Ukratko, potrebna vam je podatkovna platforma poduzeća koja uključuje podatkovno jezero i skladište. Ali što ako nemate takvu platformu, a još uvijek morate razvijati ovu praksu? Sljedeća načela koja iznosim u nastavku pomogla su nam da dođemo do točke u kojoj se možemo usredotočiti na poboljšanje svojih ideja umjesto na pronalaženje one koja funkcionira. Međutim, ovo nije projektni plato. U planu je još dosta stvari s tehnološkog i proizvodnog aspekta.
Načelo 1: Poslovna vrijednost na prvom mjestu
Stavljamo "poslovnu vrijednost" u prvi plan svih naših napora. Općenito, svaki sustav za automatsku analizu spada u skupinu složenih sustava s visokim stupnjem automatizacije i tehničke složenosti. Stvaranje cjelovitog rješenja će oduzeti puno vremena ako ga kreirate od nule. Odlučili smo staviti poslovnu vrijednost na prvo mjesto, a tehnološku cjelovitost na drugo. U stvarnom životu to znači da ne prihvaćamo naprednu tehnologiju kao dogmu. Biramo tehnologiju koja nam trenutno najbolje odgovara. S vremenom bi se moglo činiti da ćemo neke module morati ponovno implementirati. To je kompromis koji smo prihvatili.
Načelo 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 cilj zamijeniti ljude. Zapravo, rješenja strojnog učenja daleko su od savršenih i samo je u određenim područjima moguća zamjena. Odbili smo ovu ideju od samog početka iz nekoliko razloga: neuravnoteženi podaci o prijevarnoj aktivnosti i nemogućnost pružanja sveobuhvatnog popisa značajki za modele strojnog učenja. Nasuprot tome, odabrali smo opciju poboljšane inteligencije. Ovo je alternativni koncept umjetne inteligencije koji se fokusira na pomoćnu ulogu umjetne inteligencije, naglašavajući činjenicu da su kognitivne tehnologije namijenjene poboljšanju ljudske inteligencije, a ne njezinoj zamjeni. [1]
S obzirom na to, razvoj cjelovitog rješenja strojnog učenja od samog početka zahtijevao bi ogroman napor, što bi odgodilo stvaranje vrijednosti za naše poslovanje. Odlučili smo izgraditi sustav s iterativno rastućim aspektom strojnog učenja pod vodstvom naših stručnjaka za domenu. Izazov u razvoju takvog sustava je to što našim analitičarima mora pružiti slučajeve ne samo u smislu je li 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 na neki način reagirati. Samo se mali dio ovih prijavljenih slučajeva doista može klasificirati kao prijevara.
Načelo 3: Platforma bogate analitike
Najizazovniji dio našeg sustava je end-to-end provjera tijeka rada sustava. Analitičari i razvojni programeri trebali bi lako doći do skupova povijesnih podataka sa svim metrikama koje se koriste za analizu. Osim toga, podatkovna platforma trebala bi omogućiti jednostavan način nadopunjavanja postojećeg skupa metrika novima. Procesi koje kreiramo, a to nisu samo softverski procesi, trebali bi nam omogućiti jednostavno preračunavanje prethodnih razdoblja, dodavanje novih metrika i promjenu predviđanja podataka. To bismo mogli postići prikupljanjem svih podataka koje generira naš proizvodni sustav. U tom bi slučaju podaci postupno postali smetnja. Morali bismo pohraniti sve veću količinu podataka koje ne koristimo i zaštititi ih. U takvom scenariju, podaci će s vremenom postajati sve nevažniji, ali i dalje zahtijeva naše napore da njima upravljamo. Za nas gomilanje podataka nije imalo smisla, pa smo se odlučili za drugačiji pristup. Odlučili smo organizirati pohranu podataka u stvarnom vremenu oko ciljnih entiteta koje želimo klasificirati i pohraniti samo podatke koji nam omogućuju provjeru najnovijih i relevantnih razdoblja. Izazov za ovaj napor je to što je naš sustav heterogen, s više pohrana podataka i softverskih modula koji zahtijevaju pažljivo planiranje kako bi radili na dosljedan način.
Koncepti dizajna našeg sustava
Imamo četiri glavne komponente u našem sustavu: sustav unosa podataka, računalni sustav, BI analizu i sustav praćenja. Služe u specifične, izolirane svrhe, a mi ih držimo izoliranima slijedeći specifične pristupe dizajnu.
Dizajn temeljen na ugovoru
Prije svega, složili smo se da se komponente trebaju oslanjati samo na određene strukture podataka (ugovore) koji se međusobno prenose. To olakšava njihovu integraciju i ne nameće određeni sastav (i redoslijed) komponenti. Na primjer, u nekim slučajevima to nam omogućuje izravnu integraciju usisnog sustava sa sustavom za praćenje upozorenja. U tom slučaju to će se učiniti u skladu s dogovorenim ugovorom o uzbunjivanju. To znači da će obje komponente biti integrirane pomoću ugovora koji može koristiti bilo koja druga komponenta. Nećemo dodavati dodatni ugovor za dodavanje upozorenja u sustav praćenja iz ulaznog sustava. Ovaj pristup zahtijeva korištenje unaprijed određenog minimalnog broja ugovora i pojednostavljuje sustav i komunikacije. U biti, koristimo pristup koji se zove "Prvo dizajn ugovora" i primjenjujemo ga na ugovore o strujanju. [2]
Streaming posvuda
Spremanje i upravljanje stanjem u sustavu neizbježno će dovesti do komplikacija u njegovoj implementaciji. Općenito, stanje bi trebalo biti dostupno iz bilo koje komponente, trebalo bi biti dosljedno i pružati najnoviju vrijednost u svim komponentama, i trebalo bi biti pouzdano s točnim vrijednostima. Osim toga, pozivi trajnoj pohrani radi dohvaćanja najnovijeg stanja povećat će broj I/O operacija i složenost algoritama koji se koriste u našim cjevovodima u stvarnom vremenu. Zbog toga smo odlučili ukloniti državnu pohranu, ako je moguće, u potpunosti iz našeg sustava. Ovaj pristup zahtijeva da svi potrebni podaci budu uključeni u preneseni blok podataka (poruku). Na primjer, ako trebamo izračunati ukupan broj nekih opažanja (broj operacija ili slučajeva s određenim karakteristikama), izračunavamo to u memoriji i generiramo tok takvih vrijednosti. Zavisni moduli koristit će particiju i grupiranje kako bi podijelili tok u entitete i radili na najnovijim vrijednostima. Ovaj pristup eliminirao je potrebu za trajnom pohranom na disku za takve podatke. Naš sustav koristi Kafku kao broker poruka i može se koristiti kao baza podataka s KSQL-om. [3] Ali njegovo bi korištenje naše rješenje uvelike povezalo s Kafkom i odlučili smo ga ne koristiti. Pristup koji smo odabrali omogućuje nam da Kafku zamijenimo drugim brokerom poruka bez velikih internih promjena u sustavu.
Ovaj koncept ne znači da ne koristimo diskovnu pohranu i baze podataka. Za testiranje i analizu performansi sustava, moramo pohraniti značajnu količinu podataka na disk koji predstavljaju različite metrike i stanja. Ovdje je važna točka da algoritmi u stvarnom vremenu ne ovise o takvim podacima. U većini slučajeva koristimo pohranjene podatke za offline analizu, otklanjanje pogrešaka i praćenje specifičnih slučajeva i rezultata koje sustav proizvodi.
Problemi našeg sustava
Postoje određeni problemi koje smo do određene razine riješili, ali oni zahtijevaju promišljenija rješenja. Sada bih ih ovdje samo htio spomenuti jer svaka točka vrijedi za svoj članak.
- Još uvijek moramo definirati procese i politike koji podržavaju prikupljanje smislenih i relevantnih podataka za našu automatiziranu analizu podataka, otkrivanje i istraživanje.
- Uključivanje rezultata ljudske analize u proces automatskog postavljanja sustava za ažuriranje 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-a. Netko je rekao: "ML je alat za očajnike." To znači da ćete htjeti koristiti ML kada više ne budete razumjeli kako optimizirati i poboljšati svoje algoritme. S druge strane, deterministički pristup ne dopušta otkrivanje anomalija koje nisu bile predviđene.
- Trebamo jednostavan način testiranja naših hipoteza ili korelacija između metrika u podacima.
- Sustav mora imati nekoliko razina istinskih pozitivnih rezultata. Slučajevi prijevare samo su djelić svih slučajeva koji se mogu smatrati pozitivnima za sustav. Na primjer, analitičari žele dobiti sve sumnjive slučajeve na provjeru, a samo mali dio njih su prevaranti. Sustav mora učinkovito prezentirati sve slučajeve analitičarima, bez obzira radi li se o stvarnoj prijevari ili samo o sumnjivom ponašanju.
- Podatkovna platforma trebala bi moći dohvatiti skupove povijesnih podataka s izračunima koji se generiraju i izračunavaju u hodu.
- Jednostavno i automatski implementirajte bilo koju od komponenti sustava u najmanje tri različita okruženja: proizvodno, eksperimentalno (beta) i za programere.
- I na kraju, ali ne manje važno. Moramo izgraditi bogatu platformu za testiranje performansi na kojoj možemo analizirati svoje modele. [4]
reference
Izvor: www.habr.com