Surveiller la dérive de la production LLM sans tout collecter

Ce que couvrent la recherche et la documentation

ProxyDrift, une prépublication d'août 2026, étudie comment comparer le trafic en direct avec des ensembles de tests à l'aide de résumés structurés des interactions. Ces résumés remplacent un accès direct aux interactions brutes. La documentation de LangSmith décrit l'évaluation des exécutions en direct et l'ajout d'exemples aux ensembles de tests hors ligne. Ce sont des approches différentes. Ni l’un ni l’autre ne prouve qu’une configuration de surveillance protège la confidentialité ou couvre tous les types de demandes des utilisateurs.

Preuve : Détection et récupération de dérives de données préservant la confidentialité pour les applications LLM à grande échelle via des représentations proxy [1]Évaluation LangSmith [2]

Observez trois types de changement

La dérive d'entrée signifie que les demandes ont changé. Les utilisateurs peuvent demander différentes tâches, utiliser de nouvelles langues ou envoyer des documents plus longs. La dérive des résultats signifie que les résultats ont changé, comme davantage d’erreurs ou des réponses plus lentes. La dérive des mesures signifie que le processus de notation a changé. Un nouveau juge, un nouveau guide de notation ou une nouvelle règle d'échantillonnage peuvent faire évoluer les chiffres. Enregistrez ces changements séparément.

Un taux d’échec plus élevé peut signifier que les tâches entrantes sont plus difficiles. Cela ne signifie pas toujours que le modèle est plus faible. Une moyenne inchangée peut également masquer un problème si les demandes les plus faciles équilibrent les plus difficiles. Comparez les groupes importants pour votre produit, tels que la langue ou le type de tâche. Montrez le nombre d’exemples derrière chaque partition.

Gardez un enregistrement de surveillance ciblé

Rubrex recommande de commencer par la décision que chaque alerte doit prendre en charge. Pour enquêter sur un délai d'attente d'un outil, vous aurez peut-être besoin du nom de l'outil, de l'heure, du type d'erreur et de la version du logiciel. Vous n’aurez peut-être pas besoin du message utilisateur complet. Pour vérifier si une réponse est vraie, vous aurez peut-être besoin du document source. Convenez de qui peut accéder à ces données et quand elles doivent être supprimées.

Les étiquettes et les représentations basées sur des nombres, telles que les intégrations, peuvent toujours contenir des informations sensibles. Vérifiez s’ils révèlent des détails privés ou s’ils peuvent être liés à une personne. Gardez les données utilisateur en direct hors des exemples publics. Utilisez des exemples fictifs ou supprimez les détails sensibles lorsque vous expliquez un échec. Les données transformées ne peuvent pas automatiquement être partagées en toute sécurité.

Exemple : les documents numérisés provoquent de nouveaux échecs

Supposons qu’un assistant d’achat commence à recevoir des documents numérisés après le lancement d’une nouvelle intégration. Le modèle n’a pas changé, mais le système peine désormais à extraire le texte. L'ancien ensemble de tests utilise du texte numérique propre. Cela passe toujours, même si les vrais utilisateurs constatent davantage d’échecs.

Tout d’abord, confirmez l’endroit où l’extraction échoue à l’aide d’exemples que vous êtes autorisé à consulter. Ajoutez les documents numérisés à un groupe de test distinct, avec le texte de référence vérifié. Testez ensuite l’étape d’extraction ainsi que la réponse finale. Une modification rapide peut ne pas corriger le texte source manquant. Vérifiez si les nouveaux tests détectent le véritable problème avant de vous y fier comme signal d’alarme.

Donnez à chaque alerte une étape suivante

Nommez un propriétaire pour chaque alerte. Expliquez pourquoi son seuil est important et ce que le propriétaire doit vérifier en premier. Examinez les fausses alarmes ainsi que les incidents manqués par l’alerte. Lorsqu'un échec réel devient un scénario de test, enregistrez d'où il vient, ce qui devrait se produire et quelle version de l'ensemble de test le contient. Notez les changements dans les règles de trafic et de notation lorsque vous comparez les anciens et les nouveaux résultats.

• Enregistrez les versions de l’application, de l’ensemble de test, de l’arbitre et de l’échantillonnage.
• Comparez la qualité au sein de chaque groupe de tâches ainsi que dans son ensemble.
• Examinez un large échantillon ainsi que les cas qui déclenchent des alertes.
• Vérifiez les règles d'accès et de suppression des données brutes et des étiquettes dérivées.

Rendre le tableau de bord utile lors d'un incident

La surveillance montre comment les signaux sélectionnés changent au fil du temps. L'observabilité vous aide à retracer un signal jusqu'à une requête, un paramètre système ou une dépendance. L’évaluation vérifie si le résultat répond aux besoins de l’utilisateur. Rubrex recommande de connecter ces enregistrements avec un ID d'exécution. Conservez uniquement les données nécessaires à l’enquête, conformément aux règles de données convenues du produit.

Essayez de suivre une alerte du début à la fin. L’équipe peut-elle trouver les cas concernés et la version du logiciel ? Quelqu'un peut-il transformer l'échec en un test qu'un autre ingénieur peut réexécuter ? Affichez le nombre d'échantillons, les résultats manquants, les échecs graves et les définitions de scores à côté de chaque tendance. Après un correctif, réexécutez le test et vérifiez si le résultat s'est amélioré. Un tableau de bord est utile lorsqu'il aide quelqu'un à décider quoi faire ensuite.

Questions courantes