Teste A/B

Visão geral

Teste A/B (A/B testing) (também chamado de experimento controlado online (online controlled experiment)) é um método para medir o impacto causal de uma mudança em um sistema em produção ao atribuir aleatoriamente unidades (usuários, sessões, requisições etc.) a:

  • Controle (A) (control): a experiência-base atual
  • Tratamento (B) (treatment): o novo recurso/modelo/prompt/mudança de UX

Como a atribuição é aleatória, diferenças nos resultados entre A e B podem ser atribuídas (sob certas suposições) à própria mudança, e não a fatores de confusão. Em sistemas de IA/AM (AI/ML), o teste A/B costuma ser a forma mais confiável de responder a perguntas como:

  • “O novo modelo de ranqueamento (ranking model) aumenta as conversões (conversions) sem prejudicar a latência (latency)?”
  • “Um assistente baseado em modelo de linguagem grande (LLM, large language model) reduz o tempo de atendimento sem aumentar as escalas para níveis superiores (escalations)?”
  • “Um recurso de personalização melhora a retenção e para quais segmentos?”

O teste A/B se encaixa dentro de Avaliação em Produção (Evaluation in Production): ele complementa a avaliação offline (offline evaluation) (por exemplo, métricas em conjunto retido (held-out metrics)) ao medir efeitos no mundo real sob o comportamento real dos usuários e restrições do sistema. Abordagens relacionadas incluem Avaliação Offline, Avaliação Contrafactual e Bandits de Múltiplos Braços.

Quando o teste A/B é a ferramenta certa (e quando não é)

Testes A/B são melhores quando você pode expor com segurança um subconjunto do tráfego e você se importa com resultados de produto de ponta a ponta (não apenas loss/acurácia do modelo). Casos de uso típicos:

  • Recomendadores/busca/ranqueamento: mudanças no modelo de ranqueamento, features, lógica de combinação (blending)
  • Sistemas de anúncios/leilão: atualizações no modelo de lance, lógica de pacing (pacing)
  • Recursos de produto com modelo de linguagem grande: templates de prompt, configurações de recuperação (retrieval), políticas de uso de ferramentas (tool-use)
  • Detecção de fraude/abuso: limiares, políticas de decisão (com cuidado)
  • Mudanças combinadas de UI + AM: por exemplo, novo painel de explicação + atualização de modelo

Situações em que testes A/B clássicos podem ser difíceis:

  • Interferência forte/efeitos de rede (network effects) (marketplaces, feeds sociais) em que o tratamento de um usuário afeta outros
  • Resultados lentos (churn ao longo de meses) em que esperar é caro
  • Mudanças de alto risco (decisões críticas de segurança) em que a exposição precisa ser rigidamente controlada
  • Sistemas com aprendizado contínuo em que as atualizações do modelo durante o teste podem confundir os resultados

Nesses casos, ainda é possível fazer teste A/B, mas em geral é preciso trabalho extra de desenho (randomização por clusters (cluster randomization), grupos de retenção (holdouts) ou lançamentos em etapas (staged rollouts)) ou métodos complementares como Inferência Causal.

Desenhando um experimento

Bons testes A/B começam com clareza: qual mudança, quem é afetado, qual resultado você espera e o que pode dar errado.

Defina a hipótese e o estimando

Escreva uma hipótese falsificável com um resultado mensurável:

  • “Trocar para o modelo de ranqueamento v2 aumenta a taxa de conversão em compra em ≥ 0,3% (relativo) entre usuários elegíveis ao longo de 14 dias.”

Defina também o estimando (estimand): a quantidade causal exata que você quer. Escolhas comuns:

  • Efeito Médio do Tratamento (ATE, Average Treatment Effect): diferença média entre tratamento e controle
  • Intenção de Tratar (ITT, Intent-to-Treat): efeito da atribuição (padrão recomendado)
  • Tratamento nos Tratados (TOT, Treatment-on-the-Treated): efeito entre os que de fato receberam o tratamento (mais difícil; exige suposições)

