Monitoramento LLM: O que medir além da latência, erros e tokens

A monitorização do LLM deve começar com a saúde do modelo de chamada: latência, erros, volume de solicitação, tokens e qualidade de saída. Esse é o padrão razoável para um recurso de bate papo, pipeline de recuperação ou API wrapper. Uma vez que o mesmo aplicativo pode planejar, chamar ferramentas, esperar a aprovação, retomar mais tarde, ou declarar uma tarefa completa, adicionar um segundo livro razão para a saúde operacional. Os dois livros respondem a perguntas diferentes. O primeiro pergunta: O serviço modelo se comporta normalmente? O segundo pergunta: O agente fez progressos úteis e produziu o resultado esperado? Junte se a eles com um run id ; não converta um gráfico de latência verde em uma alegação de que o trabalho é saudável. Comece com a camada de monitoramento LLM padrão Um primeiro painel útil não precisa de dezenas de painéis. Precisa de provas suficientes para separar a falha do fornecedor, a falha da aplicação, a derivação de custos e a derivação da qualidade de saída. O sinal Pergunta que responde Prático primeiro alerta O que não pode provar Taxa de erro de solicitação As chamadas de modelo estão a falhar? Taxa sobre uma janela, dividida por fornecedor e modelo Se as chamadas bem sucedidas avançaram na tarefa P50/p95 latência O tempo de resposta regressou? Comparar operações e modelos semelhantes Se uma corrida lenta eventualmente entregou Tokens de entrada/saída O contexto ou a geração cresceu? Mudança em relação a uma linha de base específica da tarefa Se os tokens extras foram úteis Capacidade de transmissão A carga está a mudar? Solicitações por minuto mais simultânea Se uma corrida programada foi perdida Pontuação de qualidade A produção da amostra atendeu se a uma rubrica? Avaliação de versões mais calibração humana Se existe um arquivo, bilhete ou implantação Cobertura de rastreamento Um operador pode reconstruir a execução? Traços perdidos ou incompletos por tempo de execução Se o resultado pretendido está presente Esta linha de base corresponde à intenção de busca atual. Langfuse descreve o monitoramento em torno da latência, do throughput e das taxas de erro, com traços para caminhos de execução e avaliação para a qualidade de saída. O Splunk e a Dynatrace expandem o conjunto para recursos, segurança, custo, feedback e sinais de aplicação. Estas são visões úteis de uma aplicação LLM; nenhuma deve ser descartada simplesmente porque existe uma camada de agente. As convenções semânticas GenAI da OpenTelemetry tornam a separação visível na própria instrumentação. A especificação de desenvolvimento define o gen ai.client.token.usage e o gen ai.client.operation.duration , em seguida, separando os instrumentos de fluxo de trabalho e agentes, tais como o gen ai.invoke agent.duration , contagem de ligações de inferência e contagem de ligações de ferramentas. Desenvolvimento importa aqui: fixa a versão que implementas e espera que os nomes mudem. A implementação limpa é um livro razão de chamadas de modelo teclado por run id , operation , provider , model e timestamp. Agregá lo para alertas de nível de serviço, mas mantenha um caminho de volta para a corrida individual. Um token spike sem um identificador de corrida é uma nota; um token spike ligado a uma corrida paralisada é uma pista de incidente. Adicionar um livro razão de tarefas quando a aplicação se torna um agente Um recurso apoiado pelo LLM atravessa o limite operacional quando possui trabalho ao longo do tempo. Pode ligar para um banco de dados, escrever um relatório, abrir um pedido de retirada, esperar uma pessoa ou acordar em um horário. Nesse ponto, as respostas de modelo bem sucedidas são apenas eventos intermediários. O OpenAI Agents SDK ilustra o quão rico esses eventos podem tornar se. Seu registro de rastreamento embutido gerações, chamadas de ferramentas funcionais, entregas, barris de segurança e corridas de agentes. É uma valiosa prova de depuração. A mesma documentação também observa que os intervalos de geração e função podem conter entradas e saídas sensíveis, o que é uma razão para fazer da captura de conteúdo uma escolha explícita e não um pré requisito de monitoramento. Um livro de tarefas de saúde pode ficar menor do que o rastro. Para cada corrida, registro: expected outcome : um prédicado como report exists and parses , não a frase terminar a tarefa; outcome verified : true , false ou unavailable , com versão verificadora; progress delta : uma alteração da contagem ou da digestão específica da tarefa durante uma janela declarada; waiting on : uma dependência denominada, como human approval ou null ; last heartbeat at e last progress at , porque a atividade e o progresso são relógios diferentes; declared complete : o que foi relatado no tempo de execução; collector freshness : quando estes fatos foram observados pela última vez. Este livro razão deliberadamente não repete cada prompt, conclusão ou período. Ele armazena a mínima evidência necessária para decidir se a corrida está funcionando, esperando, presa, inacessível ou completa. Os vestígios brutos permanecem disponíveis para investigação quando a política o permitir. A importante escolha de modelagem é a evidência de três estados. Se um colecionador não puder verificar o entregue, registar o outcome verified: "unavailable" . Não converta provas faltantes em true , e não chame uma corrida desconhecida falhada apenas porque o seu sinal está ausente. Reproduzir a diferença com seis corridas O equipamento de acompanhamento contém seis corridas sintéticas. Os alertas do livro razão LLM quando os erros de solicitação são pelo menos 20%, a latência p95 excede 5.000 ms, ou o uso de tokens excede 20.000. O livro de contabilidade de tarefas verifica a espera explícita, a conclusão declarada contra um resultado determinista e a frescura do progresso. Execute a auditoria com Node.js 20 ou mais recente: O resultado exato é: O desacordo é o resultado, não um defeito em nenhum dos livros. A operação de erro de fornecedor precisa de uma investigação de modelo de serviço, mesmo que o agente ainda esteja a fazer progressos. A corrida lenta foi concluída com um resultado verificado, por isso é um problema de desempenho e não um incidente de falta de trabalho. A espera de aprovação e a corrida de falso sucesso parecem normais para o monitor LLM porque suas chamadas eram rápidas, baratas e bem sucedidas. Só o contrato de tarefa expõe o que precisa de atenção. Os números são um contra exemplo, não um ponto de referência. Seis registos sintéticos não podem estabelecer limites universais de alerta. Substitua os limites com linhas de base do seu tempo de execução, e substitua o progress delta com evidências ligadas ao trabalho real. Transformar o contrato de tarefa em alertas Comece com um fluxo de trabalho de alto valor. Escreva seu predicado de conclusão antes de adicionar outro painel. Um trabalho de pesquisa pode exigir um arquivo Markdown, pelo menos duas fontes acessíveis e um livro de evidências válido de esquema. Um trabalho de codificação pode exigir um patch limpo mais um comando de teste nomeado. Um agente de apoio pode exigir um bilhete criado ou uma escalada gravada. Depois, avaliar os sinais numa ordem que preserve o significado: 1. Se o tempo de corrida ou o coletor estiver obsoleto, marque a corrida inacessível ou incerta. 2. Se o waiting on for explícito, encaminhe a dependência em vez de reiniciar a corrida. 3. Se o tempo de execução declarar a conclusão, avaliar o resultado predicado. 4. Se a corrida estiver ativa, mas o progress delta permanecer zero para além da janela, marque o preso. 5. Se nenhum for aplicável e o progresso útil for recente, deixe o funcionar. Esta ordem impede três intervenções barulhentas. Uma espera legítima de aprovação não é um estancamento. Um comando que saiu do zero não é automaticamente uma tarefa concluída. Um rastro ocupado com ferramentas repetidas não é progresso se o artefato relevante nunca mudar. Alerta sobre a próxima ação segura, não apenas o sintoma. Um alerta de erro do provedor vai para o proprietário do aplicativo com modelo, operação, classe de erro e link de rastreamento. Uma espera de aprovação vai para a pessoa que pode decidir, com o escopo exato solicitado. Um alerta de resultado faltante aponta para o predicado falhado. Um ciclo de repetição recomenda uma pausa ou investigação limitada; não deve autorizar uma correção irreversível. Mantém a junção útil sem coletar tudo Use um run id opaco em ambos os registros. Não coloque texto do cliente, segredos, caminhos absolutos ou cargas úteis de ferramentas nesse identificador. Um registro de correlação útil pode conter: Manter as regras de retenção e de acesso diferentes se os riscos dos dados forem diferentes. Os histogramas de latência e de tokens agregados podem necessitar de retenção mais longa do que os intervalos de carregamento de prompt. A evidência do resultado pode muitas vezes ser um digesto, contagem, código de status ou resultado de esquema em vez do artefato em si. Quando um operador perfurar em um rastro, mostrar a sua frescura e o limite de amostragem para que a ausência não seja confundida com a prova. Há também um limite para a avaliação automatizada. As verificações deterministas são preferíveis para arquivos, status HTTP, linhas de banco de dados, testes e campos estruturados. Se o resultado pretendido for qualitativo, um avaliador com versão pode ajudar, mas a sua pontuação é evidência com incerteza e não verdade baseada. Calibrá lo contra revisão humana e preservar um estado unavailable . Onde se encaixa o Sidewisp A direção do produto da Sidewisp é o segundo livro: uma visão de saúde em torno dos tempos de execução dos agentes existentes, com evidências, frescura, prioridade da emissão e limites explícitos de aprovação. Não se destina a substituir o tempo de execução, o modelo de gateway ou o sistema de rastreamento bruto. Essa é a direcção, não uma alegação de monitoramento enviado. A Sidewisp está atualmente em prévia privada. O site público e o sistema de artigos estão ao vivo, enquanto a coleta de agentes de produção e saúde, os adaptadores de tempo de execução e a execução de recuperação geralmente não são enviados. Junte se à visualização privada se esta fronteira modelo chamada versus resultado coincidir com o problema operacional que você precisa resolver. Fontes primárias OpenTelemetry GenAI métricas convenções semânticas nomes métricos de status de desenvolvimento para operações de cliente, fluxo de trabalho, agente e ferramenta. Guia de rastreamento do SDK OpenAI Agents tipos de eventos rastreados, comportamento de exportação e controles de dados sensíveis. Langfuse: O que é a observabilidade e monitoramento do LLM? um indicador de referência da mesma intenção para a latência, o rendimento, os erros, o rastreamento e a avaliação.