Comment surveiller les modèles ML sans étiquette

Chez DataDome, nous utilisons l’apprentissage automatique (machine learning, ou ML) pour enrichir nos données et prendre des décisions quant à savoir si une requête provient d’un humain ou d’un acteur malveillant. Nous avons déjà présenté quelques cas d’utilisation du ML et expliqué comment nous construisons nos ensembles de données étiquetées pour la détection des bots, ainsi que comment nous pouvons déboguer des modèles machine à l’aide de notre package récemment open source sliceline. 

Mais le cycle de vie des modèles ML ne s’arrête pas à l’entraînement. Nous devons également surveiller les performances d’un modèle après son déploiement en production. Cet article se concentre sur la surveillance des modèles de classification en temps réel, sans accès aux étiquettes.

Défis liés à la surveillance des modèles de détection de bots

Prenons par exemple le cas de la classification des requêtes en tant qu’humain ou bot en utilisant uniquement des caractéristiques sans état. Dans ce cas, la plupart des fonctionnalités disponibles – comme le User-Agent, les autres en-têtes HTTP et les empreintes digitales TLS – sont catégorielles et ont des cardinalités élevées. 

En raison de la nature contradictoire de la détection des bots, la distribution des caractéristiques peut changer très rapidement car les bots s’adaptent constamment. Il est donc fortement nécessaire de surveiller nos modèles entraînés en mode batch pour déclencher une réentraînement en cas de dérive.

On pourrait imaginer un système qui collecte des étiquettes en temps réel et calcule des données de performance telles que le ROC-AUC ou le F-score. Cependant, cela n’est pas possible dans notre cas, car nous construisons des ensembles de données avec des étiquettes qui intègrent différentes sources de vérité. En particulier, nous incorporons des informations qui ne sont disponibles que plus tard et donc nous ne pouvons pas calculer continuellement les mesures de performance (voir comment nous construisons nos ensembles de données étiquetées pour la détection des bots).

Une autre exigence est de surveiller le modèle de manière rentable, idéalement avec un seul KPI à surveiller, et de n’approfondir l’analyse que lorsque nous détectons une dégradation des performances. Comme nous voulons réagir le plus rapidement possible – et en raison du volume élevé de données que nous surveillons à l’aide d’algorithmes de traitement en flux – nous ne pouvons pas surveiller plusieurs KPI pour chaque modèle.

Gardez à l’esprit que nous utilisons des modèles arborescents boostés par le gradient car ils présentent de bonnes performances pour les données tabulaires et offrent des capacités d’inférence rapides qui nous permettent de répondre à nos exigences en matière de faible latence.

Surveillance des modèles non supervisés

Avant d’explorer différentes solutions de surveillance, définissons le concept de dérive et relions-le au problème de la détection des bots. Si nous notons X les caractéristiques et y la cible, une dérive conceptuelle survient lorsque la distribution conjointe – P(X,y) – change avec le temps. On peut décomposer la distribution conjointe de la façon suivante :

Dérive des caractéristiques

Si seulement P(X) change, alors nous parlons de dérive des caractéristiques ou de covariate shift, où la distribution des caractéristiques change mais la relation avec les étiquettes reste constante. Cela peut facilement se produire si une nouvelle version d’un navigateur a été publiée et est progressivement adoptée par les utilisateurs. La proportion de la nouvelle version du navigateur dans les valeurs des caractéristiques augmentera avec le temps. Dans le pire des cas, la nouvelle version pourrait même ne pas avoir fait partie de l’ensemble de données d’entraînement du modèle, ce qui entraînerait des échantillons hors distribution.

Dérive de concept

La dérive de concept survient lorsque la relation entre les caractéristiques et la cible—P(y|X)—change avec le temps. Par exemple, lorsqu’une entreprise de commerce électronique ouvre son activité dans un nouveau pays. Alors que le trafic provenant de ce nouveau pays pouvait être considéré comme frauduleux auparavant uniquement en se basant sur son origine géographique, cette relation n’est plus valable.

Il est pratiquement impossible de détecter une véritable dérive conceptuelle par le biais de changements dans P(y|X) sans avoir accès aux étiquettes ; c’est pourquoi nous nous concentrerons désormais sur la détection de la dérive des caractéristiques. Certains changements dans P(X) auront un impact sur les performances du classificateur et indiqueront en fait une véritable dérive conceptuelle.

Focalisation de notre surveillance

D’un point de vue conceptuel, la chose la plus simple à faire pour notre équipe serait de surveiller la distribution de toutes nos caractéristiques. Mais étant donné le grand nombre de caractéristiques, cela ne serait pas rentable. De plus, une dérive dans la distribution des caractéristiques n’induit pas nécessairement une baisse des performances du modèle.

Une autre chose à laquelle nous avons accès est la distribution des probabilités prédites par le modèle. On peut considérer la sortie du modèle comme une réduction dimensionnelle des caractéristiques. Si la distribution des sorties change, alors l’entrée doit aussi avoir changé.

