Observer un système non déterministe

Un service classique tombe ou répond. Un système à base de modèle répond toujours, et peut se dégrader lentement sans qu'aucun voyant ne s'allume. C'est ce qui rend son exploitation particulière.

Ce qu'il faut tracer, et qui n'est pas évident

Les métriques habituelles, latence, taux d'erreur HTTP, disponibilité, ne captent rien du problème réel. Il faut y ajouter, pour chaque appel : le modèle et sa version exacte, le nombre de tokens en entrée et en sortie, le coût calculé, la version du prompt, et si un repli s'est déclenché.

Sans la version du prompt dans les traces, vous ne pourrez jamais relier une dégradation à un changement. Et les prompts changent plus souvent que le code.

Les signaux qui préviennent avant la plainte

La longueur des réponses. Elle dérive avant que la qualité ne s'effondre. Une moyenne qui double en une semaine annonce presque toujours un problème.

Le taux de sorties non conformes. Si vous attendez du JSON et que 3 % échouent à l'analyse, c'est un thermomètre gratuit et très sensible.

Le taux de reformulation. Un utilisateur qui repose sa question autrement vient de vous dire que la réponse était mauvaise, sans remplir aucun formulaire.

Versionner les prompts comme du code

Dans le dépôt, avec une revue, un identifiant de version, et la possibilité de revenir en arrière. Un prompt modifié en production sans trace est un incident qu'on ne pourra pas diagnostiquer.

Échantillonner pour relire

Conservez un échantillon d'interactions complètes, et relisez-en trente par semaine à la main. Aucune métrique ne remplace la lecture : c'est là qu'on voit que le ton a changé, que les réponses sont devenues évasives, que le modèle a pris un tic.