Surveillance continue, observabilité et dérive — Sécurité et gouvernance d'entreprise

Gains :

Capacité à définir des métriques qui surveillent les signaux d'utilisation, de sécurité, de qualité et de performance
Capacité à détecter la dérive de la qualité de sortie avec la ligne de base et l'échantillonnage
Possibilité de définir une alarme et une boucle de rétroaction pour les anomalies et les vagues de jailbreak

La mise en production d’un système d’IA est le début, pas la fin. Même si le modèle reste le même, le monde change : le comportement des utilisateurs, les données entrantes, les techniques d'attaque et le contexte commercial évoluent constamment. La bonne réponse d’hier peut être fausse aujourd’hui. Le dernier pilier de la sécurité est donc la surveillance continue et l'observabilité, c'est-à-dire la capacité de voir de l'extérieur ce qui se passe à l'intérieur du système. Dans cette unité, nous apprendrons quelles métriques surveiller, comment capturer la dérive de la qualité de sortie et comment alerter en cas d'anomalies.

Pourquoi une surveillance continue ?

Dans un logiciel classique, « est-ce que ça marche » est une question binaire : soit il répond, soit il ne répond pas. En IA, même si le système semble « fonctionner », il peut se détériorer silencieusement : les réponses deviennent peu à peu inexactes, les coûts augmentent, les tentatives de jailbreak se multiplient. La seule façon de les capturer est de mesurer constamment les bons signaux.

Attention : Le dysfonctionnement le plus dangereux est le dysfonctionnement silencieux, pas le dysfonctionnement bruyant. Le système ne génère pas d'erreurs, sa qualité diminue simplement. Si vous ne mettez pas en place de surveillance, la première personne à le remarquer sera votre client ou auditeur, et non vous.

Quatre familles de signaux à surveiller

Utilisation et coût : volume de requêtes, consommation de jetons, coût par utilisateur. Saut soudain ; Cela peut être le signe d'un abus, d'une intégration en boucle ou d'un commutateur qui fuit.
Signaux de sécurité : tentatives de jailbreak/injection, appels du véhicule rejetés, erreurs d'autorisation. Une augmentation peut indiquer une campagne d'attaque active.
Qualité et dérive : Diminution de la qualité de sortie au fil du temps (dérive). Par exemple, le taux de réussite de la vérification, le taux de correction de l'approbation humaine, la satisfaction des utilisateurs.
Performances : latence, taux d'erreur, délai d'attente. Cela affecte directement l’expérience utilisateur et le coût.

Qu’est-ce que la dérive et comment l’attraper ?

La dérive se produit lorsque la qualité des entrées ou des sorties du modèle change inaperçue au fil du temps. Il existe deux types : la dérive des données (la répartition des demandes entrantes change : nouveau sujet, nouvelle langue) et la dérive de la qualité (le résultat pour le même travail se détériore progressivement). Une référence est nécessaire pour capturer : enregistrer la plage normale de métriques lorsque le système est sain ; Laissez la déviation devenir une alarme.

Étape par étape : configuration de la surveillance

Mesurez la ligne de base. Enregistrez la plage normale de chaque signal lorsque le système est sain.
Définir le seuil et l'alarme. Quelle déviation avertira qui et comment ?
Prélèvement + inspection humaine. Demandez à un humain d'examiner régulièrement un échantillon des résultats (la dérive de la qualité n'est souvent que visible).
Installez un tableau de bord. Surveillez quatre familles de signaux sur un seul écran.
Boucle de rétroaction. Reliez les résultats de la surveillance à l’amélioration rapide/de contrôle.

Quatre modèles copiables

Invite d'évaluation de l'échantillonnage de qualité (suivi de la dérive avec LLM-as-juge) :

Vous trouverez ci-dessous 20 imprimables aléatoires de cette semaine. Évaluez chacun comme « bon / acceptable / mauvais » et rédigez une brève justification. Enfin je comparerai le mauvais taux avec le taux de la semaine dernière ; S'il existe une tendance (récurrence du même type d'erreur) qui ressort cette semaine, marquez-la.<outputs>{{ examples }}</outputs>

Invite de résumé des anomalies :

Examinez les métriques quotidiennes suivantes : nombre de requêtes, jetons, coût, appel d'outil rejeté, tentatives de jailbreak, latence moyenne. Marquez toute mesure qui s'écarte de plus de 30 % de la ligne de base comme "ANOMALIT" et estimez la cause possible (attaque, bug, abus).<metrics>{{ daily_data }}</metrics>

Règle de définition du seuil d'alarme :

Définir des alarmes pour chaque signal : - Coût : si dépasse 2x la moyenne quotidienne -> alerte haute priorité - Tentatives de jailbreak : si dépasse 10 par heure -> avertir l'équipe de sécurité - Taux de réussite de la vérification : si tombe en dessous de 90 % -> examen de la qualité - Latence : si p95 dépasse l'objectif de 2x -> examen des performances

