Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Retour expérience détection fraude temps réel

1 653 vues

Publié le

Présentation sur le retour d'expérience sur la mise en place d'un système de détection de fraudes, en temps réel et auto-apprenant.

Publié dans : Ingénierie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Retour expérience détection fraude temps réel

  1. 1. SYSTÈME DE DÉTECTION DE FRAUDESSYSTÈME DE DÉTECTION DE FRAUDES REXREX
  2. 2. SOMMAIRESOMMAIRE Introduction Quelques termes pour commencer ! Architecture Challenges et solutions Scala: quels avantages sur le projet ? Améliorations
  3. 3. INTRODUCTIONINTRODUCTION
  4. 4. CONSULTANTS EBIZNEXTCONSULTANTS EBIZNEXT
  5. 5. PROBAYESPROBAYES Société spécialisée en IA (INRIA / CNRS) Créé en 2003 basée à Grenoble & Paris Rachetée par le groupe La Poste en 2016
  6. 6. FRAUDIAFRAUDIA Un système de détéction de fraudes bancaires en temps réel Transaction en cours Mais aussi : Historique des transactions Cartes en oppositions Transactions frauduleuses La Banque Postale & Société Générale De fortes contraintes de performance Amélioration continue et dynamique du modèle XGBoost
  7. 7. QUELQUES TERMES POUR COMMENCER !QUELQUES TERMES POUR COMMENCER !
  8. 8. MACHINE LEARNINGMACHINE LEARNING
  9. 9. FEATURE ENGINEERINGFEATURE ENGINEERING
  10. 10. MODÈLEMODÈLE
  11. 11. SCORINGSCORING
  12. 12. LABELLABEL
  13. 13. ARCHITECTUREARCHITECTURE
  14. 14. MACRO ARCHITECTUREMACRO ARCHITECTURE Scoring nodesBank system Training nodes Monitoring nodes Card transaction Transaction Prediction Monitoring teams and data scientists Models consolidated scoring data
  15. 15. SCORING NODESCORING NODE Load Balancer Transaction Couchbase denormalized historic + user data Prediction Watcher: - Load models in memory - Persist users data feature engineering Models call Update denormalized historic Kafka Transaction, features,  prediction, and technical data (model version, ...) Users
  16. 16. SCORING NODESCORING NODE Pré-calcul et stockage d'un historique dénormalisé des transactions Chargement à chaud des nouveaux modéles Contrainte métier: update complet avant envoi de la prédiction
  17. 17. ARCHITECTURE GLOBALEARCHITECTURE GLOBALE Scoring node Scoring node Scoring node Training node Monitoring node Load balancer ES Kafka Kafka Kafka Models Bank system Card transaction Models Transaction Prediction All transaction, features and scoring information Mirror maker Monitoring teams and data scientists Users Frauds 
  18. 18. ARCHITECTURE GLOBALEARCHITECTURE GLOBALE Load balancing Transmission des features via Kafka Kafka Consommé par : Monitoring node => supervision métier Training node => réentrainement récurrent Source de donnée pour le training Temps de rétention Mirror maker nécessaire pour l'isolation des briques
  19. 19. CHALLENGES ET SOLUTIONSCHALLENGES ET SOLUTIONS
  20. 20. TEMPS DE RÉPONSETEMPS DE RÉPONSE PROBLÈMEPROBLÈME Quelques centaines de requêtes par secondes en conditions nominales Quelques ms / requête Plus de 150 features Features temporelles (dépendant de l'historique des features passées)
  21. 21. SOLUTIONSOLUTION Optimisation du feature engineering: benchmarking Structure de données spécifiques pour optimiser les calculs Trade-off performance du modèle / temps de réponse RocksDB: Key Value store local, très performant, avec un système de cache
  22. 22. RÉSILIENCE À LA PANNERÉSILIENCE À LA PANNE PROBLÈMEPROBLÈME 1 scoring node Applicatifs indépendants RocksDB local Que faire si le scoring tombe ?
  23. 23. SOLUTIONSOLUTION 3 scoring nodes Load balancing ... Problème avec RocksDB en local ?
  24. 24. BASE DE DONNÉES DISTRIBUÉEBASE DE DONNÉES DISTRIBUÉE PROBLÈMEPROBLÈME RocksDB n'est pas distribué Besoin d'un key value store, distribué et hautement performant pour remplacer RocksDB Besoin métier: immediate consistency o/
  25. 25. SOLUTIONSOLUTION Couchbase Orienté document et KV Très performant en écriture ET en lecture In memory Autres pistes: redondance à postériori: KO métier Cassandra: mauvaises performances en update Redis: pas d'immediate consistency MongoDb: mauvaises performances en concurrence d'accès Infiny span: cache distribué
  26. 26. MISE À JOUR DES DONNÉES RÉFÉRENTIELSMISE À JOUR DES DONNÉES RÉFÉRENTIELS PROBLÈMEPROBLÈME Fichier référentiels : annulent et remplacent Utilisation qu'en cas de succès complet de leurs ingestions Transaction globale Bascule des anciens aux nouveaux sans interruption de service
  27. 27. SOLUTIONSOLUTION Clés préfixées dans Couchbase Préfixe en cache Nouveaux référentiels = nouveau préfixe Invalidation du cache et suppression des données obselètes
  28. 28. AMÉLIORATION CONTINUE DU MODÈLEAMÉLIORATION CONTINUE DU MODÈLE PROBLÈMEPROBLÈME Les comportements frauduleux évoluent Feature engineering sur l'historique impossible (trop long) Pas d'interruption de service Nécessité pouvoir déclencher un entraînement à la demande
  29. 29. SOLUTIONSOLUTION Scheduling d'entrainments automatiques récurrents + IHM Réutilisation des features du scoring node grâce à Kafka Processus complexe : Akka Stream Test de perfomance : nouveau vs actuel Changement de modèle à chaud Export des données (exploratoire)
  30. 30. SCALA: QUELS AVANTAGES SUR LE PROJETSCALA: QUELS AVANTAGES SUR LE PROJET ??
  31. 31. TYPAGETYPAGE Data flow complexe "guidé" par les types & modélisation du domaine métier précis - Domaine métier : Requête Requête parsée Features Score brut Score métier Réponse Mal typé : String List[String] List[Double] Double String String Bien typé : Request List[RawFeatures] List[Features] RawScore RefinedScore Response - Les états ou transformations incorrectes sont détéctées à la compilation
  32. 32. IMMUTABILITÉIMMUTABILITÉ Contexte de charge importante et de concurrence forte L'immutabilité donne une tranquilité d'esprit Pas à gérer utilisations concurrentielles, la thread safety Seules mutations dans la code base Localement dans les algorithmes de feature engineering Reload des modèles à chaud
  33. 33. MONTÉE EN COMPÉTENCEMONTÉE EN COMPÉTENCE Onboarding en douceur de développeurs Java Code de plus en plus idiomatique "Scalava" ⇒Better Java ⇒Scala FPish ⇒FP Code review Amélioration continue de l'équipe Émergence naturelle des besoins de refactoring
  34. 34. GAIN DE PRODUCTIVITÉ GRÂCE À LA BOITE À OUTILS DE LA FPGAIN DE PRODUCTIVITÉ GRÂCE À LA BOITE À OUTILS DE LA FP ADT Modèlisation des différents états de la donnée & des erreurs Lenses pour des case class imbriquées a.copy(b = a.b.copy(...☠!)) Applicatives: combinaison d'effets indépendant Feature engineering ! Composition de fonctions Data flow du projet Polymorphisme de type Re-utilisation de code ...
  35. 35. AXES D'AMÉLIORATIONSAXES D'AMÉLIORATIONS
  36. 36. PLUS DE FP !PLUS DE FP ! Remplacement des Future par une monade IO Eager Non référentiellement transparente ZIO ? Cats IO ? Task ? Meilleure gestion des erreurs Try Fail fast Throwable Either ou Validation
  37. 37. OPTIMISER LE STOCKAGEOPTIMISER LE STOCKAGE Mise en cache des informations les plus souvent requêtées => Certains utilisateurs sont plus actifs que d'autres
  38. 38. OUVERTURE À D'AUTRE ÉCOSYSTÈMESOUVERTURE À D'AUTRE ÉCOSYSTÈMES Comment utiliser le tooling data Python / C++ / etc. ? Machine Learning as a service => gRPC HTTP/2 Protobuf Polyglot (Java, Python, Scala, C++, ...) Client / Server / Sérialisation
  39. 39. QUESTIONS ?QUESTIONS ?
  40. 40. MERCI !MERCI !

×