Quando um agente erra em produção, a linha no prompt

Quando um agente erra em produção, o jeito mais rápido de corrigir é abrir o prompt e acrescentar uma linha do tipo "se o cliente pedir tal coisa, faça tal outra". O incidente é resolvido, a vida segue e ninguém escreve teste nenhum.

Alguns meses depois, o prompt tem várias dessas linhas e ninguém sabe dizer quais ainda servem para alguma coisa e apagar qualquer uma vira aposta, então elas vão ficando.

O que falta nesse caso é o equivalente de um teste automatizado pro agente, que o pessoal chama de caso de avaliação (eval). Ele tem três partes: uma entrada real, o comportamento esperado e uma checagem que diz se a resposta passou. Quando dá pra conferir de forma objetiva, como a ferramenta chamada ou um valor, a checagem é código. Quando a resposta é texto livre, outro modelo avalia contra um critério escrito e atribui um score ao resultado.

Se o agente é montado como um grafo, com vários nós (um que classifica o pedido, outro que busca os dados, outro que responde), cada nó precisa dos seus casos e o fluxo inteiro precisa de outros, como teste unitário e de integração. Um nó pode passar sozinho e o conjunto errar, porque o problema está no que um entrega pro seguinte. Tudo isso roda a cada mudança de prompt, de ferramenta ou de modelo, como uma suíte de testes antes do deploy.

A mudança no processo é pequena. Antes de escrever a linha, escrever o caso com a entrada real do incidente e a resposta esperada. O caso precisa falhar sem a correção e passar com ela. Se ele já passa sem a linha nova, a linha não era o conserto. Depois, a correção roda contra a suíte inteira, porque uma linha nova pode consertar um incidente e quebrar um caso antigo. Com o tempo, a suíte passa a descrever o que o agente precisa continuar fazendo.

No agente de pedidos do iFood, o Ailo, o time fez isso de trás pra frente. A Chiara Caratelli, da Prosus, contou numa palestra da MLOps Community que o prompt tinha acumulado uma regra pra cada bug ou reclamação, e que o primeiro passo da limpeza foi criar um caso de avaliação pra cada situação que tinha gerado uma regra. Só depois eles renomearam ferramentas e variáveis e apagaram as regras, rodando as avaliações nesses cenários o tempo todo. O prompt encolheu, e com ele os tokens e a latência.

Sem os casos, apagar aquelas regras também seria uma aposta, como antes.

O número que eu passaria a acompanhar é simples: dos incidentes do mês corrigidos com uma linha de prompt ou uma regra, quantos ganharam um caso de avaliação antes. Se essa conta der baixa, cada linha nova é mais uma que ninguém vai ter segurança pra apagar.

Eu sempre tratei essas linhas no prompt como o conserto. Hoje vejo cada uma como uma dívida que só dá pra pagar se o caso de teste existir. Fica a dúvida de por onde começar nos prompts que já acumularam essas linhas, quando ninguém lembra mais qual incidente gerou cada uma.