Como Avaliar Prompts Antes de Colocar em Produção

A maioria das equipes testa prompts de forma manual e informal. Aqui está uma abordagem sistemática que detecta falhas antes de chegarem aos usuários.

A maioria das equipes "testa" prompts rodando-os algumas vezes e vendo se o output parece certo. Isso funciona para demos. Não funciona para produção.

Em produção, um prompt roda milhares de vezes com inputs variados. Casos extremos que você nunca pensou em testar vão surgir. Outputs que "pareciam certos" nos testes manuais vão falhar de formas embaraçosas ou caras. O padrão para um prompt de produção é muito mais alto que "funcionou quando testei".

Aqui está uma abordagem sistemática para avaliação de prompts que detecta falhas antes que cheguem aos usuários.

Etapa 1: Revisão estrutural antes de qualquer teste

Antes de rodar um único teste, revise o prompt estruturalmente. A maioria das falhas de produção é previsível lendo o prompt com atenção — você não precisa rodá-lo para identificá-las. Se não sabe o que procurar, o framework de 4 dimensões é um bom ponto de partida.

Procure por:

• Instruções ambíguas: Qualquer lugar onde o modelo pode interpretar sua intenção diferente do que você quer
• Restrições faltando: Coisas que você sabe mas não disse ao modelo
• Output subespecificado: Formato ou comprimento deixados para o julgamento do modelo
• Instruções conflitantes: Dois requisitos que não podem ser satisfeitos simultaneamente

Uma ferramenta de scoring como o PromptEval pode identificar isso automaticamente, mas você também pode fazer manualmente com um checklist. De qualquer forma, não pule esta etapa — é mais rápido do que debugar falhas em produção.

Etapa 2: Construa um conjunto de testes representativo

Testes manuais aleatórios não são avaliação. Você precisa de um conjunto de testes — uma coleção de inputs que representa a distribuição real do que o prompt vai receber em produção.

Um bom conjunto de testes inclui:

• Inputs típicos (o caminho feliz)
• Casos extremos (inputs vazios, inputs muito longos, inputs em idiomas inesperados)
• Inputs adversariais (inputs projetados para quebrar as suposições do seu prompt)
• Falhas históricas (se você tiver de versões anteriores)

Para a maioria dos prompts de produção, 20–50 casos de teste é suficiente para detectar os principais modos de falha. 20 casos bem pensados superam 100 aleatórios.

Etapa 3: Defina o que "correto" significa antes de rodar os testes

Esta é a etapa que a maioria das equipes pula — e é a mais importante. Antes de rodar seu conjunto de testes, escreva o que é um output correto para cada caso. Não uma descrição vaga — um critério específico e avaliável.

Ruim: "O output deve ser útil e claro."
Bom: "O output deve ser um objeto JSON com exatamente essas chaves, o resumo deve ter menos de 100 palavras e não deve incluir informações não presentes no input."

Se você não consegue definir correto antes de rodar o teste, vai racionalizar qualquer coisa que o modelo produza como "basicamente certo". Pré-definir a correção te força a ser honesto sobre falhas.

Etapa 4: Teste para consistência, não apenas correção

Um prompt de produção precisa ser consistente entre execuções, não apenas correto na média. A maioria da inconsistência vem de lacunas estruturais no próprio prompt — as mais comuns estão detalhadas aqui.

Rode o mesmo caso de teste várias vezes e verifique se o output varia de formas que importariam.

Configurações de temperatura, atualizações de modelo e efeitos de context window podem introduzir inconsistência que não aparece em testes de execução única. Se seu prompt está rodando em temperatura alta ou produzindo formatos diferentes em execuções diferentes, isso é um problema estrutural — não de sorte.

Etapa 5: Teste o impacto downstream

Se o output do seu prompt está sendo parseado, processado ou passado para outro sistema, teste o pipeline completo — não apenas o prompt em isolamento. Um prompt pode produzir outputs "corretos" que ainda quebram o sistema porque estão no formato errado, contêm caracteres inesperados ou violam uma suposição que o próximo passo faz.

Para prompts que retornam dados estruturados (JSON, CSV, formatos específicos), teste o que acontece quando o output está ligeiramente malformado. Seu código de parsing provavelmente é menos robusto do que você acha.

Etapa 6: Versione e documente antes de publicar

Antes de fazer deploy, salve o texto exato do prompt, a versão do modelo, as configurações de temperatura e os resultados dos testes. Parece óbvio, mas a maioria das equipes não faz — e depois não consegue diagnosticar por que os outputs mudaram.

Versionamento de prompts é a diferença entre "algo quebrou e não sabemos por quê" e "conseguimos reproduzir o estado exato antes da regressão". Também é o que permite rollback seguro quando algo dá errado em produção.

O processo mínimo viável de avaliação

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

1. Pontue estruturalmente — use um checklist ou uma ferramenta, mas não pule isso
2. Rode contra 10 inputs reais incluindo pelo menos 2 casos extremos
3. Escreva a versão e o que "correto" parece

Leva 15 minutos. Vai economizar horas de debugging em produção.

As equipes que constroem features de IA confiáveis não são as que têm os melhores modelos — são as que tratam prompts como código: com testes, versionamento e um padrão claro para o que "feito" significa.

Apply what you just learned — evaluate your prompt free.