AI Observabilité: construire un contrat de signal à quatre couches

L'observabilité de AI n'est pas une catégorie de tableau de bord. C'est la capacité de répondre à quatre questions différentes avec des preuves: Est ce que le travail était attendu? Qu'est ce qui s'est vraiment passé ? Est ce qu'il attend une dépendance légitime ? Le résultat envisagé a t il existé et a t il passé la vérification? Une pile qui répond seulement à la deuxième question peut produire de belles traces alors qu'un agent prévu ne démarre jamais, une approbation humaine passe inaperçue ou qu'une course réussie ne laisse pas de résultats. Le défaut pratique est donc un contrat de signal à quatre couches: schedule, exécution, dépendance et résultat . Gardez la latence du modèle, les jetons, les erreurs, les appels à l'outil et les intervalles, mais ne les confondz pas avec l'ensemble du contrat. Cet article teste les règles d'un petit appareil NDJSON et vous donne un audit que vous pouvez adapter avant d'acheter ou d'utiliser une autre plateforme. Traiter l'observabilité de AI comme un problème de couverture Les résultats de recherche pour l'observabilité de AI mélangent plusieurs préoccupations légitimes: la qualité du modèle, la dérive des données, les performances du GPU et des applications, les traces d'agents, la sécurité, la gouvernance et le coût. Cette largeur est la raison pour laquelle il est difficile d'évaluer notre observabilité. Deux équipes peuvent utiliser la même phrase tout en recueillant des preuves disjointes. Pour un agent qui effectue un travail prévu ou délégué, utilisez le travail prévu comme unité d'analyse. Ensuite, demandez une couche pour chaque question qui peut changer le verdict opérationnel. Couche Les preuves minimales L'échec peut être exposé Le calendrier heure prévue, date limite, heure de début, identité du calendrier La course n' a jamais commencé. L'exécution ID d'exécution, étape ou intervalle, résultat de l'outil, état du terminal, classe d'erreur la course s'est arrêtée, a été bouclée, a été réessayée ou a échoué La dépendance état d'attente explicite, type de dépendance, approbation ou référence du système externe L'attente légitime a été mal étiquetée comme coincée Le résultat identité de l'artefact ou de l'effet secondaire, vérification déterministique, temps de vérification l'exécution dit "succès" mais le travail était absent ou mal Ces couches ne sont pas des produits fournisseurs. Il s'agit de quatre joints autour d'une pièce d'identité stable. Un arrière plan de trace peut contenir la plupart des événements d'exécution. Un planificateur peut connaître les horaires attendus. Un système d'approbation peut posséder des preuves d'attente. Le lieu de destination lui même, un stockage d'objets, un référentiel, une API de billetterie, une base de données, possède généralement la meilleure vérification des résultats. Ce cadre permet également de maintenir la surveillance et l'évaluation séparées sans les forcer à se séparer. Un score de qualité basé sur les rubriques peut être un vérificateur des résultats lorsqu'aucun contrôle déterministe n'existe. Il ne doit pas remplacer silencieusement un hash de fichier, un résultat de test, un nombre de lignes ou un reçu API lorsqu'un de ces fichiers est disponible. Pourquoi une trace complète peut encore manquer l'incident Les normes de suivi s'améliorent rapidement. Lors de la mise en œuvre de la 74fd2e0 , le modèle de couverture et les champs d'action de la Conventions sémantiques génératives OpenTelemetry AI, les mesures, les événements, les exceptions, les conventions spécifiques au fournisseur et le MCP. Le document marque les conventions de GenAI comme Development , une limite de version importante lorsque vous concevez des schémas à longue durée de vie. Les spécifications de portée de l'agent définissent des opérations telles que create agent , invoke agent , invoke workflow , plan et execute tool . Il contient également des attributs utiles, y compris gen ai.operation.name , gen ai.agent.name , et error.type conditionnellement requis; voir le source de l'agent spans collé. C'est une preuve puissante d'exécution. Il indique à l'enquêteur quelle opération s'est produite, comment les intervalles se rapportent, combien de temps ils ont pris, et si une erreur signalée a mis fin à l'opération. Le suivi du cadre peut être encore plus riche. Le Documentation de suivi du SDK OpenAI Agents dit que sa trace par défaut couvre les invocations des coureurs, les intervalles de tâches et de tours, les agents, les générations, les outils de fonction, les barreaux et les remises. Il prend également en charge les spans et les processeurs personnalisés. Cela permet d'attacher des preuves commerciales manquantes. Toutefois, ni une durée terminée ni un terminal ok ne prouvent qu'une course prévue était prévue en premier lieu. Il ne prouve pas non plus l'existence de weekly report.pdf , la nouvelle période de déclaration et le passage d'un analyseur. L'absence n'est pas un défaut de traçage. Il s'agit d'une frontière entre la télémétrie d'exécution et la preuve des résultats opérationnels. Cette limite est falsifiable: prendre deux courses avec les mêmes événements d'exécution réussis, ajouter un événement outcome verified à un seul, et le verdict opérationnel doit être différent. Si votre alerte actuelle donne les deux roues le même état vert, il ne peut pas détecter de faux succès. Effectuer un audit à quatre couches sur un appareil fixe L'appareil d'accompagnement contient quatre courses observées à 2026 07 25T02:42:00Z : run alpha démarre, appelle son outil de rapport, termine et enregistre un artefact vérifié; run beta a la même forme d'exécution réussie mais aucun résultat vérifié; run gamma attend explicitement l'homologation de approve 42 ; run delta dépasse sa date limite prévue sans événement de départ. Exécuter l'audit avec Node.js 20 ou plus récent: Le classificateur renvoie une course dans chaque état: Le code utilise un ordre de décision délibérément ennuyeux. Un résultat vérifié gagne. Une attente explicite avec à la fois une raison et une référence d'approbation attend, pas coincé. Une course qui n'a jamais commencé avant sa date limite est manquée. Une course terminée sans preuve de résultat est un faux succès. Une course commencée au delà de sa date limite est coincée. Tout le reste continue à fonctionner plutôt que d'être promu en bonne santé. C'est une expérience, pas une référence. Quatre cas fabriqués à la main ne peuvent pas estimer les taux d'erreur de production, et un classifiant réel a besoin de manipulation d'événements dupliqués, de tolérances de décalage de l'horloge, de résultats de retard et de délais par emploi. L'appareil est utile parce que chaque verdict est inspectable et changer un événement change un résultat. Garder l'attente comme son propre état Un champ binaire sain/malsain détruit l'information au moment où l'opérateur en a besoin. Considérez run gamma : le processus ne progresse pas, mais le redémarrer serait une erreur par défaut. Il a une dépendance explicite à l'approbation. L'action correcte consiste à faire apparaître la demande à la bonne personne tout en préservant son champ d'application, son âge et ses limites d'autorité. Conserver au moins: Utilisez la même approche pour les temps de réinitialisation des limites de taux, les identifiants d'emploi externes, les fenêtres d'entretien et les arrivées de données en amont. Un message texte gratuit tel que still waiting est une preuve faible: il est difficile de le rediriger, de l'expirer ou de le corréler. Une dépendance typée plus une référence opaque supporte une réponse limitée sans copier le contenu secret, prompt ou d'approbation dans la télémétrie. L'activité est tout aussi facile à surévaluer. Les appels à l'outil répétés montrent qu'un processus est occupé; seuls les delta dans l'état ou le résultat montrent des progrès utiles. Un compteur de réessayer appartient donc à côté du dernier changement significatif, pas à côté d'un timestamp générique last event que la boucle peut rafraîchir à jamais. Faire de la vérification des résultats native de destination Le vérificateur le plus fort vit là où le travail aurait dû atterrir. Pour un fichier, enregistrez une clé d'objet stable, la taille, la digestion et le résultat de l'analyse. Pour une demande de retrait, enregistrez le référentiel, le numéro de relations publiques, la branche cible et la conclusion de la vérification requise. Pour une mise à jour du CRM, enregistrer l'ID d'entité non secrète, la transition de champ attendue et le résultat de lecture après rédaction. Ne mettez pas le produit brut dans chaque trace. Conservez les moindres preuves nécessaires pour répéter le contrôle. La documentation OpenAI Agents SDK prévient que les intervalles de génération et de fonctionnement peuvent contenir des entrées et sorties sensibles, et décrit les contrôles pour désactiver cette capture. Appliquez le même principe à vos événements personnalisés: les identifiants et les digestes sont généralement plus sûrs que les invites, les réponses, les identifiants, les itinéraires locaux absolus ou le contenu des clients. La vérification des résultats nécessite également de la fraîcheur. Un dossier laissé par la course d'hier n'est pas la preuve que la course d'aujourd'hui a réussi. Rejoignez l'artefact à l'exécution actuelle à travers un ID d'exécution, une période de reporting attendue, une fenêtre de création ou un digeste calculé après l'heure de démarrage actuelle. Il y a un compromis. Les contrôles natifs de destination ajoutent des travaux d'intégration et peuvent échouer indépendamment. Traiter un vérificateur non disponible comme unknown , pas sain et pas automatiquement échoué. Surface les preuves manquantes, sa dernière vérification réussie, et la confiance du verdict qui en résulte. Outils d'audit contre le contrat avant de comparer les caractéristiques Une évaluation utile du produit commence par quatre lignes, pas par une grille de logo. Pour chaque pile de candidats, demandez où chaque couche provient, comment elle rejoint la course, combien de temps elle est conservée et quelle requête prouve la couverture. 1. Peut elle importer ou dériver les délais attendus, y compris le fuseau horaire et la date limite? 2. Peut il suivre les modèles, les outils, les transferts, les tentatives et les erreurs sans avoir besoin d'une capture de charge utile sensible? 3. Peut elle représenter l'attente avec une dépendance typique et une cible d'escalade? 4. Peut elle absorber ou relier les reçus déterministes des résultats de la destination? 5. Peut elle distinguer les preuves non disponibles d'un résultat sain? 6. Pouvez vous exporter les données via un format ou une API ouverte si l'outil change ? Ne rejetez pas un outil de suivi ciblé parce qu'il manque de sémantique de planification ou de résultats. Associer avec les sources manquantes si les joints sont fiables. Rejetez l'architecture lorsqu'elle ne peut pas représenter la distinction dont vous avez besoin, cache les données manquantes derrière le statut vert ou nécessite un contenu sensible brut pour les contrôles de santé de routine. Le contrat à quatre couches résout la question initiale: la observabilité de AI pour les agents opérationnels n'est complète que lorsqu'elle peut expliquer séparément l'attente, l'exécution, la dépendance et le résultat vérifié. Les traces sont des preuves essentielles, mais elles sont une seule couche. Sidewisp est actuellement en préversion privée. Son rôle prévu est une couche de santé aux côtés des temps d'exécution existants, avec des preuves et des limites d'autorité humaine; les adaptateurs de surveillance de la production et de récupération ne sont généralement pas expédiés aujourd'hui. Si ce contrat de signal correspond aux défaillances que vous devez détecter, vous pouvez rejoindre la liste d'accès anticipé sans remplacer votre temps d'exécution ou votre passerelle modèle.