Como detectar a degradação de um recurso de IA?

Um recurso de IA se degradou quando os usuários recebem menos valor por tentativa, mesmo que todas as solicitações ao modelo retornem HTTP 200. Essa definição importa. O recurso pode continuar tecnicamente disponível enquanto as respostas perdem utilidade, ficam lentas, cedem lugar a um fallback, dobram o consumo de tokens e fazem usuários irem embora em silêncio.

Já vi equipes declararem uma correção bem-sucedida porque o gráfico de erros voltou ao verde, embora a taxa de conclusão continuasse caindo. Elas mediram a chamada ao provedor, não o resultado do usuário. Verificar a produção exige um registro por solicitação que conecte o caminho inteiro: o que o usuário tentou fazer, quais versões do aplicativo e do modelo processaram a tentativa, quanto cada etapa levou, o que o modelo produziu, se houve fallback, quanto custou e o que o usuário fez depois.

As seis famílias de sinais deste artigo respondem a perguntas diferentes. A latência mostra se o recurso responde dentro do período em que ainda é útil. A taxa de erros encontra falhas explícitas e disfarçadas. As verificações de qualidade determinam se a resposta cumpre a tarefa. O uso de fallback expõe uma perda de capacidade escondida. O gasto com tokens encontra prompts e loops ineficientes. O abandono mostra quando usuários param de esperar ou de confiar. Uma correção só fica comprovada quando a coorte afetada melhora nos sinais relevantes sem piorar outro.

Comece com um evento para cada tentativa

Um evento por solicitação é a menor unidade útil para monitorar IA em produção, pois médias não conseguem religar uma chamada lenta, uma resposta ruim e o usuário que desistiu. Emita um registro quando a tentativa chegar a um estado terminal. Dê a ela um ID de solicitação opaco e associe esse ID a traces, avaliações, registros de custo e eventos do produto. Não registre prompts ou respostas brutos por padrão. Guarde conteúdo editado, hashes, classificações ou uma referência sujeita às regras de retenção.

O evento precisa de dimensões suficientes para comparar casos equivalentes. Registre pelo menos recurso e tarefa, versões do aplicativo e do prompt, modelo e provedor, classe de cliente ou plano, região, faixa de entrada, uso de streaming, status, tentativas adicionais, motivo do fallback, tokens de entrada e saída, latência do primeiro token e total, resultado de qualidade e ação posterior. Use rótulos limitados nas métricas. IDs de solicitação e valores de alta cardinalidade pertencem aos logs ou traces, não aos rótulos.

Um evento terminal pode ter esta forma:

{"request_id":"req_7f2c","feature":"support_reply","task":"draft","app_version":"2026.07.4","prompt_version":"p18","model":"model-a","region":"eu-west","input_band":"1k-4k","status":"success","retry_count":1,"fallback":"none","latency_ms":4820,"first_token_ms":910,"input_tokens":1824,"output_tokens":436,"quality":{"policy_pass":true,"schema_pass":true,"grounded":"unknown"},"user_action":"accepted","action_delay_ms":6400}

Esse registro é um contrato de instrumentação, não um esquema universal. Um recurso de recuperação também precisa de contagem de resultados, estado vazio, IDs ou classes de fontes e validade das citações. Um agente precisa de quantidade de chamadas de ferramentas, categoria de falha, motivo de término do loop e estado dos efeitos colaterais. Um classificador precisa da classe prevista, faixa de confiança e verdade de referência quando ela chegar.

As convenções semânticas do OpenTelemetry oferecem um vocabulário comum para duração de operações, atributos de modelo e uso de tokens. Use esses nomes quando sua instrumentação aceitar, mas mantenha os campos de resultado do produto ao lado deles. Um span padrão do modelo não sabe que um cliente aceitou um rascunho ou fechou a janela. Essa última junção pertence ao aplicativo.

Antes de mudar o código, capture uma janela de referência com a mesma mistura de tráfego que será usada na verificação. Salve a consulta, os filtros da coorte, os tamanhos das amostras e o fuso horário do painel. Comparar o tráfego empresarial de segunda-feira ao tráfego gratuito de domingo pode mexer mais no gráfico do que a correção.

