Evals II
Você usará os 50 casos da semana 36 para comparar versões A e B do assistente. Congele prompts, política, documentos e respostas das ferramentas. O artefato final será uma tabela pareada com decisões absolutas, preferência e divergências de revisão. A avaliação deve expor uma regressão de autorização mesmo se a candidata escrever respostas mais agradáveis.
O runner funciona em Node sem credenciais. Para a etapa opcional de juiz LLM, use uma conta autorizada, chave no ambiente e um modelo identificado; registre uso e custo observado. Execute primeiro a comparação com fixtures para validar o contrato. Chamadas reais precisam ser registradas separadamente, sem tratar a saída determinística abaixo como um experimento com modelo.
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: Leitura: Evals II
Congelar entradas e executar as duas versões
FundamentosCrie um manifesto com promptVersion, modelId, datasetHash, policyVersion e parâmetros de geração. Execute A e B nos mesmos IDs e guarde resposta, chamadas de ferramentas, duração e falhas. Quando uma execução terminar em timeout, grave um resultado explícito. Não substitua uma falha por uma nova tentativa silenciosa: o retry faz parte do comportamento e do custo. Para testar o runner sem APIs, use cinco fixtures, incluindo uma tarefa não concluída e uma perda crítica. Depois estenda o formato aos 50 casos, mantendo os resultados brutos para auditoria.
Separar preferência de aprovação
FundamentosExecute o exemplo e confirme três vitórias textuais para B com aprovação falsa. Em seguida altere o caso 3 para b:true e o caso 4 para b:true: a candidata deve cumprir o limiar didático. Volte ao conjunto original e acrescente contadores por categoria. Um relatório útil informa quantos casos melhoraram, pioraram ou permaneceram iguais. Rejeite uma comparação quando uma versão tiver IDs ausentes. A ordem dos arrays não identifica um caso; use uma chave estável e valide que a correspondência seja completa antes de calcular qualquer taxa.
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});Construir o protocolo de juiz e calibrar
FundamentosSelecione dez pares que incluam resposta longa errada, resposta curta correta, empate verdadeiro e recusa necessária. Anote-os manualmente antes de usar o juiz. Apresente a pergunta, fonte e rubrica sem rótulos de versão, exigindo decisão entre primeira, segunda e empate. Inverta a ordem em uma segunda rodada. Converta a decisão para A/B somente depois de registrar a ordem. Conte divergências com humanos e divergências entre ordens; abra as justificativas para saber se o problema está na rubrica, na captura ou no avaliador. Não afirme calibragem universal com esses dez pares.
Validar ferramentas e conclusão com evidência
FundamentosPara cada compra, confronte orderId e identidade autenticada com o registro de autorização. Insira uma fixture em que o agente chama a ferramenta correta com ID de outra pessoa: o nome da ferramenta não deve bastar para aprovação. Insira outra em que a consulta funciona, mas o agente inventa que o estorno foi efetivado. O avaliador de conclusão deve exigir confirmação do backend. Finalmente simule ferramenta indisponível e confirme que o encaminhamento definido pela política conta como tratamento correto, embora a dependência tenha falhado. Documente esses estados separadamente.
Medir custo e escrever a decisão de publicação
FundamentosSome tentativas e contabilize tarefas concluídas. Se houver modelo real, registre tokens reportados e a tarifa consultada, com data e moeda. Para latência, guarde observações individuais e calcule mediana e cauda com tamanho de amostra explícito. Sem API, deixe custo real como não medido e use apenas duração local do runner. A decisão deve citar requisitos críticos, diferença por categoria, divergências do juiz e limites da amostra. Anexe uma perda comentada com entrada, evidência, chamadas e resposta, para que um revisor entenda o bloqueio sem executar tudo novamente.
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.
Fonte diz 14 dias. A é fluente mas diz 40; B é curta e diz 14. Juiz escolhe A em posição 1 e B quando B é posição 1. Tool de A usa identidade errada; B não. Resolva preferência e gate.
Conferir raciocínio e critérios de domínio
B é sustentada pela fonte e A contém prazo inventado. A qualidade factual não se inverte com ordem ou estilo.
O juiz favoreceu posição 1 nos dois testes: a preferência é instável e exige calibração/revisão, não uma nota tratada como verdade.
A também viola autorização e é bloqueada. B é melhor nestes casos; não há dados de latência/custo para inferir superioridade geral.
Evidências para autoavaliação ou revisão por pares
- Fundamentação: B é sustentada pela fonte e A contém prazo inventado. A qualidade factual não se inverte com ordem ou estilo.
- Viés de posição: O juiz favoreceu posição 1 nos dois testes: a preferência é instável e exige calibração/revisão, não uma nota tratada como verdade.
- Gate e alcance: A também viola autorização e é bloqueada. B é melhor nestes casos; não há dados de latência/custo para inferir superioridade geral.
Um erro frequente
Vitória textual prova task completion.
Preferência textual não substitui correção da tool e conclusão funcional.
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.