Evals II
Na semana anterior você definiu o que o agente deveria fazer. Agora precisa comparar duas versões sem confundir preferência, verdade e conclusão da tarefa. Uma resposta pode soar melhor e ainda chamar a ferramenta errada; outra pode concluir a tarefa com texto pouco elegante. Avaliação de produção exige decompor esses resultados e preservar evidência suficiente para explicar por que uma versão venceu.
Vamos construir uma comparação pareada, calibrar um juiz LLM com revisão humana e relacionar qualidade, latência e custo. O princípio de domínio desta fase é simples: nenhuma mudança de prompt ou modelo entra em produção sem métrica ou teste de regressão. Isso não exige transformar toda pergunta em uma nota única; exige definir previamente quais resultados permitem ou impedem a mudança.
JavaScriptIA & MLAvaliaçãoAo terminar esta aula
- Preferência, conclusão e correção de ferramenta são dimensões distintas.
- Juiz LLM precisa de calibragem humana e casos de borda.
- Uma regressão crítica pode vetar uma candidata mais barata e fluente.
Antes de continuar: Laboratório: Evals I
Juiz LLM: avaliador útil, testemunha imperfeita
IA & MLLLM-as-judge utiliza um modelo para aplicar uma rubrica às respostas de outro sistema. Ele pode organizar revisão em escala, mas seu julgamento também é uma saída sujeita a erro. O estudo de MT-Bench e Chatbot Arena descreve vieses como posição, verbosidade e preferência por certas respostas. Esses achados não fornecem uma taxa universal de confiabilidade para qualquer juiz atual. Na prática, forneça a pergunta, a evidência autorizada, as respostas e os critérios. Peça justificativa curta que aponte trechos observáveis, evitando solicitar raciocínio privado.
↗ Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena↗ Evaluation best practices
A calibragem começa com casos anotados por pessoas. Compare decisões do juiz e do revisor, separando divergências por tipo de erro. Um juiz que aceita respostas longas sem evidência pode estar pontuando estilo. Um juiz que rejeita recusas necessárias pode ter entendido completude como obrigação de responder sempre. Corrija a rubrica e faça nova rodada em exemplos independentes. Não use o próprio juiz para declarar que está calibrado: a referência de revisão precisa existir fora dele.
↗ Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena↗ Evaluation best practices
Pairwise eval e a posição das respostas
AvaliaçãoNa avaliação pareada, o avaliador escolhe A, B ou empate para a mesma entrada. Esse formato pode facilitar decisões relativas quando notas absolutas são difíceis de definir. O problema é que preferir B não revela se B é aceitável: duas respostas podem estar erradas. Combine preferência com verificadores absolutos para requisitos obrigatórios. Para reduzir o efeito de posição, apresente a mesma dupla em ordens diferentes e remova nomes que revelem qual versão é a candidata. Registre a ordem junto com a decisão.
Conte vitórias, derrotas e empates com os respectivos denominadores. Defina antes como tratar empates; descartá-los depois pode inflar uma taxa de vitória. Como os resultados pertencem aos mesmos casos, analise transições pareadas em vez de tratar A e B como amostras independentes. Uma vitória em três exemplos interessantes não sustenta uma mudança geral. Examine a distribuição por categoria, repita casos quando houver variabilidade e preserve discordâncias entre ordens como sinal de incerteza.
Tool correctness e task completion são diferentes
FundamentosTool correctness verifica se a ferramenta certa recebeu argumentos válidos, autorizados e adequados à tarefa. Task completion verifica se o objetivo do usuário foi atingido dentro das regras. Um agente pode chamar lookup_order corretamente e ainda abandonar a resposta após obter a compra; também pode responder por acaso corretamente sem consultar a ferramenta obrigatória. Portanto registre a trajetória observável: chamada proposta, argumentos validados, resultado recebido e estado final. Não basta procurar o nome da ferramenta no texto da resposta.
Para uma devolução, a chamada correta exige orderId associado ao usuário autenticado, não apenas um UUID bem formado. A conclusão exige informar elegibilidade conforme a política e registrar um pedido somente quando solicitado e permitido. Divida o avaliador em precondições, efeito e comunicação final. Uma ferramenta indisponível pode levar a escalonamento correto; não marque toda indisponibilidade como falha do agente. O contrato precisa distinguir falha de dependência de tratamento inadequado dessa falha.
Alucinação: comparar afirmações com evidência
FundamentosNesta aula, alucinação significa uma afirmação relevante não sustentada ou contradita pelo contexto disponível. O avaliador deve identificar a afirmação e sua evidência, porque ausência de citação não prova automaticamente falsidade. Se o documento informa 14 dias e a resposta declara 30, existe contradição verificável. Se a resposta diz “sua compra foi aprovada” sem resultado da ferramenta, existe conclusão não sustentada. Uma recusa diante de contexto insuficiente pode ser correta mesmo sem responder à pergunta principal.
Use verificadores específicos para datas, valores e IDs quando o domínio permitir. Um juiz sem acesso ao documento pode premiar uma resposta que coincide com sua memória, mas contradiz a política fornecida. Também evite penalizar reformulações equivalentes. Mantenha uma categoria “evidência insuficiente para julgar” para casos com captura incompleta. Corrigir o instrumento de avaliação é melhor que forçar uma nota definitiva com dados ausentes.
Latência, custo e success rate sem esconder o denominador
FundamentosSuccess rate é o número de tarefas concluídas dividido pelo número de tarefas elegíveis iniciadas, conforme um contrato explícito. Se você remove timeouts do denominador, transforma falhas em uma aparência de sucesso. Latência pode ser medida ponta a ponta e por etapa; mediana e percentis ajudam a mostrar a cauda, mas poucos casos tornam percentis instáveis. Compare versões sob carga e condições semelhantes, incluindo tempo de fila quando o usuário espera por ele.
↗ MLflow Tracing for LLM and Agent Observability↗ Spend Tracking
Custo deve incluir todas as tentativas, chamadas de ferramentas faturadas e uso de modelos, usando tarifas verificadas na data da medição. Não invente um preço fixo para justificar a escolha. Custo por sucesso divide o gasto total pelo número de tarefas concluídas e pode aumentar quando o modelo barato falha mais. Separe custo observado de estimativa calculada. A decisão final é um trade-off: a versão de menor custo só é candidata se preservar requisitos críticos e o nível de qualidade previamente definido.
↗ MLflow Tracing for LLM and Agent Observability↗ Spend Tracking
Regressão pareada com requisitos absolutos
FundamentosExecute node compare.cjs. Os cinco pares abaixo são fixtures construídas para mostrar uma comparação enganosa. B vence mais vezes na preferência textual, mas perde um requisito crítico. O verificador não consulta um juiz real; sua utilidade é estabelecer a regra que receberá avaliações humanas ou de um juiz calibrado.
const assert = require('node:assert/strict');
const pairs = [
{id:1,winner:'B',a:true,b:true,critical:false},
{id:2,winner:'B',a:true,b:true,critical:false},
{id:3,winner:'A',a:true,b:false,critical:true},
{id:4,winner:'tie',a:false,b:false,critical:false},
{id:5,winner:'B',a:false,b:true,critical:false}
];
const wins = pairs.filter(x=>x.winner==='B').length;
const regressions = pairs.filter(x=>x.a && !x.b);
const successes = pairs.filter(x=>x.b).length;
const approved = successes >= 4 && !regressions.some(x=>x.critical);
assert.equal(wins,3);
assert.equal(approved,false);
console.log({wins,total:pairs.length,successes,regressions,approved});B recebe três preferências em cinco pares, mas conclui apenas três tarefas e perde o caso crítico. Os limiares do exemplo são decisões didáticas; um produto deve justificá-los pelo risco e pelos objetivos de serviço. O relatório separado permite perceber que preferência, conclusão e segurança não estão medindo a mesma coisa.
Exercício aplicado
B ganha 60% das comparações textuais, mas faz uma chamada com identidade incorreta e tem mais timeouts. Você precisa justificar o gate e distinguir preferência de sucesso operacional.
- Calcule vitórias incluindo empates no denominador declarado.
- Verifique autorização e confirmação dos efeitos de ferramentas.
- Conte timeouts como resultados conforme o contrato de conclusão.
- Calibre dez pares com revisão humana e inversão de ordem.
Abrir resolução comentada
A preferência textual não autoriza publicação. A chamada com identidade incorreta viola um requisito absoluto, e os timeouts afetam conclusão e latência. O gate deve bloquear B até corrigir a perda e demonstrar a correção em regressão.
Uma revisão responsável apresenta as métricas separadas e abre os casos divergentes. O juiz serve como instrumento; sua decisão deve ser confrontada com fatos do backend e rubrica. Reduzir custo por chamada não implica reduzir custo por tarefa concluída.
const assert = require('node:assert/strict');
const pairs = [
{id:1,winner:'B',a:true,b:true,critical:false},
{id:2,winner:'B',a:true,b:true,critical:false},
{id:3,winner:'A',a:true,b:false,critical:true},
{id:4,winner:'tie',a:false,b:false,critical:false},
{id:5,winner:'B',a:false,b:true,critical:false}
];
const wins = pairs.filter(x=>x.winner==='B').length;
const regressions = pairs.filter(x=>x.a && !x.b);
const successes = pairs.filter(x=>x.b).length;
const approved = successes >= 4 && !regressions.some(x=>x.critical);
assert.equal(wins,3);
assert.equal(approved,false);
console.log({wins,total:pairs.length,successes,regressions,approved});Como conferir seu resultado
- Comparação preserva os 50 IDs e resultados ausentes.
- Vieses de posição são testados com ordem invertida.
- Falha crítica bloqueia a versão preferida.
- Custo observado e simulação estão identificados.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Distinguir preferência e critério absoluto.
- Identificar vieses do avaliador LLM.
B ganha 7/10 comparações; troca ordem das respostas e passa a4/10. B também faz uma tool não autorizada. Interprete.
Conferir raciocínio e critérios de domínio
Mudança com posição sugere viés; calibrar juiz, alternar ordem e revisar evidências.
Tool indevida viola requisito absoluto apesar da preferência textual.
Gate não promove por preferência; medir conclusão/timeout/custo com denominadores próprios.
Evidências para autoavaliação ou revisão por pares
- Juiz: Mudança com posição sugere viés; calibrar juiz, alternar ordem e revisar evidências.
- Operação: Tool indevida viola requisito absoluto apesar da preferência textual.
- Gate: Gate não promove por preferência; medir conclusão/timeout/custo com denominadores próprios.
Um erro frequente
Juiz LLM é verdade independente.
Juiz LLM pode ter vieses; calibrar e revisar evidências.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. Uma vitória pairwise prova que a resposta é correta?
Não.
Duas respostas incorretas podem ser comparadas; requisitos absolutos precisam de verificadores próprios.
2. Por que registrar a ordem apresentada ao juiz?
Para investigar e reduzir viés de posição.
Uma escolha pela primeira resposta não pode ser mapeada para A sem conhecer a ordem.
3. Qual gasto entra no custo por sucesso?
O gasto de todas as tentativas dividido pelos sucessos.
Ignorar falhas subestima o custo operacional do produto.
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- Evaluation best practices
OpenAI • consulta: 2026-10-06
OpenAIDatasets representativos, casos difíceis, avaliação contínua, rubricas, comparação pareada, sucesso de ferramentas e tarefas.
Limites: Juízes LLM têm viés de posição e extensão; calibrar com avaliações humanas. Um score não garante verdade factual.
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
Zheng et al. • consulta: 2026-10-06
IA & MLAvaliação pareada, juiz LLM e análise de vieses e concordância com humanos.
Limites: Resultados pertencem aos modelos e benchmarks do estudo; não tornam o juiz uma fonte de verdade.
- Graders
OpenAI • consulta: 2026-10-06
OpenAIComparação textual, similaridade semântica, graders por modelo e por código.
Limites: Igualdade exata exige formato definido; similaridade não demonstra correção factual.
- MLflow Tracing for LLM and Agent Observability
MLflow • consulta: 2026-10-06
AgentesIA & MLAvaliaçãoEntradas, saídas, metadados, latência e uso de tokens por etapa; integração OpenTelemetry.
Limites: Custo financeiro exige cálculo adicional com tarifas vigentes; traces só cobrem etapas instrumentadas.
- Spend Tracking
LiteLLM • consulta: 2026-10-06
FundamentosRegistro de uso e gasto, atribuição a chaves/usuários e consulta de custos.
Limites: Estimativa de custo depende das tarifas e dos metadados de uso; reconciliar com faturamento do provedor.