Graphane LLM Observabilité: prouver la couche de résultat

L'observabilité de Grafana LLM peut vous donner un compte rendu solide des appels de modèle, des générations d'agents, des traces, de l'activité de l'outil, de la latence, des jetons, des coûts et des évaluations. Il ne peut, par lui même, prouver qu'un agent était accessible au moment prévu, qu'il attendait la bonne personne, qu'il avait appliqué un effet externe exactement une fois ou qu'il produisait le produit demandé. Le défaut pratique est donc de deux parties: utiliser Grafana pour la télémétrie qu'il documente, puis ajouter un petit contrat de preuve opérationnelle pour les questions auxquelles la télémétrie ne répond pas. Testez ces pièces séparément. Une conversation qui apparaît à Grafana n'est pas la preuve que des traces et des mesures sont arrivées, et une trace propre n'est pas la preuve que la destination a changé. Ce guide met en œuvre cette limite par rapport à la documentation actuelle de Grafana et au paquet JavaScript @grafana/agento11y . Il comprend également un audit de sept cas qui rend la règle d'acceptation exécutable plutôt que de la laisser comme conseil de tableau de bord. Commencez par le chemin documenté, puis testez le en morceaux Grafana expose actuellement deux itinéraires connexes. Son AI Configuration de l'observabilité général envoie par défaut des traces, des métriques et des journaux OpenTelemetry à travers la passerelle OTLP de Grafana Cloud; un OpenTelemetry Collector ou Grafana Alloy est l'alternative documentée lorsque vous avez besoin d'un routage, de transformation ou d'un meilleur contrôle à un volume plus élevé. Sa surface Observabilité de l'agent plus récente ajoute des générations axées sur les agents, des conversations, des appels à l'outil, des étapes du flux de travail, des données de jetons et de coûts, des évaluations et des intégrations de cadres. Pour JavaScript, le paquet actuel est @grafana/agento11y . L'étiquette npm latest a renvoyé la version 0.9.0 lorsque celle ci a été vérifiée le 27 juillet 2026. Traitez le comme un instantané de mise en œuvre daté, pas comme une recommandation de version permanente. Le début le plus court documenté ressemble à ceci: Ensuite, configurer le SDK à partir de variables environnementales plutôt que de mettre un jeton d'accès dans la source: Les noms des variables d'environnement concernés sont documentés comme AGENTO11Y ENDPOINT , AGENTO11Y PROTOCOL , AGENTO11Y AUTH MODE , AGENTO11Y AUTH TENANT ID et AGENTO11Y AUTH TOKEN . N'imprimez pas leurs valeurs dans des journaux ou ne les attachez pas à des traces. Il y a une limite facile à manquer dans le Guide de l'instrumentation JavaScript de Grafana: l'exportation de génération et l'exportation OpenTelemetry ne sont pas le même chemin. Le SDK peut envoyer des données de génération, mais il a besoin d'un TracerProvider et d'un MeterProvider configurés par l'application pour exporter les champs et les mesures qu'il émet. Sans ces fournisseurs, le guide dit que les traces et les mesures sont silencieusement perdues. Cela fait d'une conversation visible un test de configuration faible. Utilisez trois sondes indépendantes: 1. Créez une génération avec un identifiant de test unique et trouvez le dans Conversations . 2. Trouvez une distance portant la même identification de corrélation dans la source de données des traces. 3. Demandez une métrique émise par le SDK sur la fenêtre d'essai et confirmez ses attributs de ressources pour identifier le service et l'environnement attendus. Faute de configuration si une sonde manque. Ne donnez pas une moyenne des trois dans un score réconfortant: generation=yes, trace=no, metric=no est une télémétrie partielle, pas une installation en grande partie saine. Une trace complète de Grafana est encore une preuve d'activité Les documents Grafana fournissent une couverture utile. Agent Observability peut capturer les générations, les appels à l'outil, les étapes du flux de travail, la latence, les erreurs, les jetons, les coûts, les scores de qualité et les comparaisons de versions. Ces signaux peuvent répondre à des questions telles que: L'appel LLM a t il échoué ou ralenti ? Quel modèle et quelle version de l'agent ont géré la fuite ? Quels outils ont été utilisés, et dans quel but? Combien de jetons et combien de coût attribué a consommé la course? Une évaluation ou une garde configurée a t elle produit un score ? Le Conventions d'agents d'OpenTelemetry GenAI donne à cette activité un vocabulaire portable. Au moment de la recherche, les conventions sur les agents étaient explicitement marquées par l'état de développement et comprenaient des opérations pour invoquer un agent ou un flux de travail, planifier et exécuter un outil. L'état de développement est important: fixez la version de l'instrumentation et attendez vous à l'évolution des attributs ou des formes d'espace. Aucun de ces noms ne définit le résultat de votre entreprise. Une période execute tool peut signaler une réponse HTTP réussie alors que le fournisseur applique la demande de manière asynchrone, la rejette après validation ou écrit à l'objet incorrect. Une durée de flux de travail complète peut coexister avec un fichier manquant. Une évaluation de la qualité peut marquer le texte généré alors qu'une course programmée n'a jamais commencé. Utilisez une carte de la preuve qui indique à la fois la preuve et sa limite: Avion de preuve Il peut établir Il n'est pas établi que Sonde de libération Export de génération Une génération de modèles enregistrée atteint l'observabilité de l'agent Des traces et des mesures ont été exportées Trouver un identifiant de conversation unique Des traces Opérations instrumentées et leur trajectoire causal La destination externe a désormais l'état prévu Demandez la durée correlative Mesures Signes de taux, de durée, d'erreur, de jeton et de coût agrégés Une course ou livrable requise réussie Demandez la fenêtre d'essai exacte Évaluation Un marqueur nommé a couru contre le matériel fourni. Une affirmation déterministe de destination adoptée Conserver la version du scoreur et la portée des entrées Résumé de l'heure d'exécution Le temps d'exécution était accessible et frais à un moment attendu La tâche accomplie Comparer l'âge du battement cardiaque avec son SLA Attendez le reçu Une pause a une raison, le propriétaire, la date limite et la gestion du CV Le propriétaire décidera à temps. Vérifiez le routage et l'escalade Résumé des effets Une opération externe peut être réconciliée Le résultat complet de l'utilisateur est présent Retour en fonction de l' identifiant d' opération stable Résultat de la réception Une affirmation spécifique à la destination adoptée Stabilité future Révéler pendant une fenêtre de stabilité Ce n'est pas un argument pour télécharger plus de contenu. Préférer les identifiants, les timestamps, les versions, les états de basse cardinalité, les hachages, les comptes et les affirmations de destination sur les instructions brutes, les compléments, les charges utiles des outils, les secrets ou les voies de fichier. La télémétrie riche et la minimisation des données sont compatibles lorsque le contrat est conçu avant l'instrumentation. Effectuer l'audit de couverture sur sept cas J'ai transformé la carte en un petit dispositif déterministe. Chaque cas indique si la génération, la trace et l'exportation métrique ont réussi; si la télémétrie et le rythme cardiaque de course sont frais; si la course a une attente légitime; si un effet externe a été reconcilié; et si le résultat attendu a reçu une réception autoritaire. Le classifiant applique la priorité plutôt que l'arithmétique: Les sept appareils couvrent: aucune génération n'est arrivée; la génération est arrivée mais les intervalles et les mesures ne l'ont pas été; toute la télémétrie existe mais est obsolète; l'agent attend légitimement avec un propriétaire, la date limite et le jeton de reprise; une tentative d'outil n'a pas de réception d'effet de réconciliation; la télémétrie et les preuves des outils sont vertes, mais le produit de livraison est manquant; le même dossier complété dispose d'un reçu de livraison autorisé. La répétition locale a passé les sept classifications attendues: La comparaison la plus utile est entre les deux derniers cas. Les deux ont génération, trace et exportation métrique. Ils sont tous les deux frais. Les deux déclarent que la course a été terminée et que l'effet de l'outil a été vérifié. Le premier n'a pas d'affirmation de destination et est classé false success ; le second ajoute object:report 17 plus un hash de contenu et devient verified . Ce changement est délibérément étroit. Aucun panneau de tableau de bord, nombre de jetons, score du modèle ou changement de statut de trace. Seuls les éléments de preuve requis par la demande de l'utilisateur changent. L'audit a une limite difficile: il fait confiance aux faits qui lui sont fournis. Un collectionneur malveillant ou brisé peut mentir, et un reçu de la mauvaise destination n'est pas une preuve. Dans la production, générez des reçus de résultats à la limite autoritaireune lecture après écriture de stockage, une requête de contrainte de base de données, une sonde de santé du déploiement, une recherche du fournisseur de messages envoyés ou une autre affirmation déterministe liée à l'ID de travail original. Transformer la couverture en porte d'acceptation de la production Exécutez un canary instrumenté avant d'activer une nouvelle version d'agent, une intégration de cadre, une route de collecteur ou un changement d'échantillonnage. Donnez au canary une pièce d'identité unique et un résultat inoffensif attendu. Il est alors nécessaire d'exiger toutes les affirmations applicables: Génération: la génération existe sous le nom de canary ID. Trace: la durée de la racine et les opérations requises par enfant sont consultables. Metric: la fenêtre canarienne contribue à la série attendue. Freshness: Le retard du collecteur reste inférieur à une limite déclarée. Runtime: un reçu de rythme cardiaque ou de planificateur prouve que le temps de fonctionnement a été atteignable au moment prévu. Attendez: toute pause nomme sa raison, le propriétaire autorisé, la date limite de la décision, la voie d'escalade et la manutention de la reprise. EEffect: les opérations d'effet secondaire se concilient avec une idempotence stable ou un identifiant d'exploitation du fournisseur. Ooutcome: une vérification d'autorisation de destination prouve l'existence de l'artefact ou de l'état requis. Privacy: la requête de test confirme que les champs de prompt, de réponse, de secret et de chemin interdits sont absents. Gardez les jugements inconvenients. Le telemetry partial devrait bloquer le déploiement d'un instrument. health unknown devrait éviter un statut vert lorsque les preuves sont périmées. waiting devrait en informer le propriétaire sans reprendre les travaux légitimes. uncertain effect devrait arrêter les tentatives clandestines. false success devrait réouvrir la tâche ou l'incident même lorsque la trace a pris fin normalement. L'échantillonnage doit être décidé séparément. Les traces lourdes peuvent être échantillonnées lorsque le volume en a besoin, mais les reçus médicaux compacts nécessaires pour classer une course requise ne doivent pas disparaître avec eux. Conserver suffisamment d'identifiants pour corréler les traces de l'échantillon avec les reçus d'exécution, d'attente, d'effet et de résultat non échantillonnés. Dans le cas contraire, une politique de télémétrie moins chère devient discrètement une politique de précision plus faible. Il y a aussi un coût d'exploitation. Les retours de destination ajoutent de la latence et des appels du fournisseur; les battements cardiaques en temps d'exécution ajoutent des contrôles de stockage et de fraîcheur; les reçus d'attente nécessitent la propriété du routage. Appliquez la plus petite vérification déterministique qui résout la décision. Une vérification de l'existence du fichier et du hash est meilleure que de demander à un autre modèle si le fichier existe probablement. Un juge LLM reste utile lorsque le résultat est sémantique, mais enregistre sa version, sa rubrique, sa portée d'entrée et son incertitude en plus des contrôles déterministes. où correspond Sidewisp Grafana est un endroit capable d'inspecter et de corréler la télémétrie. La couche manquante décrite ici est le jugement opérationnel sur la facilité d'accès, le progrès, l'attente, les effets et les résultats, et non un autre spectateur de traces. Le Sidewisp est destiné à devenir une couche de santé autour des temps d'exécution des agents existants, avec des preuves explicites, une fraîcheur, une incertitude, des limites d'approbation et une vérification. Il ne s'agit pas d'un temps de fonctionnement de remplacement ou d'une passerelle de modèle obligatoire. Les adaptateurs de surveillance de la production et de récupération ne sont pas expédiés aujourd'hui. Sidewisp est actuellement en préversion privée. Si cette limite de preuve correspond à la façon dont vous exploitez les agents, la prochaine étape appropriée est de rejoindre la liste d'attente d'aperçu privé et de décrire les vérifications de temps d'exécution et de résultats dont vous avez besoin. En attendant, gardez les verdicts de télémétrie de Grafana précis et attachez l'achèvement à la preuve de destination que votre travail nécessite réellement.