LLM Observabilidade para tempestades de retiro: custo por resultado verificado

A observabilidade LLM deve contar tokens, latência, erros e chamadas de modelo. Para um agente que pode tentar trabalhar novamente, isso é apenas o numerador. O denominador operacional é o número de resultados previstos verificados no destino. Um sinal de custo útil é, por conseguinte, o seguinte: Mantenha o custo, o proprietário e o status do resultado sob um run id estável. Não dividir o gasto por respostas bem sucedidas da API ou pela própria mensagem complete do agente. Ambos podem parecer saudáveis enquanto um fluxo de trabalho se repete, um resultado está ausente, ou duas camadas silenciosamente tentam novamente o mesmo fracasso. Este guia aplica essa regra a um experimento fixo de oito corridas. A coorte estável custa 0,012 dólares por resultado verificado. A coorte de tempestade de retry parece custar US $ 0,041 por conclusão declarada, mas sua verificação de destino prova apenas um resultado, então o número real é US $ 0,123 10,3 vezes a coorte estável. Os montantes em dólar são sintéticos; o erro contabilístico é real e reproduzível. Manter a camada de observabilidade normal do LLM O padrão razoável ainda é a telemetria de chamadas de modelo. Recorde a duração da solicitação, os tokens de entrada e saída, a classe de erro, o provedor, o modelo, a operação e a correlação de rastreamento. Esses sinais dizem se um provedor desacelerou, um contexto ampliado, um modelo alterado ou uma chamada falhou. O OpenTelemetry Convenções métricas GenAI atual faz esse concreto de base. No compromisso fixado de 24 de julho de 2026, eles definem gen ai.client.token.usage e gen ai.client.operation.duration . Eles também definem os números de inferências e de chamadas de ferramentas a nível do agente. O documento marca as convenções Development , por isso fixa a versão que implementar e espera que os campos se movam. O uso de tokens não é automaticamente um custo. Um fornecedor pode devolver contas de tokens faturáveis, um gateway pode calcular uma estimativa e uma fatura pode posteriormente conciliar o montante. Mantenha a proveniência ao lado do valor: Use um identificador de execução opaco. As instruções, as respostas, as credenciais, os argumentos das ferramentas, o conteúdo do cliente e os caminhos absolutos não pertencem a uma dimensão de custos. O rastro protegido pode permanecer disponível para investigação autorizada; o agregado só precisa de informações suficientes para localizar a tentativa e explicar a sua contabilidade. Os gráficos por chamada continuam a ser valiosos. Eles simplesmente respondem a uma pergunta diferente. Um custo decrescente por resposta modelo pode coexistir com tentativas crescentes por fluxo de trabalho. Uma tentativa de repetição bem sucedida pode reparar um erro de fornecedor transitório enquanto oculta que a mesma tarefa também foi repetida por uma fila e depois pelo agente. O modelo telemétrico descreve as chamadas. A contabilidade descreve a promessa. Fazer do resultado verificado o denominador Defina o resultado antes da execução. O modelo de texto devolvido é um resultado de chamada. A solicitação de puxão tem o compromisso esperado, o relatório existe sob a chave acordada, ou o mapa do site contém o URL publicado é um resultado. O recorde mínimo de corridas precisa de quatro estados: Estado Significado Tratamento dos custos Tratamento de saúde verified Um prédico nativo de destino aprovado Incluir o custo e aumentar o denominador Completado missing O agente declarou a conclusão , mas o predicado falhou . Incluir o custo; não aumentar o denominador Falso sucesso waiting Uma dependência nomeada ou decisão humana é excepcional Incluir custos; não o chame de sucesso ou fracasso ainda Rota para o proprietário da dependência unavailable O verificador não foi executado ou a sua evidência é obsoleta Incluir o custo conhecido; deixar desconhecido o índice se não existir denominador válido Investigar a cobertura das provas Esta distinção impede um atalho conveniente, mas destrutivo. Se uma pessoa não aprovou uma mudança, o agente está à espera; executar repetidamente o modelo não cria autoridade. Se o verificador estiver offline, tratar a sua ausência como falha pode desencadear efeitos colaterais duplicados. Se o agente disser "feito" mas o destino estiver vazio, tratar a declaração como um sucesso recompensa a falsa conclusão. Junte o registro de resultados às tentativas, em vez de copiar o entregado na loja de observabilidade: O verificador deve ser determinista sempre que possível. Verifique um hash de arquivo, linha de banco de dados, campo de API, resultado do teste ou estado de destino. Um avaliador qualitativo pode fornecer evidências quando o resultado não pode ser expresso como um predicado, mas sua versão, calibração e incerteza pertencem ao lado da pontuação. Reproduzir a diferença entre os custos de retestamento O experimento que acompanha utiliza oito corridas sintéticas: quatro estáveis e quatro numa tempestade de retest. Cada rodada contém tokens de nível de tentativa e campos de custo mais um estado final de resultado. A tempestade inclui um resultado verificado, duas declarações falsas de sucesso e uma aprovação legítima à espera. Salvar um objeto NDJSON por execução. Este par abreviado mostra a forma: Agrega todas as tentativas sob a sua coorte, e depois calcula: O conjunto completo e a auditoria mantidos com esta publicação produzem: Três observações alteram a decisão de exploração. Em primeiro lugar, o custo da tempestade por conclusão declarada subestima o custo por resultado verificado em 3x. A declaração do agente é um denominador de faturamento pobre. Em segundo lugar, a amplificação da tentativa aumenta de 1,25 para 3,00. Um painel de modelagem de chamadas pode mostrar doze chamadas individuais normais sem mostrar que elas pertencem a apenas quatro promessas. Terceiro, 62,6% do gasto de tempestade ocorre após as tentativas iniciais, e duas camadas diferentes possuem essas retrocidas. O problema não é apenas um modelo caro. É um caminho de controlo ilimitado. Este experimento não estima uma taxa de falha de produção. Os seus preços e os seus casos são construídos para testar a regra contabilística. Realize o mesmo cálculo com base na sua própria faturamento ou nos custos derivados do fornecedor, mantenha a versão fonte e preço e compare os fluxos de trabalho semelhantes ao longo do tempo. Dê uma camada para o orçamento de retomada Os retros são muitas vezes corretos. Uma solicitação acelerada ou um erro transitório da rede podem ser bem sucedidos após um atraso. A falha começa quando cada camada decide independentemente que possui a recuperação. O Orientação sobre o limite de taxa da OpenAI recomenda um backup exponencial aleatório e adverte que os pedidos fracassados ainda contribuem para o limite por minuto. A reencaminhamento contínuo consome, portanto, a capacidade necessária para a recuperação. O Referência de retestamento do AWS SDK atual documenta os mesmos princípios de controle em uma configuração de API mais ampla: tentativas máximas limitadas, retrocesso exponencial com jitter e um balde de tokens de retry quota que interrompe retry quando seu orçamento é esgotado. Estas fontes não prescrivem uma política universal de agentes. Eles apoiam um contrato mais seguro: 1. Escolha um proprietário de retest para uma operaçãonormalmente a camada mais baixa que possa classificar o erro transitório e preservar a idempotencia. 2. Contar a solicitação inicial e todas as recorrências contra uma tentativa de execução e orçamento de custos. 3. Propagar metadados para cima para que um executor de fluxo de trabalho não confunda o erro final de um SDK com uma primeira falha. 4. Faça os estados não retraiíveis explícitos: permissão negada, entrada inválida, autoridade faltante e verificação de resultados falhados precisam de roteamento ou investigação, não repetição cega. 5. Pare quando o tempo, a tentativa ou o orçamento de custos estiverem esgotados. Retorna um estado visível com as últimas provas. 6. Verifique o destino depois de uma nova tentativa. Um comando que retorna com sucesso não é o resultado prometido. As temporadas precisam de cuidados especiais. Um timeout do cliente não prova que o lado remoto não fez nada. Antes de tentar novamente uma ferramenta de efeitos colaterais, use uma chave de idempotency ou consulte o destino. Caso contrário, um sistema de observabilidade pode relatar corretamente a segunda tentativa enquanto o sistema de negócios recebe duas faturas, mensagens ou publicações. Alerta sobre regressão, depois inspecione o resultado Não me fales de mais uma vez. Comece com linhas de base específicas do fluxo de trabalho e exige persistência. Um primeiro aviso útil pode combinar três condições: Ajuste esses valores ao fluxo de trabalho. Um processo de lote com ventilador barato e idempotente pode tolerar mais tentativas. Um fluxo de trabalho de pagamento, publicação ou mensagens de clientes pode permitir menos. O fornecedor separado é atropelado por falhas na ferramenta e por um resultado de destino ausente. Eles têm diferentes proprietários e diferentes ações de segurança. O alerta deve indicar a promessa afetada, as tentativas totais, os proprietários de retestes, a proveniência dos custos, o resultado e a frescura do verificador e a próxima ação limitada. Uma mensagem útil diz: A publicação do relatório usou 12 tentativas no SDK e no workflow runner; o gasto de retest é de 63%; um dos quatro resultados é verificado; inspecione a propriedade de retest e o verificador de sitemap. Não deve dizer apenas Costo de token alto. Há dois limites importantes. Os dados de custo podem ser atrasados, estimados ou incompletos, portanto, mostre cobertura e não fabrice zeros. Os controlos de resultados também podem falhar de forma independente, de modo que o unavailable deve permanecer distinto do missing . Uma corrida waiting legítima permanece fora do denominador verificado sem ser rotulada como presa até que a sua dependência ou prazo mudem. A direção do produto da Sidewisp inclui o custo como um sinal de saúde ao lado da disponibilidade, execução, memória, ferramentas e resultados. Pretende se que funcione ao lado dos horários de execução existentes, não se torne um portal de modelo obrigatório ou um fixador autônomo. A Sidewisp está atualmente em prévia privada. O site público e a biblioteca de artigos estão ao vivo; adaptadores de monitoramento de produção, análise de custos de tokens e execução de recuperação geralmente não são enviados. Junte se à pré visualização privada se quiser ajudar a moldar como as provas, os custos e os resultados verificados devem ser encontrados enquanto os seres humanos mantêm a autoridade.