Durante los últimos seis meses, he estado creando un sistema para combatir el fraude (actividad fraudulenta, fraude, etc.) sin ninguna infraestructura inicial para esto. Las ideas de hoy que encontramos e implementamos en nuestro sistema nos ayudan a detectar y analizar muchas actividades fraudulentas. En este artículo, me gustaría hablar sobre los principios que seguimos y lo que hicimos para lograr el estado actual de nuestro sistema, sin profundizar en la parte técnica.
Principios de nuestro sistema
Cuando escucha términos como "automático" y "fraude", lo más probable es que empiece a pensar en el aprendizaje automático, Apache Spark, Hadoop, Python, Airflow y otras tecnologías en el ecosistema de la Fundación Apache y el campo de la ciencia de datos. Creo que hay un aspecto del uso de estas herramientas que generalmente no se menciona: requieren ciertos requisitos previos en su sistema empresarial antes de que pueda usarlas. En resumen, necesita una plataforma de datos empresariales que incluya un lago de datos y almacenamiento. Pero, ¿qué sucede si no tiene esa plataforma y aún necesita desarrollar esta práctica? Los siguientes principios, que describo a continuación, nos han ayudado a llegar al punto en el que podemos centrarnos en mejorar nuestras ideas, en lugar de encontrar una que funcione. Sin embargo, esto no es una "meseta" del proyecto. Hay muchas más cosas en el plan desde el punto de vista tecnológico y de producto.
Principio 1: Valor comercial primero
Ponemos el “valor comercial” al frente de todos nuestros esfuerzos. En general, cualquier sistema de análisis automático pertenece al grupo de sistemas complejos con un alto nivel de automatización y complejidad técnica. Crear una solución completa llevará mucho tiempo si la crea desde cero. Decidimos poner el valor comercial en primer lugar y la madurez tecnológica en segundo lugar. En la vida real, esto significa que no aceptamos la tecnología avanzada como dogma. Elegimos la tecnología que mejor nos funciona en ese momento. Con el tiempo, puede parecer que tendremos que volver a implementar algunos módulos. Este es el compromiso que aceptamos.
Principio 2: inteligencia aumentada
Apuesto a que la mayoría de las personas que no están profundamente involucradas en el desarrollo de soluciones de aprendizaje automático podrían pensar que el reemplazo humano es el objetivo. De hecho, las soluciones de aprendizaje automático están lejos de ser perfectas y solo en ciertas áreas es posible reemplazarlas. Abandonamos esta idea desde el principio por varias razones: datos desequilibrados sobre actividades fraudulentas y la incapacidad de proporcionar una lista exhaustiva de funciones para los modelos de aprendizaje automático. En cambio, optamos por la opción de inteligencia aumentada. Este es un concepto alternativo de inteligencia artificial que se enfoca en el papel de apoyo de la IA, enfatizando el hecho de que las tecnologías cognitivas están diseñadas para mejorar la inteligencia humana, no para reemplazarla. [1]
Con esto en mente, desarrollar una solución completa de aprendizaje automático desde el principio requeriría una gran cantidad de esfuerzo que retrasaría la creación de valor para nuestro negocio. Decidimos construir un sistema con un aspecto de aprendizaje automático en crecimiento iterativo bajo la guía de nuestros expertos en el dominio. La parte complicada de desarrollar un sistema de este tipo es que debe proporcionar a nuestros analistas estudios de casos no solo en términos de si se trata de una actividad fraudulenta o no. Por lo general, cualquier anomalía en el comportamiento de los clientes es un caso sospechoso que los especialistas necesitan investigar y de alguna manera responder. Solo unos pocos de estos casos registrados pueden clasificarse realmente como fraude.
Principio 3: Plataforma Rich Insights
La parte más difícil de nuestro sistema es la verificación de extremo a extremo del flujo de trabajo del sistema. Los analistas y desarrolladores deberían obtener fácilmente conjuntos de datos históricos con todas las métricas que se utilizaron para el análisis. Además, la plataforma de datos debería proporcionar una manera fácil de complementar un conjunto de indicadores existente con uno nuevo. Los procesos que creamos, y estos no son solo procesos de software, deberían facilitar el recalcular períodos anteriores, agregar nuevas métricas y cambiar el pronóstico de datos. Podríamos lograr esto acumulando todos los datos que genera nuestro sistema de producción. En tal caso, los datos se convertirían gradualmente en un obstáculo. Tendríamos que almacenar la creciente cantidad de datos que no usamos y protegerlos. En tal escenario, los datos se volverán cada vez más irrelevantes con el tiempo, pero aún requieren nuestros esfuerzos para administrarlos. Para nosotros, el acaparamiento de datos no tenía sentido y decidimos utilizar un enfoque diferente. Decidimos organizar almacenes de datos en tiempo real en torno a las entidades objetivo que queremos clasificar y almacenar solo los datos que nos permiten verificar los períodos más recientes y actualizados. El desafío con este esfuerzo es que nuestro sistema es heterogéneo con múltiples almacenes de datos y módulos de software que requieren una planificación cuidadosa para funcionar de manera consistente.
Conceptos de diseño de nuestro sistema
Tenemos cuatro componentes principales en nuestro sistema: un sistema de ingestión, un sistema computacional, un análisis de BI y un sistema de seguimiento. Sirven para propósitos aislados específicos, y los mantenemos aislados siguiendo ciertos enfoques de desarrollo.
Diseño basado en contrato
En primer lugar, acordamos que los componentes solo deben basarse en ciertas estructuras de datos (contratos) que se transmiten entre ellos. Esto facilita la integración entre ellos y no impone una composición (y orden) específica de componentes. Por ejemplo, en algunos casos esto nos permite integrar directamente el sistema de recepción con el sistema de seguimiento de alertas. En tal caso, esto se hará de conformidad con el contrato de notificación acordado. Esto significa que ambos componentes se integrarán mediante un contrato que cualquier otro componente puede utilizar. No agregaremos un contrato adicional para agregar alertas al sistema de seguimiento desde el sistema de entrada. Este enfoque requiere el uso de un número mínimo predeterminado de contratos y simplifica el sistema y las comunicaciones. Básicamente, estamos adoptando un enfoque llamado "Primer diseño del contrato" y aplicándolo a los contratos de transmisión. [2]
Streaming en todas partes
Guardar y administrar el estado en el sistema conducirá inevitablemente a complicaciones en su implementación. En general, el estado debe ser accesible desde cualquier componente, debe ser consistente y proporcionar el valor más actualizado en todos los componentes, y debe ser confiable con los valores correctos. Además, tener llamadas al almacenamiento persistente para obtener el estado más reciente aumentará la cantidad de E/S y la complejidad de los algoritmos utilizados en nuestras canalizaciones en tiempo real. Debido a esto, decidimos eliminar el almacenamiento de estado, si es posible, por completo de nuestro sistema. Este enfoque requiere que todos los datos necesarios se incluyan en la unidad de datos transmitidos (mensaje). Por ejemplo, si necesitamos calcular el número total de algunas observaciones (el número de operaciones o casos con ciertas características), lo calculamos en memoria y generamos un flujo de dichos valores. Los módulos dependientes utilizarán la partición y el procesamiento por lotes para dividir el flujo por entidades y operar con los valores más recientes. Este enfoque eliminó la necesidad de tener almacenamiento en disco persistente para tales datos. Nuestro sistema utiliza Kafka como intermediario de mensajes y se puede utilizar como base de datos con KSQL. [3] Pero usarlo vincularía fuertemente nuestra solución a Kafka, y decidimos no usarlo. El enfoque que hemos elegido nos permite reemplazar Kafka con otro intermediario de mensajes sin cambios internos importantes en el sistema.
Este concepto no significa que no utilicemos almacenamiento en disco y bases de datos. Para verificar y analizar el rendimiento del sistema, necesitamos almacenar una cantidad significativa de datos en el disco, que representan varios indicadores y estados. El punto importante aquí es que los algoritmos en tiempo real no dependen de tales datos. En la mayoría de los casos, usamos los datos guardados para análisis, depuración y seguimiento fuera de línea de casos y resultados específicos que produce el sistema.
Problemas en nuestro sistema
Hay ciertos problemas que hemos resuelto hasta cierto punto, pero requieren soluciones más reflexivas. Por ahora, solo me gustaría mencionarlos aquí, porque cada artículo vale su propio artículo.
- Todavía necesitamos definir procesos y políticas que ayuden a generar datos significativos y relevantes para nuestro análisis, descubrimiento y exploración automatizados de datos.
- La introducción de los resultados del análisis por parte de una persona en el proceso de ajuste automático del sistema para actualizarlo con los datos más recientes. Esta no es solo una actualización de nuestro modelo, sino también una actualización de nuestros procesos y una mejor comprensión de nuestros datos.
- Encontrar un equilibrio entre el enfoque determinista de IF-ELSE y ML. Alguien dijo: "ML es una herramienta para los desesperados". Esto significa que querrá usar ML cuando ya no sepa cómo optimizar y mejorar sus algoritmos. Por otro lado, el enfoque determinista no permite la detección de anomalías que no fueron previstas.
- Necesitamos una manera fácil de probar nuestras hipótesis o correlaciones entre las métricas de los datos.
- El sistema debe tener múltiples niveles de verdaderos resultados positivos. Los casos de fraude son solo una fracción de todos los casos que pueden considerarse positivos para el sistema. Por ejemplo, los analistas quieren recibir todos los casos sospechosos para su revisión y solo una pequeña fracción de ellos son fraudulentos. El sistema debe proporcionar de manera efectiva a los analistas todos los casos, ya sea que se trate de un fraude real o simplemente de un comportamiento sospechoso.
- La plataforma de datos debería poder recuperar conjuntos de datos históricos con cálculos creados y calculados sobre la marcha.
- Despliegue simple y automático de cualquiera de los componentes del sistema en al menos tres entornos diferentes: producción, experimental (beta) y para desarrolladores.
- Y por último pero no menos importante. Necesitamos crear una amplia plataforma de evaluación comparativa en la que podamos analizar nuestros modelos. [4]
referencias
Fuente: habr.com