Comment BlaBlaCar utilise le machine learning contre la fraude

Comment éviter, dans les systèmes de machine learning, un décalage entre les performances pendant l’entraînement et pendant l’inférence ?

Google a établi diverses règles en la matière. L’une d’entre elles consiste à enregistrer l’ensemble de caractéristiques utilisé au moment de l’inférence, puis à diriger ces caractéristiques vers un journal pour les utiliser lors de l’entraînement.

BlaBlaCar s’en est inspiré pour développer son propre système de détection des fraudes. Plus précisément, les faux profils d’utilisateurs et les trajets qu’ils publient.

La première étape a consisté à choisir un KPI : le nombre de cas de fraude signalés par les membres via le formulaire de contact. Transversal, il fait l’objet d’une mise à jour tous les trimestres, avec des objectifs par pays.

Le problème d’un tel indicateur : le signalements peuvent intervenir jusqu’à 3 semaines après la fraude. Il a donc fallu y coupler des métriques « au jour le jour ». Dans un premier temps, BlaBlaCar s’est concentré sur la réduction du taux de réservations faites sur des voyages publiés par des fraudeurs. Une fois cet élément sous contrôle, notamment grâce à des actions de sensibilisation des utilisateurs, l’attention s’est portée sur le taux d’offres frauduleuses. Le KPI de référence est resté le nombre de scams pour 10 000 passagers. Tous ces indicateurs étaient calculés quotidiennement en annotant à la main un échantillon de conducteurs actifs.

Kafka au cœur du système…

BlaBlaCar a d’abord examiné manuellement les groupes d’utilisateurs au sein desquels la proportion de fraude était le plus importante.

Par la suite s’est posée la question de passer à l’échelle et d’automatiser. L’option moteur de règles a montré ses limites autant à cause du taux de faux positifs que de par les capacités d’adaptation des fraudeurs (en moyenne, moins d’une semaine pour contourner une règle). Les systèmes de machine learning, à l’inverse, ont la capacité de s’adapter aux changements de comportement. Mais aussi de réduire les faux positifs en apprenant des patterns de fraude plus nuancés.

Pour pouvoir itérer rapidement sans compromettre le SLO de ses services de publication et de réservation de trajets, BlaBlaCar a mis à profit son infrastructure orientée événements. Son cluster Kafka a en l’occurrence servi à écouter et à scorer, en temps quasi réel, lesdits événements de publication et de réservation. Ces scores sont tramis à des services de lutte contre la fraude. Ils peuvent annuler une action, réinitialiser un mot de passe, demander des infos supplémentaires, bloquer un membre, etc.

Former l’algorithme sous-jacent implique de s’assurer de la correctitude des caractéristiques (features) lors de l’entraînement. Vu la capacité d’adaptation des fraudeurs, plus elles seront anciennes, moins elles seront susceptibles de réfléter les patterns de fraude.

C’est là qu’intervient la règle sus-évoquée. Sa mise en place a consisté à stocler toutes les caractéristiques d’inférence dans l’événement « scoring de fraude » et à s’appuyer exclusivement sur elles pour l’entraînement. BlaBlaCar a constaté, d’une part, une amélioration qualitative. Et de l’autre, une réduction de la complexité du code par rapport à ses autres pipelines utilisant le backfill (remplissage de données historiques manquantes ou remplacement d’anciens enregistrements par des nouveaux). S’appuyer sur les logs de prod permet, en outre, d’éliminer le risque de fuite de données.

… avec du BigTable dedans

Qu’en est-il de la correctitude lors de l’inférence ? BlaBlaCar dispose d’un feature store (base de données clé-valeur sur BigTable). Il constitue une projection des événements Kafka que produisent les services internes.

Lors de l’implémentation d’une nouvelle feature, trois scénarios sont possibles :

– Suffisamment d’éléments dans le feature store
Dans ce cas, on implémente, dans le service d’inférence, une fonction Java de prétraitement. Elle récupère la réponse du feature store et l’expose en tant que caractéristique. Cette dernière sera encodée sous forme d’entier et disponible dans l’événement Kafka « scoring de fraude » dès lors que le service aura été mis en prod.

– Assez de données dans les événements Kafka des services internes, mais pas disponibles dans un format adéquat au sein du feature store
Dans ce cas, on doit ajouter une fonction de prétraitement asynchrone, sous la forme d’un consommateur Kafka. Trouver la projection la plus adéquate n’est pas toujours évident. BlaBlaCar l’illustre par l’exemple d’une caractéristique contenant le nombre de messages qu’un membre a envoyés sur l’heure écoulée.

– Pas assez de données dans les événements Kafka
Il faut alors négocier, avec l’équipe responsable du service concerné, l’exposition de données. Cela peut prendre des semaines, voire des mois.

Dans tous les cas, la nouvelle caractéristique n’est disponible dans les exemples qu’une fois la fonction Java publiée. Dans la configuration la plus rapide, si un modèle est entraîné sur 30 jours de données, il faut attendre 31 jours pour entraîner un modèle sur un dataset qui, à coup sûr, contiendra dans tous ses exemples une valeur pour la nouvelle caractéristique. Pour combler ce manque pendant l’intervalle, BlaBlaCar a inclus la caractéristique et a complété les valeurs manquantes par -1. Une technique efficace aussi longtemps que le dataset d’évaluation contient des exemples complets.

Assurer la qualité des annotations

Il faut aussi s’assurer de la correctitude des annotations lors de l’entraînement. Ces annotations proviennent de 4 grandes sources :

– Examens manuels consécutifs à des tickets d’utilisateurs
– Examens manuels consécutifs à suspicion de fraude (certains sont aléatoires)
– Actions correctives (par exemple, le déblocage d’un membre bloqué par erreur)
– Règles business (essentiellement pour le monitoring, mais prises en considération dans le dataset d’entraînement en cas de manque d’annotations générées à la main)

Chaque annotation a une date et un identifiant de membre. Celles relatives à un même membre sont agrégées. Le tout est intégré dans une table qui alimente à la fois les outils de supervision et de construction des datasets. Cela évite duplications et divergences. Tout en augmentant la détection d’anomalies, tout le monde ayant la même vision de la situation. La mise à jour quotidienne de la table permet par ailleurs à BlaBlaCar d’exploiter ses outils de data quality. Tout particulièrement pour détecter les évolutions anormales de la distribution des sources d’annotations.

Illustration principale © Rafael Henrique – Adobe Stock