Gjatë gjashtë muajve të fundit, kam punuar në krijimin e një sistemi për luftimin e aktivitetit të paligjshëm (fraudulent activity, fraud, etc.) pa ndonjë infrastrukturë fillestare për këtë. Idetë e sotme që gjetëm dhe zbatuam në sistemin tonë na ndihmojnë të zbulojmë shumë aktivitete mashtruese dhe t'i analizojmë ato. Në këtë artikull do të doja të flisja për parimet që ndjekim dhe për atë që kemi bërë për të arritur gjendjen aktuale të sistemit tonë, pa u thelluar në detaje teknike.
Parimet e sistemit tonë
Kur dëgjoni terma si "automatic" dhe "fraud", ndoshta filloni të mendoni për mësimin e makinave, Apache Spark, Hadoop, Python, Airflow dhe teknologji të tjera të ekosistemit të Fondacionit Apache dhe fushës së Shkencës së të Dhënave. Mendoj se ka një aspekt të përdorimit të këtyre instrumenteve, i cili zakonisht nuk përmendet: ata kërkojnë kushte të caktuara paraprake në sistemin tuaj të korporatës para se të filloni t'i përdorni. Në mënyrë të thjeshtë, ju nevojitet një platformë korporative të dhënash që përfshin liqenin e të dhënave dhe një depo. Por çfarë nëse nuk e keni një platformë të tillë, dhe ju duhet ende të zhvilloni këtë praktikë? Parimet e mëposhtme, të cilat do t'i diskutoj më poshtë, na ndihmuan të arrijmë një moment kur mund të përqendrohemi në përmirësimin e ideve tona, në vend që të kërkojmë një zgjidhje që funksionon. Megjithatë, kjo nuk është një "platë" projekti. Ka ende shumë gjëra për të bërë nga këndvështrimi teknologjik dhe produktiv.
Parimi 1: vlera për biznesin në radhë të parë
Në krye të përpjekjeve tona kemi vendosur "vlerën për biznesin". Përgjithësisht, çdo sistem analize automatike i përket grupit të sistemeve komplekse me një nivel të lartë automatizimi dhe kompleksitet teknologjik. Krijimi i një zgjidhjeje të plotë do të kërkojë një kohë të gjatë nëse e krijoni nga e para. Ne vendosëm të japim përparësi vlerës së biznesit, dhe në vend të dytë, përfundimtarisë teknologjike. Në jetë reale, kjo do të thotë se ne nuk e pranojmë teknologjinë e avancuar si një dogmë. Ne zgjedhim teknologjinë që funksionon më mirë për ne në këtë moment. Me kalimin e kohës, mund të duket se do të na duhet të rikrijojmë disa module. Ky është një kompromis që ne pranuam.
Parimi 2: Intelligjenca e zgjeruar e njeriut (augmented intelligence)
Jam besoj se shumica e njerëzve që nuk janë thellë të angazhuar në zhvillimin e zgjidhjeve të mësimit të makinerive mund të mendojnë se zëvendësimi i njerëzve është qëllimi. Në të vërtetë, zgjidhjet e mësimit të makinerive janë shumë të largëta nga perfektesia dhe zëvendësimi është i mundur vetëm në disa fusha. Ne e kemi hedhur poshtë këtë ide që në fillim për disa arsye: të dhënat e paekuilibruara mbi aktivitete të mashtrimit dhe pamundësia për të ofruar një listë të plotë të karakteristikave për modelet e mësimit të makinerive. Ndryshe nga kjo, ne zgjedhim variantin e inteligjencës së zgjeruar. Kjo është një koncept alternativ i inteligjencës artificiale, i cili fokusohet në rolin ndihmës të AI, duke theksuar faktin që teknologjitë kognitive synojnë përmirësimin e inteligjencës njerëzore, jo zëvendësimin e saj. [1]
Duke këtë, zhvillimi i një zgjidhjeje të plotë të mësimit të makinave nga fillimi do të kërkonte përpjekje të mëdha, të cilat do të vononin krijimin e vlerës për biznesin tonë. Ne vendosëm të ndërtojmë një sistem me një aspekt të rritësit iterativ të mësimit të makinave nën udhëheqjen e ekspertëve tanë në fushë. Pjesa e ndërlikuar e zhvillimit të një sistemi të tillë është se ai duhet t'u ofrojë analistëve tanë raste jo vetëm në pikëpamje të asaj nëse është ose jo aktivitet i ndëshkueshëm. Në përgjithësi, çdo anomali në sjelljen e klientëve është një rast i dyshimtë që specialistët duhet ta hetojnë dhe të reagojnë përkatësisht. Vetëm një pjesë e vogël e këtyre rasteve të regjistruara vërtet mund të klasifikohen si mashtrim.
Principi 3: platforma e të dhënave analitike të gjera
Pjesa më e vështirë e sistemit tonë është kontrolli i vazhdueshëm i procesit të punës. Analistët dhe zhvilluesit duhet të kenë lehtësinë për të marrë grumbuj të dhënash nga periudhat e kaluara me të gjitha metrikat që janë përdorur për analizë. Për më tepër, platforma e të dhënave duhet të ofrojë një mënyrë të thjeshtë për të plotësuar grumbujt ekzistues të metrikave me të reja. Proceset që krijojmë, e që nuk janë vetëm procese software, duhet të lejojnë përsëritjen e periudhave të kaluara, shtimin e metrikave të reja dhe ndryshimin e parashikimit të të dhënave. Ne do të mund të arrijmë këtë duke akumuluar të gjitha të dhënat që gjeneron sistemi ynë prodhues. Në një rast të tillë, të dhënat gradualisht do të bëheshin një pengesë. Ne do të duhej të ruanim një volum në rritje të të dhënave që nuk i përdorim dhe t'i mbrojmë ato. Në një skenar të tillë, me kalimin e kohës, të dhënat do të bëheshin gjithnjë e më pak relevante, por do të kërkonin ende përpjekjet tona për menaxhimin e tyre. Për ne, akumulimi i të dhënave (data hoarding) nuk kishte kuptim, dhe ne vendosëm të përdorim një qasje tjetër. Ne vendosëm të organizojmë depozitat e të dhënave në kohë reale rreth entiteteve që dëshirojmë të klasifikojmë dhe të ruajmë vetëm ato të dhëna që lejojnë verifikimin e periudhave më të fundit dhe më relevante. Kompleksiteti i këtyre përpjekjeve është se sistemi ynë është heterogjen me disa depozita të dhënash dhe module software që kërkojnë planifikim të kujdesshëm për një funksionim të koordinuar.
Konceptele konstruktive të sistemit tonë
Ne kemi katër komponentë kryesorë në sistemin tonë: sistemi i marrjes (ingestion system), llogaritjes (computational), analizës (BI analysis) dhe sistemi i ndjekjes (tracking system). Ata shërbejnë për qëllime specifike dhe ne i mbajmë të izoluar, duke ndjekur qasje të caktuara në zhvillim.
Dizajni i bazuar në kontrata
Së pari, ne rënë dakord se komponentët duhet të mbështeten vetëm në struktura të caktuara të dhënash (kontrata) që kalojnë mes tyre. Kjo lejon integrimin e lehtë midis tyre dhe nuk imponon një përbërje (dhe renditje) specifike të komponentëve. Për shembull, në disa raste, kjo na lejon të integrojmë drejtpërdrejt sistemin e pranimit me sistemin e ndjekjes së alarmeve. Në këtë rast, do të bëhet në përputhje me kontratën e rënë dakord për alarmet. Kjo do të thotë se të dy komponentët do të integrohen duke përdorur kontratën që mund të përdoret nga çdo komponent tjetër. Nuk do të shtojmë një kontratë shtesë për shtimin e alarmeve në sistemin e ndjekjes nga sistemi i hyrjes. Ky qasje kërkon përdorimin e një numri minimal të kontratave të paracaktuara dhe thjeshton sistemin dhe komunikimet. Në thelb, ne përdorim një qasje të quajtur "Dizajn i Parë me Kontratë", dhe e aplikojmë atë në kontratat e transmetimit të të dhënave. [2]
Transmetimi kudo
Ruajtja dhe menaxhimi i gjendjes në sistem patjetër do të sjellin komplikime në zbatimin e tij. Në përgjithësi, gjendja duhet të jetë e aksesueshme nga çdo komponent, duhet të jetë në përputhje dhe të ofrojë vlerën më të saktë për të gjithë komponentët, dhe duhet të jetë e besueshme me vlera të sakta. Për më tepër, pranimi i thirrjeve në magazinën e përhershme për të marrë gjendjen e fundit do të rrisë numrin e operacioneve të hyrjes-daljes dhe kompleksitetin e algoritmeve që përdoren në tubat tanë në kohë reale. Për këtë arsye, ne vendosëm ta heqim sa më shumë që të jetë e mundur ruajtjen e gjendjes nga sistemi ynë. Ky qasje kërkon përfshirjen e të dhënave të nevojshme në bllokun e të dhënave të transmetuar (mesazhi). Për shembull, nëse na nevojitet të llogarisim numrin total të disa vëzhgimeve (numri i operacioneve ose rasteve me karakteristika të caktuara), ne e llogarisim atë në kujtesë dhe krijojmë një rrjedhë të tillë vlerash. Modulet e varura do të përdorin ndarjen (partition) dhe paketimin (batch) për të copëtuar rrjedhën sipas entiteteve dhe për të operuar me vlerat më të fundit. Ky qasje eliminoi nevojën për të pasur një magazinë konstante për të dhëna të tilla. Sistema jonë përdor Kafka si broker mesazhesh, dhe mund të përdoret si një bazë të dhënash me KSQL. [3] Por përdorimi i tij do të lidhte shumë zgjidhjen tonë me Kafka, dhe ne vendosëm të mos e përdorim atë. Qasja që zgjodhëm na lejon të zëvendësojmë Kafka me një broker tjetër mesazhesh pa ndryshime të mëdha brenda sistemit.
Ky эта концепte nėra që do ishim pa përdorim diskesh të ruajtjes dhe bazash të dhënash. Për të kontrolluar dhe analizuar performancën e sistemit, duhet të ruajmë në disk një pjesë të konsiderueshme të të dhënave që paraqesin tregues dhe gjendje të ndryshme. Një pikë e rëndësishme këtu është se algoritmet në kohë reale nuk varen nga këto të dhëna. Në shumicën e rasteve, ne përdorim të dhënat e ruajtura për analiza autonome, debugging dhe gjurmimin e rasteve dhe rezultateve specifike që solli sistemi.
Problemet e sistemit tonë
Ka disa probleme që ne i kemi zgjidhur deri në njëfarë niveli, por ato kërkojnë zgjidhje më të menduara. Tani, do doja t'i përmendja këtu, sepse secila pikë meriton një artikull të veçantë.
- Na nevojitet ende të përcaktojmë proceset dhe politikat që ndihmojnë në grumbullimin e të dhënave relevante dhe domethënëse për analizën tonë automatike, zbulimin dhe hulumtimin e të dhënave.
- Inkurimi i rezultateve të analizave njerëzore në procesin e automatizimit të konfigurimit të sistemit për ta përditësuar sipas të dhënave më të fundit. Kjo nuk është vetëm përditësimi i modelit tonë, por gjithashtu përditësimi i proceseve dhe përmirësimi i kuptimit të të dhënave tona.
- Gjetja e balancit mes qasjes së përcaktuar IF-ELSE dhe ML. Disa thonë: «ML është një mjet për ata që janë në dëshpërim». Kjo do të thotë që do të dëshironit të përdorni ML kur nuk e kuptoni më se si të optimizoni dhe përmirësoni algoritmet tuaja. Nga ana tjetër, qasja e përcaktuar nuk lejon zbulimin e anomalive që nuk ishin parashikuar.
- Na nevojitet një mënyrë e thjeshtë për të verifikuar hipotezat tona ose korelacionet mes metrikave në të dhëna.
- Sistemi duhet të ketë disa nivele të rezultateve të vërtetë pozitive (true positive). Raste të mashtrimit janë vetëm një pjesë e të gjitha rasteve që mund të konsiderohen pozitive për sistemin. Për shembull, analistët duan të marrin të gjithë rastet e dyshimta për verifikim, dhe vetëm një pjesë e vogël e tyre është mashtrim. Sistemi duhet të ofrojë efikasitet analistëve në mënyrë që të marrin të gjitha rastet, pavarësisht nëse është një mashtrim i vërtetë ose thjesht një sjellje e dyshimtë.
- Platforma e të dhënave duhet të lejojë marrjen e grupeve të dhënash për periudha të kaluara me llogaritjet që janë krijuar dhe llogaritur në kohë reale.
- Një shpërndarje e thjeshtë dhe automatike e çdo komponenti të sistemit në të paktën tri mjedise të ndryshme: një prodhuese, një eksperimantale (beta) dhe një për zhvilluesit.
- Dhe e fundit, por jo më pak e rëndësishme. Na nevojitet të krijojmë një platformë të gjerë për verifikimin e performancës, në të cilën mund të analizojmë modelet tona. [4]
Linke
Burimi: habr.com
