Gains :
- Capacité à reconnaître les causes silencieuses de dégradation du modèle (dérive des données, dérive du concept, erreur en amont) et à établir un suivi à trois niveaux (opérationnel, entrée, sortie)
- Capacité à évaluer les systèmes LLM dans plusieurs couches avec des vérifications de règles, une évaluation par un arbitre LLM et une évaluation humaine, et à calibrer avec une ancre humaine par un arbitre LLM.
- Capacité à concevoir un ensemble d'évaluation contenant des cas de sécurité et de pointe et à transformer chaque erreur détectée en un cas de test permanent
Une fois qu’un modèle entre en production, votre travail n’est pas terminé ; La vraie responsabilité ne fait que commencer. Parce que le modèle peut s'effondrer silencieusement lorsque personne ne le regarde. Dans cette unité, nous couvrons deux disciplines complémentaires : l'évaluation (mesure systématique de la qualité du modèle) et le monitoring (suivi constant du modèle en production). Surtout dans les systèmes LLM, l'évaluation est plus difficile et nécessite plus de soin que le ML classique.
Pourquoi le modèle de production s'effondre tranquillement
Un bug plante, le journal s'imprime, l'alarme se déclenche. En revanche, un modèle ML peut être erroné sans provoquer d’erreurs. Trois causes principales de dégradation :
- Dérive des données : la distribution des données d'entrée change au fil du temps (nouveaux produits, changement de comportement des utilisateurs, saisonnalité). Le modèle reste le même mais le monde change.
- Dérive du concept : la relation entrée-sortie change. Les tactiques de fraude et les modèles de spam évoluent ; Ce qui était bien hier sera mal aujourd’hui.
- Corruption en amont : Une source de données change de format, une zone se libère ; Le modèle bave silencieusement avec des entrées corrompues.
Le traçage rend audibles ces distorsions silencieuses.
Que regarder : trois couches
Une bonne surveillance couvre trois niveaux :
- Métriques opérationnelles : latence, taux d’erreur, volume de requêtes, utilisation des ressources. "Est-ce que le système est debout ?"
- Métriques de données/entrées : la distribution des entrées est-elle similaire à celle de la formation ? Le taux de valeurs manquantes a-t-il augmenté ? De nouvelles catégories sont arrivées ? « Le modèle voit-il des données familières ? »
- Métriques de modèle/sortie : journal de distribution des prévisions ? Les scores de confiance ont-ils chuté ? Et si possible, quelle est la précision par rapport à la vérité terrain ? « Le modèle est-il toujours précis ?
La troisième couche est la plus précieuse mais la plus difficile ; car le résultat réel arrive généralement avec du retard (il devient clair après des mois si un prêt sera remboursé ou non).
Astuce : Si le résultat réel est retardé, surveillez d'abord la distribution des entrées et des prédictions. Un changement de distribution d’entrée est un signe précoce de dégradation de la précision et peut déclencher une alarme sans attendre le résultat réel.
Évaluer les systèmes LLM : le défi particulier
En ML classique, la « bonne réponse » est claire (classe 0 ou 1). Le résultat du LLM, en revanche, est ouvert : il peut y avoir plusieurs réponses correctes à la même question, « l'exactitude » ne rentre pas dans un seul nombre. Approches d'évaluation LLM :
- Métriques référencées : comparaison du résultat à la réponse idéale. Limité; car il peut considérer la bonne réponse exprimée différemment comme « fausse ».
- Vérifications basées sur des règles : la sortie est-elle un JSON valide ? Y a-t-il des mots interdits ? Contient-il les champs souhaités ? Pas cher, fiable, serré.
- Juge LLM (LLM-as-judge) : Ne demandez pas à un modèle de demander « cette réponse est-elle bonne selon ce critère ? Cela évolue, mais l’arbitre lui-même doit être vérifié.
- Examen humain : étalon-or mais cher et lent. Il est utilisé sur l'échantillon.
Dans la pratique, ils sont utilisés ensemble : contrôles de règles bon marché sur chaque résultat, juge LLM sur un grand échantillon, évaluation humaine sur un échantillon petit mais rigoureux.
Approche faible / Approche forte
Faible : "LLM-J'ai demandé à l'arbitre, 92% de nos réponses étaient bonnes. Le système est génial."
Güçlü : "Nous avons d'abord étiqueté par l'homme 100 impressions. Nous avons exécuté le juge LLM sur les mêmes 100 impressions et mesuré l'accord humain-juge - 85 % d'accord, acceptable. Nous avons documenté où le juge s'est systématiquement trompé (une tendance à trouver de longues réponses injustement bonnes) et a corrigé son invite. Ce n'est qu'alors que nous avons fait confiance aux scores du juge."
La différence : l'approche forte vérifie l'arbitre avec une ancre humaine, pas aveuglément. Un arbitre LLM non vérifié donne une belle mais fausse confiance.
Attention : LLM-referee est également un modèle ; hallucinogène, biaisé (favorise les réponses longues/confiantes), peut être incohérent. Calibrez les scores des arbitres avec des tags humains avant de prendre des décisions de production.
Ensemble d'évaluation : soigneusement conçu
Un bon ensemble d'évaluation représente la variété des utilisations réelles et des cas difficiles. Une évaluation remplie d’exemples simples vous laissera dans une fausse confiance. Assurez-vous de le mettre dans le cluster eval :
- Cas extrêmes : entrée vide, entrée très longue, format inhabituel.
- Cas difficiles connus : exemples dans lesquels le modèle a commis des erreurs dans le passé (comme test de régression).
- Incidents de sécurité : tentatives d’injection rapides, requêtes malveillantes, pièges de violation de la vie privée.
Le cluster d'évaluation se développe avec le temps : chaque nouveau bug détecté en production devient un cas de test pour la prochaine évaluation.
Alarme et intervention
La surveillance reste incomplète sans alarme. Il doit y avoir un seuil et un plan de réponse pour chaque mesure importante : « Avertir l'ingénieur si la dérive d'entrée dépasse X », « Annulation automatique si le taux d'erreur dépasse Y ». Gardez les alarmes significatives : trop de fausses alarmes désensibilisent l'équipe et lui font manquer la véritable alarme.
trois mini-cases
Cas 1 – Alerte précoce. La véritable précision d’un modèle de prévision de la demande n’est apparue qu’à la fin de la semaine. L'équipe surveillait la distribution des intrants et a constaté l'émergence soudaine d'une nouvelle catégorie de produits un mardi – quelque chose que le modèle n'avait jamais vu. Ils ont mis à jour le modèle sans attendre la baisse de précision. La surveillance des entrées a permis de gagner des jours.
Cas 2 – Arbitre non vérifié. Une équipe a rapporté « notre qualité est excellente » sur la base d'un évaluateur LLM. Lorsque les plaintes des clients ont augmenté, une surveillance humaine a été introduite : l'arbitre a considéré les réponses sûres mais incorrectes comme « bonnes ». Une fois l’arbitre calibré avec des tags humains, la véritable qualité a été révélée et était bien inférieure. Leçon : ne faites pas confiance à l'arbitre sans le vérifier.
Cas 3 - Tests de régression. Un changement rapide a résolu un problème tout en en éliminant silencieusement un autre. Mais l’équipe a gardé les bogues passés dans le compartiment d’évaluation ; Lorsque la nouvelle modification a été testée sur ce cluster, le cas cassé a été immédiatement détecté et la modification a été corrigée. Leçon : chaque bug corrigé doit devenir un cas de test permanent.
Modèles copiables
Produire un plan de suivi pour ce modèle de production. Couvrir trois couches : 1) Opérationnel (latence, taux d'erreur, volume) 2) Entrées/données (changement de distribution, valeur manquante, nouvelle catégorie) 3) Modèle/sortie (distribution de prédiction, confiance, précision si possible) Modèle : [description]. Combien de temps faut-il pour que le résultat réel arrive : [durée]Ajoutez un seuil et une recommandation d'intervention pour chaque métrique.
Proposer une stratégie d'évaluation (évaluation) pour ce système LLM. Tâche : [description] Déterminer les couches : - Quelles vérifications basées sur des règles doivent être exécutées sur chaque sortie ? - Quels critères l'arbitre LLM doit-il évaluer et comment doivent-ils être validés (ancre humaine) ?
Vérifiez cette invite d'arbitre LLM : - Les critères d'évaluation sont-ils clairs ou subjectifs ? - Est-il sujet à un biais de longueur/confiance ?
Écrivez un runbook de réponse pour cette alarme de surveillance.Alarme : [par ex. seuil de dérive d'entrée dépassé]Doit contenir : les étapes de contrôle initiales, les causes possibles, les critères d'annulation, qui informer.
Tableau des causes de détérioration
distorsion
symptôme
La voie vers une détection précoce
dérive des données
Modifications de la distribution des entrées
Surveillance de la distribution des entrées
changement de concept
La justice tombe silencieusement
Prédiction + comparaison réelle
erreur en amont
Les champs deviennent vacants/changements de format
Validation du schéma + taux manquant
Incohérence du modèle
Changements dans la distribution de la production
Surveillance de la distribution des sorties
Erreurs courantes
- Ne pas établir de surveillance. Le modèle tombe en panne silencieusement, personne ne le voit.
- Suivez uniquement les mesures opérationnelles. Le système est opérationnel, mais les prédictions peuvent être fausses.
- Utiliser LLM sans vérifier l'arbitre. Cela donne une fausse confiance.
- Évaluez avec des exemples simples. Cela n’indique pas une réelle difficulté.
- N'inclut pas les erreurs passées dans l'évaluation. La même erreur revient à nouveau.
- Alarmes fortes. L'équipe devient désensibilisée, manquant la véritable alarme.
En résumé
Le modèle peut être inexact sans provoquer d’erreurs de production ; l'évaluation et le suivi sont donc tout aussi importants que le développement. Établir un suivi à trois niveaux (opérationnel, entrée, sortie) ; Utilisez la dérive d’entrée comme avertissement précoce si le résultat réel est retardé. Dans les systèmes LLM, l’évaluation est ouverte ; Utilisez ensemble les vérifications de règles, l'arbitre LLM et l'évaluation humaine - mais assurez-vous de valider l'arbitre LLM avec une ancre humaine. Enrichissez votre cluster Eval avec des cas de périphérie et de sécurité et transformez chaque erreur détectée en un scénario de test permanent.
Tâche de candidature
Rédigez un plan de surveillance à trois niveaux pour un modèle de production (ou quasi-production) et définissez le seuil + l'alarme pour au moins une métrique de distribution d'entrée. Si vous disposez d'un système LLM : marquez 30 résultats avec des humains, exécutez un arbitre LLM sur les mêmes résultats et mesurez l'accord homme-arbitre ; Notez le parti pris systématique de l'arbitre. Ajoutez au moins 3 bords et 2 cas de sécurité à votre cluster d'évaluation.
liste de contrôle
- [ ] La surveillance couvre les trois niveaux (opérationnel, entrée, sortie).
- [ ] J'utilise la dérive d'entrée comme avertissement précoce si le résultat réel est retardé.
- [ ] J'ai calibré l'arbitre LLM avec des étiquettes humaines.
- [ ] Le cluster Eval contient des cas de périphérie et de sécurité.
- [ ] J'ai transformé chaque bug que j'ai détecté en un cas de test permanent.
- [ ] Chaque mesure importante a un seuil et un plan de réponse.