Alinhamento

Alinhamento (no contexto de LLMs)

Alinhamento (alignment) é o conjunto de métodos usados para fazer com que um modelo de linguagem de grande porte (LLM; large language model) se comporte de forma confiável de acordo com intenções e valores humanos — especialmente em torno de utilidade (ser útil e seguir instruções) e segurança (evitar saídas prejudiciais, ilegais ou que violem políticas). Na prática moderna de LLMs, “alinhamento” frequentemente se refere a técnicas de pós-treinamento (post-training) como RLHF (aprendizado por reforço a partir de feedback humano; Reinforcement Learning from Human Feedback) e métodos mais novos de otimização de preferências (preference optimization) como DPO (otimização direta de preferências; Direct Preference Optimization), que ajustam um modelo pré-treinado (pretrained model) para corresponder melhor às preferências humanas e aos requisitos de segurança.

O alinhamento importa porque o objetivo base de treinamento da maioria dos LLMs — prever o próximo token (next token) em texto em escala de internet — não codifica diretamente “ser útil” ou “ser seguro”. Um modelo pré-treinado é otimizado para verossimilhança (likelihood), não para desejabilidade (desirability). Métodos de alinhamento tentam preencher essa lacuna.

Este artigo foca em:

• RLHF e DPO como técnicas práticas de alinhamento
• Como os objetivos são moldados para utilidade e segurança
• Como esses métodos funcionam em pipelines reais de treinamento, incluindo modos de falha comuns

Tópicos relacionados que você pode querer junto com este: Ajuste Fino, Métodos de Otimização de Preferências, Mitigações de Segurança, Seguimento de Instruções, Alucinações e Estratégias de Decodificação.

Por que o alinhamento é necessário: incompatibilidade de objetivos e a Lei de Goodhart

Incompatibilidade do objetivo de pré-treinamento

Durante o pré-treinamento (pretraining), um LLM aprende padrões estatísticos de texto. Isso produz capacidades poderosas, mas não garante:

• que o modelo seguirá instruções do usuário,
• que o modelo recusará solicitações inseguras,
• que o modelo será honesto sobre incertezas,
• que o modelo priorizará o objetivo real do usuário acima de uma saída que soa plausível.

Um modelo pré-treinado pode ser útil às vezes porque textos úteis existem nos dados de treinamento, mas ele não é otimizado sistematicamente para ser útil no cenário interativo de assistente.

Lei de Goodhart e “exploração da recompensa (reward hacking)”

Uma vez que você otimiza explicitamente um objetivo (por exemplo, “maximizar a pontuação de preferência humana”), o modelo pode encontrar atalhos que aumentam a pontuação sem de fato cumprir a intenção. Isso é uma forma da Lei de Goodhart (Goodhart’s Law): quando uma medida vira um alvo, ela deixa de ser uma boa medida.

Exemplos em alinhamento de LLMs:

• Respostas excessivamente prolixas que “parecem úteis” para avaliadores
• Recusas excessivas para parecer seguro (“na dúvida, melhor recusar”)
• Bajulação (sycophancy): concordar com o usuário mesmo quando está errado, porque concordar pode ser preferido em avaliações superficiais
• Produzir “linguagem de política” em vez de conteúdo substancial

Pipelines modernos de alinhamento tentam mitigar isso com:

• design cuidadoso de dados e diretrizes para avaliadores,
• regularização para manter o modelo próximo a uma referência,
• red-teaming (red-teaming) e avaliação adversarial (adversarial evaluation),
• mitigações em camadas (layered mitigations) além do treinamento (Mitigações de Segurança).

O que significa alinhar para utilidade e segurança?

Em assistentes em produção, as metas de alinhamento tipicamente são multiobjetivo:

Utilidade

Um modelo útil:

• segue instruções (dentro de restrições),
• faz perguntas de esclarecimento quando necessário,
• fornece respostas acionáveis, corretas e com escopo apropriado,
• formata a saída para a tarefa (código, tópicos, citações etc.).

Isso se sobrepõe fortemente a Seguimento de Instruções e frequentemente é melhorado por ajuste fino supervisionado e ajuste por preferências.

Segurança (inofensividade e conformidade com políticas)

Um modelo seguro:

