LLM Observabilité pour les tempêtes de retrait: coût par résultat vérifié

L'observabilité de LLM devrait compter les jetons, la latence, les erreurs et les appels de modèle. Pour un agent qui peut réessayer de travailler, ce n'est que le numérateur. Le dénominateur opérationnel est le nombre de résultats visés vérifiés à la destination. Un signal de coût utile est donc: Gardez le coût, le propriétaire et l'état de résultat des essais réessayés sous un run id stable. Ne divisez pas les dépenses par des réponses API réussies ou par le message complete de l'agent lui même. Les deux peuvent paraître sains pendant qu'un flux de travail se répète, qu'un produit est absent ou que deux couches tentent silencieusement à nouveau le même échec. Ce guide applique cette règle à une expérience fixe de huit tours. La cohorte stable coûte 0,012 $ par résultat vérifié. La cohorte d'essai tempête semble coûter 0,041 $ par réalisation déclarée, mais son contrôle de destination ne prouve qu'un seul résultat, donc le chiffre réel est de 0,12310,3 fois la cohorte constante. Les montants en dollars sont synthétiques; l'erreur comptable est réelle et reproduisable. Maintenir la couche d'observabilité normale de LLM Le défaut raisonnable est toujours la télémétrie des appels de modèle. Enregistrer la durée de la demande, les jetons d'entrée et de sortie, la classe d'erreur, le fournisseur, le modèle, l'exploitation et la corrélation de trace. Ces signaux vous indiquent si un fournisseur a ralenti, si un contexte s'est étendu, si un modèle a changé ou si un appel a échoué. Le OpenTelemetry Conventions métriques génétiques actuel fait de ce béton de base. Lors de la réunion du 24 juillet 2026, ils définissent gen ai.client.token.usage et gen ai.client.operation.duration . Ils définissent également le nombre d'appels à l'infraction au niveau de l'agent et le nombre d'appels à l'outil. Le document marque les conventions Development , alors fixez la version que vous mettez en œuvre et attendez vous à ce que les champs se déplacent. L'utilisation de jetons n'est pas automatiquement coûteuse. Un fournisseur peut retourner des comptes de jetons facturables, un gateway peut calculer une estimation et une facture peut ensuite concilier le montant. Gardez la provenance à côté de la valeur: Utilisez un identifiant d'exécution opaque. Les instructions, les réponses, les informations d'identification, les arguments des outils, le contenu des clients et les itinéraires absolus ne relèvent pas de la dimension des coûts. La trace protégée peut rester disponible pour une enquête autorisée; l'agrégat ne nécessite que suffisamment d'informations pour localiser la tentative et expliquer sa comptabilité. Les graphiques par appel restent précieux. Ils répondent simplement à une autre question. Une baisse des coûts par modèle de réponse peut coexister avec une augmentation des tentatives par flux de travail. Une nouvelle tentative réussie peut réparer une erreur de fournisseur transitoire tout en cachant que la même tâche a également été réessayée par une file d'attente et ensuite par l'agent. Le modèle de télémétrie décrit les appels. La comptabilité décrit la promesse. Faire du résultat vérifié le dénominateur Définir le résultat avant l'exécution. Le modèle de texte retourné est un résultat d'appel. La demande de retrait a l'engagement attendu, le rapport existe sous la clé convenue, ou la carte du site contient l'URL publiée est un résultat. Le record minimum de course a besoin de quatre états: État La signification Traitement des coûts Traitement de la santé verified Un prédicat natif de destination passé Inclure le coût et l'augmentation du dénominateur Complète missing L' agent a déclaré l' achèvement mais le prédicat a échoué Inclure le coût; ne pas augmenter le dénominateur Faux succès waiting Une dépendance nommée ou une décision humaine est exceptionnelle Inclure le coût; ne le qualifiez pas encore de succès ou d'échec Route vers le propriétaire de la dépendance unavailable Le vérificateur n'a pas exécuté ou ses preuves sont obsolètes Incluez le coût connu; laissez le ratio inconnu s'il n'existe pas de dénominateur valide Enquêter sur la couverture des preuves Cette distinction empêche un raccourci pratique mais destructeur. Si une personne n'a pas approuvé un changement, l'agent attend; exécuter le modèle à plusieurs reprises ne crée pas d'autorité. Si le vérificateur est hors connexion, le fait de considérer son absence comme une défaillance peut entraîner des effets secondaires répétés. Si l'agent dit done mais que la destination est vide, considérer la déclaration comme un succès récompense une fausse réalisation. Rejoignez le dossier des résultats aux tentatives, plutôt que de copier le produit livré dans le magasin d'observabilité: Le vérificateur doit être déterministe dans la mesure du possible. Vérifiez un hash de fichier, une rangée de base de données, un champ API, le résultat du test ou l'état de destination. Un évaluateur qualitatif peut fournir des preuves lorsque le résultat ne peut pas être exprimé comme un prédicat, mais sa version, son calibrage et son incertitude appartiennent à côté du score. Reproduire l'écart entre les coûts de retrait L'expérience qui l'accompagne utilise huit circuits synthétiques: quatre réguliers et quatre lors d'une nouvelle tempête. Chaque course contient des champs de jetons et de coûts au niveau de l'essai, ainsi qu'un état de résultat final. La tempête comprend un résultat vérifié, deux déclarations de faux succès et une approbation légitime en attente. Enregistrez un objet NDJSON par course. Cette paire abrégée montre la forme: Aggreger chaque tentative sous sa cohorte, puis calculer: L'ensemble du matériel et de l'audit conservés avec cette publication produisent: Trois observations modifient la décision d'exploitation. Tout d'abord, le coût de la tempête par réalisation déclarée sous estime le coût par résultat vérifié de 3x. La déclaration de l'agent est un mauvais dénominateur de facturation. Deuxièmement, l'amplification de la tentative passe de 1,25 à 3,00. Un tableau de bord d'appels modèles peut afficher douze appels individuellement normaux sans montrer qu'ils n'appartiennent qu'à quatre promesses. Troisièmement, 62,6% des dépenses de tempête se produisent après les tentatives initiales, et deux couches différentes possèdent ces tentatives. Le problème n'est pas seulement un modèle coûteux. C'est une voie de contrôle illimitée. Cette expérience n'estime pas le taux d'échec de la production. Ses prix et ses cas sont conçus pour tester la règle comptable. Exécutez le même calcul sur vos propres facturations ou sur les coûts dérivés du fournisseur, conservez la version source et le prix et comparez les flux de travail similaires au fil du temps. Donnez une couche du budget de réessayer Les répétitions sont souvent correctes. Une demande limitée ou une erreur de réseau transitoire peut réussir après un retard. L'échec commence lorsque chaque couche décide indépendamment qu'elle possède la récupération. Le Orientation relative aux limites de taux d'OpenAI recommande une rétroaction exponentielle aléatoire et met en garde que les demandes infructueuses contribuent toujours à la limite par minute. L'envoi continu consomme donc la capacité nécessaire à la récupération. Le Références de réessayer AWS SDK actuel documente les mêmes principes de contrôle dans un paramètre d'API plus large: tentatives maximales limitées, décalage exponentiel avec jitter, et un seau de jetons de quota de réessayer qui arrête les réessayer lorsque son budget est épuisé. Ces sources ne prévoient pas une politique universelle d'agents. Ils soutiennent un contrat plus sûr: 1. Choisissez un propriétaire de réessayer pour une opérationgénéralement la couche la plus basse pouvant classer l'erreur transitoire et préserver l'idempotence. 2. Comptez la demande initiale et chaque tentative de reprise par rapport à une tentative au niveau de l'exécution et au budget des coûts. 3. Propagez les métadonnées vers le haut afin qu'un coureur de flux de travail ne confond pas l'erreur finale d'un SDK avec une première défaillance. 4. Faites expliciter les états non rétractables: autorisation refusée, entrée non valide, autorisation manquante et vérification de résultat ratée nécessitent un routage ou une enquête, pas une répétition aveugle. 5. Arrêtez quand le temps, l'effort ou le budget sont épuisés. Retournez à un état visible avec les dernières preuves. 6. Vérifiez la destination après une nouvelle tentative. Une commande qui est revenue avec succès n'est pas le résultat promis. Les temps d'arrêt ont besoin de soins spéciaux. Un temps d'arrêt du client ne prouve pas que la partie distante n'a rien fait. Avant de réessayer un outil d'effet secondaire, utilisez une clé d'idempotence ou consultez la destination. Dans le cas contraire, un système d'observabilité peut signaler correctement la deuxième tentative alors que le système d'affaires reçoit deux factures, messages ou publications. Alerte de régression, puis inspectez le résultat N'essayez pas une seule fois. Commencez par des lignes de base spécifiques aux flux de travail et demandez de la persistance. Un premier avertissement utile peut combiner trois conditions: Ajustez ces valeurs au flux de travail. Un procédé par lots avec un ventilateur peu coûteux et idempotent peut tolérer plus de tentatives. Un flux de travail de paiement, de publication ou de messagerie client peut permettre moins. Un fournisseur séparé s'arrête à cause d'une défaillance de l'outil et d'un résultat d'absence de destination. Ils ont des propriétaires différents et des actions sécurisées différentes. L'alerte doit indiquer la promesse affectée, les tentatives totales, les propriétaires de nouvelles tentatives, l'origine des coûts, le résultat et la fraîcheur du vérificateur, ainsi que la prochaine action limitée. Un message utile dit: La publication du rapport a utilisé 12 tentatives dans le SDK et le coureur du flux de travail; les dépenses de retrait sont de 63%; l'un des quatre résultats est vérifié; inspecter la propriété de retrait et le vérificateur de la carte du site. Il ne faut pas dire que le coût des jetons est élevé. Il y a deux limites importantes. Les données de coût peuvent être retardées, estimées ou incomplètes, donc affichez la couverture et ne fabriquez pas de zéros. Les contrôles de résultats peuvent également échouer indépendamment, de sorte que unavailable doit rester distinct de missing . Une course waiting légitime reste hors du dénominateur vérifié sans être étiquetée collée jusqu'à ce que sa dépendance ou sa date limite change. La direction du produit de Sidewisp inclut le coût en tant que signal de santé en plus de la disponibilité, de l'exécution, de la mémoire, des outils et des résultats. Il est destiné à fonctionner à côté des délais de fonctionnement existants, et non à devenir une passerelle de modèle obligatoire ou un fixateur autonome. Sidewisp est actuellement en préversion privée. Le site public et la bibliothèque d'articles sont en direct; les adaptateurs de surveillance de la production, l'analyse des coûts des jetons et l'exécution de la récupération ne sont généralement pas expédiés. Rejoignez l'aperçu privé si vous voulez aider à façonner la façon dont les preuves, les coûts et les résultats vérifiés devraient se rencontrer pendant que les humains conservent l'autorité.