J'ai découvert qu'une seule métrique de passerelle de sécurité avait masqué une interruption de service d'une journée entière dans une fonctionnalité d'explication générée par IA. En traitant le « rejet par la passerelle » et l'« échec de chargement du modèle » comme une seule et même chose, la métrique a donné une fausse impression de bon fonctionnement. Elle a enregistré quatre rejets et zéro succès, alors que le modèle n'a jamais fonctionné durant cette période — une erreur qui aurait pu laisser les opérateurs aveugles face à un système défaillant.
Comment la confusion est survenue
La fonctionnalité utilise un modèle de langage local pour transformer la logique machine brute en phrases lisibles par l'humain. Une passerelle de sécurité en aval bloque toute sortie qui viole des règles prédéfinies. En production, j'ai exposé un compteur unique qui s'incrémentait chaque fois que la passerelle rejetait une phrase. Lorsque le drone a enregistré quatre explications par l'IA, le compteur a rapporté quatre rejets et aucune sortie réussie. J'ai interprété cela comme la passerelle faisant son travail, et non comme une panne de la fonctionnalité.
Ce que le compteur masquait était un échec en deux étapes :
- Le modèle ne tourne pas – Le modèle partage une machine avec le reste du système. Pour économiser de la mémoire, l'hôte le décharge après une période d'inactivité.
- Délai d'attente dépassé lors du rechargement – Lorsqu'une nouvelle menace est apparue, le système a tenté de recharger environ deux gigaoctets de données de modèle. Le rechargement a dépassé le délai de réponse de trente secondes, la requête a donc expiré et a renvoyé une réponse vide.
Parce que le compteur traitait un rejet par la passerelle et une réponse vide due à un délai d'attente comme le même événement, le tableau de bord affichait une « passerelle de sécurité opérationnelle » alors que la fonctionnalité d'IA était de fait hors service.
Pourquoi c'est important
Dans les produits pilotés par l'IA, les passerelles de sécurité empêchent les sorties nuisibles ou absurdes. Les opérateurs surveillent le taux de déclenchement de la passerelle comme un indicateur de santé. Lorsque ce signal fusionne avec des modes de défaillance non liés, la métrique devient un mensonge silencieux : elle rassure alors que le service est indisponible.
La correction qui a rétabli la visibilité
J'ai apporté trois changements concrets :
- Maintenir le modèle en mémoire – J'ai ajusté l'hôte pour qu'il conserve le modèle en mémoire, éliminant ainsi le délai de rechargement.
- Étendre le délai d'attente – J'ai augmenté la fenêtre de réponse pour gérer les chargements lents occasionnels.
- Diviser le compteur – J'ai remplacé la métrique unique « rejeté par la passerelle » par quatre compteurs distincts : accepté, rejeté, réponse vide et aucune réponse.
La troisième étape s'est avérée décisive. Au lieu d'un chiffre unique pouvant être interprété de deux manières, la répartition en quatre parties montre si la passerelle de sécurité est active, si le modèle répond, ou si la requête n'a jamais atteint un modèle.
Compromis et contre-arguments
Ce qu'il faut surveiller ensuite
Les développeurs déployant des composants d'IA devraient auditer tous les compteurs agrégés qui mélangent les contrôles de sécurité et les défaillances au niveau du système. La création d'un journal d'historique détaillé enregistrant le chemin de chaque requête — début du chargement du modèle, évaluation de la passerelle, résultat final — fournit les données d'analyse nécessaires pour repérer les problèmes cachés.
À retenir : Une seule métrique de « rejet par la passerelle » peut masquer un service d'IA hors service ; diviser cette métrique en ses événements constitutifs révèle la vérité et empêche un faux sentiment de confiance dans un système qui ne fonctionne pas réellement.