Como saber se a sua IA piorou: avaliação sem virar projeto

Você ajustou o prompt, rodou três exemplos, achou melhor e subiu. Uma semana depois um cliente reclama de um comportamento que funcionava antes — e ninguém consegue dizer se a mudança causou aquilo, porque não há registro de como estava.

Sistema de IA tem uma característica desconfortável: ele não quebra, ele degrada. O código continua rodando, a resposta continua chegando, e a qualidade cai sem nenhum sinal de erro. Sem medição, essa queda é invisível até virar reclamação.

A boa notícia é que uma avaliação útil não precisa ser sofisticada. Um conjunto de casos e um número já resolvem a maior parte do problema, e cabem em uma tarde.

Comece com trinta casos

Não espere ter o conjunto ideal. Trinta casos reais valem mais que trezentos sintéticos, e você provavelmente já tem os trinta espalhados por aí.

De onde tirar:

• Perguntas reais de usuário, do log do sistema ou do histórico de suporte.
• Casos que já deram errado. Todo bug reportado vira um caso de teste, e este é o hábito mais valioso da lista.
• Casos limite que você sabe serem difíceis: pergunta ambígua, informação que não existe na base, pedido fora de escopo.

Guarde em um arquivo versionado junto com o código, para que a evolução do conjunto tenha histórico:

[
  {
    "id": "cancelamento-prazo",
    "pergunta": "Qual o prazo para cancelar sem multa?",
    "esperado": "30 dias corridos a partir da contratação",
    "deve_conter": ["30 dias"],
    "nao_deve_conter": ["não sei", "consulte o suporte"]
  },
  {
    "id": "fora-de-escopo",
    "pergunta": "Qual a previsão do tempo amanhã?",
    "esperado": "recusa educada, redireciona ao escopo",
    "deve_conter": ["não posso ajudar"]
  }
]

Inclua deliberadamente casos cuja resposta correta é "não sei". Eles são os que detectam a regressão mais perigosa: o sistema que começou a inventar.

Escolha a métrica pela tarefa

Não existe métrica única, e usar a errada é pior que não medir. Cada tipo de tarefa tem a sua:

As três primeiras são o melhor investimento, porque rodam em segundos e não custam nada. Se a sua tarefa cabe em alguma delas, você tem uma suíte de testes de verdade — e deve tratá-la como teste automatizado, executando a cada mudança.

Para RAG, a métrica mais útil não é sobre a resposta final: é sobre a recuperação. Se o trecho correto está entre os cinco primeiros resultados, o modelo tem chance; se não está, nenhuma melhoria de prompt resolve. Medir os dois estágios separados diz onde está o problema.

Verificações simples pegam a maior parte

Antes de sofisticar, aplique as regras baratas. Elas capturam a maioria das regressões reais:

def avaliar(caso, resposta):
    falhas = []
    for termo in caso.get("deve_conter", []):
        if termo.lower() not in resposta.lower():
            falhas.append(f"faltou: {termo}")
    for termo in caso.get("nao_deve_conter", []):
        if termo.lower() in resposta.lower():
            falhas.append(f"apareceu: {termo}")
    if caso.get("formato") == "json":
        try:
            json.loads(resposta)
        except ValueError:
            falhas.append("JSON inválido")
    return falhas

Parece rudimentar, e é justamente por isso que funciona: não tem custo, não tem variância e não depende de outro modelo. Uma suíte assim com trinta casos roda em menos de um minuto e pega quebra de formato, perda de informação obrigatória e volta de comportamento indesejado.

Modelo como juiz, com ressalvas

Para resposta aberta, dá para usar um modelo avaliando as respostas de outro. É útil e tem armadilhas conhecidas, que precisam ser administradas:

• Dê critério explícito. "Avalie a qualidade" produz nota sem significado. "A resposta contém o prazo correto de 30 dias? Sim ou não" produz sinal.
• Peça decisão binária ou escala curta. Nota de 0 a 10 tem variação alta entre execuções; sim/não é estável.
• Cuidado com o viés de tamanho. Modelos julgadores tendem a preferir respostas mais longas, mesmo quando piores.
• Não use o mesmo modelo que gerou. A tendência a aprovar o próprio texto é documentada.
• Calibre contra humano. Avalie cinquenta casos à mão, compare com o juiz automático, e só confie nele se concordarem em larga maioria.

