Surveillance LLM: Ce qu'il faut mesurer au-delà de la latence, des erreurs et des jetons

La surveillance de LLM devrait commencer par la qualité des appels du modèle: latence, erreurs, volume de demande, jetons et qualité de sortie. C'est le défaut raisonnable pour une fonctionnalité de chat, un pipeline de récupération ou une enveloppe API. Une fois que la même application peut planifier, appeler des outils, attendre l'approbation, reprendre plus tard, ou déclarer une tâche terminée, ajouter un deuxième registre pour la santé opérationnelle. Les deux livres répondent à des questions différentes. Le premier demande: Le service de modèle se comporte t il normalement? Le second demande: L'agent a t il fait des progrès utiles et produit il le résultat attendu? Joignez vous à eux avec un run id ; ne transformez pas un graphique de latence vert en une affirmation que le travail est sain. Commencez par la couche de surveillance par défaut LLM Un premier tableau de bord utile n'a pas besoin de dizaines de panneaux. Elle a besoin de suffisamment de preuves pour séparer l'échec du fournisseur, l'échec de l'application, la dérive des coûts et la dérive de la qualité de sortie. Le signal La question répond Pratique première alerte Ce qu'il ne peut pas prouver Taux d'erreur de demande Les appels de modèle échouent ? Rate sur une fenêtre, divisée par fournisseur et modèle Si les appels réussis ont fait avancer la tâche la latence de p50/p95 Le temps de réponse a t il régressé ? Comparer des opérations et des modèles similaires Si une course lente a finalement été livrée Tokens d'entrée/sortie Le contexte ou la génération a t il augmenté? Changement par rapport à une ligne de base spécifique à la tâche Si les jetons supplémentaires ont été utiles Résultats La charge change t elle ? Les demandes par minute plus la simultanéité Si une course prévue a été manquée Score de qualité La production de l'échantillon a t elle répondu à une rubrique? Évaluateur de version plus calibration humaine Si un fichier, un ticket ou un déploiement existe Couverture des traces Un opérateur peut il reconstruire l'exécution ? Des traces manquantes ou incomplètes en fonction du temps d'exécution Si le résultat envisagé est présent Cette ligne de base correspond à l'intention de recherche actuelle. Langfuse décrit la surveillance autour de la latence, du débit et des taux d'erreur, avec des traces pour les chemins d'exécution et l'évaluation de la qualité de sortie. Splunk et Dynatrace étendent le jeu à des signaux de ressources, de sécurité, de coût, de rétroaction et d'application. Il s'agit d'une vue utile d'une application LLM; aucune ne doit être rejetée simplement parce qu'une couche d'agent existe. Les conventions sémantiques GenAI d'OpenTelemetry rendent la séparation visible dans l'instrumentation elle même. Les spécifications de développement définissent gen ai.client.token.usage et gen ai.client.operation.duration , puis séparent les instruments de flux de travail et d'agents tels que gen ai.invoke agent.duration , le nombre d'appels d'inférence et le nombre d'appels d'outils. Le développement importe ici: fixez la version que vous mettez en œuvre et attendez vous à ce que les noms changent. L'implémentation propre est un registre des appels de modèle avec les clés run id , operation , provider , model et timestamp. Rassemblez le pour les alertes au niveau du service, mais gardez un chemin de retour vers la course individuelle. Un pic de jeton sans identifiant de course est une facture; un pic de jeton attaché à une course bloquée est un indice d'incident. Ajouter un registre de santé des tâches lorsque l'application devient un agent Une fonctionnalité soutenue par LLM traverse la frontière opérationnelle lorsqu'elle possède un travail au fil du temps. Il peut appeler une base de données, écrire un rapport, ouvrir une demande de retrait, attendre une personne, ou se réveiller à un horaire. À ce stade, les réponses modèles réussies ne sont que des événements intermédiaires. Le SDK OpenAI Agents illustre à quel point ces événements peuvent devenir riches. Ses enregistrements de suivi intégrés générations, appels d'outil de fonction, remises, barreaux de garde, et les opérations d'agent. C'est une preuve de débogage précieuse. La même documentation note également que les intervalles de génération et de fonctionnement peuvent contenir des entrées et sorties sensibles, ce qui est une raison de faire de la capture de contenu un choix explicite plutôt qu'une condition préalable de surveillance. Un registre de santé des tâches peut rester plus petit que la trace. Pour chaque course, enregistrer: expected outcome : un prédicat tel que report exists and parses , et non la phrase completer la tâche; outcome verified : true , false ou unavailable , avec la version vérifiante; progress delta : un changement de compte ou de digestion spécifique à la tâche sur une fenêtre déclarée; waiting on : une dépendance nommée telle que human approval ou null ; last heartbeat at et last progress at , car l'activité et le progrès sont des horloges différentes; declared complete : ce qui a été rapporté par la durée de fonctionnement; collector freshness : lorsque ces faits ont été observés pour la dernière fois. Ce registre ne répéte pas délibérément chaque commande, chaque commande ou chaque période. Il stocke les preuves minimales nécessaires pour décider si la course fonctionne, attend, est coincée, inaccessible ou complète. Des traces de matières premières restent disponibles pour enquête lorsque la politique le permet. Le choix de modélisation important est la preuve tri étatique. Si un collecteur ne peut pas vérifier le produit livré, enregistrer outcome verified: "unavailable" . Ne convertissez pas les preuves manquantes en true et ne dites pas qu'une course inconnue a échoué simplement parce que son signal est absent. Reproduire l'écart avec six courses L'appareil d'accompagnement contient six circuits synthétiques. Les alertes du registre LLM lorsque les erreurs de demande sont d'au moins 20%, la latence p95 dépasse 5 000 ms ou l'utilisation de jetons dépasse 20 000. Le registre de santé des tâches vérifie l'attente explicite, l'achèvement déclaré par rapport à un résultat déterministe et la fraîcheur des progrès. Exécuter l'audit avec Node.js 20 ou plus récent: Le résultat exact est: Le désaccord est le résultat, pas un défaut dans l'un ou l'autre des livres. L'erreur du fournisseur nécessite une enquête sur le modèle de service même si l'agent fait encore des progrès. La course lente s'est terminée avec un résultat vérifié, donc c'est un problème de performance plutôt qu'un incident de travail manquant. L'attente d'approbation et le faux succès semblent normaux pour le moniteur LLM parce que leurs appels étaient rapides, bon marché et réussis. Seul le contrat de tâche expose ce qui nécessite une attention. Les chiffres sont un contre exemple, pas une référence. Six dossiers synthétiques ne peuvent pas établir de seuils d'alerte universels. Remplacez les limites par des lignes de base de votre temps d'exécution, et remplacez progress delta par des preuves liées au travail réel. Transformer le contrat de tâche en alertes Commencez par un flux de travail de grande valeur. Écrivez son prédicat de finition avant d'ajouter un autre tableau de bord. Un travail de recherche peut nécessiter un fichier Markdown, au moins deux sources accessibles et un registre de preuves valide selon un schéma. Un travail de codage peut nécessiter un patch propre plus une commande de test nommée. Un agent de soutien pourrait avoir besoin d'un ticket créé ou d'une escalade enregistrée. Ensuite, évaluez les signaux dans un ordre qui préserve leur signification: 1. Si le temps de course ou le collecteur est obsolète, marquez la course inaccessible ou incertaine. 2. Si waiting on est explicite, rediriger la dépendance au lieu de redémarrer la course. 3. Si le temps d'exécution déclare terminé, évaluez la prédication du résultat. 4. Si la course est active mais que progress delta reste zéro au delà de sa fenêtre, marquez la collée. 5. Si aucun d'entre eux ne s'applique et que les progrès utiles sont frais, laissez le fonctionner. Cet ordre empêche trois interventions bruyantes. Une attente légitime d'approbation n'est pas une impasse. Une commande qui sort de zéro n'est pas automatiquement une tâche accomplie. Une trace occupée avec des outils répétés n'est pas un progrès si l'artefact pertinent ne change jamais. Alerte sur la prochaine action sûre, pas seulement le symptôme. Une alerte d'erreur du fournisseur est envoyée au propriétaire de l'application avec le modèle, l'opération, la classe d'erreur et le lien de suivi. Une attente d'approbation revient à la personne qui peut décider, avec la portée exacte demandée. Une alerte de résultat manquant indique le prédicat échoué. Une boucle de réessayer recommande une pause ou une enquête limitée; elle ne devrait pas autoriser une correction irréversible. Gardez le joindre utile sans rassembler tout Utilisez un run id opaque sur les deux livres. Ne mettez pas de texte client, de secrets, de chemins absolus ou de charges utiles d'outils dans cet identifiant. Un enregistrement de corrélation utile peut contenir: Garder les règles de conservation et d'accès différentes si les risques de données diffèrent. Les histogrammes de latence et de jetons agrégés peuvent avoir besoin d'une rétention plus longue que les intervalles de port prompt. Les preuves des résultats peuvent souvent être un digeste, un compte, un code d'état ou un résultat de schéma plutôt que l'artefact lui même. Lorsqu'un opérateur perçoit une trace, affichez sa fraîcheur et la limite d'échantillonnage afin que l'absence ne soit pas confondue avec la preuve. Il existe également une limite à l'évaluation automatisée. Les vérifications déterministiques sont préférables pour les fichiers, l'état HTTP, les lignes de base de données, les tests et les champs structurés. Si le résultat envisagé est qualitatif, un évaluateur versionné peut aider, mais son score est une preuve avec incertitude et non une vérité fondée. Calibrez le contre l'examen humain et préservez un état unavailable . où correspond Sidewisp La direction du produit de Sidewisp est le deuxième registre: une vue de la santé autour des délais d'exécution des agents existants, avec des preuves, la fraîcheur, la priorité de l'émission et des limites d'approbation explicites. Il n'est pas destiné à remplacer le temps d'exécution, le modèle de passerelle ou le système de traçage brut. C'est une direction, pas une revendication de surveillance expédiée. Sidewisp est actuellement en préversion privée. Le site public et le système d'articles sont en direct, tandis que la collecte des agents de production et de la santé, les adaptateurs de temps d'exécution et l'exécution de récupération ne sont généralement pas expédiés. Rejoignez l'aperçu privé si cette limite modèle appel résultat correspond au problème opérationnel que vous devez résoudre. Sources primaires OpenTelemetry GenAI métriques conventions sémantiques noms de métriques de statut de développement pour les opérations client, flux de travail, agent et outil. Guide de suivi du SDK OpenAI Agents types d'événements tracés, comportement d'exportation et contrôles de données sensibles. Langfuse: Qu'est ce que l'observabilité et la surveillance de LLM ? un indicateur de référence de même intention pour la latence, le débit, les erreurs, le suivi et l'évaluation.