Model Graders: LLMs avaliando LLMs sem viés

Você rodou seu eval. Verde em 92% dos casos. Subiu pra produção. Na primeira semana, três usuários reclamando que o agente "tá esquisito", o NPS caindo e o time tentando entender o que vazou no pipeline.

A resposta provavelmente está no seu grader.

LLM-as-judge virou o atalho padrão pra escalar avaliação de IA. Anthropic embutiu Outcomes nos Managed Agents. OpenAI expôs score_model e label_model no Graders API. E Zheng et al. mostraram que GPT-4 como juiz bate 80% de agreement com humanos, no mesmo nível de inter-annotator. Bonito no benchmark.

Só que tem um detalhe: o grader é um LLM. E LLM tem viés. Se você confia cego no veredicto dele, você empacotou o viés direto no pipeline e chamou de métrica.

Esse post é sobre os três padrões de prompt que time real usa pra montar grader (rubric, reference, pairwise) e os três erros que silenciosamente invalidam o resultado. Cada erro vem com mitigação concreta, não com lista de boas práticas genérica.

TL;DR

O que é: LLM-as-judge é usar um modelo pra pontuar saídas de outro modelo (ou de si mesmo) contra critério, referência ou par.
Stack/Modelos: Claude Opus/Sonnet, GPT-4.1, o4-mini, Gemini Pro. Vale qualquer um suficientemente forte pra seguir rubric.
Custo/Acesso: API paga. Em volume é uma fração do custo de avaliação humana.
Padrões cobertos: rubric-based (1 resposta + critério), reference-based (golden answer), pairwise (A vs B).
Erros que invalidam: mesmo modelo gera e julga; ignorar position e verbosity bias; nunca calibrar com humanos.

Por que LLM-as-judge virou padrão (e por que isso é uma armadilha)

Avaliar LLM é caro. Humano expert custa horas, não escala, varia de avaliador pra avaliador. Métrica clássica de NLP (BLEU, ROUGE) não captura nuance. Sobrou LLM avaliando LLM como ponto doce: rápido, escalável, captura nuance.

A indústria foi atrás. A doc oficial da Anthropic sobre evals lista três métodos de grading (code-based, human, LLM-based) e descreve LLM-based como "fast and flexible, scalable and suitable for complex judgement". A OpenAI publicou graders parametrizáveis com schema fechado, threshold e modelo configurável. G-Eval (Liu et al., EMNLP 2023) demonstrou que LLM-as-judge com chain-of-thought atinge correlação de Spearman 0.514 com humanos em sumarização, batendo as métricas anteriores por uma margem absurda.

Tudo verdade. E é exatamente por isso que vira armadilha: o grader é tão competente que dá vontade de confiar de olhos fechados. E quando o grader é viesado, ele não erra ruidosamente. Ele erra consistentemente na mesma direção, e seu eval inteiro vira um espelho do viés.

Os três padrões de prompt para grader

Antes dos erros, o repertório. Tem três jeitos canônicos de montar grader. Você vai usar pelo menos dois em qualquer pipeline sério.

1. Rubric-based (single answer)

O grader recebe uma única resposta e um critério. Devolve nota.

Bom para: avaliar tom, completude, segurança em produção, sinal contínuo onde não tem golden answer.

Você é um avaliador. Pontue a resposta abaixo segundo o critério.

Critério: A resposta deve ser tecnicamente correta e citar a fonte.
Escala: 1 (não atende) a 5 (atende perfeitamente).

<resposta>
{output}
</resposta>

Antes de pontuar, raciocine em <thinking>...</thinking> sobre o que falta ou sobra.
Depois retorne apenas <score>N</score>.

A doc da Anthropic recomenda exatamente esse formato: "Ask the LLM to think first before deciding an evaluation score, and then discard the reasoning. This increases evaluation performance, particularly for tasks requiring complex judgement".

2. Reference-based (golden answer)

O grader recebe a resposta do modelo + uma resposta de referência. Devolve match, parcial ou erro.

Bom para: tarefas com gabarito (Q&A factual, classificação, transformação determinística onde o output é texto livre).

Você é um avaliador. Compare a resposta do modelo com a referência.

<referencia>{golden_answer}</referencia>
<resposta>{output}</resposta>

A resposta cobre os mesmos fatos da referência? Considere paráfrase aceitável.
Retorne em <result>correct|incorrect|partial</result>.

A grande vantagem é que dá pra testar o próprio grader: você sabe a resposta certa, o grader tem que bater. A grande armadilha é que o grader pode julgar paráfrase como erro mesmo quando faz sentido.

3. Pairwise (A vs B)

O grader recebe duas respostas pro mesmo prompt e escolhe a melhor.

Bom para: comparar modelos, validar mudança de prompt, montar dataset de preferência pra fine-tuning.

Você é um avaliador. Para o prompt abaixo, qual resposta é melhor?

Prompt: {prompt}

Resposta A: {output_a}
Resposta B: {output_b}

