Seu eval de domínio em um dia: 40 casos valem mais que qualquer leaderboard

Toda discussão sobre qual modelo usar termina no mesmo lugar: alguém abre um leaderboard.

O problema é que aquele número foi medido em tarefas que não são as suas, com prompts que não são os seus, por um harness que não é o seu, em um domínio que não é o seu. Ele responde uma pergunta interessante e irrelevante.

A pergunta relevante — "este modelo resolve o meu problema com qualidade suficiente e custo aceitável?" — só tem uma fonte de resposta: um conjunto de casos do seu domínio, rotulado por gente que entende do assunto.

A boa notícia é que esse conjunto é muito menor do que as pessoas imaginam. Quarenta casos bem escolhidos separam modelos melhor do que quatro mil casos amostrados ao acaso. Este artigo é o protocolo para montar isso em um dia.

TL;DR

• 40 a 60 casos bem estratificados bastam para a primeira decisão. Não espere ter mil.
• Amostre por estrato, não por aleatoriedade: comum, raro, ambíguo, multilíngue, adversarial.
• Rotule com duas pessoas nos casos difíceis. Desacordo entre humanos é o teto da sua acurácia.
• Separe dev e test no dia zero. Ajustar o corte olhando o test corrompe o número.
• Métrica por primitivo: choice pede matriz de confusão, noul pede calibração, score pede erro absoluto.
• O custo do erro é assimétrico. Ele, e não a acurácia, define o corte operacional.
• Versione o dataset e o baseline. Sem isso você não detecta regressão.

Passo 1: definir a decisão, não a tarefa

Antes de coletar qualquer caso, escreva a frase que o eval precisa responder. Ela tem uma forma fixa:

Vamos usar <modelo/configuração> em <fluxo> se <métrica> ficar acima de <limiar> com custo por sucesso abaixo de <valor>.

Se você não consegue preencher os colchetes, o problema não é falta de dados. É que a decisão ainda não existe, e nenhum eval vai criá-la.

Exemplo concreto, do fluxo de triagem de tickets que uso como caso ao longo desta série:

Vamos usar luna@medium para triagem automática se o recall de tickets urgentes ficar acima de 0,92 e a acurácia de departamento acima de 0,85, com custo por sucesso abaixo de US$ 0,02.

Repare que há dois limiares de qualidade e um de custo, e que o recall de urgência é mais exigente que a acurácia de departamento. Isso não é arbitrário: perder um ticket urgente custa mais do que mandá-lo para o time errado. Voltaremos a isso.

Passo 2: amostragem estratificada, não aleatória

Amostra aleatória de produção tem um defeito previsível: ela é dominada pelo caso fácil. Se 80% dos seus tickets são triviais, 80% do seu eval será trivial, e todos os modelos vão parecer equivalentes.

Você quer o contrário: densidade nos lugares onde os modelos se separam.

Quarenta e quatro casos. Um dia de trabalho, incluindo rotulagem.

Para achar os ambíguos sem ler mil tickets, use o próprio modelo como minerador — não como rotulador:

def mine_ambiguous(candidates, client, questions, n=10):
    """Casos onde o modelo tem baixa confiança são candidatos a ambíguos."""
    scored = []
    for c in candidates:
        r = client.evaluate(c.state, questions)
        probs = r["answers"]["department"]["probabilities"]
        top2 = sorted(probs.values(), reverse=True)[:2]
        margin = top2[0] - top2[1]          # margem pequena = disputa real
        scored.append((margin, c))
    scored.sort(key=lambda x: x[0])
    return [c for _, c in scored[:n]]

O modelo aponta onde olhar. Quem rotula é o humano. Se você aceitar o rótulo do modelo, seu eval vira um teste de consistência do modelo consigo mesmo — e ele passa sempre.

Passo 3: rotular, e medir o desacordo entre humanos

Esta é a etapa que times pulam, e a que mais muda o resultado.

Rotule os casos ambíguos com duas pessoas independentes. Não para ter redundância, mas para descobrir o teto.

from statistics import mean

def human_ceiling(labels_a: list[str], labels_b: list[str]) -> dict:
    """Concordância entre dois rotuladores = teto realista do modelo."""
    agree = [a == b for a, b in zip(labels_a, labels_b)]
    return {
        "concordancia": mean(agree),
        "casos_em_disputa": [i for i, ok in enumerate(agree) if not ok],
    }

Se dois especialistas concordam em 84% dos casos, um modelo com 86% de acurácia não é "bom" nem "ruim" — ele está no nível do desacordo humano, e a diferença já não é estatisticamente interessante. Comparar 86% com 88% nesse regime é ruído.

Mais importante: os casos em disputa quase sempre revelam que a pergunta está mal definida. Se duas pessoas não concordam se um ticket é "technical" ou "billing", o modelo também não vai. A correção é no enum, não no prompt.

# antes: categorias que se sobrepõem
criteria = {
    "billing": "cobrança e pagamentos",
    "technical": "problemas técnicos",     # e uma falha no gateway de pagamento?
}

# depois: fronteira explícita
criteria = {
    "billing": "valores, faturas, reembolsos e disputas de cobrança",
    "technical": "falhas de sistema, incluindo falhas no processamento de pagamento",
}

Uma hora reescrevendo critérios costuma render mais que uma semana ajustando prompt.

Passo 4: split honesto, no dia zero

Separe dev e test antes de rodar qualquer modelo. Congele o test.

import hashlib

def split(case_id: str, test_ratio: float = 0.4) -> str:
    """Split determinístico por hash: reprodutível e estável a novos casos."""
    h = int(hashlib.sha256(case_id.encode()).hexdigest()[:8], 16)
    return "test" if (h % 100) < test_ratio * 100 else "dev"

Hash em vez de random.shuffle porque adicionar casos novos não deve reembaralhar os antigos. Um caso nasce em um lado e fica lá.

A regra de uso é simples e constantemente violada: cortes, prompts e nível de esforço são ajustados olhando só o dev. O test é consultado uma vez, quando a decisão já está tomada, para confirmar. Se você rodou o test cinco vezes ajustando entre elas, ele virou dev e você não tem mais estimativa honesta.