Détection des fraudes en temps réel avec Feature Views

La détection des fraudes en temps réel repose sur trois types de features : ce qu'un client a fait il y a quelques secondes, ses habitudes de dépenses et le profil du paiement actuel. Ces features doivent être calculées de la même manière pour l'entraînement du modèle et pour le scoring en direct, sous peine de voir la fuite de données et le décalage entre l'entraînement et le service compromettre discrètement la qualité du modèle. Les Feature Views, qui font partie de Databricks Feature Store, répondent à ce besoin. Vous définissez chaque feature une seule fois, et cette définition génère à la fois des données d'entraînement temporelles (point-in-time) et les pipelines gérés pour l'inférence en ligne.

Un paiement de 900 $ peut sembler banal pour un client et inhabituel pour un autre. Lorsqu'il arrive, un modèle de fraude ne dispose que d'un instant pour décider s'il paraît normal, nécessite une vérification ou doit être bloqué. Approuver une transaction frauduleuse peut coûter de l'argent au client. Bloquer une transaction légitime perturbe son expérience de paiement et érode sa confiance dans la plateforme.

La transaction à elle seule ne raconte pas toute l'histoire. Le modèle doit également savoir comment ce client effectue généralement ses transactions et ce qu'il a fait il y a quelques secondes, minutes, jours ou semaines. Pendant l'entraînement, les features ne doivent utiliser que les informations disponibles au moment où chaque paiement a eu lieu. Lors du scoring en direct, elles doivent refléter les transactions récentes assez rapidement pour intercepter une activité suspecte. Si les deux chemins implémentent la logique séparément, de légères différences s'introduisent entre eux.

Cette présentation suit ce paiement de 900 $ depuis un flux Kafka jusqu'à un score de fraude servi par Model Serving, avec du code à chaque étape. L'idée centrale est qu'une seule définition de feature, pilotant à la fois l'entraînement et le service, vous offre des données d'entraînement correctes sur le plan temporel et des features en ligne cohérentes. Vous ne construisez pas de pipeline séparé pour chaque chemin.

Qu'est-ce qu'une Feature View ?

Une Feature View est une définition de Databricks Feature Store qui spécifie la source, les clés d'entité, la sémantique temporelle et la transformation d'une feature. La même définition calcule les valeurs historiques pour l'entraînement et pilote les pipelines gérés qui maintiennent les fraîches pour le service. Une seule API couvre les features par lots (batch), en streaming et à la demande. Unity Catalog gouverne leurs définitions, leurs autorisations et leur lignage.

Deux modes de défaillance motivent cette conception :

• Le décalage entre l'entraînement et le service (Training-serving skew) se produit lorsqu'une feature est calculée d'une manière lors de l'entraînement et d'une autre en production. Au moment de l'inférence, le modèle voit alors des entrées qui ne correspondent pas à ce qu'il a appris.
• La fuite de données (Data leakage) se produit lorsque les données d'entraînement incluent des informations qui n'étaient pas disponibles au moment de la prédiction. Les features correctes sur le plan temporel l'évitent en n'utilisant que les événements survenus avant le moment à prédire.

Les Feature Views intègrent le calcul des features en streaming dans le même flux de travail de science des données que l'entraînement historique et le scoring en direct. Vous pouvez évaluer les features par rapport aux transactions passées, puis utiliser les mêmes définitions pour maintenir le contexte client à jour pour les décisions en direct.

De quelles features un modèle de fraude en temps réel a-t-il besoin ?

L'objectif est de signaler les paiements suspects dès leur arrivée sans déclencher de fausses alertes sur les paiements légitimes. Pris isolément, le paiement de 900 $ peut sembler inoffensif. Mais s'il s'agit du 10e paiement en cinq minutes, il pourrait faire partie d'une rafale suspecte. Tout délai dans la reconnaissance de cette rafale donne à une personne ayant accès à un compte compromis plus de temps pour effectuer des paiements supplémentaires.

