Automātiskas sistēmas izveide, lai apkarotu iebrucējus vietnē (krāpÅ”ana)

Apmēram pēdējos seÅ”us mēneÅ”us esmu veidojis sistēmu cīņai pret krāpÅ”anu (krāpnieciska darbÄ«ba, krāpÅ”ana utt.) bez tam nekādas sākotnējās infrastruktÅ«ras. Å odienas idejas, ko atradām un ieviesām savā sistēmā, palÄ«dz mums atklāt un analizēt daudzas krāpnieciskas darbÄ«bas. Å ajā rakstā es vēlos runāt par principiem, kurus mēs ievērojām un ko mēs darÄ«jām, lai sasniegtu mÅ«su sistēmas paÅ”reizējo stāvokli, neiedziļinoties tehniskajā daļā.

Mūsu sistēmas principi

Kad dzirdat tādus terminus kā ā€œautomātisksā€ un ā€œkrāpÅ”anaā€, jÅ«s, visticamāk, sākat domāt par maŔīnmācÄ«Å”anos, Apache Spark, Hadoop, Python, Airflow un citām tehnoloÄ£ijām Apache Foundation ekosistēmā un datu zinātnes jomā. Manuprāt, ir viens Å”o rÄ«ku izmantoÅ”anas aspekts, kas parasti netiek pieminēts: pirms to izmantoÅ”anas jÅ«su uzņēmuma sistēmā ir jābÅ«t noteiktiem priekÅ”nosacÄ«jumiem. ÄŖsāk sakot, jums ir nepiecieÅ”ama uzņēmuma datu platforma, kas ietver datu ezeru un krātuvi. Bet ko darÄ«t, ja jums nav Ŕādas platformas un jums joprojām ir jāattÄ«sta Ŕī prakse? Tālāk minētie principi, kurus es aprakstu tālāk, ir palÄ«dzējuÅ”i mums sasniegt punktu, kurā varam koncentrēties uz savu ideju uzlaboÅ”anu, nevis uz funkcionējoÅ”as idejas atraÅ”anu. Tomēr tas nav projekta "plato". Plānā ir daudz vairāk lietu no tehnoloÄ£iskā un produktu viedokļa.

1. princips. Pirmkārt, biznesa vērtība

Mēs visu savu centienu priekÅ”galā izvirzām ā€œbiznesa vērtÄ«buā€. Kopumā jebkura automātiskās analÄ«zes sistēma pieder kompleksu sistēmu grupai ar augstu automatizācijas un tehniskās sarežģītÄ«bas lÄ«meni. Pilna risinājuma izveide prasÄ«s daudz laika, ja izveidosit to no nulles. Mēs nolēmām biznesa vērtÄ«bu likt pirmajā vietā un tehnoloÄ£isko briedumu otrajā vietā. Reālajā dzÄ«vē tas nozÄ«mē, ka mēs nepieņemam progresÄ«vās tehnoloÄ£ijas kā dogmu. Mēs izvēlamies to tehnoloÄ£iju, kas mums Å”obrÄ«d ir vispiemērotākā. Laika gaitā var Ŕķist, ka daži moduļi mums bÅ«s jāievieÅ” no jauna. Å is ir kompromiss, kuru mēs pieņēmām.

2. princips: Papildināts intelekts

Varu derēt, ka lielākā daļa cilvēku, kuri nav dziļi iesaistÄ«ti maŔīnmācÄ«Å”anās risinājumu izstrādē, varētu domāt, ka mērÄ·is ir cilvēku aizstāŔana. Faktiski maŔīnmācÄ«Å”anās risinājumi nebÅ«t nav perfekti, un tikai noteiktās jomās ir iespējama nomaiņa. Mēs no paÅ”a sākuma atteicāmies no Ŕīs idejas vairāku iemeslu dēļ: nesabalansēti dati par krāpnieciskām darbÄ«bām un nespēja nodroÅ”ināt izsmeļoÅ”u maŔīnmācÄ«Å”anās modeļu funkciju sarakstu. Turpretim mēs izvēlējāmies paplaÅ”inātās izlÅ«koÅ”anas iespēju. Å Ä« ir alternatÄ«va mākslÄ«gā intelekta koncepcija, kas koncentrējas uz AI atbalsta lomu, uzsverot faktu, ka kognitÄ«vās tehnoloÄ£ijas ir izstrādātas, lai uzlabotu cilvēka intelektu, nevis to aizstātu. [1]

