Për rreth gjashtë muajt e fundit kam krijuar një sistem për të luftuar mashtrimin (veprimtari mashtruese, mashtrim, etj.) pa asnjë infrastrukturë fillestare për këtë. Idetë e sotme që kemi gjetur dhe zbatuar në sistemin tonë na ndihmojnë të zbulojmë dhe analizojmë shumë aktivitete mashtruese. Në këtë artikull do të doja të flisja për parimet që ndoqëm dhe çfarë bëmë për të arritur gjendjen aktuale të sistemit tonë, pa hyrë në pjesën teknike.
Parimet e sistemit tonë
Kur dëgjoni terma si "automatik" dhe "mashtrim", ka shumë të ngjarë të filloni të mendoni për mësimin e makinerive, Apache Spark, Hadoop, Python, Airflow dhe teknologji të tjera nga ekosistemi i Fondacionit Apache dhe fusha e Shkencës së të Dhënave. Mendoj se ka një aspekt të përdorimit të këtyre mjeteve që zakonisht nuk përmendet: ato kërkojnë disa parakushte në sistemin tuaj të ndërmarrjes përpara se të filloni t'i përdorni. Me pak fjalë, keni nevojë për një platformë të të dhënave të ndërmarrjes që përfshin një liqen dhe depo të dhënash. Por, çka nëse nuk keni një platformë të tillë dhe ende duhet ta zhvilloni këtë praktikë? Parimet e mëposhtme që po ndaj më poshtë na kanë ndihmuar të arrijmë një pikë ku mund të përqendrohemi në përmirësimin e ideve tona në vend që të gjejmë një që funksionon. Megjithatë, kjo nuk është një pllajë e projektit. Ka ende shumë gjëra në plan nga pikëpamja teknologjike dhe produkti.
Parimi 1: Vlera e biznesit së pari
Ne e vendosim "vlerën e biznesit" në krye të të gjitha përpjekjeve tona. Në përgjithësi, çdo sistem i analizës automatike i përket grupit të sistemeve komplekse me një nivel të lartë automatizimi dhe kompleksiteti teknik. Krijimi i një zgjidhjeje të plotë do të marrë shumë kohë nëse e krijoni atë nga e para. Ne vendosëm të vendosim vlerën e biznesit në radhë të parë dhe kompletimin teknologjik të dytë. Në jetën reale, kjo do të thotë se ne nuk e pranojmë teknologjinë e avancuar si dogmë. Ne zgjedhim teknologjinë që funksionon më mirë për ne për momentin. Me kalimin e kohës, mund të duket se do të na duhet të ri-zbatojmë disa module. Ky është kompromisi që kemi pranuar.
Parimi 2: Inteligjenca e shtuar
Vë bast se shumica e njerëzve që nuk janë thellësisht të përfshirë në zhvillimin e zgjidhjeve të mësimit të makinerive mund të mendojnë se zëvendësimi i njerëzve është qëllimi. Në fakt, zgjidhjet e mësimit të makinerive janë larg të qenit perfekte dhe vetëm në fusha të caktuara është i mundur zëvendësimi. Ne e hodhëm poshtë këtë ide që në fillim për disa arsye: të dhëna të pabalancuara mbi aktivitetin mashtrues dhe pamundësia për të ofruar një listë gjithëpërfshirëse të veçorive për modelet e mësimit të makinerive. Në të kundërt, ne zgjodhëm opsionin e inteligjencës së zgjeruar. Ky është një koncept alternativ i inteligjencës artificiale që fokusohet në rolin mbështetës të AI, duke theksuar faktin se teknologjitë njohëse synojnë të rrisin inteligjencën njerëzore në vend që ta zëvendësojnë atë. [1]
Nisur nga kjo, zhvillimi i një zgjidhjeje të plotë të mësimit të makinerive që në fillim do të kërkonte një përpjekje të madhe, e cila do të vononte krijimin e vlerës për biznesin tonë. Ne vendosëm të ndërtojmë një sistem me një aspekt të mësimit të makinerive në rritje të vazhdueshme nën drejtimin e ekspertëve tanë të domenit. Pjesa sfiduese e zhvillimit të një sistemi të tillë është se ai duhet t'u ofrojë analistëve tanë raste jo vetëm përsa i përket faktit nëse është një aktivitet mashtrues apo jo. Në përgjithësi, çdo anomali në sjelljen e klientit është një rast i dyshimtë që specialistët duhet ta hetojnë dhe të përgjigjen disi. Vetëm një pjesë e këtyre rasteve të raportuara mund të klasifikohen me të vërtetë si mashtrim.
Parimi 3: Platforma e pasur analitike
Pjesa më sfiduese e sistemit tonë është verifikimi nga fundi në fund i rrjedhës së punës së sistemit. Analistët dhe zhvilluesit duhet të marrin lehtësisht grupe të dhënash historike me të gjitha metrikat e përdorura 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 një grup ekzistues metrikash me të reja. Proceset që krijojmë, dhe këto nuk janë vetëm procese softuerike, duhet të na lejojnë të rillogaritim me lehtësi periudhat e mëparshme, të shtojmë metrika të reja dhe të ndryshojmë parashikimin e të dhënave. Ne mund ta arrijmë këtë duke grumbulluar të gjitha të dhënat që gjeneron sistemi ynë i prodhimit. Në këtë rast, të dhënat gradualisht do të bëheshin telash. Do të na duhet të ruajmë një sasi në rritje të të dhënave që nuk i përdorim dhe t'i mbrojmë ato. Në një skenar të tillë, të dhënat do të bëhen gjithnjë e më të parëndësishme me kalimin e kohës, por ende kërkojnë përpjekjet tona për t'i menaxhuar ato. Për ne, grumbullimi i të dhënave nuk kishte kuptim, kështu që vendosëm të merrnim një qasje tjetër. Ne vendosëm të organizojmë dyqane të dhënash në kohë reale rreth entiteteve të synuara që duam të klasifikojmë dhe të ruajmë vetëm të dhënat që na lejojnë të kontrollojmë periudhat më të fundit dhe më të rëndësishme. Sfida për këtë përpjekje është se sistemi ynë është heterogjen, me shumë depo të dhënash dhe module softuerësh që kërkojnë planifikim të kujdesshëm për të funksionuar në mënyrë të qëndrueshme.
Konceptet e projektimit të sistemit tonë
Ne kemi katër komponentë kryesorë në sistemin tonë: sistemin e gëlltitjes, llogaritës, analizën e BI dhe sistemin e gjurmimit. Ato shërbejnë për qëllime specifike, të izoluara dhe ne i mbajmë të izoluar duke ndjekur qasje specifike të projektimit.
Dizajni i bazuar në kontratë
Para së gjithash, ne ramë dakord që komponentët duhet të mbështeten vetëm në struktura të caktuara të dhënash (kontrata) që kalohen ndërmjet tyre. Kjo e bën të lehtë integrimin midis tyre dhe mos imponimin e 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 marrjes me sistemin e gjurmimit të alarmit. Në një rast të tillë, kjo do të bëhet në përputhje me kontratën e rënë dakord për alarm. Kjo do të thotë që të dy komponentët do të integrohen duke përdorur një kontratë që çdo komponent tjetër mund të përdorë. Ne nuk do të shtojmë një kontratë shtesë për të shtuar sinjalizime në sistemin e gjurmimit nga sistemi i hyrjes. Kjo qasje kërkon përdorimin e një numri minimal të paracaktuar kontratash dhe thjeshton sistemin dhe komunikimet. Në thelb, ne marrim një qasje të quajtur "Contract First Design" dhe e zbatojmë atë për kontratat e transmetimit. [2]
Transmetim kudo
Ruajtja dhe menaxhimi i gjendjes në një sistem do të çojë në mënyrë të pashmangshme në komplikime në zbatimin e tij. Në përgjithësi, gjendja duhet të jetë e aksesueshme nga çdo komponent, duhet të jetë e qëndrueshme dhe të ofrojë vlerën më aktuale në të gjithë komponentët dhe duhet të jetë e besueshme me vlerat e sakta. Për më tepër, të kesh thirrje në ruajtje të vazhdueshme për të rikthyer gjendjen më të fundit do të rrisë numrin e operacioneve I/O dhe kompleksitetin e algoritmeve të përdorura në tubacionet tona në kohë reale. Për shkak të kësaj, ne vendosëm të hiqnim ruajtjen e shtetit, nëse është e mundur, plotësisht nga sistemi ynë. Kjo qasje kërkon që të gjitha të dhënat e nevojshme të përfshihen në bllokun e të dhënave të transmetuara (mesazhit). Për shembull, nëse duhet të llogarisim numrin total të disa vëzhgimeve (numrin e operacioneve ose rastet me karakteristika të caktuara), ne e llogarisim atë në memorie dhe gjenerojmë një rrjedhë vlerash të tilla. Modulet e varura do të përdorin ndarjen dhe grumbullimin për të ndarë transmetimin në entitete dhe për të funksionuar sipas vlerave më të fundit. Kjo qasje eliminoi nevojën për të patur ruajtje të vazhdueshme në disk për të dhëna të tilla. Sistemi ynë përdor Kafka-n si ndërmjetës mesazhesh dhe mund të përdoret si bazë të dhënash me KSQL. [3] Por përdorimi i tij do ta kishte lidhur shumë zgjidhjen tonë me Kafkën dhe ne vendosëm të mos e përdornim atë. Qasja që zgjodhëm na lejon të zëvendësojmë Kafkën me një ndërmjetës tjetër mesazhesh pa ndryshime të mëdha të brendshme në sistem.
Ky koncept nuk do të thotë që ne nuk përdorim ruajtjen e diskut dhe bazat e të dhënave. Për të testuar dhe analizuar performancën e sistemit, ne duhet të ruajmë një sasi të konsiderueshme të dhënash në disk që përfaqësojnë metrika dhe gjendje të ndryshme. Pika e rëndësishme këtu është se algoritmet në kohë reale nuk varen nga të dhëna të tilla. Në shumicën e rasteve, ne përdorim të dhënat e ruajtura për analiza offline, korrigjimin dhe gjurmimin e rasteve dhe rezultateve specifike që prodhon sistemi.
Problemet e sistemit tonë
Ka disa probleme që ne i kemi zgjidhur në një nivel të caktuar, por ato kërkojnë zgjidhje më të menduara. Tani do të doja vetëm t'i përmend këtu sepse çdo pikë ia vlen artikullin e vet.
- Ne ende duhet të përcaktojmë procese dhe politika që mbështesin grumbullimin e të dhënave kuptimplota dhe të rëndësishme për analizën, zbulimin dhe eksplorimin tonë të automatizuar të të dhënave.
- Përfshirja e analizave njerëzore rezulton në procesin e konfigurimit automatik të sistemit për ta përditësuar atë me të dhënat më të fundit. Kjo nuk është vetëm përditësimi i modelit tonë, por gjithashtu përditësimi i proceseve tona dhe përmirësimi i të kuptuarit tonë të të dhënave tona.
- Gjetja e një ekuilibri midis qasjes deterministe të IF-ELSE dhe ML. Dikush tha: "ML është një mjet për të dëshpëruarit". Kjo do të thotë që ju do të dëshironi të përdorni ML kur nuk kuptoni më se si të optimizoni dhe përmirësoni algoritmet tuaja. Nga ana tjetër, qasja deterministe nuk lejon zbulimin e anomalive që nuk ishin parashikuar.
- Ne kemi nevojë për një mënyrë të thjeshtë për të testuar hipotezat tona ose korrelacionet midis metrikës në të dhëna.
- Sistemi duhet të ketë disa nivele të rezultateve të vërteta pozitive. Rastet e 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 për verifikim të gjitha rastet e dyshimta dhe vetëm një pjesë e vogël e tyre janë mashtrime. Sistemi duhet t'i paraqesë në mënyrë efikase të gjitha rastet tek analistët, pavarësisht nëse bëhet fjalë për mashtrim të vërtetë apo thjesht sjellje të dyshimtë.
- Platforma e të dhënave duhet të jetë në gjendje të marrë grupe të dhënash historike me llogaritjet e krijuara dhe të llogaritura në fluturim.
- Vendosni lehtësisht dhe automatikisht cilindo nga komponentët e sistemit në të paktën tre mjedise të ndryshme: prodhim, eksperimental (beta) dhe për zhvilluesit.
- Dhe e fundit por jo më pak e rëndësishme. Ne duhet të ndërtojmë një platformë të pasur testimi të performancës në të cilën mund të analizojmë modelet tona. [4]
Referencat
Burimi: www.habr.com