Degradação de qualidade em agentes de IA ao longo do tempo

A degradação de qualidade em agentes de IA ao longo do tempo (em inglês, drift) é a queda gradual na forma como o agente faz o seu trabalho, mesmo sem que ninguém tenha mudado a sua função. Ela aparece como pequenos desvios de precisão, tom, uso de ferramentas e julgamento que, isoladamente, parecem inofensivos. A forma confiável de detectá-la é comparar o trabalho atual com uma referência fixa, em intervalos regulares, em vez de esperar por reclamações.

Principais pontos

• A degradação é lenta e raramente tem uma causa única: atualizações de modelo, instruções editadas, documentos desatualizados, integrações alteradas e uma mudança no tipo de pedido contribuem juntos.
• Os usuários costumam reagir adicionando verificações manuais em silêncio, então o primeiro sinal de perda de confiança geralmente é um improviso, não uma reclamação.
• Os sinais iniciais são mensuráveis: padrão de edições dos revisores, padrão de escalonamentos, tarefas reabertas, repetições e mudanças na forma como as respostas citam as fontes.
• Um conjunto pequeno de testes fixos, mais uma amostra nova de trabalho real recente, avaliados sempre com a mesma régua, mostra a direção da mudança.
• Toda degradação confirmada exige uma decisão registrada: adotar, ajustar, reverter ou pausar, com uma pessoa responsável pelo nome.

O que é a degradação de um agente de IA e como ela difere de um erro?

Um erro é súbito e reproduzível. Algo quebra em determinado dia, você consegue mostrar o caso que falha e a correção é clara. A degradação é o oposto: nada quebra, e a resposta continua fluente e plausível. Ela só fica um pouco menos correta, um pouco menos completa ou um pouco menos alinhada com o jeito de trabalhar da sua empresa do que estava no lançamento.

Por isso a degradação é mais perigosa do que parece. Um agente costuma ser testado com cuidado antes do lançamento, quando todos estão atentos. Meses depois, o mesmo agente roda sem acompanhamento em milhares de tarefas pequenas, e ninguém compara o trabalho de hoje com o padrão original. Cada resposta, individualmente, é aceitável. O padrão geral, não.

A reação humana é previsível. Um colega que recebeu dois resumos levemente errados passa a reler todos os resumos. Outro deixa de consultar o agente sobre um certo tipo de cliente. Ninguém abre chamado. O agente continua ocupado nos registros, mas a utilidade real já caiu. Quando alguém diz que o agente não é mais confiável, a confiança já foi perdida há semanas.

A consequência prática: você não pode depender de incidentes e reclamações para detectar a degradação. Precisa de uma rotina que a procure de propósito.

O que faz um agente perder qualidade?

Quase nunca o agente piora sozinho. Algo ao redor dele mudou. Conhecer as fontes mais comuns indica onde olhar primeiro.

• Mudanças de modelo. O fornecedor atualiza ou troca o modelo por trás do agente, e o comportamento muda de formas que nenhuma nota de versão prevê por completo. Formato, nível de cautela e uso de ferramentas podem mudar. Veja o que fazer quando o modelo de IA muda para decidir entre adotar, ajustar e reverter.
• Acúmulo de instruções. A cada problema que surge, alguém acrescenta uma frase às instruções do agente. Depois de remendos suficientes, as regras entram em conflito, e o agente resolve esses conflitos de um jeito diferente a cada dia.
• Conhecimento desatualizado. Tabelas de preço, políticas, modelos de documento e nomes de produto mudam, mas os documentos que o agente lê nem sempre mudam junto. O agente segue respondendo com uma versão antiga, e com muita segurança.
• Mudanças em integrações. Um campo é renomeado, uma permissão é restringida, uma conexão expira ou um fornecedor altera o formato de resposta. O agente se adapta no palpite, e é no palpite que a qualidade vaza.
• Acúmulo de memória. As anotações salvas pelo agente se acumulam. Algumas estão desatualizadas, outras estavam erradas desde o início, e todas influenciam respostas futuras.
• Mudança no tipo de pedido. Os usuários aprendem o que o agente faz e passam a trazer pedidos mais difíceis, mais estranhos ou de maior risco do que aqueles usados nos testes.
• Mudanças de processo do lado humano. Uma equipe muda a forma de aprovar, arquivar ou nomear as coisas, e as premissas do agente deixam de corresponder à realidade.

Observe que a maioria dessas mudanças é feita pela própria organização. A degradação é, em grande parte, um problema de operação, e por isso precisa de um responsável e de um calendário, não apenas de um prompt melhor.

Quais sinais mostram a queda de qualidade cedo?