Paturot to prātā, pilnÄ«ga maŔīnmācÄ«Å”anās risinājuma izstrāde no paÅ”a sākuma prasÄ«tu milzÄ«gu piepÅ«li, kas aizkavētu mÅ«su biznesa vērtÄ«bas radÄ«Å”anu. Mēs nolēmām izveidot sistēmu ar iteratÄ«vi augoÅ”u maŔīnmācÄ«bas aspektu mÅ«su domēna ekspertu vadÄ«bā. Šādas sistēmas izstrādes sarežģītākā daļa ir tāda, ka tai ir jāsniedz mÅ«su analÄ«tiÄ·iem gadÄ«jumu izpēte ne tikai attiecÄ«bā uz to, vai tā ir krāpnieciska darbÄ«ba. Kopumā jebkura anomālija klientu uzvedÄ«bā ir aizdomÄ«gs gadÄ«jums, kas speciālistiem ir jāizmeklē un kaut kā jāreaģē. Tikai dažus no Å”iem reÄ£istrētajiem gadÄ«jumiem tieŔām var klasificēt kā krāpÅ”anu.

3. princips. Rich Insights platforma

MÅ«su sistēmas sarežģītākā daļa ir sistēmas darbplÅ«smas pilnÄ«ga pārbaude. AnalÄ«tiÄ·iem un izstrādātājiem vajadzētu viegli iegÅ«t vēsturiskās datu kopas ar visiem analÄ«zei izmantotajiem rādÄ«tājiem. Turklāt datu platformai ir jānodroÅ”ina vienkārÅ”s veids, kā papildināt esoÅ”o rādÄ«tāju kopumu ar jaunu. MÅ«su izveidotajiem procesiem, kas nav tikai programmatÅ«ras procesi, vajadzētu atvieglot iepriekŔējo periodu pārrēķinu, jaunu metrikas pievienoÅ”anu un datu prognozes mainÄ«Å”anu. Mēs to varētu sasniegt, uzkrājot visus datus, ko Ä£enerē mÅ«su ražoÅ”anas sistēma. Šādā gadÄ«jumā dati pakāpeniski kļūtu par Ŕķērsli. Mums bÅ«tu jāsaglabā pieaugoÅ”ais datu apjoms, ko neizmantojam, un tie jāaizsargā. Šādā scenārijā dati laika gaitā kļūs arvien nenozÄ«mÄ«gāki, taču joprojām ir jāpieliek pÅ«les, lai tos pārvaldÄ«tu. Mums nebija jēgas datu uzkrāŔanai, un mēs nolēmām izmantot citu pieeju. Mēs nolēmām organizēt reāllaika datu noliktavas ap mērÄ·a entÄ«tijām, kuras vēlamies klasificēt, un glabāt tikai tos datus, kas ļauj pārbaudÄ«t jaunākos un jaunākos periodus. Å o centienu izaicinājums ir tāds, ka mÅ«su sistēma ir neviendabÄ«ga ar vairākiem datu krātuvēm un programmatÅ«ras moduļiem, kuru konsekventai darbÄ«bai nepiecieÅ”ama rÅ«pÄ«ga plānoÅ”ana.

Mūsu sistēmas dizaina koncepcijas

MÅ«su sistēmā ir četri galvenie komponenti: uzņemÅ”anas sistēma, skaitļoÅ”anas sistēma, BI analÄ«ze un izsekoÅ”anas sistēma. Tie kalpo konkrētiem izolētiem mērÄ·iem, un mēs tos turam izolēti, ievērojot noteiktas attÄ«stÄ«bas pieejas.

