Como Avaliar Prompts Antes de Colocar em Produção

A maioria das equipes "testa" prompt rodando duas ou três vezes e olhando se a resposta parece certa. Serve para uma demo. Em produção, o mesmo prompt roda milhares de vezes com inputs que você nunca digitou à mão, e é ali que os casos extremos aparecem. O padrão de "funcionou quando testei" é baixo demais, e os números dizem o tamanho do buraco.

Entre 1.018 prompts reais avaliados, a nota média foi 54 de 100, e só 10,5% chegaram a 75, o ponto em que um prompt é claro, específico e aguenta variação. Quase 9 em cada 10 nunca cruzam a barra de produção.Fonte: The Robustness Gap, State of Prompt Quality (edição Q3 2026, n=1.018)

Avaliar antes da produção é o que separa esses dois grupos. Não é rodar o prompt mais vezes: é um processo que pega a falha enquanto ela ainda é barata de consertar. As seis etapas, na ordem em que valem mais tempo:

1. Revise a estrutura e dê uma nota ao prompt antes de qualquer teste.
2. Monte um conjunto de testes de 20 a 50 inputs que pareça a produção.
3. Defina o que é "correto" para cada caso antes de rodar.
4. Teste consistência entre execuções repetidas e entre modelos diferentes.
5. Teste o pipeline inteiro, não só o prompt isolado.
6. Versione e trave regressão antes de fazer o deploy.

Por que "correto na média" não basta

Um prompt pode acertar 8 em 10 vezes e ainda assim ser péssimo em produção, porque os 2 erros caem sempre no mesmo tipo de input: o e-mail sem assunto, o pedido em outra língua, o campo que veio vazio. A dimensão que mede exatamente isso, a robustez, é o ponto cego do conjunto inteiro.

A robustez ficou em média 31,5 de 100, metade de qualquer outra dimensão, e foi a nota mais fraca em 96% dos prompts avaliados.Fonte: State of Prompt Quality, edição Q3 2026

Quase ninguém escreve a linha "se o input não trouxer a pergunta, peça esclarecimento em vez de adivinhar". Por isso a avaliação pré-produção não pode olhar só o caminho feliz. Se quiser o detalhamento dessa falha específica, o guia de como deixar prompts de IA robustos cobre os edge cases um a um.

Etapa 1: Leia o prompt antes de rodar qualquer teste

A maioria das falhas de produção dá para prever lendo o prompt com atenção. Você não precisa executá-lo para achar uma instrução ambígua ou um formato de saída deixado no ar. Se não sabe o que procurar, o framework de 4 dimensões é o checklist: clareza, especificidade, estrutura e robustez.

Os dados dão uma ordem de prioridade. Cada elemento estrutural abaixo foi comparado pela nota média dos prompts que o tinham contra os que não tinham. É correlação, não experimento controlado, mas a diferença é grande e consistente. Priorize de cima para baixo:

Repare na última linha: o exemplo dá +10 pontos e quase ninguém usa (5%). É a alavanca mais barata que sobrou na mesa. Uma ferramenta de score como o PromptEval aponta qual dos quatro está faltando em segundos, mas um checklist na mão pega os mesmos itens. O que não vale é pular a leitura.

Etapa 2: Monte um conjunto de testes que pareça a produção

Rodar inputs aleatórios não é avaliação. Você precisa de um conjunto que reproduza a distribuição real do que o prompt vai receber. A composição pesa mais que o tamanho: um conjunto de 15 inputs bem escolhidos pega mais falha que 80 variações do mesmo caso fácil.

Dez inputs é o piso para qualquer conclusão. De 20 a 50 cobre bem a maioria dos prompts de produção. Acima disso, o retorno cai rápido, a menos que o custo de um erro seja alto (saúde, jurídico, financeiro), onde vale ampliar.

Etapa 3: Escreva o que "correto" significa antes de rodar

Esta é a etapa que quase todo mundo pula, e a que mais importa. Antes de disparar o conjunto de testes, escreva o critério de output correto para cada caso. Não uma vibe, um critério verificável.

Ruim: "a resposta deve ser útil e clara."
Bom: "a resposta deve ser um JSON com as chaves nome, pedido_id e sentimento; sentimento só pode ser positivo, neutro ou negativo; nada fora do que está no input."

Se você não define correto antes, vai racionalizar qualquer saída do modelo como "basicamente certo". Com dez casos, dá para revisar à mão. Com centenas, você precisa de um juiz-LLM: um segundo modelo que recebe cada output mais a sua rubrica e devolve uma nota por critério. É a mesma mecânica que pontua cada critério de 0 a 100 no Treino diário do PromptEval, onde cada exercício traz um cenário real e um juiz que mede o quanto sua resposta bateu no gabarito. Treinar esse olho no diário é o jeito mais rápido de aprender a escrever critérios que um juiz consegue medir.

Etapa 4: Teste consistência entre execuções e entre modelos

Um prompt de produção precisa ser consistente, não só correto na média. Rode o mesmo caso várias vezes e veja se o output varia de um jeito que importaria para quem recebe. Boa parte da inconsistência vem de lacunas estruturais no próprio prompt, e as mais comuns estão listadas no guia sobre por que prompts saem inconsistentes.