O objetivo é encontrar indicadores que se movem antes de os usuários perderem a paciência. Muitos já existem no trabalho que sua equipe faz em torno do agente e ficam visíveis quando passam a ser registrados com consistência. Para a ideia geral de inferir a saúde de um sistema a partir dos dados que ele emite, vale consultar a introdução à observabilidade da OpenTelemetry, e o artigo sobre o que registrar na observabilidade de agentes de IA cobre os detalhes.

Acompanhe estes sinais, em ordem aproximada de quão cedo aparecem:

• Edições dos revisores. Se uma pessoa aprova os rascunhos do agente, registre com que frequência e com que profundidade ela edita. Um aumento lento de reescritas é o sinal honesto mais precoce que você tem.
• Formato dos escalonamentos. Olhe nas duas direções. Mais escalonamentos podem indicar que o agente perdeu confiança ou contexto. Menos podem indicar que ele passou a responder o que deveria repassar.
• Tarefas reabertas ou corrigidas. Conta tudo o que uma pessoa precisa refazer depois de o agente marcar como concluído.
• Repetições e erros de ferramenta. Mais chamadas repetidas, caminhos alternativos acionados ou requisições malformadas costumam anteceder um problema visível de qualidade.
• Respostas sem respaldo. Verifique se o agente ainda aponta a fonte de uma afirmação e se a fonte realmente diz o que o agente afirma que ela diz.
• Mudanças de estilo e tamanho. Respostas que ficam mais longas, mais cheias de ressalvas, mais genéricas ou mais formais do que o seu padrão são fáceis de notar e muitas vezes refletem uma mudança mais profunda.
• Tempo e esforço por tarefa concluída. Se o mesmo trabalho exige mais etapas ou mais intervenções humanas, o agente está se esforçando mais para o mesmo resultado.
• Comportamento dos usuários. Menos gente usando o agente numa tarefa que ele antes resolvia, ou mais gente copiando a resposta para uma lista de conferência própria, indica que a confiança está se desgastando.

Nenhum sinal sozinho prova a degradação. Um conjunto de dois ou três se movendo na mesma direção por várias semanas já justifica uma verificação formal.

Como fazer uma verificação por amostra que realmente detecte a degradação?

A ideia central é simples: medir o agente contra uma referência que não muda e também contra trabalho real recente, que muda. A parte fixa mostra se o agente mudou. A parte nova mostra se o mundo mudou ao redor dele. O artigo da Anthropic sobre avaliações (evals) de agentes de IA é um bom complemento para desenhar a parte de pontuação.

Uma rotina prática:

• Passo 1: Escreva o que é um bom resultado para cada tarefa do agente. Inclua o que ele deve fazer, o que não deve fazer e quando precisa passar o caso para uma pessoa.
• Passo 2: Mantenha um conjunto fixo de casos representativos com resultados bons já acordados, incluindo alguns casos difíceis. Não o edite de qualquer jeito. Um conjunto de testes de referência explica como montá-lo.
• Passo 3: Retire, em intervalos regulares, uma amostra nova de tarefas reais recentes. Sorteie os casos, em vez de pegar os que as pessoas lembraram.
• Passo 4: Avalie os dois conjuntos com a mesma régua. Sempre que possível, peça que o revisor pontue sem saber de qual semana veio cada resposta.
• Passo 5: Compare com a rodada anterior e com a linha de base original. Olhe a direção ao longo de várias rodadas, não uma única nota.
• Passo 6: Classifique cada falha por causa: fato errado, fonte desatualizada, instrução ignorada, problema de ferramenta, tom ou ausência de repasse a uma pessoa.
• Passo 7: Registre a decisão, o responsável e a data da próxima verificação.

A disciplina importa mais do que a sofisticação. Uma amostra modesta revisada em um dia fixo da semana vale mais do que um painel elaborado que ninguém lê. Se a tarefa tem consequências jurídicas ou financeiras, amostre com mais frequência e com um revisor mais experiente.

Como a degradação aparece na prática? Um cenário ilustrativo

Este é um cenário ilustrativo, não a descrição de um caso real.

Uma distribuidora usa um agente para redigir respostas a clientes que perguntam sobre prazos de entrega e condições de devolução. Um líder de equipe aprova cada rascunho antes do envio. No lançamento, ele altera muito pouco. Nos meses seguintes, passa a reescrever com mais frequência o parágrafo final e comenta que as respostas estão vagas sobre prazos de devolução. Ninguém trata isso como incidente.

Em uma verificação de rotina, o revisor pontua um conjunto novo de respostas recentes e o compara com o conjunto fixo de testes. O conjunto fixo continua com boa nota, o que sugere que o modelo e as instruções se comportam como antes. A amostra nova tem nota pior, e as falhas se concentram nas condições de devolução. Ao rastrear a causa, o revisor descobre que a política de devoluções foi revisada, mas a versão antiga do documento continua na base de conhecimento do agente. Às vezes o agente cita a regra antiga, às vezes a nova, conforme o trecho que recupera.