Automātiskas sistēmas izveide, lai apkarotu iebrucējus vietnē (krāpÅ”ana)

Uz līgumu balstīts dizains

Pirmkārt, mēs vienojāmies, ka komponentiem ir jāpaļaujas tikai uz noteiktām datu struktÅ«rām (lÄ«gumiem), kas tiek nodoti starp tiem. Tas ļauj viegli integrēt tos un neuzlikt noteiktu sastāvdaļu sastāvu (un secÄ«bu). Piemēram, dažos gadÄ«jumos tas ļauj mums tieÅ”i integrēt saņemÅ”anas sistēmu ar brÄ«dinājumu izsekoÅ”anas sistēmu. Šādā gadÄ«jumā tas tiks darÄ«ts saskaņā ar saskaņoto paziņoÅ”anas lÄ«gumu. Tas nozÄ«mē, ka abas sastāvdaļas tiks integrētas, izmantojot lÄ«gumu, ko var izmantot jebkura cita sastāvdaļa. Mēs nepievienosim papildu lÄ«gumu par brÄ«dinājumu pievienoÅ”anu izsekoÅ”anas sistēmai no ievades sistēmas. Å Ä« pieeja prasa izmantot iepriekÅ” noteiktu minimālo lÄ«gumu skaitu un vienkārÅ”o sistēmu un sakarus. BÅ«tÄ«bā mēs izmantojam pieeju, ko sauc par ā€œLÄ«guma pirmā noformÄ“Å”anaā€, un piemērojam to straumÄ“Å”anas lÄ«gumiem. [2]

StraumēŔana visur

Valsts glābÅ”ana un vadÄ«Å”ana sistēmā neizbēgami radÄ«s sarežģījumus tās ievieÅ”anā. Parasti stāvoklim ir jābÅ«t pieejamam no jebkura komponenta, tam jābÅ«t konsekventam un jānodroÅ”ina visjaunākā vērtÄ«ba visos komponentos, kā arÄ« jābÅ«t uzticamam ar pareizajām vērtÄ«bām. Turklāt izsaukumi uz pastāvÄ«go krātuvi, lai iegÅ«tu jaunāko stāvokli, palielinās I/O apjomu un mÅ«su reāllaika konveijeros izmantoto algoritmu sarežģītÄ«bu. Å Ä« iemesla dēļ mēs nolēmām pilnÄ«bā noņemt stāvokļa krātuvi, ja iespējams, no mÅ«su sistēmas. Å Ä« pieeja prasa, lai visi nepiecieÅ”amie dati tiktu iekļauti pārsÅ«tÄ«tajā datu vienÄ«bā (ziņojumā). Piemēram, ja mums ir jāaprēķina dažu novērojumu kopējais skaits (operāciju vai gadÄ«jumu skaits ar noteiktiem raksturlielumiem), mēs to aprēķinām atmiņā un Ä£enerējam Ŕādu vērtÄ«bu plÅ«smu. AtkarÄ«gie moduļi izmantos sadalÄ«Å”anu un pakeÅ”u veidoÅ”anu, lai sadalÄ«tu straumi pa entÄ«tijām un darbotos ar jaunākajām vērtÄ«bām. Å Ä« pieeja novērÅ” nepiecieÅ”amÄ«bu pēc pastāvÄ«gas diska uzglabāŔanas Ŕādiem datiem. MÅ«su sistēma izmanto Kafka kā ziņojumu brokeri, un to var izmantot kā datu bāzi ar KSQL. [3] Taču tā izmantoÅ”ana mÅ«su risinājumu cieÅ”i sasaistÄ«tu ar Kafku, un mēs nolēmām to neizmantot. MÅ«su izvēlētā pieeja ļauj aizstāt Kafku ar citu ziņojumu brokeri bez bÅ«tiskām iekŔējām izmaiņām sistēmā.

