Avaliação Off-Policy
Visão geral
Avaliação Off-Policy (Off-Policy Evaluation, OPE) é o problema de estimar o quão bem uma nova política de decisão teria desempenho usando apenas dados previamente registrados (logged), sem implantar essa política online. Ela é central para uma iteração segura em sistemas como anúncios, recomendações, suporte à decisão clínica e desenvolvimento de produto restrito por testes A/B.
Em cenários de bandits—especialmente Bandits Contextuais—a OPE responde a perguntas como:
- “Se mudássemos a política de recomendação hoje, que taxa de cliques (CTR) obteríamos?”
- “Uma nova política de lances aumentaria a receita sem prejudicar a experiência do usuário?”
- “Conseguimos estimar o impacto de uma política sem um experimento online caro ou arriscado?”
A OPE é poderosa, mas é fácil errar. Os dois modos de falha dominantes são:
- Viés devido a suposições de modelagem incorretas (por exemplo, um modelo de recompensa especificado de forma incorreta).
- Alta variância devido à ponderação por importância quando a nova política difere da política de logging.
Este artigo foca em OPE em bandits (problemas de decisão de um passo), onde a teoria é limpa e muitas aplicações práticas existem. Muitas ideias se generalizam para Aprendizado por Reforço de horizonte mais longo, mas a OPE sequencial introduz complicações adicionais.
Configuração do problema (bandits / bandits contextuais)
Um conjunto de dados de bandit registrado padrão contém tuplas:
[ (x_i, a_i, r_i, p_i), \quad i = 1,\dots,n ]
- (x_i): contexto (características do usuário, consulta, horário, dispositivo etc.)
- (a_i): ação tomada (anúncio exibido, item recomendado, tratamento escolhido)
- (r_i): recompensa observada (clique, compra, utilidade, desfecho)
- (p_i = \mu(a_i \mid x_i)): propensão (propensity), a probabilidade de que a política de logging (logging policy) (\mu) tenha escolhido a ação (a_i) no contexto (x_i)
Você quer avaliar uma política de avaliação (evaluation policy) (\pi(a \mid x)). A quantidade-alvo é o valor da política:
[ V(\pi) = \mathbb{E}{x \sim D}\left[ \mathbb{E}{a \sim \pi(\cdot \mid x)}[ r(x,a) ] \right] ]
Em dados de bandit registrados, você só observa (r_i) para a ação que foi de fato tomada—este é o cerne do problema do “contrafactual ausente”.
Principais suposições (o que precisa ser verdadeiro para a OPE funcionar)
OPE não é “estimação gratuita de desempenho”; ela depende de suposições. Na prática, as mais importantes são:
1) Propensões corretas (probabilidades de logging conhecidas)
Você deve conhecer (p_i = \mu(a_i \mid x_i)) com precisão para cada evento registrado.
Violações comuns:
- propensões não são registradas
- propensões são registradas incorretamente (bugs, pós-processamento, mudanças de filtragem de candidatos)
- o sistema usa regras de negócio ocultas não capturadas em (p_i)
2) Sobreposição / positividade (suporte)
Se (\pi) atribui probabilidade a ações que (\mu) quase nunca toma, você não consegue avaliar (\pi) de forma confiável a partir dos dados.
Formalmente: se (\pi(a\mid x) > 0), você precisa de (\mu(a\mid x) > 0) (e não muito pequeno) para aqueles (x,a) que importam.
Este é o bloqueador prático mais comum.
3) Ausência de confundimento não medido (dado o contexto registrado)
Em bandits contextuais, a suposição padrão é que dado o contexto registrado (x), a atribuição de ação é randomizada de acordo com (\mu(\cdot\mid x)), e a recompensa depende de (x,a), mas não de variáveis adicionais não registradas que influenciaram a escolha da ação.
Isso espelha suposições de Inferência Causal: você precisa que o contexto registrado capture o que motivou a decisão.
4) Consistência / unidades estáveis
A recompensa observada (r_i) corresponde ao resultado de tomar (a_i) em (x_i), e os resultados de um exemplo não são afetados por ações tomadas em outros exemplos (sem interferência). Isso pode falhar em leilões, marketplaces ou sistemas sociais.
Estimadores centrais de OPE
Estimadores de OPE tipicamente fazem um trade-off entre viés e variância. Três estimadores “canônicos” são:
- Método Direto (Direct Method, DM): baseado em modelo, baixa variância, pode ser enviesado
- Pontuação Inversa de Propensão (Inverse Propensity Scoring, IPS): não enviesado (sob suposições), alta variância
- Duplamente Robusto (Doubly Robust, DR): combina ambos; frequentemente o melhor na prática
Método Direto (DM)
Ajuste um modelo de recompensa (\hat{q}(x,a) \approx \mathbb{E}[r \mid x,a]) usando dados registrados e então avalie:
[ \hat{V}{DM}(\pi) = \frac{1}{n}\sum{i=1}^n \sum_{a} \pi(a\mid x_i), \hat{q}(x_i,a) ]
Prós
- Normalmente baixa variância
- Funciona mesmo se (\pi) diferir substancialmente de (\mu)
Contras
- Pode ser fortemente enviesado se (\hat{q}) estiver errado
- É fácil introduzir vazamento (por exemplo, usar características que dependem da ação tomada)
O DM costuma ser a primeira linha de base, mas raramente é suficiente sozinho.
Pontuação Inversa de Propensão (IPS) / ponderação por importância
O IPS usa Amostragem por Importância para “reponderar” recompensas observadas de modo a corresponder à política de avaliação:
[ \hat{V}{IPS}(\pi) = \frac{1}{n}\sum{i=1}^n \frac{\pi(a_i\mid x_i)}{\mu(a_i\mid x_i)} r_i = \frac{1}{n}\sum_{i=1}^n w_i r_i ]
onde (w_i = \pi(a_i\mid x_i) / p_i).
Prós
- Não enviesado se as propensões estiverem corretas e houver sobreposição
- Não requer modelagem de recompensas
Contras
- Pode ter variância enorme quando alguns (p_i) são pequenos
- Sensível a bugs de logging
IPS auto-normalizado (SNIPS)
Uma variante comum de redução de variância normaliza pelo peso total:
[ \hat{V}_{SNIPS}(\pi) = \frac{\sum_i w_i r_i}{\sum_i w_i} ]
O SNIPS é enviesado em geral, mas frequentemente tem menor variância e melhor estabilidade empírica.
Duplamente Robusto (DR)
O DR adiciona um termo de correção ao DM usando ponderação ao estilo IPS:
[ \hat{V}{DR}(\pi) = \frac{1}{n}\sum{i=1}^n \left[ \sum_{a}\pi(a\mid x_i)\hat{q}(x_i,a) ;+; \frac{\pi(a_i\mid x_i)}{\mu(a_i\mid x_i)}\left(r_i-\hat{q}(x_i,a_i)\right) \right] ]
Por que “duplamente robusto”? Sob condições padrão, o DR é consistente se ou:
- o modelo de propensão/propensões registradas estiver correto, ou
- o modelo de recompensa (\hat{q}) estiver correto
(Para bandits, se você tem propensões registradas verdadeiras, essa “dupla robustez” é especialmente atraente: mesmo um modelo de recompensa mediano pode reduzir a variância de forma significativa.)
Variantes práticas comuns
- DR com cross-fitting (cross-fitted DR): ajustar (\hat{q}) em um fold e avaliar em outro para reduzir viés por overfitting.
- DR com clipping/trim (clipped/trimmed DR): limitar pesos (w_i) para reduzir variância de cauda pesada (ao custo de viés).
- Switch-DR: usar IPS/DR apenas quando os pesos não são extremos; caso contrário, voltar ao DM.
Exemplo prático: avaliando uma nova política de recomendação
Imagine que um recomendador de notícias escolhe um de 5 artigos por visita. A política de logging (\mu) era uma política de exploração (por exemplo, epsilon-greedy) e registra propensões.
Temos arrays de dados:
x: características de contextoa: índice da ação escolhidar: recompensa (clique: 0/1)p: propensão da ação escolhida sob o loggingpi_probs: probabilidades da política de avaliação (\pi(\cdot\mid x_i)) sobre ações
IPS em Python (bandit)
import numpy as np
def ips_value(a, r, p, pi_probs):
# a: (n,) int actions
# r: (n,) rewards
# p: (n,) logging propensities for chosen action
# pi_probs: (n, K) evaluation policy probs
n = len(r)
pi_chosen = pi_probs[np.arange(n), a]
w = pi_chosen / p
return np.mean(w * r)
def snips_value(a, r, p, pi_probs):
n = len(r)
pi_chosen = pi_probs[np.arange(n), a]
w = pi_chosen / p
return np.sum(w * r) / np.sum(w)
Duplamente Robusto em Python (com um modelo de recompensa)
Suponha que você treinou um modelo que prevê (\hat{q}(x,a)) para cada ação (por exemplo, um classificador por ação ou um modelo conjunto).
def dr_value(a, r, p, pi_probs, q_hat):
# q_hat: (n, K) predicted E[r | x_i, a]
n, K = q_hat.shape
pi_q = np.sum(pi_probs * q_hat, axis=1) # sum_a pi(a|x)*q_hat(x,a)
q_chosen = q_hat[np.arange(n), a]
pi_chosen = pi_probs[np.arange(n), a]
w = pi_chosen / p
return np.mean(pi_q + w * (r - q_chosen))
Em sistemas reais, o DR frequentemente supera o IPS porque o termo ((r - \hat{q}(x,a))) é um resíduo, que pode ter variância muito menor do que recompensas brutas.
Intervalos de confiança e incerteza (frequentemente negligenciados)
Estimativas pontuais não são suficientes—a OPE pode ser ruidosa, e uma certeza enganosa é perigosa. Abordagens comuns:
- Bootstrap não paramétrico sobre eventos registrados: simples, frequentemente razoável quando os dados são i.i.d.
- ICs normais assintóticos para IPS/DR sob condições (podem ser frágeis com pesos de cauda pesada)
- Limites de concentração / limites de Bernstein empíricos: mais conservadores, às vezes usados em cenários críticos para segurança
Um diagnóstico prático: inspecione a distribuição dos pesos (w_i). Se ela tiver cauda pesada (alguns poucos pesos enormes), os intervalos de confiança serão largos e as estimativas, instáveis.
Uma heurística aproximada de “tamanho efetivo da amostra”:
[ n_{eff} = \frac{\left(\sum_i w_i\right)^2}{\sum_i w_i^2} ]
Se (n_{eff}) for minúsculo em relação a (n), sua OPE está, na prática, baseada em pouquíssimas amostras informativas.
Armadilhas comuns (e como evitá-las)
Armadilha 1: Sem sobreposição (a nova política é diferente demais)
Sintomas:
- pesos (w_i) extremamente grandes
- estimativas dominadas por um punhado de amostras
- variância enorme e resultados instáveis entre sementes aleatórias/bootstraps
Mitigações:
- garantir que a política de logging tenha exploração suficiente (por exemplo, em Bandits de Múltiplos Braços, evitar logging greedy determinístico)
- restringir a avaliação a uma classe de políticas segura próxima de (\mu)
- usar clipping/trim de pesos (com trade-off explícito de viés)
- coletar novos dados com melhor cobertura
Armadilha 2: Propensões incorretas (bugs de logging)
IPS/DR dependem criticamente de (p_i). Problemas frequentes no mundo real:
- filtragem do conjunto de candidatos: propensões calculadas para um conjunto diferente daquele que estava de fato disponível
- múltiplos estágios de ranqueamento: a probabilidade do item finalmente exibido não é a que está registrada
- incompatibilidade de versão da política: dados coletados sob muitos (\mu_t), mas tratados como um só
- lógica determinística de fallback não refletida nas propensões
Mitigações:
- registrar propensões no momento da decisão para a ação efetivamente tomada e o conjunto de candidatos efetivo
- registrar IDs de versão da política e as características usadas
- construir verificações de “validação de propensão” (por exemplo, para cada tipo de contexto, garantir que as propensões somem apropriadamente entre candidatos quando possível)
- preferir designs de logging randomizados em que as probabilidades de atribuição são conhecidas por construção
Armadilha 3: Vazamento no modelo de recompensa (viés em DM/DR)
Modelos de recompensa podem acidentalmente usar informação não disponível no momento da decisão, como:
- efeitos de “posição” que dependem do ranqueamento escolhido
- características pós-clique
- desfechos a jusante influenciados por ações anteriores na sessão
Mitigações:
- impor proveniência estrita de características (“disponível no momento da decisão”)
- usar cross-fitting para reduzir viés por overfitting no DR
- checar sanidade de estimativas do DM contra o IPS quando a sobreposição permitir
Armadilha 4: Não estacionariedade e feedback atrasado
Dados registrados podem vir de um ambiente em mudança:
- sazonalidade (fins de semana vs dias úteis)
- mudança na população de usuários
- conversões atrasadas (compra acontece dias depois)
- ciclos de retroalimentação (recomendações mudam o que os usuários veem e gostam)
Mitigações:
- incluir características de tempo/contexto e estratificar a avaliação
- alinhar janelas de recompensa (por exemplo, só avaliar após a janela de conversão se encerrar)
- usar replay com regras apropriadas de censura/rotulagem
- considerar se a suposição de bandit é violada (a política afeta contextos futuros)
Armadilha 5: Interferência e efeitos de marketplace
Em leilões de anúncios ou marketplaces, exibir o item A pode afetar resultados para o item B (competição, restrições de orçamento). A OPE padrão assume resultados independentes por evento, o que pode falhar.
Mitigações:
- avaliar em uma unidade na qual a interferência seja minimizada (por exemplo, por leilão em vez de por impressão)
- usar experimentação quando viável
- incorporar modelos estruturais se a interferência for inevitável (mais difícil, mais suposições)
Armadilha 6: Ações em slate e ranqueamento (espaço de ações combinatório)
Muitos recomendadores escolhem uma lista (slate) de itens. A “ação” então é um objeto combinatório; o IPS ingênuo pode explodir em variância porque as probabilidades de slate são minúsculas.
Mitigações:
- registrar a probabilidade do slate inteiro sob a política de logging (difícil, mas às vezes possível)
- usar modelos fatorados (propensões por posição) apenas se justificado pelo mecanismo de logging
- usar estimadores especializados (por exemplo, métodos list-wise ou métodos baseados em posição para atribuição de crédito)
Orientação prática: escolhendo um estimador
Uma abordagem pragmática comum:
- Comece com DM (linha de base rápida) e IPS/SNIPS (checagem de sanidade sob sobreposição).
- Prefira DR com cross-fitting como padrão principal quando você tem:
- propensões registradas,
- um modelo de recompensa razoável,
- sobreposição moderada.
Heurísticas:
- Se os pesos se comportam bem e a sobreposição é boa, IPS/DR podem ser confiáveis.
- Se os pesos são extremos, qualquer estimador será frágil; DR + clipping pode ser o “menos ruim”, mas você deve tratar resultados como de baixa confiança e considerar coletar novos dados.
Relação com aprendizado de políticas (otimização offline)
A OPE é frequentemente usada dentro de otimização offline de políticas (offline policy optimization) (também conhecida como aprendizado contrafactual): você busca sobre políticas (\pi_\theta) para maximizar uma estimativa de OPE (\hat{V}(\pi_\theta)).
Isso introduz um risco extra: overfitting ao estimador de OPE. Uma classe de políticas pode explorar o ruído do estimador e parecer excelente offline, mas falhar online.
Mitigações:
- separar dados para avaliação final (divisão treino/validação/teste)
- usar objetivos pessimistas (limite inferior de confiança) por segurança
- regularizar políticas para permanecerem próximas à política de logging (reduz variância via melhor sobreposição)
Extensões além de bandits (breve)
Em Processos de Decisão de Markov de horizonte mais longo, a OPE precisa lidar com trajetórias, mudança da distribuição de estados e erros que se acumulam. Famílias comuns de métodos incluem:
- amostragem por importância por trajetória e por decisão (frequentemente variância muito alta)
- avaliação baseada em modelo (aprender a dinâmica; pode ser enviesada)
- avaliação Q ajustada (FQE) e outros métodos baseados em função de valor
Mesmo que você eventualmente precise de OPE sequencial, os conceitos de OPE em bandits—sobreposição, propensões, pesos de importância, estimação duplamente robusta—continuam fundamentais.
Um checklist prático de OPE
Antes de confiar em uma estimativa offline, verifique:
- Propensões
- (p_i) estão registradas para a decisão real?
- Elas refletem corretamente a filtragem de candidatos e o desempate?
- Sobreposição
- Os pesos (w_i) são limitados e não têm cauda pesada demais?
- O tamanho efetivo da amostra (n_{eff}) é razoável?
- Robustez do estimador
- IPS e DM discordam de forma extrema? (Isso é um sinal de alerta.)
- O DR reduz variância sem sensibilidade extrema?
- Validade dos dados
- A recompensa é definida de forma consistente (atrasos, censura, atribuição)?
- Contextos e características são apenas “do momento da decisão”?
- Incerteza
- Você tem intervalos de confiança (bootstrap ou outro)?
- Os resultados são estáveis entre recortes temporais e subpopulações?
A avaliação off-policy permite iteração rápida sem testes online constantes, mas ela só é tão confiável quanto suas suposições e a qualidade do logging. Em muitos sistemas de produção, investir em logging randomizado correto e instrumentação de propensões gera ganhos maiores do que qualquer estimador engenhoso.