Teste de regressão em IA: preserve comportamentos

Testes de regressão de inteligência artificial servem para responder uma pergunta simples e difícil: depois de mudar prompt, modelo, contexto, ferramenta ou regra de negócio, o produto ainda preserva os comportamentos que já tinham sido aceitos?

A meta não é obter a mesma frase. É impedir que uma mudança tecnicamente correta apague compromissos do produto, como limites de ação, formatos de saída, recusas necessárias, critérios de aceite e expectativas do usuário.

Quando uma mudança em IA vira risco de regressão

Uma regressão em IA acontece quando uma funcionalidade que já atendia a um comportamento aceito deixa de atendê-lo depois de uma mudança. Essa mudança pode parecer pequena: encurtar um prompt, trocar um modelo de terceiro, alterar a política de contexto, ajustar uma regra de negócio ou conectar uma nova ferramenta ao fluxo.

O problema é que a variação linguística da IA pode esconder a perda. A resposta continua fluente. O deploy passa. Os testes técnicos de API, autenticação, latência e disponibilidade não quebram. Mesmo assim, algo que o produto prometia fazer deixa de acontecer.

Por isso, testes de regressão de IA não devem tentar congelar a superfície da resposta. Eles devem preservar o comportamento aceito. Se uma funcionalidade resumia chamados de suporte, não basta verificar se ela continua escrevendo um resumo plausível. É preciso verificar se ela mantém os compromissos que tornavam aquele resumo utilizável no fluxo real.

Essa diferença muda a conversa entre engenharia, qualidade e produto. A pergunta deixa de ser “a IA respondeu bem?” e passa a ser “qual compromisso do produto precisava continuar de pé depois da mudança?”.

O que deve ser preservado: comportamento, não frase exata

Em funcionalidades de IA, exigir texto idêntico costuma gerar testes frágeis. Duas respostas podem usar palavras diferentes e cumprir o mesmo papel. Também podem usar palavras parecidas e quebrar um limite relevante.

O foco dos testes de regressão de IA deve estar em categorias de preservação. Algumas delas são simples de observar:

Intenção atendida: a resposta resolve o pedido principal que o caso representa.
Restrição respeitada: a IA não executa, recomenda ou afirma algo que havia sido proibido ou condicionado.
Formato útil: a saída mantém campos, estrutura, ordem, nível de detalhe ou linguagem necessários para o fluxo.
Ação correta: quando a funcionalidade aciona uma ferramenta, o estado final esperado é produzido.
Recusa adequada: a IA interrompe ou pede confirmação quando o caso exige limite.
Autonomia preservada: a nova versão não passa a decidir sozinha algo que antes dependia de confirmação humana.

Essa lista não substitui critérios de aceite. Ela ajuda a traduzi-los em uma base de regressão. Se o produto ainda não definiu critérios de aceite para IA, a regressão ficará subjetiva demais. Nesse caso, o primeiro passo é separar o que é preferência de redação do que é compromisso operacional.

Em regressão, essa separação evita que uma preferência de redação bloqueie a mudança e que uma quebra operacional passe como simples variação linguística.

Como montar uma base mínima de regressão de IA

Uma base de regressão de IA é um conjunto revisável de casos que representa comportamentos já aceitos e que não devem desaparecer silenciosamente. Ela não precisa começar grande. Precisa começar relevante.

A seleção deve privilegiar casos que protegem compromissos do produto:

Casos frequentes, porque afetam a experiência comum do usuário.
Casos de alto risco, porque uma falha muda a decisão, a confiança ou o fluxo operacional.
Exceções conhecidas, porque costumam ser ignoradas quando a equipe otimiza para o caso médio.
Correções recentes, porque defeitos corrigidos tendem a voltar quando prompts, modelos ou ferramentas mudam.
Exemplos que representam critérios de aceite já aprovados, porque reduzem debate subjetivo na hora de decidir.

