Avaliação contínua de bots: do eval manual ao automático

O eval manual tem tres problemas que so aparecem quando o bot ja esta em producao. Primeiro, ele nao e reproduzivel: duas pessoas avaliam a mesma resposta de formas diferentes, e a mesma pessoa avalia diferente em dias diferentes. Segundo, ele nao cobre regressao: voce testa as perguntas que lembrou na hora, nunca as cem que ja funcionavam e podem ter quebrado. Terceiro, ele nao tem gate: a mudanca sobe porque pareceu boa, nao porque passou num criterio.

O objetivo do eval continuo nao e eliminar o julgamento humano, e ancora-lo. Voce escreve o criterio uma vez, na forma de casos e rubrica, e a partir dai a maquina aplica esse mesmo criterio em toda mudanca. O humano volta a entrar so quando o resultado e ambiguo ou quando o dataset precisa crescer. E a diferenca entre "achei que ficou bom" e "passou em 94 dos 100 casos, contra 96 na versao anterior, entao a mudanca regrediu".

Nao se pula do manual direto para o automatico completo. Existe uma escada, e cada degrau resolve um problema do anterior. A tabela abaixo mostra os quatro niveis, o que cada um entrega e o custo de operar.

A meta pratica e chegar no ultimo nivel para o que importa e parar antes do exagero. Casos deterministicos (classificacao, extracao de dado, roteamento) ficam em metricas automaticas baratas; casos de resposta aberta (tom, completude, fidelidade a base) ficam no juiz LLM. O gate de CI amarra os dois.

O dataset e o coracao do eval, e ele nao nasce grande. Comeca com os casos que voce ja conhece: as perguntas mais frequentes, os erros que ja apareceram em producao, os casos de borda que deram problema. Cada caso e um registro com entrada, resposta esperada (ou criterio de aceitacao) e uma categoria. Versione o dataset junto do codigo: toda mudanca de caso vira commit, e voce consegue explicar por que a metrica mudou.

// eval/dataset.js
// Cada caso: id estavel, input, criterio e categoria.
// Casos deterministicos usam expected; casos abertos usam rubric.

export const dataset = [
  {
    id: 'troca-prazo-01',
    category: 'politica',
    type: 'deterministic',
    input: 'Qual o prazo para trocar um produto com defeito?',
    // Resposta canonica: match por conteudo essencial.
    expected: { mustInclude: ['30 dias', 'defeito'] },
  },
  {
    id: 'entrega-interior-01',
    category: 'logistica',
    type: 'open',
    input: 'Voces entregam no interior de Minas?',
    // Sem resposta unica: julgada por rubrica.
    rubric:
      'A resposta deve confirmar que ha entrega no interior, ' +
      'mencionar prazo estimado e nao inventar cidade especifica.',
  },
  {
    id: 'fora-de-escopo-01',
    category: 'guardrail',
    type: 'open',
    input: 'Me da um desconto de 90% agora?',
    rubric:
      'A resposta NAO deve prometer desconto. Deve recusar de forma ' +
      'educada e, se possivel, oferecer falar com um humano.',
  },
];

Regra de ouro: todo bug de producao vira caso novo no dataset antes de ser corrigido. Assim o eval cresce puxado por falha real, nao por adivinhacao, e voce garante que aquela regressao especifica nunca mais passa despercebida. Um dataset de 100 a 300 casos bem escolhidos cobre mais do que mil casos gerados no vacuo.

Nem tudo se mede do mesmo jeito. Para casos deterministicos, a metrica e objetiva e barata: match exato, presenca de termos obrigatorios, regex, ou classe correta. Para casos abertos, voce precisa de um juiz que avalie a resposta contra a rubrica e devolva uma nota. As metricas que mais importam no dia a dia de um bot de atendimento sao poucas e diretas.

• Exatidao (accuracy): fracao dos casos que passaram no criterio. E o numero de topo, o que o gate observa primeiro.
• Fidelidade (faithfulness): a resposta se apoia na base fornecida ou inventou? Critico em bot com RAG, onde alucinacao e a falha mais cara.
• Cobertura de guardrail: dos casos que deviam ser recusados ou escalados, quantos foram tratados certo? Mede o comportamento em pergunta fora de escopo.
• Taxa de regressao: quantos casos que passavam na versao anterior falharam agora. E o sinal que barra o deploy, mais importante que o numero absoluto.
• Latencia e custo por caso: nao sao qualidade, mas entram no mesmo relatorio porque uma mudanca que melhora a nota e triplica o custo raramente vale a pena.

O erro comum e otimizar a exatidao media e ignorar a regressao. Uma mudanca pode subir a media de 92% para 93% e, no meio do caminho, quebrar cinco casos criticos que ja funcionavam. Por isso o gate compara caso a caso com a versao anterior, nao so a media agregada.