A latência da cauda revela a falha sob tráfego

A degradação de latência costuma aparecer na cauda antes de alterar a média. Acompanhe mediana, p90, p95 e p99 da latência total, além do tempo até o primeiro token para respostas em streaming. A mediana descreve a solicitação comum. Os percentis altos expõem filas, limites de taxa, partidas a frio, contextos longos, novas tentativas e uma região ou classe pequena que a média esconde.

Meça pelo menos quatro limites: do clique no navegador à resposta visível, o tempo do servidor do aplicativo, a chamada ao provedor e o pós-processamento. O provedor pode continuar rápido enquanto a recuperação ou o banco de dados trava. O servidor pode parecer saudável enquanto o navegador espera por um stream bloqueado. Um único cronômetro leva a equipe a corrigir a dependência que já tem gráfico.

Defina o objetivo de serviço pela tolerância dos usuários, não por um número redondo conveniente. Em um recurso de redação, você pode exigir que 95% das tentativas elegíveis mostrem o primeiro token útil dentro da janela de paciência medida no produto. Em uma extração em segundo plano, o tempo total importa mais. Tire esses limites da linha de base e da pesquisa de produto; não copie os de outro recurso.

Histogramas do Prometheus permitem agregar percentis quando os limites dos buckets correspondem à decisão. A documentação do Prometheus alerta que resumos no cliente e histogramas no servidor têm propriedades de agregação diferentes. Para um histograma clássico, uma consulta útil por versão é:

histogram_quantile(0.95,
  sum by (le, app_version) (
    rate(ai_feature_duration_seconds_bucket{feature="support_reply",status="success"}[10m])
  )
)

Exclua falhas apenas quando um gráfico de erros as mostrar ao lado. Caso contrário, remover timeouts faz a latência parecer melhor durante uma pane. Mantenha visões separadas para chamadas bem-sucedidas, todas as tentativas terminais e timeouts. Mostre também o volume, pois um p95 menor durante o colapso do tráfego não significa recuperação.

No streaming, a latência do primeiro token e a total podem seguir direções opostas. Uma mudança no prompt pode gerar um token cedo e divagar pelo dobro do tempo. O recurso parece ágil enquanto pioram o custo computacional e o tempo até uma resposta útil. Trate os dois tempos como verificações de lançamento independentes.

Depois da correção, compare as distribuições do segmento afetado e de um controle inalterado. Exija observações suficientes para preencher a cauda; um p99 baseado em poucas tentativas não prova nada. Observe também o crescimento das novas tentativas e a profundidade da fila. Um p95 menor comprado pelo abandono de mais solicitações com um timeout curto é uma troca, não uma correção.

Conte falhas silenciosas junto com exceções

A taxa de erros deve incluir qualquer tentativa incapaz de entregar o resultado prometido, não apenas exceções e respostas fora de 2xx. Timeouts do provedor, limites de taxa, saída estruturada inválida, respostas vazias, recusas de política, falhas de ferramentas, recuperação sem fonte útil, rejeição de validação e tentativas esgotadas precisam de categorias terminais explícitas. Se o aplicativo trocar tudo por um texto simpático e retornar 200, o usuário ainda sofreu uma falha.

Use estados terminais mutuamente exclusivos para manter o denominador honesto. Comece com success, user_error, system_error, policy_block e abandoned, depois guarde um motivo específico. Decida por escrito se um resultado parcial conta como sucesso. Um relatório sem uma seção obrigatória pode ser sucesso parcial no editor e erro do sistema em uma exportação automática.

A verificação básica é tentativas elegíveis com falha / todas as tentativas elegíveis. Tire erros do usuário, como um arquivo incompatível explicado antes da inferência, do numerador de confiabilidade, mas mostre-os separadamente. Uma alta pode revelar uma interface confusa ou mudança nas entradas. Mostre taxa e contagem juntas. Uma falha em duas tentativas e quinhentas em um milhão apresentam problemas opostos que o percentual sozinho esconde.

Novas tentativas precisam de taxa e distribuição próprias. A Amazon Builders' Library explica que elas acrescentam carga a uma dependência talvez já sobrecarregada e que várias camadas podem multiplicar o trabalho. Isso se aplica diretamente às chamadas de IA, lentas e caras o bastante para tornar a amplificação dolorosa. Registre a camada, limite as tentativas, use recuo com aleatoriedade e emita a falha original mesmo quando uma tentativa posterior funcionar.