O DORA recomenda testes ao longo do desenvolvimento, combinando automação e atividades manuais, como exploração e usabilidade, além de manter e revisar as suítes de teste. Essa orientação é especialmente útil em IA: uma base de regressão não deve virar arquivo morto. Quando o produto muda, os casos também precisam ser revistos.

Uma boa base mínima tem casos com entrada, comportamento esperado, critério de sucesso e forma de verificação. O comportamento esperado não deve ser “responder de forma adequada”. Isso é amplo demais. Melhor: “separar resumo de recomendação”, “não prometer uma ação automática”, “pedir confirmação antes de acionar a ferramenta”, “incluir os campos obrigatórios” ou “recusar quando faltar contexto”.

Roteiro de decisão para testar regressões em funcionalidades de IA

Antes de mudar prompt, modelo ou ferramenta, a equipe pode percorrer estes pontos para decidir se a nova versão preserva comportamentos aceitos.

Comportamento preservado: a nova versão mantém a intenção principal que já era aceita para este caso? Se a intenção deixar de ser atendida, trate como regressão bloqueadora, mesmo que a resposta pareça bem escrita.
Restrição preservada: a nova versão continua respeitando limites definidos, como não executar certa ação, não afirmar algo sem base ou pedir confirmação antes de avançar? Se uma restrição explícita for quebrada, bloqueie ou escale para decisão de produto e risco.
Formato preservado: a saída continua útil para o fluxo em que será consumida, incluindo estrutura, campos obrigatórios, nível de detalhe e linguagem esperada? Se a variação impedir uso operacional, registre como regressão, ainda que o conteúdo esteja semanticamente próximo.
Resultado verificável: há um verificador claro para confirmar se a tarefa foi concluída no ambiente, e não apenas uma mensagem da IA dizendo que concluiu? Se o teste depende só da declaração do agente, esse caso não deve aprovar a regressão sozinho.
Correção anterior protegida: um problema já corrigido voltou a aparecer depois da mudança? Se sim, o caso deve entrar na base permanente de regressão ou ter sua permanência revisada explicitamente.
Variação aceitável: a diferença observada muda o compromisso do produto ou apenas a forma de expressão? Se muda o compromisso, é regressão. Se muda apenas a forma, pode ser aceita quando não prejudicar o uso.
Exposição controlada: a mudança pode ser ativada para uma parcela menor antes de ampliar o uso? Se o impacto potencial for alto e a separação entre disponibilizar e ativar for possível, prefira exposição gradual.

O valor do checklist está menos em padronizar respostas e mais em forçar uma decisão explícita. Uma quebra pode ser aceita. Mas, quando isso acontece, precisa ser assumida como decisão de produto, não escondida como variação natural de IA.

Exemplo fictício: resumo de chamados de suporte

Exemplo fictício: uma funcionalidade de IA resume chamados de suporte e sugere a próxima ação ao analista.

O comportamento aceito é este: quando o chamado envolve cancelamento de assinatura, a IA deve resumir o pedido, indicar documentos pendentes e não prometer reembolso automático. A equipe troca o modelo para reduzir custo e ajusta o prompt para respostas mais curtas.

O teste de regressão não precisa exigir o mesmo parágrafo da versão anterior. Ele precisa executar casos antigos de cancelamento e verificar três compromissos:

A IA ainda separa resumo de recomendação.
A IA mantém a lista de documentos pendentes quando eles aparecem no histórico.
A IA evita prometer reembolso automático.

Se a nova resposta fica mais curta, mas preserva esses três compromissos, a mudança pode seguir para uma etapa controlada. Se omite documentos ou promete reembolso, a versão regrediu. A hipótese de redução de custo ou melhoria de concisão não compensa, por si só, a perda de comportamento aceito. Esse efeito deve ser medido no ambiente apropriado, não presumido como resultado.

Esse exemplo também mostra um ponto de liderança: nem toda melhoria local melhora o produto. Uma resposta mais curta pode ser desejável, mas não se ela remove uma informação que sustentava a decisão do analista.

Quando a trajetória muda sem quebrar o comportamento aceito

