Viimeisen noin kuuden kuukauden ajan olen luonut järjestelmää petosten (petollinen toiminta, petos jne.) torjuntaan ilman mitään alustavaa infrastruktuuria tätä varten. Tämän päivän ideat, jotka olemme löytäneet ja toteuttaneet järjestelmästämme, auttavat meitä havaitsemaan ja analysoimaan monia petollisia toimia. Tässä artikkelissa haluan puhua periaatteista, joita noudatimme ja mitä teimme saavuttaaksemme järjestelmämme nykyisen tilan, menemättä syvälle tekniseen osaan.
Järjestelmämme periaatteet
Kun kuulet termejä, kuten "automaattinen" ja "petos", alat todennäköisesti ajatella koneoppimista, Apache Sparkia, Hadoopia, Pythonia, Airflowta ja muita Apache Foundation -ekosysteemin ja Data Science -alan teknologioita. Luulen, että näiden työkalujen käytössä on yksi näkökohta, jota ei yleensä mainita: ne edellyttävät tiettyjä vaatimuksia yritysjärjestelmässäsi, ennen kuin voit aloittaa niiden käytön. Lyhyesti sanottuna tarvitset yritystietoalustan, joka sisältää datajärven ja varaston. Mutta entä jos sinulla ei ole tällaista alustaa ja sinun on silti kehitettävä tätä käytäntöä? Seuraavat alla jakamani periaatteet ovat auttaneet meitä saavuttamaan pisteen, jossa voimme keskittyä ideoiden parantamiseen toimivan löytämisen sijaan. Tämä ei kuitenkaan ole projektitasanne. Suunnitelmassa on vielä paljon asioita teknologian ja tuotteen näkökulmasta.
Periaate 1: Liikearvo ensin
Asetamme "liiketoiminnan arvon" kaikkien ponnistelujemme etusijalle. Yleensä kaikki automaattiset analyysijärjestelmät kuuluvat monimutkaisten järjestelmien ryhmään, joilla on korkea automaatiotaso ja tekninen monimutkaisuus. Täydellisen ratkaisun luominen vie paljon aikaa, jos luot sen tyhjästä. Päätimme asettaa liiketoiminnan arvon etusijalle ja teknologisen täydellisyyden toiseksi. Tosielämässä tämä tarkoittaa, että emme hyväksy kehittynyttä teknologiaa dogmaksi. Valitsemme tekniikan, joka toimii meille tällä hetkellä parhaiten. Ajan myötä saattaa näyttää siltä, että meidän on otettava jotkin moduulit käyttöön uudelleen. Tämä on kompromissi, jonka hyväksyimme.
Periaate 2: Lisätty älykkyys
Lyön vetoa, että useimmat ihmiset, jotka eivät ole syvästi mukana koneoppimisratkaisujen kehittämisessä, saattavat ajatella, että tavoitteena on ihmisten korvaaminen. Itse asiassa koneoppimisratkaisut ovat kaukana täydellisistä ja vain tietyillä alueilla on mahdollista korvata. Hylkäsimme tämän idean alusta alkaen useista syistä: petollisen toiminnan epätasapainoiset tiedot ja kyvyttömyys tarjota kattavaa luetteloa koneoppimismalleihin liittyvistä ominaisuuksista. Sitä vastoin valitsimme tehostetun älykkyyden vaihtoehdon. Tämä on vaihtoehtoinen tekoälykonsepti, joka keskittyy tekoälyn tukirooliin ja korostaa sitä tosiasiaa, että kognitiivisten teknologioiden tarkoituksena on parantaa ihmisen älykkyyttä eikä korvata sitä. [1]
Tämän vuoksi täydellisen koneoppimisratkaisun kehittäminen alusta alkaen vaatisi valtavasti vaivaa, mikä viivästyisi arvon luomista liiketoiminnallemme. Päätimme rakentaa järjestelmän, jossa on iteratiivisesti kasvava koneoppimisnäkökohta verkkotunnusasiantuntijoidemme ohjauksessa. Haastava osa tällaisen järjestelmän kehittämisessä on se, että sen on annettava analyytikoillemme tapauksia paitsi siitä, onko kyseessä petollinen toiminta vai ei. Yleisesti ottaen mikä tahansa poikkeavuus asiakkaan käyttäytymisessä on epäilyttävä tapaus, joka asiantuntijoiden on tutkittava ja reagoitava jotenkin. Vain murto-osa näistä raportoiduista tapauksista voidaan todella luokitella petoksiksi.
Periaate 3: Rich Analytics -alusta
Järjestelmämme haastavin osa on järjestelmän työnkulun päästä päähän -varmennus. Analyytikoiden ja kehittäjien tulisi helposti hankkia historialliset tietojoukot, joissa on kaikki analysoinnissa käytetyt mittarit. Lisäksi tietoalustan tulisi tarjota helppo tapa täydentää olemassa olevaa mittaristoa uusilla. Luomiemme prosessien, jotka eivät ole vain ohjelmistoprosesseja, pitäisi antaa meille mahdollisuus helposti laskea uudelleen aiemmat jaksot, lisätä uusia mittareita ja muuttaa dataennustetta. Voisimme saavuttaa tämän keräämällä kaikki tuotantojärjestelmämme tuottamat tiedot. Tässä tapauksessa tiedoista tulee vähitellen haittaa. Meidän on tallennettava kasvava määrä dataa, jota emme käytä, ja suojattava se. Tällaisessa tilanteessa tiedoista tulee ajan myötä yhä epäolennaisempia, mutta niiden hallinta vaatii silti ponnistelujamme. Meille tietojen keräämisessä ei ollut järkeä, joten päätimme valita toisenlaisen lähestymistavan. Päätimme järjestää reaaliaikaisia tietovarastoja niiden kohdekokonaisuuksien ympärille, jotka haluamme luokitella, ja tallentaa vain ne tiedot, joiden avulla voimme tarkistaa viimeisimmät ja relevantit ajanjaksot. Tämän työn haasteena on, että järjestelmämme on heterogeeninen, ja siinä on useita tietovarastoja ja ohjelmistomoduuleja, jotka vaativat huolellista suunnittelua toimiakseen johdonmukaisesti.
Järjestelmämme suunnittelukonseptit
Järjestelmässämme on neljä pääkomponenttia: käsittelyjärjestelmä, laskennallinen, BI-analyysi ja seurantajärjestelmä. Ne palvelevat tiettyjä, eristettyjä tarkoituksia, ja pidämme ne erillään noudattamalla erityisiä suunnittelumenetelmiä.
Sopimuspohjainen suunnittelu
Ensinnäkin sovimme, että komponenttien tulisi perustua vain tiettyihin tietorakenteisiin (sopimuksiin), jotka välitetään niiden välillä. Tämä tekee niiden yhdistämisestä helppoa eikä vaadi tiettyä komponenttien koostumusta (ja järjestystä). Esimerkiksi joissakin tapauksissa tämä antaa meille mahdollisuuden integroida imujärjestelmä suoraan hälytyksen seurantajärjestelmään. Tässä tapauksessa tämä tehdään sovitun hälytyssopimuksen mukaisesti. Tämä tarkoittaa, että molemmat komponentit integroidaan sopimuksella, jota mikä tahansa muu komponentti voi käyttää. Emme lisää lisäsopimusta hälytysten lisäämiseksi seurantajärjestelmään syöttöjärjestelmästä. Tämä lähestymistapa vaatii ennalta määrätyn vähimmäismäärän sopimuksia ja yksinkertaistaa järjestelmää ja viestintää. Käytämme pohjimmiltaan "Contract First Design" -nimistä lähestymistapaa ja sovellamme sitä suoratoistosopimuksiin. [2]
Suoratoisto kaikkialla
Tilan tallentaminen ja hallinta järjestelmässä johtaa väistämättä hankaluuksiin sen toteuttamisessa. Yleensä tilan tulee olla saatavilla mistä tahansa komponentista, sen tulee olla johdonmukainen ja tarjota uusin arvo kaikissa komponenteissa, ja sen tulee olla luotettava oikeilla arvoilla. Lisäksi kutsuminen pysyvään tallennustilaan viimeisimmän tilan hakemiseksi lisää I/O-toimintojen määrää ja reaaliaikaisissa putkissa käytettävien algoritmien monimutkaisuutta. Tämän vuoksi päätimme poistaa tilatallennustilan, mikäli mahdollista, kokonaan järjestelmästämme. Tämä lähestymistapa edellyttää, että kaikki tarvittava data sisällytetään lähetettyyn datalohkoon (viestiin). Jos meidän on esimerkiksi laskettava joidenkin havaintojen kokonaismäärä (operaatioiden tai tapausten määrä, joilla on tietyt ominaisuudet), laskemme sen muistissa ja luomme tällaisten arvojen virran. Riippuvat moduulit jakavat virran kokonaisuuksiksi osion ja erän avulla ja käyttävät uusimpia arvoja. Tämä lähestymistapa eliminoi jatkuvan levymuistin tarpeen tällaisille tiedoille. Järjestelmämme käyttää Kafkaa viestivälittäjänä ja sitä voidaan käyttää tietokantana KSQL:n kanssa. [3] Mutta sen käyttäminen olisi sitonut ratkaisumme voimakkaasti Kafkaan, joten päätimme olla käyttämättä sitä. Valitsemamme lähestymistapa mahdollistaa Kafkan korvaamisen toisella viestivälittäjällä ilman suuria sisäisiä muutoksia järjestelmään.
Tämä käsite ei tarkoita, että emme käytä levymuistia ja tietokantoja. Järjestelmän suorituskyvyn testaamiseksi ja analysoimiseksi meidän on tallennettava levylle huomattava määrä tietoa, joka edustaa erilaisia mittareita ja tiloja. Tärkeä asia tässä on, että reaaliaikaiset algoritmit eivät ole riippuvaisia sellaisista tiedoista. Useimmissa tapauksissa käytämme tallennettuja tietoja offline-analyysiin, virheenkorjaukseen ja järjestelmän tuottamien tiettyjen tapausten ja tulosten seurantaan.
Järjestelmämme ongelmat
On tiettyjä ongelmia, jotka olemme ratkaisseet tietylle tasolle, mutta ne vaativat harkittumpia ratkaisuja. Nyt haluaisin vain mainita ne tässä, koska jokainen kohta on oman artikkelinsa arvoinen.
- Meidän on vielä määriteltävä prosesseja ja käytäntöjä, jotka tukevat mielekkään ja asiaankuuluvan datan keräämistä automaattista tietojen analysointia, etsimistä ja kartoittamista varten.
- Ihmisen analyysitulosten sisällyttäminen prosessiin, jossa järjestelmä määritetään automaattisesti päivittämään se uusimmilla tiedoilla. Tämä ei ole vain mallimme päivittämistä, vaan myös prosessiemme päivittämistä ja tietojemme ymmärtämisen parantamista.
- Tasapainon löytäminen IF-ELSE:n ja ML:n deterministisen lähestymistavan välillä. Joku sanoi: "ML on työkalu epätoivoisille." Tämä tarkoittaa, että haluat käyttää ML:ää, kun et enää ymmärrä algoritmien optimointia ja parantamista. Toisaalta deterministinen lähestymistapa ei salli sellaisten poikkeamien havaitsemista, joita ei ole ennakoitu.
- Tarvitsemme yksinkertaisen tavan testata hypoteesejamme tai korrelaatioita datassa olevien mittareiden välillä.
- Järjestelmällä on oltava useita tasoja todellisia positiivisia tuloksia. Petostapaukset ovat vain murto-osa kaikista tapauksista, joita voidaan pitää järjestelmän kannalta myönteisinä. Esimerkiksi analyytikot haluavat saada kaikki epäilyttävät tapaukset tarkistettavaksi, ja vain pieni osa niistä on petoksia. Järjestelmän on esitettävä tehokkaasti kaikki tapaukset analyytikoille riippumatta siitä, onko kyseessä todellinen petos vai vain epäilyttävä toiminta.
- Tietoalustan pitäisi pystyä hakemaan historiallisia tietojoukkoja, joissa on lennossa luotuja ja laskettuja laskelmia.
- Ota kaikki järjestelmän komponentit käyttöön helposti ja automaattisesti vähintään kolmessa eri ympäristössä: tuotanto-, kokeellinen (beta) ja kehittäjille.
- Ja viimeisenä mutta ei vähäisimpänä. Meidän on rakennettava rikas suorituskyvyn testausalusta, jonka avulla voimme analysoida mallejamme. [4]
viittaukset
Lähde: will.com