Supervised fine-tuning e dados de instrução

01 · Conceito

Conceito

Comece pelo artefato, antes da teoria. Quando você chama o Qwen3.8-27B, você não entrega uma string; entrega uma conversa, e um chat template transforma essa conversa numa única sequência plana de tokens. Os papéis são renderizados como tokens marcadores — system, user, assistant — em torno do seu texto. Por padrão o turno do assistente começa com um segmento delimitado de thinking antes da resposta propriamente dita. E o model card documenta uma chave no nível da requisição, enable_thinking em False, que suprime esse segmento. Tudo isso — os marcadores, o segmento, a chave — é saída de post-training. Nada disso existe num checkpoint pré-treinado, e nada disso é arquitetura. Esses marcadores de papel são ids de token comuns tirados do mesmo vocabulário de 248.320 linhas de onde vem todo outro token.

O supervised fine-tuning (SFT) é onde a maior parte desse protocolo é instalada. Ele pega um checkpoint pré-treinado e continua treinando-o em demonstrações do comportamento desejado: uma instrução de system, um pedido de user e uma resposta de assistant escrita ou aprovada por um humano. O objetivo não é reensinar gramática ou conhecimento de mundo. A lição 6.1 argumentou que a capacidade já está presente; o SFT torna o contrato conversacional, os padrões de saída e as fronteiras de tarefa estatisticamente familiares, de modo que o comportamento certo vire o padrão sem nenhuma demonstração no contexto.

A loss é a mesma cross-entropy no nível do token usada no pretraining causal, com uma modificação que carrega quase todo o peso. Dados os tokens da conversa $x_1,\ldots,x_T$,

onde $A$ denota as posições da resposta do assistente. Os tokens de system e user permanecem no contexto de entrada — o modelo precisa prestar attention neles — mas sua loss é mascarada.

Percorra um registro pela aritmética, porque é no mascaramento que as implementações erram em silêncio. Suponha que a conversa renderizada tokenize em 460 posições: 18 tokens marcadores de template, 96 tokens de system, 226 tokens de user e 120 tokens de assistant. O forward pass roda sobre as 460. O backward pass soma log-probabilidades sobre 120 delas. Todo gradiente que o otimizador vê responde, portanto, a uma única pergunta — dado tudo o que veio antes, este era o próximo token certo da resposta do assistente? — e nunca à pergunta do que o usuário deveria ter perguntado. Se a conversa tem três turnos de assistente, a máscara acompanha as fronteiras de papel e cobre os três, não apenas o sufixo final.

Agora o desvio clássico: treinar nas 460 posições sem máscara, com a teoria de que mais tokens supervisionados devem significar mais aprendizado. Treina bem. A loss cai. Aí o modelo em produção termina a resposta e alegremente escreve a próxima pergunta do usuário, porque você gastou 340 de cada 460 sinais de gradiente ensinando-o a ser um bom previsor de turnos de usuário e de marcadores de template. A correção não é mais dados, é a máscara. Cerca de três quartos dos tokens de um registro típico de instrução são contexto para condicionar, não comportamento para imitar.

Um exemplo de instrução ensina muito mais que sua resposta literal. Ele demonstra como ler um pedido, quais suposições explicitar, que formato usar, quando fazer uma pergunta de esclarecimento e — criticamente — quando parar. Um exemplo de segurança ensina uma recusa delimitada seguida de uma alternativa benigna. Um exemplo de uso de ferramenta ensina uma chamada estruturada em vez de prosa. Para um modelo como o Qwen3.8-27B, que entrega dois modos num único conjunto de pesos, as demonstrações precisam cobrir os dois ramos: conversas que contêm um segmento de thinking e conversas que não contêm, para que a chave de fato selecione um comportamento bem ensaiado em vez de empurrar o modelo para fora da sua distribuição de treino.

Qualidade de dados é, portanto, o problema central de projeto, e não é um problema de volume. Milhares de templates quase duplicados criam a ilusão de escala enquanto ensinam um padrão de superfície frágil. Demonstrações prolixas tornam o modelo prolixo mesmo quando os usuários pedem concisão. Respostas com citações inventadas recompensam invenção. Rótulos contraditórios ensinam fronteiras instáveis. A filtragem precisa inspecionar prompts além de respostas, porque uma resposta limpa pareada com uma instrução ambígua ainda ensina o mapeamento errado. O projeto da mistura importa pelo mesmo motivo: se a maioria dos exemplos são tarefas fáceis de reescrita, o modelo fica agradável sem ficar melhor em raciocínio nem em compor várias instruções. Separe conjuntos de avaliação por família de tarefa e por fonte, já que um split aleatório de registros duplicados vaza entre treino e teste.

O SFT também arrisca catastrophic forgetting quando as learning rates ficam altas, o treino roda por muito tempo ou os dados são homogêneos demais. O checkpoint escorrega na direção da distribuição supervisionada e perde massa de probabilidade sobre comportamento pré-treinado útil. Otimização conservadora, misturas amplas e avaliação contra as capacidades base expõem o trade-off. Métodos parameter-efficient (lição 6.3) reduzem quais pesos se movem, mas não salvam supervisão ruim.

Por fim, SFT não é aprendizado de preferência. Uma única resposta-alvo diz “imite isto” sem dizer como ela se compara a alternativas plausíveis, então a imitação no nível do token penaliza demais diferenças inofensivas de redação sempre que várias respostas teriam servido. Métodos de preferência ensinam ordenação relativa, e normalmente rodam depois que o SFT estabeleceu uma política de conversa estável. Um pipeline sólido registra a linhagem do dataset, o chat template, o tokenizer, a política de mascaramento, os pesos da mistura, a configuração do otimizador e a ancestralidade do checkpoint — porque quando o comportamento regredir seis semanas depois, exatamente um desses mudou.