Para recursos de AM, ITT costuma ser mais seguro porque sistemas em produção têm não conformidade (noncompliance) (cache misses, fallbacks, elegibilidade parcial).

Escolha a unidade de randomização

A unidade (unit of randomization) é o que é atribuído a A ou B:

  • Randomização no nível de usuário: melhor quando os efeitos persistem entre sessões e você quer experiências estáveis (atribuição persistente (sticky assignment)).
  • No nível de sessão: útil quando a experiência é reiniciada a cada sessão; reduz contaminação de longo prazo, mas pode aumentar a variância.
  • No nível de requisição: às vezes usada para experimentos de infraestrutura; arriscada para mudanças voltadas ao usuário por causar experiências inconsistentes.
  • No nível de cluster (região, escola, coorte de marketplace): usada quando se espera interferência.

Em sistemas de AM, a randomização no nível de usuário é comum porque comportamento e personalização se acumulam ao longo do tempo.

Defina exposição e elegibilidade

Você precisa de uma definição precisa de:

  • População elegível: quem poderia ver o recurso (por exemplo, usuários logados em localidades suportadas)
  • Evento de exposição: o que significa ter “recebido” o tratamento (por exemplo, uma lista ranqueada gerada pelo modelo v2)

Rastreie tanto a atribuição quanto a exposição. Um padrão comum é:

  • Registrar experiment_assignment no início da requisição
  • Registrar treatment_exposure quando o componente realmente executou (chamada do modelo bem-sucedida, prompt usado etc.)

Isso ajuda a diagnosticar não conformidade e interpretar resultados.

Implementação da randomização (e por que isso importa)

A randomização precisa ser reprodutível, não enviesada e difícil de quebrar por acidente.

Uma abordagem típica é segmentação por buckets baseada em hash (hash-based bucketing):

import hashlib

def assign_variant(user_id: str, experiment_id: str, p_treatment=0.5) -> str:
    key = f"{experiment_id}:{user_id}".encode("utf-8")
    h = hashlib.sha256(key).hexdigest()
    x = int(h[:8], 16) / 16**8  # uniform in [0,1)
    return "treatment" if x < p_treatment else "control"

Boas práticas:

  • Atribuição persistente: mapeamento estável para um usuário ao longo das sessões
  • Determinístico: mesma entrada → mesmo bucket (bom para depuração)
  • Isolamento por experimento: inclua experiment_id no hash
  • Randomização estratificada (stratified randomization): se covariáveis importantes importam (por exemplo, plataforma, região), faça buckets separadamente dentro de estratos para reduzir desbalanceamento

Execute periodicamente um teste A/A (A/A test) (duas variantes idênticas) para validar instrumentação e verificar se as taxas de falso positivo batem com as expectativas.

Alocação de tráfego e ramp-ups

Em vez de pular direto para 50/50, muitas equipes fazem rampa gradual de tráfego (ramp-up):

  • 1% → 5% → 10% → 25% → 50%
  • Pausar em cada etapa para monitorar métricas de guarda

Estratégias comuns de alocação:

  • 50/50: maximiza o poder para experimentos com dois braços
  • 90/10: reduz risco, mas aumenta o tempo para atingir significância
  • Multivariante (A/B/C/...): compara múltiplos tratamentos; requer controle de testes múltiplos

Considere também um grupo de retenção de longa duração (por exemplo, 1–5% permanentemente no baseline) para detectar regressões de longo prazo após a implantação completa (rollout), especialmente quando modelos evoluem.

Escolhendo métricas de sucesso e métricas de guarda

Defina um Critério Geral de Avaliação (OEC)

Escolha uma métrica primária que você usará para decidir lançar/não lançar. O Critério Geral de Avaliação (OEC, Overall Evaluation Criterion) deve refletir o objetivo do produto e ser difícil de “jogar”. Exemplos:

  • Recomendador: compras por usuário ou receita por sessão
  • Assistente de suporte: taxa de resolução de problemas e/ou tempo até resolução
  • Busca: buscas bem-sucedidas por usuário (ou conversões downstream), não apenas taxa de cliques (CTR, click-through rate)