Å is jēdziens nenozÄ«mē, ka mēs neizmantojam diska krātuvi un datu bāzes. Lai pārbaudÄ«tu un analizētu sistēmas veiktspēju, mums diskā jāsaglabā ievērojams datu apjoms, kas atspoguļo dažādus rādÄ«tājus un stāvokļus. SvarÄ«gi ir tas, ka reāllaika algoritmi nav atkarÄ«gi no Ŕādiem datiem. Vairumā gadÄ«jumu mēs izmantojam saglabātos datus bezsaistes analÄ«zei, atkļūdoÅ”anai un konkrētu gadÄ«jumu un sistēmas radÄ«to rezultātu izsekoÅ”anai.

Mūsu sistēmas problēmas

Ir noteiktas problēmas, kuras esam atrisinājuÅ”i lÄ«dz noteiktam lÄ«menim, taču tām ir nepiecieÅ”ami pārdomātāki risinājumi. Pagaidām es gribētu tos Å”eit tikai pieminēt, jo katrs priekÅ”mets ir sava raksta vērts.

  • Mums joprojām ir jādefinē procesi un politikas, kas palÄ«dz Ä£enerēt nozÄ«mÄ«gus un atbilstoÅ”us datus mÅ«su automatizētai datu analÄ«zei, atklāŔanai un izpētei.
  • Personas analÄ«zes rezultātu ievieÅ”ana sistēmas automātiskās noregulÄ“Å”anas procesā, lai atjauninātu to ar jaunākajiem datiem. Å is ir ne tikai mÅ«su modeļa atjauninājums, bet arÄ« mÅ«su procesu atjauninājums un labāka izpratne par mÅ«su datiem.
  • LÄ«dzsvara atraÅ”ana starp IF-ELSE un ML deterministisko pieeju. Kāds teica: "ML ir lÄ«dzeklis izmisuÅ”ajiem." Tas nozÄ«mē, ka jÅ«s vēlēsities izmantot ML, kad vairs nesaprotat, kā optimizēt un uzlabot savus algoritmus. No otras puses, deterministiskā pieeja neļauj atklāt anomālijas, kas nebija paredzētas.
  • Mums ir nepiecieÅ”ams vienkārÅ”s veids, kā pārbaudÄ«t savas hipotēzes vai korelācijas starp datu metriku.
  • Sistēmai ir jābÅ«t vairākiem patiesi pozitÄ«vu rezultātu lÄ«meņiem. KrāpÅ”anas gadÄ«jumi ir tikai daļa no visiem gadÄ«jumiem, kurus var uzskatÄ«t par pozitÄ«viem sistēmai. Piemēram, analÄ«tiÄ·i vēlas saņemt visus aizdomÄ«gos gadÄ«jumus izskatÄ«Å”anai, un tikai neliela daļa no tiem ir krāpnieciski. Sistēmai ir efektÄ«vi jānodroÅ”ina analÄ«tiÄ·i ar visiem gadÄ«jumiem neatkarÄ«gi no tā, vai tā ir Ä«sta krāpÅ”ana vai tikai aizdomÄ«ga rÄ«cÄ«ba.
  • Datu platformai jāspēj izgÅ«t vēsturiskās datu kopas ar aprēķiniem, kas izveidoti un aprēķināti lidojuma laikā.
  • VienkārÅ”a un automātiska jebkura sistēmas komponenta izvietoÅ”ana vismaz trÄ«s dažādās vidēs: ražoÅ”anas, eksperimentālā (beta) un izstrādātājiem.
  • Un visbeidzot, bet ne mazāk svarÄ«gi. Mums ir jāizveido plaÅ”a salÄ«dzinoŔās novērtÄ“Å”anas platforma, kurā mēs varam analizēt savus modeļus. [4]

atsauces

  1. Kas ir paplaŔinātais intelekts?
  2. API pirmā dizaina metodoloģijas ievieŔana
  3. Kafka pārvērÅ”as par "notikumu straumÄ“Å”anas datu bāzi"
  4. AUC ā€” ROC lÄ«knes izpratne

Avots: www.habr.com

Pievieno komentāru