A correção não é mexer no prompt. A equipe remove o documento desatualizado, cria a regra de que todo documento de política traga a versão em vigor e acrescenta três casos de devolução ao conjunto fixo. A amostra seguinte confirma a melhora. Como a comparação separou o conjunto fixo do conjunto novo, a equipe evitou uma discussão longa e inútil sobre se o modelo tinha piorado.

O que fazer quando a degradação é confirmada?

Confirmar a degradação não é o fim. O erro comum é responder acrescentando mais uma instrução, o que alimenta a próxima rodada de degradação. Use o padrão das falhas para escolher a resposta.

• Se as falhas começam após uma data de mudança conhecida, como uma atualização de modelo ou uma edição de instruções, compare antes e depois e reverta ou ajuste essa mudança.
• Se o conjunto fixo se mantém, mas o trabalho novo falha, suspeite de conhecimento desatualizado, de um novo tipo de pedido ou de uma mudança de processo. Corrija a fonte e depois amplie o conjunto fixo.
• Se as chamadas de ferramenta falham ou se repetem, conserte a integração e revise as regras de repetição antes de mexer nas instruções.
• Se o agente deixa de fazer repasses que deveria fazer, reforce os limites e teste-os diretamente. O escalonamento humano funciona melhor quando a pessoa recebe a decisão a tomar, não a confusão.
• Se a degradação pode ter causado dano, como informação errada enviada a clientes, pause a tarefa afetada e siga o seu processo de incidentes.
• Se a causa não está clara, reduza temporariamente a autonomia do agente, por exemplo voltando a apenas redigir rascunhos, enquanto você investiga.

Qualquer que seja a escolha, registre. Um histórico curto do que degradou, por quê e o que mudou torna a próxima investigação muito mais rápida e evita que as instruções virem uma pilha ilegível de remendos.

Como a Be Human lida com a degradação em operação gerenciada?

A Be Human trata a degradação como uma tarefa rotineira de operação, não como surpresa. No primeiro contato definimos a função, os limites de aprovação e um critério de sucesso observável, que dá às verificações posteriores algo concreto para comparar. Na operação gerenciada, isso pode incluir avaliações recorrentes contra um conjunto fixo de testes e uma amostra nova de trabalho real, monitoramento dos sinais descritos acima, manutenção de integrações e revisão de permissões. Quando uma verificação mostra queda, as mudanças são feitas de forma controlada, com o motivo registrado e uma pessoa do lado do cliente informada. Um ritmo semanal para esse trabalho está descrito no checklist semanal de manutenção de agentes de IA.

Por onde uma equipe pequena deve começar?

Você não precisa de um programa completo no primeiro dia. Escolha a tarefa em que uma resposta errada custa mais. Escreva em poucas linhas como é um bom resultado. Reúna um conjunto pequeno de exemplos reais com resultados acordados. Depois reserve um horário recorrente, toda semana ou a cada quinze dias, para avaliar uma amostra nova e compará-la com a rodada anterior. Mantenha um registro de uma página com resultados e decisões.

Se você quiser uma moldura mais ampla para responsabilidade e risco, o NIST AI Risk Management Framework oferece um vocabulário para medir e gerenciar sistemas de IA ao longo do tempo. O princípio é o mesmo em qualquer escala: alguém é responsável por perceber, e a percepção acontece em um calendário.

Perguntas frequentes

Com que frequência devemos verificar a degradação do agente de IA? Depende do risco e de quanto muda ao redor do agente. Uma amostra semanal serve para um agente que lida com clientes ou dinheiro, e um intervalo maior pode servir para tarefas internas de baixo risco. Faça também uma verificação extra após qualquer atualização de modelo, edição de instruções ou mudança de integração.

Degradação é o mesmo que alucinação? Não. Alucinação é o agente produzir conteúdo sem respaldo em uma única resposta, enquanto a degradação é uma tendência de qualidade ao longo de muitas respostas e do tempo. A degradação pode incluir mais alucinação, mas também abrange tom, repasses não feitos, fatos desatualizados e uso ineficiente de ferramentas.

É possível detectar a degradação sem equipe técnica? Sim, em grande parte. Edições dos revisores, tarefas reabertas e uma amostra pequena avaliada com uma régua escrita pedem conhecimento do seu negócio, não código. A ajuda técnica passa a ser útil para registrar as chamadas de ferramenta e rastrear a causa quando a amostra mostra um problema.

Devemos retreinar ou trocar o modelo quando a degradação aparece? Em geral, não como primeiro passo. A maior parte da degradação vem de documentos desatualizados, instruções acumuladas, mudanças de integração ou um novo tipo de pedido, e tudo isso é mais barato e seguro de corrigir diretamente. Troque o modelo apenas quando a comparação com o seu conjunto fixo de testes mostrar que o próprio modelo é a causa.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.