Depuis environ six mois, je crée un système de lutte contre la fraude (activité frauduleuse, escroquerie, etc.) sans aucune infrastructure initiale pour cela. Les idées d'aujourd'hui que nous avons trouvées et mises en œuvre dans notre système nous aident à détecter et à analyser de nombreuses activités frauduleuses. Dans cet article, je voudrais parler des principes que nous avons suivis et de ce que nous avons fait pour arriver à l'état actuel de notre système, sans entrer dans la partie technique.
Principes de notre système
Lorsque vous entendez des termes tels que "automatique" et "fraude", vous commencez très probablement à penser à l'apprentissage automatique, à Apache Spark, Hadoop, Python, Airflow et à d'autres technologies de l'écosystème Apache Foundation et du domaine de la science des données. Je pense qu'il y a un aspect de l'utilisation de ces outils qui n'est généralement pas mentionné : ils nécessitent que certaines conditions préalables soient en place sur votre système d'entreprise avant de pouvoir commencer à les utiliser. En bref, vous avez besoin d'une plate-forme de données d'entreprise qui comprend un lac de données et un stockage. Mais que se passe-t-il si vous ne disposez pas d'une telle plateforme et avez encore besoin de développer cette pratique ? Les principes suivants, que je décris ci-dessous, nous ont aidés à arriver au point où nous pouvons nous concentrer sur l'amélioration de nos idées, plutôt que d'en trouver une qui fonctionne. Cependant, ce n'est pas un "plateau" du projet. Il y a beaucoup plus de choses dans le plan du point de vue technologique et produit.
Principe 1 : La valeur métier d'abord
Nous plaçons la « valeur commerciale » au premier plan de tous nos efforts. En général, tout système d'analyse automatique appartient au groupe des systèmes complexes avec un haut niveau d'automatisation et de complexité technique. La création d'une solution complète prendra beaucoup de temps si vous la créez à partir de zéro. Nous avons décidé de mettre la valeur commerciale en premier et la maturité technologique en second. Dans la vraie vie, cela signifie que nous n'acceptons pas la technologie de pointe comme un dogme. Nous choisissons la technologie qui nous convient le mieux pour le moment. Au fil du temps, il peut sembler que nous devrons réimplémenter certains modules. C'est le compromis que nous avons accepté.
Principe 2 : Intelligence augmentée
Je parie que la plupart des gens qui ne sont pas profondément impliqués dans le développement de solutions d'apprentissage automatique pourraient penser que le remplacement humain est l'objectif. En fait, les solutions d'apprentissage automatique sont loin d'être parfaites et le remplacement n'est possible que dans certains domaines. Nous avons abandonné cette idée dès le départ pour plusieurs raisons : des données déséquilibrées sur les activités frauduleuses et l'impossibilité de fournir une liste exhaustive de fonctionnalités pour les modèles d'apprentissage automatique. En revanche, nous avons opté pour l'option intelligence augmentée. Il s'agit d'un concept alternatif d'intelligence artificielle qui se concentre sur le rôle de soutien de l'IA, soulignant le fait que les technologies cognitives sont conçues pour améliorer l'intelligence humaine, et non pour la remplacer. [1]
Dans cette optique, développer dès le départ une solution complète de machine learning nécessiterait un effort colossal qui retarderait la création de valeur pour notre entreprise. Nous avons décidé de construire un système avec un aspect itératif croissant d'apprentissage automatique sous la direction de nos experts du domaine. La partie délicate du développement d'un tel système est qu'il doit fournir à nos analystes des études de cas non seulement pour déterminer s'il s'agit ou non d'une activité frauduleuse. En général, toute anomalie dans le comportement des clients est un cas suspect sur lequel les spécialistes doivent enquêter et réagir d'une manière ou d'une autre. Seuls quelques-uns de ces cas enregistrés peuvent réellement être qualifiés de fraude.
Principe 3 : Plateforme d'analyse enrichie
La partie la plus difficile de notre système est la vérification de bout en bout du flux de travail du système. Les analystes et les développeurs devraient facilement obtenir des ensembles de données historiques avec toutes les métriques utilisées pour l'analyse. En outre, la plate-forme de données devrait fournir un moyen simple de compléter un ensemble d'indicateurs existant par un nouveau. Les processus que nous créons, et ce ne sont pas que des processus logiciels, doivent permettre de recalculer facilement les périodes précédentes, d'ajouter de nouvelles métriques et de modifier la prévision des données. Nous pourrions y parvenir en accumulant toutes les données générées par notre système de production. Dans un tel cas, les données deviendraient progressivement un obstacle. Nous aurions besoin de stocker la quantité croissante de données que nous n'utilisons pas et de les protéger. Dans un tel scénario, les données deviendront de moins en moins pertinentes au fil du temps, mais nécessiteront toujours nos efforts pour les gérer. Pour nous, la thésaurisation des données n'avait pas de sens, et nous avons décidé d'utiliser une approche différente. Nous avons décidé d'organiser des entrepôts de données en temps réel autour des entités cibles que nous souhaitons classer, et de ne stocker que les données permettant de vérifier les périodes les plus récentes et à jour. Le défi de cet effort est que notre système est hétérogène avec plusieurs magasins de données et modules logiciels qui nécessitent une planification minutieuse pour fonctionner de manière cohérente.
Concepts de conception de notre système
Nous avons quatre composants principaux dans notre système : un système d'ingestion, un système de calcul, une analyse BI et un système de suivi. Ils servent des objectifs isolés spécifiques, et nous les gardons isolés en suivant certaines approches de développement.
Conception basée sur contrat
Tout d'abord, nous avons convenu que les composants ne devraient s'appuyer que sur certaines structures de données (contrats) qui sont transmises entre eux. Cela permet de s'intégrer facilement entre eux et de ne pas imposer une composition (et un ordre) spécifique des composants. Par exemple, dans certains cas, cela nous permet d'intégrer directement le système de réception au système de suivi des alertes. Dans un tel cas, cela se fera conformément au contrat de notification convenu. Cela signifie que les deux composants seront intégrés à l'aide d'un contrat que tout autre composant peut utiliser. Nous n'ajouterons pas de contrat supplémentaire pour ajouter des alertes au système de suivi à partir du système d'entrée. Cette approche nécessite l'utilisation d'un nombre minimum prédéterminé de contrats et simplifie le système et les communications. Fondamentalement, nous adoptons une approche appelée "Contract First Design" et l'appliquons aux contrats de streaming. [2]
Diffuser partout
La sauvegarde et la gestion de l'état dans le système entraîneront inévitablement des complications dans sa mise en œuvre. En général, l'état doit être accessible à partir de n'importe quel composant, il doit être cohérent et fournir la valeur la plus à jour pour tous les composants, et il doit être fiable avec les valeurs correctes. De plus, avoir des appels au stockage persistant pour obtenir le dernier état augmentera la quantité d'E/S et la complexité des algorithmes utilisés dans nos pipelines en temps réel. Pour cette raison, nous avons décidé de supprimer complètement le stockage d'état, si possible, de notre système. Cette approche nécessite que toutes les données nécessaires soient incluses dans l'unité de données transmise (message). Par exemple, si nous devons calculer le nombre total de certaines observations (le nombre d'opérations ou de cas avec certaines caractéristiques), nous le calculons en mémoire et générons un flux de ces valeurs. Les modules dépendants utiliseront le partitionnement et le traitement par lots pour diviser le flux par entités et fonctionner sur les dernières valeurs. Cette approche a éliminé le besoin d'avoir un stockage sur disque persistant pour ces données. Notre système utilise Kafka comme courtier de messages et il peut être utilisé comme base de données avec KSQL. [3] Mais l'utiliser lierait fortement notre solution à Kafka, et nous avons décidé de ne pas l'utiliser. L'approche que nous avons choisie nous permet de remplacer Kafka par un autre courtier de messages sans modifications internes majeures du système.
Ce concept ne signifie pas que nous n'utilisons pas de stockage sur disque et de bases de données. Afin de vérifier et d'analyser les performances du système, nous devons stocker une quantité importante de données sur le disque, ce qui représente divers indicateurs et états. Le point important ici est que les algorithmes temps réel ne dépendent pas de telles données. Dans la plupart des cas, nous utilisons les données enregistrées pour l'analyse hors ligne, le débogage et le suivi des cas spécifiques et des résultats produits par le système.
Problèmes dans notre système
Il y a certains problèmes que nous avons résolus à un certain niveau, mais ils nécessitent des solutions plus réfléchies. Pour l'instant, je voudrais juste les mentionner ici, car chaque article vaut son propre article.
- Nous devons encore définir des processus et des politiques qui aident à générer des données significatives et pertinentes pour notre analyse, découverte et exploration automatisées des données.
- L'introduction des résultats d'analyse par une personne dans le processus de réglage automatique du système pour le mettre à jour avec les dernières données. Il ne s'agit pas seulement d'une mise à jour de notre modèle, mais aussi d'une mise à jour de nos processus et d'une meilleure compréhension de nos données.
- Trouver un équilibre entre l'approche déterministe de IF-ELSE et ML. Quelqu'un a dit : "Le ML est un outil pour les désespérés." Cela signifie que vous voudrez utiliser ML lorsque vous ne comprendrez plus comment optimiser et améliorer vos algorithmes. En revanche, l'approche déterministe ne permet pas de détecter des anomalies qui n'étaient pas prévues.
- Nous avons besoin d'un moyen simple de tester nos hypothèses ou les corrélations entre les métriques dans les données.
- Le système doit avoir plusieurs niveaux de vrais résultats positifs. Les cas de fraude ne représentent qu'une fraction de tous les cas pouvant être considérés comme positifs pour le système. Par exemple, les analystes souhaitent recevoir tous les cas suspects pour examen, et seule une petite partie d'entre eux sont frauduleux. Le système doit effectivement fournir aux analystes tous les cas, qu'il s'agisse d'une véritable fraude ou simplement d'un comportement suspect.
- La plate-forme de données doit pouvoir récupérer des ensembles de données historiques avec des calculs créés et calculés à la volée.
- Déploiement simple et automatique de n'importe lequel des composants du système dans au moins trois environnements différents : production, expérimental (bêta) et pour les développeurs.
- Et pour couronner le tout. Nous devons créer une plate-forme de test de performance riche sur laquelle nous pouvons analyser nos modèles. [4]
références
Source: habr.com