7 testes de regressão que todo agente de IA deveria passar antes de ir para produção

O problema não é o modelo — é o estado

Quando um agente de IA falha em produção, a causa quase nunca é um modelo “burro”. Segundo um artigo do Machine Learning Mastery assinado por Vinod Chugani, a maioria das falhas acontece porque a camada de orquestração perde o controle do estado — e a maior parte das equipes descobre isso da pior forma: em produção, com tráfego real de usuários.

Antes da lista de testes, o artigo faz uma distinção essencial: “estado” é o registro determinístico e transacional dos passos de execução do agente; “memória” é o contexto probabilístico e recuperado que é injetado no prompt. Quando um agente se comporta mal, o problema quase sempre mora no estado, não no modelo.

Outro aviso estrutural: como o comportamento de agentes é estocástico, uma única execução não é um teste confiável. A recomendação é fixar o snapshot do modelo, zerar a temperatura (onde o provedor permitir) e rodar cada teste vezes suficientes para estabelecer uma taxa de aprovação com intervalo de confiança.

Os 7 testes de regressão

1. Perda de contexto e degradação de recuperação

Quando o histórico da conversa se aproxima do orçamento de prompt, a camada de orquestração precisa decidir o que remover. O teste alimenta o agente com uma conversa sintética que preenche ~80% do orçamento e pergunta algo cuja resposta depende de um fato estabelecido na primeira interação. Passa apenas se a recuperação semântica resgatar aquele trecho evicto — ou se a sumarização preservou as relações essenciais. Cuidado com a armadilha do “OU”: passar por recuperação é diferente de passar por sumarização; trate como dois testes.

2. Idempotência de execução de ferramentas

Um agente com acesso de escrita vai, sob condições reais de rede, emitir o mesmo chamado mais de uma vez. O teste força o mesmo payload a chegar três vezes e passa só se o sistema registrar exatamente uma escrita. A chave de idempotência deve derivar da identidade lógica da operação (hash de nome da ferramenta + argumentos canônicos + ID de correlação), nunca da posição da mensagem.

3. Resistência a override de instrução e prompt injection

O teste injeta payloads adversários por entrada direta e por vetores indiretos (documentos recuperados). Passa se o agente chegar a um estado terminal seguro sem executar a instrução injetada e sem vazar o system prompt. O assert deve ser sobre o rastro de chamadas e efeitos colaterais, não sobre o texto de saída — um agente pode recusar educadamente em prosa enquanto ainda dispara uma chamada nociva por baixo.

4. Aderência à saída estruturada

Com decodificação restrita por schema, a invalidade sintática é estruturalmente impossível. O que resta testar é diferente: truncamento (o orçamento de tokens corta a saída no meio), refusals (que devolvem parse nulo com campo de recusa e devem virar 403, não retry), conformidade semântica e viés de versão do modelo (alias apontando para um snapshot antigo).

5. Não-terminação e orquestração limitada

O que chamam de deadlock costuma ser livelock: o agente progride no ciclo pensamento-ação-observação, mas nunca avança rumo ao objetivo. O teste dá uma tarefa impossível ou aponta o agente para uma ferramenta mockada que retorna erro persistente, e passa se a execução terminar de forma limpa após um orçamento fixo. O orçamento deve ser triplo: máximo de passos, custo cumulativo de tokens e timeout de relógio.

6. Grounding de RAG contra recall paramétrico

O teste introduz um fato sintético que contradiz o conhecimento comum e pergunta sobre ele. A versão ingênua só verifica se o agente adota o fato recuperado — necessário, mas insuficiente. O risco corre nas duas direções: o agente deve adotar o fato sintético correto sobre o conhecimento paramétrico defasado, mas também resistir a um fato recuperado obviamente errado quando a contradição é detectável.

7. Reidratação de estado e consistência

Em implantação distribuída, o processo que inicia a sessão raramente é o que a termina. O teste executa o agente até a metade, serializa o estado, destrói o objeto em memória e o reidrata em um novo processo — e passa se o agente concluir corretamente. Dois pontos costumam afundar esse teste: viés de versão (estado serializado por uma versão antiga precisa ser desserializável pela atual) e o acoplamento com a idempotência (retomar no meio de uma chamada exige saber se o efeito colateral já foi confirmado).

O que esses testes não pegam

Os sete cobrem modos de falha estruturais na fronteira do sistema, mas não tratam de regressão de custo e latência, deriva de contrato de ferramentas quando uma API muda o schema, vazamento de PII em argumentos de ferramentas ou deriva do espaço de embeddings quando um novo encoder é implantado sem reindexar a base vetorial. Construir a suíte é a linha de partida; rodá-la de forma consistente, em versões fixas de modelo e com limiares de confiança, é o que a mantém útil no dia 100.