Azure LLM Observabilité: vérification de l'écart vert échantillonné

L'observabilité d'Azure LLM devrait répondre à plus que a fini une course? Avant d'accepter un verdict sain, prouvez quatre conditions pour la même course: la télémétrie est consultable et fraîche, l'état d'exécution est compris, chaque contrôle de qualité requis couvre réellement la course et le résultat promis existe à sa destination. Microsoft Foundry vous donne des éléments utiles de cette preuve. Il peut placer des traces côté serveur dans Azure Monitor Application Insights, afficher des métriques opérationnelles dans le tableau de bord de surveillance des agents et exécuter des évaluations en fonction des réponses de production échantillonnées. Ces pièces ne sont pas interchangeables. Une trace peut être fraîche pendant qu'un évaluateur a sauté la course. Un évaluateur peut passer alors qu'un fichier, un billet, un déploiement ou un message n'ont jamais atteint leur destination. Une course complète peut également être en attente d'une décision humaine légitime que l'application a mal modélisée. Le défaut pratique est donc un audit de couverture et non un score composé. Gardez les preuves non disponibles non disponibles, considérez l'échantillonnage comme une couverture plutôt que comme un succès, et laissez un reçu de résultat spécifique à la charge de travail combler l'écart final. Lisez les surfaces de la fonderie comme preuve séparée Microsoft vue d'ensemble de l'observabilité distingue trois capacités: Tracing enregistre le chemin d'exécution, y compris les appels de modèle, l'utilisation des outils, la latence et les intervalles connexes. Monitoring résume les mesures opérationnelles telles que les jetons, la latence, le taux d'erreur et le succès de l'exécution. Evaluation mesure des propriétés de qualité ou de sécurité sélectionnées avec des évaluateurs intégrés ou personnalisés. Cette séparation est importante lors d'un incident. Une durée réussie établit qu'une opération instrumentée a atteint un statut terminal. Il n'est pas établi que le tableau de bord actuel puisse voir toutes les étendues pertinentes, qu'un évaluateur ait examiné cette réponse ou que l'effet secondaire demandé ait eu lieu. Les fonderies guide d'installation de suivi définissent explicitement deux limites utiles. Tout d'abord, le suivi côté serveur de l'agent hébergé commence après que le projet soit connecté à Application Insights. Deuxièmement, de nouvelles traces peuvent prendre quelques minutes pour apparaître. Si la trace attendue est absente, le verdict responsable n'est pas failli ou sanit. C'est evidence indisponible jusqu'à ce que vous distinguiez la connexion, l'autorisation, le retard d'ingestion, le prélèvement d'échantillons et l'instrumentation. L'accès à la requête est une autre condition indépendante. La documentation de surveillance de Foundry nécessite un accès adapté à Azure basé sur les rôles à Application Insights et, pour les vues de journaux, à l'espace de travail Log Analytics associé. Un opérateur qui peut ouvrir le projet mais ne peut pas consulter sa télémétrie protégée a un problème de visibilité, pas de preuve d'un agent sain. La même précaution s'applique à l'onglet Moniteur. Le Guide du tableau de bord de surveillance de l'agent décrit le taux de réussite de l'exécution, les jetons, la latence et les résultats d'évaluation. Il indique également que l'évaluation continue s'effectue sur les réponses échantillonnées . Le prélèvement d'échantillons est une décision valable sur les coûts et le débit, mais cela soulève une question de dénominateur: cette course particulière a t elle reçu toutes les évaluations requises pour la décision que vous prenez? Ne répondez pas à cette question à partir d'un score global. Enregistrez le par course. Donnez un enregistrement de couverture Commencez par un petit disque sans contenu. Gardez des identifiants ou des hashes permettant à un opérateur autorisé de trouver les preuves sous jacentes; ne copiez pas les instructions, les arguments d'outils, les secrets ou les sorties de modèles dans un nouveau magasin de santé. Chaque champ répond à une décision: 1. L'opérateur peut il récupérer la télémétrie actuelle? Testez la connexion Application Insights et l'autorisation de requête réelle. Une page de portail de chargement n'est pas le test. 2. Est ce que la trace est suffisamment fraîche pour ce flux de travail? Définir un budget à partir de la durée attendue de la course plus le retard observé de l'ingestion. Ne réutilisez pas silencieusement la couche verte d'hier. 3. Qu'est ce que fait l'agent? Préserver working , waiting , succeeded , et les états de défaillance. Une approbation nommée ou une dépendance extérieure est une attente, pas un arrêt. 4. La couverture des magasins est elle couverte par l'évaluateur requis? 5. Est ce que le résultat promis est arrivé? Recherche la destination qui possède le résultat. Le résultat doit correspondre au travail. Pour un rapport généré, vérifiez que l'objet attendu existe et que son hash ou son schéma est correct. Pour une mise à jour du billet, lisez le billet et vérifiez la transition d'état prévue. Pour une mutation d'API, consultez la ressource cible plutôt que de faire confiance à l'échange HTTP réussi du client. Pour une tâche de code, il est nécessaire d'exiger la différence attendue plus le résultat de construction ou d'essai pertinent. Cet enregistrement évite délibérément un champ universel de réussite. La combinaison de preuves inégalées trop tôt est comment une couverture inconnue devient verte. Répétez la décision avant les alertes de câblage L'appareil utilisé pour cet article contient huit circuits synthétiques et aucune crédibilité, requête ou télémétrie de production Azure. Son classificateur évalue la visibilité avant l'état d'exécution, l'état d'exécution avant la qualité et la qualité avant le résultat: L'exécution de node audit azure observability.mjs contre le dispositif fixe a produit huit correspondances et aucun déséquilibre: Le cas de l'accusé Les preuves du côté Azure Les preuves de destination Le verdict Connexion présente, requête refusée Ne peut pas inspecter la télémétrie courante Présentation de la réception EVIDENCE UNAVAILABLE Vieille trace, tous les autres champs verts La récolte Présentation de la réception EVIDENCE STALE Trace fraîche, opération active Activité actuelle Pas encore attendu WORKING Une nouvelle trace, nommée attendant l'approbation Attendu actuel Pas encore attendu WAITING Exécution réussie, évaluation requise saute Absence de couverture de qualité Présentation de la réception QUALITY UNKNOWN Exécution réussie, évaluation échantillonnée échouée La qualité a échoué Présentation de la réception QUALITY FAILED Exécution et évaluation réussies Complet dans la fonderie Résultat de l'absence FALSE COMPLETE Exécution et évaluation réussies Complet dans la fonderie Présentation de la réception HEALTHY Deux résultats sont faciles à mal gérer. QUALITY UNKNOWN n'est pas un évaluateur raté. Il indique que l'évaluateur n'a pas couvert la durée requise pour cette décision. Vous pouvez rediriger cet état vers un substitut déterministe, une évaluation ponctuelle si nécessaire, ou un examen humain. Vous ne pouvez pas réétiqueter le score de tableau de bord global comme résultat de cette course. Le WAITING n'est pas non plus un échec. Si la trace est fraîche et identifie un propriétaire légitime et une dépendance, l'action utile consiste à faire surface l'attente de ce propriétaire. Le redémarrage de l'agent peut dupliquer le travail ou rejeter le contexte sans résoudre la dépendance. Mettez des alertes sur l'état de défaillance, pas la couleur Une alerte doit nommer les éléments de preuve qui ont été cassés: Telemetry non disponible : vérifier la connexion Foundry to Application Insights, la requête RBAC, l'accès à la table protégée, l'instrumentation et le trafic récent. EEvidence stale : comparer le dernier temps de suivi observé avec le budget de fraîcheur du flux de travail et le retard d'ingestion connu. Qualité inconnue : inspecter le taux d'échantillonnage configuré et savoir si cette décision nécessite réellement un évaluateur. Qualité ratée : conservez le nom de l'évaluateur, la version, le seuil et l'identifiant de l'exécution testée avant d'enquêter. False complete : arrêtez les tentatives automatisées à la limite de l'effet secondaire et concilier la destination par un identifiant de travail stable. Cela produit des opérations plus silencieuses qu'une alerte sur chaque échantillon manquant ou de longue durée. Les directives du tableau de bord de Microsoft offrent de larges seuils d'enquête, tels que l'examen de faibles taux de réussite ou de latence élevée. Ces signaux de la flotte sont utiles pour trouver une cohorte. L'enregistrement de la couverture par course décide de ce qui ne va pas avec une pièce particulière. La fraîcheur a aussi besoin d'un propriétaire. Application Insights contrôle la durée pendant laquelle les preuves restent consultables; les autorisations d'ingestion et de requête contrôlent si elles sont visibles maintenant. Conservez séparément le dernier temps de requête réussi et le dernier temps de suivi correspondant. Le tableau de bord chargé ne prouve rien. Gardez la vue d' avant et les limites de confidentialité visibles La documentation actuelle de la fonderie marque des parties du suivi et de la surveillance des agents comme prévisualisation. Le vue d'ensemble du suivi des agents indique que le suivi est généralement disponible pour les agents prompt et hébergés tandis que le suivi du flux de travail et des agents externes sont en prévisualisation. Le guide de surveillance marque également les caractéristiques du tableau de bord comme prévisualisation. Enregistrer le type d'agent et l'état des fonctionnalités dans le répertoire; ne pas transférer les garanties d'un parcours d'agent hébergé vers un flux de travail externe sans vérifier le contrat en cours. Le suivi peut capturer les instructions, les sorties, les arguments des outils et les résultats des outils. Microsoft conseille de supprimer les contenus sensibles avant d'atteindre la télémétrie et d'appliquer des contrôles d'accès à la production et de conservation. Une couche de santé devrait faire référence aux preuves avec des identifiants sans contenu lorsque cela est possible, et ne pas créer un second stock de charges utiles sensibles. Il y a une dernière limitation à garder à côté du verdict: ce classifiant teste la prééminence des preuves. Il ne contacte pas un abonnement Azure, ne déduit pas un objectif de niveau de service d'ingestion ou ne décide pas de ce que signifie le succès de votre application. Le reçu de destination est délibérément spécifique à la charge de travail. C'est cette frontière qui est le point. L'observabilité d'Azure LLM peut exposer l'exécution, les performances, la qualité des échantillons et les preuves de débogage. La santé de l'exploitation exige également la fraîcheur, la couverture, un état d'attente correct et la preuve du résultat attendu. Sidewisp est actuellement en préversion privée. Son objectif est de transformer les données provenant des délais d'exécution des agents existants en une vue de santé claire tout en préservant l'incertitude et les limites d'approbation humaine; la surveillance de Microsoft Foundry n'est pas présentée ici comme une intégration Sidewisp expédiée.