Evite escolher apenas métricas proxy (proxy metrics) que podem mudar sem valor real (por exemplo, cliques podem aumentar por clickbait).

Métricas de guarda (não causar dano)

Métricas de guarda (guardrail metrics) são métricas que não devem regredir além de um limiar. Em IA/AM, métricas de guarda comuns incluem:

  • Latência (p95/p99), timeouts, taxas de erro
  • Custos do sistema: tokens de GPU/modelo de linguagem grande, gasto de inferência (inference) por requisição
  • Qualidade e segurança: taxa de reclamações, taxa de escalonamento, violações de políticas
  • Equidade (fairness) entre grupos (quando aplicável): indicadores de impacto discrepante (disparate impact) (link para Equidade em AM)
  • Restrições de negócio: taxa de reembolso, chargebacks, métricas de conformidade regulatória

Defina limiares explícitos antes de executar o teste, por exemplo:

  • “A latência p99 não pode aumentar mais do que 20 ms”
  • “O custo do modelo de linguagem grande por ticket resolvido não pode aumentar mais do que 5%”

Indicadores antecedentes vs. retardatários

Muitos resultados importantes são atrasados (retenção, churn, valor do tempo de vida). Em geral, você precisa de:

  • Indicadores antecedentes (leading indicators) (curto prazo): engajamento, conclusão de tarefa
  • Indicadores retardatários (lagging indicators) (longo prazo): retenção, receita ao longo de semanas

Por exemplo, um novo ranqueamento de feed pode aumentar o engajamento no dia seguinte (antecedente), mas prejudicar a retenção de longo prazo (retardatário). Planeje a duração do teste e as regras de parada para levar isso em conta.

Definições de métricas: seja preciso

Ambiguidade causa confusão sem fim. Defina:

  • Numerador/denominador (por exemplo, “conversões / sessões elegíveis”)
  • Janela de atribuição (na mesma sessão vs. 7 dias)
  • Lógica de deduplicação (por usuário por dia?)
  • Filtragem de bots e exclusão de tráfego interno
  • O que acontece com dados ausentes/timeouts

Fundamentos estatísticos: significância, poder e confiança

Noções básicas de teste de hipótese

A maioria dos testes A/B avalia se a diferença entre tratamento e controle é improvável sob uma hipótese nula (null hypothesis) de ausência de efeito. Conceitos-chave:

  • valor‑p (p-value): probabilidade de observar dados pelo menos tão extremos quanto os seus se a nula fosse verdadeira
  • nível de significância (significance level) (α): probabilidade de um erro do Tipo I (falso positivo), comumente 0,05
  • poder estatístico (power) (1−β): probabilidade de detectar um efeito verdadeiro de certo tamanho, comumente 0,8 ou 0,9
  • intervalo de confiança (IC, confidence interval): faixa de tamanhos de efeito plausíveis

Para tomada de decisão, intervalos de confiança costumam ser mais informativos do que um rótulo binário “significativo/não significativo”.

Testes comuns por tipo de métrica

  • Desfechos binários (binary outcomes) (conversão): diferença de proporções (teste z (z-test)) ou regressão logística (logistic regression)
  • Métricas contínuas (receita por usuário, latência): teste t (t-test) ou regressão (frequentemente robusta/por bootstrap (bootstrapped))
  • Métricas de contagem (cliques por usuário): modelos de Poisson/binomial negativa, ou bootstrap

Em plataformas de teste A/B em produção, é comum usar agregados no nível de usuário (user-level aggregates) (um registro por usuário) para reduzir problemas de correlação de eventos repetidos.

Tamanho de amostra e efeito mínimo detectável (MDE)

