Teste de regressão de prompts no CI: como não piorar sem perceber

Teste de regressão de prompts no CI: como não piorar sem perceber

Teste de regressão de prompts é rodar, a cada mudança de prompt ou de modelo, um conjunto fixo de casos reais e comparar o resultado com um critério combinado antes de publicar. No CI, isso vira uma etapa automática: se a nota cair abaixo do limite acordado ou se um caso crítico falhar, a mudança não segue. Assim a equipe deixa de descobrir a piora pela reclamação do cliente.

Principais pontos

• Prompt, modelo e descrição de ferramentas definem o comportamento do agente. Toda alteração em qualquer um deles deve passar pelo mesmo conjunto de casos.
• O conjunto fixo nasce de conversas reais (mascaradas) e de erros que já aconteceram, não de exemplos inventados na hora.
• Prefira checagens determinísticas. Use um modelo como avaliador só onde há julgamento, e calibre esse avaliador com revisão humana.
• Separe casos críticos, em que qualquer falha bloqueia, de casos gerais, avaliados por nota agregada com limite.
• Todo incidente em produção vira um caso novo. Sem isso, o teste envelhece e passa a proteger contra problemas que ninguém tem mais.

Por que um prompt piora sem ninguém perceber?

Prompts não se comportam como código comum. Uma frase adicionada para corrigir um erro específico pode mudar o tom, o tamanho ou a decisão em situações que ninguém olhou. O resultado parece bom nos três exemplos que o autor da mudança testou à mão, e o problema só aparece dias depois, em outro tipo de conversa.

Há ainda mudanças que não passam por você. O provedor pode atualizar o modelo por trás de um nome genérico. Uma descrição de ferramenta alterada por outro time muda quando o agente a chama. Um documento novo na base de conhecimento muda o que ele cita. Em todos esses casos, o texto do prompt continua igual e o comportamento muda.

A saída da IA também varia entre execuções. Por isso a pergunta útil não é se uma resposta ficou idêntica, e sim se ela continua dentro do que a empresa aceita. O teste de regressão transforma esse aceite em regras escritas e repetíveis. Para o problema vizinho de respostas inventadas, vale ler o guia prático para reduzir respostas erradas de agentes de IA.

O que entra no conjunto fixo de casos?

Comece pequeno, mas representativo. O conjunto precisa cobrir o que importa para o negócio, e não o que é fácil de escrever. Uma boa mistura inclui:

• Os fluxos mais frequentes, escritos como o cliente realmente fala, com abreviações, áudio transcrito e mensagens incompletas.
• Casos de borda: informação faltando, pedido ambíguo, duas perguntas na mesma mensagem.
• Pedidos fora do escopo, em que o correto é recusar ou encaminhar.
• Situações que exigem entrega a uma pessoa, como reclamação grave, cancelamento ou assunto jurídico.
• Tentativas de fazer o agente ultrapassar seus limites, como pedir para ignorar instruções ou revelar o prompt.
• Erros que já aconteceram em produção, com a conversa original mascarada.

Cada caso deve ter uma entrada, o contexto necessário (por exemplo, dados fictícios de um pedido), o critério de aprovação e uma marca de criticidade. O critério pode ser uma resposta de referência, uma lista de condições obrigatórias ou uma lista de coisas proibidas.

Sobre dados pessoais: ao aproveitar conversas reais, remova ou substitua nome, telefone, documento e endereço antes de guardar o caso no repositório. Isso reduz risco com a LGPD e facilita compartilhar o conjunto com a equipe. O texto sobre retenção de logs de conversas de IA detalha prazo e mascaramento.

Como avaliar a resposta se o texto muda a cada execução?

Use camadas, da mais barata e objetiva para a mais subjetiva.

Primeira camada, regras determinísticas. Verifique o que dá para verificar com código: o agente chamou a ferramenta certa, com os argumentos certos? Devolveu o formato esperado? Acionou a transferência para humano? Evitou termos e promessas proibidos? Citou apenas informações presentes no contexto fornecido? Essas checagens são estáveis e baratas, e devem cobrir a maior parte dos casos críticos.

Segunda camada, avaliador por modelo. Para qualidades como tom adequado, clareza ou fidelidade ao material de referência, um segundo modelo pode pontuar a resposta com base em uma rubrica escrita. A rubrica precisa ser específica (por exemplo, a resposta confirma o prazo informado no contexto sem acrescentar outro) e o avaliador precisa ser conferido contra notas humanas em uma amostra. Um avaliador que ninguém calibrou é só mais uma fonte de ruído.

Terceira camada, revisão humana. Reserve para os casos em que a nota mudou de forma relevante e para a calibração periódica. Quem conhece o processo de atendimento deve ser a pessoa que decide o que é uma resposta aceitável.

Para casos que oscilam, rode a mesma entrada mais de uma vez, mantenha a configuração de geração o mais estável possível e decida pela taxa de aprovação, não por uma execução isolada. Camadas de validação em tempo de execução complementam isso, como explicado em guardrails para agentes de IA.

Passo a passo para colocar no CI

O desenho abaixo funciona com qualquer pipeline que a equipe já use. Os nomes das ferramentas importam menos que a disciplina.

