La dérive d’un modèle est une évolution matérielle de son comportement ou de sa performance observée par rapport à une baseline, une attente ou une limite d’exploitation approuvée. Elle peut provenir des populations d’entrée, de la relation entre données et résultat, du produit, des sources en amont, d’un fournisseur, des prompts, des outils ou du modèle. La dérive des données décrit un changement de distribution. La dérive conceptuelle décrit une nouvelle relation entre les informations et la cible. La dégradation de performance est un résultat, pas un diagnostic. Les équipes doivent définir leurs termes car les disciplines les emploient différemment.
Un modèle peut continuer à produire un JSON valide tout en devenant moins utile, équitable ou fiable. La vérité terrain arrive parfois plusieurs semaines plus tard, les erreurs graves sont rares et la moyenne reste stable alors qu’un segment se dégrade. Dans un produit génératif, une mise à jour fournisseur, un nouvel index, un prompt ou une réponse d’outil peut modifier le comportement même si la version affichée paraît identique. Alerter sur toute différence crée du bruit; suivre uniquement la disponibilité ignore l’échec sémantique. Sans baseline, seuil et responsable, la dérive devient une explication après incident plutôt qu’un signal maîtrisé.
Surveillez la décision ou la tâche de bout en bout, pas seulement l’endpoint du modèle. Établissez les baselines avant publication, segmentez selon les conséquences et combinez indicateurs avancés, résultats retardés et retours humains. Une alerte ouvre un diagnostic; elle ne prouve pas une défaillance et n’impose pas le réentraînement. Contenez d’abord les effets nocifs, localisez le composant modifié, puis choisissez entre données, prompt, recherche, règle, fournisseur, poids ou périmètre. Versionnez le système complet pour reproduire l’attendu et l’observé.
Types de dérive
Une distribution différente est un indice, pas la cause
La dérive des données apparaît quand changent population, langue, appareil, type de document ou distribution des attributs. La dérive conceptuelle survient lorsque la relation entre information et résultat correct évolue, par exemple avec une fraude ou une politique nouvelle. Une baisse peut aussi venir d’un champ absent, d’un parser cassé, d’une recherche périmée, d’instructions modifiées ou d’une règle aval. Ces causes appellent des remèdes distincts. Réentraîner ne répare ni une source vide ni une permission erronée.
Les produits génératifs élargissent l’observation. Suivez ancrage factuel, validité des citations, schémas, choix d’outil, tâche accomplie, corrections et escalades avec latence et coût. La qualité libre ne se réduit pas toujours à un score automatique; ajoutez une revue humaine structurée et des résultats réels. Définissez la matérialité avant que le signal ne bouge et conservez les cas qui expliquent le franchissement du seuil.
| Observation | Cause possible | Premier contrôle |
|---|---|---|
| Distribution modifiée | Population ou source | Intégrité source et cohorte |
| Relation résultat modifiée | Concept ou politique | Vérité terrain récente |
| Qualité changée après release | Version modèle ou prompt | Trace déploiement |
| Citations dégradées | Recherche ou index | Couverture et classement |
| Échecs outils en hausse | Contrat ou dépendance | Logs typés et API |
Conception de la réponse
Contenir la conséquence avant d’optimiser le modèle
Un seuil d’action doit correspondre à une réponse préparée. Un changement faible peut ouvrir une analyse; un échec lourd peut exiger abstention, revue humaine, réduction du trafic ou retour arrière. Gardez un groupe de comparaison stable si possible et vérifiez que le monitoring lui-même est actuel. Enregistrez versions, cohortes et exemples avant de modifier plusieurs composants. Sinon la performance revient sans que l’équipe sache pourquoi elle avait bougé.
Le playbook NIST AI RMF recommande de surveiller le fonctionnement en production et de comparer les indicateurs opérationnels aux mesures avant déploiement. Il note que l’évolution du contexte peut invalider les hypothèses et évoque distributions, anomalies, revue humaine et nouvelle vérité terrain. Utilisez ce cadre pour la gouvernance, pas comme un détecteur universel. Chaque produit doit définir ses mesures, plages acceptables, responsables et règles d’intervention.
- Établir la baseline du produit complet.
- Segmenter par conséquence et pas seulement volume.
- Observer la santé du monitoring.
- Diagnostiquer avant de réentraîner.
- Tester confinement et retour avant incident.
Ce qui caractérise un bon résultat
Résultats concrets pour dérive modèle IA
- Chaque tâche critique possède une baseline approuvée et un responsable.
- Entrées, comportement et résultats réels sont mesurés par segment utile.
- Les seuils reflètent les conséquences et la variation naturelle.
- Les alertes portent assez de contexte pour le diagnostic et le triage.
- Les réponses incluent confinement, retour et abstention avant réentraînement.
- Les cas réels enrichissent l’évaluation sous une gouvernance explicite.
Modèle opératoire
Comment exécuter le travail
- 01
Définir le fonctionnement attendu
Documentez utilisateurs, contextes, plages de données, résultats, limites et échecs matériels. Mesurez avant publication la performance et l’incertitude par segment, avec la recherche et le workflow environnants.
- 02
Instrumenter signaux et résultats
Mesurez distributions, valeurs absentes, santé des sources, versions, qualité de recherche, validations échouées, corrections humaines et résultats métier ultérieurs. Protégez la vie privée et collectez avec un objectif.
- 03
Fixer les seuils et trier
Définissez niveaux d’avertissement et d’action selon variance, volume et conséquence. À l’alerte, vérifiez l’intégrité des données, comparez les cohortes et examinez des cas avant d’attribuer la cause au modèle.
- 04
Contenir, corriger et apprendre
Réduisez l’exposition par fallback, abstention, revue humaine ou retour. Corrigez le composant responsable, rejouez la régression et publiez progressivement. Ajoutez les nouveaux cas confirmés à l’évaluation gouvernée.
Évaluation
Les questions qui changent la décision
- Quel comportement représente la valeur et lequel un dommage matériel?
- Quelle période, quelles données et quelle configuration forment la baseline?
- Quels segments peuvent se dégrader sous une moyenne apparemment saine?
- Quand la vérité terrain arrive-t-elle et quel proxy utiliser jusque-là?
- Quel seuil demande enquête, confinement ou arrêt?
- Peut-on attribuer le changement aux données ou aux dépendances avant réentraînement?
Modes d’échec
Où les équipes perdent le contrôle
Une saisonnalité normale est interprétée comme une dérive.
Une distribution stable masque une relation différente avec le résultat.
Une moyenne cache une dégradation grave pour un petit groupe.
Une version de modèle, prompt ou recherche manque dans la trace.
Le pipeline de monitoring fournit des valeurs rassurantes mais anciennes.
Le réentraînement automatique amplifie une boucle ou de mauvais labels.
Mesure
Mesurer le travail terminé
La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.
- succès de tâche et erreurs matérielles face à la baseline
- évolution des entrées, sorties et résultats par cohorte
- temps du signal au triage, confinement et rétablissement
- alertes confirmées, rejetées et manquées après incident
- taux de correction humaine, abstention et fallback
- couverture de trace des versions modèle, prompt, source et outil
Questions
Questions fréquentes
Qu’est-ce que la dérive d’un modèle IA?
C’est une évolution matérielle du comportement ou de la performance par rapport à une baseline ou une limite approuvée. Données, concepts, système, dépendances ou modèle peuvent en être la cause.
Quelle différence entre dérive des données et du modèle?
La première décrit une distribution différente. La seconde désigne souvent plus largement un comportement modifié. Une distribution peut changer sans baisse, et la qualité peut baisser sans shift évident.
Comment détecter la dérive d’un modèle?
Comparez entrées, comportements et résultats aux baselines versionnées, par risque et usage. Combinez statistiques, validation, vérité terrain retardée, revue humaine structurée et surveillance du monitoring.
La dérive exige-t-elle toujours un réentraînement?
Non. La cause peut être une source, un prompt, un index, un outil, une règle ou le produit. Contenez les effets, diagnostiquez le composant puis appliquez la plus petite correction étayée.
Sources
Sources primaires
- AI RMF Playbook: Measure National Institute of Standards and Technology
- Artificial Intelligence Risk Management Framework 1.0 National Institute of Standards and Technology
À propos de l’auteur
Tony Kim
Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.
Zeke
Ingénierie de produits IA pour transformer un cahier des charges en produit fiable en production.
Directions produit, fondateurs et équipes d’ingénierie. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.
Découvrir Zeke→