Duela sei hilabete inguru iruzurrari aurre egiteko sistema bat sortzen ari naiz (iruzur-jarduera, iruzurra, etab.) horretarako hasierako azpiegiturarik gabe. Gure sisteman aurkitu eta ezarri ditugun gaurko ideiek iruzurrezko jarduera asko detektatzen eta aztertzen laguntzen digute. Artikulu honetan, jarraitu ditugun printzipioei buruz eta gure sistemaren egungo egoera lortzeko egin genuenari buruz hitz egin nahiko nuke, atal teknikoan sakondu gabe.
Gure sistemaren printzipioak
"Automatiko" eta "iruzur" bezalako terminoak entzuten dituzunean, ziurrenik, ikaskuntza automatikoari, Apache Spark, Hadoop, Python, Airflow eta Apache Fundazioaren ekosistemaren eta Data Science eremuko beste teknologia batzuei buruz pentsatzen hasiko zara. Uste dut tresna hauek erabiltzean normalean aipatzen ez den alderdi bat dagoela: zure enpresa-sisteman aurrebaldintza batzuk behar dituzte haiek erabiltzen hasi aurretik. Laburbilduz, datu-lakua eta biltegia barne hartzen dituen enpresa-datuen plataforma bat behar duzu. Baina zer gertatzen da horrelako plataformarik ez baduzu eta oraindik praktika hau garatu behar baduzu? Jarraian partekatzen ditudan printzipio hauek gure ideiak hobetzera bideratu gaitezkeen puntu batera iristen lagundu digute, funtzionatzen duen bat aurkitzeko beharrean. Hala ere, hau ez da proiektu-plataforma bat. Planean oraindik gauza asko daude teknologiaren eta produktuaren ikuspuntutik.
1. printzipioa: Enpresa-balioa lehenik
Gure ahalegin guztietan "negozio-balioa" jartzen dugu. Oro har, analisi automatikoko edozein sistema automatizazio eta konplexutasun tekniko handiko sistema konplexuen multzoari dagokio. Irtenbide oso bat sortzeak denbora asko beharko du hutsetik sortzen baduzu. Negozioaren balioa lehenik eta osotasun teknologikoa bigarrenean jartzea erabaki genuen. Bizitza errealean, horrek esan nahi du ez dugula teknologia aurreratua dogma gisa onartzen. Momentu honetan hobekien egokitzen zaigun teknologia aukeratzen dugu. Denborarekin, badirudi modulu batzuk berriro ezarri beharko ditugula. Hau da onartu genuen konpromisoa.
2. printzipioa: Adimen areagotua
Apustu dut ikaskuntza automatikoko irtenbideak garatzen sakon inplikatuta ez dagoen jende gehienek pentsa dezaketela gizakiak ordezkatzea dela helburua. Izan ere, ikaskuntza automatikoko irtenbideak perfektutik urrun daude eta arlo jakin batzuetan soilik ordezkatzea posible da. Ideia hau hasieratik baztertu genuen hainbat arrazoirengatik: iruzurrezko jarduerari buruzko datu desorekatuak eta ikaskuntza automatikoko ereduetarako eginbideen zerrenda osoa emateko ezintasunagatik. Aitzitik, adimen hobetua aukera aukeratu dugu. Hau adimen artifizialaren kontzeptu alternatibo bat da, AIaren euskarri-eginkizunean oinarritzen dena, teknologia kognitiboek giza adimena hobetu beharrean dagoela azpimarratuz. [1]
Hori ikusita, ikaskuntza automatikoko irtenbide osoa hasieratik garatzeak esfortzu handia eskatuko luke, eta horrek gure negoziorako balio-sorkuntza atzeratuko luke. Gure domeinuko adituen gidaritzapean, etengabe hazten ari den ikaskuntza automatikoaren alderdi batekin sistema bat eraikitzea erabaki genuen. Sistema hori garatzearen erronka da gure analistei kasuak eman behar dizkiela, ez bakarrik iruzurrezko jarduera den ala ez. Oro har, bezeroen portaeraren edozein anomalia kasu susmagarri bat da, espezialistek nolabait ikertu eta erantzun behar dutena. Salatutako kasu horien zati bat bakarrik iruzur gisa kalifikatu daiteke.
3. printzipioa: Analitiko plataforma aberatsa
Gure sistemaren zatirik zailena sistemaren lan-fluxuaren amaierako egiaztapena da. Analistek eta garatzaileek erraz lortu beharko lituzkete datu-multzo historikoak analisirako erabiltzen diren metrika guztiekin. Gainera, datu-plataformak lehendik dagoen metrika-multzo bat berriekin osatzeko modu erraz bat eman beharko luke. Sortzen ditugun prozesuek, eta hauek ez dira software-prozesuak soilik, aurreko aldiak erraz kalkulatzeko, metrika berriak gehitzeko eta datu-iragarpena aldatzeko aukera eman beharko liguke. Gure ekoizpen sistemak sortzen dituen datu guztiak pilatuz lor genezake. Kasu honetan, pixkanaka datuak traba bihurtuko lirateke. Erabiltzen ez ditugun datu gero eta gehiago gorde eta babestu beharko genituzke. Eszenatoki horretan, datuak gero eta garrantzirik gabekoak izango dira denborarekin, baina hala ere gure ahaleginak behar ditu kudeatzeko. Guretzat datuen biltzeak ez zuen zentzurik, eta, beraz, beste ikuspegi bat hartzea erabaki genuen. Sailkatu nahi ditugun xede-entitateen inguruan denbora errealeko datu-biltegiak antolatzea erabaki dugu, eta aldi berrienak eta garrantzitsuenak egiaztatzeko aukera ematen diguten datuak soilik gordetzea. Ahalegin honen erronka gure sistema heterogeneoa dela da, eta modu koherentean funtzionatzeko plangintza zaindua behar duten datu-biltegi eta software-modulu ugari ditu.
Gure sistemaren diseinu kontzeptuak
Lau osagai nagusi ditugu gure sisteman: ingesta-sistema, konputazionala, BI analisia eta jarraipen-sistema. Helburu zehatz eta isolatuak betetzen dituzte, eta isolatuta mantentzen ditugu diseinu-ikuspegi zehatzak jarraituz.
Kontratuan oinarritutako diseinua
Lehenik eta behin, adostu genuen osagaiak haien artean pasatzen diren datu-egitura (kontratu) batzuetan soilik oinarritu behar zirela. Horrek errazten du haien artean integratzea eta osagaien konposizio (eta ordena) zehatzik ez inposatzea. Esaterako, kasu batzuetan, sarrera-sistema zuzenean integratzeko aukera ematen digu alertak jarraitzeko sistemarekin. Halakoetan, hitzartutako alerta-kontratuaren arabera egingo da. Horrek esan nahi du bi osagaiak beste edozein osagaik erabil dezakeen kontratu baten bidez integratuko direla. Ez dugu kontratu gehigarririk gehituko sarrera sistematik jarraipen-sistemari alertak gehitzeko. Ikuspegi honek aurrez zehaztutako gutxieneko kontratu kopuru bat erabiltzea eskatzen du eta sistema eta komunikazioak sinplifikatzen ditu. Funtsean, "Contract First Design" izeneko ikuspegia hartzen dugu eta streaming kontratuetan aplikatzen dugu. [2]
Streaming nonahi
Sistema batean egoera gordetzeak eta kudeatzea ezinbestean konplikazioak ekarriko ditu bere ezarpenean. Oro har, egoera edozein osagaitatik eskuragarri egon behar da, koherentea izan behar du eta osagai guztietan baliorik berriena eman behar du, eta fidagarria izan behar du balio zuzenekin. Gainera, biltegiratze iraunkorrerako deiak egiteak azken egoera berreskuratzeko I/O eragiketa kopurua eta gure denbora errealeko kanalizazioetan erabiltzen diren algoritmoen konplexutasuna areagotuko du. Horregatik, egoera biltegiratzea erabaki genuen, ahal bada, gure sistematik guztiz kentzea. Ikuspegi honek beharrezkoak diren datu guztiak transmititutako datu-blokean (mezuan) sartzea eskatzen du. Adibidez, behaketa batzuen guztizko kopurua kalkulatu behar badugu (ezaugarri jakin batzuk dituzten eragiketa edo kasuen kopurua), memorian kalkulatzen dugu eta halako balioen korrontea sortzen dugu. Menpeko moduluek partizioa eta loteak erabiliko dituzte korrontea entitateetan banatzeko eta azken balioekin funtzionatzeko. Planteamendu honek datu horietarako disko iraunkorra edukitzeko beharra ezabatu zuen. Gure sistemak Kafka erabiltzen du mezu-artekari gisa eta KSQL-rekin datu-base gisa erabil daiteke. [3] Baina hura erabiltzeak gure irtenbidea oso lotuko zuen Kafkarekin, eta ez erabiltzea erabaki genuen. Aukeratu dugun ikuspegiari esker, Kafka beste mezu-artekari batekin ordeztu dezakegu sisteman barne aldaketa handirik gabe.
Kontzeptu honek ez du esan nahi disko biltegiratzea eta datu-baseak erabiltzen ez ditugunik. Sistemaren errendimendua probatzeko eta aztertzeko, hainbat metrika eta egoera adierazten dituen datu kopuru esanguratsu bat gorde behar dugu diskoan. Puntu garrantzitsuena da denbora errealeko algoritmoak ez direla datu horien araberakoak. Kasu gehienetan, biltegiratutako datuak lineaz kanpo aztertzeko, arazketarako eta sistemak sortzen dituen kasu eta emaitza zehatzen jarraipena egiteko erabiltzen ditugu.
Gure sistemaren arazoak
Badira zenbait arazo maila jakin batera konpondu ditugunak, baina konponbide zehatzagoak eskatzen dituzte. Orain hemen aipatu nahiko nituzke puntu bakoitzak bere artikulua merezi duelako.
- Oraindik datu esanguratsu eta garrantzitsuak pilatzea onartzen duten prozesuak eta politikak definitu behar ditugu gure datuen analisi, aurkikuntza eta esplorazio automatizatuetarako.
- Giza analisiaren emaitzak sistema automatikoki konfiguratzeko prozesuan sartzea azken datuekin eguneratzeko. Hau gure eredua eguneratzeaz gain, gure prozesuak eguneratzea eta gure datuen ulermena hobetzea da.
- IF-ELSE eta MLren ikuspegi deterministaren arteko oreka bilatzea. Norbaitek esan zuen: "ML etsientzako tresna da". Horrek esan nahi du ML erabili nahi duzula zure algoritmoak nola optimizatu eta hobetu ulertzen ez duzunean. Bestalde, ikuspegi deterministak ez du aurreikusten ez ziren anomaliak detektatzeko aukera ematen.
- Modu erraz bat behar dugu gure hipotesiak edo datuen metriken arteko korrelazioak probatzeko.
- Sistemak benetako emaitza positiboen hainbat maila izan behar ditu. Iruzur kasuak sistemarentzat positibotzat jo daitezkeen kasu guztien zati bat baino ez dira. Esaterako, analistek kasu susmagarri guztiak jaso nahi dituzte egiaztatzeko, eta horietako zati txiki bat baino ez dira iruzurrak. Sistemak modu eraginkorrean aurkeztu behar dizkie kasu guztiak analistei, benetako iruzurra edo portaera susmagarria den kontuan hartu gabe.
- Datu-plataformak datu-multzo historikoak berreskuratu ahal izan behar ditu hegan sortutako eta kalkulatutako kalkuluekin.
- Inplementatu erraz eta automatikoki sistemaren osagaietako edozein gutxienez hiru ingurune desberdinetan: ekoizpenean, esperimentaletan (beta) eta garatzaileentzat.
- Eta azkenik. Errendimendu-probak egiteko plataforma aberats bat eraiki behar dugu, gure ereduak aztertu ahal izateko. [4]
Erreferentziak
Iturria: www.habr.com