La surveillance de production IA est l’observation continue et échantillonnée des intrants, de la configuration, des sorties, de l’interaction utilisateur, des corrections humaines, des effets en aval, de la fiabilité, des coûts et des risques. Elle relie télémétrie opérationnelle, évaluations propres au produit et contrôles d’incident. Elle vise à détecter un comportement ne répondant plus à l’usage, la distribution ou l’acceptation approuvés et à soutenir investigation, confinement, retour arrière et amélioration.
Les tableaux de service peuvent rester verts pendant que le comportement se dégrade. Les requêtes réussissent, mais les sources changent, un prompt modifie le périmètre, les utilisateurs remplacent les recommandations, une langue échoue ou une politique amont bouge. La vérité arrive tard ou jamais. Tout journaliser crée un risque de confidentialité, trop peu empêche la reconstruction. Un score agrégé cache les échecs graves d’une minorité et l’équipe ne sait pas si modèle, données, orchestration, utilisateurs ou processus ont changé.
Surveillez le chemin de décision complet proportionnellement à la conséquence. Tracez versions et caractéristiques utiles sans recueillir de contenu inutile. Associez indicateurs opérationnels, contrôles automatiques, revue humaine d’échantillons et résultats. Définissez échecs critiques et autorité avant la sortie. La dérive invite à diagnostiquer et n’est pas un verdict. Conservez des bases comparables, enquêtez par segment et revenez en arrière lorsque la preuve franchit un seuil nommé.
Conception des traces
Tracer la décision sans tout journaliser
Cartographiez la demande jusqu’à la conséquence: préparation, routage, sources, prompt, modèle, paramètres, outils, politique, post-traitement, sortie affichée, action utilisateur et système en aval. Tous les systèmes n’emploient pas chaque couche. Versionnez les composants et corrélez les événements afin de reconstruire le comportement. La version du modèle ne suffit pas lorsque filtres, instructions système ou schéma d’outil modifient matériellement la réponse.
Appliquez la minimisation à l’observabilité. Déterminez quels intrants ou sorties peuvent être retenus, pour quel but, combien de temps, avec quel accès et quelle occultation. Là où le contenu ne peut rester, préservez attributs dérivés, références, échantillons consentis ou capture sécurisée suffisante pour l’enquête approuvée. Documentez l’impossible à reconstruire. Séparez journaux opérationnels et preuve d’audit restreinte. La surveillance n’autorise pas à conserver tout ce que l’utilisateur soumet.
| Couche | Trace utile | Question |
|---|---|---|
| Intrant | Source, format, segment, échantillon permis | Peut-on conserver? |
| Orchestration | Route, prompt, recherche, politique | Peut-on reproduire? |
| Modèle et outils | Version, paramètres, appels, résultats | Qui a agi? |
| Sortie | Décision, références, repli, échantillon | Qu’a vu l’utilisateur? |
| Humain | Accepter, éditer, remplacer, escalader | Quelle autorité reste? |
| Aval | Résultat métier ou sécurité | Quand la vérité arrive? |
Qualité
Associer proxys rapides et vérité produit plus lente
Les indicateurs rapides incluent disponibilité, latence, reprises, repli, nombre de sources, erreur d’outil, structure valide et coût. Des assertions déterministes détectent format interdit, citation absente, schéma ou règle. Les évaluateurs modèles fournissent des signaux pour des dimensions validées. Aucun ne prouve automatiquement la bonne décision utilisateur. Calibrez chaque proxy face à une revue compétente et aux résultats, et surveillez le proxy lorsque modèle ou politique change.
Échantillonnez le comportement pour une revue structurée. Le hasard estime la qualité ordinaire; le ciblage couvre segments critiques, nouvelles versions, confiance faible, plaintes, remplacements et intrants inhabituels. Conservez le plan pour ne pas rapporter ces cas comme fréquence. Employez le même contrat et la même taxonomie que hors ligne et ajoutez les nouveaux échecs. Lorsque la vérité arrive tard, reliez-la prudemment: seules certaines recommandations sont suivies et les résultats observés forment un sous-ensemble biaisé.
- Utiliser les signaux opérationnels pour la vitesse, pas comme preuve.
- Valider les évaluateurs automatiques contre des humains compétents.
- Combiner échantillons aléatoires et défis ciblés.
- Rapporter les échecs graves séparément de la qualité agrégée.
- Tenir compte du délai et de la sélection dans les résultats.
Changement
Traiter la dérive comme question système
Comparez caractéristiques d’intrants, mix de tâches, langues, sources, formats, utilisateurs, corpus, attributs de sortie, interventions et qualité à la base approuvée. Choisissez des caractéristiques liées au comportement et mesurables légitimement. Un changement statistique invite à enquêter sans être automatiquement nocif. Un trafic saisonnier peut être attendu; un agrégat stable peut cacher une dégradation dans un segment important.
Enquêtez par couches. Le trafic a-t-il changé? Un prompt, modèle, embedding, index, outil, politique ou écran a-t-il été déployé? Une source amont a-t-elle changé? Les relecteurs ont-ils de nouvelles règles? La métrique reste-t-elle stable? Reproduisez les traces permises et rejouez la régression protégée. Comparez le retour ou l’ajustement sur les mêmes cas. Enregistrez hypothèse et preuve. Ne dites pas “dérive du modèle” lorsque la cause est une source obsolète ou une règle métier.
| Signal | Couches possibles | Premier comparatif |
|---|---|---|
| Qualité en baisse | Modèle, prompt, recherche, trafic, politique | Segment et version |
| Plus de remplacements | UI, confiance, tâches, réponses | Échantillon motivé |
| Latence en hausse | Modèle, outils, file, longueur | Trace composant |
| Coût en hausse | Volume, jetons, reprises, route | Coût par tâche |
| Citation absente | Recherche, corpus, génération, affichage | Trace source |
| Nouvel échec grave | Politique, distribution, dépendance | Cas incidents |
Boucle de contrôle
Prédéfinir le confinement et transformer les incidents en contrôles
Fixez les seuils selon la conséquence et non seulement la fréquence. Une divulgation restreinte peut exiger un confinement immédiat, une préférence de style non. Nommez qui peut limiter le trafic, augmenter la revue, désactiver une action ou un outil, choisir une route sûre, restaurer prompt ou modèle ou arrêter la fonction. Conservez configuration et preuves, informez les responsables et communiquez l’incertitude. Le retour arrière doit être testé avant sortie et couvrir données et index, pas uniquement le code.
Après confinement, vérifiez le rétablissement sur incidents, régression et échantillons vivants. Identifiez les contrôles contributeurs sans réduire la cause à l’opérateur. Actualisez surveillance, limites, tests, procédures et aide utilisateur. Un cas de production n’entre dans l’évaluation qu’après droits, provenance, doublons et partitions. Suivez la récidive et les risques créés par la correction. La surveillance est complète lorsqu’elle permet réaction et apprentissage gouvernés, pas lorsqu’elle produit le plus grand tableau.
- Fixer les seuils selon la conséquence.
- Nommer l’autorité pour périmètre, revue et retour.
- Tester le retour sur modèles, prompts, données et outils.
- Vérifier le rétablissement sur cas incidents et représentatifs.
- Gouverner l’ajout de preuves de production aux évaluations.
Ce qui caractérise un bon résultat
Résultats concrets pour surveiller IA en production
- Chaque sortie conséquente est liée aux versions modèle, prompt, recherche, outil et politique.
- Les changements d’intrants sont visibles par segment sans journal sensible inutile.
- La qualité combine tests automatiques, échantillons revus et preuves en aval.
- Les échecs critiques, abstentions, escalades et remplacements sont séparés.
- Les équipes distinguent modèle, recherche, outil, données, interface et politique.
- Coût et latence sont évalués avec la qualité et non isolément.
- Des seuils déclenchent confinement, communication et retour arrière nommés.
- Les cas de production revus actualisent évaluations et contrôles sous version.
Modèle opératoire
Comment exécuter le travail
- 01
Définir le chemin surveillé
Cartographiez intrants, préparation, recherche, prompts, modèles, outils, politiques, sorties, actions humaines et systèmes en aval. Classez conséquence, réversibilité et confidentialité et choisissez le minimum nécessaire.
- 02
Instrumenter versions et opérations
Enregistrez versions de déploiement, latence, erreurs, reprises, résultats d’outils, jetons ou calcul, repli, abstention et file. Préservez la corrélation et les événements d’audit protégés.
- 03
Mesurer le comportement par segment
Exécutez les assertions valides, échantillonnez pour revue qualifiée et reliez les résultats tardifs. Rapportez qualité, échecs graves et interventions par langue, source, utilisateur, complexité et segment approuvé.
- 04
Détecter et investiguer le changement
Comparez distributions d’intrants, sorties et opérations avec la base. Lorsqu’un signal bouge, testez modèle, prompt, recherche, données, outils, politique, trafic et relecteurs avant attribution.
- 05
Contenir, apprendre et mettre à jour
Limitez le périmètre, augmentez la revue, désactivez un outil, choisissez une route sûre, restaurez la configuration ou arrêtez. Gardez les preuves, vérifiez le retour et ajoutez les cas aux évaluations sous contrôle.
Évaluation
Les questions qui changent la décision
- Quelles décisions et conséquences justifient la surveillance?
- Quel minimum de données permet d’enquêter sans rétention inutile?
- Quelles versions système et politique associer à chaque sortie?
- Quels contrôles automatiques sont des proxys et lesquels exigent un humain?
- Quels segments révèlent le dommage caché par l’agrégat?
- Quels résultats arrivent tard, avec ambiguïté ou biais de sélection?
- Quel seuil déclenche enquête, revue accrue, retour ou arrêt?
- Qui peut contenir le système et accepter le risque résiduel?
Modes d’échec
Où les équipes perdent le contrôle
Disponibilité et taux d’erreur peuvent être confondus avec justesse.
Les journaux complets peuvent exposer contenu personnel ou confidentiel.
La suppression d’attributs peut empêcher reproduction ou analyse des groupes.
Un juge automatique peut dériver ou partager les angles morts.
Les pouces utilisateurs peuvent surreprésenter les cas faciles.
Un remplacement humain peut être pris pour une erreur sans comprendre le travail.
Un changement de distribution peut être attribué au modèle plutôt qu’au trafic.
Des alertes bruyantes peuvent rendre les opérateurs insensibles.
L’optimisation des coûts peut réduire silencieusement la qualité.
Des échecs peuvent contaminer le benchmark sans revue des droits.
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.
- sorties traçables aux versions système et politique
- volume et distribution des intrants par segment
- qualité avec incertitude sur échantillons revus
- nombre d’échecs critiques et exposition
- abstention, repli, escalade et remplacement humain
- échec de recherche, outil et dépendance
- latence et coût unitaire avec qualité
- précision des alertes et temps d’enquête
- réussite du retour arrière et récidive
- cas de production incorporés aux évaluations gouvernées
Questions
Questions fréquentes
Que faut-il surveiller pour une IA en production?
Versions, mix des intrants et tâches, fiabilité, latence, coût, recherche et outils, qualité par segment, échecs graves, abstention, escalade, corrections humaines et résultats pertinents.
Peut-on surveiller automatiquement la qualité IA?
Seulement certaines dimensions. Les contrôles automatiques donnent des signaux rapides, mais doivent être validés et associés à une revue compétente et aux preuves du vrai résultat produit.
Qu’est-ce que la dérive d’un modèle IA?
Le terme couvre un changement dégradant le comportement, mais la cause peut être intrants, modèle, données, prompt, outils, politique ou utilisateurs. Traitez le signal comme une enquête par couches.
Faut-il toujours journaliser prompts et sorties?
Non. La rétention suit but, permission, sensibilité et minimisation. Employez échantillons restreints ou attributs dérivés lorsque le contenu complet crée un risque disproportionné.
Sources
Sources primaires
- Artificial Intelligence Risk Management Framework 1.0 National Institute of Standards and Technology
- AI test, evaluation, validation and verification 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→