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
14. MACRO ARCHITECTUREMACRO ARCHITECTURE
Scoring nodesBank system
Training nodes
Monitoring nodes
Card
transaction
Transaction
Prediction
Monitoring
teams and
data
scientists
Models
consolidated
scoring data
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. 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. 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
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. 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. RÉSILIENCE À LA PANNERÉSILIENCE À LA PANNE
PROBLÈMEPROBLÈME
1 scoring node
Applicatifs indépendants
RocksDB local
Que faire si le scoring tombe ?
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. 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. 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. 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. 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. 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)
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. 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. 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. 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
...
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. 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. 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