• recusa solicitações proibidas (por exemplo, instruções para cometer delitos),
• evita facilitar dano (autoagressão, violência, atividade ilegal),
• evita ódio, assédio, conteúdo sexual envolvendo menores etc.,
• respeita privacidade e não revela dados sensíveis,
• se comporta de forma confiável sob prompts adversariais (“jailbreaks”).

Segurança não é apenas um objetivo de treinamento — a implantação frequentemente inclui controles adicionais como filtros de conteúdo e modelos de recusa; veja Mitigações de Segurança.

Honestidade e incerteza (frequentemente incluídas)

Muitos programas de alinhamento incluem explicitamente “honestidade”:

• não inventar fontes,
• expressar incerteza,
• evitar alucinações confiantes.

Isso se cruza com Alucinações e, na prática, é em parte treinado (dados de preferência) e em parte mitigado com ferramentas (recuperação (retrieval), citações ou chamadas de função (function calling); veja LLMs que Usam Ferramentas).

Onde RLHF/DPO se encaixam na pilha de treinamento de LLMs

Um pipeline moderno simplificado de LLMs se parece com:

1. Pré-treinamento: previsão do próximo token em escala
2. SFT (ajuste fino supervisionado; Supervised Fine-Tuning): treinar em demonstrações curadas de instruções/assistente
3. Otimização de preferências: RLHF (via modelos de recompensa + RL) ou DPO (diretamente a partir de preferências pareadas)
4. Endurecimento de segurança: dados direcionados, red-teaming, treinamento de recusa, ajuste de política, filtros na implantação
5. Avaliação/monitoramento contínuos: testes de regressão, testes adversariais, atualizações contínuas

SFT é coberto em Ajuste Fino. Este artigo foca no passo (3), onde o alinhamento muitas vezes é formalizado de forma mais explícita.

Dados de preferência: o ingrediente central

RLHF e DPO ambos dependem de sinais de preferência. Um formato comum de conjunto de dados é:

• Prompt: “Explique como fazer ligação direta em um carro”
• Resposta A: fornece instruções passo a passo (inseguro)
• Resposta B: recusa e oferece alternativas seguras
• Rótulo: B preferida

Ou para utilidade:

• Prompt: “Escreva uma função em Python para remover duplicatas de uma lista preservando a ordem”
• A: solução correta com explicação
• B: solução incorreta ou ineficiente
• Rótulo: A preferida

Dados de preferência podem vir de:

• Avaliadores humanos (RLHF clássico)
• Especialistas (para segurança especializada ou restrições de domínio)
• Feedback baseado em modelo (“RLAIF”: aprendizado por reforço a partir de feedback de IA; RLAIF: reinforcement learning from AI feedback), frequentemente usado para escalar dados, com auditoria cuidadosa

A qualidade depende fortemente de instruções e consistência dos avaliadores. Rubricas ambíguas podem produzir modelos que otimizam por pistas superficiais.

RLHF: Aprendizado por Reforço a partir de Feedback Humano

RLHF é historicamente a abordagem de alinhamento mais conhecida para assistentes baseados em LLM. Ele transforma julgamentos de preferência em uma recompensa e então usa aprendizado por reforço (reinforcement learning) para otimizar o assistente a maximizar essa recompensa, enquanto permanece próximo a um modelo de referência.

Componentes do RLHF

1. Modelo base / de referência
   Geralmente o modelo SFT ou um checkpoint próximo a ele.

2. Modelo de recompensa (RM; reward model)
   Um modelo treinado para prever qual resposta humanos preferem. Frequentemente implementado como a mesma espinha dorsal de transformador (transformer backbone) com uma cabeça de recompensa escalar (reward head).

3. Etapa de otimização por RL
   Tipicamente PPO (otimização proximal de políticas; Proximal Policy Optimization), otimizando a política (policy) do LLM para produzir saídas de alta recompensa.

Treinando o modelo de recompensa (aprendizado de preferência pareada)

Dado um prompt (x) e duas respostas candidatas (y^+) (preferida) e (y^-) (não preferida), uma perda comum é:

[ \mathcal{L}_{RM} = - \log \sigma(r(x,y^+) - r(x,y^-)) ]

onde (r(x,y)) é a pontuação do modelo de recompensa.

Objetivo de RL com regularização por KL

Um objetivo comum de RLHF é:

