Évaluer un modèle sous dérive de distribution
L’évaluation estime le comportement d’un système pour une distribution cible, un seuil, un workflow et un coût d’erreur donnés ; elle ne lui attribue pas un score permanent.
Pour une distribution de déploiement et une perte :
Une moyenne sur le jeu de test n’estime ce risque que si ce jeu approche , reste en dehors du développement et utilise les bons labels et la bonne perte. Un intervalle iid étroit ne couvre pas une dérive future inconnue.
Voir l’image en grandChaque point bleu représente un modèle : l’abscisse donne sa précision sur le test original, l’ordonnée celle sur de nouvelles données. Les points sous la diagonale en tirets indiquent une baisse, malgré la forte relation entre les scores décrite par la droite rouge. Les panneaux concernent CIFAR-10 et ImageNet ; les barres donnent des intervalles de Clopper–Pearson à 95 %. Un classement globalement préservé peut donc accompagner une baisse systématique des performances absolues.
Définir l’objet évalué
system model + preprocessing + threshold + human process
unit one prediction object
population people/time/place to which results extend
prediction_time information available then
outcome_horizon label window and maturity
action what the prediction triggers
loss false-positive, false-negative, delay, and abstention cost
Si l’action modifie les données futures, un test statique évalue la politique avant déploiement, pas la boucle de rétroaction.
Types de dérive
Ces dérives peuvent se chevaucher. Une dérive des entrées ne garantit pas une perte de performance, et l’absence de dérive détectée ne garantit pas la sûreté.
Le modèle strict de dérive des covariables suppose que change et que reste fixe. Le changement pur de labels modifie tout en conservant . Ce sont des hypothèses, pas des conclusions tirées d’un histogramme des entrées. Sous dérive des covariables, pondérer les erreurs source par n’estime le risque cible que si la source couvre le support cible ; des poids élevés rendent aussi l’estimation bruitée. La pondération ne crée pas de preuves pour des régions jamais observées.
Les splits répondent à des questions différentes
Consulter le jeu de test à répétition, ne publier que le meilleur seed ou ajuster le système à un benchmark externe transforme le test en validation.
Les métriques répondent à des questions différentes
L’accuracy dépend de la prévalence des classes. La précision et le rappel dépendent du seuil. Sous un pur changement d’a priori, à distributions de scores conditionnelles aux classes fixes, le rappel reste constant mais la précision change avec la prévalence. ROC-AUC mesure un classement, pas un point de fonctionnement. PR-AUC met l’accent sur les positifs, mais sa référence dépend de la prévalence. La log loss et le score de Brier évaluent différemment la qualité des probabilités. La calibration dépend de la distribution et de l’échantillon.
Pour la régression, MAE et RMSE pondèrent différemment les valeurs extrêmes ; les erreurs en pourcentage peuvent échouer près de zéro ; la perte quantile vise des quantiles conditionnels. Les métriques de classement décrivent un protocole de classement, pas l’utilité en aval. Choisissez les métriques selon les actions et les coûts d’erreur, pas selon les habitudes des classements publics.
Exemple : 1 % de fraude
Parmi 10 000 transactions, 100 sont frauduleuses. Toujours prédire « normal » donne 99 % d’accuracy et un rappel nul. Supposons qu’un seuil signale 200 transactions, dont 60 réellement frauduleuses :
precision = 60 / 200 = 30%
recall = 60 / 100 = 60%
Si aucun cas n’est signalé, la précision est indéfinie car son dénominateur est nul ; si un sous-groupe de test ne contient aucun positif, le rappel est indéfini. Signalez ces cas plutôt que de les assimiler implicitement à des prédictions réussies.
L’utilité dépend aussi du coût des 200 contrôles, des 40 fraudes manquées, de la friction imposée aux clients, du retard des labels et de la prévalence du mois suivant. Choisissez le seuil sur le jeu de validation, puis évaluez-le sur un test ultérieur ; choisir et publier le seuil sur le même jeu de test produit une estimation optimiste.
Le taux de faux positifs vaut ici . Pour une prévalence , un taux de vrais positifs et un taux de faux positifs ,
Si la prévalence atteint 5 % à taux conditionnels fixes, la précision attendue passe à environ 69,1 % et le rappel reste à 60 %. C’est un calcul sous changement d’a priori, pas une prévision de stabilité des taux conditionnels. Voir les définitions des métriques de scikit-learn.
Pour un seuil opérationnel, supposons que soit une probabilité de fraude calibrée, qu’une fausse alerte coûte , qu’une fraude manquée coûte et qu’une décision correcte ne coûte rien. Signalez si , soit . Les capacités limitées ou des coûts d’examen non nuls modifient ce problème ; une ROC-AUC ne peut choisir seule le seuil.
Trois niveaux d’incertitude
- Échantillon d’évaluation : intervalles analytiques ou bootstrap ; conservez l’appariement pour comparer des modèles sur les mêmes cas, et rééchantillonnez par groupe ou par bloc en présence de dépendance de groupe ou de temps.
- Aléa d’entraînement : initialisation, ordre des données et kernels non déterministes ; répétez plusieurs seeds.
- Environnement : politiques, comportements, capteurs et populations futurs ; les intervalles iid l’ignorent généralement.
Publiez les dénominateurs, le nombre d’éléments par slice, les exécutions échouées et la source d’incertitude représentée par chaque intervalle.
Slices, seuils et abstention
Les métriques globales peuvent masquer des échecs par groupe, appareil, langue, période ou niveau de difficulté. Définissez à l’avance les slices liés aux risques ; multiplier les slices après coup crée des effets de sélection qui doivent être confirmés. Dans les systèmes à fortes conséquences, le modèle peut s’abstenir ou transmettre le cas à un humain, mais la compétence des réviseurs, la capacité de la file et le biais de sélection font alors partie du système. La confiance n’est pas automatiquement une probabilité calibrée, surtout sous dérive.
Baselines et tests de résistance
Utilisez des constantes, des règles saisonnières, les processus métier et des modèles simples ; retirez les features suspectes ; testez le temps, le bruit, les valeurs manquantes, la longueur, la langue et l’appareil ; essayez de nouvelles cohortes ou de nouveaux sites ; vérifiez les entrées invalides et les chemins de refus ; comparez les architectures à nombre de paramètres, volume de données et budget d’entraînement contrôlés.
intended_decision: ...
target_population_and_period: ...
prediction_time_and_horizon: ...
data_version_and_split: ...
baselines: [...]
selection_metric: ...
final_metrics_and_thresholds: ...
uncertainty: sample, seed, environment
slices_and_minimum_counts: [...]
leakage_and_contamination_checks: [...]
resource_and_latency_budget: ...
known_failures_and_out_of_scope: [...]
monitoring_and_revalidation_trigger: ...
Les benchmarks publics facilitent la comparaison, mais encouragent le surapprentissage de tâches, de langues, de matériels et de critères de réussite fixes. Les tests internes correspondent mieux à l’usage réel, mais peuvent être petits et non audités. Les Model Cards et le NIST AI RMF fournissent des questions de reporting ; ils ne certifient ni la sûreté ni l’équité.
Cette note concerne la prédiction supervisée. Les effets causaux, les tests A/B, les politiques d’apprentissage par renforcement, la génération ouverte et la collaboration humain–IA exigent d’autres estimands et d’autres dispositifs expérimentaux.