Compteur de jetons LangChain: évaluation de l'audit et couverture de l'utilisation

La réponse utile n'est pas choisir un compteur de jetons LangChain. Utilisez deux compteurs différents pour deux décisions différentes. Exécutez count tokens approximately() avant un appel de modèle lorsque vous avez besoin d'une estimation rapide de la pression contextuelle. Lisez le AIMessage.usage metadata rapporté par le fournisseur après l'appel lorsque vous avez besoin d'une entrée, d'une sortie, d'un cache ou d'une utilisation de raisonnement observés. Ensuite, comparez les dossiers d'utilisation avec un manifeste d'appel de modèle attendu. Sans ce dernier chèque de couverture, un total ordonné peut être faible seulement parce qu'un appel n'a jamais été compté. Cette distinction compte pour un agent. Une estimation de l'historique du message peut aider à décider si le contexte doit être ajusté. Il ne peut pas prouver ce que le fournisseur a traité, ce qu'il a facturé, si une nouvelle tentative d'utilisation a été émise ou si un appel de modèle niché a échappé à l'appel de retour. La question opérationnelle est donc la suivante: Quel train de comptage soutient cette décision, et comment savons nous que tous les appels attendus l'ont atteint ? Traiter l'approximation et l'utilisation du fournisseur comme des preuves distinctes La référence Python actuelle de LangChain décrit count tokens approximately() comme une approximation simple. En défaut, il divise les caractères par quatre, ajoute trois jetons par message et fait des tours de manière conservatrice. La fonction compte le contenu et les rôles des messages. Il contient également les appels aux outils AI, les identifiants d'appels aux messages des outils, les noms optionnels, une allocation d'image fixe et les schémas d'outils fournis par l'argument tools . La documentation indique explicitement que des jetons spécifiques au modèle sont nécessaires pour des comptes précis. Cela rend la fonction utile avant l'invocation: Le détail tools=bound tools n'est pas cosmétique. L'implémentation sérialise chaque schéma fourni et ajoute ses caractères à l'approximation. Si un modèle est lié à des outils mais que le compteur ne reçoit que messages , l'estimation peut omettre une grande surface d'entrée répétée. À l'inverse, le fait de passer des outils ne rend pas le résultat exact. Il reste une estimation basée sur un ratio générique et des quotas fixes. Après invocation, utilisez les métadonnées sur le AIMessage retourné: LangChain standardise UsageMetadata autour de input tokens , output tokens et total tokens , avec des cartes de détails d'entrée et de sortie optionnelles. Son propre exemple comprend la création de cache, les lectures de cache, l'audio et le raisonnement. Optional est le mot important. Un champ cache read manquant est une preuve indisponible, pas une preuve que la valeur était nulle. Conserver cette distinction en stockage au lieu de remplir les détails absents avec 0 . Pour les appels multiples, UsageMetadataCallbackHandler regroupe AIMessage.usage metadata entre les modèles: L'agrégation est pratique, mais l'agrégation répond à ce que le gestionnaire a vu, pas à ce que le flux de travail aurait dû appeler. Donner à chaque tentative de modèle un call id stable, un attempt id , le nom du fournisseur/modèle résolu et un timestamp. Une nouvelle tentative est une seconde tentative, pas une correction du premier compteur. Construire un test de couverture autour du manifeste d'appel modèle Commencez par le travail attendu, pas par les lignes d'utilisation qui existent. Pour une course en quatre étapes, le manifeste peut nécessiter plan:1 , retrieve:1 , draft:2 et verify:1 . Le suffixe est le numéro de tentative. Le vérificateur ajoute ensuite les tentatives attendues à trois formes de preuve: une approximation pré vol, y compris les messages et les schémas d'outils requis; l'utilisation déclarée par le fournisseur du message retourné ou du callback; la réception du niveau de tâche qui indique que l'étape a produit son effet attendu. La combinaison produit plus d'états utiles qu'un total: État Ce qui existe Une interprétation sûre provider reported utilisation du fournisseur, avec l'identité de l'appel l'utilisation observée pour cette tentative approximate only estimation pré vol, aucune utilisation par le fournisseur estimation du contexte; utilisation de la facturation non disponible missing call ligne manifeste, aucune observation l'écart d'instrumentation ou de la scène n'a jamais été exécuté detail unavailable Total du fournisseur, manquant de détails préliminaires/détails de raisonnement attendus le total peut être utilisé; l'analyse des composants est bloquée duplicate attempt deux lignes d'utilisation pour une ID de tentative risque d'agrégation; fixer l'identité avant la somme L'appareil d'accompagnement semble délibérément plausible tout en restant incomplet. Il contient quatre appels attendus. Deux utilisent le fournisseur, l'un n'a qu'une approximation et l'autre n'a pas d'observation. Les deux rangées de fournisseurs s'élèvent à 1 451 jetons. Ce nombre est correct et opérationnellement incomplet. Exécuter l'audit: Le résultat est le suivant: Les deux appels qui présentent les deux formes de preuve démontrent également pourquoi une estimation devrait conserver son étiquette. L'approximation était de 5,0% inférieure au total des fournisseurs pour un appel et de 16,5% inférieure pour un autre. Ce dispositif ne prévoit pas que ces pourcentages soient généralisés; les valeurs sont des données d'essai fixes. Il prouve que l'audit ne représente pas les estimations du total des fournisseurs observés et peut exposer les désaccords sans considérer aucun des deux exemples comme un facteur de calibration universel. Un détail subtil de la mise en œuvre actuelle mérite une attention particulière. Le use usage metadata scaling=True optionnel de LangChain prend le message AI le plus récent avec utilisation, nécessite un fournisseur cohérent et évolue l'approximation vers le haut. La source fixe ce facteur entre 1.0 et 1.25 ; elle n'échelle pas une estimation à la baisse. Il peut s'agir d'une estimation historique conservatrice utile. Il ne s'agit pas d'un algorithme de réconciliation pour les factures, les fournisseurs mixtes ou les appels manquants. Déterminez ce que chaque compteur est autorisé à conduire Attachez une limite de décision à chaque numéro stocké. Utilisez une approximation pour: avertir avant qu'une histoire ne s'approche d'une limite de contexte doux; comparer deux variantes d'interrogatoire ou de schéma d'outil avant de les envoyer; décider de résumer, de récupérer ou de supprimer le contexte remplaçable; estimer l'effet relatif de l'inclusion d'un autre message ou d'un schéma d'outil. Utiliser l'utilisation déclarée par le fournisseur pour: attribuer les entrées et sorties observées à une tentative de modèle complète; des composants de cache, audio ou de raisonnement séparés lorsque le fournisseur les renvoie; réconcilier les totaux des fournisseurs/modèles entre les tentatives; calculer le coût uniquement avec une source de prix datée et une manipulation explicite pour des détails indisponibles. N' utilisez aucun compteur seul pour prouver: que tous les appels de modèle attendus ont été effectués avec des instruments; que l'appel à l'outil ait atteint sa destination; que le livrable attendu existe; qu'une nouvelle tentative a été sûre ou utile; qu'une course à faible coefficient a obtenu le résultat souhaité. Ces allégations nécessitent une couverture d'appels et des preuves de résultats. Une mise en œuvre compacte peut faire respecter quatre règles de promotion: 1. Chaque attempt id attendu a exactement une observation. 2. Chaque appel observé est étiqueté approximate ou provider reported ; les étiquettes ne sont jamais fusionnées en silence. 3. Les estimations de pré vol avec des outils prouvent que le schéma a été transmis au comptoir. 4. Les détails du fournisseur ou du cache manquants restent null /disponibles et bloquent uniquement les décisions qui en ont besoin. Le seuil ne doit pas être universellement de 100%. Une prévisualisation hors production pourrait permettre une couverture approximative uniquement. Une alerte budgétaire ou un remboursement des clients ne devraient pas. Encodez la politique à côté du consommateur: context warning peut accepter les estimations, tandis que cost reconciliation nécessite une utilisation complète du fournisseur et des identifiants d'essai uniques. Vérifiez la limite avant d' optimiser Le défaut raisonnable est simple: estimer avant, observer après, la couverture de l'audit à la limite de l'exécution. Optimiser seulement après les trois travaux. Si une estimation de contexte est élevée, inspectons ses intrants avant de couper. L'ensemble des outils était il inclus ? Les résultats des outils sont ils encore nécessaires pour la prochaine décision? Un message long est il un reçu de décision durable ou un récit remplaçable? En supprimant le mauvais contexte, une course peut être moins chère et moins fiable. Si l'utilisation du fournisseur est inattendument faible, vérifiez les appels manquants avant de célébrer. Les blocs de streaming de confirmation ont été combinés dans le message final, les rappels se sont propagés dans des enfants exécutables, les retries ont reçu des identifiants d'essai distincts et l'étape de vérification attendue a réellement été exécutée. Un graphique des coûts avec des intervalles manquants n'est pas un résultat d'optimisation. Si les économies de cache sont importantes, demandez la carte détaillée spécifique au fournisseur et enregistrez sa disponibilité. LangChain vous donne une enveloppe commune, mais les fournisseurs ne peuplent pas nécessairement chaque composant. Ne déduisez pas une erreur de cache d'une clé manquante. Comparer comme avec comme: le même fournisseur, le modèle, la surface de prompt/outil, l'état de cache et l'exigence de résultat. Enfin, ajoutez des preuves symboliques à un reçu de tâche. Pour un agent de révision de documents, le reçu peut contenir la révision de la source, les sections requises vérifiées, les affirmations ratées et le hash de sortie. Les jetons par appel réussi sont toujours un dénominateur faible si l'artefact final est absent. Cette conception à deux voies est intentionnellement plus étroite qu'une pile d'observabilité générique. Il répond à une décision concrète: qu'un numéro de jeton LangChain soit une estimation contextuelle, une mesure du fournisseur observée ou une vue incomplète qui ne doit pas entraîner des revendications de coûts ou d'optimisation. Sidewisp est actuellement en préversion privée. L'analyse de l'utilisation des jetons et du coût estimé est planifiée, pas expédiée. L'orientation du produit consiste à relier les signaux de coûts à des progrès utiles et à des résultats vérifiés tout en gardant les preuves et l'incertitude visibles. Si cette limite opérationnelle correspond à la façon dont vous dirigez les agents, vous pouvez rejoindre la prévisualisation privée. Les sources Référence Python LangChain: count tokens approximately Impression de la source LangChain pour le compteur approximatif Guide des messages LangChain: utilisation des jetons sur AIMessage Référence LangChain: UsageMetadata Référence LangChain: UsageMetadataCallbackHandler