Convertendo para Dados de Treinamento

Esta habilidade assume que eval-harness-first já avaliou os traces que estão sendo convertidos aqui — goldens, graders e runs/<run-id>/results.json existem antes do início da conversão. Esta é a vantagem do ciclo que a habilidade nomeia em seu próprio fluxo: "os mesmos traces rotulados se tornam o conjunto de treinamento." A conversão acontece aqui; a avaliação já ocorreu a montante.

Entrada: traces avaliados — eval/goldens.jsonl mais runs/<run-id>/results.json, cada linha carregando um task_id, uma verdict do avaliador e um reward quando a tarefa suporta uma pontuação escalar (pontuação do juiz, crédito parcial de execução ou um verificador RLVR):

{"task_id": "t-042", "trace_id": "t-042-a3",
 "messages": [{"role": "user", "content": "..."}],
 "verdict": "pass", "reward": 0.91,
 "grader": "exact_match"}

Formato de saída: linhas com formato exatamente igual à tabela de Seleção de Formato de dataset-curation — linhas de messages SFT ou pares de prompt/chosen/rejected DPO — para que a saída desta habilidade seja a entrada dessa habilidade sem nenhuma etapa de reformatação entre elas.

O Princípio

O harness de avaliação já fez o trabalho de rotulagem: cada trace em results.json carrega um veredito, e frequentemente uma recompensa, antes que esta habilidade o toque. Converter um trace avaliado em uma linha de treinamento é mecânico — escolher um formato da tabela de dataset-curation, mapear campos, escrever JSONL. A curadoria é o trabalho que resta — quais traces atingem uma barra de qualidade, quais pares são informativos e quais linhas nunca devem entrar no conjunto de treinamento.

Trate qualquer etapa de conversão que exija reavaliação de um trace como um sinal de que o harness está faltando um avaliador, não uma lacuna que esta habilidade deva cobrir. Um trace sem veredito ou recompensa ainda não é conversível — encaminhe-o de volta para eval-harness-first primeiro, não o rotule manualmente aqui para desbloquear a conversão.

SFT a partir de Traces

• Mantenha a fração de maior recompensa de trajetórias bem-sucedidas, não todas as que passaram. Classifique os traces que passaram por recompensa e pegue uma fração (o padrão Agente-relâmpago) em vez de cada trace que apenas atingiu a barra de aprovação — um trace que mal passou é um sinal SFT mais fraco do que um que pontuou bem acima do limite.
• Falhas corrigidas por especialistas se tornam exemplos SFT ouro diretamente (o padrão Langfuse) — quando um humano edita a saída de um trace falho em uma correta, essa correção não precisa de limite de recompensa; um humano já a validou. Encaminhe as correções diretamente para o conjunto SFT.
• Mascaramento em nível de passo supera a exclusão de trajetória inteira para traces de múltiplos passos. Quando apenas alguns passos em uma trajetória de múltiplos passos estão ruins, mascare a perda nos passos ruins e mantenha os bons, em vez de descartar a trajetória inteira. SRFT relata 32,2% contra 30,9% no SWE-bench para mascaramento de crítico em nível de passo sobre exclusão de trajetória — uma diferença real, embora modesta, do corte mais granular.

Pares de Preferência a partir de Traces

• Construa pares a partir de trajetórias que passaram versus as que falharam na MESMA tarefa, nunca a partir de traces de melhor e pior pontuação não relacionados retirados de tarefas diferentes — pares entre tarefas ensinam o modelo a preferir uma tarefa em vez de outra, não uma resposta em vez de outra.
• Selecione o membro rejeitado em μ−2σ da distribuição de recompensa para essa tarefa, nunca o mínimo absoluto. A seção Construção de Pares de preference-optimization contém a fórmula de seleção completa; esta habilidade fornece os traces avaliados que ela consome.
• Seleção por delta de juiz pontuado reduz o volume de pares sem reduzir o sinal. Pontue cada par candidato pelo delta do juiz escolhido menos rejeitado e mantenha apenas o subconjunto de maior delta — os top 5k de um pool de 16,5k candidatos corresponderam ao resultado downstream do pool completo. Construa o conjunto completo de candidatos primeiro, depois filtre por delta; não limite a geração em 5k antecipadamente.

Higiene

• Verifique segredos e PII antes que qualquer linha seja enviada, e redaque o que for encontrado. Traces originados de logs de produção podem conter credenciais, chaves de API, tokens ou dados de clientes — execute uma verificação de segredo/PII em cada linha SFT e DPO e redaque as correspondências; a conversão falha fechada (a linha é descartada, não enviada com o conteúdo bruto) se campos sensíveis permanecerem após a redação. Nunca cometa segredos.
• Goldens de avaliação nunca devem vazar para dados de treinamento. Mantenha cada ID de eval/goldens.jsonl fora de cada conjunto SFT e DPO convertido — um trace que também aparece como um golden é treinado no item exato contra o qual o checkpoint será avaliado posteriormente,

…