DPO: pulando o reward model

01 · Conceito

Conceito

A lição 6.5 deixou você segurando quatro modelos ao mesmo tempo e uma policy de 27B de parâmetros cujo estado de otimizador sozinho chega a centenas de gigabytes. A maioria dos times não consegue rodar isso, e muitos não precisam. A Direct Preference Optimization (DPO) parte de uma relação matemática entre uma policy ótima regularizada por KL e sua recompensa, e então a rearranja para que a policy possa ser treinada diretamente em pares de preferência — sem reward model, sem workers de rollout, sem cabeça de valor. O que sobra é um forward pass e uma loss.

Cada exemplo ainda contém um prompt $x$, uma resposta preferida $y^{+}$ e uma resposta rejeitada $y^{-}$. A DPO usa uma policy treinável $\pi_\theta$ e uma referência congelada $\pi_{ref}$, soma as log-probabilidades dos tokens de cada resposta condicionada ao prompt, e compara quanto a policy favorece cada resposta a mais do que a referência já favorecia:

Agora torne isso concreto no modelo deste curso. Você quer adaptar o estilo do instruct mode do Qwen3.8-27B para um produto de suporte, e tem 8.000 pares de preferência. Montar o treino significa responder a quatro perguntas, nesta ordem.

Primeira: de onde vem o modelo de referência? Carregar ingenuamente dois checkpoints de 27B em bf16 não é um plano para uma placa. Combine DPO com LoRA da lição 6.3: treine adapters sobre um backbone de poucos bits e obtenha a log-probability de referência rodando o mesmo backbone com os adapters desativados. Isso remove a segunda cópia dos pesos, mas não prova encaixe numa GPU fixa; ativações, metadados de quantization, comprimento da sequência, micro-batch e buffers do backend ainda determinam a residência.

Segunda: que modo você está treinando? O Qwen3.8-27B vem com thinking mode ligado por padrão e instruct mode atrás de enable_thinking em False, e os dois renderizam a mesma conversa em sequências de tokens diferentes. Log-probabilidades são calculadas sobre tokens, então um par coletado num modo e pontuado no outro não é meramente ruidoso — é outro objetivo. Escolha um modo, renderize tanto a resposta escolhida quanto a rejeitada por aquele exato ramo do template, e registre qual ramo o dataset usou.

Terceira: quais tokens entram na soma? Se você está treinando thinking mode e sua resposta escolhida carrega um traço de raciocínio de 900 tokens enquanto a rejeitada carrega 200, a diferença de log-probabilidade somada é dominada pelo comprimento do traço antes de a qualidade ter voz. Ou mascare o segmento de thinking da loss e pontue só a resposta final, ou controle deliberadamente o comprimento dos seus pares. Não deixe isso ao acaso.

Quarta: como os candidatos foram amostrados? Registre a configuração completa. Para reproduzir as recomendações do model card, thinking usa temperature 1.0, top_p 0.95, top_k 20, min_p 0.0, presence_penalty 0.0 e repetition_penalty 1.0; instruct usa 0.7, 0.80, 20, 0.0, 1.5 e 1.0. O operador do deployment pode escolher outros valores, então amostras fora da recomendação não são intrinsecamente inválidas nem respostas que usuários jamais verão. O que importa é a distribuição de candidatos cobrir o comportamento que você pretende implantar e essa escolha ficar registrada.

Então passe um exemplo pela aritmética. Tome $\beta = 0.1$. Suponha que a resposta escolhida pontue $-42.0$ sob a policy e $-45.0$ sob a referência, um ganho relativo de $+3.0$; e que a rejeitada pontue $-50.0$ sob a policy e $-48.0$ sob a referência, uma perda relativa de $-2.0$. Então $m = 0.1 \times (3.0 - (-2.0)) = 0.5$, e a loss é $-\log\sigma(0.5)\approx 0.47$. Repare no que moveu o número: não quão provável cada resposta é, mas quanto a verossimilhança de cada uma se deslocou em relação à referência.

Essa distinção prepara o desvio clássico. Times logam a log-probabilidade bruta das respostas escolhidas sob a policy, veem-na cair durante o treino, e concluem que o treino está quebrado — o modelo está ficando pior em produzir as respostas que dissemos preferir. Olhe as duas séries e o pânico se dissolve. É perfeitamente normal a log-probabilidade da escolhida escorregar de $-42$ para $-44$ enquanto a da rejeitada desaba de $-50$ para $-60$: a margem passou de 8 para 16, que é exatamente o que o objetivo otimiza. A DPO nunca prometeu elevar a verossimilhança absoluta da resposta escolhida. Ela prometeu tornar a resposta escolhida mais característica da nova policy do que a rejeitada é. Se você quer um piso de verossimilhança absoluta, precisa também de um termo supervisionado — que é precisamente o projeto que o ORPO adota, na lição 6.7. O que você deveria acompanhar é a margem, a acurácia pareada, o comprimento médio das respostas e a divergência tipo KL em relação à referência; quando a log-probabilidade da escolhida despenca e o comprimento desaba junto, aí sim o treino está degenerando.

Remover o reward model não remove as preferências, e toda fraqueza que a lição 6.4 catalogou sobrevive intacta: discordância entre anotadores, viés de comprimento, cobertura rala de prompts, policies de candidatos desatualizadas, exemplos mal rotulados. A DPO também pode punir uma resposta rejeitada que continha material útil, porque o rótulo se aplica à sequência inteira e nunca identifica o trecho que falhou. E como a DPO padrão é offline, ela não coleta julgamentos novos conforme a policy se move; se o treino empurra o modelo para comportamento que o dataset nunca cobriu, não existe feedback nenhum lá. Variantes iterativas regeneram candidatos e coletam pares novos, o que restaura um laço de produção de dados mesmo evitando a maquinaria do PPO.

Os detalhes mecânicos merecem o mesmo cuidado que a matemática. O padding precisa ser mascarado. Os tokens de prompt precisam ser excluídos de forma consistente dos dois lados. O truncamento nunca pode apagar a evidência que determinou o rótulo — uma resposta rejeitada cortada antes do seu erro é uma resposta rejeitada sem motivo visível para ter sido rejeitada. E as convenções de $\beta$ diferem entre bibliotecas, então um valor copiado da config de outra pessoa pode significar outra coisa na sua.

O modelo durável é modelagem pareada de policy. A DPO torna a resposta desejada mais característica da nova policy em relação a uma linha de base fixa, e a resposta rejeitada menos. Ela troca um jurado escalar aprendido e um otimizador online por uma loss offline elegante — enquanto os julgamentos humanos, a escolha da referência, o ramo do template e a avaliação continuam sendo a especificação de verdade.