Observe erros recuperados como sinal inicial. Se o sucesso não muda, mas cresce a parcela que precisa de uma segunda ou terceira chamada, a capacidade ou a dependência já se degradou. O usuário percebe mais latência e a equipe financeira vê mais gasto antes que a disponibilidade se altere.

Alerte para consumo rápido e lento. Um pico abrupto pede uma janela curta, enquanto um parser de prompt que falha um pouco mais durante dias pede comparação longa. Divida por versão, modelo, prompt, região, classe de cliente, faixa de entrada e tarefa. Não dispare uma alerta por fatia; use uma alerta geral e as fatias para localizar a origem.

Para verificar uma correção, exija que o motivo afetado volte ou supere a referência enquanto o total de falhas cai. Senão, o código pode apenas ter renomeado a mesma falha. Inspecione uma amostra de eventos terminais e confirme que o status corresponde ao que o usuário recebeu.

A qualidade precisa de verdade tardia e sinais ao vivo

Qualidade de saída não é disponibilidade. Uma resposta fluente pode estar errada, sem apoio, incompleta, insegura, fora do formato ou irrelevante enquanto a infraestrutura parece perfeita. Meça com uma rubrica específica da tarefa e separe restrições rígidas de julgamentos graduais. Juntar tudo em uma nota esconde a falha.

Execute verificações rígidas em toda resposta elegível quando possível. Valide o JSON contra o esquema, campos obrigatórios contra regras de negócio, citações contra fontes recuperadas, argumentos de ferramentas contra listas permitidas e idioma contra a localidade pedida. Registre cada teste como booleano ou motivo nomeado. Nunca deixe uma média anular uma violação de esquema que quebra a próxima etapa.

A avaliação gradual precisa de amostra estável e critérios observáveis. Para um rascunho de suporte, avalie se responde ao cliente, usa fatos do contexto aprovado, evita inventar políticas e oferece uma solução acionável. Guarde a versão da rubrica, do avaliador e da regra de amostragem. Quando o avaliador mudar, rode as versões antiga e nova na mesma amostra antes de unir as séries.

Avaliadores automáticos servem para ampliar a cobertura, não como verdade incontestável. Calibre-os com revisão humana, meça divergências por tarefa e idioma e envie casos incertos ou de alto impacto a pessoas. Um modelo avaliando outro pode mudar quando qualquer um deles muda. Se o prompt de avaliação tiver o mesmo ponto cego do prompt de produção, o gráfico pode aprovar um trabalho ruim com confiança.

A orientação do Google sobre ML em produção faz uma distinção importante: a verdade de referência ao vivo costuma chegar tarde ou nunca, então as equipes precisam de métricas substitutas e devem observar mais as mudanças do que um valor bruto isolado. Para recursos generativos, bons sinais incluem aprovação do esquema, suporte das citações, distância de edição antes da aceitação, regeneração, cópia ou aceite, reclamações e conclusão posterior. Nenhum vale para tudo. Muita cópia pode indicar um ótimo rascunho ou usuários levando o texto para outro lugar a fim de consertá-lo.

Crie um pequeno conjunto continuamente rotulado com tarefas reais e editadas de produção. Faça amostragem pelas fatias importantes, não de modo puramente aleatório, ou a tarefa fácil mais comum dominará. Inclua falhas, entradas longas, idiomas raros, clientes novos e pedidos perto dos limites de política. Revise o mesmo conjunto sentinela em cada versão e acrescente uma amostra rotativa para capturar mudanças no tráfego.

Declare degradação quando uma taxa rígida ultrapassar seu limite, um critério gradual cair de modo relevante abaixo da referência com amostra suficiente ou um sinal de usuário mudar na mesma direção das avaliações humanas. Não procure uma nota mágica. A evidência fica mais forte quando restrições, revisores e comportamento concordam, e mais interessante quando divergem.

