Como investigar regressão após trocar modelo de IA

Quando a qualidade cai logo depois de trocar um modelo de inteligência artificial, a pior resposta é culpar o modelo por instinto. A queda pode estar no modelo, mas também pode estar no prompt, no contexto, nas ferramentas, no roteamento, nos critérios de avaliação ou na forma como a mudança foi ativada.

Investigar regressão após troca de modelo de IA exige comparar versões como sistemas e isolar uma variável por vez antes de decidir ajustar, conter ou reverter.

A troca de modelo como mudança de sistema

A sequência parece convincente: a equipe troca o modelo, observa respostas piores e conclui que o novo modelo reduziu a qualidade. Essa hipótese é legítima. Só não é evidência suficiente.

Na prática, uma versão de produto com IA pode mudar mais do que o modelo. A investigação deve considerar novo prompt, novas instruções de sistema, ajustes de temperatura, mudança na janela de contexto, outro mecanismo de busca, nova regra de roteamento ou critérios de avaliação revisados. Às vezes, a interface também muda e passa a induzir entradas diferentes dos usuários.

Por isso, a primeira decisão de liderança não é escolher outro modelo. É formular a investigação certa: o que exatamente mudou entre a versão anterior e a nova versão?

Essa distinção evita dois erros caros. O primeiro é descartar um modelo que poderia funcionar bem com outra orquestração. O segundo é manter a troca e tentar compensar a queda com correções superficiais, sem entender a causa provável.

Na investigação, o texto final é só uma camada da evidência. A comparação também precisa observar entrada, contexto, instrução, execução, verificação e uso real. Se ignora esse conjunto, a equipe discute impressões, não regressão.

Reconstrua a versão anterior antes de comparar

Toda investigação começa por uma linha de base. Linha de base, aqui, é a fotografia reexecutável da versão que era considerada aceitável antes da mudança.

Essa fotografia deve registrar, no mínimo:

• modelo usado na versão anterior;
• prompt de sistema e instruções adicionais;
• parâmetros de geração disponíveis para a equipe;
• fontes de contexto, bases consultadas e regras de recuperação;
• ferramentas ou ações que a IA podia acionar;
• políticas de segurança, filtros e restrições;
• critérios de sucesso usados para avaliar respostas;
• conjunto de casos de referência.

Sem essa reconstrução, a equipe compara a versão nova contra uma memória coletiva. E memória coletiva costuma ser generosa com o passado e impaciente com o presente.

O DORA recomenda que testes aconteçam ao longo do desenvolvimento, combinando automação com atividades manuais, como exploração e usabilidade. Também recomenda manter e revisar suítes de teste, em vez de tratar qualidade como uma etapa posterior ao desenvolvimento. Aplicado à IA, isso significa que a base de comparação precisa existir antes da crise, não apenas depois da reclamação.

Quando a versão anterior não puder ser reconstruída, a equipe deve declarar a incerteza. Ainda é possível investigar, mas o resultado será menos preciso. Nesse caso, vale reconstruir uma referência aproximada com registros disponíveis, exemplos de uso, casos de atendimento e avaliações humanas. O ponto é não fingir precisão onde há lacuna.

Um bom sinal de maturidade não é ter certeza imediata. É saber o que pode ser afirmado, o que é hipótese e o que ainda precisa ser testado.

Compare resultados, trajetória e efeito no ambiente

Depois de reconstruir a linha de base, compare três camadas diferentes.

A primeira é o resultado produzido. A resposta ficou correta, completa, útil, segura e adequada ao formato esperado? Essa é a camada mais visível, mas não deve ser a única.

A segunda é a trajetória. Trajetória é o caminho usado pela IA para chegar ao resultado: quais fontes consultou, que ferramenta acionou, que passos executou, que instruções priorizou e onde abandonou o fluxo. Duas respostas parecidas podem ter trajetórias muito diferentes. E duas trajetórias parecidas podem gerar resultados finais distintos.

A terceira é o efeito no ambiente. Em um agente ou fluxo com ação, não basta a IA dizer que concluiu uma tarefa. É preciso verificar se o efeito esperado ocorreu no produto, no sistema ou no processo. A Anthropic distingue a trajetória de execução do agente do resultado efetivo no ambiente e observa que uma mensagem de conclusão não comprova, sozinha, que a tarefa foi realizada.

Essa separação muda a conversa sobre qualidade. Uma resposta pode parecer elegante e ainda assim consultar a fonte errada. Um agente pode declarar sucesso e não ter concluído a ação. Uma versão nova pode escrever melhor e decidir pior.

