RL offline
O que é Aprendizado por Reforço Offline?
Aprendizado por Reforço Offline (Offline Reinforcement Learning, offline RL) (também chamado de RL em lote (batch RL)) é o cenário em que um agente deve aprender uma política de tomada de decisão puramente a partir de um conjunto de dados fixo de experiência registrada (logged experience), sem coletar dados adicionais ao interagir com o ambiente durante o treinamento.
Isso contrasta com o aprendizado por reforço (reinforcement learning, RL) “padrão” (standard RL), em que o agente alterna entre:
- agir no ambiente para coletar novos dados,
- e melhorar sua política usando esses dados.
O RL offline é motivado por domínios em que a exploração online é cara, insegura, lenta ou regulada — por exemplo, saúde, robótica em hardware real, controle industrial, finanças e muitos sistemas de produtos voltados ao usuário.
O RL offline fica na interseção de:
- Conceitos de Aprendizado por Reforço clássicos (MDPs, funções de valor (value functions), backups de Bellman (Bellman backups)),
- aprendizado por reforço fora da política (off-policy RL) (aprender uma política-alvo a partir de dados produzidos por outra política), e
- aprendizado por imitação (imitation learning) (aprender a imitar comportamento), mas tem armadilhas únicas que exigem cuidados algorítmicos especiais.
Por que o RL Offline é Difícil: Deslocamento de Distribuição e “Ações Desconhecidas”
No RL offline, o conjunto de dados foi gerado por alguma política de comportamento (behavior policy) (ou uma mistura de políticas), frequentemente denotada por ( \mu(a \mid s) ). Queremos aprender uma política-alvo (target policy) ( \pi(a \mid s) ) que (idealmente) obtenha maior retorno (return).
O principal desafio é o deslocamento de distribuição (distribution shift):
- O conjunto de dados contém pares estado–ação extraídos de ( d_\mu(s, a) ) (a distribuição de comportamento).
- Se a política aprendida ( \pi ) seleciona ações que são raras ou ausentes no conjunto de dados para um determinado estado, o algoritmo precisa generalizar além dos dados observados.
- Muitos algoritmos de RL dependem de bootstrap (bootstrapping) (aprender a partir de previsões de outras previsões). No RL offline, o bootstrap pode amplificar erros para ações fora da distribuição (out-of-distribution, OOD), causando superestimação de valor (value overestimation) e levando a política a explorar esses erros.
Esse modo de falha às vezes é chamado de erro de extrapolação (extrapolation error): o crítico (critic) atribui um valor irrealisticamente alto a ações que não foram bem cobertas pelo conjunto de dados, e o ator (actor) aprende a escolhê-las.
Uma intuição concreta
Suponha que você tenha um conjunto de dados de registros de direção em que, em uma certa velocidade e posição na faixa, o motorista geralmente escolhe pequenos ajustes no volante. Um algoritmo de RL offline que otimiza ingenuamente valores Q (Q-values) pode descobrir que um ângulo de direção brusco tem um Q previsto muito alto (porque o modelo nunca o viu, e a aproximação de função (function approximation) extrapolou mal). A política aprendida então escolhe essa curva brusca — apesar de ser insegura e não suportada pelos dados.
Os algoritmos de RL offline são, em grande parte, sobre evitar ou controlar esse tipo de exploração de ações OOD.
Configuração do Problema (MDP + Conjunto de Dados Fixo)
O RL offline normalmente assume um Processo de Decisão de Markov (Markov Decision Process, MDP) ( (\mathcal{S}, \mathcal{A}, P, r, \gamma) ) como no RL padrão:
- (s \in \mathcal{S}): estado
- (a \in \mathcal{A}): ação
- (P(s' \mid s, a)): dinâmica
- (r(s, a)): recompensa
- (0 < \gamma < 1): fator de desconto
Mas, em vez de interação, recebemos um conjunto de dados:
[ \mathcal{D} = {(s_i, a_i, r_i, s'_i, \text{done}i)}{i=1}^N ]
coletado por uma política de comportamento ( \mu ) (frequentemente desconhecida). O objetivo é aprender uma política ( \pi ) que maximize o retorno esperado:
[ J(\pi) = \mathbb{E}\left[\sum_{t=0}^\infty \gamma^t r(s_t, a_t)\right] ]
com a restrição de que o aprendizado deve usar apenas ( \mathcal{D} ).
Relação com Tópicos Próximos
RL offline vs. aprendizado por imitação (clonagem de comportamento)
Clonagem de Comportamento (Behavior Cloning, BC) trata o conjunto de dados como aprendizado supervisionado: prever (a) a partir de (s). É simples e estável, mas geralmente não consegue superar o comportamento do conjunto de dados (a menos que o conjunto de dados misture bom e mau comportamento e a BC “faça uma média” de forma útil).
O RL offline busca melhorar além da política de comportamento usando recompensas e atribuição de crédito em horizontes longos — evitando, ao mesmo tempo, armadilhas OOD.
RL offline vs. RL fora da política
Algoritmos fora da política padrão (por exemplo, DQN, TD3, SAC) podem usar buffers de replay (replay buffers), mas tipicamente assumem que podem continuar coletando novos dados. Sem isso, o bootstrap pode se tornar instável. O RL offline modifica objetivos/restrições para fazer o aprendizado fora da política funcionar sem nova experiência.
RL offline vs. bandits
Em Bandits, não há estrutura de transição de estados de horizonte longo. Bandits contextuais offline (offline contextual bandits) são mais simples, mas ainda enfrentam problemas de suporte e avaliação. O RL offline herda esses problemas e adiciona composição temporal e bootstrap.
Fundamentos Teóricos: O que Precisa Ser Verdade?
O RL offline tem várias realidades do tipo “não existe almoço grátis”. Embora a teoria varie conforme as suposições, os temas recorrentes são:
1) Suposições de suporte / cobertura
Aprender uma política de alto desempenho exige que o conjunto de dados forneça cobertura suficiente dos estados e ações que a política irá executar.
Uma versão simplificada:
- Se a ação ótima (a^*) em algum estado crítico (s) nunca aparece no conjunto de dados, é fundamentalmente difícil saber que ela é boa.
- Por isso, algoritmos de RL offline frequentemente visam a melhor política dentro do suporte do conjunto de dados, ou incorporam pessimismo (pessimism)/incerteza para evitar ações sem suporte.
Isso está intimamente relacionado a coeficientes de concentrabilidade (concentrability) ou descasamento de distribuição (distribution mismatch) em análises teóricas: se a política-alvo visita regiões distantes da distribuição do conjunto de dados, as garantias se degradam rapidamente.
2) Avaliação fora da política é difícil
Até mesmo avaliar uma política offline pode ser difícil, especialmente com horizontes longos e ações contínuas. Estimadores de alta variância podem dificultar escolher entre políticas candidatas com segurança.
O RL offline frequentemente se apoia em:
- métodos de avaliação de política offline (offline policy evaluation, OPE), ou
- desenhos algorítmicos que reduzem a necessidade de estimar com precisão valores para ações OOD.
3) Pessimismo pode ser necessário
Muitos métodos bem-sucedidos de RL offline implementam alguma forma de estimativa pessimista de valor (pessimistic value estimation): tratar valores incertos (sem suporte) de estado–ação como menores do que extrapolações otimistas sugeririam. Isso desencoraja a política a escolher ações não respaldadas por dados.
Técnicas Centrais em Algoritmos de RL Offline
Os algoritmos de RL offline diferem em forma, mas a maioria das abordagens bem-sucedidas usa uma ou mais destas ideias:
1) Restrições de política / regularização pelo comportamento
Manter a política aprendida próxima da política de comportamento para que ela não derive para regiões sem suporte.
Mecanismos comuns:
- regularização por KL (KL regularization): penalizar ( \mathrm{KL}(\pi(\cdot\mid s),|,\mu(\cdot\mid s)) )
- restrições no espaço de ações (action-space constraints): considerar apenas ações prováveis sob o conjunto de dados
- adicionar um termo de perda de BC às atualizações do ator (popular na prática)
Isso troca melhoria por segurança: restrições mais fortes reduzem risco OOD, mas limitam ganhos de desempenho.
2) Aprendizado conservador (inferior) de valor
Penalizar valores Q para ações que não estão no conjunto de dados, para que eles não se tornem espuriamente grandes.
Intuição: se você não consegue justificar uma ação com dados, não atribua a ela um valor alto.
3) Estimativa de incerteza e pessimismo
Estimar incerteza via conjuntos (ensembles), dropout (dropout) ou modelos probabilísticos (probabilistic models) explícitos, e então escolher políticas que maximizem um limite inferior de confiança (lower confidence bound).
Isso é conceitualmente similar a bônus de exploração (exploration bonuses) no RL online, exceto que no RL offline a incerteza é frequentemente usada para ser mais cauteloso, não mais exploratório.
4) RL offline baseado em modelo (aprender a dinâmica e planejar de forma conservadora)
Aprender um modelo de dinâmica (dynamics model) ( \hat{P}(s' \mid s, a) ) a partir do conjunto de dados e gerar rollouts sintéticos (synthetic rollouts). Isso pode aumentar o tamanho efetivo dos dados, mas traz risco de viés de modelo (model bias). Métodos offline baseados em modelo frequentemente adicionam penalidades para incerteza do modelo ou restringem rollouts a regiões dentro da distribuição. Veja também AR Baseado em Modelo.
5) Abordagens de modelagem de sequência
Alguns métodos de RL offline tratam trajetórias (trajectories) como sequências e aprendem a gerar ações condicionadas a retornos desejados (por exemplo, “imitação condicionada ao retorno (return-conditioned imitation)”). Esses métodos podem funcionar bem quando os dados são ricos e diversos, mas ainda dependem da distribuição do conjunto de dados e podem ter dificuldade quando precisam extrapolar muito além dela.
Principais Famílias de Algoritmos de RL Offline (Visão de Alto Nível)
Abaixo estão padrões algorítmicos representativos, e não uma lista exaustiva.
Clonagem de comportamento (BC): a linha de base que você sempre deveria tentar
A BC costuma ser surpreendentemente forte, especialmente quando:
- o conjunto de dados é quase especialista,
- o espaço de ações é bem coberto, e
- o aprendizado de recompensa é ruidoso ou esparso.
Objetivo da BC (supervisionado): [ \max_\pi ; \mathbb{E}_{(s,a)\sim\mathcal{D}}[\log \pi(a\mid s)] ]
Prós: estável, simples, baixo risco de ações OOD
Contras: não consegue melhorar de forma confiável além do comportamento do conjunto de dados
Ator-crítico offline com regularização por BC (por exemplo, estilo TD3+BC)
Uma receita prática comum é:
- aprender um crítico com backups no estilo TD a partir do conjunto de dados
- atualizar o ator para maximizar Q mais um termo de clonagem de comportamento que evita deriva extrema
Isso geralmente funciona bem em conjuntos de dados de “qualidade mista (mixed quality)”.
Aprendizado Q Conservador (estilo CQL)
Métodos no estilo CQL adicionam um termo ao objetivo do crítico que explicitamente puxa para baixo valores Q para ações não vistas no conjunto de dados, enquanto ajusta Q nas ações do conjunto de dados.
Objetivo de alto nível:
- (Q(s,a)) deve ser alto apenas quando o conjunto de dados dá suporte a isso.
Aprendizado Q Implícito (estilo IQL) / regressão ponderada por vantagem
Abordagens do tipo IQL evitam a maximização explícita sobre ações potencialmente OOD durante o treinamento do crítico e aprendem políticas ponderando as ações do conjunto de dados por vantagens (advantages) estimadas.
Isso frequentemente produz resultados fortes com treinamento relativamente estável em tarefas de controle contínuo (continuous control).
Métodos offline baseados em modelo (ideias no estilo MOPO/COMBO)
Esses métodos aprendem um modelo de dinâmica e realizam planejamento (planning) ou otimização de política usando rollouts sintéticos, mas adicionam conservadorismo:
- penalizar transições incertas,
- limitar o horizonte de rollout,
- restringir ações na direção da distribuição de dados.
Avaliação de Política Offline (OPE): Como Sabemos se uma Política é Boa?
Como você não pode implantar e testar online durante o treinamento, você precisa de uma forma de estimar desempenho offline. Abordagens comuns de OPE incluem:
1) Amostragem por importância (IS)
Repondera retornos de trajetórias de comportamento para estimar a política-alvo:
[ \mathbb{E}\pi[\cdot] \approx \mathbb{E}\mu\left[\prod_t \frac{\pi(a_t\mid s_t)}{\mu(a_t\mid s_t)} \cdot \text{return}\right] ]
Problema: a variância explode com o horizonte; requer conhecer ou estimar ( \mu ).
Variantes incluem IS por decisão (per-decision IS) e IS ponderado (weighted IS).
2) Estimadores duplamente robustos (DR)
Combinam um modelo de valor aprendido com amostragem por importância para reduzir a variância e, sob certas condições, oferecem robustez a erros de modelo.
3) Avaliação Q Ajustada (FQE)
Treinar uma função Q (Q-function) para uma política fixa ( \pi ) por regressão no conjunto de dados e então estimar (J(\pi)) a partir dos valores Q.
Problema: ainda está sujeito a deslocamento de distribuição, mas costuma ser mais prático do que IS bruto em controle contínuo.
Conclusão prática sobre OPE
Em muitos sistemas reais, OPE é usado para ranquear candidatos e filtrar políticas obviamente arriscadas; depois, a validação final envolve implantação controlada (modo sombra (shadow mode), canário (canary) ou testes A/B (A/B tests)) quando possível. Garantias apenas offline são limitadas quando a política aprendida se desvia substancialmente do comportamento registrado.
Exemplos Práticos
Exemplo 1: Políticas de tratamento em saúde a partir de logs de UTI
Dados: características de estado do paciente (sinais vitais, exames), intervenções administradas (fluidos, medicamentos), desfechos (por exemplo, sobrevivência, complicações).
Objetivo do RL offline: aprender uma estratégia de tratamento que melhore os desfechos esperados.
Por que RL offline se encaixa:
- Você não pode “explorar” tratamentos aleatórios em pacientes reais.
- Existem grandes conjuntos de dados retrospectivos.
Desafios típicos:
- confundimento e observabilidade parcial (partial observability) (o “estado” registrado pode não capturar tudo o que clínicos usaram)
- recompensas atrasadas
- restrições de segurança (deve evitar intervenções sem suporte)
Na prática, as equipes frequentemente:
- começam com BC ou RL offline conservador,
- usam estimativa forte de incerteza e revisão por clínicos,
- tratam políticas aprendidas como suporte à decisão (decision support) em vez de controle totalmente autônomo.
Exemplo 2: Sistemas de recomendação / ranqueamento de anúncios a partir de interações registradas
Dados: contextos (características do usuário, sessão), itens exibidos, cliques/conversões.
Isso é próximo de bandits contextuais, mas pode virar RL se:
- ações influenciam estados futuros (engajamento de longo prazo),
- você otimiza objetivos de múltiplos passos (retenção (retention)).
Complicações do RL offline:
- os dados registrados são enviesados por políticas anteriores (“você só observa feedback do que mostrou”)
- a avaliação é difícil sem registro randomizado (randomized logging) (escores de propensão (propensity scores))
Padrões práticos de solução:
- garantir algum grau de exploração randomizada na política de logging (quando permitido),
- usar OPE com informação de propensão,
- preferir melhoria de política com restrições em vez de otimização sem restrições.
Exemplo 3: Robótica aprendendo a partir de demonstrações e tentativas anteriores
Dados: trajetórias de teleoperação (teleoperation), controladores roteirizados ou políticas anteriores.
O RL offline pode melhorar além das demonstrações, mas apenas se:
- o conjunto de dados contiver variação suficiente e algum comportamento bem-sucedido,
- você controlar ações OOD (robôs reais podem quebrar).
É comum:
- pré-treinar com BC,
- aplicar ajuste fino (fine-tuning) com RL offline de forma conservadora,
- depois fazer ajuste fino online limitado, se permitido (um pipeline híbrido de offline para online (hybrid offline-to-online pipeline)).
Um Fluxo de Trabalho Mínimo de RL Offline (O que Profissionais Realmente Fazem)
1) Construir o conjunto de dados com cuidado
Perguntas-chave sobre o conjunto de dados:
- É uma política de comportamento única ou uma mistura ao longo do tempo?
- Ele contém tanto bom quanto mau comportamento?
- Como está a cobertura de ações (por estado)?
- As recompensas estão bem definidas e alinhadas ao que você quer?
Higiene de dados (data hygiene) importa muito:
- terminação consistente de episódios (
done) - temporização correta da recompensa (especialmente desfechos atrasados)
- normalizar observações/ações se estiver usando redes neurais (neural networks)
- lidar com censura (censoring) e valores ausentes (comum em logs reais)
2) Começar com linhas de base fortes
Uma escada típica de linhas de base:
- Clonagem de Comportamento
- BC + reponderação simples de recompensa (se apropriado)
- Um método conservador de RL offline (por exemplo, ator-crítico com forte regularização por BC)
Isso evita gastar semanas em um método complexo quando o conjunto de dados, fundamentalmente, não consegue sustentar melhoria.
3) Validar com OPE + verificações de sanidade
Em geral, você quer múltiplos sinais:
- estimativas de OPE (variantes de FQE/DR/IS)
- métricas de restrição/segurança (desvio de ação em relação aos dados, funções de custo)
- testes de estresse (stress tests) em estados raros
- se disponível, avaliação em um simulador ou em um modelo de alta fidelidade (high-fidelity model)
4) Implantar com cautela (se implantação for o objetivo)
Padrões comuns de segurança:
- modo sombra (a política faz recomendações, mas não age)
- filtragem (gating) (só agir quando a confiança é alta / o estado está dentro da distribuição)
- rollout gradual com monitoramento
Esqueleto de Código Ilustrativo (Conjunto de Dados Offline + Loop de Treinamento)
Abaixo está um esboço deliberadamente de alto nível. Implementações reais dependem da sua biblioteca (PyTorch/JAX) e da escolha de algoritmo.
import numpy as np
# Offline dataset of transitions (e.g., from logs)
D = {
"s": np.load("states.npy"), # shape [N, obs_dim]
"a": np.load("actions.npy"), # shape [N, act_dim]
"r": np.load("rewards.npy"), # shape [N, 1]
"s_next": np.load("next_states.npy"), # shape [N, obs_dim]
"done": np.load("dones.npy"), # shape [N, 1]
}
# Pseudocode objects: actor πθ(a|s), critic Qϕ(s,a), target critic Q̄
actor = ActorNetwork()
critic = CriticNetwork()
target_critic = CriticNetwork()
target_critic.load_state_dict(critic.state_dict())
for step in range(200_000):
batch = sample_batch(D, batch_size=256)
s, a, r, s_next, done = batch
# Critic update (bootstrapped target)
with torch.no_grad():
a_next = actor.sample(s_next)
q_target = r + (1.0 - done) * gamma * target_critic(s_next, a_next)
q_pred = critic(s, a)
critic_loss = mse(q_pred, q_target)
# Offline-specific modification examples:
# - add conservatism penalty to critic_loss (CQL-style)
# - or avoid max over actions and use implicit objectives (IQL-style)
critic_opt.zero_grad()
critic_loss.backward()
critic_opt.step()
# Actor update with behavior regularization (BC term)
a_pi = actor.sample(s)
actor_loss = -critic(s, a_pi).mean()
bc_loss = mse(a_pi, a) # simplistic; often log-prob loss is used
actor_loss = actor_loss + alpha * bc_loss
actor_opt.zero_grad()
actor_loss.backward()
actor_opt.step()
soft_update(target_critic, critic, tau=0.005)
Isso captura a forma de muitos métodos offline para controle contínuo: aprendizado do crítico + melhoria do ator + um mecanismo explícito para evitar deriva para ações OOD.
Modos de Falha Comuns e Dicas de Depuração
Explosão de valores Q / aprendizado instável
Sintomas: valores Q crescem muito; a política produz ações extremas.
Mitigações:
- regularização pelo comportamento mais forte
- penalidades Q conservadoras / pessimismo
- double Q com clipping, redes-alvo (target networks), taxas de aprendizado menores
- conjuntos (ensembles) e alvos pessimistas
A política colapsa para clonagem de comportamento
Sintomas: nenhuma melhoria sobre BC mesmo com sinal de recompensa.
Possíveis razões:
- o conjunto de dados contém pouco sinal para melhoria (comportamento quase determinístico)
- a recompensa é ruidosa demais ou mal alinhada
- regularização forte demais (a política não consegue se desviar)
A avaliação offline não bate com a realidade
Sintomas: OPE diz que a política é ótima; a implantação falha (ou vice-versa).
Mitigações:
- usar múltiplos estimadores de OPE
- validar em períodos de tempo de holdout (holdout) / diferentes coortes de usuários
- medir a divergência da política em relação ao conjunto de dados e tratar divergência grande como alto risco
- incorporar incerteza e seleção conservadora
Onde o RL Offline é Usado Hoje
O RL offline é especialmente relevante quando você tem:
- muitos logs,
- capacidade limitada de explorar, e
- necessidade de otimizar resultados de longo prazo.
Áreas de aplicação representativas:
- suporte à decisão em saúde
- sistemas de recomendação e ranking (frequentemente mais próximo de bandits, às vezes RL)
- robótica aprendendo a partir de demonstrações e execuções anteriores
- cadeia de suprimentos e operações
- controle de energia/rede
- finanças (com fortes ressalvas sobre não estacionariedade (non-stationarity) e confundimento)
O RL offline também se relaciona conceitualmente a pipelines de alinhamento em RL para LLMs (RL for LLMs): grande parte de RLHF começa a partir de conjuntos de dados fixos de preferências (offline), embora o pipeline completo possa incluir amostragem online do modelo e coleta iterativa de dados.
Principais Conclusões
- RL offline aprende políticas a partir de dados registrados fixos sem exploração interativa.
- Sua dificuldade central é o deslocamento de distribuição: objetivos ingênuos de RL podem explorar extrapolação da função Q para ações não suportadas pelo conjunto de dados.
- RL offline bem-sucedido tipicamente depende de conservadorismo, restrições, incerteza/pessimismo e avaliação cuidadosa.
- Na prática, RL offline é um fluxo de trabalho: desenho do conjunto de dados → linhas de base fortes (especialmente BC) → melhoria conservadora → OPE + verificações de segurança → implantação cautelosa.
- RL offline é poderoso quando o conjunto de dados é rico e relevante, mas não pode recuperar magicamente o comportamento ótimo sem cobertura suficiente de boas ações e sinais informativos.
Se você quiser conectar RL offline a fundamentos mais amplos de RL, veja Conceitos de Aprendizado por Reforço e AR Baseado em Modelo.