Uma correção passa quando o critério falho melhora na fatia original sem regredir segurança ou outro critério de alto impacto. Leia exemplos anteriores e posteriores. Notas agregadas dizem que algo mudou; exemplos pareados dizem se o defeito real foi corrigido.

O fallback esconde perda de capacidade

Um fallback pode manter a página disponível quando o recurso de IA já falhou. Acompanhe a taxa como tentativas que retornaram fallback / tentativas elegíveis, separada por tipo e motivo. Meça também o sucesso do ponto de vista do usuário. Conselho estático, resposta em cache, modelo menor e fluxo manual não entregam o mesmo serviço.

Nomeie cada caminho: troca de provedor, modelo inferior, cache, modelo determinístico, recurso desligado ou transferência humana. Registre se a troca ocorreu antes da inferência, depois de uma chamada falha, após a validação ou após a espera do usuário. O momento explica se a causa foi capacidade, qualidade, política ou latência.

Equipes costumam incluir fallbacks bem-sucedidos na taxa principal de sucesso. A disponibilidade parece estável enquanto a capacidade pretendida some. Publique duas taxas: sucesso do caminho principal e sucesso do resultado útil. A diferença mede dependência de fallback. Se o caminho principal cai e o resultado se mantém, o fallback funciona e o caminho principal continua degradado.

Defina um orçamento de fallback com base nas promessas do produto e no planejamento de capacidade. Um modelo alternativo pode servir para incidentes curtos, mas ser caro ou pior durante uma semana. Um modelo de texto evita uma tela vazia, mas não conta como resposta de pesquisa completa. Acrescente uma duração contínua máxima ao limite da taxa para o baixo tráfego não esconder um fallback ligado a noite inteira.

Teste esses caminhos com injeção controlada de falhas. Simule timeout, saída inválida, cota esgotada, contexto ausente e rejeição de validação. Confirme que o evento terminal registra causa original, fallback escolhido, latência adicional e resultado do usuário. Um caminho nunca exercitado costuma falhar junto com o principal.

Após a correção, o sucesso principal deve voltar e o fallback retornar à referência. Verifique se ninguém apenas desativou o contador ou moveu a ramificação. Compare chamadas ao provedor com sucessos principais; diferenças sem explicação revelam outra tentativa ou caminho não instrumentado.

O gasto com tokens deve seguir um resultado concluído

O gasto vira sinal de degradação quando o recurso consome mais tokens de entrada ou saída para a mesma tarefa bem-sucedida. O total diário mede principalmente o tráfego. Acompanhe tokens de entrada, saída e cache, além do custo monetário por tentativa, e normalize por resultado aceito ou concluído.

Medidas úteis incluem tokens por tentativa elegível, por sucesso principal, custo por saída aceita e por tarefa posterior concluída. As duas últimas impedem que um modelo barato e inútil pareça eficiente. Divida por modelo, prompt, recurso, tarefa, faixa de entrada, tentativas e fallback. Mantenha preços em uma tabela versionada, em vez de gravar tarifas atuais nos eventos históricos.

As convenções de IA generativa do OpenTelemetry definem atributos de tokens e duração, distinguindo entrada e saída. Elas fornecem um bom vocabulário de transporte. O aplicativo ainda precisa conectar o uso a accepted, edited, regenerated, abandoned ou ao resultado que gera valor.

O crescimento do prompt merece alertas diretos. Separe tokens de instruções estáticas, conteúdo do usuário e contexto recuperado quando possível. Um erro de template pode duplicar a conversa, a recuperação repetir trechos ou um agente entrar em loop. Limites de saída podem esconder o custo por truncamento e piorar a qualidade, então acompanhe motivo de término e taxa de truncamento.

Faça conciliação entre eventos do aplicativo e exportações de cobrança. A telemetria pode se perder, novas tentativas podem contornar o wrapper e o provedor pode contar tokens de cache ou raciocínio de forma diferente. Sem IDs do provedor, não é preciso casar cada solicitação, mas totais por modelo e período devem ficar dentro da tolerância combinada. Investigue o resíduo em vez de aplicar um fator silencioso.

Uma alerta prática compara custo por resultado bem-sucedido com um orçamento fixo e uma referência recente comparável. Exija volume mínimo e exclua experimentos com orçamento próprio. Depois associe a alerta às distribuições de tokens. Uma média maior pode vir de mais entradas longas, mas um p50 maior em todas as faixas aponta para crescimento do prompt ou fluxo.

