Viimased umbes kuus kuud olen loonud süsteemi pettuste (pettuslik tegevus, pettus jne) vastu võitlemiseks ilma selle jaoks esialgse infrastruktuurita. Tänased ideed, mille oleme leidnud ja oma süsteemis rakendanud, aitavad meil tuvastada ja analüüsida paljusid pettusi. Selles artiklis tahaksin rääkida põhimõtetest, mida järgisime ja mida tegime oma süsteemi praeguse seisu saavutamiseks, ilma tehnilisse ossa laskumata.
Meie süsteemi põhimõtted
Kui kuulete selliseid termineid nagu "automaatne" ja "pettus", hakkate tõenäoliselt mõtlema masinõppele, Apache Sparkile, Hadoopile, Pythonile, Airflow'le ja teistele Apache Foundationi ökosüsteemi ja andmeteaduse valdkonna tehnoloogiatele. Arvan, et nende tööriistade kasutamisel on üks aspekt, mida tavaliselt ei mainita: need nõuavad teie ettevõtte süsteemis teatud eeltingimusi, enne kui saate neid kasutama hakata. Lühidalt öeldes on teil vaja ettevõtte andmeplatvormi, mis sisaldab andmejärve ja -ladu. Aga mis siis, kui teil sellist platvormi pole ja teil on siiski vaja seda praktikat arendada? Järgmised põhimõtted, mida ma allpool jagan, on aidanud meil jõuda punkti, kus saame keskenduda oma ideede täiustamisele, selle asemel, et leida üks, mis toimib. See pole aga projekti platoo. Kavas on veel palju asju tehnoloogilisest ja tootelisest aspektist.
1. põhimõte: esiteks äriväärtus
Seame äriväärtuse kõigis oma jõupingutustes esikohale. Üldiselt kuulub igasugune automaatne analüüsisüsteem kõrge automatiseerituse ja tehnilise keerukusega keeruliste süsteemide rühma. Terviklahenduse loomine võtab palju aega, kui loote selle nullist. Otsustasime seada esikohale äriväärtuse ja teisele kohale tehnoloogilise terviklikkuse. Reaalses elus tähendab see, et me ei aktsepteeri arenenud tehnoloogiat dogmana. Valime tehnoloogia, mis meie jaoks hetkel kõige paremini töötab. Aja jooksul võib tunduda, et peame mõned moodulid uuesti kasutusele võtma. See on kompromiss, mille me aktsepteerisime.
2. põhimõte: laiendatud intelligentsus
Vean kihla, et enamik inimesi, kes pole masinõppelahenduste väljatöötamisega põhjalikult seotud, võivad arvata, et eesmärk on inimeste asendamine. Tegelikult pole masinõppe lahendused kaugeltki täiuslikud ja ainult teatud valdkondades on võimalik asendada. Lükkasime selle idee algusest peale tagasi mitmel põhjusel: petturliku tegevuse andmed on tasakaalustamata ja suutmatus pakkuda masinõppemudelite jaoks kõikehõlmavat funktsioonide loendit. Seevastu valisime täiustatud luurevõimaluse. See on alternatiivne tehisintellekti kontseptsioon, mis keskendub tehisintellekti toetavale rollile, rõhutades tõsiasja, et kognitiivsed tehnoloogiad on mõeldud inimese intelligentsuse suurendamiseks, mitte selle asendamiseks. [1]
Seda arvestades nõuaks tervikliku masinõppelahenduse väljatöötamine algusest peale tohutut pingutust, mis lükkaks meie ettevõttele väärtuse loomise edasi. Otsustasime oma domeeniekspertide juhendamisel luua korduvalt kasvava masinõppe aspektiga süsteemi. Sellise süsteemi väljatöötamise keeruline osa seisneb selles, et see peab andma meie analüütikutele juhtumeid mitte ainult selles osas, kas tegemist on pettusega või mitte. Üldiselt on igasugune anomaalia klientide käitumises kahtlane juhtum, mida spetsialistid peavad uurima ja sellele kuidagi reageerima. Vaid murdosa neist teatatud juhtumitest saab tõepoolest liigitada pettusteks.
3. põhimõte: rikas analüüsiplatvorm
Meie süsteemi kõige keerulisem osa on süsteemi töövoo täielik kontrollimine. Analüütikud ja arendajad peaksid hõlpsasti hankima ajaloolisi andmekogumeid koos kõigi analüüsiks kasutatavate mõõdikutega. Lisaks peaks andmeplatvorm pakkuma lihtsat viisi olemasoleva mõõdikute komplekti täiendamiseks uutega. Meie loodud protsessid ja need ei ole ainult tarkvaraprotsessid, peaksid võimaldama hõlpsalt eelmisi perioode ümber arvutada, uusi mõõdikuid lisada ja andmete prognoosi muuta. Seda saaksime saavutada, kui kogume kõik andmed, mida meie tootmissüsteem genereerib. Sellisel juhul muutuksid andmed järk-järgult häirivaks. Peaksime talletama üha suuremat hulka andmeid, mida me ei kasuta, ja neid kaitsma. Sellise stsenaariumi korral muutuvad andmed aja jooksul üha ebaolulisemaks, kuid nende haldamine nõuab siiski meie jõupingutusi. Meie jaoks ei olnud andmete kogumisel mõtet, mistõttu otsustasime kasutada teistsugust lähenemist. Otsustasime korraldada reaalajas andmesalved sihtüksuste ümber, mida tahame klassifitseerida, ja salvestada ainult need andmed, mis võimaldavad meil kontrollida kõige värskemaid ja asjakohasemaid perioode. Selle jõupingutuse väljakutse seisneb selles, et meie süsteem on heterogeenne, mitme andmesalve ja tarkvaramooduliga, mille järjepidevaks toimimiseks on vaja hoolikat planeerimist.
Meie süsteemi disainikontseptsioonid
Meie süsteemis on neli põhikomponenti: sisestussüsteem, arvutuslik, BI-analüüs ja jälgimissüsteem. Need teenivad konkreetseid, eraldatud eesmärke ja me hoiame neid isoleerituna, järgides konkreetseid disainilahendusi.
Lepingupõhine disain
Esiteks leppisime kokku, et komponendid peaksid tuginema ainult teatud andmestruktuuridele (lepingutele), mida nende vahel edastatakse. See muudab nendevahelise integreerimise lihtsaks ja ei kehtesta komponentide konkreetset koostist (ja järjekorda). Näiteks mõnel juhul võimaldab see sisselaskesüsteemi otse häirejälgimissüsteemiga integreerida. Sellisel juhul tehakse seda vastavalt kokkulepitud häirelepingule. See tähendab, et mõlemad komponendid integreeritakse lepingu alusel, mida saab kasutada mis tahes muu komponent. Me ei lisa täiendavat lepingut jälgimissüsteemi hoiatuste lisamiseks sisendsüsteemist. Selline lähenemine nõuab etteantud minimaalse arvu lepingute kasutamist ning lihtsustab süsteemi ja sidet. Põhimõtteliselt kasutame lähenemisviisi nimega "Lepingu esimene disain" ja rakendame seda voogedastuslepingute puhul. [2]
Voogesitus kõikjal
Riigi salvestamine ja haldamine süsteemis toob paratamatult kaasa komplikatsioone selle rakendamisel. Üldiselt peaks olek olema juurdepääsetav mis tahes komponendist, see peaks olema järjepidev ja pakkuma kõigi komponentide jaoks kõige värskemat väärtust ning see peaks olema õigete väärtustega usaldusväärne. Lisaks suurendab uusima oleku hankimiseks püsivale salvestusruumile helistamine sisend-/väljundoperatsioonide arvu ja meie reaalajas kasutatavate konveierite algoritmide keerukust. Seetõttu otsustasime võimaluse korral olekusalvestuse oma süsteemist täielikult eemaldada. Selline lähenemine eeldab, et edastatavasse andmeplokki (sõnumisse) lisatakse kõik vajalikud andmed. Näiteks kui meil on vaja arvutada mõne vaatluse koguarv (teatud tunnustega operatsioonide või juhtumite arv), arvutame selle mälus ja genereerime selliste väärtuste voo. Sõltuvad moodulid kasutavad voo üksusteks jagamiseks ja uusimate väärtustega töötamiseks partitsiooni ja partitsiooni. See lähenemisviis kõrvaldas vajaduse selliste andmete jaoks püsiva kettasalvestuse järele. Meie süsteem kasutab Kafkat sõnumivahendajana ja seda saab kasutada KSQL-iga andmebaasina. [3] Kuid selle kasutamine oleks sidunud meie lahenduse tugevalt Kafkaga ja me otsustasime seda mitte kasutada. Meie valitud lähenemine võimaldab meil asendada Kafka mõne teise sõnumivahendajaga, ilma et oleks vaja süsteemis suuri muudatusi teha.
See mõiste ei tähenda, et me ei kasuta kettasalvestust ja andmebaase. Süsteemi jõudluse testimiseks ja analüüsimiseks peame kettale salvestama märkimisväärse hulga andmeid, mis esindavad erinevaid mõõdikuid ja olekuid. Siin on oluline, et reaalajas algoritmid ei sõltu sellistest andmetest. Enamasti kasutame salvestatud andmeid võrguühenduseta analüüsiks, silumiseks ning süsteemi poolt toodetavate konkreetsete juhtumite ja tulemuste jälgimiseks.
Meie süsteemi probleemid
On teatud probleeme, mille oleme teatud tasemeni lahendanud, kuid need nõuavad rohkem läbimõeldud lahendusi. Nüüd tahaksin neid siin lihtsalt mainida, sest iga punkt on väärt oma artiklit.
- Peame ikkagi määratlema protsessid ja poliitikad, mis toetavad sisuliste ja asjakohaste andmete kogumist meie automatiseeritud andmete analüüsi, avastamise ja uurimise jaoks.
- Inimanalüüsi tulemuste kaasamine süsteemi automaatse seadistamise protsessi, et värskendada seda uusimate andmetega. See ei tähenda ainult meie mudeli värskendamist, vaid ka protsesside värskendamist ja andmete mõistmise parandamist.
- Tasakaalu leidmine IF-ELSE ja ML deterministliku lähenemise vahel. Keegi ütles: "ML on meeleheitel olevate inimeste tööriist." See tähendab, et soovite kasutada ML-i, kui te enam ei mõista, kuidas oma algoritme optimeerida ja täiustada. Teisest küljest ei võimalda deterministlik lähenemine avastada anomaaliaid, mida ei osatud ette näha.
- Vajame lihtsat viisi oma hüpoteeside või andmetes olevate mõõdikute vaheliste korrelatsioonide testimiseks.
- Süsteemil peab olema mitu taset tõeliselt positiivseid tulemusi. Pettusejuhtumid on vaid murdosa juhtumitest, mida võib süsteemi jaoks positiivseks pidada. Näiteks soovivad analüütikud saada kontrollimiseks kõik kahtlased juhtumid ja vaid väike osa neist on pettused. Süsteem peab analüütikutele tõhusalt esitama kõik juhtumid, olenemata sellest, kas tegemist on tegeliku pettusega või lihtsalt kahtlase käitumisega.
- Andmeplatvorm peaks suutma hankida ajaloolisi andmekogumeid koos arvutustega, mis genereeritakse ja arvutatakse käigu pealt.
- Saate hõlpsasti ja automaatselt juurutada mis tahes süsteemikomponente vähemalt kolmes erinevas keskkonnas: tootmis-, katse- (beeta) ja arendajatele mõeldud keskkonnas.
- Ja viimane, kuid mitte vähem oluline. Peame üles ehitama rikkaliku jõudlustestimise platvormi, millel saame oma mudeleid analüüsida. [4]
Viited
Allikas: www.habr.com