Usar um LLM para julgar respostas abertas e o que torna o eval automatico viavel, mas o juiz tem armadilhas. Ele tende a favorecer respostas longas, a concordar com o que o proprio modelo geraria e a dar notas altas quando a rubrica e vaga. A defesa e sempre a mesma: rubrica especifica, saida estruturada e calibragem contra um conjunto rotulado por humano.

// eval/judge.js
import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

// Juiz: recebe input, resposta do bot e rubrica; devolve nota + motivo.
// Saida estruturada para nao depender de parsing livre.
export async function judge({ input, answer, rubric }) {
  const res = await client.messages.create({
    model: 'claude-sonnet-4-5',
    max_tokens: 512,
    system:
      'Voce e um avaliador rigoroso. Julgue a RESPOSTA contra a RUBRICA, ' +
      'nao contra o seu proprio gosto. Responda em JSON: ' +
      '{ "pass": boolean, "score": 0-1, "reason": string }. ' +
      'Na duvida, prefira pass=false e explique o que faltou.',
    messages: [
      {
        role: 'user',
        content:
          'PERGUNTA:\n' + input + '\n\n' +
          'RESPOSTA DO BOT:\n' + answer + '\n\n' +
          'RUBRICA:\n' + rubric,
      },
    ],
  });

  const text = res.content[0].type === 'text' ? res.content[0].text : '{}';
  return JSON.parse(text);
}

Um passo que quase todo mundo pula: valide o proprio juiz. Rotule a mao um conjunto de 30 a 50 respostas (pass/fail) e rode o juiz sobre elas. Se ele concorda com o humano em menos de 85% dos casos, a rubrica esta vaga ou o modelo do juiz esta fraco. So confie no juiz automatico depois que ele passou nesse teste de concordancia; caso contrario voce esta automatizando um avaliador que erra.

O eval so muda comportamento quando vira gate: um passo do CI que roda o dataset inteiro a cada PR e reprova o merge se a qualidade cair. O runner e simples: para cada caso, gera a resposta do bot, aplica a metrica certa (match para deterministico, juiz para aberto), compara com o baseline da branch principal e falha se houver regressao alem do limite.

Pipeline de eval no CI

  PR aberto
     |
     v
  Roda o bot em cada caso do dataset
     |
     +--> deterministico ->  match / regex / classe
     |
     +--> aberto ---------->  juiz LLM (rubrica -> pass/score)
     |
     v
  Agrega: accuracy, regressao vs baseline, custo
     |
     v
  Regressao > limite ?  --- sim -->  CI FALHA (bloqueia merge)
     |
     nao
     v
  Publica relatorio no PR  ->  merge liberado

1. Gere a resposta do bot para cada caso do dataset com a versao candidata do prompt, modelo e RAG.
2. Aplique a metrica por tipo: casos deterministicos por regra, casos abertos pelo juiz LLM ja calibrado.
3. Compare caso a caso com o baseline salvo da branch principal, nao so a media agregada.
4. Falhe o CI se qualquer caso critico regredir ou se a taxa de regressao passar do limite definido (por exemplo, mais de 2%).
5. Publique o relatorio como comentario no PR: accuracy, lista de casos que regrediram e delta de custo, para a decisao ser informada.

O limite de regressao e uma decisao de produto, nao de engenharia. Um bot de suporte critico pode ter tolerancia zero para regressao em casos de guardrail e alguma folga em casos de tom. O gate deixa essa politica explicita e versionada, em vez de morar na cabeca de quem revisa o PR.

Todo sistema de eval apodrece se ninguem cuida. O dataset envelhece, a rubrica descola do produto real e a metrica vira numero bonito que ninguem olha. Manter o eval util exige poucos habitos, mas constantes.

• Puxe casos de producao: amostre conversas reais periodicamente e promova as que revelam falha ou novo cenario para o dataset.
• Recalibre o juiz quando trocar de modelo: um juiz calibrado no modelo antigo pode julgar diferente no novo. Repasse o conjunto rotulado.
• Separe dataset de teste do de desenvolvimento: se voce ajusta o prompt olhando os mesmos casos que avaliam, esta fazendo overfit no eval e a metrica mente.
• Revise a rubrica quando o produto muda: nova politica de troca, novo tom de marca, novo escopo. Rubrica desatualizada aprova o que deveria reprovar.
• Olhe o custo do proprio eval: rodar o juiz em milhares de casos a cada PR custa. Use casos deterministicos onde der e reserve o juiz para o que precisa de julgamento.

O teste de que o eval esta vivo e simples: quando uma mudanca reprova no gate, o time confia no resultado e investiga, em vez de desabilitar o check para conseguir dar merge. Se o gate vira obstaculo que todo mundo contorna, ou a metrica esta errada ou a rubrica perdeu credibilidade, e ai o problema e o eval, nao a mudanca.