Une application de détection des fraudes créée avec Databricks Apps traite un flux de transactions financières. Chaque événement comprend un ID client, un montant, un type de paiement, un horodatage ainsi que les pays d'origine et de destination. L'application envoie chaque transaction à un point de terminaison Model Serving. Elle affiche ensuite le score de risque de la transaction parallèlement au volume de transactions en direct, aux transactions signalées et aux flux d'un pays à l'autre.
 

Le modèle combine trois types de contexte :

• Activité récente : un nombre de transactions sur cinq minutes et un montant total sur 10 minutes, calculés avec RollingWindow, capturent la fréquence des paiements du client et le montant de ses dépenses.
• Ligne de base des dépenses : une moyenne sur 30 jours et un écart type, maintenus avec SawtoothWindow, décrivent le montant typique des paiements du client et sa variabilité.
• Détails de la transaction : le montant du paiement actuel, le type de paiement ainsi que les pays d'origine et de destination fournissent le contexte de la décision.

L'architecture comporte un chemin historique pour l'entraînement et un chemin en ligne pour l'inférence. Tous deux partent des mêmes définitions de feature dans Unity Catalog. Le chemin historique lit la table d'ingestion du Stream pour construire des jeux d'entraînement temporels. Le chemin en ligne matérialise les agrégats dans l'Online Feature Store, où Model Serving les lit au moment de la requête.

Comment définir des features en streaming à partir de Kafka

Avant de décider quelles features servir, vous pouvez tester des alternatives par rapport aux transactions historiques. Un nombre de transactions sur cinq minutes offre-t-il un signal plus fort qu'un nombre sur 15 minutes ? Comparer le montant actuel avec la variabilité des dépenses du client aide-t-il au-delà de la simple utilisation de sa moyenne ?

Dans cet exemple, les événements de transaction client arrivent sous forme de flux Kafka. Un Stream enregistré détient la connexion, le schéma et les paramètres d'ingestion, et un& StreamSource s'y réfère pour calculer des features en temps réel. Les topics Kafka ne conservent pas assez d'historique pour l'entraînement du modèle. Databricks gère par conséquent une copie hors ligne du flux dans une table d'ingestion. Pour l'entraînement ou le remplissage d'un magasin en ligne, Databricks calcule les valeurs historiques à partir de la table d'ingestion et utilise le flux Kafka en direct pour les données les plus récentes.

Lors de l'ingestion, transformation_sql remodèle les champs imbriqués de la charge utile (payload) de valeur Kafka dans le schéma requis par les features. La projection fait partie de la définition de la source, ce qui vous évite de déployer un pipeline de prétraitement séparé. Pour notre paiement, la charge utile de valeur Kafka contient :

La démo utilise demo_user_id avec customer_id pour garder séparés les historiques clients des différents utilisateurs de l'application.

Nous définissons le compte sur cinq minutes avec RollingWindow. Le notebook compagnon inclut les importations, la configuration et la projection source complète.

Vous pouvez inspecter ses valeurs historiques dans un notebook avec compute_features(features=[recent_transaction_count]). Le total sur 10 minutes utilise la même source et les mêmes clés, avec un Sum sur une RollingWindow de 10 minutes.

Une fenêtre en dents de scie (sawtooth window) est une agrégation à longue période rétrospective (lookback) dont la limite la plus ancienne avance par étapes quotidiennes. Elle combine l'historique calculé par lots avec des mises à jour en streaming pour l'activité récente. Pour notre paiement de 900 $, SawtoothWindow ajoute une ligne de base de dépenses de 30 jours aux fenêtres glissantes courtes. Les deux types de fenêtres maintiennent l'activité récente à jour. La limite la plus ancienne de la fenêtre en dents de scie se déplaçant quotidiennement plutôt que continuellement, sa période rétrospective effective est légèrement supérieure à 30 jours. La ligne de base utilise les agrégations intégrées Avg, StddevPop et Count sur les montants des paiements sur la même fenêtre en dents de scie.

Databricks démarre un pipeline d'ingestion géré lorsqu'un Stream est créé et conserve les événements entrants dans sa table d'ingestion. Si vous avez également besoin d'événements antérieurs à la création du Stream, StreamBackfillSource vous permet de fournir votre propre historique lors de la configuration du Stream. Une fois que la table couvre toute la période rétrospective, une nouvelle feature en dents de scie peut l'utiliser immédiatement au lieu d'attendre 30 jours que les événements s'accumulent.