Critérios: correção técnica, clareza, ausência de alucinação.
Retorne em <winner>A|B|tie</winner> com justificativa em <reasoning>.

Pairwise costuma dar sinal mais forte que rubric absoluto. Humano também é melhor comparando que pontuando. Foi o método central do MT-Bench e Chatbot Arena. Mas é o mais frágil em termos de viés (já já volto nele).

Os 3 erros que invalidam o seu eval

Aqui é onde o pipeline derrete. Cada erro tem documentação científica por trás e mitigação concreta.

Erro 1: usar o mesmo modelo pra gerar e pra julgar

Você gera com Claude Sonnet. Avalia com Claude Sonnet. Faz sentido ergonomicamente, mas o resultado é viciado.

Wataoka, Takahashi e Ri (NeurIPS 2024) mostraram que o self-preference bias não está em "o modelo gosta do próprio nome". Está em perplexity: LLMs avaliam mais alto saídas com menor perplexity (texto mais familiar pra eles), independente de quem gerou. Como o modelo que gerou tem perplexity mínima nas próprias saídas, ele se auto-favorece sistematicamente.

A doc da Anthropic é explícita: "Generally best practice to use a different model to evaluate than the model used to generate the evaluated output".

Mitigação:

Cross-model. Gera com um modelo, julga com outro. Sonnet gera, GPT-4.1 julga. Ou inverte.
Ensemble. Em decisão crítica, três judges diferentes votam. Discordância vira sinal pra revisão humana.
Teste de auto-favorecimento. Antes de confiar no grader, dá pra ele pares onde o "perdedor" foi gerado pelo mesmo modelo do judge. Se ele consistentemente prefere a saída do irmão, você tem o problema medido.

Erro 2: ignorar position bias e verbosity bias em pairwise

Esse é o erro que mais aparece em pipeline real porque pairwise é o padrão usado pra comparar modelos.

Position bias: o judge prefere a resposta da posição A (ou B, depende do modelo). Zheng et al. documentaram em três modelos diferentes. Um estudo sistemático posterior confirmou que mesmo modelos de fronteira mudam o veredicto quando você inverte a ordem.

Verbosity bias: o judge prefere a resposta mais longa, mesmo quando ela só repete o mesmo conteúdo. Justice or Prejudice (Ye et al., 2024) cataloga isso junto com fallacy oversight e sentiment bias.

Os dois juntos significam que sua "vitória de 60%" do modelo novo pode ser 50/50 com mais palavras na posição A.

Mitigação:

Avaliação dupla com inversão. Roda o pair como (A, B) e como (B, A). Só conta como vitória se A ganha nas duas. Se inverter, é tie. Custa 2x em tokens, derruba position bias completamente.
Penalizar verbosity no rubric. "Em caso de empate em qualidade, prefira a resposta mais concisa." Sem isso o judge usa tamanho como tie-breaker.
Normalizar tamanho. Se o problema é grave, trunca ambas no mesmo limite antes de mandar pro judge.
Misturar ordem aleatoriamente em batch. Nunca rode todo o eval com o seu modelo favorito sempre em A.

Erro 3: nunca calibrar o grader com humanos

Esse é o erro silencioso. O grader roda há seis meses, todo mundo confia, ninguém testou se ele bate com humano expert.

A doc oficial da Anthropic é direta: "LLM-as-judge graders should be closely calibrated with human experts to gain confidence that there is little divergence between the human grading and model grading". A OpenAI insiste em "writing grader prompts is an iterative process" e recomenda validar a hierarquia: o grader tem que pontuar model_grader(answer_1) > model_grader(answer_2) quando você sabe que answer_1 é melhor.

Sem calibração, dois efeitos cascateiam:

Você está otimizando o errado. Se o seu grader gosta de respostas burocráticas e o usuário gosta de respostas diretas, cada iteração afasta o produto do usuário e aproxima do gosto do grader.
Grader hacking. O modelo gerador descobre, sozinho, qual padrão o grader recompensa. Comum em RLAIF e em loops de auto-melhoria.

Mitigação:

Held-out humano de 50 a 200 exemplos. Domínio especialista pontua segundo o mesmo rubric. Você roda o LLM-grader nos mesmos exemplos e mede agreement. Aceitável a partir de ~80% de agreement em domínio subjetivo. Cohen's kappa > 0.6 é régua decente.
Recalibre depois de mudar prompt do grader, modelo, ou rubric. Toda mudança no judge é mudança no instrumento de medida.
Leia transcripts. A advice mais antifrágil que tem: separa 20 casos por semana e lê os reasonings do judge. Você vai pegar erro qualitativo que nenhum agreement % captura.
Rotacione modelos do grader. Se você sempre usa GPT-4.1 como judge, padrões viciam nele. Sortear entre dois ou três modelos por avaliação dilui o problema.

Montando isso na prática

Esqueleto que dá pra rodar hoje, com Anthropic SDK em Python:

import anthropic

client = anthropic.Anthropic()