Invite de recherche de dérive :

Le taux de réussite de la vérification est passé de 94 % à 78 % au cours des 2 dernières semaines. Aidez-moi à répondre à ces questions : (1) Un nouveau sujet/langue/format est-il apparu dans les demandes entrantes ? (2) Les erreurs sont-elles concentrées dans une catégorie particulière ? (3) Le timing coïncide-t-il avec un changement d'invite/de modèle/d'outil ? Nommez les données à vérifier pour chacun.

Invite faible/Invite forte

mauvaise approche

Approche forte

"S'il y a une erreur, on verra"

Base de référence + seuil + alarme proactive

Je vérifie juste si le système est debout.

Surveillance de quatre familles de signaux (usage, sécurité, qualité, performance)

Ne pas échantillonner du tout la qualité de sortie

Échantillonnage humain régulier + LLM-as-juge

Ne pas collecter et examiner les métriques

Tableau de bord + boucle de rétroaction

Trois mini-étuis

Cas 1 — L'alarme de coût a détecté la clé qui fuyait. Le coût quotidien des jetons d’une entreprise a triplé du jour au lendemain. L'alarme de seuil a alerté l'équipe de sécurité ; L'enquête a montré qu'une clé de test avait été divulguée et utilisée par un robot. La clé a été révoquée en 25 minutes ; S'il n'y avait pas eu d'alarme, la facture aurait été constatée à la fin du mois.

Cas 2 — Dérive de qualité silencieuse. Le taux de réussite à la vérification d'un assistant d'assistance est passé de 95 % à 80 % en trois semaines. L'échantillonnage hebdomadaire a capturé cela ; La raison en était que les clients commençaient à poser des questions sur une nouvelle gamme de produits et que la base de connaissances du modèle à ce sujet était incomplète. Le taux s'est rétabli lors de la mise à jour de la base de connaissances.

Cas 3 — La vague de jailbreak était précoce. Les tentatives d'injection effectuées sur un assistant sont passées de 2 à 40 par heure en une journée. Alarme de sécurité déclenchée ; On a vu qu'une « recette » pour cracker le système était partagée sur un forum. L'équipe a mis à jour l'invite de défense et les comptes suspects à taux limité ; La vague s’est calmée avant de se transformer en véritable fuite.

Astuce : Ne vous contentez pas uniquement des métriques de la machine. La dérive de la qualité est souvent détectée simplement en demandant à un humain de lire les échantillons de sortie. Une petite routine consistant à examiner 15 à 20 impressions aléatoires par semaine permettra de détecter rapidement les pannes silencieuses les plus coûteuses.

Erreurs courantes

Ne pas le mettre en production et mettre en place un suivi ("ça marche, ok").
Ne pas pouvoir identifier l'anomalie sans mesurer la ligne de base.
Manquer la dérive de la qualité en regardant uniquement "est-ce que ça tient debout".
Ne pas échantillonner du tout la qualité de sortie à travers les yeux humains.
Ne pas déclencher une alarme et découvrir le problème auprès du client/superviseur.
Ne pas relier les résultats du suivi à l’amélioration (pas de boucle de rétroaction).

En résumé

Les systèmes d’IA peuvent se détériorer discrètement ; Le dysfonctionnement le plus dangereux est celui qui ne génère pas d'erreurs, mais réduit seulement la qualité.
Suivez quatre familles de signaux : utilisation/coût, sécurité, qualité/dérive et performances.
La dérive (la dérive de la qualité des entrées ou des sorties au fil du temps) est capturée uniquement par rapport à une référence.
Un échantillonnage humain régulier en plus des métriques de la machine capture la dérive de la qualité.
Connectez la surveillance à la boucle d’alarme et de rétroaction ; Mesurer et ne pas regarder n’est pas surveiller.

Tâche de candidature

Choisissez au moins une métrique de chacune des quatre familles de signaux pour votre propre système d'IA et notez leurs lignes de base actuelles (ou estimées). Définissez un seuil d’alarme pour chaque métrique. Ensuite, prenez 15 des résultats de votre semestre dernier et notez-les avec l'invite d'échantillonnage ci-dessus ; Notez le « mauvais » taux. Que cela soit votre première référence avec laquelle comparer la dérive dans le futur.

liste de contrôle

[ ] J'ai défini des métriques de quatre familles de signaux (utilisation, sécurité, qualité, performances).
[ ] J'ai défini une ligne de base et un seuil d'alarme pour chaque métrique.
[ ] J'échantillonne régulièrement la qualité du résultat à travers des yeux humains.
[ ] Je surveille les signaux sur un seul écran avec un panneau d'affichage.
[ ] L'alarme est envoyée à l'équipe de sécurité en cas d'anomalies et de vagues de jailbreak.
[ ] J'attribue les résultats du suivi à l'amélioration de l'invite/du contrôle.