Des de fa uns sis mesos, he estat creant un sistema de lluita contra el frau (activitat fraudulenta, frau, etc.) sense cap infraestructura inicial per a això. Les idees actuals que hem trobat i implementat al nostre sistema ens ajuden a detectar i analitzar moltes activitats fraudulentes. En aquest article m'agradaria parlar dels principis que vam seguir i què vam fer per aconseguir l'estat actual del nostre sistema, sense aprofundir en la part tècnica.
Principis del nostre sistema
Quan escolteu termes com "automàtic" i "frau", probablement comenceu a pensar en l'aprenentatge automàtic, Apache Spark, Hadoop, Python, Airflow i altres tecnologies de l'ecosistema de la Fundació Apache i el camp de la ciència de dades. Crec que hi ha un aspecte de l'ús d'aquestes eines que no s'acostuma a mencionar: requereixen que hi hagi determinats requisits previs al vostre sistema empresarial abans de poder-los utilitzar. En resum, necessiteu una plataforma de dades empresarial que inclogui un llac de dades i emmagatzematge. Però, què passa si no teniu aquesta plataforma i encara necessiteu desenvolupar aquesta pràctica? Els principis següents, que descric a continuació, ens han ajudat a arribar al punt en què podem centrar-nos a millorar les nostres idees, en lloc de trobar-ne una que funcioni. No obstant això, això no és una "meseta" del projecte. Hi ha moltes més coses al pla des del punt de vista tecnològic i de producte.
Principi 1: el valor empresarial primer
Posem el "valor empresarial" al capdavant de tots els nostres esforços. En general, qualsevol sistema d'anàlisi automàtica pertany al grup de sistemes complexos amb un alt nivell d'automatització i complexitat tècnica. Crear una solució completa trigarà molt de temps si la creeu des de zero. Vam decidir posar primer el valor empresarial i en segon lloc la maduresa tecnològica. A la vida real, això vol dir que no acceptem la tecnologia avançada com a dogma. Triem la tecnologia que millor ens funciona en aquest moment. Amb el temps, pot semblar que haurem de tornar a implantar alguns mòduls. Aquest és el compromís que vam acceptar.
Principi 2: Intel·ligència augmentada
Aposto que la majoria de la gent que no està profundament involucrada en el desenvolupament de solucions d'aprenentatge automàtic podria pensar que la substitució humana és l'objectiu. De fet, les solucions d'aprenentatge automàtic estan lluny de ser perfectes i només en determinades àrees és possible la substitució. Vam abandonar aquesta idea des del principi per diversos motius: dades desequilibrades sobre l'activitat fraudulenta i la incapacitat de proporcionar una llista exhaustiva de funcions per als models d'aprenentatge automàtic. En canvi, vam optar per l'opció d'intel·ligència augmentada. Aquest és un concepte alternatiu d'intel·ligència artificial que se centra en el paper de suport de la IA, posant èmfasi en el fet que les tecnologies cognitives estan dissenyades per millorar la intel·ligència humana, no per substituir-la. [1]
Tenint això en compte, desenvolupar una solució completa d'aprenentatge automàtic des del principi requeriria un gran esforç que retardaria la creació de valor per al nostre negoci. Vam decidir construir un sistema amb un aspecte iteratiu de creixement de l'aprenentatge automàtic sota la guia dels nostres experts del domini. La part complicada del desenvolupament d'aquest sistema és que ha de proporcionar als nostres analistes estudis de casos no només en termes de si es tracta d'una activitat fraudulenta o no. En general, qualsevol anomalia en el comportament dels clients és un cas sospitós que els especialistes han d'investigar i respondre d'alguna manera. Només alguns d'aquests casos registrats es poden classificar realment com a frau.
Principi 3: plataforma Rich Insights
La part més difícil del nostre sistema és la verificació d'extrem a extrem del flux de treball del sistema. Els analistes i desenvolupadors haurien d'obtenir fàcilment conjunts de dades històriques amb totes les mètriques que s'han utilitzat per a l'anàlisi. A més, la plataforma de dades hauria de proporcionar una manera senzilla de complementar un conjunt d'indicadors existents amb un de nou. Els processos que creem, i no només són processos de programari, haurien de facilitar el recàlcul de períodes anteriors, afegir noves mètriques i canviar la previsió de dades. Ho podríem aconseguir acumulant totes les dades que genera el nostre sistema de producció. En aquest cas, les dades es convertirien gradualment en un obstacle. Hauríem d'emmagatzemar la quantitat creixent de dades que no fem servir i protegir-les. En aquest escenari, les dades seran cada cop més irrellevants amb el temps, però encara requereixen els nostres esforços per gestionar-les. Per a nosaltres, l'acumulació de dades no tenia sentit i vam decidir utilitzar un enfocament diferent. Vam decidir organitzar magatzems de dades en temps real al voltant de les entitats objectiu que volem classificar, i emmagatzemar només les dades que ens permetin comprovar els períodes més recents i actualitzats. El repte d'aquest esforç és que el nostre sistema és heterogeni amb múltiples magatzems de dades i mòduls de programari que requereixen una planificació acurada per funcionar de manera coherent.
Conceptes de disseny del nostre sistema
Tenim quatre components principals al nostre sistema: un sistema d'ingestió, un sistema computacional, una anàlisi de BI i un sistema de seguiment. Tenen propòsits aïllats específics i els mantenim aïllats seguint certs enfocaments de desenvolupament.
Disseny basat en contracte
En primer lloc, vam acordar que els components només haurien de dependre de determinades estructures de dades (contractes) que es passen entre ells. Això facilita la integració entre ells i no imposar una composició (i ordre) específics dels components. Per exemple, en alguns casos això ens permet integrar directament el sistema receptor amb el sistema de seguiment d'alertes. En aquest cas, es farà d'acord amb el contracte de notificació pactat. Això vol dir que tots dos components s'integraran mitjançant un contracte que qualsevol altre component pot utilitzar. No afegirem cap contracte addicional per afegir alertes al sistema de seguiment des del sistema d'entrada. Aquest enfocament requereix l'ús d'un nombre mínim predeterminat de contractes i simplifica el sistema i les comunicacions. Bàsicament, estem adoptant un enfocament anomenat "Contract First Design" i l'apliquem als contractes de streaming. [2]
Transmissió per tot arreu
Desar i gestionar l'estat al sistema comportarà inevitablement complicacions en la seva implementació. En general, l'estat ha de ser accessible des de qualsevol component, ha de ser coherent i proporcionar el valor més actualitzat en tots els components, i ha de ser fiable amb els valors correctes. A més, tenir trucades a l'emmagatzematge persistent per obtenir l'últim estat augmentarà la quantitat d'E/S i la complexitat dels algorismes utilitzats en els nostres pipelines en temps real. Per això, vam decidir eliminar l'emmagatzematge d'estat, si és possible, completament del nostre sistema. Aquest enfocament requereix que totes les dades necessàries s'incloguin a la unitat de dades transmesa (missatge). Per exemple, si necessitem calcular el nombre total d'algunes observacions (el nombre d'operacions o casos amb determinades característiques), el calculem en memòria i generem un flux d'aquests valors. Els mòduls dependents utilitzaran particions i lots per dividir el flux per entitats i operar amb els valors més recents. Aquest enfocament va eliminar la necessitat de disposar d'emmagatzematge en disc persistent per a aquestes dades. El nostre sistema utilitza Kafka com a agent de missatges i es pot utilitzar com a base de dades amb KSQL. [3] Però utilitzar-lo vincularia fortament la nostra solució amb Kafka, i vam decidir no utilitzar-la. L'enfocament que hem escollit ens permet substituir Kafka per un altre agent de missatges sense grans canvis interns al sistema.
Aquest concepte no vol dir que no utilitzem emmagatzematge en disc i bases de dades. Per comprovar i analitzar el rendiment del sistema, hem d'emmagatzemar una quantitat important de dades al disc, que representa diversos indicadors i estats. El punt important aquí és que els algorismes en temps real no depenen d'aquestes dades. En la majoria dels casos, fem servir les dades desades per a l'anàlisi fora de línia, la depuració i el seguiment de casos i resultats específics que produeix el sistema.
Problemes del nostre sistema
Hi ha certs problemes que hem resolt fins a un cert nivell, però requereixen solucions més reflexives. De moment, només m'agradaria esmentar-los aquí, perquè cada article val el seu propi article.
- Encara hem de definir processos i polítiques que ajudin a generar dades significatives i rellevants per a la nostra anàlisi, descoberta i exploració automatitzada de dades.
- La introducció dels resultats de l'anàlisi per part d'una persona en procés d'ajustament automàtic del sistema per actualitzar-lo amb les dades més recents. Això no és només una actualització del nostre model, sinó també una actualització dels nostres processos i una millor comprensió de les nostres dades.
- Trobar un equilibri entre l'enfocament determinista de IF-ELSE i ML. Algú va dir: "ML és una eina per als desesperats". Això vol dir que voldreu utilitzar ML quan ja no entengueu com optimitzar i millorar els vostres algorismes. D'altra banda, l'enfocament determinista no permet la detecció d'anomalies no previstes.
- Necessitem una manera senzilla de provar les nostres hipòtesis o correlacions entre mètriques de les dades.
- El sistema ha de tenir múltiples nivells de veritables resultats positius. Els casos de frau són només una fracció de tots els casos que es poden considerar positius per al sistema. Per exemple, els analistes volen rebre tots els casos sospitosos per revisar-los, i només una petita part d'ells són fraudulents. El sistema ha de proporcionar als analistes de manera eficaç tots els casos, ja siguin un frau real o només un comportament sospitós.
- La plataforma de dades hauria de ser capaç de recuperar conjunts de dades històriques amb càlculs creats i calculats sobre la marxa.
- Desplegament senzill i automàtic de qualsevol dels components del sistema en almenys tres entorns diferents: producció, experimental (beta) i per a desenvolupadors.
- I per últim, però no menys important. Hem de crear una àmplia plataforma de benchmarking sobre la qual puguem analitzar els nostres models. [4]
Referències
Font: www.habr.com