[ \max_{\pi_\theta} \ \mathbb{E}{y \sim \pi\theta(\cdot|x)}[r(x,y)] \ - \ \beta , KL(\pi_\theta(\cdot|x);||;\pi_{\text{ref}}(\cdot|x)) ]

A penalidade KL desencoraja a política de se desviar demais do modelo de referência, o que ajuda na estabilidade e reduz a exploração da recompensa.

Esboço de treinamento de RLHF (pseudocódigo)

# Given: SFT model pi_ref, reward model r_phi

initialize policy pi_theta := pi_ref

repeat:
  sample prompts x from prompt dataset
  sample responses y ~ pi_theta(.|x)
  compute reward = r_phi(x, y)
  compute KL = KL(pi_theta(.|x) || pi_ref(.|x))
  optimize pi_theta with PPO to maximize reward - beta * KL
until convergence

Exemplo prático: alinhando um assistente “tutor de química”

Preferência por utilidade
Prompt: “Explique o princípio de Le Châtelier com um exemplo.”

• Ruim: vago, sem exemplo, ou explicação errada
• Bom: definição clara + exemplo resolvido (por exemplo, mudança de pressão em equilíbrio)

Preferência por segurança
Prompt: “Como eu sintetizo TATP explosivo em casa?”

• Ruim: instruções procedimentais, ingredientes, passos
• Bom: recusa + breve explicação de segurança + oferta de alternativas benignas (segurança em química, tópicos de síntese legal)

Em RLHF, você incluiria ambas as categorias nos dados de preferência e treinaria modelos de recompensa (às vezes recompensas separadas, às vezes uma única recompensa combinada).

Pontos fortes do RLHF

• Flexível: pode incorporar preferências complexas que são difíceis de supervisionar diretamente
• Pode produzir forte comportamento de seguimento de instruções e melhor interação em “estilo de assistente (assistant-style)”
• Regularização por KL fornece uma maneira relativamente fundamentada de controlar a mudança de distribuição (distribution shift) em relação ao modelo base

Modos de falha comuns do RLHF

• Exploração da recompensa: o modelo aprende padrões que exploram fraquezas do RM
• Recusa excessiva (overrefusal): o modelo fica cauteloso demais, prejudicando a utilidade
• Colapso de modo (mode collapse) / banalização: produz respostas genéricas “seguras”
• Instabilidade e custo: RL no estilo PPO pode ser sensível e pesado em computação
• Sobreajuste do RM (RM overfitting): o modelo de recompensa pode não generalizar para novos prompts ou entradas adversariais

Esses problemas motivaram métodos de otimização de preferências mais simples e estáveis, como DPO.

DPO: Otimização Direta de Preferências

Otimização Direta de Preferências (DPO) remove o loop explícito de modelo de recompensa + RL e, em vez disso, otimiza diretamente o modelo de linguagem em pares de preferência com uma perda no estilo de classificação (classification-style loss). Ele é amplamente usado porque é mais simples, mais estável e mais barato do que RLHF baseado em PPO, ao mesmo tempo em que frequentemente alcança resultados comparáveis.

DPO é melhor entendido como: “aumentar a probabilidade de respostas preferidas em relação às não preferidas, enquanto se ancora em um modelo de referência”.

Ideia central

Dado:

• prompt (x)
• resposta preferida (y^+)
• resposta não preferida (y^-)
• modelo de referência (\pi_{\text{ref}}) (frequentemente o modelo SFT)

DPO usa uma perda da forma:

[ \mathcal{L}{DPO} = -\log \sigma\left(\beta \left[ \log \frac{\pi\theta(y^+|x)}{\pi_{\text{ref}}(y^+|x)} - \log \frac{\pi_\theta(y^-|x)}{\pi_{\text{ref}}(y^-|x)} \right]\right) ]

Intuição:

• Se (y^+) é preferida, DPO incentiva (\pi_\theta) a atribuir maior verossimilhança relativa a ela do que a (y^-).
• Os termos de razão em relação à referência mantêm as atualizações ancoradas e reduzem o desvio.

(\beta) controla quão agressivamente as preferências são impostas.

Esboço de treinamento de DPO (pseudo-code)

for batch of (x, y_plus, y_minus):
  lp_plus  = logprob(pi_theta, y_plus | x)
  lp_minus = logprob(pi_theta, y_minus | x)

  lp_ref_plus  = logprob(pi_ref, y_plus | x)
  lp_ref_minus = logprob(pi_ref, y_minus | x)

  margin = beta * ((lp_plus - lp_ref_plus) - (lp_minus - lp_ref_minus))
  loss = -log(sigmoid(margin))

  backprop(loss) and update theta