Uma correção que reduz tokens, mas derruba o aceite ou aumenta o fallback, transferiu o custo aos usuários. Verifique tokens e dinheiro na mesma coorte, depois os limites de qualidade, conclusão e latência. Eficiência é trabalho útil por unidade de gasto, não a menor conta.

O abandono conecta a saúde do sistema à paciência

O abandono é a evidência mais clara de que o recurso perdeu sua janela útil, mas exige definição exata. Conte como abandonada a tentativa em que o usuário fecha ou sai antes de um resultado útil, cancela a geração, inicia outra sem usar a primeira ou fica inativo além do limite do recurso. Mantenha esses motivos separados.

O denominador deve conter tentativas elegíveis que realmente começaram. Não divida por visualizações de página nem trate toda desconexão como abandono sem verificar se o trabalho continuou e o usuário voltou. Em tarefas de segundo plano, abandono pode ser apagar a tarefa ou nunca abrir o resultado no período definido. Em um assistente embutido, cancelar e repetir de imediato é um sinal mais forte.

Instrumente navegador e servidor com o mesmo ID. Emita tempos de envio, primeiro token visível, resultado útil, cancelamento, navegação, nova tentativa, aceite, edição e conclusão posterior. Eventos do cliente podem desaparecer ao fechar a aba, então use heartbeat ou entrega do tipo sendBeacon quando adequado e marque resultados incertos. Não classifique todo evento ausente como usuário perdido.

Mostre abandono por faixas de latência. Isso revela a curva de paciência: parcela abandonada antes de 2, 5, 10 segundos e depois, com limites adequados ao recurso. Compare o tempo até a primeira saída útil, não qualquer token. Um preâmbulo rápido e inútil melhora o primeiro token sem reter ninguém.

Meça também regeneração e correção. Usuários podem esperar uma resposta ruim e tentar de novo em vez de sair. Combine abandoned, cancelled e regenerated_before_use em uma visão ampla de falhas, preservando cada componente. Aceite sem edição ajuda, mas fluxos obrigatórios e cliques acidentais o tornam imperfeito.

Sazonalidade e intenção complicam o comportamento. Separe usuários novos e recorrentes, tarefa, dispositivo e entrada. Compare mesma hora e dia quando os padrões de tráfego importarem. Use um recurso inalterado ou controle se lentidão geral, campanha ou mudança de interface puder afetar o comportamento.

Depois da correção, a coorte afetada deve abandonar menos sob tráfego e intenção comparáveis. Confirme que os inícios não caíram porque o botão ficou difícil de achar. Verifique a conclusão posterior; prender usuários diante de um indicador por mais tempo pode reduzir saídas registradas e piorar a experiência.

Segmente primeiro e agregue depois

A maioria das falhas afeta uma fatia antes de toda a frota. Um prompt novo pode quebrar entradas em espanhol, uma rota falhar numa região, uma mudança de recuperação prejudicar documentos longos ou os dados de um cliente disparar um loop. Médias globais diluem cada caso.

Anexe dimensões ligadas a algo que você pode mudar: versões do aplicativo e prompt, modelo, provedor, região, recurso, tarefa, localidade, faixa de entrada, versão do índice, grupo do experimento e fallback. Para agentes, acrescente ferramenta e motivo de término. Use classes de clientes que preservem privacidade em vez de identidades nos painéis.

Não transforme todo valor em rótulo de métrica. Alta cardinalidade encarece o monitoramento e prejudica as consultas. Defina faixas limitadas de entrada, saída, latência e cliente. Mantenha detalhes exatos em traces ou logs e passe de um agregado suspeito a tentativas representativas.

Toda comparação de versão precisa de uma tabela de coortes. Mostre contagem e parcela do tráfego ao lado de latência, falhas, verificações rígidas, fallback, custo por resultado e abandono. Compare candidato e controle, atual e referência. Se a composição do tráfego mudou, estratifique ou repondere antes de afirmar melhora.

