Under de senaste cirka sex månaderna har jag skapat ett system för att bekämpa bedrägerier (bedrägeri, bedrägeri, etc.) utan någon initial infrastruktur för detta. Dagens idéer som vi har hittat och implementerat i vårt system hjälper oss att upptäcka och analysera många bedrägliga aktiviteter. I den här artikeln skulle jag vilja prata om de principer vi följde och vad vi gjorde för att uppnå det nuvarande tillståndet för vårt system, utan att gå in på den tekniska delen.
Principer för vårt system
När du hör termer som "automatisk" och "bedrägeri" börjar du med största sannolikhet tänka på maskininlärning, Apache Spark, Hadoop, Python, Airflow och andra teknologier från Apache Foundation-ekosystemet och Data Science-området. Jag tror att det finns en aspekt av att använda dessa verktyg som vanligtvis inte nämns: de kräver vissa förutsättningar i ditt företagssystem innan du kan börja använda dem. Kort sagt, du behöver en företagsdataplattform som inkluderar en datasjö och ett lager. Men vad händer om du inte har en sådan plattform och fortfarande behöver utveckla denna praxis? Följande principer som jag delar nedan har hjälpt oss nå en punkt där vi kan fokusera på att förbättra våra idéer snarare än att hitta en som fungerar. Detta är dock ingen projektplatå. Det finns fortfarande en hel del saker i planen ur teknisk och produktsynpunkt.
Princip 1: Affärsvärde först
Vi sätter "affärsvärde" i främsta rummet i alla våra ansträngningar. I allmänhet tillhör alla automatiska analyssystem gruppen av komplexa system med hög automatiseringsnivå och teknisk komplexitet. Att skapa en komplett lösning kommer att ta mycket tid om du skapar den från grunden. Vi bestämde oss för att sätta affärsvärdet först och teknisk fullständighet i andra hand. I verkligheten betyder det att vi inte accepterar avancerad teknik som dogm. Vi väljer den teknik som fungerar bäst för oss för tillfället. Med tiden kan det tyckas att vi kommer att behöva implementera om några moduler. Detta är den kompromiss vi accepterade.
Princip 2: Förstärkt intelligens
Jag slår vad om att de flesta människor som inte är djupt involverade i att utveckla lösningar för maskininlärning kanske tror att målet är att ersätta människor. Maskininlärningslösningar är faktiskt långt ifrån perfekta och endast inom vissa områden är utbyte möjlig. Vi avvisade denna idé från början av flera skäl: obalanserad data om bedräglig aktivitet och oförmågan att tillhandahålla en heltäckande lista över funktioner för modeller för maskininlärning. Däremot valde vi alternativet förbättrad intelligens. Detta är ett alternativt koncept för artificiell intelligens som fokuserar på AI:s stödjande roll, och betonar det faktum att kognitiva teknologier är avsedda att förbättra mänsklig intelligens snarare än att ersätta den. [1]
Med tanke på detta skulle utvecklingen av en komplett maskininlärningslösning från början kräva en enorm ansträngning, vilket skulle försena skapandet av värde för vår verksamhet. Vi bestämde oss för att bygga ett system med en iterativt växande maskininlärningsaspekt under ledning av våra domänexperter. Den utmanande delen av att utveckla ett sådant system är att det måste förse våra analytiker med fall inte bara när det gäller om det är bedräglig aktivitet eller inte. I allmänhet är varje anomali i kundbeteende ett misstänkt fall som specialister måste undersöka och svara på något sätt. Endast en bråkdel av dessa rapporterade fall kan verkligen klassificeras som bedrägeri.
Princip 3: Rich Analytics-plattform
Den mest utmanande delen av vårt system är end-to-end-verifiering av systemets arbetsflöde. Analytiker och utvecklare bör enkelt skaffa historiska datamängder med alla mätvärden som används för analys. Dessutom bör dataplattformen ge ett enkelt sätt att komplettera en befintlig uppsättning mätvärden med nya. De processer vi skapar, och dessa är inte bara mjukvaruprocesser, bör göra det möjligt för oss att enkelt räkna om tidigare perioder, lägga till nya mätvärden och ändra dataprognosen. Vi skulle kunna uppnå detta genom att samla all data som vårt produktionssystem genererar. I det här fallet skulle uppgifterna gradvis bli till besvär. Vi skulle behöva lagra en växande mängd data som vi inte använder och skydda den. I ett sådant scenario kommer data att bli mer och mer irrelevant med tiden, men kräver fortfarande våra ansträngningar för att hantera den. För oss var datahamstring inte meningsfullt, så vi bestämde oss för att ta ett annat tillvägagångssätt. Vi bestämde oss för att organisera realtidsdatalager kring målenheterna som vi vill klassificera, och lagra endast de data som gör att vi kan kontrollera de senaste och relevanta perioderna. Utmaningen med detta arbete är att vårt system är heterogent, med flera datalager och programvarumoduler som kräver noggrann planering för att fungera på ett konsekvent sätt.
Designkoncept för vårt system
Vi har fyra huvudkomponenter i vårt system: intagssystem, beräkningssystem, BI-analys och spårningssystem. De tjänar specifika, isolerade syften, och vi håller dem isolerade genom att följa specifika designmetoder.
Kontraktsbaserad design
Först och främst kom vi överens om att komponenter endast ska förlita sig på vissa datastrukturer (kontrakt) som skickas mellan dem. Detta gör det enkelt att integrera mellan dem och inte påtvinga en specifik sammansättning (och ordning) av komponenter. Till exempel, i vissa fall tillåter detta oss att direkt integrera intagssystemet med larmspårningssystemet. I sådant fall kommer detta att ske i enlighet med det överenskomna larmavtalet. Detta innebär att båda komponenterna kommer att integreras med ett kontrakt som vilken annan komponent som helst kan använda. Vi kommer inte att lägga till ett ytterligare kontrakt för att lägga till varningar till spårningssystemet från inmatningssystemet. Detta tillvägagångssätt kräver användning av ett förutbestämt minsta antal kontrakt och förenklar systemet och kommunikationen. I huvudsak använder vi ett tillvägagångssätt som kallas "Contract First Design" och tillämpar det på strömmande kontrakt. [2]
Streamar överallt
Att spara och hantera tillstånd i ett system kommer oundvikligen att leda till komplikationer i dess implementering. I allmänhet bör tillstånd vara tillgängligt från vilken komponent som helst, det bör vara konsekvent och ge det mest aktuella värdet för alla komponenter, och det bör vara tillförlitligt med rätt värden. Att ha anrop till beständig lagring för att hämta det senaste tillståndet kommer dessutom att öka antalet I/O-operationer och komplexiteten hos de algoritmer som används i våra realtidspipelines. På grund av detta beslutade vi att ta bort statlig lagring, om möjligt, helt från vårt system. Detta tillvägagångssätt kräver att all nödvändig data ingår i det överförda datablocket (meddelandet). Till exempel, om vi behöver beräkna det totala antalet observationer (antalet operationer eller fall med vissa egenskaper), beräknar vi det i minnet och genererar en ström av sådana värden. Beroende moduler kommer att använda partition och batchning för att dela upp strömmen i enheter och arbeta på de senaste värdena. Detta tillvägagångssätt eliminerade behovet av att ha beständig disklagring för sådana data. Vårt system använder Kafka som meddelandeförmedlare och det kan användas som en databas med KSQL. [3] Men att använda den skulle ha knutit vår lösning kraftigt till Kafka, och vi bestämde oss för att inte använda den. Tillvägagångssättet vi valde gör att vi kan ersätta Kafka med en annan meddelandeförmedlare utan större interna förändringar i systemet.
Detta koncept betyder inte att vi inte använder disklagring och databaser. För att testa och analysera systemets prestanda måste vi lagra en betydande mängd data på disken som representerar olika mätvärden och tillstånd. Det viktiga här är att realtidsalgoritmer inte är beroende av sådana data. I de flesta fall använder vi den lagrade datan för offlineanalys, felsökning och spårning av specifika fall och resultat som systemet producerar.
Problem med vårt system
Det finns vissa problem som vi har löst till en viss nivå, men de kräver mer genomtänkta lösningar. Nu skulle jag bara vilja nämna dem här eftersom varje punkt är värd sin egen artikel.
- Vi behöver fortfarande definiera processer och policyer som stöder ackumulering av meningsfull och relevant data för vår automatiserade dataanalys, upptäckt och utforskning.
- Inkorporering av mänskliga analysresultat i processen att automatiskt ställa in systemet för att uppdatera det med de senaste data. Detta är inte bara att uppdatera vår modell, utan också att uppdatera våra processer och förbättra vår förståelse av vår data.
- Att hitta en balans mellan det deterministiska tillvägagångssättet för IF-ELSE och ML. Någon sa, "ML är ett verktyg för de desperata." Det betyder att du kommer att vilja använda ML när du inte längre förstår hur du kan optimera och förbättra dina algoritmer. Å andra sidan tillåter det deterministiska tillvägagångssättet inte upptäckt av anomalier som inte var förutsedda.
- Vi behöver ett enkelt sätt att testa våra hypoteser eller korrelationer mellan måtten i datan.
- Systemet måste ha flera nivåer av verkligt positiva resultat. Bedrägeriärenden är bara en bråkdel av alla fall som kan anses vara positiva för systemet. Till exempel vill analytiker ta emot alla misstänkta fall för verifiering, och endast en liten del av dem är bedrägerier. Systemet måste effektivt presentera alla fall för analytiker, oavsett om det är faktiska bedrägerier eller bara misstänkt beteende.
- Dataplattformen ska kunna hämta historiska datamängder med beräkningar som genereras och beräknas i farten.
- Distribuera enkelt och automatiskt någon av systemkomponenterna i minst tre olika miljöer: produktion, experimentell (beta) och för utvecklare.
- Och sist men inte minst. Vi måste bygga en rik plattform för prestandatestning på vilken vi kan analysera våra modeller. [4]
referenser
Källa: will.com