RL para LLMs

Aprendizado por reforço (reinforcement learning, RL) aparece no treinamento moderno de modelos de linguagem principalmente como uma forma de alinhar o comportamento de um modelo pré-treinado (pretrained) com preferências humanas, diretrizes de segurança e sinais de sucesso de tarefa que não são bem capturados apenas pela previsão do próximo token (next-token prediction). O exemplo mais conhecido é RLHF (aprendizado por reforço a partir de feedback humano, Reinforcement Learning from Human Feedback), popularizado por sistemas como InstructGPT e ChatGPT.

Este artigo explica o pipeline central de RLHF, como a geração de texto pode ser enquadrada como um problema de RL, quais algoritmos são usados na prática (especialmente a Otimização Proximal de Políticas (Proximal Policy Optimization, PPO)) e o que pode dar errado quando você otimiza um modelo de linguagem contra uma recompensa aprendida.

Por que Aprendizado por Reforço para LLMs?

Um modelo de linguagem grande (large language model, LLM) pré-treinado geralmente é treinado com um objetivo auto-supervisionado (self-supervised): prever o próximo token. Isso produz um modelo amplamente capaz, mas não garante que o modelo irá:

  • seguir instruções de forma confiável
  • recusar solicitações inseguras
  • ser verdadeiro em vez de meramente plausível
  • ser conciso em vez de prolixo
  • corresponder a noções humanas de estilo e tom “úteis”

Muitos desses requisitos são difíceis de especificar como alvos supervisionados diferenciáveis. RL ajuda porque pode otimizar uma política (policy) contra um sinal de recompensa (reward signal) que pode vir de:

  • humanos ranqueando saídas do modelo (preferências)
  • um modelo de recompensa (reward model) treinado nesses rankings
  • avaliadores automáticos (testes unitários (unit tests), compiladores (compilers), verificadores de estilo (style checkers))
  • resultados de ferramentas/agentes (tools/agents) (o agente de navegação na web concluiu a tarefa?)

RL é, portanto, um mecanismo de moldagem de comportamento (behavior shaping): “aumente comportamentos que pontuam bem sob essa recompensa, diminua os que não pontuam”, enquanto tenta não destruir a competência geral de linguagem do modelo.

Conceitualmente, RLHF se conecta diretamente a ideias padrão de RL—políticas, trajetórias (trajectories), maximização de recompensa e gradientes de política (policy gradients)—cobertas em Conceitos de Aprendizado por Reforço e Métodos de Aprendizado por Reforço.

Da modelagem de linguagem ao alinhamento

Pré-treinamento e ajuste por instruções

A maioria dos LLMs em produção passa por etapas:

  1. Pré-treinamento (pretraining) (previsão auto-supervisionada do próximo token)
    Produz um modelo de uso geral com amplo conhecimento e capacidade linguística. Veja Arquitetura Transformer.

  2. Ajuste fino supervisionado (supervised fine-tuning, SFT) em dados de seguimento de instruções
    Treina o modelo para imitar respostas “boas” escritas por humanos (ou por modelos fortes). Isso frequentemente melhora de forma dramática a aderência a instruções.

  3. Otimização por preferências (preference optimization) (frequentemente RLHF)
    Usa comparações como “Resposta A é melhor do que Resposta B” para mover o modelo em direção ao que os usuários preferem, especialmente nos eixos de segurança e utilidade.

SFT sozinho é aprendizado por imitação (imitation learning): ele reproduz a distribuição das demonstrações. A otimização no estilo de RL vai além: ela pode melhorar além das demonstrações de acordo com a recompensa, mas isso também introduz novos modos de falha (exploração da recompensa (reward hacking), deriva (drift), superotimização (over-optimization)).

O problema de alinhamento e aprendizado de preferências

Muitos objetivos de alinhamento são subjetivos ou dependem de contexto. Em vez de escrever uma função de recompensa codificada à mão (“+1 por utilidade”), RLHF geralmente aprende uma função de recompensa a partir de preferências:

  • Mostre a um humano um prompt (prompt) e duas respostas do modelo.
  • Pergunte qual resposta é melhor (às vezes com razões ou rubrica).
  • Treine um modelo de recompensa para atribuir pontuações maiores a respostas preferidas.

Este é um caminho prático para capturar conceitos vagos como “educado”, “seguro”, “no tema” ou “não evasivo, mas cauteloso”.

Pipeline de RLHF (abordagem clássica)

A pilha “clássica” de RLHF tem três etapas principais.

Etapa 1: Coletar demonstrações e treinar uma política SFT