GRADER_PROMPT = """Você é um avaliador rigoroso.

Critério: {criteria}
Escala: 1 (não atende) a 5 (atende perfeitamente).

<resposta>{output}</resposta>

Pense em <thinking>...</thinking> antes de pontuar.
Em caso de empate em qualidade, prefira a resposta mais concisa.
Retorne apenas <score>N</score> ao final.
"""

def grade(output: str, criteria: str, judge_model="claude-opus-4-7") -> int:
    msg = client.messages.create(
        model=judge_model,
        max_tokens=1024,
        messages=[{
            "role": "user",
            "content": GRADER_PROMPT.format(output=output, criteria=criteria),
        }],
    )
    text = msg.content[0].text
    return int(text.split("<score>")[1].split("</score>")[0])

def grade_pairwise(prompt, a, b, judge_model="claude-opus-4-7"):
    # Avalia nas duas ordens pra anular position bias.
    v1 = _judge_pair(prompt, a, b, judge_model)
    v2 = _judge_pair(prompt, b, a, judge_model)
    if v1 == "A" and v2 == "B":  # ganhou nas duas
        return "A"
    if v1 == "B" and v2 == "A":
        return "B"
    return "tie"

Padrão importante: gerador e judge são modelos diferentes (no exemplo, gerar com claude-haiku-4-5, julgar com claude-opus-4-7, ou cruzar com a OpenAI). E o grade_pairwise resolve position bias com o truque das duas ordens.

Se você está na stack OpenAI, o equivalente é declarar o grader em config:

{
  "type": "score_model",
  "name": "answer-quality",
  "model": "o4-mini-2025-04-16",
  "input": [
    {"role": "system", "content": "Você é um avaliador rigoroso..."},
    {"role": "user", "content": "Critério: {{ item.criteria }}. Resposta: {{ sample.output_text }}"}
  ],
  "range": [1, 5],
  "pass_threshold": 4,
  "sampling_params": {"reasoning_effort": "medium"}
}

A vantagem aqui é que a OpenAI gerencia execução, threshold e reporte. A desvantagem é que você fica preso aos modelos suportados (gpt-4.1, o4-mini, o3 e variantes).

Limitações e quando o LLM-grader não serve

LLM-as-judge não é universal. Tem casos onde é a ferramenta errada:

Tarefa verificável determinística. Código que tem que rodar, math que tem resposta única, parsing JSON. Use assert, não Claude. Mais barato, mais confiável, zero viés.
Domínio com risco regulatório. Saúde, jurídico, financeiro de alto risco. LLM-grader é input, não veredicto. Humano expert no loop.
Avaliar modelo mais forte que o seu judge. Se você está testando GPT-5 com judge GPT-4.1, o judge vira gargalo. Ele não consegue distinguir um output excelente de um output só bom. Sobe o tier do judge ou volta pra humano.
Sinal já saturado. Se 100% dos casos passam no grader, ele não está medindo mais nada. Aumenta a dificuldade do dataset ou aposenta o grader.

A regra é simples: LLM-grader é instrumento de medida. Trata ele como termômetro de produção: calibra, valida contra padrão, troca quando o sinal degrada.

FAQ rápido

Posso usar Claude pra julgar saída do Claude? Pode, mas evita. O self-preference bias é mensurável. Se for inevitável (custo, latência), pelo menos varie a versão (Sonnet julgando Opus, ou inverso) e calibre com humano.

Quantos exemplos humanos preciso pra calibrar? Mínimo viável: 50 com label expert. Confortável: 200. O importante não é o número absoluto, é que o set seja representativo da distribuição real de produção e inclua casos de borda.

Pairwise ou rubric absoluto, qual escolher? Pairwise pra preferência relativa (escolher entre dois prompts, dois modelos). Rubric absoluto pra threshold de aceite em produção (passou de 4? deploya). Pipeline maduro usa os dois.

Como evito grader hacking quando uso o judge num loop de RLAIF? Rotacionar judges entre rounds, manter held-out humano fixo que nunca entra no loop, monitorar drift do agreement humano vs judge. Se o gap aumenta, o gerador aprendeu a hackear o judge.

Conclusão

LLM-as-judge é alavanca brutal. Você sai de avaliação humana cara e lenta pra avaliação contínua e barata, e isso muda o que dá pra construir em IA aplicada. Anthropic e OpenAI já trataram o grader como produto de primeira classe, com schema, threshold e modelo dedicado.

Mas alavanca sem ponto de apoio empurra o nada. Se você gera e julga com o mesmo modelo, ignora position e verbosity bias em pairwise, e nunca compara o seu grader com humano expert, todo o eval que você está rodando é um espelho do viés do judge dressed up como métrica. Você não está medindo a qualidade do produto. Está medindo o gosto do grader.

O próximo passo é tratar o grader como você trata o resto da stack: versionado, testado, calibrado. Cross-model por padrão, dupla avaliação com inversão em pairwise, held-out humano que nunca entra no loop. É chato, é trabalho, e é a diferença entre ter eval e ter teatro de eval.