Antes de lançar, estime quantas unidades você precisa. Para uma métrica de taxa de conversão, o tamanho de amostra depende de:

  • taxa de conversão baseline
  • MDE (efeito mínimo detectável (MDE, minimum detectable effect)) (menor efeito que importa para você)
  • α e poder
  • razão de alocação (allocation ratio)

Um cálculo simplificado para testes de duas proporções é:

[ n \approx \frac{2 (z_{1-\alpha/2} + z_{1-\beta})^2 , p(1-p)}{\Delta^2} ]

Onde (p) é a conversão baseline e (\Delta) é o ganho (lift) absoluto.

Exemplo (Python, aproximado):

import math
from scipy.stats import norm

def sample_size_two_proportions(p=0.10, delta=0.002, alpha=0.05, power=0.8):
    z_alpha = norm.ppf(1 - alpha/2)
    z_beta = norm.ppf(power)
    return 2 * (z_alpha + z_beta)**2 * p * (1 - p) / (delta**2)

print(sample_size_two_proportions(p=0.10, delta=0.002))  # per-variant approx

Notas práticas:

  • MDEs muito pequenos podem exigir amostras enormes; alinhe expectativas com o tráfego.
  • Se você for segmentar resultados (por exemplo, mobile vs. web), garanta poder para os principais recortes ou trate-os como exploratórios.

Redução de variância: CUPED e covariáveis

Métricas online são ruidosas. Redução de variância (variance reduction) melhora o poder sem exigir mais tráfego.

Uma técnica comum é CUPED (experimento controlado usando dados pré‑experimento, Controlled-experiment Using Pre-Experiment Data): ajustar resultados usando comportamento pré-experimento correlacionado com a métrica (por exemplo, compras da semana passada). Outra abordagem: ajuste por regressão com covariáveis (covariates).

Esses métodos preservam a não tendenciosidade sob randomização e podem reduzir materialmente os tamanhos de amostra necessários.

Teste sequencial e “peeking”

Uma armadilha comum: checar resultados diariamente e parar quando p < 0,05. Isso infla falsos positivos.

Opções:

  • Comprometer-se com um horizonte fixo e analisar uma vez.
  • Usar desenhos sequenciais em grupos (group sequential designs) ou gasto de alfa (alpha spending).
  • Usar abordagens bayesianas (Bayesian) com limiares de decisão bem definidos (ainda exige rigor).
  • Se você usa painéis (dashboards) sempre ligados, configure-os para reportar intervalos sequencialmente válidos.

Testes múltiplos e “pesca” de métricas

Se você testa muitas métricas, segmentos e variantes, algumas parecerão significativas por acaso.

Mitigações:

  • Pré-especificar a métrica primária e um pequeno conjunto de métricas secundárias-chave
  • Corrigir para comparações múltiplas quando apropriado (por exemplo, Holm-Bonferroni, Benjamini–Hochberg para cenários exploratórios)
  • Tratar recortes pós-hoc como hipóteses a validar em testes de acompanhamento

Fluxo prático de análise em sistemas de AM

1) Validar a integridade do experimento

Antes de interpretar resultados:

  • Desvio de razão amostral (SRM, sample ratio mismatch): as alocações estão próximas das divisões pretendidas? Grandes desvios geralmente indicam bugs de logging ou atribuição.
  • Balanceamento de covariáveis (covariate balance): verifique se variáveis-chave pré-tratamento (mix de plataforma, região) estão balanceadas.
  • Taxas de exposição (exposure rates): o tratamento de fato recebe o novo modelo/prompt? Os fallbacks são desiguais?

2) Use intenção de tratar como padrão

Analise por grupo atribuído, não por “quem foi exposto”, a menos que você tenha uma estratégia causal forte para não conformidade. ITT responde: o que acontece se implantarmos isso?

3) Atribua métricas de forma consistente

Para métricas no nível de usuário:

  • Agregue eventos por usuário/dia ou usuário/janela do experimento
  • Garanta que usuários que nunca acionaram o recurso sejam tratados de forma consistente (frequentemente incluídos, dependendo do estimando)

