Évaluer sous dérive de distribution

L’évaluation estime un système sous une distribution, un seuil, un workflow et un coût donnés ; elle ne lui attribue pas un score permanent.

$$R_Q(f)=\mathbb{E}_{(x,y)\sim Q}[\ell(f(x),y)].$$

La moyenne test estime ce risque seulement si test approche $Q$, reste hors développement et utilise les bons labels/pertes. Un intervalle iid étroit n’inclut pas une dérive future inconnue.

Décrire modèle + prétraitement + seuil + humain, unité, population, prediction time, horizon, action et coûts d’erreur/abstention. Si l’action change les données futures, le test statique n’évalue pas la boucle de feedback.

Shift	Changement	Exemple	Limite
covariate	$p(x)$	appareil, région, saison	drift de X ne prouve pas $p(y\mid x)$ stable
prior	$p(y)$	prévalence	labels ou hypothèses nécessaires
concept	$p(y\mid x)$	politique change	difficile sans labels
mesure	processus d’enregistrement	capteur/codage	ressemble à un changement réel
sélection	mécanisme d’inclusion	seuls cas revus labellisés	test représente les sélectionnés

Random holdout répond au même régime ; group holdout aux nouvelles entités ; forward test au futur historique ; validation externe à un autre site ; nested CV sépare sélection et estimation. Aucun ne répond à tout. Regarder test de façon répétée le transforme en validation.

Métriques

Accuracy suit la prévalence. Precision/recall dépendent du seuil et de la base. ROC-AUC mesure un rang, pas un seuil. PR-AUC a une baseline liée à la prévalence. Log loss, Brier et calibration posent d’autres questions. En régression, MAE/RMSE pèsent différemment les queues ; les pourcentages échouent près de zéro ; quantile loss cible un quantile. Choisir selon action et coût, non selon leaderboard.

Exemple : 1 % de fraude

Sur 10 000 transactions dont 100 fraudes, toujours répondre normal donne 99 % accuracy et 0 recall. Si un seuil signale 200 cas dont 60 fraudes : precision=30 %, recall=60 %. L’utilité dépend encore du coût de 200 revues, des 40 fraudes manquées, de la friction, du retard des labels et de la prévalence future. Choisir le seuil sur validation puis tester plus tard.

Incertitude

1. échantillon test : intervalle bootstrap/analytique, cluster ou block si dépendance ;
2. entraînement : seeds, ordre, kernels non déterministes ;
3. environnement : politique, comportement, capteur, population, souvent absent de l’intervalle iid.

Rapporter dénominateurs, tailles de slices et runs ratés. Préspécifier les slices à risque ; trop de slices post-hoc demandent confirmation. Une zone d’abstention ajoute capacité et biais des réviseurs au système ; confiance n’est pas calibration, surtout sous shift.

Comparer constantes, saisonnalité, règles métier et modèles simples ; retirer features suspects ; stresser temps, bruit, manque, longueur, langue, appareil et nouveaux sites ; contrôler paramètres, données et budget dans les ablations.

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: [...]
known_failures_and_out_of_scope: [...]
monitoring_and_revalidation_trigger: ...

Les benchmarks publics facilitent la comparaison mais invitent l’overfit à des tâches, langues et métriques fixes. Les tests internes correspondent mieux à l’usage mais peuvent manquer d’audit. Model Cards et NIST AI RMF posent des questions ; ils ne certifient ni sûreté ni équité. Causalité, A/B, RL, génération ouverte et collaboration humain–IA exigent d’autres estimands.