Como testar prompts sistematicamente em vez de chutar o que funciona
- Authors
- Name
- ThePromptEra Editorial
A maioria das pessoas testa prompts do jeito que debugava código em 1995: muda algo, executa, torce para melhorar. Depois repete até a meia-noite.
Tem um jeito melhor. Testar prompts sistematicamente significa estabelecer uma performance de referência, isolar variáveis e medir resultados consistentemente. Parece acadêmico. Na prática é mais rápido e te dá confiança no que você está construindo.
O Problema de Chutar
Quando você ajusta um prompt sem um plano, está coletando anedotas, não dados. Uma execução com a redação A parece melhor que a B—mas era mesmo? A entrada mudou? A temperatura era diferente? Você só teve sorte?
Essa abordagem queima horas. Você acaba com um prompt que parece correto mas não resolve consistentemente seu problema real. Aí você publica, os usuários reclamam, e você volta ao ponto de partida.
O custo explode quando você está testando prompts para produção. Uma melhoria de 2% em acurácia em milhões de requisições não fica óbvia testando manualmente. Mas é a diferença entre uma ferramenta em que as pessoas confiam e uma que elas abandonam.
Passo 1: Defina Sua Métrica de Sucesso Primeiro
Antes de escrever um único prompt de teste, responda: Como é o sucesso?
Tem que ser mensurável. Não "explicações melhores". Não "mais útil". Específico.
Exemplos:
- Para um classificador: Acurácia (% de previsões corretas) ou F1 score em um conjunto de teste rotulado
- Para um resumidor: Score ROUGE ou avaliadores humanos dando notas de 1-5 em clareza
- Para geração de código: O código gerado roda sem erros? Passa nos testes fornecidos?
- Para respostas de suporte ao cliente: Elas respondem a pergunta do usuário? Tempo de resposta? Tom adequado?
Escolha sua métrica antes de testar. Isso previne que você escolha a dedo resultados que parecem bons depois.
Passo 2: Construa um Conjunto de Testes
Você precisa de exemplos. Reais. Não cenários inventados.
Reúna 20-100 casos de teste representativos, dependendo do seu uso:
- Pares entrada/saída para tarefas de geração (prompt + saída esperada)
- Entradas com respostas rotuladas para classificação (texto + categoria correta)
- Descrições de problemas para tarefas de debug/código
Armazene consistentemente. JSON funciona bem:
[
{
"input": "Resuma este artigo em 2 frases: [texto do artigo]",
"expected_output": "Resumo em duas frases que capture os pontos principais",
"category": "noticia"
},
{
"input": "...",
"expected_output": "...",
"category": "recurso"
}
]
O conjunto de testes é sua verdade. Tudo mais se compara contra ele.
## Passo 3: Crie uma Baseline
Execute seu prompt atual (ou uma baseline simples) contra todos os casos de teste. Registre a métrica.
Se você está medindo acurácia em 50 casos de teste:
- Prompt baseline obtém 68% (34 corretos)
Agora você tem um número. Toda nova versão precisa superar isso ou você sabe que é pior.
Isso leva 5 minutos com um script. Vale a pena. A baseline previne regressão.
## Passo 4: Mude Uma Coisa Por Vez
Essa é a parte do método científico. Ajuste uma variável, teste, meça, compare.
Variáveis que você pode testar:
- **Clareza das instruções**: "Retorne JSON" vs. "Formate sua resposta como JSON válido com as chaves: nome, idade, email"
- **Exemplos no prompt**: 0 exemplos vs. 2 exemplos vs. 5 exemplos
- **Role-playing**: Sem papel vs. "Você é um desenvolvedor Python especialista"
- **Formato de saída**: Linguagem natural vs. estruturado vs. passo a passo
- **Temperatura ou sampling**: Se está usando Claude, isso afeta aleatoriedade
- **Restrições**: Adicionar limites de comprimento, requisitos de tom, tratamento de casos extremos
Teste uma mudança. Se a acurácia vai de 68% para 71%, mantenha. Se cai, reverta.
Documente o que está testando:
```
Baseline: 68% de acurácia
Teste 1 - Adicionou 3 exemplos: 72% ✓ MANTÉM
Teste 2 - Mudou temp de 0.7 para 1.0: 65% ✗ REVERTE
Teste 3 - Adicionou instrução para caso extremo: 73% ✓ MANTÉM
Teste 4 - Simplificou linguagem (baseline do Teste 3): 71% ✗ VOLTA AO TESTE 3
Melhor atual: 73%
```
Esse log é ouro. Você vê exatamente o que ajudou.
## Passo 5: Valide em Dados Novos
Seu conjunto de testes pode ficar "assado". Você começa a otimizar _para_ aqueles exemplos específicos em vez de resolver o problema real.
Reserve 20% dos seus dados originais antes de começar. Não olhe para eles. Depois de terminar de iterar, execute seu prompt final contra esse conjunto.
Se seu conjunto de testes marca 75% mas o conjunto de validação marca 62%, você fez overfitting. Volte e teste de novo no conjunto original. Algo funcionou para aqueles casos mas não generaliza.
## Escalando Para Produção
Depois de validar um prompt, você ainda pode melhorá-lo:
1. **Monitore uso real**: Acompanhe sua métrica em entradas reais de usuários. A performance bate com seu conjunto de testes?
2. **Colete falhas**: Quando a saída do Claude está errada, adicione ao seu conjunto de testes. Teste novamente.
3. **Atualizações periódicas**: A cada mês, reteste contra dados novos. O prompt ainda bate sua meta?
## Um Exemplo Real
Digamos que você está construindo um filtro de moderação de conteúdo.
**Prompt baseline**:
"Este conteúdo é apropriado para um ambiente profissional? Responda sim ou não."
Executado em 50 casos de teste: 76% de acurácia
**Teste 1**: Adicione exemplos de casos duvidosos:
```
"É apropriado? Sim ou não. Exemplos: 'Discordo da abordagem do orçamento' = sim, 'Sua ideia é burra' = não, 'Podemos discutir o cronograma?' = sim"
```
Resultado: 82% de acurácia. Mantenha.
**Teste 2**: Adicione níveis de severidade:
```
"Avalie este conteúdo: 1=apropriado, 2=duvidoso, 3=inapropriado"
```
Resultado: 79% em escala de 3. Um pouco mais difícil mas seu negócio precisa de nuance. Mantenha.
**Teste 3**: Simplifique a linguagem na versão anterior:
```
"Avalie: 1=ok, 2=talvez não, 3=não ok"
```
Resultado: 78%. A redação original era mais clara. Volte ao Teste 2.
Seu prompt final marca 82% no seu conjunto de testes, 80% em dados não vistos. Você publica.
## Por Que Funciona
Você não está mais chutando. Você tem:
- Um objetivo claro (a métrica)
- Experimentos controlados (uma mudança por teste)
- Evidência (números antes/depois)
- Reprodutibilidade (alguém mais pode executar o mesmo conjunto de testes)
Essa abordagem funciona independente de testar uma vez ou iterar em um prompt que potencializa milhares de usuários. É a diferença entre engenharia e esperança.
Comece pequeno. Pegue um prompt que usa regularmente. Construa um conjunto de teste de 20 casos essa semana. Meça sua baseline. Mude uma coisa. Veja o que acontece.
Você vai publicar prompts melhores. Mais rápido.
```