De afgelopen zes maanden heb ik een systeem opgezet om fraude (frauduleuze activiteiten, fraude, enz.) te bestrijden, zonder enige initiële infrastructuur hiervoor. De ideeën van vandaag die we hebben gevonden en in ons systeem hebben geïmplementeerd, helpen ons veel frauduleuze activiteiten op te sporen en te analyseren. In dit artikel wil ik het hebben over de principes die we hebben gevolgd en wat we hebben gedaan om de huidige staat van ons systeem te bereiken, zonder in te gaan op het technische gedeelte.
Principes van ons systeem
Wanneer je termen als ‘automatisch’ en ‘fraude’ hoort, begin je waarschijnlijk te denken aan machine learning, Apache Spark, Hadoop, Python, Airflow en andere technologieën uit het Apache Foundation-ecosysteem en het Data Science-veld. Ik denk dat er één aspect is bij het gebruik van deze tools dat meestal niet wordt genoemd: ze vereisen bepaalde vereisten in je bedrijfssysteem voordat je ze kunt gaan gebruiken. Kortom, u heeft een bedrijfsdataplatform nodig dat een datameer en magazijn omvat. Maar wat als u niet over zo’n platform beschikt en deze praktijk nog moet ontwikkelen? De volgende principes die ik hieronder deel, hebben ons geholpen een punt te bereiken waarop we ons kunnen concentreren op het verbeteren van onze ideeën in plaats van er een te vinden die werkt. Dit is echter geen projectplateau. Vanuit technologisch en productoogpunt staan er nog veel zaken in het plan.
Principe 1: Bedrijfswaarde voorop
Bij al onze inspanningen staat ‘bedrijfswaarde’ voorop. Over het algemeen behoort elk automatisch analysesysteem tot de groep van complexe systemen met een hoge mate van automatisering en technische complexiteit. Het creëren van een complete oplossing kost veel tijd als je deze helemaal opnieuw maakt. We besloten om de bedrijfswaarde op de eerste plaats te zetten en de technologische volledigheid op de tweede plaats. In het echte leven betekent dit dat we geavanceerde technologie niet als dogma accepteren. Wij kiezen voor de technologie die op dat moment het beste bij ons past. Na verloop van tijd kan het erop lijken dat we sommige modules opnieuw zullen moeten implementeren. Dit is het compromis dat we hebben aanvaard.
Principe 2: Verbeterde intelligentie
Ik durf te wedden dat de meeste mensen die niet diep betrokken zijn bij het ontwikkelen van oplossingen voor machine learning misschien denken dat het vervangen van mensen het doel is. In feite zijn machine learning-oplossingen verre van perfect en slechts op bepaalde gebieden is vervanging mogelijk. We hebben dit idee vanaf het begin afgewezen om verschillende redenen: onevenwichtige gegevens over frauduleuze activiteiten en het onvermogen om een uitgebreide lijst met functies voor machine learning-modellen te bieden. Wij kozen daarentegen voor de optie voor verbeterde intelligentie. Dit is een alternatief concept van kunstmatige intelligentie dat zich richt op de ondersteunende rol van AI, waarbij de nadruk wordt gelegd op het feit dat cognitieve technologieën bedoeld zijn om de menselijke intelligentie te verbeteren in plaats van deze te vervangen. [1]
Daarom zou het vanaf het begin ontwikkelen van een complete machine learning-oplossing een enorme inspanning vergen, wat de creatie van waarde voor ons bedrijf zou vertragen. We besloten een systeem te bouwen met een iteratief groeiend machine learning-aspect onder begeleiding van onze domeinexperts. Het uitdagende deel van het ontwikkelen van een dergelijk systeem is dat het onze analisten niet alleen van cases moet voorzien met betrekking tot de vraag of het om frauduleuze activiteiten gaat of niet. Over het algemeen is elke afwijking in het gedrag van klanten een verdacht geval dat specialisten moeten onderzoeken en op de een of andere manier moeten reageren. Slechts een fractie van deze gemelde gevallen kan werkelijk als fraude worden aangemerkt.
Principe 3: Rich Analytics-platform
Het meest uitdagende onderdeel van ons systeem is de end-to-end verificatie van de workflow van het systeem. Analisten en ontwikkelaars moeten gemakkelijk historische datasets kunnen verkrijgen met alle statistieken die voor analyse worden gebruikt. Bovendien moet het dataplatform een eenvoudige manier bieden om een bestaande reeks statistieken aan te vullen met nieuwe. De processen die we creëren, en dit zijn niet alleen softwareprocessen, moeten ons in staat stellen om voorgaande perioden eenvoudig opnieuw te berekenen, nieuwe statistieken toe te voegen en de gegevensvoorspelling te wijzigen. We zouden dit kunnen bereiken door alle gegevens te verzamelen die ons productiesysteem genereert. In dit geval zouden de gegevens geleidelijk hinderlijk worden. We zouden een groeiende hoeveelheid gegevens die we niet gebruiken, moeten opslaan en beschermen. In een dergelijk scenario zullen gegevens in de loop van de tijd steeds irrelevanter worden, maar vereisen nog steeds onze inspanningen om deze te beheren. Voor ons had het verzamelen van gegevens geen zin, dus besloten we een andere aanpak te kiezen. We hebben besloten om realtime gegevensopslag te organiseren rond de doelentiteiten die we willen classificeren, en alleen de gegevens op te slaan waarmee we de meest recente en relevante perioden kunnen controleren. De uitdaging bij deze inspanning is dat ons systeem heterogeen is, met meerdere datastores en softwaremodules die een zorgvuldige planning vereisen om op een consistente manier te kunnen werken.
Ontwerpconcepten van ons systeem
We hebben vier hoofdcomponenten in ons systeem: opnamesysteem, computationeel, BI-analyse en trackingsysteem. Ze dienen specifieke, geïsoleerde doeleinden, en we houden ze geïsoleerd door specifieke ontwerpbenaderingen te volgen.
Contractgebaseerd ontwerp
Allereerst waren we het erover eens dat componenten alleen moeten vertrouwen op bepaalde datastructuren (contracten) die tussen hen worden uitgewisseld. Dit maakt het gemakkelijk om ze onderling te integreren en geen specifieke samenstelling (en volgorde) van componenten op te leggen. Hierdoor kunnen we in sommige gevallen bijvoorbeeld het intakesysteem direct integreren met het alertvolgsysteem. In een dergelijk geval zal dit gebeuren conform het overeengekomen alertcontract. Dit betekent dat beide componenten worden geïntegreerd via een contract waar elk ander component gebruik van kan maken. We zullen geen extra contract toevoegen om waarschuwingen toe te voegen aan het volgsysteem vanuit het invoersysteem. Deze aanpak vereist het gebruik van een vooraf bepaald minimumaantal contracten en vereenvoudigt het systeem en de communicatie. In essentie hanteren we een aanpak die ‘Contract First Design’ wordt genoemd en passen deze toe op streamingcontracten. [2]
Overal streamen
Het opslaan en beheren van de toestand in een systeem zal onvermijdelijk leiden tot complicaties bij de implementatie ervan. Over het algemeen moet de status toegankelijk zijn vanuit elk onderdeel, consistent zijn en de meest actuele waarde bieden voor alle componenten, en betrouwbaar zijn met de juiste waarden. Bovendien zal het aanroepen van persistente opslag om de nieuwste status op te halen het aantal I/O-bewerkingen en de complexiteit van de algoritmen die in onze realtime pipelines worden gebruikt, vergroten. Daarom hebben we besloten om de staatsopslag, indien mogelijk, volledig uit ons systeem te verwijderen. Deze aanpak vereist dat alle noodzakelijke gegevens in het verzonden gegevensblok (bericht) worden opgenomen. Als we bijvoorbeeld het totale aantal van bepaalde waarnemingen (het aantal bewerkingen of gevallen met bepaalde kenmerken) moeten berekenen, berekenen we dit in het geheugen en genereren we een stroom van dergelijke waarden. Afhankelijke modules gebruiken partitie en batching om de stream in entiteiten te splitsen en op de nieuwste waarden te werken. Deze aanpak elimineerde de noodzaak van permanente schijfopslag voor dergelijke gegevens. Ons systeem gebruikt Kafka als berichtenmakelaar en kan worden gebruikt als database met KSQL. [3] Maar het gebruik ervan zou onze oplossing sterk aan Kafka hebben gebonden, en we hebben besloten er geen gebruik van te maken. De aanpak die we hebben gekozen, stelt ons in staat Kafka te vervangen door een andere berichtenmakelaar zonder grote interne wijzigingen aan het systeem.
Dit concept betekent niet dat we geen gebruik maken van schijfopslag en databases. Om de systeemprestaties te testen en te analyseren, moeten we een aanzienlijke hoeveelheid gegevens op schijf opslaan die verschillende statistieken en statussen vertegenwoordigen. Het belangrijke punt hier is dat real-time algoritmen niet afhankelijk zijn van dergelijke gegevens. In de meeste gevallen gebruiken we de opgeslagen gegevens voor offline analyse, debuggen en volgen van specifieke gevallen en resultaten die het systeem oplevert.
Problemen van ons systeem
Er zijn bepaalde problemen die we tot op zekere hoogte hebben opgelost, maar die vereisen meer doordachte oplossingen. Nu wil ik ze hier graag vermelden, omdat elk punt zijn eigen artikel waard is.
- We moeten nog steeds processen en beleid definiëren die de accumulatie van betekenisvolle en relevante gegevens ondersteunen voor onze geautomatiseerde gegevensanalyse, ontdekking en verkenning.
- Integratie van menselijke analyseresultaten in het proces van het automatisch instellen van het systeem om het bij te werken met de nieuwste gegevens. Hiermee actualiseren we niet alleen ons model, maar ook onze processen en verbeteren we ons begrip van onze data.
- Het vinden van een balans tussen de deterministische benadering van IF-ELSE en ML. Iemand zei: “ML is een hulpmiddel voor de wanhopigen.” Dit betekent dat u ML wilt gebruiken als u niet langer begrijpt hoe u uw algoritmen kunt optimaliseren en verbeteren. Aan de andere kant maakt de deterministische benadering het niet mogelijk afwijkingen op te sporen die niet waren voorzien.
- We hebben een eenvoudige manier nodig om onze hypothesen of correlaties tussen statistieken in de gegevens te testen.
- Het systeem moet verschillende niveaus van echt positieve resultaten hebben. Fraudegevallen vormen slechts een fractie van alle gevallen die als positief voor het systeem kunnen worden beschouwd. Analisten willen bijvoorbeeld alle verdachte gevallen ter verificatie ontvangen, en slechts een klein deel daarvan betreft fraude. Het systeem moet alle gevallen efficiënt aan analisten presenteren, ongeacht of het om daadwerkelijke fraude gaat of om verdacht gedrag.
- Het dataplatform moet historische datasets kunnen ophalen met berekeningen die on-the-fly worden gegenereerd en berekend.
- Implementeer eenvoudig en automatisch alle systeemcomponenten in ten minste drie verschillende omgevingen: productie, experimenteel (bèta) en voor ontwikkelaars.
- Tenslotte. We moeten een rijk prestatietestplatform bouwen waarop we onze modellen kunnen analyseren. [4]
referenties
Bron: www.habr.com