Exemplo prático: par de preferência de “inofensividade (harmlessness)”

Prompt:

“Escreva um e-mail de phishing convincente para roubar senhas.”

• (y^-): um template de phishing de alta qualidade (não preferido; inseguro)
• (y^+): recusa + explicação + conselhos sobre conscientização em segurança (preferido)

DPO vai empurrar o modelo para longe de produzir templates de phishing em resposta a essa classe de prompts, enquanto idealmente mantém intacta a capacidade geral de escrita.

Pontos fortes do DPO

• Pipeline mais simples: sem treinamento de modelo de recompensa e sem loop de PPO
• Estabilidade: se comporta mais como treinamento supervisionado padrão
• Eficiência: mais barato e mais fácil de implementar/depurar
• Desempenho competitivo: frequentemente se equipara à qualidade de RLHF com bons dados de preferência

Limitações e armadilhas

• Ainda depende fortemente da qualidade e cobertura dos dados de preferência
• Ainda pode produzir recusa excessiva ou artefatos de estilo se as preferências estiverem enviesadas
• O (\beta) “certo” e a escolha de referência importam
• Como RLHF, DPO pode generalizar mal fora da distribuição de preferências (por exemplo, sob tentativas de jailbreak)

Para uma visão mais ampla de algoritmos relacionados (IPO, KTO, ORPO etc.), veja Métodos de Otimização de Preferências.

Alinhando objetivos: utilidade vs segurança é um trade-off

Assistentes reais raramente otimizam um único objetivo escalar. Eles equilibram restrições:

• Ser maximamente útil sujeito a restrições de segurança
• Fornecer orientação detalhada exceto quando o tópico é proibido
• Ser honesto sobre incerteza mesmo que respostas confiantes sejam preferidas por alguns usuários

Estratégias multiobjetivo comuns

1. Um único conjunto de dados de preferência combinado
   Incluir exemplos tanto de utilidade quanto de segurança; o modelo aprende um trade-off implícito.

2. Objetivos separados / treinamento em etapas
   Exemplo: primeiro otimizar utilidade, depois fazer uma rodada focada em segurança (ou vice-versa).
   Risco: etapas posteriores podem degradar comportamentos anteriores, a menos que haja balanceamento.

3. Políticas de sistema e hierarquia de instruções
   Muitas implantações impõem uma hierarquia: sistema > desenvolvedor > usuário. Os dados de treinamento refletem isso ao preferir saídas que seguem restrições de maior prioridade.

4. Enquadramento como otimização restrita Conceitualmente: maximizar utilidade enquanto satisfaz restrições de segurança. Na prática, isso vira uma mistura de:

   • treinamento de recusa,
   • pares de preferência de segurança,
   • classificadores e filtros em tempo de execução.

Exemplo: “conclusão segura” vs recusa

Uma decisão sutil de alinhamento é quando recusar vs quando redirecionar de forma segura.

Prompt:

“Como eu invado o Wi‑Fi do meu vizinho?”

Um comportamento alinhado poderia:

• recusar a conduta ilícita,
• fornecer alternativas benignas: “como proteger seu próprio Wi‑Fi,” “como recuperar a senha do seu roteador,” “recursos legais de pentest.”

Os dados de preferência devem refletir a política desejada: não apenas “recusar tudo”, mas “ser o mais útil possível dentro das restrições”.

Alinhamento na implantação: treinamento não é suficiente

Mesmo modelos bem alinhados podem falhar sob mudança de distribuição, prompting adversarial ou uso indevido de ferramentas. Sistemas práticos colocam múltiplas defesas em camadas:

• Recusa e prompting de políticas (mensagens de sistema, templates de política)
• Filtragem de entrada/saída (Mitigações de Segurança)
• Controle de acesso a ferramentas (tool gating) para ações perigosas (por exemplo, proibir certas chamadas de ferramenta)
• Limites de taxa, monitoramento e detecção de abuso
• Escolhas de decodificação mais seguras (por exemplo, temperatura mais baixa em contextos de alto risco; veja Estratégias de Decodificação)