Você começa a partir de um modelo pré-treinado e faz ajuste fino nele com demonstrações (prompt → resposta ideal). O resultado é sua política inicial, frequentemente chamada de:

  • π_sft (modelo SFT)

Essa política já é utilizável e atua como um forte prior para a etapa de RL.

Etapa 2: Treinar um modelo de recompensa a partir de comparações

Você coleta dados de preferência:

  • prompt x
  • duas respostas candidatas y_a, y_b
  • rótulo: qual é a preferida

Então treina um modelo de recompensa r_φ(x, y) que pontua pares (prompt, resposta).

Uma perda comum é a perda de preferência Bradley–Terry / logística:

Given preferred y_w (winner) and y_l (loser):

P(y_w ≻ y_l | x) = σ(rφ(x, y_w) - rφ(x, y_l))

Loss = -log σ(rφ(x, y_w) - rφ(x, y_l))

Na prática, o modelo de recompensa muitas vezes é implementado como um transformer com uma “cabeça de recompensa” escalar (reward head) no topo, treinado de modo semelhante a um classificador/regressor.

Detalhes práticos importantes:

  • Dados de preferência são caros; controle de qualidade e calibração de anotadores importam.
  • Modelos de recompensa podem sofrer overfitting; conjuntos de validação (holdout sets) e prompts adversariais ajudam.
  • Modelos de recompensa são vulneráveis à exploração se otimizados agressivamente demais.

Etapa 3: Otimizar a política com RL (frequentemente PPO)

Agora você trata o LLM como uma política π_θ que gera respostas e recebe recompensa de r_φ. Você otimiza π_θ para aumentar a recompensa esperada enquanto permanece próximo de uma política de referência (geralmente o modelo SFT) via uma penalidade de divergência de Kullback–Leibler (Kullback–Leibler divergence, KL).

O algoritmo mais comum historicamente é PPO (Otimização Proximal de Políticas (Proximal Policy Optimization, PPO)), um método de gradiente de política na política (on-policy) (veja Métodos de Gradiente de Política e Métodos Ator-Crítico).

Um objetivo simplificado de RLHF se parece com:

Maximize  E_{y ~ πθ(·|x)} [ rφ(x, y) - β * KL(πθ(·|x) || πref(·|x)) ]

Onde:

  • π_ref geralmente é o modelo SFT congelado (ou um snapshot)
  • β controla quão fortemente você penaliza o afastamento

O que o PPO está fazendo aqui (intuitivamente)

  • Amostrar respostas a partir da política atual.
  • Pontuá-las com o modelo de recompensa.
  • Calcular uma vantagem (advantage) (o quanto melhor do que o esperado).
  • Atualizar a política para tornar tokens de alta recompensa mais prováveis e tokens de baixa recompensa menos prováveis.
  • Usar recorte (clipping) / restrições no estilo de região de confiança (trust region) para evitar atualizações desestabilizadoras.

Um loop de treinamento altamente simplificado se parece com:

for batch in prompts:
    # 1) Rollout: sample from current policy
    responses, logp = policy.sample_with_logprobs(prompts)

    # 2) Score: reward model + KL penalty against reference
    rm_score = reward_model(prompts, responses)           # scalar per sequence
    kl = (logp - ref_policy.logprob(prompts, responses))  # per-token or per-seq
    reward = rm_score - beta * kl.sum(dim="tokens")

    # 3) Learn a value baseline (critic) and compute advantages
    values = value_head(prompts, responses)
    adv = compute_gae(reward, values)

    # 4) PPO update on policy parameters using clipped objective
    ppo_update(policy, logp, adv)
    value_update(value_head, reward)

Implementações reais incluem detalhes como:

  • moldagem de KL por token (per-token) (não apenas em nível de sequência)
  • branqueamento de vantagem (advantage whitening) / normalização de recompensa
  • mascaramento para saídas de comprimento variável
  • batching cuidadoso e treinamento distribuído

Enquadrando a geração de LLM como um problema de RL

Mesmo que a geração de texto não pareça um robô se movendo em um mundo, ela mapeia de forma limpa para RL:

Estados, ações e episódios

  • Estado: o prompt atual mais os tokens já gerados (a janela de contexto (context window)).
  • Ação: o próximo token a gerar.
  • Política: a distribuição do LLM sobre os próximos tokens.
  • Episódio / trajetória: uma conclusão completa gerada (ou um diálogo multi-turno).
  • Recompensa: frequentemente dada ao fim da conclusão por um modelo de recompensa, às vezes moldada ao longo dos tokens.

Este é um grande espaço de ação (tamanho do vocabulário) e um horizonte longo (muitos tokens), o que torna a redução de variância (baselines de valor, Estimativa Generalizada de Vantagem (Generalized Advantage Estimation, GAE)) importante.

