2026-08-01T06:53:53.922Z
Contador de tokens LangChain: Estimativa de auditoria e cobertura de uso
Use aproximação antes de uma chamada de modelo LangChain, uso do provedor depois dela e um manifesto de chamada esperada para capturar evidências de token faltantes.
A resposta útil não é pick one LangChain token counter. Use dois contadores diferentes para duas decisões diferentes. Execute o count tokens approximately() antes de uma chamada de modelo quando você precisa de uma estimativa rápida da pressão contextual. Leia o AIMessage.usage metadata relatado pelo provedor após a chamada quando você precisar de entrada, saída, cache ou uso de raciocínio observado. Em seguida, compare os registos de utilização com um manifesto de chamada de modelo esperado. Sem esse último cheque de cobertura, um total ordenado pode ser baixo só porque uma chamada nunca foi contada. Essa distinção importa num agente. Uma estimativa da história da mensagem pode ajudar a decidir se é preciso cortar o contexto. Não pode provar o que o provedor processou, o que faturou, se uma retest emitiu uso, ou se uma chamada modelo aninhado escapou da chamada de volta. A questão operacional é, portanto, a seguinte: Qual é a linha de contagem que apoia esta decisão, e como sabemos que todas as chamadas esperadas chegaram a ela? Tratar a aproximação e a utilização do fornecedor como evidências separadas A referência Python atual da LangChain descreve o count tokens approximately() como uma aproximação simples. Em suas configurações padrão, divide caracteres por quatro, adiciona três tokens por mensagem e rodea de forma conservadora. A função conta o conteúdo da mensagem e as funções. Ele também conta com chamadas de ferramentas AI, IDs de chamadas de mensagens de ferramentas, nomes opcionais, uma allocação de imagem fixa e esquemas de ferramentas fornecidos através do argumento tools . A documentação diz explícitamente que são necessários tokenizers específicos do modelo para contagens precisas. Isso torna a função útil antes da invocação: O detalhe do tools=bound tools não é cosmético. A implementação serializa cada esquema fornecido e adiciona seus caracteres à aproximação. Se um modelo estiver ligado a ferramentas, mas o contador receber apenas messages , a estimativa pode omitir uma grande superfície de entrada repetida. Por outro lado, a passagem de ferramentas não torna o provedor do resultado exato. A estimativa continua a ser baseada em um rácio genérico e em quotas fixas. Após invocação, utilize os metadados do AIMessage devolvido: A LangChain padroniza o UsageMetadata em torno do input tokens , output tokens e total tokens , com mapas de detalhes de entrada e saída opcionais. Seu próprio exemplo inclui criação de cache, leituras de cache, áudio e raciocínio. "Optional" é a palavra importante. Um campo cache read faltante é uma prova indisponível, não prova de que o valor foi zero. Preservar essa distinção no armazenamento em vez de preencher os detalhes ausentes com 0 . Para várias chamadas, o UsageMetadataCallbackHandler agrega o AIMessage.usage metadata em diferentes modelos: A agregação é conveniente, mas uma agregação responde o que o processador viu,não o que o fluxo de trabalho deveria ter chamado. Guarde registros por tentativa também. Dê a cada tentativa de modelo um call id estável, um attempt id , o nome do fornecedor/modelo resolvido e um timestamp. Uma nova tentativa é uma segunda tentativa, não uma correcção ao primeiro contador. Construir um teste de cobertura em torno do manifesto de chamada de modelo Comece com o trabalho esperado, não com quaisquer filas de uso que aconteçam existir. Para uma corrida de quatro etapas, o manifesto pode exigir plan:1 , retrieve:1 , draft:2 e verify:1 . O sufixo é o número da tentativa. O verificador junta as tentativas esperadas a três formas de evidência: Uma aproximação pré voio, incluindo as mensagens e os esquemas de ferramentas necessários; Utilização relatada pelo prestador da mensagem ou da chamada de volta devolvida; O recibo do nível da tarefa que diz que o estágio produziu o efeito esperado. A junção produz estados mais úteis do que um total: Estado O que existe Interpretação segura provider reported Utilização do prestador, com a identidade da chamada Utilização observada para essa tentativa approximate only Estimação pré voio, não utilização do prestador Estimação do contexto; uso de faturamento não disponível missing call linha manifesto, sem observação Falta de instrumentação ou estágio nunca executado detail unavailable Total dos fornecedores, falta de detalhes de cache/razão esperados Total pode ser utilizável; a análise dos componentes é bloqueada duplicate attempt duas linhas de utilização para uma ID de tentativa risco de agregação; fixação da identidade antes da soma O material que acompanha parece deliberadamente plausível, mas permanece incompleto. Contém quatro chamadas esperadas. Dois têm uso do provedor, um tem apenas uma aproximação, e um não tem observação. As duas fileiras de fornecedores somam 1.451 tokens. Esse número é aritméticamente correto e operacionalmente incompleto. Execução da auditoria: O resultado é: As duas chamadas que contêm ambas as formas de evidência também demonstram por que uma estimativa deve manter o seu rótulo. A aproximação foi 5,0% inferior ao total dos prestadores para uma chamada e 16,5% inferior para outra. Esta fixação não afirma que esses percentuais sejam generalizados; os valores são dados de ensaio fixos. A análise demonstra que a auditoria mantém as estimativas fora do total observado do fornecedor e pode expor discordâncias sem tratar qualquer exemplo como um fator de calibração universal. Um detalhe sutil da implementação actual merece atenção. O use usage metadata scaling=True opcional da LangChain leva a mensagem AI mais recente com uso, requer um provedor consistente e escala a aproximação para cima. A fonte fixa esse fator entre o 1.0 e o 1.25 ; não escala uma estimativa para baixo. Esta pode ser uma estimativa histórica conservadora útil. Não é um algoritmo de reconciliação para faturas, provedores mistos ou chamadas faltantes. Decidir o que cada contador pode conduzir Anexe um limite de decisão a cada número armazenado. Use uma aproximação para: Alertar antes de uma história se aproximar de um limite de contexto suave; Comparar duas variantes de esquema de resposta ou de ferramenta antes de enviá las; Decidir se resumir, recuperar ou abandonar o contexto substituível; Estimar o efeito relativo da inclusão de outra mensagem ou esquema de ferramenta. Usar o uso relatado pelo fornecedor para: atribuir a entrada e saída observadas a uma tentativa de modelo concluída; Componentes separados de cache, áudio ou raciocínio quando o prestador os devolver; Conciliar os totais dos fornecedores/modelos entre as tentativas; Calcular custos apenas com uma fonte de preço datada e manipulação explícita para detalhes indisponíveis. Não use nenhum contador sozinho para provar: que todas as chamadas modelo esperadas foram instrumentadas; Que uma chamada de ferramenta tenha chegado ao seu destino; que existe o valor esperado de entrega; que uma nova tentativa foi segura ou útil; que uma corrida de baixo token tenha alcançado o resultado solicitado. Essas alegações precisam de cobertura de chamadas e provas de resultados. Uma aplicação compacta pode impor quatro regras de promoção: 1. Cada attempt id esperado tem exatamente uma observação. 2. Cada chamada observada é rotulada approximate ou provider reported ; os rótulos nunca são silenciosamente fundidos. 3. Estimativas de pré vôo de instrumentos provam que o conjunto de esquemas foi passado para o balcão. 4. O fornecedor ou o detalhe do cache faltante permanece null /disponível e bloqueia apenas as decisões que o exigem. O limiar não precisa ser universalmente de 100%. Uma pré visualização não produtiva poderia permitir apenas cobertura aproximada. Um alerta de orçamento ou um reembolso ao cliente não devem. A context warning pode aceitar estimativas, enquanto a cost reconciliation requer o uso completo do provedor e IDs únicas de tentativa. Verifique o limite antes de otimizar O incumprimento razoável é simples: estimar antes, observar depois, a cobertura da auditoria na fronteira de execução. Otimizar apenas após os três trabalhos. Se uma estimativa de contexto for elevada, inspecione as suas entradas antes de cortar. O conjunto completo de ferramentas estava incluído? Os resultados das ferramentas ainda são necessários para a próxima decisão? Uma mensagem longa é um recibo de decisão duradouro ou uma narrativa substituível? Remover o contexto errado pode tornar a corrida mais barata e menos confiável. Se o uso do provedor for inesperadamente baixo, verifique se faltam chamadas antes de celebrar. Os blocos de streaming de confirmação foram combinados na mensagem final, os callbacks foram propagados para executáveis infantis, as retries receberam IDs de tentativa distintas e a fase de verificação esperada foi realmente executada. Um gráfico de custos com intervalos faltantes não é um resultado de otimização. Se o armazenamento no cache for importante, exigir o mapa de detalhes específico do fornecedor e registar a sua disponibilidade. A LangChain dá lhe um envelope comum, mas os provedores não necessariamente povoam todos os componentes. Não deduzir uma falta de cache a partir de uma chave faltante. Compare como com como: mesmo provedor, modelo, interface de prompt/ ferramenta, estado de cache e requisito de resultado. Finalmente, junte provas simbólicas a um recibo de tarefa. Para um agente de revisão de documentos, o recibo pode conter a revisão da fonte, seções necessárias verificadas, afirmações falhadas e hash de saída. Os tokens por chamada bem sucedida ainda são um denominador fraco se o artefato final estiver ausente. Este projeto de dois trilhos é intencionalmente mais estreito do que uma pilha de observabilidade genérica. Responde a uma decisão concreta: se um número de token LangChain é uma estimativa de contexto, uma medição observada do fornecedor ou uma visão incompleta que não deve gerar reclamações de custo ou otimização. A Sidewisp está atualmente em prévia privada. As análises de utilização de tokens e custos estimados são planejadas, não enviadas. A orientação do produto consiste em conectar os sinais de custo a progressos úteis e resultados verificados, mantendo visíveis as evidências e a incerteza. Se esse limite operacional coincidir com a forma como diriges os agentes, podes fazer o Junte se à pré visualização privada. Fontes Referência Python LangChain: count tokens approximately Impressão de fonte de LangChain para o contador aproximado Manual de mensagens LangChain: uso de tokens em AIMessage Referência LangChain: UsageMetadata Referência LangChain: UsageMetadataCallbackHandler