Métricas de Avaliação de Prompt: O Framework de 2 Camadas (2026)

Todo guia de avaliação de prompt que li começa no mesmo lugar: você já rodou o prompt, tem outputs, e agora o que mede? Scores BLEU, ratings de relevância, rubricas de LLM-como-juiz. Tudo válido. Tudo Camada 2.

O que falta é a Camada 1 — a pergunta que você deveria responder antes de rodar qualquer coisa. Esse prompt está estruturalmente sólido o suficiente para produzir outputs confiáveis?

Considere debugar um bot de suporte que continua dando respostas erradas. Você roda 50 casos de teste via LLM-como-juiz e obtém um score de relevância de 0,62. Baixo. Mas o que está causando isso? O modelo? O retrieval? O prompt? Métricas de output não atribuem a falha — apenas a reportam. Métricas da Camada 1 fazem algo diferente: dizem se o prompt em si é o problema, antes de qualquer output existir.

Por que avaliação de prompt precisa de duas camadas

A forma como a maioria das equipes aprende isso é ao contrário. Elas investem em pipelines de avaliação de output, ajustam métricas, montam conjuntos de testes. E continuam encontrando as mesmas falhas porque os prompts que as produzem nunca foram estruturalmente sólidos.

Corrija um problema da Camada 1 — por exemplo, uma instrução vaga que o modelo interpreta diferente em cada execução — e seus scores da Camada 2 melhoram sem tocar no modelo, retrieval ou infraestrutura. As duas camadas não são alternativas. Respondem perguntas diferentes em momentos diferentes do ciclo de desenvolvimento.

Camada 1 — Métricas estruturais (pré-execução)

Quatro dimensões. Cada uma mira um modo de falha distinto. São independentes — um prompt pode ter score alto em clareza e baixo em especificidade.

Nos dados do PromptEval, especificidade falha 2,3× mais que qualquer outra dimensão. As pessoas escrevem requisitos vagos e assumem que o modelo preenche as lacunas corretamente. Às vezes funciona. Quando não funciona, culpam o modelo.

Clareza: O modelo consegue entender a intenção em uma leitura? Sem linguagem ambígua, sem instruções conflitantes, sem tarefa enterrada depois de três parágrafos de contexto.
Passa: "Escreva um resumo de 3 frases do artigo a seguir para um leitor não-técnico."
Falha: "Resuma isso." — Que comprimento? Que audiência? Que nível de detalhe?

Especificidade: A dimensão de maior impacto. Especificidade mede se os requisitos são precisos o suficiente para restringir o output a algo útil — ou se você deixou espaço para o modelo retornar 10 respostas diferentes que todas parecem válidas.
Passa: "Liste exatamente 5 riscos, cada um com menos de 20 palavras, ordenados por probabilidade."
Falha: "Liste alguns riscos." — Quantos? Que comprimento? Em que ordem?

Estrutura: O prompt está na ordem certa? Contexto antes da tarefa, tarefa antes das restrições de formato, restrições de formato antes dos exemplos. Quando essa ordem quebra — formato no topo, tarefa implícita — os modelos produzem outputs de qualidade inferior mesmo quando todas as informações estão tecnicamente presentes.

Robustez: O prompt se mantém quando o input muda? Prompts que funcionam perfeitamente no seu input de teste frequentemente quebram quando um usuário manda algo mais curto, mais longo, fora do assunto ou vazio. Scores de robustez medem se o prompt trata esses casos explicitamente.

Cole seu prompt no PromptEval para obter um score 0–100 nessas quatro dimensões em menos de 10 segundos, com callouts específicos para o que está causando cada penalidade. O guia completo de avaliação de qualidade de prompt cobre como interpretar e agir em cada dimensão.

Camada 2 — Métricas de output (pós-execução)

Depois que o prompt passa pela verificação estrutural, as métricas de output medem se ele está produzindo os resultados corretos para seus inputs específicos.

LLM-como-juiz: Você usa um segundo modelo para avaliar outputs contra seus critérios em escala. Rápido e flexível, mas requer design cuidadoso do prompt do juiz — viés de posição (o modelo favorece a primeira opção), viés de verbosidade (respostas mais longas parecem melhores) e auto-preferência (modelos tendem a favorecer respostas similares ao seu próprio estilo) afetam todos os scores de juiz LLM.

Métricas baseadas em referência (BLEU, ROUGE): Compara outputs com respostas de referência usando sobreposição de n-gramas. Funciona bem para tarefas com outputs corretos verificáveis (SQL, código, extração estruturada), mas é imprecisa para geração aberta onde múltiplas respostas corretas existem.

Revisão humana com rubrica: Mais lenta mas mais confiável para outputs subjetivos como tom, adequação de marca ou seguimento de instruções nuançado. Use quando os critérios de avaliação são difíceis de formalizar.

Aprovação/reprovação binária: Defina um padrão mínimo aceitável para cada critério e verifique cada output contra ele. O mais simples de rodar; fácil de agregar em uma taxa de aprovação em todo o conjunto de testes.

A sequência correta

Avaliação estrutural e de output não são alternativas — são sequenciais. Avalie estruturalmente primeiro. Corrija falhas estruturais óbvias antes de rodar um único teste de output. Rodar testes de output em um prompt não otimizado desperdiça avaliações — você continua encontrando falhas sem saber qual problema estrutural as está causando.

Se o prompt pontua abaixo de 55 na avaliação estrutural, corrija aquelas dimensões antes de montar o conjunto de testes. Se pontua acima de 70, passe diretamente para avaliação de output. Para comparar duas variantes de prompt sistematicamente, este guia sobre teste A/B de prompts cobre o processo completo.

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.