• Versione tudo no repositório: prompt, parâmetros de geração, descrições de ferramentas e o identificador exato do modelo. Evite apelidos que mudam sozinhos.
• Crie o arquivo de casos em formato simples (JSON, YAML ou planilha exportada), com entrada, contexto, critério e criticidade.
• Escreva um executor que chame o agente em ambiente de teste, com ferramentas simuladas ou apontando para dados fictícios. Nunca para sistemas reais.
• Implemente os avaliadores em camadas: regras primeiro, rubrica por modelo depois.
• Guarde um resultado de referência (baseline) da versão atualmente em produção, para comparar cada mudança contra ele.
• Gere um relatório legível no pull request: quais casos passaram, quais falharam, o que mudou em relação à referência, além de custo e latência da rodada.
• Configure a etapa como obrigatória para mesclar. Sem aprovação do teste, o merge não acontece.
• Agende uma execução periódica, mesmo sem mudança de código, para detectar alterações vindas do provedor do modelo.
• Registre cada execução com identificador, versão do prompt e do modelo. Convenções de telemetria para IA generativa, como as do OpenTelemetry, ajudam a padronizar esses campos.

Quando bloquear e quando só avisar?

Sem uma regra de decisão combinada antes, o teste vira discussão a cada falha. Defina o guia abaixo antes da primeira rodada.

• Caso crítico falhou: bloqueia sempre, sem exceção por pressa.
• Nota agregada dos casos gerais abaixo do limite acordado: bloqueia.
• Queda pequena, dentro da variação normal observada nas repetições: avisa e pede revisão humana, sem bloquear.
• Melhora geral, mas um caso importante piorou: o responsável pelo fluxo registra por escrito por que aceita a troca.
• Troca de modelo: rodar o conjunto completo, comparar também custo e latência, e só aprovar com decisão registrada.
• Teste instável: nunca ignorar. Corrija o caso, o critério ou o avaliador, porque um teste que falha ao acaso ensina a equipe a desprezar o alerta.

O limite de aprovação deve vir do piloto, não de um número copiado de outro lugar. Veja como definir métricas e pontos de decisão em como medir um piloto de automação com IA.

Cenário ilustrativo: a resposta mais curta que escondeu um cancelamento

Cenário ilustrativo: uma distribuidora usa um agente no WhatsApp para consultar pedidos e orientar clientes. Alguém da equipe percebe que as respostas estão longas e ajusta o prompt para pedir mensagens mais curtas.

Na rodada do CI, os casos gerais de consulta de pedido passam com nota igual ou melhor. Mas um caso crítico falha: o cliente escreve que quer cancelar e reclama de atraso, e o agente, agora mais enxuto, responde com uma frase de desculpas sem acionar a transferência para um atendente. O pipeline bloqueia a mudança e o relatório aponta exatamente o caso.

A equipe então reescreve a instrução para manter a regra de transferência explícita, roda de novo e aprova. Sem o conjunto fixo, a versão mais curta teria ido ao ar, e o problema só apareceria quando um cliente insatisfeito ficasse sem resposta humana.

Como o método mapear, limitar, pilotar e transferir se aplica

Primeiro, mapear: antes de escrever casos, é preciso saber como o processo funciona hoje, quais pedidos chegam, o que um atendente faria em cada um e qual é o ponto de partida de qualidade. Os casos críticos saem desse mapa. Segundo, limitar: o teste só tem sentido se o agente tem limites claros de dados e ações, porque cada limite vira um critério verificável (não pode prometer, deve transferir, não pode consultar tal sistema).

Terceiro, pilotar: o conjunto de casos entra em um fluxo real, com logs e uma métrica de sucesso combinada, e os limites de bloqueio são calibrados com o que se observa. Quarto, transferir: ao entregar a operação, o repositório com casos, avaliadores e regras de decisão passa para a equipe, junto com a orientação de quem aprova mudanças e como um incidente vira um caso novo. Depois disso, a empresa decide expandir, ajustar ou parar.

Uma observação de autoria: as bases técnicas citadas aqui vêm de documentação oficial sobre avaliações de IA. A organização em camadas e as regras de bloqueio são recomendações de implementação, e os limites numéricos de cada empresa são hipóteses a validar no piloto. Para a escrita das instruções em si, veja como escrever prompt para atendimento ao cliente com IA.

Perguntas frequentes

Quantos casos preciso para começar? Não existe quantidade mágica. Comece com os casos que cobrem os fluxos mais frequentes, os pedidos que exigem transferência para humano e os erros já ocorridos, e deixe o conjunto crescer a cada incidente. É melhor ter poucos casos bem escolhidos e confiáveis do que muitos genéricos que ninguém revisa.

Preciso de uma ferramenta específica de avaliação? Não obrigatoriamente. Um script que lê o arquivo de casos, chama o agente e aplica as checagens já resolve o início, e roda em qualquer pipeline de CI. Plataformas de avaliação ajudam quando o volume de casos e de versões cresce, mas a parte difícil continua sendo escolher bons casos e critérios claros.

O modelo avaliador é confiável o bastante para bloquear uma mudança? Depende de como ele foi calibrado. Use regras determinísticas para os casos críticos e deixe o avaliador por modelo para qualidades mais subjetivas, sempre conferido contra notas humanas em uma amostra. Se a rubrica for vaga, o resultado também será.

Com que frequência devo rodar o conjunto? A cada mudança de prompt, de ferramenta, de base de conhecimento ou de modelo, e também de forma agendada para pegar alterações do provedor. Se o custo da rodada completa pesar, mantenha uma versão reduzida, com os casos críticos, em cada pull request e a completa em horários programados.

Fontes

• Anthropic: Demystifying evals for AI agents
• OpenAI: guia de evals
• OpenTelemetry: convenções semânticas para IA generativa
• NIST: AI Risk Management Framework