Vencendo com Multi-Armed Bandits: Experimentação Inteligente em Databricks
Publicado em 18 de agosto de 2025
Realizar experimentos muitas vezes parece um jogo de apostas. Você deve direcionar mais volume para a variante A ou dar outra chance para a variante B? O teste A/B tradicional divide o tráfego e espera — mas e se você pudesse adaptar continuamente, maximizando ganhos conforme aprende? Entre os Multi-Armed Bandits: uma elegante mistura de probabilidade, estatística e tomada de decisão que transforma experimentos em motores dinâmicos de otimização.
Assim como escolher a máquina certa em um cassino, Multi-Armed Bandits ajudam a decidir qual opção merece sua próxima moeda — aqui, a moeda é tráfego, impressões ou atenção do usuário. Vamos explorar como funcionam, por que superam os testes estáticos e como aplicamos isso no Databricks.
O Problema dos Testes A/B Estáticos
Testes A/B tradicionais dividem o tráfego entre variantes e esperam até que os resultados alcancem significância estatística. A divisão não precisa ser 50/50 — você pode usar 90/10 ou outras proporções — mas quanto menor a alocação para uma variante, mais tempo leva para reunir evidências suficientes.
Na nossa empresa, usamos bastante testes A/B para mudanças estruturais grandes na experiência do usuário. Pense em um novo fluxo de onboarding, uma página de pagamento redesenhada ou uma mudança de navegação no app. Nessas decisões, queremos o rigor e a certeza de um teste A/B tradicional.
Mas quando se trata de experimentação rápida — como testar assuntos de e-mail, templates de CRM ou novas propostas de valor — depender apenas de A/B estático nos atrasaria muito. Isso porque o A/B tradicional tem algumas desvantagens embutidas:
- Oportunidade perdida: variantes mais fracas continuam recebendo tráfego até o fim do teste.
- Aprendizado lento: alcançar significância pode levar dias ou semanas, especialmente com divisões desbalanceadas.
- Sem adaptatividade: uma vez definida a divisão, o sistema não ajusta conforme o desempenho.
É aí que os Multi-Armed Bandits brilham: equilibram continuamente exploração (testar variantes incertas) com exploração (apostar nos melhores desempenhos), adaptando alocações em tempo real conforme os resultados chegam.
A Intuição dos Multi-Armed Bandits
Imagine-se entrando em um cassino com várias máquinas caça-níqueis. Cada máquina (ou "braço") tem uma probabilidade de pagamento desconhecida — algumas generosas, outras não. Você tem um número limitado de moedas, e cada moeda gasta é uma chance de aprender qual máquina é mais lucrativa.
O dilema: se você jogar apenas em uma máquina desde o início, pode perder uma melhor logo ao lado. Se espalhar suas moedas igualmente, vai desperdiçar jogadas nas máquinas ruins.
A estratégia ótima está no meio: experimentar o suficiente para explorar o cenário, mas também apostar mais nas que parecem promissoras (explorar).
Essa é a essência do problema dos Multi-Armed Bandits. Cada "tentativa" — seja puxar a alavanca de uma máquina ou enviar um assunto de e-mail — traz mais informação sobre o verdadeiro pagamento. Com o tempo, a estratégia ajusta, direcionando cada vez mais moedas para as máquinas que entregam os melhores retornos.
No marketing ou produto, cada "braço" é uma variante — um assunto de e-mail, um design de landing page, uma estratégia de recomendação. Cada "moeda" é uma unidade de atenção do usuário — um envio, uma impressão ou uma visita. O framework realoca o tráfego continuamente, recompensando bons desempenhos sem ignorar totalmente os incertos, para descobrir vencedores mais rápido e minimizar arrependimentos.
Uma Abordagem Bayesiana com Distribuições Beta
Ao experimentar, cada interação do usuário é basicamente um teste binário: sucesso ou fracasso (clicou ou não, converteu ou não). Isso se encaixa naturalmente na distribuição binomial, que descreve a probabilidade de observar um certo número de sucessos em um número fixo de tentativas.
Por exemplo:
- Se enviarmos 1.000 e-mails e obtivermos 30 cliques, podemos pensar nisso como 1.000 testes de Bernoulli (cada usuário clica = 1 ou não = 0).
- A distribuição binomial nos diz a probabilidade de ver exatamente 30 sucessos (ou 31, ou 29) dado uma taxa de clique (CTR) "verdadeira" subjacente.
O desafio: não sabemos a CTR verdadeira de antemão. É aí que entra a estatística bayesiana.
Entra a Distribuição Beta
A distribuição Beta é parceira natural da binomial porque serve como prior conjugado. Em outras palavras: permite atualizar nossas crenças suavemente conforme novos dados chegam.
Para cada variante i, modelamos o CTR como:
$$CTR_i \sim \text{Beta}(\alpha, \beta),$$
onde $\alpha$ representa o número de sucessos observados (cliques), $\beta$ o número de fracassos (não cliques), e juntos definem uma distribuição de probabilidade sobre o verdadeiro CTR.
Intuitivamente:
- Uma variante com poucos dados tem uma curva larga e incerta — pode ser ótima ou péssima.
- Uma variante com muitos dados tem uma curva estreita e precisa — estamos muito mais confiantes sobre seu CTR.
Exemplo
Vamos comparar três variantes, todas com ~3% de CTR mas tamanhos de amostra diferentes:
| Envios | Cliques | CTR | Intervalo de Confiança 95% |
|---|---|---|---|
| 1.000 | 30 | 2,955% | [2,11%, 4,25%] |
| 10.000 | 300 | 2,995% | [2,68%, 3,35%] |
| 100.000 | 3.000 | 2,999% | [2,90%, 3,11%] |
Note que a média do CTR permanece igual, mas o intervalo de confiança diminui conforme os dados aumentam. Essa é a ideia central: nem todo CTR de 3% é igual — a quantidade de evidência muda o quanto devemos confiar nele.
Podemos visualizar isso plotando as distribuições Beta para cada caso. Com menos amostras, a curva é larga e incerta. Com mais amostras, fica estreita e concentrada em torno de 3%.
Thompson Sampling em Ação
Agora temos, para cada variante, uma distribuição posterior sobre seu verdadeiro CTR. Pense em cada curva Beta como nossa crença atualizada após observar sucessos e fracassos, ou seja, usando $\alpha = \alpha + \text{cliques}$ e $\beta = \beta + (\text{envios} - \text{cliques})$ para atualizar o prior.
Thompson Sampling transforma essa incerteza em ação:
- Para cada variante, sorteie uma amostra aleatória de sua posterior (curva Beta).
- Selecione a variante com o maior valor sorteado para aquela "tentativa".
- Repita muitas vezes; a proporção de "vitórias" por variante estima a probabilidade de ser a melhor.
Essas probabilidades de vitória são pesos naturais para o próximo lote. Variantes com posteriors mais largas (mais incertas) ainda vencem em alguns mundos simulados (exploração), enquanto variantes consistentemente fortes vencem com frequência e recebem mais tráfego (exploração).
Exemplo de alocação por simulação
Cenário: três variantes com ~3% de CTR e tamanhos de amostra diferentes
(1.000 envios / 30 cliques), (10.000 envios / 300 cliques), (100.000 envios / 3.000 cliques).
- Parâmetros posteriores (assumindo prior Beta(1,1)): α = [31, 301, 3001], β = [971, 9701, 97001].
- Probabilidade estimada de cada variante ser a melhor (via simulação Thompson): [0,491, 0,282, 0,228].
- Alocação sugerida para o próximo lote: [49,1%, 28,2%, 22,8%].
Mesmo com médias de CTR semelhantes, a menor amostra tem posterior mais larga e às vezes sorteia alto, vencendo em muitos mundos simulados. Isso é exploração. Conforme a evidência cresce, os posteriors se estreitam e a variante boa começa a dominar a alocação. Isso é exploração.
Em produção, você pode adicionar limites mínimos de alocação e rampas máximas, mantendo o comportamento adaptativo.
Por trás dos panos, os sorteios vêm dos posteriors Beta atualizados (variáveis aleatórias Beta), e as contagens de vitórias nas simulações aproximam a probabilidade de cada variante ser o "melhor braço".
Arquitetura: Multi-Armed Bandits no Databricks + Engage (AWS)
Nossa ferramenta de CRM usada para enviar mensagens aos usuários se chama Engage e foi construída internamente. Ela usa principalmente AWS SES para enviar e-mails aos clientes, e os dados são rastreados em tempo real usando Kinesis com Databricks, alimentando tabelas Delta. Usuários podem configurar testes AB na ferramenta com N variantes e publicá-los — o percentual de volume alocado para cada variante será atualizado usando o framework acima.
Em alto nível, separamos dois loops: um loop de dados em tempo real que mantém as métricas do CRM atualizadas (≤ ~1 minuto), e um loop de decisão que periodicamente atualiza os pesos das variantes usando Bandits. O loop de decisão lê métricas agregadas do Delta (Gold), calcula novos pesos via Thompson Sampling e publica de volta no Engage, onde os usuários são atribuídos determinísticamente às variantes.
Quadro A - Fluxo de Dados CRM em Tempo Real (≤ ~1 min de latência)
- Engage dispara envios com experiment_id e variant_id.
- E-mails saem via Amazon SES; eventos de rastreamento (envio, entrega, bounce, abertura, clique) chegam via SNS, que são alimentados no Amazon Kinesis e consumidos por um job de streaming no Databricks.
- O job de streaming processa e enriquece eventos (user_id, experiment_id, variant_id, timestamps) e grava em tabelas na arquitetura Medallion.
- Mantemos uma tabela Delta Gold por variante: envios, aberturas, cliques, descadastros e outras métricas por experiment_id × variant_id (atualização minuto a minuto).
Quadro B - Loop de Alocação Bandit (a cada X minutos)
- Um agendador invoca o job Bandit para cada experimento ativo.
- O job lê a tabela Gold e atualiza os posteriors (alpha, beta) por variante, usando a conversão configurada (clique, abertura ou conversão in-site).
- O job executa Thompson Sampling para estimar a probabilidade de ser o melhor para cada variante e deriva novos pesos.
- O job grava pesos e metadados em uma tabela Delta de alocações e publica os pesos atuais na configuração de AB Test do Engage (DynamoDB).
Trade-offs, Limites e Quando Usar o Quê
Bandits não são mágica; são uma escolha de política. Eles brilham quando velocidade de aprendizado e adaptação contínua importam — assuntos de e-mail, templates, ofertas rápidas. São menos interessantes para decisões lentas e de alto impacto (ex: redesign de checkout), onde o A/B clássico traz a defesa que você quer.
Dois pontos práticos mantêm os bandits honestos. Primeiro, priors: se você conhece o CTR histórico de um canal, use um prior baseado em dados para evitar explorar demais em cold start. Segundo, limites: imponha uma alocação mínima por braço, limite rampas entre ciclos e defina regras de parada (ex: graduar automaticamente um vencedor após alta probabilidade sustentada de ser o melhor). Se o agendador atrasar, use os últimos pesos conhecidos ou uma divisão conservadora. Essas práticas evitam o problema do "sorteio ruim inicial" e mantêm a produção estável.
O Que Aprendemos (e Próximos Passos)
Após adotar esse loop, duas coisas ficaram claras. Primeiro, tempo até o vencedor caiu — não por sorte, mas porque a política parou de desperdiçar volume em variantes ruins. Segundo, confiança ficou visível: ao plotar posteriors e intervalos, fica claro quando um "CTR de 3%" é respaldado por 1k ou 100k envios, permitindo decisões informadas para produto e CRM.
Uma próxima evolução natural é um recompensa composta, não um único métrico. O CRM precisa equilibrar reputação com provedores, conversão in-site e desengajamento. Uma recompensa escalar como
$$ \text{recompensa} = w_\text{abertura}\cdot \text{abertura} + w_\text{clique}\cdot \text{clique} + w_\text{conv}\cdot \text{conversao} \; - \; w_\text{descad}\cdot \text{descadastro} $$
permite capturar esses trade-offs explicitamente. Otimizar só CTR pode destacar variantes que também aumentam descadastros — já vimos esse padrão e não queremos promovê-lo. Na prática, os pesos devem ser normalizados e gerenciados com cuidado. Falaremos de recompensas compostas e bandits com restrições em um post futuro.
A próxima fronteira são os Bandits Contextuais — deixar que features (canal, dispositivo, segmento, horário) influenciem a política, tornando o "melhor braço" dependente do contexto. É o mesmo backbone bayesiano com uma camada de roteamento mais inteligente. Comece simples, instrumente bem e evolua quando os dados mostrarem que a complexidade extra vale a pena.
Considerações Finais
Se detecção de anomalias é sobre encontrar problemas rápido, Multi-Armed Bandits são sobre encontrar oportunidades mais rápido. Transformam experimentação de divisão fixa em um sistema vivo que aprende onde sua atenção gera retorno. Na prática, a matemática é modesta, o footprint operacional é pequeno e o ganho — menos envios desperdiçados, convergência mais rápida, confiança mais clara — se acumula com o tempo.
Ferramentas simples, bem combinadas, ainda vencem.
