Como Fazer Teste A/B de Prompts de IA (Guia Multi-Critério com Exemplos Reais)

Dados do leaderboard público do PromptEval mostram que mesmo prompts de produção bem ranqueados — com score acima de 70 de 100 — consistentemente têm pontos fracos em pelo menos uma dimensão estrutural. O prompt que você acha melhor frequentemente não é, nas formas específicas que importam para seu caso de uso.

Teste A/B é como você descobre com certeza. Mas a forma como a maioria dos desenvolvedores testa prompts — roda os dois algumas vezes, vê qual parece melhor — não produz conclusões confiáveis. Este guia dá um método sistemático que produz.

Por que teste A/B de prompts é mais difícil que A/B de páginas web

Testes A/B de páginas web medem uma única métrica: taxa de clique, conversão, tempo na página. Um número, vencedor claro.

Testes A/B de prompts são inerentemente multidimensionais. Um prompt pode ser melhor em seguir instruções de formato mas pior em tom. Melhor para inputs curtos mas pior para casos extremos. Melhor para um modelo mas não para outro. Se você avalia em apenas uma dimensão, vai otimizar para ela enquanto regride em outras que não mediu.

Por isso teste A/B de prompts requer critérios explícitos e pré-definidos — não uma sensação vaga de qual output parece melhor. Os critérios que você escolhe antes de rodar o teste determinam o que você realmente aprende com ele. Escolhê-los depois de ver os resultados é como você confirma seu viés pré-existente em vez de testá-lo.

O Framework PACE para Teste A/B de Prompts

PACE é um processo de quatro etapas para rodar testes A/B de prompts que produzem resultados acionáveis, não apenas impressões.

P — Pareie seus prompts. Defina o Prompt A e o Prompt B com uma única variável diferente entre eles. O erro mais comum é mudar múltiplas coisas ao mesmo tempo — system prompt, papel, formato e tom — e depois não saber qual mudança gerou o resultado. Teste uma variável por vez.

A — Afirme seus critérios. Escreva o que "melhor" significa antes de rodar um único teste. Seja específico e binário ou com score onde possível: "Resposta fica abaixo de 150 palavras" é testável. "Resposta é clara" não é. Para cada critério, decida: é aprovação/reprovação ou um score de 1 a 5? Mire em 3 a 7 critérios. Menos de 3 perde dimensões significativas; mais de 7 cria ruído nos resultados.

C — Cubra seus inputs. Monte um conjunto de testes que represente a distribuição real que seu prompt vai enfrentar em produção — não só inputs que você espera que ele trate bem. Um conjunto representativo para a maioria dos prompts de produção inclui: 5-7 inputs típicos (o caminho feliz), 2-3 casos extremos (formatos incomuns, informações ausentes, solicitações limítrofes) e 1-2 inputs adversariais. Dez inputs no total é o mínimo para conclusões significativas.

E — Avalie e compare. Rode os dois prompts em todos os inputs. Pontue cada output contra cada critério. Some os scores. O prompt que vence em mais critérios em mais inputs é a melhor escolha — mas olhe para o breakdown dimensional antes de decidir. Um prompt que vence 6 de 7 critérios mas perde no que é mais crítico para seu caso de uso não é a escolha certa, mesmo que o score total seja maior.

Antes de aplicar o PACE, uma verificação de qualidade estrutural em cada variante de prompt pega problemas que vão tornar seus resultados de teste sem sentido independente de quão bem você projetou o teste. O guia de avaliação de qualidade de prompt cobre como fazer isso em menos de 10 segundos.

Como definir critérios de avaliação que realmente medem o que importa

O modo de falha aqui é escrever critérios que parecem específicos mas não são. "Precisão" não é um critério. "A resposta contém apenas informação presente no contexto fornecido, sem fatos alucinados" é um critério.

Seis categorias de critérios que funcionam para a maioria dos testes de prompt de produção:

• Conformidade de formato: O output corresponde ao formato especificado? (schema JSON, contagem de bullets, contagem de palavras, cabeçalhos de seção)
• Seguimento de instruções: O output aborda o que foi pedido, sem ignorar ou reinterpretar a solicitação?
• Ancoragem factual: O output evita introduzir informação que não está no input ou contexto?
• Consistência de tom: O output mantém o tom especificado em diferentes tipos de input?
• Tratamento de casos extremos: O output se comporta corretamente quando o input é ambíguo, tem dados ausentes ou está fora do padrão?
• Comprimento de output: A resposta está dentro da faixa de comprimento especificada — nem truncada nem preenchida?

Exemplo real: dois prompts, 5 critérios, 10 inputs

Uma equipe de suporte SaaS está testando dois system prompts para um agente de triagem de tickets. O agente lê tickets de suporte e os classifica por urgência (P1/P2/P3) e categoria (faturamento, técnico, geral).

Prompt A (conciso): "Você é um agente de triagem de suporte. Classifique cada ticket por urgência (P1: sistema fora, P2: feature principal quebrada, P3: problema menor ou pergunta) e categoria (faturamento, técnico, geral). Retorne JSON: {urgência, categoria, motivo}."

Prompt B (detalhado): inclui definições expandidas de cada nível de urgência, exemplos de cada categoria, e instruções de fallback para tickets ambíguos.

Após rodar os dois contra 10 inputs reais:

• Conformidade de formato: Prompt A: 9/10 · Prompt B: 10/10
• Seguimento de instruções: A: 8/10 · B: 9/10
• Ancoragem factual: A: 10/10 · B: 10/10
• Consistência de urgência: A: 7/10 · B: 9/10
• Tratamento de casos extremos: A: 5/10 · B: 8/10

O Prompt B vence 4 de 5 critérios. Mas o Prompt B também usa 3× mais tokens. Para um sistema que roda 10.000 classificações por dia, isso é uma diferença de custo real. A decisão não é automática — você tem os dados para tomar uma decisão informada em vez de uma fundamentada em intuição.

Sem uma configuração de teste formal com critérios pré-definidos, você provavelmente teria escolhido o Prompt A por parecer "mais limpo" — e continuaria se perguntando por que tratamento de casos extremos estava falhando em produção.

Ferramentas para teste A/B de prompts sem código

A abordagem tradicional requer um script Python, uma API key, um dataset JSON e 30-60 minutos de configuração antes de ver um único resultado. Isso é um investimento razoável para pipelines de avaliação de CI/CD. É uma barreira desproporcional para um gerente de produto ou fundador que precisa de uma resposta direcional antes de se comprometer com um pipeline de avaliação completo.

O Batch A/B Test do PromptEval roda comparações estruturadas multi-critério em um wizard no browser. Você define dois prompts, até 7 critérios e até 10 inputs de teste — o LLM juiz avalia cada combinação e exibe radar chart e bar chart por dimensão. Requer BYOK (Anthropic ou OpenAI), disponível nos planos Pro e Team.

Se você quer iterar em variantes de prompt antes de se comprometer com um teste em lote, o Playground (Pro) permite testar prompts ao vivo contra a API da Anthropic ou OpenAI com sua própria chave, vendo outputs em tempo real com diferentes inputs antes de desenhar a comparação formal.

Score your prompts before they hit production

PromptEval scores prompts 0–100 across 4 dimensions — clarity, structure, context, and output spec — and tells you exactly what to fix.