Comment Jumio a construit un feature store en temps réel sur AWS
Jumio, fournisseur de solutions de vérification d'identité utilisées pour détecter la fraude et établir la confiance numérique, a détaillé dans un billet de blog publié par Amazon Web Services l'architecture de son magasin de caractéristiques (feature store) temps réel pour ses modèles de machine learning. Le système repose sur Amazon Kinesis Data Streams pour l'ingestion des événements, Amazon Managed Service for Apache Flink pour leur transformation en caractéristiques (features), et Amazon SageMaker Feature Store pour leur stockage en mémoire avant utilisation par les modèles d'inférence. Un second flux, dédié à l'entraînement des modèles, achemine les événements via Amazon Data Firehose vers Amazon S3, où ils sont traités par Amazon EMR et stockés sous forme de tables Iceberg. L'ensemble a été déployé dans trois régions AWS : Virginie du Nord (us-east-1), Francfort (eu-central-1) et Singapour (ap-southeast-1), avec un objectif de latence inférieur à 100 millisecondes pour les cas d'usage de détection de fraude en temps réel.
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
Cette refonte répond à des problèmes concrets rencontrés par Jumio avant la mise en place du système centralisé : chaque équipe entretenait son propre magasin de caractéristiques hors ligne, générant des données dupliquées et des définitions incohérentes ; les features validées à l'entraînement devaient être réimplémentées manuellement en production, en Java ou en Python, ce qui multipliait les risques de bugs et d'écarts entre les deux environnements ; et certains événements, liés à des processus de revue prolongés, pouvaient n'arriver que plusieurs semaines après le fait initial, compliquant leur intégration en temps réel. En unifiant l'ingénierie des features autour d'une plateforme unique, Jumio réduit les risques d'erreurs de fraude liées à des données obsolètes ou incohérentes, accélère la mise en production de nouvelles caractéristiques et permet à des équipes différentes de développer des features de façon autonome, avec moins de coordination nécessaire entre elles.
Ce cas illustre une problématique plus large pour les entreprises qui dépendent du machine learning en temps réel, notamment dans les secteurs de la fintech et de la lutte contre la fraude, où la fraîcheur et la cohérence des données conditionnent directement la fiabilité des décisions automatisées. Jumio a formalisé cinq exigences techniques structurant son architecture : une scalabilité permettant de gérer un volume croissant de requêtes et de nouvelles features sans casser les schémas existants, des capacités avancées d'ingénierie de features incluant la création conditionnelle et la sélection basée sur l'horodatage des événements, une latence de service sous les 100 millisecondes, la capacité à réalimenter rétroactivement le magasin hors ligne pour le réentraînement et le débogage des modèles, et enfin un cycle de développement agile pour les équipes cross-fonctionnelles. Ce type d'architecture de référence, combinant streaming géré et stockage de features intégré, s'inscrit dans une tendance plus générale des fournisseurs cloud à proposer des briques prêtes à l'emploi pour le MLOps temps réel.
Le déploiement inclut la région AWS de Francfort (eu-central-1), impliquant un traitement de données localisé en Europe pour les clients de Jumio.