Atribuição de crédito

Se a recompensa só é dada ao final (por exemplo, “pontuação de utilidade”), quais tokens merecem crédito? Métodos de gradiente de política lidam com isso usando retornos de Monte Carlo (Monte Carlo returns) e baselines, mas o treinamento pode ser ruidoso.

Sistemas práticos de RLHF frequentemente:

  • adicionam penalidades de KL por token (moldagem densa)
  • mantêm saídas relativamente curtas durante o treinamento
  • usam uma cabeça de valor (value head) para estabilizar estimativas de vantagem

Exemplo prático: alinhando um modelo de sumarização

Imagine um assistente de sumarização. O pré-treinamento ensina linguagem. O SFT ensina “resuma assim”. Mas usuários podem preferir sumários que sejam:

  • fiéis (sem alucinações (hallucinations))
  • concisos
  • cubram pontos-chave
  • com tom neutro

Você pode coletar preferências:

Prompt (artigo) → dois sumários → humano escolhe o melhor.

O modelo de recompensa pode aprender padrões como:

  • penalizar entidades inventadas
  • penalizar a ausência de alegações-chave
  • recompensar redação concisa

Então o RL otimiza a política em direção a essas preferências. Uma rubrica simplificada poderia ser incorporada em diretrizes de anotação; depois, essa rubrica é destilada implicitamente no modelo de recompensa.

Um modo de falha concreto: se o modelo de recompensa correlacionar erroneamente “inclui números e citações” com “alta qualidade”, a política pode começar a adicionar citações falsas. Isso é exploração da recompensa: o modelo encontra um atalho que aumenta a recompensa sem satisfazer a intenção real.

Mitigação: incluir exemplos de preferência adversariais, checagens de factualidade e avaliações em conjuntos de validação (holdout); limitar a força da otimização via KL.

Regularização por KL: por que ela é central no RLHF

Sem uma restrição, maximizar uma recompensa aprendida pode empurrar a política para regiões em que:

  • o modelo de recompensa é não confiável (fora da distribuição (out-of-distribution))
  • a qualidade da linguagem degrada
  • o modelo fica excessivamente “estilizado” para agradar a recompensa

A penalidade de KL:

  • atua como uma região de confiança em torno do modelo de referência
  • preserva capacidades gerais
  • reduz exploração da recompensa (embora não a elimine)

Em muitos sistemas, ajustar o coeficiente de KL β é um dos controles mais importantes:

  • muito pequeno → deriva e exploração
  • muito grande → nenhuma melhoria significativa sobre SFT

Além do RLHF “clássico”

RLAIF e juízes LLM

RLAIF (RL a partir de feedback de IA, RL from AI Feedback) substitui ou complementa humanos com um juiz de IA (frequentemente um LLM mais forte) que ranqueia saídas ou fornece pontuações escalares. Isso pode escalar o feedback drasticamente, mas introduz viés do juiz e potencial de pontos cegos sistemáticos.

Um padrão comum:

  • fazer bootstrap com algum feedback humano
  • usar feedback de IA para dados em larga escala
  • auditar periodicamente com humanos / equipes vermelhas (red teams)

Otimização de preferências “sem RL” (DPO e afins)

Abordagens recentes como Otimização Direta por Preferências (Direct Preference Optimization, DPO) otimizam a política diretamente a partir de dados de preferência sem um loop explícito de modelo de recompensa + PPO. Esses métodos frequentemente:

  • são mais simples de implementar
  • são mais estáveis do que PPO em muitos regimes
  • ainda dependem da qualidade e cobertura dos dados de preferência

Mesmo que você use treinamento no estilo DPO para muitas atualizações de alinhamento, RL continua valioso quando:

  • recompensas vêm de ambientes não diferenciáveis (sucesso com ferramentas, jogos, simuladores)
  • você precisa de melhoria online a partir de interação
  • você quer controle explícito sobre exploração e tomada de decisão sequencial

(Esses tópicos se conectam a Aprendizado por Reforço Offline e Exploração vs Aproveitamento.)

Uso de ferramentas e RL agêntico

À medida que LLMs se tornam “agentes” que chamam ferramentas (busca, execução de código, bancos de dados), RL se torna mais literal:

  • Estado: conversa + saídas de ferramentas
  • Ação: escolher uma ferramenta, argumentos, ou produzir texto
  • Recompensa: sucesso da tarefa (por exemplo, taxa de aprovação em testes), penalidades de latência/custo, restrições de segurança

Exemplos:

  • agentes de programação recompensados pela taxa de aprovação em testes unitários
  • agentes de navegação recompensados por encontrar informação correta
  • assistentes recompensados por concluir tarefas com sucesso respeitando regras de segurança