Por isso, cada caso de avaliação deve ter entradas, critérios de sucesso e verificadores. Verificador é qualquer mecanismo que confirme o resultado esperado: uma checagem automática, uma comparação com procedimento vigente, uma revisão humana estruturada ou a confirmação de que uma ação realmente alterou o estado correto.

Em casos que exigem julgamento, ambiguidade, risco operacional ou impacto relevante para usuários, a equipe deve definir verificadores compatíveis com o risco e com os critérios de sucesso.

Isole uma mudança por vez na matriz de investigação

O núcleo da investigação é simples de explicar e trabalhoso de executar: altere uma variável por rodada.

Se a versão nova combina modelo novo, prompt novo e base de contexto revisada, a regressão pode estar em qualquer um desses pontos ou na combinação entre eles. Comparar apenas versão antiga contra versão nova mostra que algo mudou. Não mostra o quê.

Uma matriz de investigação deve criar combinações controladas, por exemplo:

• modelo antigo com prompt antigo;
• modelo novo com prompt antigo;
• modelo antigo com prompt novo;
• modelo novo com prompt novo;
• mesmo modelo e mesmo prompt, mas contexto antigo ou novo;
• mesma configuração, mas com ferramenta antiga ou ferramenta nova;
• mesmos resultados, avaliados por critério antigo e por critério novo.

A ordem depende da suspeita principal. Se as reclamações envolvem respostas vagas, comece por prompt e contexto. Se envolvem ações incompletas, olhe ferramentas, permissões e verificadores. Se envolvem reprovação em casos que antes passavam, revise também o critério de avaliação, porque a régua pode ter mudado.

Essa matriz não identifica a causa com certeza. Ela reduz ambiguidade. A conclusão honesta pode ser: a causa provável está na combinação entre modelo novo e instrução nova, ou entre contexto novo e verificador antigo.

Esse já é um avanço. Uma causa provável bem delimitada orienta decisão melhor do que uma opinião forte sobre o nome do modelo.

Checklist de isolamento da regressão após troca de modelo

Use este checklist para conduzir a investigação sem transformar a análise em debate abstrato.

• A versão anterior pode ser reproduzida? Confirme se modelo, prompt, parâmetros, contexto, ferramentas e critérios antigos estão registrados. Sem isso, a comparação vira memória de equipe.
• A amostra de casos é a mesma nas duas versões? Rode a versão antiga e a nova sobre os mesmos casos, com os mesmos dados de entrada e o mesmo critério de sucesso.
• A mudança investigada está isolada? Altere apenas um componente por rodada: modelo, prompt, contexto, ferramenta, política ou verificador. Se duas variáveis mudam juntas, a causa fica ambígua.
• O resultado foi verificado no ambiente, não apenas na resposta? Em agentes ou fluxos com ação, confirme se a tarefa produziu o efeito esperado, e não apenas se a IA declarou que terminou.
• A regressão aparece em casos críticos ou apenas em preferências de estilo? Separe falhas que afetam segurança, decisão, operação ou confiança das diferenças aceitáveis de redação, formato ou tom.
• Existe um critério de parada para a nova versão? Defina antes da ampliação quais sinais obrigam contenção ou reversão, como falhas críticas, correções manuais recorrentes ou reprovação em casos de referência.
• A decisão final está ligada à causa provável? Evite trocar novamente o modelo se a evidência aponta para prompt, base de contexto, ferramenta, roteamento ou critério de avaliação.

Esse checklist se conecta a uma disciplina maior de qualidade. Se a organização ainda não tem casos de referência, critérios de aceite e avaliações mínimas, vale revisar o guia pilar sobre qualidade de software com IA e aprofundar a criação de uma avaliação de aplicação de IA. A investigação de regressão fica muito mais frágil quando nasce apenas depois do incidente.

Use exposição gradual para testar a hipótese sem ampliar o dano

Depois de formular a causa provável, resista à tentação de liberar a correção para todos de uma vez. Em IA, a exposição gradual é uma forma de aprender com limite de dano.

O capítulo de canários 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 e discute o uso de configurações para separar essas decisões.

Essa distinção é muito útil em produtos com IA. A equipe pode ter o código pronto, mas manter a nova configuração desativada para a maioria dos usuários. Pode ativar apenas para um grupo controlado, para tipos de pergunta menos sensíveis ou para cenários em que a reversão é simples.