Em funcionalidades com agentes, a regressão pode ficar ainda menos visível. O agente pode narrar passos coerentes, dizer que verificou dados, declarar que abriu uma solicitação ou afirmar que concluiu a tarefa. Nada disso prova o resultado.

A Anthropic distingue a trajetória de execução do agente do resultado efetivo no ambiente. Uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado. Avaliações precisam de entradas, critérios de sucesso e verificadores, e podem exigir várias tentativas.

Para regressão, essa distinção é decisiva. Se a funcionalidade deveria atualizar um campo, consultar uma base, criar uma tarefa ou manter um bloqueio, o teste precisa verificar o estado final ou a saída consumida pelo usuário. A cadeia de raciocínio aparente não é critério suficiente.

Isso vale também para recursos que não são agentes completos. Uma funcionalidade pode explicar muito bem por que decidiu algo e, ainda assim, falhar no formato esperado, esquecer uma restrição ou ignorar contexto relevante. Confiança não nasce da fluência. Nasce de verificadores adequados ao compromisso do produto.

Quando aceitar uma quebra e quando tratar como defeito

Nem toda diferença entre versões é regressão. O desafio é classificar a mudança sem transformar gosto pessoal em bloqueio, nem tratar quebra relevante como detalhe.

Uma classificação prática pode separar cinco situações:

Regressão bloqueadora: um comportamento aceito deixa de acontecer, uma restrição explícita é quebrada ou uma ação indevida passa a ser permitida.
Regressão aceitável com decisão explícita: o produto decide abandonar ou alterar um compromisso anterior, registra o motivo e ajusta critérios, comunicação e testes.
Melhora com efeito colateral: a nova versão melhora um aspecto, mas prejudica outro. A decisão depende do peso relativo de cada compromisso.
Variação irrelevante: muda a redação, a ordem de uma explicação ou o estilo, sem prejudicar o uso.
Caso que exige julgamento humano: envolve ambiguidade, experiência do usuário, risco reputacional ou uma decisão de negócio que não deve ser automatizada sem revisão.

Na atualização de fevereiro de 2026, a METR considera os novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade e aponta dificuldades de medir tempo com agentes concorrentes. Esse ponto não prova qualidade ou falta de qualidade em funcionalidades de IA. No contexto deste artigo, ele funciona como alerta metodológico: métricas indiretas, como tempo ou produtividade, não substituem verificação do comportamento que o produto prometeu entregar.

Se a discussão sobre regressão vira apenas “a equipe ficou mais rápida” ou “a resposta parece melhor”, a organização está medindo ao redor do problema. O teste de regressão precisa voltar ao compromisso aceito.

Como usar lançamento gradual para reduzir o impacto de regressões

Mesmo com boa base de regressão, testes não eliminam comportamento inesperado em IA. Eles reduzem perdas conhecidas e tornam quebras mais visíveis. Por isso, a forma de ativar a mudança também faz parte da estratégia de qualidade.

O capítulo de canarying do Google SRE trata da avaliação de uma mudança em uma parcela do tráfego antes de ampliar a exposição. Também distingue disponibilizar código de ativar funcionalidades, com uso de configurações para separar essas decisões.

Aplicado a IA, isso permite separar a entrega técnica da ativação da mudança, quando essa separação for possível. Quando possível, a mudança de prompt, modelo, ferramenta ou regra pode ser ativada para um grupo menor, acompanhada por verificadores, revisão de casos críticos e sinais de suporte.

Essa separação ajuda a evitar uma armadilha comum: tratar deploy bem-sucedido como autorização de comportamento. Disponibilizar não é o mesmo que ampliar. Para funcionalidades de IA, essa diferença pode ser a fronteira entre aprender com segurança e descobrir uma regressão tarde demais.

Para a próxima mudança, a equipe precisa sair com três definições: quais comportamentos aceitos entram na base revisável, quais verificadores comprovam preservação e quais quebras só podem seguir se forem assumidas como decisão de produto.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.