Pastaruosius maždaug šešis mėnesius kūriau kovos su sukčiavimu (nesąžininga veikla, sukčiavimu ir pan.) sistemą, neturėdamas tam jokios pradinės infrastruktūros. Šiandienos idėjos, kurias radome ir įgyvendinome savo sistemoje, padeda aptikti ir analizuoti daugybę nesąžiningų veiksmų. Šiame straipsnyje norėčiau pakalbėti apie principus, kurių laikėmės ir ką padarėme, kad pasiektume dabartinę mūsų sistemos būklę, nesigilindamas į techninę dalį.
Mūsų sistemos principai
Išgirdę tokius terminus kaip „automatinis“ ir „sukčiavimas“, greičiausiai pradėsite galvoti apie mašininį mokymąsi, „Apache Spark“, „Hadoop“, „Python“, „Airflow“ ir kitas „Apache Foundation“ ekosistemos ir duomenų mokslo srities technologijas. Manau, kad yra vienas šių įrankių naudojimo aspektas, kuris paprastai nėra minimas: norint pradėti juos naudoti, reikia tam tikrų jūsų įmonės sistemos sąlygų. Trumpai tariant, jums reikia įmonės duomenų platformos, apimančios duomenų ežerą ir sandėlį. Bet ką daryti, jei neturite tokios platformos ir vis tiek turite plėtoti šią praktiką? Šie principai, kuriais dalinuosi toliau, padėjo mums pasiekti tašką, kai galime sutelkti dėmesį į savo idėjų tobulinimą, o ne bandydami rasti tai, kas veikia. Tačiau tai nėra projekto plynaukštė. Plane dar daug dalykų technologiniu ir gaminio požiūriu.
1 principas: pirmiausia verslo vertė
„Verslo vertę“ laikome visų savo pastangų priešakyje. Apskritai bet kuri automatinės analizės sistema priklauso sudėtingų sistemų, turinčių aukštą automatizavimo ir techninio sudėtingumo lygį, grupei. Viso sprendimo sukūrimas užtruks daug laiko, jei jį kursite nuo nulio. Nusprendėme verslo vertę teikti pirmoje vietoje, o technologinį išsamumą – antroje vietoje. Realiame gyvenime tai reiškia, kad mes nepriimame pažangių technologijų kaip dogmos. Mes pasirenkame technologiją, kuri šiuo metu mums labiausiai tinka. Laikui bėgant gali atrodyti, kad kai kuriuos modulius turėsime įdiegti iš naujo. Tai yra kompromisas, kurį priėmėme.
2 principas: padidintas intelektas
Lažinuosi, kad dauguma žmonių, kurie nėra giliai įsitraukę į mašininio mokymosi sprendimų kūrimą, gali manyti, kad tikslas yra pakeisti žmones. Tiesą sakant, mašininio mokymosi sprendimai toli gražu nėra tobuli ir tik tam tikrose srityse juos galima pakeisti. Nuo pat pradžių šią idėją atmetėme dėl kelių priežasčių: nesubalansuotų duomenų apie nesąžiningą veiklą ir nesugebėjimo pateikti išsamaus mašininio mokymosi modelių funkcijų sąrašo. Priešingai, pasirinkome patobulinto žvalgybos parinktį. Tai alternatyvi dirbtinio intelekto koncepcija, kurioje pagrindinis dėmesys skiriamas pagalbiniam AI vaidmeniui, pabrėžiant faktą, kad kognityvinės technologijos skirtos žmogaus intelektui pagerinti, o ne jį pakeisti. [1]
Atsižvelgiant į tai, sukurti pilną mašininio mokymosi sprendimą nuo pat pradžių pareikalautų didžiulių pastangų, o tai atidėtų vertės kūrimą mūsų verslui. Vadovaujant mūsų domeno ekspertams, nusprendėme sukurti sistemą su nuolat augančiu mašininio mokymosi aspektu. Sudėtinga tokios sistemos kūrimo dalis yra ta, kad ji turi pateikti mūsų analitikams bylas ne tik apie tai, ar tai yra nesąžininga veikla, ar ne. Apskritai bet kokia klientų elgesio anomalija yra įtartinas atvejis, kurį specialistai turi ištirti ir kažkaip reaguoti. Tik dalis šių atvejų, apie kuriuos pranešta, tikrai gali būti klasifikuojami kaip sukčiavimas.
3 principas: turtinga analizės platforma
Sudėtingiausia mūsų sistemos dalis yra sistemos darbo eigos patikrinimas iki galo. Analitikai ir kūrėjai turėtų lengvai gauti istorinių duomenų rinkinius su visa analizei naudojama metrika. Be to, duomenų platforma turėtų būti paprastas būdas esamą metrikų rinkinį papildyti naujais. Mūsų kuriami procesai, o tai ne tik programinės įrangos procesai, turėtų leisti mums lengvai perskaičiuoti ankstesnius laikotarpius, pridėti naujų metrikų ir keisti duomenų prognozę. Tai galėtume pasiekti sukaupę visus duomenis, kuriuos generuoja mūsų gamybos sistema. Tokiu atveju duomenys pamažu taptų nepatogumu. Turėtume saugoti vis daugiau duomenų, kurių nenaudojame, ir juos apsaugoti. Esant tokiam scenarijui, laikui bėgant duomenys taps vis nereikšmingesni, bet vis tiek reikės mūsų pastangų juos valdyti. Mums duomenų kaupimas nebuvo prasmingas, todėl nusprendėme imtis kitokio požiūrio. Nusprendėme sutvarkyti realaus laiko duomenų saugyklas pagal tikslinius objektus, kuriuos norime klasifikuoti, ir saugoti tik tuos duomenis, kurie leidžia patikrinti naujausius ir aktualiausius laikotarpius. Šių pastangų iššūkis yra tas, kad mūsų sistema yra nevienalytė, su daugybe duomenų saugyklų ir programinės įrangos modulių, kuriuos reikia kruopščiai planuoti, kad veiktų nuosekliai.
Mūsų sistemos dizaino koncepcijos
Mūsų sistemoje yra keturi pagrindiniai komponentai: priėmimo sistema, skaičiavimo, BI analizė ir sekimo sistema. Jie tarnauja konkretiems, izoliuotiems tikslams, o mes laikome juos izoliuotus laikydamiesi specifinių projektavimo metodų.
Projektavimas pagal sutartį
Visų pirma sutarėme, kad komponentai turėtų remtis tik tam tikromis duomenų struktūromis (sutartimis), kurios perduodamos tarp jų. Tai leidžia lengvai juos integruoti ir neprimesti konkrečios komponentų sudėties (ir tvarkos). Pavyzdžiui, kai kuriais atvejais tai leidžia mums tiesiogiai integruoti įsiurbimo sistemą su įspėjimo sekimo sistema. Tokiu atveju tai bus daroma pagal sutartą įspėjimo sutartį. Tai reiškia, kad abu komponentai bus integruoti pagal sutartį, kurią gali naudoti bet kuris kitas komponentas. Mes nepridėsime papildomos sutarties dėl įspėjimų įtraukimo į sekimo sistemą iš įvesties sistemos. Šis metodas reikalauja iš anksto nustatyto minimalaus sutarčių skaičiaus ir supaprastina sistemą bei ryšius. Iš esmės mes laikomės požiūrio, vadinamo „Sutarties pirmasis dizainas“ ir taikome jį srautinio perdavimo sutartims. [2]
Srautas visur
Būsenos išsaugojimas ir valdymas sistemoje neišvengiamai sukels komplikacijų ją įgyvendinant. Apskritai būsena turėtų būti pasiekiama iš bet kurio komponento, ji turi būti nuosekli ir pateikti naujausią visų komponentų vertę, be to, ji turėtų būti patikima su teisingomis reikšmėmis. Be to, iškvietus nuolatinę saugyklą, kad būtų galima gauti naujausią būseną, padidės įvesties / išvesties operacijų skaičius ir mūsų realaus laiko vamzdynuose naudojamų algoritmų sudėtingumas. Dėl šios priežasties nusprendėme, jei įmanoma, visiškai pašalinti būsenos saugyklą iš savo sistemos. Šis metodas reikalauja, kad visi reikalingi duomenys būtų įtraukti į perduodamą duomenų bloką (pranešimą). Pavyzdžiui, jei reikia apskaičiuoti bendrą kai kurių stebėjimų skaičių (operacijų ar atvejų su tam tikromis charakteristikomis skaičių), tai apskaičiuojame atmintyje ir generuojame tokių reikšmių srautą. Priklausomi moduliai naudos skaidinį ir paketų sudarymą, kad padalytų srautą į objektus ir veiktų pagal naujausias reikšmes. Šis metodas pašalino poreikį turėti nuolatinę tokių duomenų saugyklą diske. Mūsų sistema naudoja Kafka kaip pranešimų tarpininką ir gali būti naudojama kaip duomenų bazė su KSQL. [3] Tačiau naudojant jį mūsų sprendimas būtų labai susietas su Kafka, todėl nusprendėme jo nenaudoti. Mūsų pasirinktas metodas leidžia pakeisti Kafka kitu pranešimų tarpininku be didelių vidinių sistemos pakeitimų.
Ši sąvoka nereiškia, kad mes nenaudojame disko saugyklos ir duomenų bazių. Norėdami patikrinti ir analizuoti sistemos veikimą, turime diske saugoti didelį kiekį duomenų, kurie atspindi įvairias metrikas ir būsenas. Svarbu tai, kad realaus laiko algoritmai nepriklauso nuo tokių duomenų. Daugeliu atvejų mes naudojame saugomus duomenis analizei neprisijungus, derinimui ir konkrečių sistemos sukurtų atvejų bei rezultatų sekimui.
Mūsų sistemos problemos
Yra tam tikrų problemų, kurias išsprendėme iki tam tikro lygio, tačiau jos reikalauja labiau apgalvotų sprendimų. Dabar tiesiog norėčiau juos paminėti, nes kiekvienas punktas vertas savo straipsnio.
- Vis dar turime apibrėžti procesus ir politiką, kurie padėtų kaupti reikšmingus ir svarbius duomenis, kad galėtume atlikti automatizuotą duomenų analizę, atradimą ir tyrinėjimą.
- Žmogaus analizės rezultatų įtraukimas į automatinio sistemos nustatymo procesą, kad ji atnaujintų naujausius duomenis. Tai ne tik mūsų modelio atnaujinimas, bet ir procesų atnaujinimas bei duomenų supratimo gerinimas.
- Raskite pusiausvyrą tarp deterministinio IF-ELSE ir ML požiūrio. Kažkas pasakė: „ML yra įrankis beviltiškiems“. Tai reiškia, kad norėsite naudoti ML, kai nebesuprantate, kaip optimizuoti ir tobulinti savo algoritmus. Kita vertus, deterministinis metodas neleidžia aptikti anomalijų, kurių nebuvo galima numatyti.
- Mums reikia paprasto būdo patikrinti savo hipotezes arba duomenų koreliacijas tarp metrikų.
- Sistema turi turėti kelis tikrų teigiamų rezultatų lygius. Sukčiavimo atvejai yra tik dalis visų atvejų, kurie gali būti laikomi teigiamais sistemai. Pavyzdžiui, analitikai nori gauti patikrinimui visus įtartinus atvejus, ir tik nedidelė jų dalis yra sukčiavimas. Sistema turi efektyviai pateikti visus atvejus analitikams, nepaisant to, ar tai tikras sukčiavimas, ar tik įtartinas elgesys.
- Duomenų platforma turėtų turėti galimybę gauti istorinius duomenų rinkinius su skaičiavimais, sugeneruotais ir apskaičiuotais skrydžio metu.
- Lengvai ir automatiškai įdiekite bet kurį sistemos komponentą mažiausiai trijose skirtingose aplinkose: gamybinėje, eksperimentinėje (beta) ir kūrėjams.
- Ir paskutinis, bet ne mažiau svarbus dalykas. Turime sukurti turtingą našumo testavimo platformą, kurioje galėtume analizuoti savo modelius. [4]
Nuorodos
Šaltinis: www.habr.com