Il est possible de détecter des changements dans la distribution des probabilités dans son ensemble, mais une approche plus intéressante consiste à se concentrer sur la marge. Nous nous attendons à ce que la sortie d’un classificateur binaire soit une combinaison de deux densités de probabilité :

1. Une pour la classe positive.
2. Une autre pour la classe négative. 

La marge est la région séparant les deux distributions. Intuitivement, on s’attend à ce que le classificateur soit moins certain de ses prédictions lorsque les caractéristiques changent, ce qui entraîne une augmentation de la densité de marge. En cas de changement soudain, nous pouvons également voir la densité de marge diminuer.

Marge initiale du classificateur (à gauche), augmentation de la densité de marge due à la dérive (au centre), et baisse de la densité de marge causée par une dérive soudaine (à droite). [Figure tirée de arxiv.org/abs/1704.00023.]

Il est tentant d’utiliser la densité de marge comme indicateur, car elle se concentre sur l’incertitude des prédictions du modèle. Cependant, la valeur de la probabilité prédite n’est pas toujours un indicateur de l’incertitude d’une prédiction du classificateur. 

En fait, nous avons remarqué que les classificateurs arborescents boostés par le gradient peuvent faire des prédictions très sûres (proches de 1 ou 0) pour des échantillons contenant des valeurs inédites. Le résultat réel dépend de la graine aléatoire utilisée pour entraîner le modèle. Nous avons donc besoin d’une méthode plus robuste pour estimer l’incertitude.

Une façon d’estimer l’incertitude est d’utiliser un ensemble de modèles indépendants, une méthode utilisée pour estimer l’incertitude pour les réseaux neuronaux en utilisant de couches d’exclusion. Dans notre cas, nous pouvons générer un ensemble de modèles en utilisant différentes graines aléatoires. 

Nous estimons ensuite l’incertitude comme la variance des logits des prédictions sur les différents modèles de l’ensemble. L’intuition derrière cette approche est que si les données diffèrent de ce que les modèles ont vu pendant l’entraînement, leurs prédictions seront plus diverses.

Utiliser l’incertitude pour surveiller les modèles

Pour illustrer l’idée d’utiliser l’incertitude pour surveiller les modèles de ML, nous utilisons un ensemble de modèles d’arbres à gradient boosting sur histogramme entraînés sur le jeu de données de détection d’intrusion KDD Cup 1999 (KDD99). Le jeu de données KDD99 contient trois caractéristiques catégorielles et plusieurs caractéristiques numériques pour classifier différents types d’intrusion. 

Nous avons modifié la cible pour transformer le problème en un problème de classification binaire, distinguant uniquement le trafic normal du trafic anormal. Nous nous sommes concentrés sur les échantillons hors distribution pour les données catégorielles, car ils constituent la majorité de nos ensembles de données. 

Nous avons mené l’expérience en contaminant itérativement les caractéristiques catégorielles avec des valeurs non vues lors de l’entraînement pour calculer l’incertitude des prédictions. L’expérience a simulé un environnement dans lequel de nouvelles valeurs apparaissent et se propagent progressivement. Chaque niveau de contamination représente les données à un moment différent.

Vous pouvez voir ci-dessous qu’il existe une corrélation positive entre la contamination et la moyenne de l’incertitude calculée.

Un aspect intéressant de cette approche est que l’on pourrait qualifier l’incertitude d’un modèle entraîné, puis surveiller l’incertitude en production pour détecter des déviations. Un sous-produit heureux du calcul de l’incertitude est la prévention des risques : nous pouvons décider de nous abstenir et de ne pas prendre de décision si la prédiction est incertaine.

Comme l’incertitude est calculée pour chaque échantillon, nous pouvons utiliser l’information pour approfondir et découvrir la cause première de l’augmentation de l’incertitude. Nous avons mené une expérience en utilisant sliceline et avons pu découvrir les valeurs que nous avions injectées dans le jeu de données. 

Sliceline a été initialement conçu pour trouver des segments où un modèle sous-performe. Dans ce cas, nous avons fourni le score d’incertitude au lieu de l’erreur du modèle et avons découvert les échantillons contenant les valeurs injectées.

Conclusion

Le contrôle des modèles d’apprentissage automatique sans accès aux étiquettes dans le contexte de la détection des bots est un défi particulier. Mais chez DataDome, nous l’abordons comme une excellente opportunité d’explorer différentes solutions à des problèmes complexes, et de trouver la meilleure réponse pour nos clients.

La quantification de l’incertitude joue un rôle important dans la surveillance des modèles ML et l’atténuation des risques, c’est pourquoi nous l’utilisons chez DataDome pour surveiller les performances des modèles utilisés pour l’enrichissement des données. Nous sommes également en train de l’implémenter dans nos modèles à faible latence utilisés directement pour la détection des bots.