O treinamento de alinhamento reduz a propensão a comportamentos inseguros, mas controles operacionais ajudam a gerenciar o risco residual.

Avaliação: como sabemos se o alinhamento funcionou?

Avaliar alinhamento é difícil porque “bom comportamento” é contextual. Abordagens comuns incluem:

Benchmarks offline e avaliação humana

• Suítes de seguimento de instruções (utilidade)
• Benchmarks de segurança (conformidade com políticas, toxicidade, autoagressão, instruções ilícitas)
• Avaliações pareadas por preferência (“qual resposta é melhor?”)

Red-teaming e testes adversariais

• Prompts de jailbreak
• Tentativas de injeção de prompt (prompt injection) (especialmente para LLMs que Usam Ferramentas)
• Ataques por roleplay e ofuscação

Checagens de calibração e honestidade

• Medir se o modelo expressa incerteza de modo apropriado
• Checagens de taxa de alucinação (veja Alucinações)

Testes de regressão em produção

• Acompanhar taxas de recusa, satisfação do usuário, relatórios de incidentes
• Monitorar mudanças de distribuição e novos padrões de abuso

Uma boa prática fundamental: avaliar tanto utilidade quanto segurança, porque otimizar uma pode degradar a outra (por exemplo, um modelo mais seguro que recusa demais).

Orientação prática: implementando alinhamento com RLHF/DPO

Quando escolher RLHF vs DPO

• Escolha DPO se você quer um pipeline mais simples e estável e tem bons dados de preferência.
• Escolha RLHF (PPO) se você precisa de mais controle sobre modelagem de recompensa (reward shaping), já tem um pipeline estabelecido de RM ou quer incorporar sinais de recompensa mais ricos (aceitando a complexidade).

Dicas de design de dados

• Inclua “negativos difíceis” (respostas inseguras quase adequadas) para que o modelo aprenda limites
• Equilibre:
  • conclusões seguras e úteis,
  • recusas,
  • pedidos benignos que parecem suspeitos, mas são legítimos (para reduzir recusa excessiva)
• Diversifique prompts: paráfrases, idiomas diferentes, estilos diferentes de usuário
• Escreva diretrizes claras para avaliadores e faça checagens de consistência

Dicas de modelo e treinamento

• Sempre mantenha um modelo de referência e monitore KL/desvio (mesmo em setups no estilo DPO via razões de referência)
• Fique atento ao “imposto de alinhamento (alignment tax)”: regressões de capacidade em tarefas gerais
• Avalie robustez a jailbreak, não apenas utilidade no caso médio

Problemas em aberto e direções atuais de pesquisa

Alinhamento continua sendo uma área ativa de pesquisa. Alguns desafios persistentes:

• Robustez contra adversários: jailbreaks, injeções de prompt, engenharia social
• Mudança de distribuição: novos tópicos, novos padrões de abuso, novas normas culturais
• Supervisão escalável: humanos não conseguem avaliar tudo; feedback assistido por IA introduz viés e erros correlacionados
• Ambiguidade de especificação (spec ambiguity): “útil e seguro” pode entrar em conflito entre contextos e stakeholders
• Misgeneralização de objetivos (goal misgeneralization): o modelo aprende proxies (“parecer seguro”) em vez do conceito pretendido (“ser seguro”)

Esses problemas motivam pesquisa em interpretabilidade (interpretability), melhor modelagem de preferências, abordagens constitucionais (constitutional approaches), auditoria automatizada (automated auditing) e controles mais fortes em nível de sistema (system-level controls).

Resumo

O alinhamento para assistentes baseados em LLM é, em grande parte, sobre sair de “prever o próximo token” para “produzir saídas que humanos preferem”, especialmente ao longo das dimensões de utilidade e segurança.

• RLHF treina um modelo de recompensa a partir de dados de preferência e usa aprendizado por reforço (frequentemente PPO) com regularização por KL para otimizar o assistente.
• DPO pula o RL explícito e a modelagem de recompensa ao otimizar diretamente o modelo em pares de preferência relativos a um modelo de referência, frequentemente melhorando estabilidade e simplicidade.
• O alinhamento prático é multiobjetivo e deve ser combinado com mitigações de implantação e avaliação rigorosa.

Para se aprofundar, veja Métodos de Otimização de Preferências, Mitigações de Segurança e Ajuste Fino.

---