Para métricas no nível de requisição, como latência:

  • Cuidado com correlação (muitas requisições por usuário)
  • Considere agrupar erros-padrão por usuário ou usar médias por usuário

4) Interprete a heterogeneidade com cuidado

É útil entender quem se beneficia:

  • usuários novos vs. existentes
  • localidades
  • tipos de dispositivo
  • coortes de alta atividade vs. baixa atividade

Mas lembre-se: muitos recortes aumentam o risco de descobertas falsas. Use a análise de heterogeneidade para gerar hipóteses e depois confirmar.

Armadilhas comuns (especialmente para recursos de IA/AM)

Efeitos de novidade e efeitos de aprendizado

Usuários podem se comportar de forma diferente simplesmente porque algo parece novo (efeitos de novidade (novelty effects)) ou podem levar tempo para aprender uma nova interface (efeitos de aprendizado (learning effects)). Os efeitos podem:

  • disparar no começo e depois decair
  • começar negativos e depois melhorar

Mitigações:

  • rodar tempo suficiente para passar o período de novidade
  • analisar dinâmica temporal (efeito por dia)
  • considerar lançamentos em etapas e grupos de retenção mais longos para medição durável

Interferência e efeitos de rede (violando SUTVA)

Testes A/B assumem que o resultado de um usuário não depende das atribuições de outros. Isso frequentemente falha em:

  • marketplaces (compradores e vendedores interagem)
  • redes sociais (conteúdo vem de outras pessoas)
  • leilões e anúncios (a competição altera preços)
  • ecossistemas de recomendação (o inventário é compartilhado)

Sintomas incluem efeitos diluídos ou enganosos.

Mitigações:

  • randomização por clusters (por região, escola, mercado)
  • desenhar experimentos em torno de métricas em nível de mercado (market-level)
  • usar estimadores causais (causal estimators) especializados quando a interferência é inevitável (link: Inferência Causal)

Amostragem enviesada em produção (efeitos de seleção)

Mesmo com atribuição aleatória, seu conjunto de dados medido pode ser enviesado se o logging ou a elegibilidade depender do tratamento:

  • tratamento aumenta crashes → menos eventos registrados → métricas parecem melhores do que a realidade
  • mudança do modelo causa menos carregamentos de página → menos oportunidades de observar conversões
  • instrumentação difere entre variantes

Mitigações:

  • registrar atribuição no ponto mais cedo possível
  • garantir que caminhos de código de logging sejam compartilhados
  • acompanhar ausência de dados e taxas de queda de eventos como métricas de guarda

Não conformidade, cross-over e contaminação

  • Usuários podem trocar de dispositivo/conta (quebrando a persistência no nível de usuário).
  • Caches/CDNs podem servir experiências mistas.
  • Agentes de suporte ao cliente podem ver as duas versões e mudar o comportamento.

Mitigações:

  • escolher a unidade de randomização correta (conta vs. dispositivo)
  • implementar bucketing consistente entre plataformas
  • monitorar taxas de cross-over e considerar vinculação de contas quando possível

Ciclos de realimentação com sistemas adaptativos/de aprendizado

Sistemas de IA podem mudar o ambiente a partir do qual aprendem:

  • Um novo recomendador muda no que os usuários clicam, mudando dados de treino.
  • Uma ferramenta com modelo de linguagem grande muda fluxos de suporte, alterando rótulos e padrões de resolução.
  • Políticas de aprendizado online podem “aprender” durante o teste, misturando efeitos do tratamento com a evolução da política.

Mitigações:

  • congelar pesos do modelo durante o experimento quando viável
  • versionar pipelines de dados de treino e garantir rotulagem consistente
  • se você precisa aprender online, considere avaliação ciente de bandits (bandit-aware evaluation) ou separar tráfego de exploração vs. avaliação (exploration vs evaluation traffic) (veja Bandits de Múltiplos Braços)

Sazonalidade e mudanças concorrentes

