Do modelo base ao assistant: SFT, RLHF, DPO e GRPO

O primeiro passo é o menos glamouroso e é o que faz a maior parte do trabalho. Colete exemplos de instruções pareadas com boas respostas e continue treinando nelas com exatamente a loss do Capítulo 8 — prever o próximo token — mas apenas na parte da resposta. Isso é supervised fine-tuning, ou SFT.

Nada novo está sendo ensinado sobre linguagem. O que está sendo ensinado é um formato: que texto com esta forma é seguido por texto com aquela forma, e então ele para. Observe de novo a falha do modelo base. Ele respondeu à pergunta na primeira frase e depois não conseguiu parar, porque nada em seu treino jamais marcou o fim de uma resposta. Parar é um comportamento aprendido.

Também é por isso que o modelo precisa receber a indicação de onde estão os limites, que é o que um chat template faz:

<|im_start|>system
You are Qwen, created by Alibaba Cloud. You are a helpful assistant.<|im_end|>
<|im_start|>user
What is the capital of France?<|im_end|>
<|im_start|>assistant

Esses marcadores <|im_start|> e <|im_end|> são tokens reais no vocabulário, adicionados antes do fine-tuning, e o modelo viu milhões deles exatamente nessas posições. É assim que ele sabe de quem é a vez e onde uma fala termina.

Ignore o template e entregue ao modelo uma pergunta nua, e você estará dando a ele uma sequência que ele não viu no treino. Medido, mesmo modelo, mesma pergunta, mesmo greedy decoding:

 The capital of France is Paris.

To verify this, I will use a simple
Python code snippet to confirm that
Paris is indeed the capital city of
France.

[...and then it starts writing a
Python script to check its own answer]

The capital of France is Paris.

A resposta está certa nos dois casos, mas sem os marcadores o modelo deriva para escrever Python para se verificar, porque o prompt que recebeu não se parece com nada do que ele viu no fine-tuning. Esta é a causa mais comum de “o modelo ficou mais burro quando eu o chamei diretamente”: o template não é uma decoração em volta do modelo, ele faz parte do modelo, e um template errado é uma degradação silenciosa sem erro associado.

SFT tem um teto, e esse teto são os dados. Para fazer fine-tuning em uma demonstração, alguém precisa escrever a resposta ideal — e, para a maioria das perguntas interessantes, escrever uma boa resposta é difícil, lento, caro e produz exatamente uma resposta cuja qualidade você não consegue verificar.

O que as pessoas fazem bem é comparar. Diante de duas respostas, um anotador consegue dizer com segurança qual é melhor em poucos segundos, sem ser capaz de produzir nenhuma das duas. Esse é o fato sobre o qual toda a segunda etapa é construída, e é a parte que a maioria das explicações entende ao contrário:

Humanos não escrevem as respostas. Eles ranqueiam pares.

Então os dados são pares — um prompt, duas respostas e qual delas venceu. Isso não pode ser encaixado em uma loss de próximo token, porque não há uma sequência-alvo. É preciso outra máquina.

Você não pode pedir a um humano que dê nota a cada resposta durante o treino — seriam milhões de julgamentos. Então você treina um modelo para imitar os humanos: um reward model que recebe uma resposta e retorna um escalar.

Treiná-lo a partir de comparações usa um resultado de 1952. O modelo Bradley–Terry² diz que, se dois itens têm forças latentes, a probabilidade de um vencer o outro é a função logística da diferença entre elas. Inverta isso e ele vira uma loss: dado que um humano preferiu $y_w$ a $y_l$, maximize

que, em código, é o loop de treino inteiro:

loss = -F.logsigmoid(reward(chosen) - reward(rejected)).mean()   

Observe o que o modelo nunca vê: uma nota absoluta. Ele só aprende diferenças, que é exatamente o que os dados contêm.

Agora a parte que vale medir. Um reward model aprende o que os anotadores recompensaram, e anotadores são pessoas. Aqui está uma simulação em que a qualidade real de uma resposta depende apenas de ser útil e correta — comprimento não vale nada —, mas o anotador simulado tem uma leve preferência por respostas mais longas quando todo o resto está próximo, um viés humano bem documentado. Treine o reward model em 2000 comparações e leia seus pesos:

