9. Anti-modèles et pièges courants

Douze pièges courants, décrits ici comme des scénarios types, qui produisent des données que personne n’utilise, des tableaux de bord que personne ne lit ou des plateformes auxquelles personne ne se fie. Les éviter coûte moins cher que les corriger.

9.1 Instrumenter avant de définir les questions

Symptôme : un arbre de traces exhaustif, avec des centaines d’attributs par span, mais personne ne sait répondre à « quel est le score de fidélité par locataire ? ». Les attributs pertinents n’ont jamais été indexés.

Remède : l’étape 1 du chapitre 4. Écrivez d’abord les questions.

9.2 Confondre journaux et observabilité

Symptôme : un gros volume de journaux structurés dans Loki ou Splunk, aucun span, aucune évaluation. Le coût est élevé, l’exploitation de la valeur reste manuelle.

Remède : passer au niveau 2. Les journaux sont un canal de secours, pas le signal principal.

9.3 Stocker prompts et réponses sans caviardage

Symptôme : une trace de production contient une clé d’API qu’un utilisateur a collée dans la conversation. La trace est désormais conservée dans un dorsal interrogeable, largement accessible.

Remède : caviarder dans le collecteur, avant tout exportateur. Ne comptez jamais sur l’application pour nettoyer les données.

9.4 Un LLM juge sur chaque trace

Symptôme : le coût en jetons de l’évaluation dépasse celui des appels LLM de production. Les données d’évaluation sont si bruitées que personne n’agit dessus.

Remède : hiérarchiser les évaluateurs. Par exemple : évaluateurs à base de règles, peu coûteux, sur 100 % ; juges LLM moyens sur 10 % ; juges coûteux sur 1 % plus les traces signalées. N’utilisez l’auto-cohérence que là où elle compte.

9.5 Des tableaux de bord sans alertes

Symptôme : de superbes tableaux Grafana que personne ne regarde ; les régressions sont découvertes par les utilisateurs.

Remède : chaque panneau qui représente un véritable SLO doit avoir son alerte. Les tableaux de bord servent au diagnostic, les alertes à l’exploitation.

9.6 Des attributs à forte cardinalité sur les métriques

Symptôme : pression mémoire sur le dorsal de métriques, requêtes lentes, explosion soudaine des coûts à l’arrivée d’un nouveau locataire.

Remède : hygiène des attributs. Les clés à forte cardinalité vont sur les traces. Les dimensions des métriques doivent être bornées.

9.7 Aucun versionnage des prompts et des configurations

Symptôme : une régression de qualité est détectée, mais personne ne sait quel changement l’a causée. Plusieurs choses ont été livrées cette semaine-là.

Remède : chaque artefact versionné, la version capturée sur chaque span, les déploiements corrélés aux changements de version.

9.8 Traiter la dérive comme un défaut à corriger

Symptôme : une alarme de dérive se déclenche, l’équipe reconstruit l’index ou change de modèle, la dérive revient la semaine suivante.

Remède : la dérive est un signal, pas un défaut. Elle indique que le monde a changé. La bonne réponse est d’investiguer et la bonne action est souvent de ne rien faire. Seule une partie des dérives est corrélée à une perte de qualité.

9.9 Acheter un outil avant de définir la pile

Symptôme : l’équipe souscrit à un produit commercial d’observabilité LLM, l’intègre, puis découvre qu’il ne peut pas être déployé dans la juridiction requise ou qu’il ne tient pas la cardinalité.

Remède : le choix entre open source et commercial est une décision stratégique, prise au regard des contraintes de souveraineté, de coût et d’intégration. Prenez cette décision avant d’évaluer des produits.

9.10 Évaluer sans calibrer

Symptôme (scénario illustratif) : les scores de fidélité semblent stables autour de 0,85, mais des vérifications ponctuelles révèlent que le juge contredit souvent le jugement humain. Personne ne se fie à la métrique.

Remède : constituer un jeu de calibration avec une vérité terrain humaine. Mesurer l’accord avec un indicateur corrigé du hasard (kappa de Cohen). Itérer sur le prompt du juge jusqu’au seuil fixé à l’avance. Recalibrer à chaque changement de modèle juge.

9.11 Faire l’impasse sur la boucle fermée

Symptôme : les évaluations tournent, les scores sont stockés, rien ne change. La plateforme produit des données, mais aucune amélioration.

Remède : formaliser la revue hebdomadaire. Les traces en échec deviennent des entrées du jeu de non-régression. Sans ce rituel, l’observabilité se réduit à un stockage coûteux en lecture seule.

9.12 Confondre MLOps et observabilité de l’IA

Symptôme : une équipe MLOps porte la pile d’observabilité de l’IA et tente d’instrumenter la couche d’inférence LLM comme elle instrumente l’entraînement des modèles. La sémantique ne correspond pas.

Remède : l’observabilité de l’IA relève de l’observabilité de production. Elle est portée par l’équipe plateforme, en collaboration avec les équipes ML et sécurité. Le MLOps gère le cycle de vie des modèles, pas celui des requêtes.

Suite : Annexe.

Marquer comme lue