Comment comparer un paiement en direct avec la base de référence d'un client

Une feature à la demande est calculée au moment de la requête en combinant les valeurs de la requête de scoring avec des features stockées. Comparer une transaction en direct à la base de référence historique d'un client est une méthode courante pour repérer un comportement anormal. Dans Feature Views, les informations au moment de l'inférence sont représentées par un RequestSource — ici, transaction_amount provenant de la requête de l'application.

Deux clients peuvent avoir une moyenne de 300 $ par paiement tout en dépensant de manière très différente. Avec des écarts-types de 100 $ et 600 $, le même paiement de 900 $ se situe à six écarts-types au-dessus de la moyenne d'un client et à un seul au-dessus de celle de l'autre. Le modèle combine cette comparaison avec l'activité récente et les détails du paiement pour estimer le risque de fraude.

Les agrégations Sawtooth conservent la moyenne et l'écart-type sur 30 jours. La feature à la demande les combine avec le montant actuel pour calculer (current_amount - average) / standard_deviation. Nous implémentons ce calcul sous forme de Python UDF enregistré dans Unity Catalog :

La définition de feature utilise des objets Feature en amont enregistrés. FeatureViewSource rassemble le montant actuel et les trois statistiques sur 30 jours, et CustomUDF appelle la fonction :

Lorsqu'il n'y a pas assez d'historique utilisable, la fonction renvoie zéro en guise de solution de repli. Un indicateur distinct permet au modèle de distinguer cette solution de repli d'un véritable zéro, ce qui signifie que le paiement correspond à la moyenne du client. La même feature dérivée est évaluée par rapport aux entrées historiques lors de l'entraînement, et par rapport à la requête actuelle ainsi qu'aux statistiques récupérées lors de l'inférence.

Comment tester des candidats feature avant de les déployer

Pendant le développement des features, vous pouvez inspecter les définitions de features dans un notebook avec compute_features(). Cela fonctionne pour les features dérivées dont les entrées proviennent entièrement de données source historiques. Pour les comparaisons dépendantes des requêtes telles que amount_deviation, utilisez plutôt create_training_set(), qui fournit les champs de paiement actuels à partir d'exemples étiquetés. La fonction Unity Catalog doit exister, mais les définitions de features peuvent rester non enregistrées pendant que vous testez les candidats.

Cela vous permet de vérifier si une feature améliore les performances hors ligne du modèle de fraude avant de le déployer pour le scoring en direct. Par exemple, vous pouvez comparer des modèles avec et sans amount_deviation sur des paiements ultérieurs mis de côté. Ces expériences s'exécutent sur un calcul par lots (batch) sur l'historique des transactions, ce qui vous permet d'évaluer chaque candidat sans configurer de matérialisation en ligne. Une fois que vous avez sélectionné les features, enregistrez leurs définitions et matérialisez les agrégations mobiles et Sawtooth pour le serving.

Comment créer des données d'entraînement correctes à un instant donné (point-in-time)

Chaque exemple d'entraînement historique nécessite des features calculées à l'horodatage de ce paiement. Pour notre paiement de 900 $ à 10h00, le décompte sur cinq minutes doit inclure les transactions de 9h55 jusqu'à 10h00, sans l'inclure. Un décompte récupéré à 10h03 pourrait inclure un paiement effectué à 10h02, qui n'était pas disponible lors du scoring du paiement initial. Il s'agit d'une fuite de données : le modèle apprend de l'activité future et ses performances hors ligne semblent meilleures qu'elles ne le sont réellement. Feature Views utilise les clés client et l'horodatage de chaque exemple pour calculer la fenêtre historique correcte à partir des événements de la table d'ingestion du Stream.

Après avoir enregistré les features sélectionnées, create_training_set() crée les données d'entraînement du modèle. Le DataFrame étiqueté fournit les clés client, l'heure de l'événement, les champs de paiement actuels et is_fraud. Cet extrait sélectionne les features enregistrées de la procédure guidée, y compris la base de référence sur 30 jours, et utilise les lignes précédant une date limite choisie pour l'entraînement :

