Model Monitoring

La surveillance des modèles consiste à mesurer en continu les entrées, les sorties, les performances et l'état de service d'un modèle d'apprentissage automatique déployé, avec des alertes lorsque l'un de ces éléments sort de la plage attendue. Les défaillances des modèles passent généralement inaperçues : un détecteur continue de produire des boîtes avec des scores de confiance plausibles après le déplacement d'une caméra, l'encrassement d'un objectif ou la refonte d'un produit ; seule sa précision change. La surveillance compare le comportement en direct à une référence, généralement les données de validation sur lesquelles le modèle a été approuvé. Les équipes découvrent ainsi la dérive des données et la baisse de précision dans des tableaux de bord plutôt qu'auprès des utilisateurs. Elle boucle le processus d'ingénierie du machine learning (MLOps) après le déploiement du modèle et détermine quand le modèle doit être réentraîné.

Éléments à surveiller#

La surveillance en production couvre généralement quatre couches :

• Latence d'inférence et état du service : taux de requêtes, taux d'erreur, latence p95 et p99, ainsi que mémoire et utilisation du GPU, souvent collectés avec Prometheus et présentés dans Grafana.
• Données d'entrée : violations de schéma, valeurs manquantes et changements dans les statistiques des caractéristiques ou des images, comme la luminosité, la résolution ou la taille des objets.
• Confiance des prédictions et répartition des sorties : répartition des classes, détections par image et scores de confiance. Un changement à ce niveau, appelé dérive des prédictions, constitue un signal d'alerte précoce avant la disponibilité des étiquettes.
• Performances du modèle : précision, précision positive, rappel ou mAP, calculés lorsque la vérité terrain est disponible. Les étiquettes de fraude peuvent arriver plusieurs semaines plus tard sous la forme de rétrofacturations, et les équipes de vision étiquettent manuellement un échantillon d'images de production.

Ultralytics Platform intègre la couche de prédiction à ses points de terminaison dédiés : l’onglet Monitoring affiche la distribution de confiance d’un modèle YOLO déployé, la confiance moyenne au fil du temps, les principales classes et le nombre de prédictions par image ; les images récentes peuvent être enregistrées avec leurs prédictions dans un jeu de données pour examen et réentraînement. Le guide de surveillance et de maintenance des modèles et la leçon de l’Ultralytics Academy Observabilité et dérive expliquent les vérifications de dérive pour les déploiements YOLO.

Deux types de changements sont à l'origine de la plupart des dégradations. La dérive des données, également appelée décalage de covariables, modifie les entrées, par exemple lorsque la caméra d'inspection d'une ligne de fabrication est déplacée ou que l'éclairage change. La dérive conceptuelle modifie la relation entre les entrées et les bonnes réponses, par exemple lorsque les fraudeurs changent de tactique et que des transactions autrefois normales deviennent frauduleuses. Les statistiques des entrées révèlent directement la dérive des données, tandis que la dérive conceptuelle n'apparaît dans les métriques de performance qu'une fois les étiquettes disponibles. Ces deux phénomènes comptent parmi les causes les plus courantes de défaillance des modèles de vision par ordinateur en production.

Détecter la dérive#

Un contrôle courant de la dérive compare la distribution d'une statistique en temps réel à la référence à l'aide d'un test de Kolmogorov-Smirnov à deux échantillons, qui mesure l'écart maximal entre deux distributions cumulées. Ce script l'applique à des scores de confiance de détection simulés : un échantillon de référence issu de la validation, une semaine de production qui lui correspond et une semaine dont les scores sont plus faibles :

import numpy as np
from scipy.stats import ks_2samp

rng = np.random.default_rng(0)

# Detection confidences logged at validation time form the reference distribution
reference = rng.beta(8, 2, size=2000)

# Two simulated production windows: one like the reference, one shifted lower
windows = {"week 1": rng.beta(8, 2, size=500), "week 2": rng.beta(5, 3, size=500)}

for name, live in windows.items():
    # Two-sample Kolmogorov-Smirnov test: do both samples come from one distribution?
    result = ks_2samp(reference, live)
    drift = result.pvalue < 0.01
    print(f"{name}: mean {live.mean():.2f}, KS {result.statistic:.3f}, p {result.pvalue:.1e}, drift {drift}")

La semaine 1 passe le test, avec une statistique KS de 0,037 et une valeur p = 0,64. En semaine 2, la confiance moyenne tombe à 0,63, contre 0,80 en semaine 1, et une statistique KS de 0,456 avec p = 1,2e-75 signale une dérive. Avec plusieurs milliers d'échantillons, même des changements inoffensifs deviennent statistiquement significatifs ; les contrôles en production déclenchent donc souvent une alerte lorsque la statistique KS ou l'indice de stabilité de la population (PSI) dépasse un seuil fixe. Des bibliothèques open source comme Evidently et NannyML regroupent ces tests dans des rapports de dérive. NannyML estime aussi la précision d'un classifieur sans étiquettes à partir de ses scores de confiance calibrés. Amazon SageMaker Model Monitor et Vertex AI Model Monitoring proposent les mêmes contrôles sous forme de services gérés. Une alerte déclenche alors une enquête :

Surveillance, observabilité et évaluation#

• Observabilité : les journaux, les traces et les entrées stockées qui expliquent le déclenchement d'une alerte. La surveillance exécute des contrôles prédéfinis ; de nombreux fournisseurs proposent les deux sous la forme d'une observabilité du machine learning.
• Évaluation du modèle : mesure les scores d'un modèle sur un jeu de test mis de côté avant sa publication. La surveillance répète cette mesure sur le trafic en direct tant que le modèle est en service.
• Suivi des expériences : enregistre les exécutions d'entraînement pendant le développement, avant que des données de production ne soient disponibles.