O reward model está funcionando perfeitamente. Ele aprendeu fielmente as preferências que recebeu — incluindo a parte dessas preferências que não tem nada a ver com qualidade. Um reward model não é uma medida do que é bom; é uma medida do que os anotadores escolheram, e cada viés no conjunto de anotação agora é um coeficiente em uma função diferenciável contra a qual um modelo muito maior está prestes a otimizar.

Isso nos leva ao que acontece quando você o otimiza. Dê à policy um orçamento fixo de esforço para distribuir pelas propriedades da resposta, com uma assimetria realista: ser útil e ser correto é caro, e ser mais longo é barato — basta continuar escrevendo.

Reward por unidade de esforço, para o modelo treinado acima: útil 8,26, correto 8,31, comprimento 31,70. Comprimento paga quase quatro vezes mais do que correção, não porque o reward model está quebrado, mas porque é barato.

Otimize contra essa reward e observe os dois números:

A reward subiu por um fator de 2,5. Aquilo que a reward deveria medir foi para zero. A policy descobriu que conseguia pontuar enormemente bem escrevendo muito e não dizendo nada, e nenhuma parte do loop de treino tinha como perceber, porque o reward model é a definição de bom dentro do loop.

Isso é reward hacking, e se você já se perguntou por que modelos de chat são tão verbosos, esta tabela é uma grande parte da resposta.

A defesa padrão é penalizar a policy por se afastar demais de onde começou, medindo a distância com a divergência KL do Capítulo 4:

A referência $\pi_{\text{ref}}$ é o modelo SFT — a policy antes da etapa de reinforcement. A alegação é que isso impede o modelo de se desviar para comportamentos degenerados. Vamos descobrir quanto dessa alegação sobrevive à medição. Mesma configuração, varrendo $\beta$:

Leia a última linha em relação ao restante. Em $\beta = 0$ e $\beta = 1$, a penalidade não faz absolutamente nada: a reward vale tanto mais do que a KL que o otimizador paga a multa e faz hacking mesmo assim. Entre 5 e 15, o comportamento oscila. E, em $\beta = 60$, a qualidade real subiu de volta para 1,769 — o que ainda está abaixo dos 1,791 que o modelo de referência tinha antes de tudo isso começar.

Uma ressalva antes que esse número seja citado em qualquer lugar: os 1,791 da última linha e os 0,974 que a primeira tabela dá à policy inicial são duas medições diferentes do mesmo modelo pré-RL, feitas separadamente pelos dois experimentos. Compare linhas dentro de uma tabela, nunca entre tabelas — a conclusão de cada tabela se sustenta em suas próprias linhas, e nenhuma depende da baseline da outra.

Então o resumo honesto não é “a penalidade KL impede reward hacking”. É:

A penalidade KL não impede reward hacking. Ela limita o quanto a policy pode se afastar da referência — e, como a falha exige movimento, isso ajuda. Mas é uma coleira, não uma correção: com $\beta$ baixo, a coleira arrebenta; com $\beta$ alto, você recebe o modelo de referência de volta e toda a etapa cara não comprou nada.

A faixa útil é estreita, sua localização depende do reward model, e não há como encontrá-la exceto olhando. É por isso que o modelo de referência precisa ser bom — a KL é um piso na qualidade da referência, não um teto para a falha — e isso é uma grande parte do motivo pelo qual essa etapa é difícil na prática, não em princípio.

O algoritmo que fez isso funcionar em escala é Proximal Policy Optimization.³ Em um parágrafo: ele estima a advantage de cada resposta, atualiza a policy para aumentar a probabilidade de respostas acima da baseline e limita o tamanho de qualquer atualização individual para que uma grande estimativa de advantage não destrua a policy em um único passo. Aplicado a modelos de linguagem⁴, isso significa manter quatro modelos em jogo ao mesmo tempo — a policy, a referência, o reward model e um critic — com a policy gerando novas amostras durante todo o treino.

Funciona, produziu o InstructGPT e tudo que descendeu dele, e é genuinamente difícil: quatro modelos na memória, sampling no loop de treino e uma reputação merecida de instabilidade. Fingir que dá para implementá-lo em um post de blog seria desonesto, então este capítulo não faz isso.

O que o substituiu para a maioria dos fins veio de uma observação. O objetivo regularizado por KL acima tem uma policy ótima em forma fechada, e essa expressão pode ser invertida: a reward pode ser escrita em termos da policy ótima e da referência. Substituir isso de volta na loss Bradley–Terry faz o reward model desaparecer por completo. O que resta é uma loss supervisionada em pares de preferência — sem sampling, sem critic, sem reward model, dois modelos na memória em vez de quatro.