Resultados variam por dia da semana, feriados, campanhas de marketing, incidentes, outages e outros releases.

Mitigações:

  • rodar testes ao longo de ciclos semanais completos quando relevante
  • evitar testes sobrepostos que interagem (ou usar desenhos fatoriais (factorial designs))
  • anotar timelines com incidentes e releases

Exemplos práticos

Exemplo 1: Atualização de modelo de ranqueamento para um feed de e-commerce

Mudança: Substituir o modelo de ranqueamento v1 pelo v2 (novas features + arquitetura).

  • Unidade: nível de usuário
  • Métrica primária (OEC): compras por usuário elegível ao longo de 7 dias
  • Secundárias: taxa de adicionar ao carrinho, receita por usuário
  • Métricas de guarda: latência p95/p99, timeouts, taxa de devolução, reclamações de clientes
  • Tráfego: rampa 1% → 10% → 50%, com rollback automatizado se métricas de guarda estourarem limites
  • Notas de análise:
    • Usar CUPED com compras do período prévio para reduzir variância
    • Observar interferência se o estoque (inventory) for escasso (itens populares), o que pode criar spillovers

Exemplo 2: Mudança de prompt em assistente de suporte ao cliente com modelo de linguagem grande

Mudança: Novo prompt + ajuste de top-k de recuperação.

  • Unidade: nível de ticket (ticket-level) ou nível de sessão do agente (agent-session-level) (dependendo do fluxo)
  • OEC: taxa de resolvido sem escalonamento
  • Métricas de guarda: taxa de violação de políticas, relatos de alucinação (hallucination), tempo médio de atendimento, satisfação do cliente (CSAT, customer satisfaction)
  • Preocupações especiais:
    • resultados atrasados (CSAT chega mais tarde)
    • “novidade”: agentes podem inicialmente confiar demais ou confiar de menos no assistente
    • medição: definir “violação” de forma consistente, muitas vezes via uma amostra de revisão humana mais checagens automatizadas

Esse tipo de experimento frequentemente combina métricas online com avaliação humana direcionada e auditorias (veja Avaliação de LLM se sua wiki incluir isso).

Boas práticas operacionais para experimentação em produção

  • Pré-registrar o plano (pre-register) (mesmo que internamente): hipótese, população, métricas, duração, critérios de parada, exclusões.
  • Instrumentar primeiro, depois experimentar: rode um A/A ou uma simulação (dry-run) para validar logging, SRM e painéis.
  • Automatizar monitoramento de métricas de guarda com alertas e ganchos de rollback.
  • Manter experimentos isolados: gerencie interações entre testes concorrentes (desenhos fatoriais ou exclusões mútuas (mutual exclusions)).
  • Preferir intervalos de confiança + significância prática (practical significance): decisões de lançamento devem considerar tamanho de efeito e risco de negócio, não apenas p < 0,05.
  • Documentar resultados: o que foi lançado, o que não foi, lições aprendidas—especialmente quando resultados são nulos (ainda são valiosos).
  • Planejar monitoramento pós-implantação: após o fim do experimento, continue observando métricas para drift, regressões e efeitos de longo prazo (veja Monitoramento de Modelos e Drift de Dados).

Resumo

O teste A/B é o principal mecanismo de avaliação online (online evaluation) para recursos de IA/AM porque fornece uma forma principiada de estimar impacto causal sob comportamento real dos usuários. Um teste A/B eficaz exige:

  • desenho cuidadoso do experimento (unidade, elegibilidade, exposição)
  • boas métricas de sucesso e métricas de guarda
  • randomização correta e alocação de tráfego
  • rigor estatístico sobre poder, análises sequenciais e comparações múltiplas
  • consciência de armadilhas de produção—especialmente efeitos de novidade, interferência e amostragem enviesada

Quando bem feito, o teste A/B transforma mudanças de modelo e de produto em ciclos de aprendizado mensuráveis e repetíveis, melhorando resultados para usuários enquanto controla risco.