O paradoxo de Simpson é comum. Cada tarefa pode ficar mais lenta enquanto a média melhora porque mais tráfego passou a uma tarefa rápida. O oposto pode condenar uma boa versão que recebeu entradas difíceis. Examine mudanças dentro de cada tarefa antes do número combinado.

Canários separam efeitos da versão e do tempo. Envie uma parcela estável e determinística do tráfego elegível ao candidato, mantenha a atribuição fixa por usuário ou fluxo e registre elegibilidade e atribuição. Se apenas atribuições bem-sucedidas chegarem à análise, o experimento já tem viés de sobrevivência.

Fatias pequenas pedem cuidado. Mostre intervalos de confiança ou incerteza, imponha contagens mínimas e combine janelas vizinhas quando possível. Não ignore uma falha grave porque a amostra é pequena; revise os exemplos e aplique uma regra rígida de segurança. Confiança estatística e gravidade operacional respondem a perguntas diferentes.

Essa segmentação frequentemente expõe código de aplicativo gerado por IA que espalhou chamadas ao modelo por várias rotas sem wrapper comum. A FixMyMess usa diagnóstico de código e verificação especializada ao reparar esse tipo de caminho de produção, mas o resultado duradouro ainda depende de um contrato de instrumentação que todo código futuro deve seguir.

Uma correção só passa com uma regra de evidência escrita

Uma correção termina quando uma comparação definida antes mostra recuperação do sinal quebrado, protege os outros sinais e resiste ao tráfego real pelo tempo necessário para cobrir a falha. «O gráfico parece melhor» não é critério de aceitação. Escreva a regra antes de implantar para a equipe não escolher depois uma janela favorável.

Use esta sequência para um incidente ou correção planejada:

1. Congele a coorte do incidente. Registre recurso, tarefa, versões, rota do modelo, regiões, faixas de entrada e período afetados. Guarde IDs representativos sem conteúdo sensível.
2. Declare a falha em termos mensuráveis. Nomeie métrica principal, referência, valor observado, limite e amostra mínima. Acrescente proteções para erros, qualidade rígida, fallback, custo por resultado e abandono.
3. Implante num canário determinístico. Confirme a integridade da telemetria antes de julgar o código. Candidato e controle devem receber tráfego comparável, e toda tentativa deve chegar a um estado terminal.
4. Compare distribuições e exemplos. Compare candidato com controle e os dois com a referência histórica. Revise tarefas falhas pareadas ou o conjunto sentinela para uma média não esconder o defeito original.
5. Promova, segure ou reverta pela regra escrita. Continue observando durante o próximo ciclo relevante e registre resultados das consultas, versões e decisão.

Uma regra pode dizer: a latência total p95 para documentos longos deve voltar abaixo do limite anterior sobre a contagem combinada; timeouts e fallback não podem superar a referência; esquema e notas humanas não podem cair; custo por rascunho aceito deve respeitar o orçamento; abandono deve melhorar contra o controle. Seus valores devem vir da referência e tolerância a risco do produto.

A integridade da telemetria faz parte da regra. Compare inícios e eventos terminais, chamadas ao provedor e uso, ações aceitas e taxas conhecidas de entrega do cliente. Se uma versão perde 15% dos eventos terminais, todas as taxas seguintes podem parecer melhores. Bloqueie a promoção quando os dados ausentes puderem mudar a conclusão.

Separe critérios de reversão dos limites de alerta. Uma alerta pede investigação. Uma regra de reversão afirma que o candidato causou dano suficiente para interromper a exposição. Violações de segurança ou qualidade podem exigir reversão imediata por um caso confirmado, enquanto uma mudança modesta de latência precisa de amostra estável.

Execute uma avaliação sombra ou replay quando a exposição real for arriscada, mas não a chame de prova de produção. Replays não reproduzem filas ao vivo, limites do provedor, navegador, mudanças nos dados recuperados nem reações dos usuários. Eles reduzem incerteza antes do canário; não o substituem.

O pacote final deve deixar um engenheiro cético reproduzir a decisão: coorte, texto das consultas, definições, janelas de referência e candidato, amostras, incerteza, exemplos revisados, cobertura da telemetria e resultado. Se não explica por que os usuários ficaram melhor e quanto isso custou, a correção continua sendo uma opinião.