Evals I

Um golden dataset reúne entradas e expectativas revisadas para uma tarefa definida. O adjetivo golden não transforma a resposta de referência em verdade eterna: a política comercial pode mudar, uma pergunta pode ter várias respostas corretas e uma anotação humana pode conter erro. Por isso cada caso precisa de identificação, origem, versão da política e justificativa da expectativa. Considere uma loja cujo prazo de devolução é 14 dias: o caso deve fornecer esse documento, e não exigir que o modelo adivinhe uma regra ausente. A unidade avaliada inclui a pergunta, o contexto autorizado e os resultados disponíveis das ferramentas. Sem esses elementos, uma execução posterior não é comparável.

↗ Evaluation best practices

A cobertura deve representar o uso pretendido e também situações em que falhar é caro. Uma proposta de 50 casos é reservar 20 para dúvidas comuns, 10 para ambiguidades, 10 para ausência de evidência e 10 para limites de autorização. Essa distribuição é uma escolha de laboratório, não uma recomendação universal. Registre separadamente a categoria de cada caso: uma média alta pode ocultar vazamento de dados em uma fatia pequena.

↗ Evaluation best practices

Um test case descreve uma situação e uma condição observável de aprovação. “Responder bem” é amplo demais; “informar o prazo de 14 dias, citar a política v3 e não afirmar que a compra é elegível sem consultar a data” permite revisão. Separe requisitos obrigatórios de preferências estilísticas. Um erro de autorização pode bloquear o caso inteiro, enquanto uma frase longa pode apenas reduzir a nota de clareza. Essa separação impede que um texto elegante compense um comportamento inseguro. Também declare os dados que o avaliador conhece: julgar a resposta sem o documento usado pelo agente cria falsos positivos de alucinação.

↗ Evaluation best practices

Casos de borda revelam a semântica do contrato. No último dia do prazo, a regra considera a hora ou apenas a data? Uma ferramenta que retorna null significa inexistência, indisponibilidade ou acesso negado? Antes de testar o modelo, resolva essas ambiguidades com o responsável pelo produto. Um caso com expectativa contraditória testa a confusão do avaliador, não a capacidade do agente.

↗ Evaluation best practices

Exact match compara um resultado com uma representação esperada. É adequado para IDs, rótulos fechados e campos com normalização definida. Se a saída deve ser {action:"escalate"}, aceitar outro valor muda o comportamento do sistema. Para texto livre, entretanto, “prazo de quatorze dias” pode equivaler a “14 dias” sem igualdade literal. O semantic match busca proximidade de significado, mas proximidade não prova consistência com a fonte: “14 dias” e “40 dias” podem compartilhar muitas palavras. Em uma resposta operacional, números, nomes e permissões merecem verificadores específicos além da análise semântica.

↗ Graders

Normalize somente o que não altera o contrato. Remover espaços externos de um rótulo pode ser aceitável; remover negações ou arredondar valores financeiros não é. Para respostas estruturadas, primeiro valide o esquema e depois os campos críticos. Para a parte textual, use rubrica com evidências. Um avaliador híbrido deixa explícito que formato, fatos e utilidade são dimensões diferentes, evitando interpretar similaridade como uma autorização para executar ferramentas.

↗ Graders

Uma rubrica especifica critérios e exemplos de desempenho. Para fundamentação, use três níveis: zero quando existe afirmação contrária à fonte; um quando a resposta é compatível, mas não mostra suporte suficiente; dois quando as afirmações relevantes são sustentadas pelas evidências fornecidas. Acrescente um exemplo para cada nível e uma regra para “não aplicável”. Sem essa regra, dois revisores podem penalizar uma recusa correta por ausência de citação, mesmo quando nenhum documento estava disponível. A rubrica deve olhar para o produto e não para a preferência pessoal do autor.

↗ Evaluation best practices

Teste a rubrica em uma rodada pequena de dupla anotação. Se duas pessoas discordam frequentemente, examine as justificativas antes de tirar média das notas. Pode faltar uma definição de sucesso ou haver casos com contexto insuficiente. Não apague divergências difíceis para aumentar a concordância: elas mostram onde a especificação precisa amadurecer. Uma revisão da rubrica exige versão nova, porque altera o significado do score e a comparação histórica.

↗ Evaluation best practices

Uma avaliação de regressão executa casos preservados sobre uma versão nova e uma baseline. Compare por caso, não apenas por média. Se a versão B acerta uma pergunta comum e erra um caso crítico que A resolvia, a taxa agregada pode permanecer igual e esconder uma regressão importante. Guarde o identificador do caso, as duas respostas, a decisão do avaliador e a categoria do erro. O histórico permite investigar se a causa foi prompt, recuperação de documentos, ferramenta ou mudança de política.

↗ Evaluation best practices

Separe um conjunto de desenvolvimento, que pode orientar ajustes, e um conjunto de avaliação, usado para decisões de publicação. Ver repetidamente os erros do teste e adaptar o prompt a eles transforma o teste em desenvolvimento. Quando uma falha de produção vira um novo caso, registre sua incorporação e preserve um conjunto independente. Cinquenta casos são uma boa entrega pedagógica, mas não demonstram cobertura completa nem estimativas precisas para todos os segmentos. Repita execuções quando a variabilidade do modelo for relevante e apresente a dispersão.

↗ Evaluation best practices

Salve o exemplo como eval.cjs e execute node eval.cjs com Node instalado. Ele verifica rótulos fechados; as saídas são fixtures, não respostas obtidas de um provedor. A função normaliza espaços e caixa somente porque o contrato declarou essas variações equivalentes. Uma referência crítica separa erro operacional de mera variação textual.

A saída prevista mostra dois acertos em três casos e releaseAllowed igual a false. Isso ilustra por que o gate de publicação pode considerar criticidade além da taxa de aprovação. O código não avalia se o agente citou a fonte correta nem se o texto inventou fatos: esses verificadores devem ser adicionados ao contrato. Uma taxa de dois terços nesta amostra de três casos não é estimativa confiável de desempenho em produção.