Esses cenários frequentemente envolvem horizontes mais longos e mais oportunidades para erros se acumularem, tornando técnicas de RL (atribuição de crédito, estimação de valor) mais relevantes.

Recompensas multiobjetivo e restrições

Alinhamento raramente é um único escalar. Você pode se importar com:

  • utilidade
  • inocuidade
  • honestidade
  • estilo / voz da marca
  • latência / verbosidade

Na prática, sistemas combinam sinais:

  • somas ponderadas de recompensas
  • filtros baseados em regras mais recompensas aprendidas
  • otimização com restrições (por exemplo, recusar conteúdo proibido)

Equilibrar esses objetivos é tanto trabalho de produto/especificação quanto de ML.

Modos de falha comuns (e como profissionais mitigam)

Exploração da recompensa (jogo da especificação)

A política explora falhas no modelo de recompensa: ela aprende a parecer boa em vez de ser boa.

Mitigações:

  • manter uma forte restrição de KL
  • coleta adversarial de dados (“encontre prompts em que o modelo engana a recompensa”)
  • ensembles de modelos de recompensa / incerteza
  • avaliação humana periódica em prompts de validação
  • incorporar verificadores (por exemplo, ferramentas de factualidade) quando possível

Superotimização e mudança de distribuição

À medida que você otimiza, as saídas podem derivar para longe da distribuição de dados de preferência, onde o modelo de recompensa é mal calibrado.

Mitigações:

  • early stopping com base na taxa de vitória em validação
  • misturar perda de SFT (“PPO + supervisionado”)
  • coleta iterativa de dados com a política atual (loop de aprendizado ativo (active learning))

Colapso de modo / artefatos de estilo

O modelo pode se tornar excessivamente prolixo, excessivamente cauteloso ou repetitivo porque esses padrões se correlacionam com recompensa.

Mitigações:

  • recompensar explicitamente concisão ou penalizar verbosidade
  • diversificar dados de preferência
  • adicionar exemplos negativos direcionados (por exemplo, “avisos desnecessários”)

Regressões de segurança e vulnerabilidade a jailbreak

Se o modelo de recompensa não cobre prompts adversariais, a política pode se tornar mais capaz e ainda assim explorável.

Mitigações:

  • red teaming e dados de treinamento adversariais
  • recompensa de segurança separada / bloqueio por classificador (classifier gating)
  • avaliar em suítes selecionadas de jailbreak

Notas de implementação que importam na prática

Em quais dados você treina?

O desempenho de RLHF depende fortemente da distribuição de prompts (prompt distribution):

  • Se os prompts parecem com prompts internos de anotação, mas não com usuários reais, você faz overfitting.
  • Muitos sistemas misturam:
    • prompts de usuários reais (com salvaguardas de privacidade)
    • prompts sintéticos (templates de tarefas diversas)
    • prompts de equipes vermelhas (testes de estresse de segurança)

Calibração e escala do modelo de recompensa

As pontuações do modelo de recompensa são arbitrárias até uma escala; PPO é sensível à escala da recompensa.

Práticas comuns:

  • normalizar/recortar recompensas (normalize/clip)
  • branqueamento de vantagem dentro do batch
  • monitorar deriva da recompensa e KL ao longo do tempo

Aspectos offline vs online

RLHF é “online” no sentido de que você amostra da política atual durante a otimização (rollouts na política (on-policy)), mas também é “offline” porque:

  • o modelo de recompensa é treinado em um conjunto fixo de dados de preferências
  • humanos não estão no loop a cada passo de gradiente

RL totalmente online com feedback humano contínuo é possível, mas caro e operacionalmente complexo.

Quando você deve usar RL para alinhamento de LLMs?

RL (incluindo métodos no estilo RLHF) é mais útil quando:

  • você consegue definir ou aprender uma recompensa que corresponda ao que você quer
  • alvos supervisionados são insuficientes (preferências, rubricas, sucesso de tarefa)
  • você precisa de otimização em interações de horizonte longo (agentes, ferramentas)
  • você consegue investir em avaliação e monitoramento para evitar exploração da recompensa

Se sua tarefa é bem especificada com saídas de verdade-terreno (ground-truth) (por exemplo, tradução com referências), aprendizado supervisionado pode ser mais simples e seguro.

Tópicos relacionados

RL para LLMs é uma área ativa: o campo continua explorando métodos mais estáveis de otimização por preferências, melhor modelagem de recompensa, feedback escalável (incluindo feedback de IA) e treinamento agêntico mais seguro, em que o sucesso é medido por resultados reais em vez de pontuações proxy.