YoursSarcastically/eval-design

O que eval-design faz?

Você está projetando a medição, não o produto. O resultado desta skill é uma decisão que alguém pode defender em uma sala, não um número.

Na maioria das vezes a decisão é o que corrigir em seguida. Um eval que apenas classifica sistemas é um relatório; um eval que nomeia as duas coisas que mais custam para você, e prova que a correção funcionou quando você o executa novamente, é um loop de desenvolvimento. Construa para o segundo — a taxonomia de falhas e a análise por critério importam mais do que a pontuação principal, porque essas são as partes nas quais alguém pode agir.

A posição

Quatro regras. São opiniões, e são o ponto central desta skill.

1. Sem 'vibes'. "Parece melhor" não é um resultado. Se uma mudança não pode ser expressa como um movimento em um critério definido medido em um conjunto fixo, ela não foi avaliada. Lance-a se quiser — apenas não afirme que foi testada.

2. Todo critério deve ser discutível. Um critério no qual dois revisores cuidadosos não poderiam se posicionar em lados opostos está medindo nada. "A saída é útil?" não é um critério. "A resposta informa o período de reembolso em dias?" É. Todo critério em uma rubrica carrega a discordância específica que foi escrito para resolver — veja references/rubric-design.md.

3. Nenhum LLM-juiz por padrão. Um juiz é um sistema com sua própria taxa de erro, e um juiz não validado lava esse erro para o seu número principal. Humanos rotulam primeiro, o juiz é calibrado contra esses rótulos, e a concordância é publicada ao lado de cada resultado que o juiz produziu. Veja references/judges.md.

4. Reporte a linha de base ou o eval é marketing. Regex, uma regra de palavra-chave, o sistema de produção atual, ou não fazer nada. Aproximadamente um terço das funcionalidades de IA lançadas perdem para algo que não custa nada em pelo menos um critério, e você quer descobrir isso antes de um gerente de contratação ou um vice-presidente descobrir.

Duas regras estruturais decorrem destas:

• Portões são pisos, não pesos. Um critério de segurança, jurídico ou de confiança não é negociado contra o desempenho médio. Um sistema abaixo do piso não é um candidato a nenhum preço. Médias ponderadas escondem exatamente isso.
• Intervalos de confiança ou nenhuma classificação. Com n=150 uma diferença de 3 pontos é ruído. Classificar sistemas dentro do ruído é a maneira mais comum de o trabalho de eval enganar quem o lê.

Fluxo de trabalho

Trabalhe nesta ordem. Não pule para a pontuação — toda falha de eval remonta a algo pulado acima.

1. Encontre a decisão. O que muda com base no resultado? "Qual modelo enviamos", "isso pode ficar sem supervisão", "a mudança de prompt regrediu". Se nada mudar, pare e diga isso — este é o momento mais valioso do processo, e a resposta honesta às vezes é "você não precisa de um eval".
2. Escreva a taxonomia de falhas primeiro. Antes dos critérios. Colete 30–50 saídas reais, leia cada uma e agrupe o que deu errado. Critérios derivados de falhas observadas superam critérios derivados da imaginação, todas as vezes. → references/failure-taxonomy.md
3. Transforme a taxonomia em critérios. Cada um recebe um peso, uma discordância e, opcionalmente, um portão. → references/rubric-design.md
4. Construa o conjunto dourado. Estratificado, adversarial, versionado e pequeno o suficiente para que um humano realmente o rotule. → references/golden-sets.md
5. Rotule com humanos, meça a concordância. Se dois rotuladores não puderem concordar, a rubrica está quebrada, não os rotuladores. Corrija a rubrica e re-rotule. → references/statistics.md
6. Apenas agora considere um juiz, e apenas calibrado. → references/judges.md
7. Execute todos os sistemas, incluindo uma linha de base não-IA, escreva results.json e renderize. → references/scorecard-spec.md
8. Escreva o veredito você mesmo. O scorecard mostra números; um humano declara a troca sendo feita e o que reverteria a decisão.

Renderização

python3 skills/eval-design/scripts/render_scorecard.py results.json --md

Escreve um scorecard.html autocontido (sem requisições externas, claro e escuro) e um SUMMARY.md para leitura no repositório. Esquema: references/scorecard-spec.md.

python3 skills/eval-design/scripts/validate_rubric.py results.json

Falha nos erros que tornam um scorecard desonesto: pesos que não somam 1, critérios sem discordância declarada, portões sem justificativa, linha de base ausente ou uma classificação reivindicada dentro do intervalo de confiança.

Quando não usar isso

• Um ajuste de prompt único sem decisão associada. Apenas olhe para a saída.
• Você não tem usuários nem exemplos. Obtenha 30 entradas reais primeiro. Um eval construído em entradas imaginadas mede sua imaginação.
• A tarefa tem uma resposta correta que um programa pode verificar — aritmética, JSON válido, uma compilação que constrói. Escreva a verificação, não uma rubrica.
• Alguém quer um número para justificar uma decisão já tomada. Diga isso em voz alta em vez de construir o eval.

Arquivos de referência

Carregue sob demanda; não os leia todos de uma vez.

Arquivo	Leia quando
references/rubric-design.md	Escrevendo ou corrigindo critérios
references/failure-taxonomy.md	Começando a partir de saídas reais
references/golden-sets.md	Escolhendo e estratificando casos
references/judges.md	Alguém propõe usar LLM-juiz
references/statistics.md	Tamanho da amostra, ICs, concordância, deriva
references/scorecard-spec.md	Escrevendo results.json
references/antipatterns.md	Revisando o eval de outra pessoa