Eval Harness Primeiro

O portão da Fase 0 para todo o plugin: finetuning-method-selection e todas as habilidades downstream assumem que este harness existe antes que uma configuração de treinamento seja escrita. O harness não é um artefato do final da execução — é o motor de curadoria de dados. Os mesmos rastros rotulados que constroem os "goldens" alimentam os dados de treinamento, menos uma exclusão explícita.

Entrada: rastros de produção/agente, se existirem, ou uma especificação de tarefa, se não existirem, mais rotuladores dispostos a avaliar ≥100 exemplos. Formato de saída: o diretório eval/ abaixo — "goldens", avaliadores, suíte de drift e a linha de base do modelo base na qual as fases posteriores se baseiam.

O Portão

Sem harness de avaliação, sem fine-tune. Pular para uma configuração de treinamento e não há nada para medir, nada para capturar regressões e nenhum dado rotulado para treinar. O ciclo:

1. Coletar rastros — spans de produção/agente, ou tarefas sintéticas, se ainda não existirem.
2. Análise de erros — codificação aberta em ≥100 rastros, codificação axial em 4–8 categorias de falha.
3. Um avaliador por categoria — determinístico primeiro; LLM-judge calibrado apenas para critérios genuinamente subjetivos.
4. Priorizar por frequência × severidade × valor.
5. Os rastros rotulados alimentam a curadoria do conjunto de dados, menos uma exclusão explícita. Cada ID eval/goldens.jsonl permanece excluído dos dados de treinamento por ID.
6. Treinar.
7. Reexecutar o mesmo harness no checkpoint — não um diferente, mais flexível.
8. A detecção de drift retorna à etapa 2 — novos modos de falha de produção reabrem a análise de erros.

As etapas 2–4 constroem o harness; as etapas 5–8 são o motivo pelo qual ele deve existir primeiro — ele é tanto a fonte de dados de treinamento quanto o portão de saída do checkpoint.

Construindo "Goldens"

• A partir de rastros, quando eles existem: executar análise de erros — codificação aberta em ≥100 rastros reais (lê-los, marcar falhas com suas próprias palavras, sem taxonomia fixa ainda), depois codificação axial para agrupar essas marcas em 4–8 categorias de falha nomeadas. Menos de 4 significa que a passagem de codificação foi muito superficial; mais de 8 significa que as categorias precisam ser mescladas. Exceção: tarefas de superfície de falha única (por exemplo, extração de esquema estrito) podem resultar em 1–2 categorias com sub-métricas por campo dentro de um avaliador — não invente divisões artificiais sem evidências por trás delas.
• Sintético, quando os rastros ainda não existem: geração baseada em dimensão — enumerar os eixos que importam (tipo de tarefa, dificuldade, caso extremo, persona) e amostrar o produto cruzado; prompts gerados livremente agrupam em torno do que for mais fácil de escrever.
• "Goldens" são versionados como código — commit eval/goldens.jsonl, diff em revisão, marcar por lançamento. Ele também serve como suíte de regressão CI.

Avaliadores

Um avaliador por categoria de falha da análise de erros — não um para todo o conjunto de avaliação. Uma única pontuação combinada esconde qual categoria regrediu.

• Determinístico primeiro. Regex, validação de esquema ou verificações de execução são mais baratas, reproduzíveis e não precisam de calibração.
• **LLM-judge apenas para critérios genuinamente subjetivos ** — tom, fidelidade, "qual resposta é melhor" — onde nenhuma verificação determinística pode expressá-lo.
• Passar/falhar binário em vez de Likert. Uma escala de 1–5 ou 1–10 é mais ruidosa para calibrar e mais difícil de aplicar consistentemente; agrupar em passar/falhar.
• Pontuação estilo MMLU da suíte de drift: preferir logprob em vez de gerar e extrair — um orçamento de token apertado torna a geração e extração frágil para análise em modelos que preambulam, confundindo a conformidade do formato com o conhecimento que está sendo medido. Modelos para todas as quatro formas de avaliador e esta nota de pontuação: references/grader-templates.md.

Calibração do Judge é um Pré-requisito

Qualquer categoria roteada para um LLM-judge precisa de calibração antes que seus vereditos contem para algo além da exploração — um pré-requisito rigoroso, não um "bom ter". N/A quando nenhuma categoria é roteada para um judge — um harness totalmente determinístico não tem nada para calibrar; declare isso em vez de deixar esta seção sem resposta.

• Rotule ≥100 itens, divididos em treino/dev/teste selado (relatar uma vez, sem retoques depois).
• Relatar TPR e TNR, não um único número de acurácia combinado — um judge pode atingir 90% dizendo sempre "passar" em um conjunto enviesado.
• Fixar o judge em um snapshot de modelo fixo e recalibrar em caso de mudança de judge-modelo, trimestralmente, independentemente.
• O judge deve vir de uma família de modelos diferente da do modelo em teste.
• Um judge que não atinge a barra acordada de TPR/TNR é enviado apenas consultivo — flags para revisão humana, nunca bloqueia uma promoção. Protocolo completo, correção de viés,

…