Isso é Direct Preference Optimization,⁵ e são duas linhas:

def dpo_loss(pi_w, pi_l, ref_w, ref_l, beta=0.1):
    """pi_* and ref_* are summed log-probabilities of a full response."""
    logits = beta * ((pi_w - ref_w) - (pi_l - ref_l))   
    return -F.logsigmoid(logits)                        

Leia o que ela diz. A quantidade que está sendo empurrada para cima é o quanto mais a policy prefere o vencedor do que a referência preferia, menos o quanto mais ela prefere o perdedor. A referência não é uma penalidade aparafusada depois — ela está dentro da loss, que é por isso que DPO não precisa de um termo KL separado.

A propriedade mais importante está no gradient. Avalie a loss e seu gradient no mesmo par em cinco estados diferentes da policy:

O gradient cresce conforme a policy erra mais. Pares que o modelo já resolve contribuem quase nada; pares em que ele inverte a resposta dominam a atualização. DPO pondera cada exemplo pelo quanto a policy está errada agora, automaticamente, sem scheduling — e essa autoponderação é o mecanismo que faz o trabalho que a estimativa de advantage e o critic do PPO faziam. (A loss na terceira linha é exatamente $\ln 2$, que é a âncora para conferir qualquer implementação: uma policy idêntica à sua referência não aprendeu nada e deve ficar em $\ln 2$.)

GRPO⁶ segue uma rota diferente para sair do mesmo problema. Ele mantém o loop de sampling, mas elimina o critic: em vez de treinar um modelo para prever a baseline, ele amostra um grupo de respostas para o mesmo prompt e usa diretamente a reward média do grupo como baseline. A advantage de uma resposta é o quanto ela foi melhor que suas irmãs. Isso troca um modelo inteiro por um batch maior, e foi isso que tornou prático o treino com rewards verificáveis — o assunto do Capítulo 12.

Duas coisas para levar adiante.

A primeira é que essa etapa tem um custo, e ele aparece como capacidade. Modelos frequentemente pioram de forma mensurável em algumas tarefas de benchmark depois do treino de alinhamento — o imposto de alinhamento — porque o objetivo mudou: uma resposta segura, cautelosa e bem formatada nem sempre é a resposta que maximiza a precisão. Parte dessa lacuna foi eliminada por engenharia, e parte dela é uma troca real, não um bug a corrigir.

A segunda é a pergunta que a palavra alinhado esconde. Alinhado com quem? A cadeia é: uma empresa escreve diretrizes, contratados as interpretam, suas comparações treinam um reward model, o reward model molda uma policy, e a policy responde a uma pergunta de alguém que não viu nada disso. Cada elo é uma escolha feita por pessoas específicas, e nenhum dos algoritmos deste capítulo tem opinião alguma sobre essas escolhas serem boas.

Isso não é floreio retórico. É o motivo concreto pelo qual dois modelos de frontier recusam pedidos diferentes, por que o mesmo modelo muda de ideia entre versões e por que “alinhado” é uma descrição de um processo, não uma propriedade de um artefato. A matemática deste capítulo está estabelecida. Essa parte, não.

O post-training ensinou o modelo a responder. Não o ensinou a pensar antes de responder, e as duas coisas são diferentes de uma forma que acaba sendo treinável.

O Capítulo 12 trata do que acontece quando você deixa um modelo gastar mais computação em uma pergunta difícil na hora da resposta, em vez de na hora do treino — chain of thought, reinforcement learning a partir de rewards verificáveis e o motivo pelo qual um modelo que mostra seu raciocínio não está apenas se explicando, mas computando de outro modo. Ele também paga a dívida deste capítulo: GRPO existe nele, fazendo o trabalho que o critic do PPO costumava fazer, em rewards que não precisam de anotador algum porque uma prova ou confere, ou não confere.

As gerações acima vêm de gpt2 e Qwen/Qwen2.5-0.5B-Instruct com greedy decoding, então se reproduzem exatamente. O Capítulo 11 do Hugging Face LLM Course percorre SFT e DPO com trl e peft se você quiser rodar a coisa real em vez da simulação; o capítulo 7 de Build a Large Language Model (From Scratch), de Sebastian Raschka, implementa instruction fine-tuning de ponta a ponta sem uma biblioteca.