Antes de ampliar, defina critérios de parada. Eles não precisam ser numerosos, mas precisam ser claros. Exemplos: falha em casos de referência considerados críticos, aumento recorrente de correções manuais, divergência grave em relação ao procedimento vigente ou verificador indicando que ações não foram concluídas.

Métricas agregadas ajudam, mas podem esconder problemas raros e relevantes. Uma média aceitável pode conviver com falhas graves em casos específicos. Por isso, combine sinais de uso com amostras revisadas, casos de referência e análise por tipo de falha.

Se a organização está estruturando adoção de IA de forma mais ampla, esse tipo de controle deve aparecer no roadmap de IA, não apenas como uma reação emergencial.

Decida entre ajuste, contenção ou reversão

A investigação precisa terminar em decisão operacional. Há três caminhos principais.

Ajuste quando a causa provável estiver localizada e a correção puder ser testada com segurança. Exemplo: a regressão aparece quando o modelo novo recebe uma instrução curta demais para consultar o procedimento antes de responder. A resposta não é abandonar o modelo, mas revisar a instrução, testar a combinação e expor gradualmente.

Contenha quando a regressão se concentra em cenários específicos, especialmente se eles forem críticos. A contenção pode envolver regra de roteamento, bloqueio de certos tipos de solicitação, exigência de revisão humana, limite de autonomia ou retorno temporário ao fluxo anterior para uma categoria de uso. Em agentes, essa contenção deve considerar o efeito no ambiente, não apenas a qualidade textual da resposta.

Reverta quando a causa continuar incerta e o impacto for relevante. Reverter não é fracasso técnico. É uma decisão de preservação de confiança enquanto a equipe aprende. A organização pode continuar investigando fora da exposição principal, com casos controlados e critérios mais claros.

A pior decisão é insistir em uma versão nova porque ela parece mais moderna, mesmo quando a evidência mostra perda de qualidade em situações que importam. Confiança não se sustenta em preferência por novidade. Sustenta-se em capacidade de verificar.

Exemplo fictício: assistente interno piora após trocar o modelo

Imagine um exemplo fictício: uma empresa usa um assistente interno para responder dúvidas operacionais sobre procedimentos de atendimento. A equipe troca o modelo de IA e, nas primeiras semanas, usuários relatam respostas mais longas, mais confiantes e menos aderentes ao procedimento vigente.

A suspeita inicial recai sobre o modelo novo. A equipe, porém, reconstrói a versão anterior e percebe que a mudança incluiu três variáveis: modelo novo, prompt revisado e nova instrução para sintetizar respostas em linguagem mais natural.

A investigação usa a mesma amostra de perguntas nas duas versões. Em cada caso, os avaliadores verificam se a resposta cita o procedimento correto, se preserva exceções relevantes e se evita recomendar uma ação fora da regra vigente. Quando há ação sugerida, a equipe confere se ela corresponde ao procedimento, em vez de aceitar a declaração da IA como evidência.

Ao isolar as variáveis, surge uma hipótese: o modelo novo responde adequadamente com o prompt antigo, e o prompt novo funciona de modo aceitável com o modelo antigo. A queda aparece com mais força na combinação entre modelo novo e instrução de síntese. A formulação pede respostas naturais e curtas, mas não obriga a preservar as exceções do procedimento antes de resumir.

Esse exemplo não prova um resultado universal. Ele mostra o tipo de raciocínio necessário. A causa provável não era simplesmente “modelo novo pior”. Era a interação entre modelo novo, instrução de síntese e critério insuficiente para verificar exceções.

A decisão prudente seria conter a nova configuração, revisar o prompt, incluir casos de referência com exceções operacionais e só ampliar a exposição depois de nova comparação. Se a empresa já usa uma estratégia de IA conectada ao negócio, essa decisão também deveria considerar impacto sobre confiança dos usuários, custo de correção manual e risco operacional.

A próxima decisão não é trocar de modelo de novo. É comparar a versão anterior e a nova versão em uma matriz controlada, isolar uma mudança por vez e decidir, com base na causa provável, entre ajuste, contenção ou reversão.

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

Leituras para continuar

• Como revisar dependências sugeridas por agentes de código
• Como medir a produtividade de desenvolvedores com IA

Fontes

• DORA: automação de testes
• Anthropic: avaliações de agentes
• Google SRE: lançamentos graduais

Para continuar esta leitura

• Como acompanhar correções manuais feitas pelo usuário