Usado com esses cuidados, o juiz automático é um bom filtro de triagem: ele aponta os casos suspeitos, e a pessoa revisa só aqueles.

Quando rodar

A avaliação só cumpre o papel se for executada nos momentos certos, e todos são previsíveis:

• Antes de subir qualquer mudança de prompt. Este é o principal. Alteração de prompt é deploy de código e merece o mesmo rigor.
• Quando o fornecedor atualizar o modelo. É a regressão mais traiçoeira, porque você não mudou nada. Um sistema afinado para uma versão pode se comportar diferente na seguinte, sem aviso.
• Depois de reindexar a base, em sistemas RAG.
• Periodicamente, ainda que nada tenha mudado. Detecta deriva do conteúdo da base e problema de infraestrutura.

Guarde o resultado de cada execução com data, versão do prompt e modelo usado. A série histórica é o que transforma "acho que piorou" em "caiu de 27 para 22 acertos na terça, quando o prompt mudou".

Medir também em produção

O conjunto de avaliação cobre o que você previu. Produção traz o que você não previu, e alguns sinais são baratos de coletar:

• Taxa de "não sei". Uma subida súbita costuma indicar problema de recuperação.
• Reformulação. Usuário que repete a pergunta de outro jeito não ficou satisfeito com a primeira resposta. É o sinal implícito mais forte que existe.
• Escalada para humano, em fluxo de atendimento.
• Latência e tamanho da resposta. Mudanças bruscas indicam alteração de comportamento, mesmo sem queda visível de qualidade.

Some a isso um botão de avaliação na interface. A taxa de resposta é baixa, mas o que chega é ouro — e cada caso negativo deve virar um item do conjunto de avaliação. É assim que ele cresce sem virar projeto: um caso por vez, vindo da realidade.

Esses registros compartilham a infraestrutura de instrumentação que já vale a pena manter por razões de custo — a mesma tabela que responde "quanto gastamos" responde "está funcionando".

Cuidado com o conjunto que envelhece

Um problema silencioso: o conjunto de avaliação deixa de representar o uso real.

Isso acontece de dois jeitos. O primeiro é o produto mudar — funcionalidades novas geram perguntas novas, e o conjunto continua medindo o que importava há seis meses. O segundo é mais sutil: ao ajustar o sistema repetidamente contra os mesmos trinta casos, você acaba otimizando para eles em vez de para o problema. É o equivalente a estudar o gabarito.

Duas práticas evitam isso:

• Separe um conjunto que você não olha. Reserve um terço dos casos e use apenas para conferência final, sem consultar durante os ajustes. Se o resultado no conjunto de trabalho sobe e no reservado não, você está ajustando ao gabarito.
• Renove com casos reais. A cada mês, acrescente perguntas vindas de produção e aposente as que já não representam nada. Um conjunto vivo mede o presente.

Vale também revisar as respostas esperadas periodicamente. Política muda, preço muda, procedimento muda — e um caso cuja resposta correta está desatualizada penaliza o sistema justamente quando ele acerta.

O mínimo defensável

Se for para fazer apenas o essencial: trinta casos em JSON, um script que roda todos e conta acertos, execução obrigatória antes de cada mudança de prompt, e o histórico dos números guardado.

Isso não é avaliação de última geração. É o suficiente para não subir uma regressão sem perceber, que é o problema real — e coloca você à frente da maioria dos sistemas de IA em produção hoje, que não medem nada e descobrem pelos usuários.

O ganho colateral aparece depois e costuma ser maior que o esperado: com o número na mesa, as discussões sobre qualidade deixam de ser disputas de opinião. "Ficou melhor" vira "subiu de 22 para 26", e a conversa passa a ser sobre os quatro casos que ainda falham. Para equipe pequena, essa mudança de vocabulário vale tanto quanto a detecção de regressão.

E há um efeito prático imediato: com a suíte pronta, experimentar fica barato. Testar um modelo mais novo, um prompt reescrito ou um parâmetro diferente passa a custar um minuto de execução em vez de uma semana de observação — e é aí que as melhorias reais começam a aparecer.