Les clés et les horodatages sélectionnent l'historique du client mais sont exclus en tant qu'entrées du modèle. Les champs de requête alimentent les calculs de features ; le classifieur utilise les features nommées résultantes. Les lignes suivantes forment un ensemble de validation utilisant les mêmes définitions.

Nous entrînons un classifieur de forêt aléatoire (random forest) et évaluons la précision moyenne et l'AUC ROC sur ce dernier. Nous enregistrons ensuite le modèle via le client Feature Engineering. Le passage de training_set=train_set enregistre les dépendances de features dont le serving aura besoin :

Comment servir des features en temps réel pour l'inférence en ligne

Transférer les features sélectionnées ci-dessus dans le scoring en direct nécessite des pipelines pour maintenir des agrégats en streaming, traiter les données historiques et maintenir le magasin en ligne à jour. La création et l'exploitation de ces pipelines ajoutent des mois de travail d'ingénierie des données en plus du développement du modèle de fraude. Avec Feature Views, les définitions de features enregistrées pilotent ce processus : un appel à materialize_features() crée des pipelines gérés qui rendent les agrégations disponibles dans Databricks Online Feature Store, propulsé par Lakebase.

Le chemin de streaming utilise Spark Real-Time Mode (RTM) pour traiter les événements entrants en continu et mettre à jour les agrégats mobiles au fur et à mesure de leur arrivée.

Nous matérialisons les agrégations mobiles et Sawtooth. Pour la base de référence Sawtooth sur 30 jours, Databricks gère la partie historique avec le calcul par lots et l'activité récente avec le streaming. Les deux sont fusionnés lors de la lecture en une seule feature, et StreamingMode() gère ce chemin hybride sans appel par lots séparé. Vérifiez les deux chemins de matérialisation dans Catalog Explorer avant le serving. Les recommandations Sawtooth conseillent d'attendre deux jours pleins avant une utilisation en production.

RequestSource fournit les valeurs de chaque requête de scoring, et les features dérivées sont calculées à la demande. Une fois le modèle déployé, l'application envoie les clés client et les champs de paiement actuels à son point de terminaison. Model Serving récupère les features client les plus récentes et évalue l'écart à la demande, puis transmet les entrées au modèle de fraude. Voici notre paiement de 900 $ au format de requête de l'application, en utilisant l'appel SDK du scoreur :

L'application envoie event_time dans cette requête, mais la recherche en ligne utilise les features client les plus récentes disponibles, et non un instantané historique sélectionné par cette estampille temporelle. Dans cette démo, l'application score chaque paiement avant de le publier sur Kafka. Cela évite d'inclure le paiement actuel dans son propre historique, ce qui correspond à l'exclusion de ce paiement de la fenêtre d'entraînement. Les mises à jour de features et le scoring s'exécutent toujours de manière asynchrone, de sorte que d'autres événements peuvent être en cours lors du scoring du paiement suivant.

Le point de terminaison renvoie une probabilité dans fraud_probability et un indicateur dans fraud_prediction. L'application stocke les transactions scorées dans Lakebase pour le tableau de bord.

Comment gouverner les features ML dans Unity Catalog

Les modèles de fraude en production soulèvent des questions de gouvernance : quels modèles utilisent une feature, d'où elle vient et qui peut la lire. Unity Catalog rassemble les définitions de features, les autorisations et la traçabilité pour y répondre. MLflow enregistre les features utilisées par chaque modèle, et Model Serving utilise ces dépendances lorsqu'il traite une requête d'inférence.

Les privilèges de feature contrôlent le cycle de vie :

• CREATE FEATURE contrôle l'enregistrement.
• READ FEATURE accorde l'accès aux métadonnées des features.
• MANAGE autorise les opérations telles que la matérialisation.

Les privilèges de feature ne remplacent pas les autorisations SELECT requises sur les tables sources ou matérialisées pour l'entraînement et le serving.