Tem um segundo eixo que quase ninguém testa: o mesmo prompt em modelos diferentes. Se hoje você roda em um modelo e amanhã troca por outro mais barato, o comportamento pode mudar sem aviso. O Playground do PromptEval deixa você rodar o prompt ao vivo com sua própria chave (Anthropic ou OpenAI) e comparar as saídas lado a lado. Para comparar duas versões de prompt contra vários inputs de uma vez, o Batch A/B Test roda a matriz inteira e mostra qual vence por critério. O passo a passo completo de teste e iteração está no guia de como testar e iterar prompts de IA.

Etapa 5: Teste o pipeline, não só o prompt

Se o output é parseado, processado ou passado adiante, teste a cadeia inteira. Um prompt pode dar respostas "corretas" que ainda quebram o sistema porque vieram com uma aspa a mais, um campo faltando ou um caractere que o próximo passo não espera.

Para prompts que devolvem dados estruturados (JSON, CSV, um formato fixo), teste o que acontece quando a saída vem levemente malformada. Seu código de parsing quase sempre é menos tolerante do que você imagina. Um input adversarial do conjunto de testes costuma ser o que expõe isso.

Etapa 6: Versione e trave a regressão antes do deploy

Antes de publicar, salve o texto exato do prompt, o modelo, a temperatura e o resultado dos testes. Parece óbvio, mas a maioria não faz, e depois não consegue explicar por que os outputs mudaram. Versionar é a diferença entre "quebrou e não sabemos por quê" e "reproduzimos o estado exato antes da regressão".

A parte que quase nenhum guia cobre é o passo seguinte: impedir que a próxima edição degrade o que já funciona. Um gate de regressão compara a nota da versão nova com a da versão em produção e reprova o deploy se a nota cair além de um limite que você define. No PromptEval isso roda no seu CI pela GitHub Action, usando o slug de produção como baseline, nos planos Pro e Team. O efeito prático: uma mudança "inofensiva" que derruba a robustez de 70 para 45 falha o build antes de chegar no usuário, em vez de virar um incidente na segunda-feira.

Um exemplo com nota: antes e depois

O salto entre um prompt reprovado e um pronto para produção quase sempre vem das mesmas alavancas da Etapa 1. Veja um extrator de dados de e-mail, antes e depois.

Mesma tarefa, 44 pontos de diferença. O papel, o formato tipado e a linha "se um campo não estiver no e-mail, use null" são o que faz o prompt aguentar o e-mail bagunçado que sempre chega. Nenhum output novo foi necessário para prever isso: a nota subiu na revisão estrutural, antes de qualquer teste.

O processo mínimo, em 15 minutos

Se não fizer mais nada antes de publicar um prompt, faça estas três coisas:

1. Pontue estruturalmente, com um checklist ou uma ferramenta de score. É onde os +29 do formato e os +24 das restrições aparecem.
2. Rode contra 10 inputs reais, com pelo menos 2 casos extremos e 1 adversarial.
3. Escreva a versão e o critério do que é "correto", para conseguir reproduzir e comparar depois.

A etapa 1 é a que o PromptEval resolve em segundos: você cola o prompt e vê onde ele perde pontos, com a dimensão mais fraca em destaque, antes de qualquer deploy. Essa checagem cabe no plano gratuito. Quando já existe um prompt em produção para proteger, o gate de regressão no CI passa a reprovar sozinho toda edição que derruba a nota. Para a rubrica por trás do número, o guia de como avaliar a qualidade de um prompt de IA mostra o método completo, e o relatório com mais de 1.000 prompts traz os números que sustentam cada etapa acima.

As equipes que shippam IA confiável não são as com o melhor modelo. São as que tratam prompt como código: com teste, versão e um gate que reprova o que regride.

Perguntas frequentes

Como avaliar um prompt antes de colocar em produção?

Meça se ele aguenta input real antes que o usuário veja. Seis etapas: revisão estrutural com nota, conjunto de 20 a 50 inputs, definição do que é "correto", teste de consistência entre execuções e modelos, teste do pipeline e versão com gate de regressão. Nos dados do PromptEval, só 10,5% dos prompts passam da barra de produção de 75.

Quantos casos de teste preciso?

De 20 a 50 bem escolhidos para a maioria dos prompts. A composição pesa mais que o volume: 5 a 7 típicos, 2 a 3 extremos, 1 a 2 adversariais e todas as falhas históricas. Dez é o mínimo para qualquer conclusão.

O que é um gate de regressão de prompt?

Ele compara a nota da versão nova com a da versão em produção e reprova o deploy se a nota cair além do limite que você definiu. No PromptEval roda no CI pela GitHub Action, com o slug de produção como baseline (Pro e Team).

Dá para automatizar a avaliação?

Sim, com um juiz-LLM: um segundo modelo que pontua cada output contra a sua rubrica. É o que permite avaliar centenas de casos sem revisar cada um à mão, e a mesma mecânica que pontua o Treino diário e o Batch A/B.