Você já se perguntou por que o ChatGPT responde educadamente em vez de cuspir texto incoerente? Um modelo base sem alignment gera texto estatisticamente provável. Ele completa frases. Não “quer” ajudar ninguém.
O que transforma um gerador de texto num assistente útil é Reinforcement Learning from Human Feedback (RLHF). E entender isso explica muito do comportamento que você observa nos modelos em produção.
O mapa pro profissional de infra
| Conceito RL | O que faz | Equivalente em infra |
|---|---|---|
| Agent | Quem toma ações | O autoscaler, o controller |
| Environment | Onde as ações acontecem | O cluster, a infra |
| Reward | Feedback numérico (bom/ruim) | Métricas (latência, custo, uptime) |
| Policy | Estratégia de decisão | Regras do autoscaler (quando escalar, quanto) |
| Episode | Uma sequência completa de ações | Um ciclo de scaling (scale up → observa → scale down) |
| Exploration vs Exploitation | Tentar coisas novas vs usar o que funciona | Canary deploy vs stable release |
Reinforcement learning em 5 minutos
RL é uma das três formas de machine learning. As outras duas são:
- Supervised learning: você dá exemplos com resposta certa. “Essa imagem é um gato.” O modelo aprende a mapear input → output.
- Unsupervised learning: você dá dados sem rótulo. O modelo encontra padrões sozinho. Clustering, por exemplo.
- Reinforcement learning: o modelo aprende tentando coisas e recebendo feedback. Sem exemplos explícitos da “resposta certa”.
A analogia clássica é treinar um cachorro. Você não explica em português pro cachorro o que é “sentar”. Você espera ele sentar, dá um petisco (reward positivo), e repete. Com o tempo, ele aprende que sentar = petisco.
RL funciona assim:
O agent observa o estado do environment, toma uma ação, recebe um reward (número positivo ou negativo), observa o novo estado, e repete. Com milhares de iterações, a policy (estratégia) converge pro comportamento que maximiza reward.
Por que LLMs precisam de RL
O treinamento moderno de um LLM costuma ter três fases. A primeira é self-supervised pre-training, a segunda é supervised fine-tuning (SFT), e a terceira usa otimização por preferências como RLHF ou DPO.
Fase 1: Pre-training (self-supervised)
O modelo lê trilhões de tokens da internet e aprende a prever o próximo token. Resultado: um modelo que sabe completar frases, mas não sabe conversar. Se você perguntar “Qual a capital da França?”, ele pode responder “Qual a capital da Alemanha? Qual a capital da Itália?” porque aprendeu que perguntas vêm em sequência.
Custo de infra: milhares de GPUs por semanas. Centenas de milhões de dólares. Você não vai fazer isso.
Fase 2: Supervised Fine-Tuning (SFT)
Humanos escrevem exemplos de conversas corretas. “Pergunta: X. Resposta ideal: Y.” O modelo aprende o formato de assistente.
Custo de infra: dezenas de GPUs por dias. Centenas de milhares de dólares.
Fase 3: RLHF (Reinforcement Learning from Human Feedback)
Aqui é onde a mágica acontece. O processo:
- O modelo gera múltiplas respostas pra mesma pergunta
- Humanos ranqueiam as respostas (qual é melhor, qual é pior)
- Um “reward model” é treinado nessas preferências humanas
- O LLM é otimizado via RL pra maximizar o score do reward model
Pergunta: "Como deletar um namespace no Kubernetes?"
Resposta A: "kubectl delete namespace meu-ns"
Resposta B: "Para deletar um namespace, utilize o comando kubectl..."
Resposta C: "rm -rf /" (claramente ruim)
Humano rankeia: B > A > C
Reward model aprende: respostas com explicação > respostas secas > respostas perigosas
O resultado é um modelo que aprende preferências humanas sem que ninguém precise escrever a “resposta perfeita” pra cada pergunta possível.
RLHF na prática: o pipeline
PPO (Proximal Policy Optimization) é o algoritmo de RL mais usado no pipeline clássico de RLHF. Ele atualiza a policy do modelo de forma conservadora, pra não divergir demais do comportamento base. Pensa num deployment blue-green onde a nova versão não pode ser radicalmente diferente da anterior.
DPO (Direct Preference Optimization) é uma alternativa mais recente e simples. Em vez de treinar um reward model separado, otimiza direto nas preferências. Menos infra necessária, resultados comparáveis.
Reward hacking: quando RL dá errado
Lembra quando você configurou um autoscaler baseado em CPU e ele ficou oscilando entre scale-up e scale-down a cada 30 segundos? Isso é essencialmente o mesmo problema de reward hacking em RL.
Se o reward model tem uma falha, o LLM vai explorar essa falha. Exemplos reais:
- Reward model dá score alto pra respostas longas → modelo gera texto verboso e repetitivo
- Reward model valoriza “parecer confiante” → modelo inventa fatos com certeza absoluta (hallucination)
- Reward model penaliza respostas curtas → modelo nunca diz “não sei”
Isso é exatamente o que acontece com qualquer sistema de otimização. Se sua métrica de SLA é “uptime de 99.9%”, e o time otimiza só pra isso, eles vão achar formas criativas de “estar up” sem necessariamente funcionar bem.
RL além de LLMs: onde você já viu isso
RL aparece em vários lugares que um profissional de infra pode encontrar:
| Aplicação | Agent | Environment | Reward |
|---|---|---|---|
| Autoscaling inteligente | Controller de scaling | Cluster + workload | Custo baixo + SLA cumprido |
| Roteamento de rede | SDN controller | Topologia de rede | Latência mínima, sem congestion |
| Scheduling de jobs | Scheduler | Pool de recursos | Utilização alta + fairness |
| Detecção de anomalia | Monitor agent | Séries temporais | Alertas corretos (precision + recall) |
| Cache eviction | Cache manager | Working set | Hit rate alto |
O Azure Autoscale, por exemplo, não usa RL puro. Usa regras determinísticas. Mas sistemas mais avançados como o Autopilot do Google usam RL pra decidir limites de recursos de containers.
O custo de RL em infra
Se seu time decide fazer RLHF em um modelo custom, aqui está o que eles vão precisar:
# Recurso estimado pra RLHF de um modelo 7B
- 4-8x A100 80GB (ou equivalente)
- 2-4 semanas de training
- ~5000-50000 comparações humanas (ou sintéticas)
- Storage: ~500GB pra checkpoints intermediários
- Network: alta bandwidth entre GPUs (NVLink ou InfiniBand)
Na prática, a maioria dos times não faz RLHF from scratch. Eles usam modelos já alinhados e, quando precisam customização, combinam prompt engineering, RAG e fine-tuning só nos modelos e providers que suportam isso. Mas entender o pipeline ajuda a dimensionar infra quando o pedido chegar.
DPO vs PPO: o trade-off prático
| Aspecto | PPO | DPO |
|---|---|---|
| Complexidade | Alta (reward model + RL loop) | Baixa (otimização direta) |
| Compute necessário | 2x-4x do SFT | ~1.5x do SFT |
| Estabilidade de training | Instável, requer tuning | Mais estável |
| Qualidade final | Ligeiramente melhor em scale | Comparável em modelos menores |
| Quando usar | Modelos grandes (>70B), budget alto | Modelos menores, iteração rápida |
O que levar pra segunda-feira
- RLHF é o motivo pelo qual LLMs parecem “inteligentes”. Sem ele, são só geradores de texto que completam frases.
- Reward hacking é real. Se o modelo faz algo estranho (responde verbosamente, inventa coisas com confiança), provavelmente é uma falha no reward signal.
- RL em infra já existe. Autoscalers inteligentes, cache policies, scheduling. O conceito é o mesmo: agent observa, age, recebe feedback, melhora.
- DPO simplificou muito o pipeline. Times pequenos podem alinhar modelos sem a complexidade toda de PPO.
No próximo post, vamos falar de vector databases. Agora que você sabe o que são embeddings (do post anterior) e como modelos aprendem (esse post), vamos ver onde e como esses vetores são armazenados e buscados em produção.
Leitura complementar
- What is Reinforcement Learning (Neo Kim, System Design Newsletter)
- Training language models to follow instructions with human feedback (paper do InstructGPT/RLHF)
- Direct Preference Optimization (paper do DPO)