Dans Catalog Explorer, les Feature Views apparaissent sous Functions, avec leurs définitions, liens sources, tables matérialisées et statut. Les matérialisations en streaming se connectent à leurs pipelines Lakeflow gérés par le système pour inspection. Tags de matérialisation permettent aux équipes d'attribuer les coûts de calcul des pipelines ou des tâches à une équipe ou un projet spécifique.

Points clés pour la détection des fraudes en temps réel

Notre paiement de 900 $ dispose désormais d'un contexte : activité récente, base de référence à long terme et requête actuelle. Trois pratiques ont rendu cela possible :

• Définir une fois, utiliser deux fois. Des définitions de features partagées pour l'entraînement et le serving réduisent l'écart entre l'entraînement et le serving (training-serving skew) provenant d'implémentations distinctes.
• Calculer au point dans le temps. Les fenêtres d'entraînement qui excluent les événements futurs préviennent la fuite de données (data leakage) et garantissent la fiabilité des métriques hors ligne.
• Laisser la plateforme exécuter les pipelines. La matérialisation et la recherche en ligne sont gérées, ce qui permet de se concentrer sur le choix de meilleurs signaux de fraude.

Ces mêmes schémas vont au-delà de ce guide. LastN conserve des séquences telles que les pays de destination des 10 paiements les plus récents d'un client, ce qui aide les modèles à repérer les changements dans les itinéraires de paiement. Les features par lot (batch features) peuvent également utiliser des agrégations sur toute la durée de vie pour résumer l'historique complet d'une entité.

Pour un examen plus approfondi de l'infrastructure sous-jacente à la fraîcheur en streaming inférieure à la seconde, lisez Comment le Databricks Feature Store sert des features avec une fraîcheur inférieure à la seconde. Pour les détails d'implémentation, consultez la documentation pour l'API Feature Views, la matérialisation et l'exploration des Feature Views dans Unity Catalog.

FAQ

Que sont les Databricks Feature Views ?

Les Feature Views sont une fonctionnalité du Databricks Feature Store permettant de définir des features ML une seule fois et de les utiliser à la fois pour l'entraînement et la production. Chaque définition spécifie une source, des clés d'entité, une sémantique temporelle et une transformation. La même API couvre les features par lot (batch), en streaming et à la demande, et Unity Catalog les gouverne.

Comment les Feature Views empêchent-elles la fuite de données lors de l'entraînement d'un modèle de fraude ?

Les Feature Views calculent les features de chaque exemple d'entraînement à l'estampille temporelle de cet exemple. Pour un paiement à 10h00, un compte de transactions de cinq minutes inclut les paiements de 9h55 jusqu'à 10h00 (exclu). Cela empêche l'activité future d'entrer dans les données d'entraînement, afin que les performances hors ligne ne soient pas surévaluées.

Qu'est-ce que l'écart entre l'entraînement et le serving (training-serving skew) et comment les Feature Views le réduisent-elles ?

L'écart entre l'entraînement et le serving se produit lorsque les features sont calculées d'une manière pour l'entraînement et d'une autre pour l'inférence en direct. Les Feature Views le réduisent en utilisant une seule définition enregistrée pour le calcul historique et la matérialisation en ligne. Les équipes n'ont pas besoin de réimplémenter la logique de feature pour la production.

Est-ce que les Feature Views peuvent calculer des features à partir de flux Kafka ?

Oui. Un Stream enregistré contient la connexion Kafka, le schéma et les paramètres d'ingestion, et un StreamSource y fait référence dans les définitions de features. Databricks conserve une copie hors ligne du flux dans une table d'ingestion pour l'entraînement et le remplissage (backfill). Le mode temps réel met à jour les agrégats de streaming à mesure que de nouveaux événements arrivent.

Comment les features en temps réel sont-elles servies à un modèle de fraude en production ?

L'appel de materialize_features() crée des pipelines gérés qui maintiennent les agrégats à jour dans l'Online Feature Store, alimenté par Lakebase. Lorsque le modèle est enregistré avec log_model() et déployé sur Model Serving, le point de terminaison récupère les features client les plus récentes et calcule les features à la demande à partir de la requête. Il renvoie ensuite une probabilité de fraude.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original