o problema
Prompt engineering sem eval é comparação de duas versões lendo cinco saídas e escolhendo a que soou melhor. Isso não escala e não sobrevive a discordância: duas pessoas olham o mesmo output e uma acha que está bom. Sem um número, não existe critério de parada, não existe regressão detectável e não existe como saber se a troca de modelo melhorou ou piorou a aplicação.
A dificuldade real é que muita coisa que importa parece não ser mensurável. “Resposta segura”, “tom adequado”, “não vaza dado do paciente”, “usa o contexto que foi dado” — tudo isso soa qualitativo demais para virar métrica, e o resultado prático é que ninguém mede nada. A página ataca exatamente esse ponto: o problema não é o tema ser nebuloso, é o critério estar mal escrito.
a ideia
Inverter a ordem de trabalho. Primeiro os critérios de sucesso, depois a bateria de evals que mede esses critérios, e só então o prompt. O ciclo entre os dois primeiros é descrito como o centro do prompt engineering, não como uma etapa de qualidade que vem no fim.
O critério bom tem quatro propriedades: específico (“classificação precisa de sentimento”, não “boa performance”); mensurável, com métrica quantitativa ou escala qualitativa aplicada de forma consistente; alcançável, calibrado por benchmark, experimento anterior ou pesquisa, e não acima do que os modelos de fronteira fazem hoje; e relevante ao propósito da aplicação — precisão de citação é crítica num app médico e secundária num chatbot casual.
O exemplo que carrega a tese é o de segurança. “Saídas seguras” é o critério ruim. O critério bom é: menos de 0,1% das saídas, em 10.000 tentativas, marcadas para toxicidade pelo filtro de conteúdo. Mesmo tema, mesma preocupação — só que agora dá para rodar.
como funciona
A doc lista os critérios que costumam importar: task fidelity, consistência, relevância e coerência, tom e estilo, preservação de privacidade, uso de contexto, latência e preço. A maioria dos casos precisa de avaliação multidimensional, combinando vários deles.
Para o desenho dos evals, três princípios. Ser específico à tarefa: a bateria tem que espelhar a distribuição real de entradas, edge cases inclusos. Automatizar quando der: estruturar as perguntas para permitir nota automática, seja múltipla escolha, string match, código ou LLM. E priorizar volume sobre qualidade — muitas perguntas com sinal um pouco mais fraco batem poucas perguntas corrigidas à mão.
Na hora de dar nota, escolha o método mais rápido, confiável e escalável que resolva. A ordem é:
# code-based: mais rápido e mais confiável
exact match: output == golden_answer
string match: key_phrase in outputGrading por código não tem nuance para julgamento complexo. Grading humano é o mais flexível e de maior qualidade, e a orientação é evitá-lo quando possível, por ser lento e caro. Grading por LLM é rápido, flexível e escalável, adequado a julgamento complexo, com a ressalva de testar a confiabilidade antes de escalar.
Os exemplos de eval da página pareiam critério e método: exact match para fidelidade em análise de sentimento, similaridade de cosseno para consistência de um bot de FAQ, ROUGE-L para sumarização, escala Likert julgada por LLM para tom, classificação binária por LLM para privacidade, escala ordinal por LLM para uso de contexto.
Para o juiz LLM, três recomendações. Rubrica detalhada e explícita, do tipo “a resposta deve sempre mencionar ‘Acme Inc.’ na primeira frase; se não mencionar, é automaticamente incorreta” — e um mesmo critério pode exigir várias rubricas. Saída empírica e restrita: ou correct/incorrect, ou uma nota de 1 a 5, nunca texto livre. E pedir raciocínio antes da nota, descartando o raciocínio depois.
o que isso custou
O método empurra quase tudo para o canto menos confiável do triângulo. Código não julga nuance, humano é caro demais para rodar sempre, então tom, privacidade e uso de contexto acabam avaliados por LLM — e a própria doc admite que esse método precisa ser validado antes de escalar, sem dizer como validar nem quanto de discordância é aceitável.
“Volume sobre qualidade” é uma troca declarada: você aceita sinal mais sujo em cada item para ganhar poder estatístico no agregado. Funciona para detectar regressão grande; é frágil para diferença pequena entre dois prompts.
E a página entrega o método, não os valores. Quantos casos de teste, qual número é bom para o seu domínio, qual limiar barra um deploy: nada disso está aqui, e o critério de “alcançável” ainda amarra sua meta ao teto dos modelos de hoje, que muda a cada release.
onde isso aparece hoje
A combinação rubrica explícita + saída restrita + raciocínio antes da nota é hoje a receita padrão de LLM-as-judge nas bibliotecas de eval. A própria doc fecha com dois encaminhamentos: usar Claude para expandir um conjunto de casos de teste a partir de uma base pequena, e um cookbook com exemplos de evals corrigidos por humano, por código e por LLM. Lida como checklist, a lista de critérios funciona bem para montar o gate de CI de um prompt.