Avaliações Antes de Funcionalidades

Todo time construindo com LLMs em algum momento chega à mesma conclusão: "Não consigo saber se minhas mudanças estão ajudando ou piorando." Ajustes no prompt parecem melhorias até que um usuário traz um output pior do que o que estava em produção no mês passado. A versão do modelo muda e degrada silenciosamente um terço das respostas. Você troca de fornecedor, conserta um bug e introduz três.

A solução não é fazer prompts melhores. A solução é ter avaliações.

Um conjunto de avaliação (eval set) é o equivalente em LLM a uma suíte de testes: uma coleção fixa e versionada de inputs e outputs esperados (ou regras de aprovado/reprovado) que você consegue rodar a cada mudança. Sem isso, você está adivinhando. Com isso, você está fazendo engenharia.

O atalho que custa caro

A maioria dos times pula avaliações porque construí-las parece mais lento do que simplesmente lançar. E é — pelas primeiras três semanas. Depois disso, a matemática se inverte. Times sem avaliações gastam cada vez mais tempo caçando regressões, debatendo "será que o modelo piorou?" e fazendo rollbacks de emergência. Times com avaliações lançam mais rápido porque toda mudança é uma mudança mensurável.

Se você já se pegou perguntando "o que você acha, o prompt novo está melhor?", você precisava de um conjunto de avaliação no mês passado.

O que um conjunto de avaliação realmente é

No mínimo: um CSV, um arquivo JSON ou uma tabela com três colunas.

• Input — o prompt ou a mensagem do usuário que o seu sistema recebe.
• Output esperado — a resposta certa, ou a regra que a resposta precisa satisfazer.
• Tags — categorias para você identificar quais tipos de input estão regredindo (ex.: "PT-BR", "borda", "uso de ferramenta").

E um script que roda seu sistema em cada linha, compara o output com o output esperado e reporta aprovado / reprovado / nota. Só isso. A primeira versão pode ser um notebook em Python. Não precisa de UI.

Três tipos de avaliação

Você normalmente vai precisar de uma combinação. Tarefas diferentes pedem corretores diferentes.

1. Ground truth

Você sabe exatamente qual é a resposta certa. Classificação, extração, output estruturado — esses têm ground truth. A correção é uma comparação de string ou schema. Barato, determinístico, rápido.

Use quando: a tarefa tem uma única resposta correta (sentimento, categoria, extração de JSON, cálculo matemático).

2. Baseado em rubrica

Você não tem uma única resposta certa, mas tem regras. "O output precisa incluir uma saudação, precisa ter menos de 200 palavras, não pode prometer desconto." Rode cada regra como uma verificação.

Use quando: a tarefa é generativa mas com restrições (rascunhos, resumos, respostas para clientes).

3. Avaliado por modelo (model-graded)

Um modelo separado, geralmente mais potente, dá nota ao output contra uma rubrica que você escreve. Útil para tarefas fluentes onde dá para descrever qualidade mas não enumerar. Trate como mais ruidoso que os dois primeiros — e sempre faça spot-check contra julgamento humano numa amostra.

Use quando: a tarefa é aberta (respostas longas, explicações, brainstorms). Não use isso como sua única avaliação — combine com pelo menos uma verificação por rubrica.

Construindo seus primeiros 50 exemplos

Você não precisa de 5.000. Precisa de 50 — bem escolhidos.

1. Roube da produção. Puxe 200 inputs reais dos logs (últimos 30 dias). Se você ainda não tem logs, comece pelos logs e volte aqui depois.
2. Amostre por diversidade. Não pegue os 50 mais fáceis. Misture caminhos felizes, inputs ambíguos, requisições malformadas, inputs longos, inputs curtos, e pelo menos 5 que pareçam adversariais.
3. Sanitize. Tire PII. Substitua nomes, e-mails, números de conta por placeholders realistas. Não comite dado bruto de cliente num repositório.
4. Rotule à mão. Os primeiros 50 precisam ser rotulados por um humano que conhece o domínio. Essa é a parte trabalhosa e insubstituível. Reserve duas horas focadas.
5. Use tags com generosidade. "Pergunta sobre devolução", "input em PT-BR", "multi-turno", "exige uso de ferramenta". As tags são o que vai te permitir dizer depois "nossa taxa de aprovação em PT-BR caiu 12% nessa semana."

Depois disso, você tem um conjunto de avaliação. Rode seu sistema atual de produção contra ele. A nota que sair é o chão — qualquer mudança futura precisa bater essa nota ou não entra.

A cadência

Rode as avaliações em:

• Toda mudança de prompt. Sem exceção. O ciclo de feedback rápido só funciona se for rápido — mantenha o conjunto pequeno o suficiente para uma rodada completa levar menos de cinco minutos.
• Toda troca de modelo. Incluindo bumps de versão menores. "Mesmo modelo, snapshot novo" já queimou mais lançamentos do que dá para contar.
• Toda atualização do índice de retrieval. Se seu sistema busca contexto de um vector store, mudanças nesse store podem mudar o comportamento sem você ver.
• Semanalmente, como freshness check. Mesmo sem nada ter mudado do seu lado, drift acontece. Agende uma rodada para sexta de manhã.

A armadilha: quando sua avaliação melhora mas seus usuários não

O modo de falha mais caro de um conjunto de avaliação é quando o time começa a otimizar a avaliação em vez do produto. A nota sobe, e os usuários reclamam mais.

Duas proteções:

• Mantenha uma fatia separada. Reserve 20% dos exemplos num "test set" que o time não pode usar para iteração. Olhe mensalmente. Se a nota de treino sobe mas a de teste estagna, você está fazendo overfitting na avaliação.
• Combine notas de avaliação com uma métrica de produção. Taxa de thumbs-up, taxa de escalonamento, taxa de reembolso — algo com sinal do mundo real. Se avaliação e produção divergirem por mais de duas semanas, sua avaliação está errada; conserte.

Fechando

Avaliações não são glamourosas. Não aparecem na demo. Não geram o tweet de lançamento. São o que faz o sistema que você lançou continuar bom na semana 12.

Se você só vai fazer uma coisa essa semana antes de escrever mais lógica de prompt, escreva o conjunto de avaliação. O resto do sistema fica mais fácil a partir daí.