Desde hai uns seis meses levo creando un sistema de loita contra a fraude (actividade fraudulenta, fraude, etc.) sen ningunha infraestrutura inicial para iso. As ideas de hoxe que atopamos e implementamos no noso sistema axúdannos a detectar e analizar moitas actividades fraudulentas. Neste artigo gustaríame falar dos principios que seguimos e do que fixemos para acadar o estado actual do noso sistema, sen entrar na parte técnica.
Principios do noso sistema
Cando escoitas termos como "automático" e "fraude", o máis probable é que comeces a pensar na aprendizaxe automática, Apache Spark, Hadoop, Python, Airflow e outras tecnoloxías do ecosistema da Fundación Apache e do campo Data Science. Creo que hai un aspecto do uso destas ferramentas que non se adoita mencionar: requiren certos requisitos previos no seu sistema empresarial antes de comezar a utilizalas. En resumo, necesitas unha plataforma de datos empresarial que inclúa un lago de datos e un almacén. Pero que pasa se non tes tal plataforma e aínda necesitas desenvolver esta práctica? Os seguintes principios que comparto a continuación axudáronnos a chegar a un punto no que podemos centrarnos en mellorar as nosas ideas en lugar de atopar unha que funcione. Non obstante, non se trata dunha meseta de proxecto. Aínda hai moitas cousas no plan dende o punto de vista tecnolóxico e de produto.
Principio 1: Valor comercial en primeiro lugar
Poñemos o "valor comercial" á vangarda de todos os nosos esforzos. En xeral, calquera sistema de análise automática pertence ao grupo de sistemas complexos cun alto nivel de automatización e complexidade técnica. Crear unha solución completa levará moito tempo se a creas desde cero. Decidimos poñer o valor empresarial primeiro e a integridade tecnolóxica en segundo lugar. Na vida real, isto significa que non aceptamos a tecnoloxía avanzada como dogma. Escollemos a tecnoloxía que mellor nos funciona neste momento. Co paso do tempo, pode parecer que teremos que volver a implantar algúns módulos. Este é o compromiso que aceptamos.
Principio 2: Intelixencia aumentada
Aposto que a maioría das persoas que non están profundamente implicadas no desenvolvemento de solucións de aprendizaxe automática poderían pensar que o obxectivo é substituír aos humanos. De feito, as solucións de aprendizaxe automática están lonxe de ser perfectas e só en determinadas áreas é posible a substitución. Rexeitamos esta idea desde o principio por varias razóns: datos desequilibrados sobre a actividade fraudulenta e a imposibilidade de ofrecer unha lista completa de funcións para os modelos de aprendizaxe automática. En cambio, escollemos a opción de intelixencia mellorada. Este é un concepto alternativo de intelixencia artificial que se centra no papel de apoio da IA, facendo fincapé no feito de que as tecnoloxías cognitivas están destinadas a mellorar a intelixencia humana en lugar de substituíla. [1]
Ante isto, desenvolver unha solución completa de aprendizaxe automática desde o principio requiriría un esforzo enorme, o que atrasaría a creación de valor para o noso negocio. Decidimos construír un sistema cun aspecto de aprendizaxe automática en crecemento iterativo baixo a guía dos nosos expertos do dominio. O reto de desenvolver un sistema deste tipo é que ten que proporcionar aos nosos analistas casos non só en termos de se é actividade fraudulenta ou non. En xeral, calquera anomalía no comportamento do cliente é un caso sospeitoso que os especialistas deben investigar e responder dalgún xeito. Só unha fracción destes casos denunciados poden realmente ser clasificados como fraude.
Principio 3: plataforma de analítica rica
A parte máis desafiante do noso sistema é a verificación de extremo a extremo do fluxo de traballo do sistema. Os analistas e desenvolvedores deberían obter facilmente conxuntos de datos históricos con todas as métricas utilizadas para a análise. Ademais, a plataforma de datos debería proporcionar un xeito sinxelo de complementar un conxunto de métricas existente con outras novas. Os procesos que creamos, e non son só procesos de software, deberían permitirnos recalcular facilmente períodos anteriores, engadir novas métricas e cambiar a previsión de datos. Poderíamos conseguilo acumulando todos os datos que xera o noso sistema de produción. Neste caso, os datos converteríanse aos poucos nunha molestia. Necesitaríamos almacenar unha cantidade crecente de datos que non usamos e protexelos. Neste escenario, os datos serán cada vez máis irrelevantes co paso do tempo, pero aínda requiren os nosos esforzos para xestionalos. Para nós, a acumulación de datos non tiña sentido, polo que decidimos adoptar un enfoque diferente. Decidimos organizar almacéns de datos en tempo real arredor das entidades obxectivo que queremos clasificar e almacenar só os datos que nos permitan comprobar os períodos máis recentes e relevantes. O reto deste esforzo é que o noso sistema é heteroxéneo, con múltiples almacéns de datos e módulos de software que requiren unha planificación coidadosa para funcionar de forma coherente.
Conceptos de deseño do noso sistema
Temos catro compoñentes principais no noso sistema: sistema de inxestión, computacional, análise de BI e sistema de seguimento. Serven a propósitos específicos e illados, e mantemos illados seguindo enfoques de deseño específicos.
Deseño baseado en contratos
En primeiro lugar, acordamos que os compoñentes só deben depender de determinadas estruturas de datos (contratos) que se pasan entre eles. Isto facilita a integración entre eles e non impoñer unha composición (e orde) específica de compoñentes. Por exemplo, nalgúns casos isto permítenos integrar directamente o sistema de admisión co sistema de seguimento de alertas. En tal caso, farase conforme ao contrato de alerta pactado. Isto significa que ambos compoñentes integraranse mediante un contrato que pode utilizar calquera outro compoñente. Non engadiremos un contrato adicional para engadir alertas ao sistema de seguimento desde o sistema de entrada. Este enfoque require o uso dun número mínimo de contratos predeterminado e simplifica o sistema e as comunicacións. Esencialmente, adoptamos un enfoque chamado "Contract First Design" e aplicámolo aos contratos de streaming. [2]
Streaming por todas partes
Gardar e xestionar o estado nun sistema levará inevitablemente a complicacións na súa implementación. En xeral, o estado debe ser accesible desde calquera compoñente, debe ser coherente e proporcionar o valor máis actual en todos os compoñentes e debe ser fiable cos valores correctos. Ademais, ter chamadas ao almacenamento persistente para recuperar o estado máis recente aumentará o número de operacións de E/S e a complexidade dos algoritmos utilizados nas nosas canalizacións en tempo real. Debido a isto, decidimos eliminar o almacenamento de estado, se é posible, completamente do noso sistema. Este enfoque require que todos os datos necesarios se inclúan no bloque de datos transmitido (mensaxe). Por exemplo, se necesitamos calcular o número total dalgunhas observacións (o número de operacións ou casos con determinadas características), calculámolo en memoria e xeramos un fluxo de tales valores. Os módulos dependentes usarán a partición e o lote para dividir o fluxo en entidades e operar cos valores máis recentes. Este enfoque eliminou a necesidade de ter almacenamento persistente en disco para tales datos. O noso sistema usa Kafka como intermediario de mensaxes e pódese usar como base de datos con KSQL. [3] Pero usalo vincularía moito a nosa solución a Kafka, e decidimos non usala. O enfoque que eliximos permítenos substituír a Kafka por outro corredor de mensaxes sen grandes cambios internos no sistema.
Este concepto non significa que non utilicemos o almacenamento en disco e as bases de datos. Para probar e analizar o rendemento do sistema, necesitamos almacenar unha cantidade importante de datos no disco que representen varias métricas e estados. O punto importante aquí é que os algoritmos en tempo real non dependen de tales datos. Na maioría dos casos, utilizamos os datos almacenados para a análise sen conexión, a depuración e o seguimento de casos específicos e resultados que produce o sistema.
Problemas do noso sistema
Hai certos problemas que solucionamos ata certo nivel, pero requiren solucións máis reflexivas. Agora só gustaríame mencionalos aquí porque cada punto vale o seu propio artigo.
- Aínda necesitamos definir procesos e políticas que admitan a acumulación de datos significativos e relevantes para a nosa análise, descubrimento e exploración de datos automatizados.
- Incorporación dos resultados da análise humana no proceso de configuración automática do sistema para actualizalo cos datos máis recentes. Isto non só é actualizar o noso modelo, senón tamén actualizar os nosos procesos e mellorar a nosa comprensión dos nosos datos.
- Buscar un equilibrio entre o enfoque determinista de IF-ELSE e ML. Alguén dixo: "ML é unha ferramenta para os desesperados". Isto significa que quererá usar ML cando xa non entenda como optimizar e mellorar os seus algoritmos. Por outra banda, o enfoque determinista non permite detectar anomalías non previstas.
- Necesitamos un xeito sinxelo de probar as nosas hipóteses ou correlacións entre as métricas dos datos.
- O sistema debe ter varios niveis de verdadeiros resultados positivos. Os casos de fraude son só unha fracción de todos os casos que se poden considerar positivos para o sistema. Por exemplo, os analistas queren recibir todos os casos sospeitosos para a súa verificación, e só unha pequena parte deles son fraudes. O sistema debe presentar de forma eficiente todos os casos aos analistas, independentemente de se se trata de fraude real ou só de comportamento sospeitoso.
- A plataforma de datos debería poder recuperar conxuntos de datos históricos con cálculos xerados e calculados sobre a marcha.
- Implementa de xeito sinxelo e automático calquera dos compoñentes do sistema en polo menos tres ambientes diferentes: produción, experimental (beta) e para desenvolvedores.
- E por último, pero non menos importante. Necesitamos construír unha plataforma rica de probas de rendemento na que poidamos analizar os nosos modelos. [4]
referencias
Fonte: www.habr.com